The quality of an automation depends on the quality of the brief behind it. A vague brief produces a vague build, a long email thread of questions and a launch date that keeps moving. A clear brief produces a build that matches what you pictured, delivered on the date you were given, with far fewer revisions. The difference is not talent or technology. It is whether the person building knows what you actually want.
This guide explains how to write a brief for an online store automation, whether you are hiring a freelancer, an agency, a done-for-you service or your own developer. It covers what to write down, how specific to be, the mistakes that cause delays, how to prepare access safely and how to check a brief before you send it. A copy-ready template is available on our store automation brief page.
What a brief is for
A brief is a short document that tells the builder what the automation should do, for which store, under which rules and by when. It does three jobs. It removes guesswork, so the builder spends time building rather than asking. It sets a standard, so you both know what finished means. And it protects you, because everything agreed is written down.
A brief is not a specification written by an engineer. It is a plain description from the person who knows the store best. You do not need technical language. You need clear facts, honest numbers and a good sense of what must never happen.
The nine things every brief should cover
- Your store. Platform, store address, what you sell, who buys it and where you ship.
- The problem. What is going wrong or taking time today, in plain words.
- The goal. What should be true when it works, ideally with a number.
- The tools involved. The apps and services the automation must connect to.
- The rules. What it must always do, never do and when a person must decide.
- Your voice. How customer-facing messages should sound, with examples you like.
- The numbers. Order volume, average order value and anything else that sizes the build.
- The dates. When you need it live and any events to plan around.
- The people. Who approves, who grants access and who to ask if they are away.
Start with the problem, not the solution
Many briefs begin with a solution: “I want a chatbot” or “set up abandoned cart emails”. That is understandable, but it skips the most useful information, which is why. A builder who understands the problem can suggest a better answer, and you can judge whether the finished work solves it.
| Instead of writing… | Write… | Why it helps |
|---|---|---|
| “I want a chatbot.” | “Customers ask where their order is about forty times a week and we answer each one by hand.” | The builder knows the real job |
| “Send reminder emails.” | “About six in ten shoppers who start checkout never finish and we never follow up.” | The scale of the problem is clear |
| “Fix our payouts.” | “Our bank deposits never match Shopify and our accountant spends hours each month.” | Success can be measured |
| “Better product pages.” | “Eight hundred products use supplier text that is copied on other sites.” | The scope is visible |
Define success in a way you can check
A goal you cannot measure is a wish. Choose one or two outcomes that you can check after launch, and write the number next to today’s figure. If you do not know the number, write how you would find it.
- “Reply to order status questions within one minute, so our inbox has fewer than ten a week.”
- “Recover at least one in twenty abandoned carts without discounting orders below our minimum margin.”
- “Match every payout to its orders, so our monthly close takes an hour, not a day.”
Be careful with promises about revenue. A good builder cannot guarantee sales, and a brief that demands a specific revenue figure invites exaggeration. Ask for the process to be right and measurable, then judge the results over time.
Write the rules, especially the “never” rules
Rules turn a general idea into your automation. They are also where most briefs are thin. Write down what the automation must always do, what it must never do and when it must stop and ask a person.
Always
- Check the order status before answering a delivery question.
- Include the order number in every message about an order.
- Stop a sequence the moment the customer buys.
Never
- Offer a discount that takes an order below the minimum margin.
- Promise delivery dates that carriers do not confirm.
- Message anyone who has opted out.
- Discuss another customer’s order.
Ask a person when
- The customer is angry or mentions a legal threat.
- An order is above a stated value.
- A request does not match any rule.
Describe your voice with examples
Adjectives like “friendly” and “professional” mean different things to different people. Two or three examples tell a builder far more. Paste an email you were proud of, a reply you wish you had sent and a phrase you hate. Then write the words your brand uses and avoids.
Give the numbers that size the build
Volume decides how much resilience an automation needs. A store with fifty orders a month and a store with fifty thousand need different designs even if the goal sounds the same. Give honest, rounded figures.
- Monthly orders and average order value.
- Number of products and variants.
- Number of support tickets a week.
- Sales channels and countries you sell in.
- Peak seasons and how much traffic spikes.
List the tools and the access they need
Automation lives between the tools you already use, so a builder needs to know which ones. Name each tool, say who owns the account and describe what you expect to connect. Never put passwords, keys or secret tokens into a brief, a form or an email. Reputable builders request access through a secure channel and ask for the narrowest role that does the job. Our access and requirements guide explains how this works, and our security practices page describes how we handle it.
Set dates and name the people
Tell the builder the date you want the work live and why it matters. A sale, a launch or a busy season changes the plan. Also name one person who can approve wording and rules, and who to ask if they are away. Many projects slow down not because the build is hard, but because nobody could say yes.
Mistakes that cause delays
- Skipping the “why”. The builder guesses, and guesses wrong.
- Being vague about rules. The first draft behaves in ways you did not expect.
- Leaving out edge cases. Refunds, duplicates, out-of-stock items and international orders are where automations fail.
- Changing the scope halfway. New requests are normal, but they reset the plan, so keep a short list for a second phase.
- No single approver. Feedback arrives from four people in four directions.
- Sharing secrets in the brief. It is unsafe and unnecessary.
Edge cases: where automations break
The common path is easy. The unusual orders are what test an automation. Ask yourself what happens when an order is partly refunded, when a customer changes their address after paying, when an item is out of stock after the order, when an order is split across two suppliers, when a customer pays in another currency or when someone orders ten times in a day. One line on each saves days later.
Check your brief before you send it
- Could a stranger understand the problem from the first paragraph?
- Does it say what success looks like and how you will check it?
- Are the rules written as “always”, “never” and “ask a person”?
- Are there two or three examples of your voice?
- Are the numbers there, even if rounded?
- Does it name the tools, the owner of each and who approves?
- Are there dates, and a reason for them?
- Is every password, key and secret absent?
After you send it
A good builder replies with questions, a clear scope, a price, a delivery window and what they need from you. Expect the first reply to be specific to your store, not a template. Look for a plan with a list of what is included, what is not and what will be tested before launch. Our how it works page shows how a Checkout Loom project moves from brief to launch, and the quote form collects the same information in a few short steps.
A worked brief for an abandoned cart project
Seeing a finished example makes everything above easier. Here is a condensed brief for an imaginary store, written the way we like to receive them.
- Store: a Shopify store selling handmade candles, about six hundred orders a month, average order value seventy dollars, shipping to the United States and Canada.
- Problem: most shoppers who start checkout never finish and we never follow up. We think we lose a few hundred orders a month.
- Goal: recover at least one in twenty abandoned checkouts without selling below a thirty percent margin. We currently recover none.
- Tools: Shopify for the store, Klaviyo for email, a text message app for opted-in shoppers.
- Rules: always link back to the exact cart. Never discount in the first message. Never message anyone who has opted out. Stop when the shopper buys. Ask a person for carts above three hundred dollars.
- Voice: warm and short, like a small shop owner. We love the tone of our welcome email. We never use “hurry”.
- Dates: live before the end of next month, ahead of the holiday season.
- People: the owner approves wording. The part-time assistant grants access.
That is about two hundred words, and it answers nearly every question a builder would otherwise ask. Notice how much is numbers, rules and examples, and how little is technical.
Briefing differently for each type of project
| Project | Extra detail to include | Why it matters |
|---|---|---|
| Support chatbot | Your top fifty questions, policies and what must go to a person | It decides how well the assistant answers on day one |
| Product descriptions | A voice guide, facts that must not change and a pilot batch | It protects accuracy and brand |
| Repricing | Minimum price per product, signals allowed and change limits | It prevents margin-destroying prices |
| Payout reconciliation | Chart of accounts, channels and your accountant’s preferences | Entries must land in the right place |
| Order routing | Supplier list, order formats and stock rules | Every order needs a destination and a fallback |
| Disputes | Your processor, deadlines and evidence sources | Each reason code needs the right evidence |
Reviewing the first draft
When the first version arrives, review it against your brief, not your mood. Read every message the automation can send. Test the edge cases you listed. Then give feedback in one consolidated message: what is right, what needs to change and what is missing. One clear round of feedback is faster than five small ones, and it is how a revision policy is meant to work. Our revision policy explains what counts as a round and how to make the most of each one.
Questions to ask a builder in return
- What exactly is included, and what is not?
- When will it be live, and what happens if it is late?
- Who reviews what the AI writes before customers see it?
- Who owns the flows and rules when we finish?
- What happens to my data and access afterwards?
- What does it cost to change something later?
The short version
Describe the problem, define success, write the rules, show your voice, give your numbers, name the tools and people, set the date and keep secrets out. A brief that does these things shortens the project, sharpens the result and protects you if anything is misunderstood. Use our template, send it with your quote request and you will start faster.