How to write an AI consulting brief.

Most organisations buying AI consulting for the first time write the brief last, after the budget is approved and the shortlist is half-formed. It gets a week, it borrows structure from the last IT tender, and it goes out describing a capability rather than a problem.

What comes back is four proposals that each sound reasonable and none of which can be compared to the others. One quotes a discovery phase, one quotes a pilot, one quotes a platform, and one quotes a team by the month. The evaluation panel then argues about price, because price is the only field that lines up. That is not a supplier problem. It is what an under-specified brief produces.

A good brief does one job: it makes proposals comparable without telling suppliers how to solve the problem. Six things get you there.

1. State the business problem, not the capability.

"We want to explore generative AI" is a budget line, not a brief. It tells a supplier nothing they can price, so they price the safest thing, which is a discovery phase that ends in another document.

Write the problem the way the person who owns it would describe it to a colleague. "Our claims team reads 400 PDFs a week to extract six fields, and the backlog is nine days." "Our sales team cannot answer which customers are at risk of leaving, because the three systems that would tell them disagree." Those briefs get proposals you can hold side by side, because every supplier is pricing the same outcome.

If you genuinely do not know which problem to solve first, that is a different engagement. Say so, and run an AI readiness assessment or a use-case prioritisation as its own piece of work rather than burying it inside a delivery brief.

2. Name the decision or workflow that changes.

Every AI engagement that lands has a moment where somebody does something differently. A claim is routed without being read. A forecast is published without being rebuilt by hand. A customer gets an answer in ten seconds instead of two days.

Name that moment in the brief, and name the person whose job it belongs to. It does two things. It stops suppliers proposing work that produces insight nobody acts on, and it gives you a sponsor whose number moves, which is the single strongest predictor of whether the thing survives the year after it is built.

3. Describe the data you hold, including what is wrong with it.

This is the section briefs most often sanitise, and it is the one that most changes the price. Suppliers who cannot see the data price the risk, and pricing risk blind is expensive. Suppliers who are told "our data is in good shape" and then find it is not will raise a variation in week three.

Say what systems hold the data, roughly how much there is, how far back it goes, whether anyone owns its definitions, and what you already know is broken. "Customer records live in Dynamics and a legacy Access database that three people maintain. We know about 12% of records are duplicated. Nobody owns the definition of active customer." A supplier who reads that and still quotes eight weeks has told you something useful about themselves.

Contested definitions are the most common thing an assessment finds and the most commonly omitted from a brief. We have written about why that happens in why AI needs a governed data platform.

4. List the constraints that are genuinely non-negotiable.

Constraints are not a wish list. They are the things that, if breached, kill the project regardless of how well it works. In Australian organisations they are usually some subset of:

• Data residency. Whether data, including data sent to a model provider, may leave Australia, and whether that answer differs by data class.
• Regulatory obligation. APRA CPS 230 and CPS 234 if you are a regulated entity, the Privacy Act and the Australian Privacy Principles for personal information, sector rules on top of both. If you are in financial services, our CPS 230 guide sets out what the operational-risk side asks for.
• Existing platform commitments. If you have three years left on an Azure agreement, say so. It is not a technology preference, it is a cost constraint, and it belongs in the brief.
• Internal capacity. How many days a week your own people can actually give. Overstating this is the most common cause of a slipped timeline, and suppliers plan around it if you are honest.

Four to six real constraints is normal. Twenty means you have written a preferences list, and suppliers will start quietly ignoring the ones that look soft.

5. Give a budget band.

The argument against publishing a budget is that suppliers will quote to it. They will. The argument for is stronger: without a band, every proposal is scoped to a different size, and you cannot compare a $90,000 pilot to a $600,000 programme on anything except the number.

A band also filters honestly. A supplier who reads "$150,000 to $250,000, twelve to sixteen weeks" and tells you the problem cannot be solved for that has given you a genuinely useful answer, and you should treat it as information rather than as a failed bid. We have set out what the bands typically buy in what AI consulting costs in Australia.

6. Publish how you will choose.

State the criteria and their weights in the brief. Not because procurement requires it, but because it disciplines your own panel and it tells suppliers where to spend their effort.

A workable default for a first AI engagement:

• Understanding of the problem (30%). Did they restate it more precisely than you wrote it? That is the strongest single signal in any proposal.
• Approach and sequencing (25%). What they would do first, and why that before anything else.
• The named team (20%). Who actually does the work, with their time split. Not the partner who presents.
• Evidence from comparable work (15%). Similar problem, similar data condition, similar organisation size. Logos are not evidence.
• Price (10%). Low, deliberately. Within a published band, price differences mostly reflect team seniority, and the cheapest team is rarely the cheapest outcome.

Three things to leave out.

The technology. Naming a model, a vendor or an architecture in the brief converts a design question into a compliance exercise. You have removed the main thing you are buying, which is judgement about approach, and you will not find out that the supplier disagreed until the project is underway.

A solution you have already designed. If the brief describes the system rather than the problem, you will get four quotes to build your design and no challenge to it. Put your hypothesis in an appendix marked as a hypothesis, and ask suppliers to agree or disagree with it. The disagreements are worth more than the agreements.

A fixed-price demand for undefined work. Fixed price on a scope nobody can see yet does not transfer risk, it prices it and adds a margin. Fix the price of a defined first phase and put a band on what follows.

What a good response looks like.

When the proposals come back, the ones worth shortlisting share three traits. They restate your problem in sharper terms than you did. They say what they would not do, and why. And they name the assumptions that, if wrong, change the price, which is the closest thing to honesty a proposal can contain.

The ones to be careful with are fluent, comprehensive, and uncommitted. They cover every phase, cite every framework, and contain no sentence that could be wrong. A proposal that cannot be wrong cannot be checked.

For how the resulting work is usually structured once it is awarded, see what an AI consulting engagement actually looks like.

General information only, not legal or regulatory advice. Current as at September 2026.