How to Write an AI Project Brief Your Team Will Follow

A Tampa staffing agency spent $22,000 on an AI project that never launched. The vendor built exactly what they asked for. The problem: nobody had written down what they actually needed. The brief said "automate candidate screening" and the vendor delivered a keyword matcher. The team wanted something that could read resumes and rank cultural fit. Same words, different expectations.

A project brief is the cheapest insurance policy in AI. Fifteen minutes of writing prevents months of building the wrong thing. This guide walks through what belongs in that document and what to leave out.

What a Brief Is (and Isn't)

A brief is not a technical specification. You don't need to know APIs, model architectures, or integration protocols. Those are the vendor's job. Your brief answers three questions: what problem are we solving, how will we know it worked, and what constraints exist.

Think of it as the difference between telling a contractor "I want a modern kitchen" versus "I want a kitchen where two people can cook at the same time, the dishwasher is next to the sink, and the budget is $40K." The second version gets you a kitchen you actually use.

Section 1: The Problem Statement

Start with one paragraph describing the problem in plain language. Name the people affected, the frequency, and the cost. Skip the aspirational language about "digital acceleration" and write what's actually happening.

Example problem statement

"Our sales team (4 reps) spends approximately 6 hours per week each writing follow-up emails after discovery calls. Most follow-ups go out 2-3 days late because reps prioritize new calls over writing. We estimate this delay costs us 3-5 deals per month based on response-time data from our CRM."

Notice what's in there: who (4 sales reps), how much time (6 hours/week each), the delay (2-3 days), and the estimated cost (3-5 lost deals/month). A vendor reading this knows exactly what to target.

Section 2: Success Criteria

This is where most briefs fail. They describe what the tool should do but not how anyone will judge whether it works. Write your success criteria as measurable statements you can check in 30 days.

Good criteria are binary. You can answer yes or no. "Follow-up emails go out within 4 hours of each call" is testable. "Improve our email response workflow" is not.

Aim for 3-5 criteria. More than five and you're describing a second project. Fewer than three and you haven't thought hard enough about what success looks like. Here's a practical set for the email follow-up example:

Follow-up drafts appear in the rep's inbox within 1 hour of a call ending
At least 80% of drafts require only minor edits before sending
Average follow-up send time drops from 2.5 days to under 4 hours
Sales reps each recover 4+ hours per week

Section 3: Scope Boundaries

Write down what the project does NOT include. This section prevents scope creep, which kills more AI projects than bad technology.

Be specific. "Phase 1 does not include CRM integration" means something. "We'll keep the scope manageable" means nothing. List every feature or integration someone might expect but that you're intentionally excluding.

Scope boundary examples

• Does NOT include automatic sending (reps review every draft)
• Does NOT integrate with phone system (call notes entered manually for now)
• Covers discovery calls only, not onboarding or support calls
• English language only

Section 4: Data and Systems

Your vendor needs to know what data exists and where it lives. You don't need a technical inventory. List the tools your team uses for the relevant workflow and what kind of information sits in each one.

For the email example: "We use HubSpot CRM for deal tracking, Google Calendar for meeting scheduling, and reps currently type call notes into a shared Google Doc. Average call note is 200-400 words."

If your data is messy, say so. Most business data is, and honest assessment saves time. A vendor who knows upfront that your CRM has duplicate records won't be surprised three weeks into the project.

Section 5: Timeline and Budget

State your hard deadlines and your budget range. Not a single number for budget, but a range. "We have $8,000-$12,000 for this project and need it operational before our Q2 hiring push starts on April 1" gives a vendor room to propose options.

If you have no idea what this should cost, say that too. Our budget planning guide covers realistic ranges. Vendors respect honesty about budget more than they respect silence.

Include any internal constraints: regulatory review timelines, planned system migrations, seasonal busy periods when your team can't participate in testing. These shape the project timeline more than the technology itself.

Section 6: Who's Involved

Name the decision maker, the daily point of contact, and anyone who will test or use the final product. Roles matter more than org charts. Your vendor needs to know: who approves the final deliverable, who answers questions during the build, and who gives feedback during testing.

Skip this section and you get the classic problem where a project manager approves something the end users hate, or where no single person has authority to make decisions, so every question takes a week to answer.

Filling It In

Brief template (copy and fill)

Problem: [Who is affected, what they're doing now, how much time/money it costs]

Success criteria: [3-5 measurable, yes/no statements]

Not included: [Features and integrations explicitly excluded from this phase]

Data & systems: [Tools used, data formats, known quality issues]

Budget & timeline: [Range, hard deadlines, internal constraints]

People: [Decision maker, daily contact, testers/users]

This entire document should fit on one page. If it doesn't, you're either describing multiple projects or including technical details that belong in the vendor's proposal, not your brief.

Three Mistakes That Weaken a Brief

Writing for the vendor instead of for yourself. The brief is your thinking tool first. If you can't clearly articulate the problem and success criteria to your own team, no vendor can solve it for you. Write the brief before you contact anyone.

Describing the solution instead of the problem. "We want a GPT-4 powered chatbot with RAG and vector search" tells the vendor exactly what to build. It also prevents them from suggesting something simpler, cheaper, and better. Describe the problem. Let the vendor propose solutions.

Skipping the "not included" section. Every AI project has a gravitational pull toward "while we're at it, can we also..." The exclusions section is your defense against that pull. Without it, your project scope doubles before anyone writes a line of code.

After the Brief

Share the brief with every vendor you're considering. Identical input makes vendor comparison straightforward. You're comparing proposals against the same requirements instead of comparing apples to architectures.

Keep the brief alive during the project. When someone suggests adding a feature, check it against the scope boundaries. When the vendor delivers, check the output against your success criteria. The brief isn't paperwork. It's the scorecard.

Fifteen minutes of writing now prevents the $22,000 misunderstanding later. Open a blank document, fill in six sections, and you have a project that starts with shared expectations instead of shared assumptions.