How to brief an AI development company
What should you know about how to brief an AI vendor so the proposal you get back is useful?
A good brief states the decision the AI changes, the data available, the systems involved, constraints, budget range and success metric. Six sections, two pages, and every vendor who reads it can price the same thing, which is the only way to compare proposals and the fastest route to a fixed quote.
Knowing how to brief an AI vendor is the difference between receiving three comparable fixed-price proposals and receiving three documents that each describe a different project. The brief does not need to be long or technical. It needs to answer six questions: what decision the AI will change, what data exists, which systems are involved, what constraints apply, what the budget range is, and how success will be measured. Two pages is enough. A vendor who receives less will spend the first two weeks of the engagement finding it out at your expense.
This article is a practical AI project brief template, with what to put in each section and how to handle the RFP for AI development if procurement requires one.
Why AI project requirements need a different brief
A conventional software brief describes features. An AI brief has to describe a decision, because the system's job is to make or support one, and its value is entirely determined by how much that decision matters. A brief that lists features ("a chatbot", "document summarisation", "an assistant") invites vendors to price a feature and leaves the question of whether it will work on your data unasked. A brief that describes a decision, the data behind it and the metric that would prove it improved lets a vendor say honestly whether the thing can be built and what it would take to find out.
It also has to be honest about the data, because that is where most AI projects succeed or fail.
The six sections of the brief
| Section | What to write | What vendors do with it |
|---|---|---|
| 1. The decision | Which decision the AI changes, who makes it today, how often, how long it takes, what a wrong one costs | Estimate value, choose the design pattern, judge whether AI is the right tool |
| 2. The data | What inputs exist, in what format, how many, how clean, whether labelled outputs exist, where it lives | Decide whether a benchmark is possible, and price the data preparation |
| 3. The systems | Systems the AI must read from or write to, whether they have APIs, who administers them | Price integration, which is usually the largest part of the build |
| 4. Constraints | Data residency, regulation, languages, latency, channels, existing vendor commitments | Rule models and architectures in or out before proposing |
| 5. Budget and timeline | A range, not a number, and the date something has to be true by | Propose a staged plan that fits, rather than guess |
| 6. Success metric | One measurable outcome with a baseline, and the review date | Set the acceptance threshold and design the evaluation |
Section one: the decision
Write it as a sentence a colleague outside the project would understand. "Loan applications with complete documents are approved for the next stage without a second reviewer." "Customers asking where their order is get an answer with the live status without waiting for an agent." Then answer: who makes this decision now, how many times a day, how long it takes, how often it is wrong and what a wrong decision costs. Those five answers give the vendor the value ceiling and tell them how much automation is safe. If you cannot write the sentence, the project is not ready to brief, and a discovery sprint is the right next step.
Section two: the data
Be specific and be honest. Formats (PDF, scanned image, phone photograph, free text, structured records), rough volumes, where the data lives and who controls access, whether the correct output exists anywhere (a human's decision in a system of record, a past resolution, a completed form), and known quality problems. "We have ten thousand invoices as PDFs, about a third of them scans, and the approved amounts are in the finance system" is a paragraph a vendor can benchmark against. "We have lots of data" is not. If the data cannot leave your environment, say so here; it changes the shortlist of models.
Section three: the systems
List every system the AI would need to read from or write to, whether each has an API, whether anyone has used that API before, and who administers it. Integration most often decides the price and the date, and a system without an API that nobody mentioned will be discovered in week three. Include the channel if there is one: web app, WhatsApp, voice, email, an existing helpdesk. Our post on adding an AI agent to Zendesk, Freshdesk or Intercom shows how much the channel shapes the build.
Sections four to six: constraints, budget and the metric
Constraints are the rules the design must respect: data residency, sector regulation, languages, latency expectations, security review requirements, and any vendor commitments already made. They rule options in and out before anyone proposes them.
Budget should be a range, and giving one is not a negotiating weakness. It lets a vendor propose a staged plan that fits: a discovery sprint, a proof of concept, then an MVP, each fixed price, rather than a single number chosen to look competitive. Timeline should name the date by which something must be true (a board meeting, a season, a contract renewal) rather than a wish. Our pricing page shows program prices so you can set a realistic range before you write.
The success metric is one measurable thing, with its current value, and a review date. Resolution rate per intent. Straight-through rate at an agreed accuracy. Hours returned. Refuse metrics the system reports on itself. The vendor turns this into the acceptance threshold both sides are held to.
If procurement requires an RFP
Put the six sections at the front, and ask every vendor the same evidence questions: will you benchmark on our data before quoting a build, how is done defined and can we run the test, what happens to out-of-scope requests, who owns the code, prompts, models and evaluation data at the end, and what is excluded. Score proposals on those answers. The wider vendor questions are in How to choose an AI development company: a 12-point checklist. Avoid RFPs that specify the solution ("must use vector database X"); specify the decision and the metric and let the proposals differ on how.
A worked example
A lending business's first brief for document automation was a single line: "automate KYC using AI." Three vendors returned proposals for three different products at three different prices, none comparable. The rewritten brief took an afternoon. The decision: applications whose six mandatory fields match across four document types proceed without a manual check. The data: scanned and photographed documents in the loan-origination system, tens of thousands, with the manual checker's decisions recorded. The systems: the origination system, with an API, and a document store without one. Constraints: data stays in India, Hindi and English documents, a compliance sign-off on any automated pass. Budget: a range covering discovery through MVP. Metric: straight-through rate at an agreed field accuracy, with the current manual throughput as baseline. The three proposals that came back were comparable, and the one chosen began with a ten-day benchmark. The resulting system is described in the KYC document intelligence case study.
Team and timeline
Writing the brief takes a sponsor and one person who knows the data and the systems half a day to a day. If you cannot complete sections one, two and six, that is useful information: it means the project needs a discovery sprint before it needs a brief. We run that as Sprint Zero, ten working days at a fixed $3,250 or ₹2,00,000, credited to the next build, and it produces the benchmark, the architecture sketch and the cost model that turn a brief into a fixed quote. A completed brief usually leads straight to a proof of concept or to Launch 6, our six-week AI-accelerated MVP program, fixed price at $26,500–45,500 or from ₹17,60,000. Both sit within our AI strategy services; we are happy to review a draft brief via the contact page.
Before you start: a checklist
- Write the decision the AI changes in one sentence a non-specialist would understand
- Describe the data honestly: formats, volumes, quality, location, whether correct outputs exist
- List every system to read from or write to, with or without an API, and its administrator
- State constraints: residency, regulation, languages, latency, channels, prior commitments
- Give a budget range and the date something must be true by
- Choose one success metric, capture its baseline and set the review date
- Ask every vendor the same evidence questions and score on the answers
- Keep the brief to two pages; attach detail rather than burying the six sections in it
Questions clients ask
- Should we tell vendors our budget? Give a range. It produces staged, comparable proposals instead of guesses, and a good vendor will propose less than the range if less is needed.
- What if we do not know whether the data is good enough? Say so. A vendor who benchmarks before quoting will find out in ten days; one who quotes anyway is guessing.
- Do we need to specify the technology? No. Specify the decision, the constraints and the metric. Let proposals differ on models and architecture, and judge them on evidence.
- How many vendors should we brief? Two or three. More than that and the evaluation becomes the project.
Related reading
What a board should ask before approving an AI budget covers the same six questions from the approver's side, and Fixed-price AI development: how it works and when it fits explains what a vendor needs from the brief to offer a fixed price. The NIST AI Risk Management Framework is a useful primary source for the constraints section in regulated settings.
Six sections, two pages, one decision, one metric: brief an AI vendor that way and the proposals you receive will be comparable, honest and priced.
Frequently asked questions
What should an AI project brief include?
▾
The decision the AI changes, the data available and its quality, the systems to integrate, constraints such as residency and languages, a budget range with a real deadline, and one success metric with a baseline. Two pages is enough.
Should an RFP for AI development specify the technology?
▾
No. Specify the decision, constraints and metric, and ask every vendor the same evidence questions: benchmarking on your data, how done is defined, what happens to scope changes, and who owns the code and prompts.
What if we cannot answer the six questions yet?
▾
That means the project needs discovery before a brief. A ten-day discovery sprint benchmarks models on your data, sketches the architecture and prices the build, which turns an incomplete brief into a fixed quote. Details are on our pricing page.