Write an AI Project Brief That Gets Comparable Proposals

Most AI project briefs start with a solution: build a chatbot, add a copilot, automate a workflow. That is one decision too late.

If three consultants receive only that sentence, they will price three different projects. One may quote a prototype. One may include production integrations and monitoring. One may assume your team will clean the data and run the system after launch. The totals will not be comparable because the work is not comparable.

A useful brief is not a long request for proposal. One page is enough to give every bidder the same starting line and expose what your own team has not decided yet.

What the brief is for

The brief has two jobs. First, it lets a consultant tell whether the project fits their team. Second, it gives you a fixed point for comparing scope, assumptions, and price.

Public guidance reaches the same practical conclusion from different angles. The NIST AI Risk Management Framework starts with intended purpose, users, context, impacts, and ways to measure performance. The UK government's AI procurement guidance recommends a clear problem statement, a data assessment, output-based requirements, and a plan for the system after launch. Neither starts with a model name.

Keep the brief short and specific.

If an answer is unknown, write “unknown” and ask bidders to explain how they would resolve it. That is more useful than filling the page with confident but untested assumptions.

The one-page AI project brief

1. The work today

Describe one workflow from its trigger to its finish. Name who does it, how often it happens, which systems they touch, where work waits, and what usually has to be corrected.

Example

Each weekday, two support coordinators read new customer emails, find the account in our CRM, choose one of twelve request types, and route the case to the right queue. About 1,800 requests arrive each month. Misrouted cases are found only after a team rejects them.

That gives a bidder something they can inspect. “We want to use AI in customer support” does not.

2. The result you want

State the business change, not the feature. Include the current baseline if you have it, the improvement you want to test, and anything that must not get worse.

What should become faster, cheaper, safer, or more consistent?
How is it measured now?
What result would make a pilot worth continuing?
What tradeoff would make you stop?

If you do not have a baseline, make measurement part of discovery. Do not ask a consultant to promise a percentage improvement against a process nobody has measured.

3. The people involved

List the people who use the workflow, approve exceptions, own the underlying policy, support the systems, and are affected by mistakes. Include outside users such as customers, patients, job applicants, or suppliers when relevant.

This is where a simple automation often changes shape. A tool used by three trained employees needs a different interface and review path from one making suggestions to thousands of customers.

4. The data and systems

Name the likely sources without attaching sensitive data to the first brief. For each source, note its owner, format, approximate volume, quality problems, access limits, and whether a safe sample exists.

Which systems need to be read from or written to?
Which fields contain personal, confidential, or regulated information?
How much historical data is available, and does it include the outcome you care about?
Who can approve access for discovery, testing, and production?

“We have the data” is not the same as “the project can use the data.” Finding that distinction after a contract is signed is an expensive way to begin.

5. The boundaries

Say what the system may suggest, what it may change, what requires a person, and what it must never do. Then describe what should happen when the system is uncertain, unavailable, or wrong.

For the support-routing example, the first version might be allowed to recommend a queue but not send a customer reply, change an account, or close a case. Low-confidence requests would return to the existing manual queue. Those limits affect the architecture and the price, so they belong in the brief.

6. The pilot and acceptance test

Define the evidence you will use to decide whether the work continues. A good acceptance test names the sample, the measure, the person who judges it, and the threshold for go, revise, or stop.

For example: test against a held-back set of previously resolved requests; compare routing quality and handling time with the current process; review every high-impact error; and have the support lead approve the result. The actual thresholds should come from your baseline and risk tolerance, not from a generic benchmark.

7. Ownership after launch

Name the internal owner and ask bidders to state what that person will receive at handoff. Include documentation, access, training, monitoring, incident response, maintenance, vendor accounts, and the right to continue the work with another supplier.

Also ask for the twelve-month operating cost separately from the build price. Hosting, model usage, third-party software, monitoring, support, and internal review time can turn the lowest build quote into the most expensive option.

8. The commercial guardrails

Give a credible budget band, target decision date, important deadlines, procurement steps, and known dependencies. A budget band helps a consultant propose the right shape of work. Hiding it usually produces more unsuitable proposals, not a better price.

If you are uncertain, ask for discovery and delivery to be priced separately. That lets you buy the missing answers without pretending the full build is already defined.

A complete brief in twelve lines

Copy this structure into an email or document:

Workflow: What happens now, from trigger to finish?
Volume: How often does it happen, and how variable is the work?
Problem: Where does time, cost, delay, inconsistency, or risk appear?
Outcome: What observable business result should change?
Baseline: How is that result measured today?
Users: Who uses, approves, supports, and is affected by the system?
Data: What sources exist, who owns them, and what is missing?
Systems: What must be read, changed, or integrated?
Limits: What requires human review, and what must never be automated?
Pilot: What sample and acceptance test will decide whether to continue?
Handoff: Who owns the system, documentation, access, and maintenance?
Guardrails: What budget, timing, security, legal, or procurement constraints apply?

What every proposal should answer

Send the same brief to every bidder and ask them to respond in the same order. Each proposal should:

restate the problem and call out assumptions or missing information;
separate discovery, pilot, production, and ongoing support;
name what is included, excluded, and dependent on your team;
explain the test plan and what counts as acceptance;
identify the delivery team and relevant evidence from similar work;
itemize the build price and expected operating costs;
define documentation, access, training, and handoff.

Then use the proposal scorecard to compare whether each bid answers the same questions. Do not reward a longer proposal for avoiding a harder answer.

Before you send it

Have the workflow owner, the system owner, and the person accountable for the result read the brief. If they disagree, resolve that before asking an outside team to price the work. A vendor cannot turn an internal disagreement into a reliable scope.

Keep the first version to one page. Supporting diagrams, policies, and data notes can follow after a consultant confirms the fit and the right confidentiality terms are in place.

Ready to send the brief?

Submit the same project details once for review and relevant introductions, or compare directory records if you already have a shortlist.

Send a project brief Compare firms

Sources

NIST AI Risk Management Framework — voluntary guidance for mapping the purpose, context, people, measures, and risks around an AI system.
UK government guidelines for AI procurement — guidance on problem statements, data assessment, output-based requirements, supplier evaluation, and lifecycle planning.