How to write an AI project brief that does not waste money

Most AI builds go wrong in the brief, not the build. By the time a developer is writing code, the damage is already done: a vague scope, a missing data source, no clear owner, and a success metric that nobody agreed on. This post gives you the five questions your brief must answer before anyone touches a keyboard.

Why do AI projects fail before they start?

95% of enterprise GenAI pilots see no measurable return, and the share of organisations abandoning most of their AI initiatives rose 17 percentage points to 42% in a single year. Those are scoping failures, not technology failures.

The pattern is always the same. Someone sees a demo, gets excited, books a call with an agency or a freelancer, and describes what they want in broad strokes. The agency nods along. A proposal arrives. Work begins. Three months later the thing that gets built is not quite what was imagined, the data it needed was locked in a system nobody mentioned, and the person who was supposed to approve outputs has been on leave since week two.

A good brief prevents all of that. It is five answered questions, and it fits on one page.

Question one: who is the user and what is their actual job?

Not "the marketing team" or "our ops people". One person, one task.

Describe what that person does today without the AI, step by step. Where do they start? What do they open? What do they type or read or decide? Where does it end?

If you cannot describe the current manual process in four sentences, you do not yet understand it well enough to automate it. Take that as a diagnostic, not a criticism. Go and sit with the person for an hour before you write another word.

The user definition also tells you what the interface needs to be. A warehouse operative does not want a dashboard. A finance director does not want a Slack bot. Get this wrong and you build something technically correct that nobody uses.

Question two: where does the data come from?

Every AI build runs on inputs. Your brief needs to name them precisely.

• What system holds the data? (CRM, ERP, spreadsheet, inbox, website, API)
• Is it structured or unstructured?
• Who owns access to it?
• How fresh does it need to be: real-time, daily, weekly?
• Are there any legal or contractual restrictions on using it?

The last one kills more projects than any technical problem. A company wants to build an AI that analyses customer feedback. Halfway through the build, legal points out that the feedback data lives in a third-party platform and the terms of service prohibit extraction. Six weeks of work, gone.

Name the source. Confirm access. Get it in writing if there is any doubt.

When we built Bidwell, the tender-response product, the entire architecture depended on ingesting UK contract-award records. Before a single line of code was written, we confirmed the data source, the update frequency, and the licence terms. Bidwell now has 2,100+ programmatic pages indexed off the back of 32,858 records. That only works because the data question was answered first.

Question three: where does the output go?

This is the question most briefs skip entirely, and it is the one that determines whether the AI actually changes anything.

An AI that produces a summary and drops it into a shared folder nobody checks has zero business value. The output needs a destination that is already part of someone's workflow.

• Does it write to a CRM field?
• Does it send an email?
• Does it update a row in a spreadsheet?
• Does it post to Slack?
• Does it generate a document that a human then edits and sends?

Be specific about the format too. "A report" is not a destination. "A PDF sent to the account manager's inbox by 8am every Monday" is a destination.

For our work with Vivify, the venue-discovery system, the output was a qualified list of hirer groups routed directly to the client, not a dashboard or a report. The first live run found 107 hirer groups for one school at a total data cost of £0.14. That number only means something because the output destination was defined before the build started.

Question four: who approves it and what does approval mean?

AI outputs need a human in the loop, at least at first. Your brief needs to name that human and define what they are actually checking.

This is about accountability, full stop. When the AI drafts a tender response, a contract summary, or a customer-facing email, someone needs to own the decision to send it. If that person is not named in the brief, you will spend the first month of go-live watching outputs pile up in a queue while everyone assumes someone else is reviewing them.

Define:

• Who is the approver by job title?
• What are they checking for? (accuracy, tone, compliance, all three)
• How long should approval take?
• What happens if they are unavailable?

The approver question also forces a useful conversation about automation depth. Some clients want the AI to act autonomously once it has proven itself over a hundred cycles. Others want a human sign-off indefinitely. Neither is wrong. Both need to be decided before the build, not after.

Question five: what is the number?

One metric. Not a list of KPIs. One number that tells you, six months from now, whether this was worth doing.

It might be hours saved per week. It might be the percentage of tender responses submitted on time. It might be cost per qualified lead. It might be the number of manual steps removed from a process.

The number does two things. First, it forces everyone to agree on what success looks like before opinions diverge. Second, it gives the build team a target to design towards, not just a feature list to execute.

A brief without a number is a wish list. A brief with a number is a project.

Half of UK SMEs now use AI in some form, but using AI and getting value from AI are different things. The ones getting value have usually done the unglamorous work of defining the metric before the build.

What a complete brief looks like

Here is the skeleton. Fill in each cell before you talk to anyone who writes code.

One page. That is all it needs to be. If you cannot fit it on one page, the scope is too large and needs splitting.

What to do if you are stuck on any of these

The most common sticking point is the source question. The data exists somewhere, but nobody is quite sure where, who owns it, or whether it can be moved. If that is you, the right first step is a short discovery session with someone who can map your data landscape before you commission a build.

The second most common sticking point is the number. Teams often resist committing to a metric because they are worried about being held to it. That is a cultural problem, not a technical one, and it is worth surfacing early. An AI build that nobody is willing to measure is an AI build that will be quietly shelved in six months.

Our consultancy work usually starts here, before any product decision, because the brief is where the money is either saved or wasted. If you want a second pair of eyes on a brief you are already working on, or you need help getting to a brief in the first place, book a consultation and we can work through it together.