What Belongs in an AI Automation Discovery Brief

A usable AI automation discovery brief documents seven things: the business outcome you want, the current workflow step by step, who makes which decisions, the systems involved, hard constraints, what happens when the process fails, and how you will know the automation actually worked. Skip any one of these and scope creep or a stalled build usually follows.

Why most automation projects skip the brief

Small businesses usually start automation projects from a tool demo or a vendor pitch instead of a written brief, which is why so many stall mid-build. A brief forces you to define the outcome and the failure paths before anyone writes a workflow, which is the step most owners skip because it feels slower than just starting.

Most owners get sold on a capability, “this can answer your phones” or “this can draft your invoices,” before anyone has written down what the current process looks like or what would count as success. The result is a build that technically works but doesn’t fit how the business actually operates. A front desk automation that can’t handle a rescheduled appointment, or an invoicing workflow that breaks when a customer disputes a line item, usually fails because nobody documented that edge case up front.

A discovery brief is not a project plan and not a vendor proposal. It is the raw material both sides need before either can commit to scope. If you’re comparing options for who builds this, our guide on AI automation agency for SMBs: what to look for covers how to vet a partner, but the brief below is what you bring to that conversation regardless of who builds it.

The seven things a brief must contain

A complete brief names the business outcome in plain terms, maps the current workflow step by step, lists every human decision point, inventories the systems touched, states hard constraints like budget and compliance, describes what happens when something fails, and defines what evidence will prove the automation works.

Element	What it answers	Example (illustrative)
Business outcome	Why does this matter to revenue, cost, or risk	Reduce missed calls that turn into lost bookings
Current workflow	What actually happens today, step by step	Caller reaches voicemail after hours, staff calls back next morning
Human decisions	Where judgment is required, not just data entry	Deciding whether a caller’s request needs a same-day callback
Systems involved	What software or hardware touches the process	Phone line, scheduling software, CRM, text messaging
Constraints	Budget, timeline, compliance, staff bandwidth	Must not require a new phone number; HIPAA applies
Failure paths	What breaks the process today and what could break it after automation	Caller has a multi-part question the system can’t answer
Acceptance evidence	What proof confirms the automation delivers the outcome	Call logs showing reduced missed-call rate over 30 days

Each row exists because leaving it blank creates a specific, predictable problem later. Skip constraints and you get a proposal that’s over budget. Skip failure paths and the automation embarrasses you the first time a customer hits an edge case.

Business outcome, not feature wish list

State the outcome in terms of revenue, cost, or risk, not in terms of the tool you think you want. “We lose bookings when calls go to voicemail after 6pm” is a brief. “We want an AI receptionist” is a feature wish. The first gives a builder something to measure against; the second gives them nothing to push back on when scope grows.

Current workflow, documented honestly

Write down what actually happens today, including the messy parts. If your team already improvises around a broken step, say so. A workflow map with the honest gaps included is more useful than a clean diagram that describes how the process is supposed to work.

Human decisions the automation should not make alone

List every point where a human currently exercises judgment: pricing exceptions, refund approvals, medical triage, anything with legal or safety weight. These are the places where you decide whether the automation handles the task fully, escalates it, or stays out of it entirely. For phone-based businesses, this list often overlaps heavily with what’s covered in our breakdown of what an AI voice agent for small business actually does.

What to leave out of the brief

A discovery brief should not include a chosen tool, a locked technical architecture, or a final price. Naming a specific platform or vendor before scoping the problem narrows your options and can lock you into a solution that doesn’t fit the workflow you just mapped.

The brief describes the problem and the constraints, not the solution. Let the builder or your internal team propose the architecture once they’ve seen the full picture. If you already have a required system, an existing CRM you’re not replacing, that’s a constraint, not a solution, and it belongs in the constraints row, not as the entire brief.

Constraints and failure paths deserve their own detail

Constraints and failure paths are the two sections owners most often write vaguely, and they’re the two that cause the most expensive misunderstandings. Be specific about budget ceilings, compliance requirements, and staffing limits, and list every way the current process breaks down before you ask an automation to handle it.

Vague constraints like “keep it affordable” invite mismatched proposals. A number, even a rough range, does more work than an adjective. Similarly, “sometimes calls are complicated” is not a failure path. “About one in five after-hours calls involves a question our front desk staff would also need to escalate to a manager” (illustrative) is a failure path, because it tells a builder exactly where the automation needs an escalation rule.

Medical and legal-adjacent businesses have extra failure paths worth naming explicitly: after-hours emergencies, HIPAA-covered information, anything a human must review before it goes out. If that’s your context, see our guides on AI answering service for medical offices and AI receptionist vs. law firm front desk costs and gaps for how those constraints typically get written up.

How acceptance evidence keeps everyone honest

Acceptance evidence is the pre-agreed proof that the automation met the outcome you named, decided before the build starts, not after. Define it as a measurable signal, like a call log, a report, or a before-and-after comparison, so both sides can evaluate the result the same way instead of arguing about impressions.

Decide this before the build starts, not after, because after the fact both sides tend to grade success differently. A simple format works:

1. Name the metric tied to the original outcome (missed-call rate, invoice turnaround time, response time to inquiries).
2. Set the measurement window (30 days is common for phone-based automations).
3. Agree on the data source (call logs, CRM records, a shared report).
4. Agree in advance what “working” looks like, not perfect, but functioning as intended.

This is also where cost conversations get grounded in reality. Our article on AI automation agency pricing: what you actually pay in 2026 explains why a defined outcome and acceptance criteria tend to produce tighter, more predictable quotes than an open-ended request.

When a full brief isn’t worth writing

If the task is genuinely small, a single scheduled reminder email or a one-time data export, a full seven-part brief is overkill. Save the formal brief for automations that touch customer-facing decisions, compliance-sensitive information, or more than one system, where the cost of a mismatch is higher than the time spent documenting it.

A brief also isn’t a substitute for talking to whoever will build the automation. It’s a starting document, not a contract. Expect it to change once a builder points out a constraint or failure path you missed.

Turning the brief into next steps

Once you have these seven pieces written down, even roughly, you’re in a position to have a useful conversation with an automation partner instead of a speculative one. If you’re still deciding whether to hire an agency or a freelancer for the build itself, AI automation agency vs freelancer: which is right for your business walks through that tradeoff directly.

A fixed-scope audit is the right next step when your brief reveals more than one system or decision point involved, since that’s usually when informal quotes stop being reliable. You can book a free AI audit to walk through your brief with someone who scopes these builds for a living, no obligation to proceed past that conversation.

Frequently asked questions

How long should a discovery brief take to write?

For most small-business automations, a working draft takes one to two hours if you already know your current workflow. The time is mostly spent writing down decisions and failure paths you haven’t consciously listed before, not researching anything new.

Do I need technical knowledge to write one?

No. The brief describes your business process and constraints in plain language. Naming systems by their common name, “our scheduling software,” “our phone line”, is enough. Technical mapping is the builder’s job once they have your brief.

What if I don’t know my failure paths yet?

Ask your front-line staff. Whoever answers phones, handles bookings, or processes invoices today usually knows the edge cases better than an owner does, because they deal with them directly.

Can one brief cover multiple automations at once?

It’s better to write one brief per outcome. A brief that tries to cover phone handling, invoicing, and scheduling at once tends to blur constraints and failure paths that are actually specific to each workflow.

Does a brief replace a vendor’s discovery call?

No. A brief prepares you for that call. It shortens the call and improves the quality of the resulting proposal, but a builder will still ask follow-up questions specific to how they plan to implement the automation.