How to Brief an AI Automation Build Without Being Sold a Chatbot

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:

1. ✓The job, written as instructions to a new starter
2. ✓Volume and timing tolerance
3. ✓The three things it must never decide alone
4. ✓Systems involved, and who can grant access
5. ✓What "working" means, as a testable sentence
6. ✓Who owns the exceptions

Everyone who attends the half-day workshop leaves with this filled in for their own best candidate, which is usually more valuable than the automation we build in the room. If you already have a brief and want it built, a paid pilot is the next step.