A vague brief is not a starting point; it is a liability. We have read enough proposals from AI agencies to know that open-ended language in a brief becomes open-ended billing in a contract, and by the time the client notices, the scope is already gone. What you put in writing before you engage anyone is the project. Everything after that is execution.
Why Most AI Briefs Are Too Thin
The typical client brief for an AI project runs something like: “We want to automate our customer support” or “We need an AI tool to help our team work faster.” That is a budget, not a brief. It tells the agency your problem exists, not what solving it actually looks like.
Three things are almost always missing:
- A defined output with a format and a destination
- The data sources the AI will actually touch
- A measurable threshold for “it’s working”
Without these, the agency scopes to their comfort level, not yours. That is how a project quoted at £18,000 becomes a £40,000 engagement with no clear finish line.
The Vendor Incentive Problem
Here is the uncomfortable reality: AI agencies are not incentivized to ask for a tighter brief. A vague scope protects them when outputs are disappointing, timelines slip, or the underlying data turns out to be messier than anticipated. “The data wasn’t ready” and “we’ll define metrics in Phase 2” are not technical problems, they are scope problems that a tight brief makes much harder to hide.
Only 11% of businesses that experiment with AI successfully implement it at scale. The failure usually happens before a line of code is written.
What a Proper AI Brief Contains
A brief that holds scope is not a 40-page requirements document. It is a one-to-two page document that answers five questions clearly.
1. What Is the Single Problem You Are Solving?
Write one sentence. Not a paragraph, one sentence. “Customers submit enquiries via our contact form; it currently takes our team 4 hours to triage and respond; we want that reduced to under 30 minutes without adding headcount.”
That sentence names the current state, the pain, and the target outcome. It is specific enough to scope against. “Improve our customer experience” is not.
2. What Data Will the AI Actually Use?
List every source. If the AI will read emails, name the inbox and confirm access is possible. If it will query a CRM, name the CRM, confirm the API exists, and confirm the data is clean enough to use. Data quality problems cause 43% of AI project failures, and every one of them was discoverable before the project started.
Be explicit about what data is off-limits too. Out-of-scope data definitions are as important as in-scope ones. They prevent a vendor from widening the integration later and billing it as a change order.
3. What Does the Output Look Like, Exactly?
Describe the output in concrete terms: format, destination, and frequency. “A daily Slack message summarising overnight enquiries, in plain English, with a priority tag (High / Medium / Low) and the original enquiry attached.” That is a scopeable output. “A useful summary” is not.
If you cannot describe the output yet, that is a signal to run a small discovery session before writing the brief, not to hand a vague description to an agency and hope they interpret it correctly.
4. Who Approves the Output Before It Acts?
Every AI integration has a moment where the system either does something autonomously or hands off to a human. Define that moment explicitly. “The AI drafts the response; a team member approves before it sends” is a different project, and a different risk profile, to “the AI sends automatically if confidence is above 90%.”
Human-in-the-loop decisions are not optional edge cases. They are core architecture decisions. If your brief does not name them, the agency will decide for you.
5. What Does Success Look Like in Numbers?
Not “it saves time”, how much time, measured how, checked when? A brief with measurable success criteria creates an acceptance threshold. A brief without one gives the vendor a subjective finish line they can declare whenever it suits them.
Examples of useful success criteria:
- Response triage time drops from 4 hours to under 30 minutes, measured over 4 weeks post-launch
- AI draft accuracy (no hallucinated facts, correct tone) verified on 100 test cases before go-live
- Error / fallback rate below 5% in the first month
What to Include in Writing Before You Sign
The brief is where the project is designed. The contract is where it is enforced. These are two different documents, and both need the same specificity.
Before you sign any statement of work, the following should be in writing:
Defined deliverables, not activities. “Design and develop an AI triage workflow” is an activity. “An AI triage workflow that processes inbound enquiries, assigns a priority tag, and delivers a draft response to the assigned team member within 5 minutes” is a deliverable. Only deliverables can be accepted or rejected.
Acceptance criteria. The exact conditions under which you sign off. Not “when we’re happy with it”, when accuracy exceeds X%, latency is below Y seconds, and the fallback behaves as specified. Projects with quantified success metrics defined upfront achieve a 54% success rate; those without achieve 12%.
An explicit out-of-scope list. Name what the project does not include. Integrations not in scope. Data sources not in scope. Languages, user types, channels not in scope. Each item on this list is a potential change order you just eliminated.
A change order threshold. What counts as scope change, and what is covered in the base fee? “Any new data source triggers a change order review” is better than leaving it undefined.
An exit clause. If a milestone is missed by more than X weeks, or if acceptance criteria are not met after two remediation attempts, the client can exit without penalty. No reputable agency refuses this. If they do, that is your answer.
A Concrete Example: What Good and Bad Briefs Look Like
Bad brief: “We want an AI assistant to help our sales team.”
What does the agency scope? Whatever they want. You will get a proposal that includes a discovery phase, a pilot phase, an integration phase, and a retainer. Budget: unknown until Phase 2.
Good brief: “Our sales team of six receives 60–80 new leads per week via HubSpot. Qualification currently takes 45 minutes per lead. We want an AI tool that pulls from the HubSpot record, our product catalogue, and past deal data to produce a one-page qualification brief per lead in under 3 minutes. The output goes to the assigned rep’s HubSpot task. Success: qualification time drops to under 5 minutes per lead, measured over a 30-day trial.”
That brief can be scoped. It names inputs (HubSpot, product catalogue, deal data), output (one-page brief in HubSpot tasks), volume (60–80/week), success criteria (5-minute qualification), and evaluation period (30 days). A vendor reading that brief cannot blur scope. There is nowhere for it to go.
If you are building this kind of AI capability into your website or operations platform, note that the same scoping discipline applies to custom WordPress development, the brief defines what gets built, and anything not in the brief is a future conversation.
Red Flags That Mean Your Brief Is Still Too Vague
After you write your brief, check it against these signals:
- You describe what you hope the AI will do, but not what it will produce
- The success criteria include the words “better,” “faster,” or “more efficient” without numbers
- The data sources are described as “our CRM” or “our systems” without naming them
- You have not listed a single thing that is explicitly out of scope
- You cannot describe the human handoff point
If any of these apply, the brief needs another pass before it goes to an agency. Tightening the brief up front tends to surface scope disagreements before they become contract disputes, which is considerably cheaper.
FAQ
What is the difference between an AI brief and an AI scope document?
The brief is what you write before you engage an agency, it defines the problem, the output, the data, the success criteria, and the constraints. The scope document is what the agency produces in response, as part of their proposal. The brief informs the scope. If your brief is vague, the scope document will be vague too. The brief is your document; the scope document is theirs.
How long should an AI project brief be?
One to two pages for most SMB projects. You are not writing a technical specification, you are giving an agency enough information to scope accurately and commit to a deliverable. More important than length is specificity: one sentence defining the output is worth more than two paragraphs of background.
Should I pay for a discovery phase before writing a brief?
A short discovery workshop (half a day, fixed fee) can be useful if you genuinely cannot describe your outputs or data sources. A £20,000–£50,000 discovery phase that produces only a requirements document is a different thing entirely. If a paid discovery phase ends without working code or a testable proof of concept, treat that as a red flag. A focused scoping session with a direct brief can establish whether a project is viable in a matter of hours, if the agency needs weeks of paid discovery before they can give you an honest answer, that is itself an answer.
What should I do if the agency’s scope document doesn’t match my brief?
Do not sign. Go back through the scope document line by line against your brief and identify every divergence. Specifically check: are the deliverables named in concrete terms, or are they activities? Are the success criteria the same numbers you wrote in the brief? Is the out-of-scope list included? If the agency cannot align the scope document to your brief before signing, the project will not align after.
How do I know if an AI agency is deliberately keeping scope vague?
Three signals: they quote a price before naming a specific deliverable; they recommend a tool or platform before reviewing your workflow; their proposal contains no exit clause or milestone-based payment structure. Any one of these warrants a direct conversation. All three means the scope will not hold.
Can I use this briefing approach for AI integrations with existing platforms like WooCommerce?
Yes, and it applies directly. A WooCommerce development project with an AI layer (product recommendations, automated descriptions, dynamic pricing) still needs the same inputs: what data the AI reads, what it outputs, where the output goes, and what success looks like. Platform integrations do not reduce the need for a tight brief, they add integration complexity that makes vague scope even more expensive.
If you want to talk through what this looks like for your operation before you send anything to an agency, start a conversation. We scope custom AI builds before any commitment, we will tell you what it takes, what the output looks like, and what success means in your specific context. See how we scope and build this at designodin.com/ai.