A procurement-grade template that converts a vague AI ambition ("we should automate sales pipeline handover") into a document a serious vendor can quote against. Twelve sections covering business goal, target outcome, in-scope/out-of-scope, existing system inventory, integration points, data inventory, acceptance criteria, T-shirt-sized cost, and procurement timeline. Free download. CC0. The brief itself is what J Labs produces alongside you in a four-day Spec engagement.
The ambition usually arrives as a sentence. Someone senior says we should automate the sales pipeline handover, and it lands on whoever runs operations with an instruction to find a vendor. A sentence is not a project. It is a wish with a budget attached, and no serious vendor can quote against a wish without first rewriting it into something they can build.
So they do. Each vendor writes their own version of your project inside their proposal, with the boundaries drawn where their strengths sit. You end up with as many projects as proposals, at prices that cannot be compared, because what varies is not the price but the scope you never wrote down.
We think the buyer should write that document first, and we have published the one we use. It is a free, CC0 template in twelve sections, and it is the same document we produce alongside a buyer in a four-day Spec. Here is why it exists, what each section decides, which one gets skipped, and how to use it with a vendor.
Why does every AI project need a brief before code?
Because the expensive mistakes in an AI project are made before anyone writes code. Wrong output from a model is a fixable defect. A project pointed at the wrong outcome, scoped without boundaries, or priced without a data inventory cannot be fixed by better engineering, because engineering was never the problem. We decline engagements that begin with 'we want AI somewhere in the business', because vague briefs lead to vague results.
The brief is also the cheapest procurement instrument you own. Vendors charge for ambiguity, because ambiguity is risk and risk is priced. Every line you leave undefined is a line each vendor fills in their own favour. A brief that says what is out of scope, which systems the project touches and what acceptance means puts that ambiguity back where it belongs: with you, before the money moves.
What goes in the brief?
Twelve sections, each forcing a decision your organisation has to make anyway. The only question is whether you make it now, on paper, or later, in a change request. In order:
- Project header. Decides who owns the project, who wrote the brief, and whether it is a draft, reviewed, or ready to issue for bid.
- Business goal. Decides what the problem is in language a board member would understand, what it costs to leave unsolved, and why now. The first version is always too vague; rewrite it.
- Target outcome. Decides the measurable result, not the deliverable. Reducing triage time is an outcome; installing a router is an output. Outcomes survive scope changes.
- Scope, in and out. Decides what is deliberately excluded and what is deferred. If you do not say the user-facing interface is out, one vendor will quote it in and another will not.
- Existing system inventory. Decides which systems the project reads from or writes to, on which version, under which licence, owned by whom. Legacy integrations are priced differently from greenfield ones.
- Integration points. Decides the direction, protocol and authentication of every external interface. Where you do not know, write unknown: a discovery item, not a missing answer.
- Data inventory. Decides where each source lives, what shape it is in and how clean it honestly is, plus the data you do not have yet. That last line is where projects slip.
- Success criteria. Decides the conditions under which you sign off, the conditions under which you refuse, and who signs in what order. Agreed before work starts.
- Risks and assumptions. Decides which risks the vendor shares with you. The ones you list are shared; the ones you leave out are yours at the end.
- T-shirt-sized cost and timeline. Decides your own rough number, by component, before any vendor gives you theirs.
- Vendor selection criteria. Decides what vendors are judged on and when each procurement milestone falls, stated up front, not discovered in the review.
- Glossary. Decides which internal terms a vendor will not know, so nobody has to ask. The vendor who asks anyway is the careful one.
Which section do buyers always skip, and why does it cost them?
The cost and timeline section. Almost every buyer we meet fills the header, goal and scope with care, works through the inventories, and leaves the T-shirt sizing blank on the grounds that pricing is the vendor's job. It is not. Your rough estimate, by component, is the only anchor in the conversation that belongs to you. Without it the first proposal becomes the anchor and the whole range drifts upwards.
If the buyer has no number, the vendor sets the number, and it is never the lower one.
It asks for nothing precise: a size per component, a rough cost band and duration, the envelope you would take to the board, and what happens if it runs over. Vendors will refine every figure. What they cannot do is refine a figure you never wrote.
The data inventory, by contrast, gets filled in wrongly rather than skipped. The cleanliness column surprises everyone, because the honest score is usually lower than the written one, and every point of optimism there becomes data preparation nobody budgeted.
When is the brief ready to send?
When you can fill the existing system inventory and the data inventory without guessing. If you cannot, the project is not ready for a vendor, because the gap is internal discovery rather than implementation. Fill everything up to the risks with your own team before any vendor is involved, and have the people who own the data and the affected systems read it before it is issued; their corrections are the ones that would otherwise arrive as change requests. Mark unknowns as unknown. A discovery line in a proposal is far cheaper than an assumption in a contract.
How do you use the brief with a vendor?
Send the same document to more than one vendor and compare written proposals, not sales pitches. Every vendor is now quoting against the same scope, systems, data and acceptance language, so when two proposals differ the difference is finally informative: it tells you what one vendor saw that the other did not.
Hold vendors to the success criteria before work starts. A fixed-price engagement without acceptance criteria is an hourly engagement with extra paperwork, and a vendor who will not agree to yours is telling you something about the delivery. Read the risks back to them and ask which they will share.
The brief is vendor-neutral, which protects you from us as much as from anyone else. Take it to your in-house team, take it to a competitor, or shelve it. The document is the product.
What to do next
Download the free template from the Spec page on this site and fill it with your own team. It is CC0: copy it, fork it, put your logo on it. If you can complete the inventories, issue it for bid. If you cannot, you have learned something a proposal would have hidden.
If you would rather write it with us, that is what the Spec is. It starts with a 20 or 45-minute discovery call and a one-page summary within 24 hours. The four-day Spec itself, from €5,000, produces this brief in this exact shape, with an architecture sketch and a written cost estimate, all of which you own outright. If you then choose to build with us, the average build ships in eight weeks and 95% of our projects reach production. We work with companies of 50 to 5,000 people, and the next step after the Spec is never contingent on a build.