The gap between "we want to automate this" and a working system is a written brief, and most teams
never produce one. They describe the problem in a meeting, a supplier interprets it generously, and
three months later everyone is disappointed in a way that is nobody's fault in particular.
A good brief is about one page. Here is what has to be in it, and why each part earns its space.
1. The job, described as a job
Not "use AI to improve customer service". Write the actual thing, the way you would explain it to a
new starter on their first morning.
When an order-status email arrives, find the order in Shopify, check whether it has shipped, and
reply with the tracking link. If the order is older than thirty days or the customer is asking
about a refund, do not reply, flag it for Ana.
That paragraph is worth more than a page of objectives. It contains the trigger, the systems, the
action, and the boundary. A supplier can price it.
2. Volume and timing
How many times a day, and does it matter how fast. Nine hundred a month with a four-hour tolerance is
a different system, at a different price, from thirty a day that must go out within two minutes.
Teams routinely omit this and then feel surprised at the quote.
3. The three things it must never decide alone
This is the part that separates a brief from a wish. Write down, explicitly, what the automation is
forbidden to do on its own. Issue a refund. Promise a delivery date. Contact a customer who has
complained. Change a price.
Anything that touches money, makes a promise to a customer, or is legally binding belongs on this
list. A supplier who does not ask for it is not going to build boundaries into what they deliver.
4. Where the data actually lives, and who can grant access
Name the systems and name the person who can give a key. This one line prevents the most common
delay in the whole process, which is not technical: it is a project sitting still for two weeks
because nobody knows who owns the API credentials.
If the data is in PDFs, say whether they are real documents or scans, because the second is a
materially different problem.
5. What "working" means, in a sentence you could test
Not "it works well". Something checkable:
Out of a hundred real emails from last month, it should handle at least eighty without a person,
and everything it does not handle should be in Ana's queue with the reason.
Now you have an acceptance test, and both sides know what finishing looks like. Without it, you get
an argument about whether the thing is done.
6. Who owns the exceptions
Name a person. Every automation produces cases it will not touch, and if nobody owns that queue the
work has been relocated rather than removed. This is the single most common way a technically
successful automation fails commercially.
What a good supplier does with this
They come back with a fixed price, or they come back with questions that make your brief better. What
they should not come back with is a discovery call to "understand your needs", because you have just
written them down.
They should also, occasionally, tell you not to build it. A brief that scores badly on volume or
lands squarely in judgement territory is one a decent supplier will decline or reduce in scope. If a
supplier has never once told you a job was not worth automating, you are talking to a salesperson.
The template
Six headings, one page:
- The job, written as instructions to a new starter
- Volume and timing tolerance
- The three things it must never decide alone
- Systems involved, and who can grant access
- What "working" means, as a testable sentence
- Who owns the exceptions
Everyone who takes the asynchronous course finishes with this filled in for their own
best candidate, which is usually more valuable than the automation built on their file. If you
already have a brief and want it built, a paid pilot is the next step.
Originally published on devaland.com: How to Brief an AI Automation Build Without Being Sold a Chatbot
Top comments (2)
The Shopify order-status example is perfect because the exclusion rule (older than thirty days or refund talk goes to Ana) is where most briefs fall apart. People describe the happy path and forget to write down when the system should stay quiet. I'd almost argue the "do not reply" conditions deserve their own section, since that's the part suppliers are least likely to ask about and the part that causes the angry customer emails.
Agreed, and I would go further: the "stay quiet" rules are where the brief earns its money. A supplier will always build the happy path; nobody asks "when must it not answer?" unless the brief makes them. A short section of its own, in plain sentences ("an order older than thirty days: pass it to Ana, say nothing"), is also the easiest part to test before launch, because each rule is one message you can send and watch it stay silent.