How to Write an AI Project Brief: What to Send an Agency or Developer Before Your First Call

A good AI project brief is a two-to-four page document that describes the process you want to automate, how often it happens, the tools and data involved, when a human should take over, how you will measure success, and your constraints. Send it before the first call so agencies can quote on facts instead of guesses.

Key takeaways: Describe the problem and the current process, not the technology you think you need. Seven short sections are enough, and they make proposals easier to compare.

Why write a brief before talking to an agency?

Writing a brief forces you to find out what you actually need, and it gives every provider the same starting information. Without one, the first call usually becomes a discovery session where you improvise answers about volumes, tools and edge cases. The proposals that come back then reflect each agency's assumptions, which makes them very hard to compare. One may quote a simple FAQ bot, another a full agent connected to your CRM, and you will not know whether the difference is quality or a different reading of your problem.

A brief also protects you from scope drift. If the written document says the assistant answers order-status questions and hands off refunds to a person, nobody can later claim the refund flow was included. It does not need to be technical. You are the expert on your business, and the agency is the expert on building; the brief is the bridge. If you are still unsure which process to start with, read What to Automate First in Your Small Business before you write anything.

What should an AI project brief include?

A useful brief has seven sections, and each one answers a question a competent agency will ask anyway. You can write all of them in one sitting, ideally with the person who does the work today sitting next to you. Short, honest answers beat polished ones. Where you do not know something, write "unknown" instead of guessing, because an agency can plan around a known gap but not around a wrong number.

1. The process and the problem. What happens today, step by step, who does it, and what hurts (slow replies, errors, hours lost).
2. Volume and timing. How many requests, messages or documents per week, and when the peaks happen.
3. Tools in use. CRM, helpdesk, store platform, calendar, messaging channels, spreadsheets, and who has admin access.
4. Data sources. Where the answers live: FAQs, policies, price lists, past conversations, product catalog. Note whether they are current and who owns them.
5. Handoff rules. What the automation must never handle alone, and who receives the case when it passes to a person.
6. Success measure. The one or two numbers that would tell you it is working.
7. Constraints. Budget range, deadline, languages, privacy requirements, brand tone and anything off limits.

How do I describe the current process?

Describe it as a sequence of real steps, using a recent example rather than a general summary. For instance: a customer writes on WhatsApp asking where their order is, someone opens Shopify, finds the order by email, copies the tracking link and replies, usually within a few hours. Add the exceptions you see often, such as customers with no order number or orders stuck at the carrier. These exceptions are where most projects get expensive, so naming them early is the most valuable thing you can do. Include two or three anonymised real messages or documents if you can.

How do I state volume without exact numbers?

Give a rough range and say how you got it. "About 30 to 50 messages a day, more on Mondays, counted from last month's inbox" is far more useful than "a lot". Volume affects the design, the running costs of the model and the decision between a simple tool and a custom build. If you cannot count, ask the person who handles the inbox to tally one typical week. Do the same for the time each case takes, since that figure is the base for any later return calculation.

How do I define handoff rules and success measures?

Handoff rules say which cases the AI must pass to a person, and success measures say how you will judge the result after launch. Both are the sections owners most often skip, and both decide whether the project feels like a win. For handoff, list the triggers: angry customers, refunds above a certain amount, legal or medical questions, anything involving payment disputes. Also say who receives the case and through which channel, because a handoff that lands in an unmonitored inbox is worse than no automation. The article on automating customer support and when to hand off to a human goes deeper on this, and autonomous vs. semi-autonomous agents helps you decide how much freedom the system should have.

For success, choose measures you can actually observe: share of questions resolved without a person, average first-reply time, hours saved per week, leads that get a follow-up within an hour. Avoid vague goals such as "improve customer experience". Write down today's baseline so you can compare after launch. If you want a framework for turning those numbers into a business case, see The ROI of AI Agent Automation. Be realistic about the first weeks too: expect to review conversations and adjust, since no assistant is right on day one.

What constraints should I put in the brief?

Constraints are anything that limits the solution, and stating them up front saves everyone a wasted proposal. The common ones are budget range, target launch date, languages, channels (web chat, WhatsApp, Instagram), tone of voice, and rules about customer data. If you handle personal data of people in the EU, say so and mention any privacy commitments you have already made; the agency should explain how data is stored and which model providers see it. For background on risks, see Security and Ethics in Autonomous Agent Deployment.

On budget, a range is better than silence, even if it feels uncomfortable. Without one, agencies either guess high to be safe or quote something you cannot afford. Also state what you have already tried, such as an off-the-shelf chatbot or a no-code automation, and why it fell short. That context helps the provider tell you honestly whether you need a custom build at all; Custom AI Agent vs. No-Code Tools vs. Off-the-Shelf SaaS covers that choice.

What does a short brief look like in practice?

A brief can fit on a single page if each section is a few lines. The table below shows how vague input compares with input an agency can price, using a made-up small online shop as the example.

Notice that none of this requires technical language. If your use case is a specific one, such as order-status questions in Shopify or appointment booking, the matching article will help you list the right edge cases before you write.

How do I use the brief to compare proposals?

Use your seven sections as a checklist and score each proposal against them. A good proposal restates your process in its own words, names the tools it will connect to, explains how handoff works, says what it will measure, and lists what is out of scope. If a proposal ignores a section, ask why before comparing prices. Be wary of any quote that promises specific results without having seen your data; results depend on your volume, content quality and process.

It also helps to send the same brief to two or three providers and note which questions each one asks back. Sharp questions about your exceptions are a good sign. For the other side of the conversation, How to Choose an AI Agent and Automation Agency lists what to ask them. At Kuan AI the work starts with a diagnosis, then design, implementation, and measuring and scaling what works, so a brief like this maps directly onto the first step. You can send yours through the contact form on kuan-ai.com, and they reply within 24 hours; even a rough draft is enough to start.

Once your brief is written, read it once as if you were a stranger who has never seen your business. Anything that makes you ask a question is a gap to fill before you send it, and fixing it now costs a few minutes instead of a week of back-and-forth later.