“Help us with AI” is a perfectly reasonable opening conversation. It is a terrible statement of work.
Give three suppliers that brief and you may receive a workshop, a chatbot and a six-month transformation programme. Comparing the prices will tell you almost nothing, because they have priced different problems.
The short answer: an AI consultancy brief should name the business problem, workflow owner, scope, data constraints, deliverables, acceptance criteria, commercial assumptions and handover. Write enough to make proposals comparable, without prescribing a solution before discovery.
Start with the problem you can describe
Explain what happens today and why it matters. Include who performs the work, its frequency, known delays and the consequences of errors. State which figures are measured and which are estimates.
A useful problem statement might say: our team prepares a recurring proposal type using approved product material, but assembling and checking the first draft consumes substantial time. We want to test whether assisted drafting reduces total effort while preserving claim accuracy and client confidentiality.
That is an illustrative example, not a reported client result. Notice that it does not require a particular model or a swarm of agents. It leaves room for a supplier to suggest a simpler solution.
Copy this brief structure
| Brief section | What to write | What it prevents |
|---|---|---|
| Problem and owner | Current workflow and accountable person | A solution without a business sponsor |
| Scope | Included tasks and explicit exclusions | Uncontrolled expansion |
| Data and systems | Sources, owners, access and restrictions | Discovering integration barriers too late |
| Deliverables | Working outputs and retained documentation | Paying solely for advice you cannot apply |
| Acceptance | Tests, measures and acceptance authority | A demonstration replacing evidence |
| Commercials | Budget range or cap, currency and assumptions | Incomparable quotes |
| Handover | Accounts, training, support and exit | Permanent supplier dependency |
Fill in the proposal-drafting example
In scope: one proposal format, one approved reference library, draft generation and human review. Out of scope: automatic sending, price-setting, legal commitments and retrieval from unrelated client folders.
Deliverables: a configured drafting workflow, a documented source library, representative test results, reviewer instructions and a runbook. Specify what your organisation owns and what remains a third-party service.
Acceptance: agreed reviewers assess claim accuracy and completeness; access tests show restricted material cannot be retrieved; total preparation and checking time is compared with the baseline. Set numerical thresholds with the process owner after measuring the current work, not by copying a convenient percentage from a template.
Stop condition: a material access failure blocks release until resolved and retested. Missing quality or time-saving targets triggers a decision to revise, narrow or stop the pilot.
Ask suppliers to expose assumptions
Request an explicit list of client responsibilities. Who cleans documents, provides test examples, obtains access, attends reviews and owns the final service? Supplier estimates often depend on those tasks being completed promptly.
Ask each proposal to distinguish fixed deliverables from discovery-dependent work. A sensible response may say that integration cost cannot be confirmed until access is inspected. That is more credible than false precision.
Include variable costs such as model usage, hosting and licences. For UK and UAE comparisons, request a declared currency and explain how travel, remote delivery, taxes and exchange assumptions are handled in the quote. Resolve tax treatment with the relevant adviser rather than guessing in the template.
Do not turn the brief into an architectural trap
Prescribe business constraints and evidence. Be cautious about prescribing a stack unless there is a genuine organisational requirement. “Must use our approved identity system” is a constraint. “Must use five autonomous agents” is often a preference looking for a problem.
Ask the supplier to explain simpler alternatives and what would make the proposed approach unsuitable. The AI versus automation guide provides a way to make that conversation concrete.
Use the brief after procurement
The brief should remain the reference during delivery. Record scope changes, their effect on cost and acceptance, and the person approving them. Do not allow a helpful conversation to become an unrecorded contractual assumption.
A good brief makes it easier to say what is finished. If the team cannot tell whether a milestone meets the brief, improve the brief before arguing about the milestone.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
