How to Write an AI Project Brief That Gets You an Accurate Quote

Send three AI vendors a one-line brief — “we want a chatbot for our website” — and you will get three quotes that differ by a factor of five. None of them is wrong. Each vendor has filled the gaps in your brief with its own guesses, and priced in the risk of guessing badly.

A good brief closes those gaps. It takes an hour or two to write, it gets you quotes you can actually compare, and it tells you a lot about each vendor from the questions they ask back. This guide covers what to include, with a template at the end you can copy.

Start with the problem, not the technology

“We want a chatbot” describes a solution. Vendors can quote it, but not well, because they do not know what it has to achieve. Describe the work instead: what task takes too long, who does it today, how often, and what it costs when it goes wrong.

Compare two openings. The first: “We need an AI assistant for customer support.” The second, a made-up but typical example: “Our four-person support team answers around 400 emails a week; about half are questions about delivery times and returns that are already answered in our help pages. We want customers to get those answers instantly, and the team to see only the rest.” The second one can be scoped, estimated and measured.

Describe your data honestly

Most AI projects succeed or fail on data, so this is where vague briefs cost the most. Say where the data lives (a CRM, shared drives, a database, paper), what format it is in, roughly how much there is, and how clean it is. If the task needs labelled examples — past decisions, tagged images, categorised tickets — say whether they exist.

“We have lots of data” tells a vendor nothing. “About 3,000 PDF contracts, mostly digital, around 10% scanned, stored in SharePoint” tells them what the document-processing work will look like. Mention personal or sensitive data, and any rules about where it may be stored, at this stage rather than after the quote.

Define what success looks like

Write down how you will judge the result before anyone builds it. A useful success criterion names a measure and a level: “answers at least 80% of returns questions correctly, with a link to the source”, or “flags at least 9 out of 10 damaged parcels in the photos, with no more than 1 in 20 false alarms”.

You do not need the exact numbers right. The point is to agree what will be measured and on what examples, so that at the end nobody is arguing about whether the system “seems good”. If you cannot yet say what success is, say so — a good vendor will propose a short discovery phase to find out.

List the constraints

Constraints change the design and the price more than most features do. The ones worth listing: where the system and data must be hosted (for example in the EU), which systems it must connect to, which languages it must handle, who the users are and on what devices, any deadline, and any regulation that applies to your sector.

Also say what should stay as it is. If your team must keep approving every refund, or if the assistant must never answer medical questions, that is a requirement, not a detail.

Share a budget range

Many buyers keep the budget secret, hoping for a lower quote. In practice it produces quotes for different projects: one vendor proposes a pilot, another a full platform. Sharing a range lets vendors propose the best scope for that money and tell you honestly if it is not enough.

If you have no idea what things cost, get a rough range first — from an online estimator or a short call — and put that range in the brief.

A brief template you can copy

1. The problem: what task, who does it today, how often, and what it costs in time or errors.

2. The users: who will use the result, how many, and in which languages and on which devices.

3. The data: where it lives, format, volume, quality, whether labelled examples exist, and whether it contains personal data.

4. Success: how you will measure the result, on which examples, and what level would make it worth continuing.

5. Constraints: hosting and data location, integrations, regulation, deadline, and anything that must not change.

6. Budget and timing: a range, and when you would like a first working version.

7. Contact: who makes the decision and who can answer technical questions.

What a good vendor does with your brief

Expect questions. A vendor who quotes a fixed price for a machine learning project without seeing any of your data is either padding heavily or planning to discover the problems on your budget. Good answers usually come as a range with written assumptions, often with a short paid discovery or proof of concept first.

Be wary of guarantees such as “99% accuracy” before anyone has tested on your data, and of vendors who cannot explain how they will measure the result you described. The brief is your first filter: the way a team responds to it is a preview of how they will run the project.