The demo always works.
That's the trap. An agency spends a week wiring up an automation, shows the client a run that classifies fifty emails perfectly, and everyone in the room decides the project is basically done. Then the build starts, and it turns out the client has four inboxes, not one. The historical data lives in a CRM nobody has admin access to. Six per cent of the emails are in Bahasa. And the person who signed off on the demo has quietly assumed the thing will also draft replies.
None of that is a technology problem. It's a scoping problem.
Before starting Scopeyard, I spent years running a product development studio and delivering AI automation work across healthcare, recruitment and operations. The automation projects that went badly were almost never the ones where the model underperformed. They were the ones where we agreed to "automate the intake process" without ever writing down what one unit of intake actually was, what accuracy we owed, or who handled the cases the system got wrong.
The industry data says the same thing at scale. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls — three failures that all trace back to scope. MIT's Project NANDA study of enterprise GenAI found that 95% of pilots delivered no measurable P&L impact, and concluded the failure was in the approach, not the model.
So here is how I scope AI automation work.
The thesis in one line:
Scoped AI Project = Defined Unit of Work × Data Reality × Accuracy Bar × Human Fallback + Change Budget
Miss any term and you're not scoping. You're hoping.
1. Scope the workflow, not the technology
Clients ask for tools. "We want an AI agent." "Can you put a chatbot on our support?" "We need RAG on our documents." If you scope to the tool, you've scoped to a thing that has no edges, because a chatbot can always do one more thing.
Scope to the workflow instead. Which process, with which trigger, ending in which state? Not "an AI agent for recruitment" but "when a CV arrives in this inbox, extract twelve fields, score against the open role's criteria, and write the result into the ATS as a draft record." That sentence has a beginning and an end. You can price it, test it and hand it over.
The test I use: if you can't describe the automation as a sentence with a trigger and a terminal state, you don't have a scope yet. You have an ambition.
Write down what's out of scope in the same breath. Not the passive "anything not listed above is excluded" clause — the specific things the client is quietly imagining. In the CV example: it does not send emails to candidates, it does not reject anyone automatically, it does not handle CVs sent as photographs. Naming the three things they were secretly hoping for is worth more than ten pages of boilerplate.
2. Define the unit of work before you price anything
Every AI automation has a natural unit — a resolved ticket, a parsed invoice, a screened CV, a summarised call. Find it and make it the spine of the entire proposal.
The unit gives you four things at once: a volume estimate, a cost denominator, an accuracy denominator, and an obvious basis for a maintenance contract. Without it you end up quoting "the automation" as a lump, which means every question about performance or cost becomes an argument.
Ask for the numbers up front and make them contractual assumptions:
- How many units per month today? What's the peak?
- What's the current cost per unit in human time?
- What's the distribution — are 80% of them boring and 20% weird?
That last one decides the project. Most automations are easy on the boring 80% and brutal on the tail. If a client tells you the volume is 4,000 documents a month, but 600 of them are scanned faxes from one hospital, the fax problem is the project. Price it as such or exclude it explicitly.
3. Charge for a data reality check, and do it before you quote the build
The single most reliable way to lose money on AI work is quoting a fixed price on data you haven't seen. Estimates for how much of AI project effort goes into data preparation and cleanup cluster around 60–70%, and Gartner has put the share of organisations whose data is genuinely AI-ready at around 12%. You are, statistically, walking into a mess.
So make the mess someone's paid deliverable. Run a short, scoped assessment: pull a real sample, check formats, check access, check who owns the credentials, check whether the "clean historical dataset" the client mentioned exists in any form other than a person's memory.
| Automation size | Data + workflow assessment fee | Duration | What you deliver |
|---|---|---|---|
| Single workflow, one system | $2,000–$5,000 | 3–5 days | Sample run, integration map, accuracy baseline |
| Multi-step, 2–4 systems | $5,000–$15,000 | 1–3 weeks | Above, plus eval set and a costed build plan |
| Agentic, cross-department | $15,000–$40,000+ | 3–6 weeks | Above, plus governance, escalation and rollback design |
The ranges above are the shape I've used and seen used; adjust to your market. The point isn't the exact figure. The point is that the assessment is a sold engagement with its own deliverable, so if the client walks away afterwards, you've been paid for the most valuable thinking in the whole project. If a client won't pay a few thousand to find out whether their data supports the thing they want, they will not pay for the six weeks of remediation it needs either.
I've written more on the pricing mechanics in How to Price AI Automation Projects.
4. Put the accuracy bar in writing, in the client's units
"Accurate" is not a specification. Somebody has to write a number down, and it should be you, in the assessment phase, measured on their real data.
Frontier model hallucination rates in 2026 still run anywhere from roughly 3% to 19% depending on model, task and configuration — and benchmark scores are poor predictors of what you'll see on a messy enterprise corpus. So don't quote a vendor's benchmark. Build a small eval set from the client's own examples during the assessment, measure against it, and state the bar in their units: "correctly extracts all twelve fields on 94% of CVs in the agreed test set; flags the rest for review."
Then hold two lines. First, the bar is measured on the agreed test set, not on whatever surprising document arrives in month three. Second, closing the gap from 94% to 99% is a separate, priced piece of work — usually a bigger one than getting to 94% in the first place. Agencies lose entire margins by treating the last few percentage points as a bug fix.
5. Scope the human in the loop as a deliverable, not an apology
Every automation that touches real consequences needs a path for the cases it gets wrong. That path is a deliverable: a review queue, an escalation rule, a confidence threshold, a person who owns exceptions, an audit trail.
Clients don't ask for this because they're imagining full automation. Your job in scoping is to say plainly that 100% autonomy on a consequential workflow is not what they're buying, and then show them the design that makes 94% genuinely useful. In healthcare work this was never negotiable — anything touching a clinical or eligibility decision got a named reviewer and a log. It turned out to be the right default everywhere else too.
Price it. Building a review interface, a threshold policy and an audit log is real engineering. If you fold it in for free to keep the quote attractive, you'll build it anyway in week five and eat it.
6. Count the steps, because reliability compounds downwards
This is the arithmetic that kills agentic scopes. A step that is 95% reliable, chained ten times, gives you about 59% end-to-end reliability. Chain twenty steps and you're near 36%.
Which means a multi-step agent is not "a bigger version" of a single-step automation. It's a different risk class. When a client describes a workflow with nine handoffs, you have three honest options: cut the chain, add checkpoints between steps so errors don't propagate, or scope the first version to the two steps that carry most of the value.
I almost always take the third. Ship the narrow thing, get real production numbers, then expand with evidence. It's also the commercially smarter move — a shipped narrow automation earns you the second project; a stalled ambitious one earns you a reference you can't use.
7. Scope the running cost, not just the build
An AI automation has a cost per unit forever. Agencies routinely scope the build and say nothing about the run, then discover in month two that nobody agreed who pays the API bill.
Work it out during the assessment using your unit of work. Take tokens per unit, multiply by volume, multiply by the model's rate. Production-tier model pricing in 2026 sits around $2.50–$5 per million input tokens and $15–$25 per million output tokens for the frontier tiers, with budget models an order of magnitude cheaper — so model choice, prompt caching and routing simple cases to a cheaper model are scope decisions with real money attached. Batch APIs across the major providers offer a flat 50% discount where latency allows.
Then write into the proposal: who holds the API account, what happens if volume doubles, what the monthly floor looks like, and what maintenance covers. A model deprecation or a changed upstream API is not a warranty claim. It's a maintenance contract.
8. Write the change budget in before anyone needs it
Scope will change. On AI projects it changes more than usual, because the client learns what's possible only once something is running. Pretending otherwise doesn't prevent change requests — it just makes each one a negotiation you're having for free.
So build the mechanism in at proposal stage. A named change process, a rate for out-of-scope work, and ideally a pre-agreed pool — say 10–15% of build value — the client can spend on changes without a new contract cycle. It converts every awkward "can it also do X" conversation from a conflict into a transaction.
The same discipline applies to approvals. Automation projects stall on sign-off more than on engineering: a model output sits waiting for someone's opinion for eleven days, and the client remembers the delivery as slow. Every deliverable needs a named approver, a date and a visible state. This is the part we built Scopeyard around — milestones, review states and client approvals in one place — because on AI work the difference between a project that feels controlled and one that feels chaotic is almost always whether anyone can see what's waiting on whom.
Final thoughts
Scoping an AI automation is not a more technical version of scoping a website. The uncertainty sits in different places: in the data you haven't seen, in the tail of weird cases, in the accuracy nobody defined, in the steps that multiply against you, and in a running cost that never stops.
Every one of those can be handled — but only in the scoping phase, and only in writing. Afterwards they're not scope items. They're arguments.
The agencies that get burned on AI work aren't the ones who scoped it wrong. They're the ones who never scoped it at all — they demoed it, and called that a scope.
Get paid to look before you promise.