How to write an AI project brief that gets accurate quotes
How do you write an AI project brief that gets accurate quotes?
A brief produces accurate quotes when it answers four questions: what decision or task is being automated, what data exists and in what shape, which systems must be read and written, and how success will be measured. Everything else in a brief is context; these four set the price.
An AI project brief produces accurate quotes when it answers four questions: what task or decision is being automated, what data exists and in what shape, which systems must be read from and written to, and how success will be measured. Everything else is useful context. Those four set the price, and a brief missing any of them will be quoted as a guess.
What follows is the structure we ask for before quoting, section by section, with what each section changes in the number, what to attach to it, and how to keep the whole thing to two or three pages so busy people actually write it.
Why most briefs produce inaccurate quotes
Briefs usually describe a solution rather than a job. "We want an AI chatbot for customer support" names a product category and leaves every cost driver unspecified: how many intents, which systems the bot must touch, whether it answers or acts, what languages, what accuracy is acceptable and who decides. Three vendors reading that sentence will price three different systems, and the cheapest will be the one who imagined the smallest.
The fix is not a longer brief. It is a brief that states the job in the vocabulary of the people who do it today. A single paragraph describing what a support agent actually does between receiving a message and closing the ticket is worth more to an estimator than five pages of requirements, because it reveals the systems, the decisions and the exceptions at once.
There is a live companion piece on the softer side of this, how to brief an AI development company, which covers how to run the conversation. This post is about the document.
The eight sections of a brief that gets accurate quotes
1. The job, described as work
Two to five sentences describing what a person does today, start to finish, including the systems they open and the judgement calls they make. Name the volume: conversations per day, documents per month, tickets per week. Volume is what turns a design into a running cost.
2. The decision you are trying to make
State whether you are deciding if this is possible, deciding which vendor to use, or committing to a build. Vendors quote differently for each, and pretending a feasibility question is a build request produces a number that helps nobody.
3. Data: what exists, where, in what state
The largest single cost driver in most AI projects. Say how many documents or records, in what formats, where they live, whether they are clean, whether they contain personal data, and whether a sample can be shared under NDA. A vendor who has seen twenty representative files can quote data preparation properly; one who has not will either pad the line or omit it.
4. Systems and integrations
List every system the solution must read from or write to, and mark each one read or write. Write access changes the architecture, the permission model and the testing burden. Note which systems have a supported API and which will need a workaround, because the second kind can double an integration line on its own.
5. The accuracy bar and how it is measured
Name the measurable outcome and who judges it. "Ninety per cent of extracted fields match the human-verified value on a sample of two hundred documents" is quotable. "High accuracy" is not. If you cannot state the bar yet, say so explicitly and ask for a discovery step to define it; that is a legitimate answer and costs far less than discovering it during acceptance testing.
6. Constraints: data residency, hosting and compliance
Say whether data may leave your infrastructure, which jurisdictions apply, and whether the DPDP Act, sectoral regulator guidance or contractual client terms constrain where processing happens. A requirement for self-hosted inference rather than a hosted API changes the architecture and the running cost materially.
7. Timeline, budget range and what drives the date
A budget range is not a weakness to hide; it is the input that lets a vendor propose the right scope instead of the maximum one. If a date is fixed by an external event such as an audit, a peak season or a licence expiry, say what the event is, because it changes sequencing.
8. Ownership and what happens after launch
State who will own the code, prompts and infrastructure, and whether you want the vendor to run the system afterwards or hand it to your team. Eazyware transfers code, prompts, model choices, infrastructure and documentation in every engagement, and support afterwards is an optional Care Plan rather than an obligation.
What each section changes in the quote
| Brief section | What it changes in the price | What to attach |
|---|---|---|
| The job, with volume | Model and infrastructure running cost | A short workflow description or screen recording |
| Decision being made | Engagement shape: discovery, proof or build | Nothing |
| Data inventory | Data preparation effort, often the largest line | Twenty representative files or a schema dump |
| Systems and read/write marks | Integration effort and permission design | API documentation links or vendor names |
| Accuracy bar | Evaluation effort and acceptance criteria | Fifty real inputs with known correct outputs |
| Residency and compliance | Hosting choice and self-hosting cost | Your policy extract or auditor requirement |
| Timeline and budget range | Scope proposed, team shape, sequencing | The date and the event driving it |
| Ownership and aftercare | Handover effort and support tier | Your preferred support hours |
The attachments that shorten a quote by a week
- Twenty representative documents or records, including the ugly ones. Clean samples produce optimistic quotes.
- Fifty real inputs with known correct outputs. This becomes the golden question set and it is the fastest way to make accuracy a number rather than an argument.
- A list of systems with API documentation links and the name of who owns each internally.
- One screen recording of the current process being done once, end to end.
- Your data residency and privacy policy extract, if there is one.
- Existing volumes for the last three months, not a projection.
- A signed NDA, ready to go. We sign one before the first working session in any case.
OpenAI's own evaluation guide makes the same point from the engineering side: an eval needs a dataset of representative inputs with expected outputs before anything can be measured. Supplying that dataset with the brief moves the argument about quality to the start of the project, which is where it is cheap.
How long should the brief be?
Two to three pages, plus attachments. Longer briefs do not produce better quotes; they produce quotes based on the first two pages. If a section would run past half a page, it is usually a sign that the scope contains two projects and should be split.
Write it once and send the identical document to every vendor. Comparing quotes is only meaningful when the input was the same, which is the point made in how to compare AI proposals when nobody quotes hourly.
What if you cannot write the brief yet?
This is common and it is not a failure. If the data is unmapped or the accuracy bar is genuinely unknown, buy a small piece of fixed-price discovery and let it produce the brief. A ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build that follows, produces the use-case shortlist, the data assessment and the evaluation plan. A three-week ProofRun at $6,250 or ₹4,00,000 goes further and answers one hard technical question on your real data before you commit. Published figures for every programme are on the pricing page, and you can size an engagement yourself with the estimate tool.
A brief that worked
An NBFC sent us a two-page brief for KYC and loan onboarding document processing. It named the document types, gave monthly volumes, listed the four systems involved with read and write marked against each, stated that no customer data could leave their infrastructure, and attached forty real documents including the badly scanned ones. It also named the accuracy bar and who would judge it.
That brief took an afternoon to write and removed about two weeks from the front of the engagement, because the architecture question, self-hosted rather than hosted inference, was settled before the first call rather than after the first quote. The resulting build is described in the KYC document intelligence case study.
When a brief is the wrong instrument
A written brief is the wrong tool when the work is exploratory research rather than delivery. If nobody knows whether the outcome is achievable on your data, a brief creates an illusion of specification and invites quotes that are really bets. Buy a bounded proof instead.
It is also wrong when you are early enough that a conversation would change the shape entirely. Sending a detailed brief for a solution you have already chosen prevents a vendor from telling you that a simpler approach, or no AI at all, would do the job. We would rather have that conversation before the document exists. If that is where you are, the contact page is the better starting point than a specification.
Finally, a brief cannot substitute for an internal owner. If no one on your side can answer follow-up questions within a day, the most precise brief in the world will still produce a slow, hedged quote.
Related reading
What a fixed-price AI quote should contain is the mirror image of this post, written from the quote side, and scope lock: the discipline that makes fast MVPs possible explains what happens to the brief once the build starts.
A brief is not a sales document; it is the specification your quote will be argued against, so write the uncomfortable parts down first.
Frequently asked questions
What should an AI project brief include at minimum?
▾
Four things: the job described as work with volumes, the data inventory with formats and locations, every system to be read from or written to, and a measurable accuracy bar with who judges it. Add constraints, budget range and ownership expectations. Two to three pages plus attachments is the right length.
Should I put a budget in the AI project brief?
▾
Yes, as a range. A budget range lets a vendor propose the scope that fits it instead of quoting the maximum version or guessing low. Withholding it does not produce a better price; it produces a quote for a system you may not want. Eazyware publishes starting prices so the range can be informed.
What if we do not know our accuracy requirement yet?
▾
Say so in the brief and ask for a discovery step rather than inventing a number. A ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, produces the evaluation plan and a golden question set. Defining the bar during acceptance testing is far more expensive than defining it beforehand.