How to brief an AI or automation project (with a free template)

The template

Copy these questions into a document and answer each in a few sentences. Rough answers are fine.

• What should be different once this is done?
• How is the work done today, step by step, and by whom?
• What goes wrong, how often, and what does it cost you in hours or money?
• Which tools are involved: CRM, inbox, spreadsheets, accounting, databases?
• Where does the data live, roughly how much is there, and how tidy is it?
• Who will use the result, and how do they feel about new tools?
• How many emails, orders, documents or requests come through a day or a month?
• Are there security, privacy or industry rules, or tools you have to keep?
• How will you know it worked?
• When do you need it, and what budget range are you working with?
• Who signs off?

Describe the problem, not the solution

“We want an AI agent” is a solution. “Our finance team spends two days a month typing invoices into the accounting system, and last quarter we paid the same supplier twice” is a problem. The second sentence tells us what to build, and it leaves room for us to say when something simpler would do the job. We’d rather recommend a ten-step automation than sell you an agent you don’t need.

Show us the messy bits

Walk through the work as it really happens, not as it’s written in the process document. A screenshot of the spreadsheet or a forwarded example email tells us more than three paragraphs of description.

Mention the exceptions too: the supplier who only sends scanned PDFs, the client who needs everything in a different format, the step that only Priya knows how to do. Those exceptions are exactly where automations break, and we’d rather hear about them before we quote.

Be honest about your data

List the tools involved and say how clean the data is. If there are duplicate customers, half-filled fields and three spreadsheets that disagree, say so. Nobody’s data is perfect, and a short review will tell us how much tidying is needed. It’s often the biggest single factor in how long a project takes, so it’s better on the table early.

Mention the constraints early

If customer data has to stay in a particular region, if your industry has rules about who can see what, or if IT only approves certain tools, put it in the brief. These things don’t make a project impossible, but finding out about them halfway through is how timelines slip.

Pick one number to judge it by

Choose one or two things you can measure before and after: hours per week spent on the task, time to reply to a new lead, errors per month, invoices handled without retyping. Without a number, you can’t tell if the project worked, and it’s hard to decide what to improve next.

Share a budget range

Some people worry that naming a budget means they’ll be charged exactly that. In practice it does the opposite: it lets a team tell you what’s realistic and suggest a smaller first version that fits. Most of the projects we’re proudest of started small, with one workflow or one feature, and grew once it had proved itself.

What to do with it

A decent brief gets you a faster and more accurate estimate, and it also tells you something about the team you’re talking to. Good teams come back with sharp questions; weak ones just send a price.

When yours is ready, send it through our contact page or bring it to a free 30-minute call. An engineer will read it before the call, not a salesperson.