How to Scope an AI Automation Project So It Doesn't Eat You Alive

"Can you build something that reads these and puts them in the system?"

That's the whole brief. That's what an AI automation project usually looks like when it arrives. Nine words, one gesture at a folder, and an expectation that you'll quote a number by Friday.

Those nine words hide about six separate questions, and every one of them is somewhere the project can quietly go 40 hours over. Not because the AI part is hard. The AI part is usually the easiest week of the whole thing. It goes over because nobody wrote down what "reads these" means, whose data it is, what happens when it's wrong, and who's on the hook when the model it runs on gets retired eleven months from now.

I sell this work. I run a one-person agency in Augsburg building Claude Code skills and automations for clients, mostly in the US. So this isn't a warning from the sidelines. It's the list of things I now put in writing before I quote, because leaving them out is how you end up doing a discovery project for free with a build project's deadline attached.

Want the printable version? Download the complete scoping worksheet as a PDF — 9 pages, the full six-question questionnaire, no login required.

The Failure Rate Numbers You'll See Quoted at You

Somebody in the sales conversation is going to quote a statistic at you. Usually it's "95% of AI projects fail." Before you either repeat it or panic about it, look at where it comes from.

That 95% comes from The GenAI Divide: State of AI in Business 2025, out of MIT's NANDA initiative. It's not a peer-reviewed MIT study, and it doesn't say 95% of AI projects fail. It says 95% of the pilots it looked at showed no measurable P&L impact within about six months. The evidence base is 52 executive interviews, a survey of roughly 150 leaders and a scan of about 300 public deployments, and the report itself calls its interview findings directionally accurate rather than drawn from company reporting. Cost savings, cycle time, churn: none of it counted. The honest version is that in a small set of self-reported interviews, most pilots hadn't moved the P&L in six months. Less dramatic. Also true.

The number I'd actually use is from S&P Global Market Intelligence's 451 Research, whose Voice of the Enterprise AI survey covers more than 1,000 organisations in North America and Europe: the share of companies abandoning most of their AI initiatives went from 17% to 42% year over year, and the average organisation scrapped 46% of its proof-of-concepts before production. Still self-reported, but a thousand companies beats 52 interviews, and abandonment is something people can answer accurately about themselves.

Then Gartner, which on 25 June 2025 predicted that over 40% of agentic AI projects would be cancelled by the end of 2027 due to escalating costs, unclear business value and inadequate risk controls. Note the tense: that's a forecast, not a measurement, and anyone quoting it as an observed failure rate is quoting it wrong. The useful part is the three causes it names. Cost, ambiguity and risk. Not the technology failing to work. All three are scope problems.

Nobody Agreed What "Working" Means

An automation that's right 80% of the time is either a triumph or a total write-off depending on the task, and nobody decides which up front. Which is how you get to the demo and discover you and the client had different projects in your heads the whole time.

Sorting inbound email into three buckets at 80%? Genuinely fine. A message lands in the wrong folder, someone moves it, life continues. Extracting payment amounts from invoices at 80%? That's one wrong number in every five, in accounting, which is worse than useless: now somebody has to check all of them, which is the job you were hired to remove.

So the scope needs an acceptance criterion, in numbers, agreed before you build. Something like: measured against a sample of 200 real documents the client provides, the system correctly extracts the six named fields in at least 95% of cases, and flags rather than guesses when confidence is low. Three things do the work there. The sample is real client data, not your cherry-picked examples. The fields are named, so "it should also get the PO number" is a change order rather than an assumption. And the flagging clause makes an honest "I don't know" correct behaviour rather than a miss.

Write down the counting method too, because "95% accurate" without a denominator is an argument waiting to happen: one wrong field out of six, is that document 0% or 83%?

And be blunt about which category the task is in. If being wrong 5% of the time is both unacceptable and undetectable, say so on the call, because sometimes the right answer is that this shouldn't be fully automated at all. Half of my honest flowchart on whether you need an AI consultant is really this question in disguise.

The Data Is Always Worse Than the Client Said

Always. Not usually. I have never once opened a client's data and thought "oh, this is cleaner than described."

What you're told: "It's all in the CRM, it's pretty standardised." What's there: exports from two CRMs because they migrated in 2023 and never finished, a spreadsheet the office manager keeps privately because she doesn't trust the CRM, dates in three formats, company names with and without GmbH, scanned PDFs that are photographs of paper, and 200 records where somebody put the phone number in the notes field.

That isn't the client lying. Nobody has looked at all of their data at once in years, and the person describing it to you is describing the tidy part they touch.

The fix isn't a bigger buffer in your estimate. It's a separate, paid, fixed-scope discovery phase before you quote the build. One to two weeks: you get a real export, profile it, and deliver a short document saying what's in there, what share is usable as-is, what cleanup would cost, and what the realistic accuracy ceiling is on this input. The client pays for it and owns the deliverable. If they walk afterwards, they got value and you got paid.

Two clauses go with it. The build quote is valid only against the data set profiled during discovery, described precisely enough to identify it. And data cleanup is excluded unless quoted separately. Otherwise you will absorb the cleanup, silently, at midnight, for free.

"Just Connect It to Our System"

"Just" is carrying a load-bearing amount of weight in that sentence. I've collected other phrases like it in a list of client lines that mean scope creep already started, and this one belongs near the top.

What "their system" turns out to be, roughly in order of frequency: a SaaS product with a documented API, which is the good case. One whose API is gated behind a partner programme or a pricing tier the client isn't on. An API with undocumented rate limits you discover in production. An on-premise system whose vendor charges four figures for an integration consultation. A system with no API, where the real answer is a nightly CSV drop. And the one that hurts: an API that exists, behind an IT department that needs six weeks and a security review to issue credentials.

That last one isn't technical at all, and it blows more delivery dates than anything else on the list. You cannot fix it with better code.

So name the integration surface explicitly. Not "integrates with the client's CRM," but: integration with HubSpot via the v3 CRM API, using credentials the client provides by a named date, covering these named objects and these operations. Add a clause making credentials, licence tiers and third-party fees the client's responsibility, with the timeline shifting day for day if access is late. Not as a punishment. As the thing that stops you eating a delay you had no power to prevent. And write down what happens if the integration turns out to be impossible, because discovery is where a rescope should still be cheap.

Every Edge Case Arrives as "It Should Obviously Also Handle This"

The word "obviously" is the tell. The client considers this case so normal that it never occurred to them to mention it, which is also why they genuinely feel they aren't asking for anything new.

Multi-currency invoices. Documents in a second language. The supplier who sends everything as a phone photo. Credit notes, which look like invoices with the sign flipped. The quarterly batch that arrives as one 400-page PDF instead of 400 files. Each is a real day of work, sometimes three, and each arrives framed as a bug rather than a feature.

You can't enumerate every edge case in advance, and that isn't the goal. The goal is a boundary, so everything outside it is visibly outside it. Which means your scope describes the input universe rather than the output: single-page PDFs generated digitally, in English or German, from the supplier list provided during discovery, one invoice per file. Anything that doesn't match routes to the exception queue rather than getting processed.

That last clause changes the conversation. An unhandled edge case is no longer a failure, it's the system behaving as specified, and extending coverage becomes a priced change request against a written baseline. I've been on the wrong end of a post-delivery renegotiation, and the clause that saved me worked precisely because it was specific enough to be boring.

Then budget an edge-case allowance into the build: a fixed number of days for cases found during the pilot, priced in. When those days are used, further cases are change requests. The client sees a real number and nobody feels ambushed.

Human Review Is the Deliverable, Not the Fallback

Here's the thing that surprises people who haven't shipped one of these: the human-in-the-loop design is usually the majority of the actual work.

The extraction is a prompt and some plumbing. The rest is: how a low-confidence result gets surfaced, who sees it, in what interface, how they correct it, how the correction gets back into the system of record, who gets notified when the queue backs up, and what happens when the reviewer is on holiday.

Every one of those is a design decision with a client-side dependency. Leave them out of the scope and you'll build them anyway in the last two weeks, unpaid, because without them the automation doesn't function.

So the review workflow goes in the deliverables list as its own line item with its own price. Name the interface, whether that's a Slack approval flow, an admin screen or an email digest. Name the reviewing role, and get the client to name the actual person. Define what "resolved" means and what happens when it isn't.

Then say out loud what this does to headcount, because most clients still expect it to go to zero. Realistically you're moving someone from doing all of it to checking the 10% the system flagged. That's a genuine efficiency gain worth paying for. It's just not the demo they saw, and what happens after a CEO watches an AI demo is the same gap seen from the other end.

The Maintenance Tail Nobody Prices

An automation is not a website. A website you build, hand over, and it keeps rendering. An automation sits on infrastructure that changes underneath it whether anyone touches the code or not.

Anthropic commits to at least 60 days notice before retiring a publicly released model, which is the good end of the industry. Sixty days is courteous and also not very long if the client has to schedule a change window, revalidate accuracy against their acceptance criteria and get sign-off. Models do get retired on real timelines, and 2026 has already taken several widely used ones off the API. If your automation pins a model, someone owns re-validating it when that model goes away.

That's one of four moving parts. Token prices change. Rate limits and API terms change. And the client's own process changes, which is the sneakiest: they add a field to a form, or a new supplier joins with a different format, and the automation starts being quietly wrong in a way nobody notices for a month.

Prompt drift is real too, and less mystical than it sounds. The prompt doesn't degrade; the inputs shift or the model underneath changes, and the same prompt produces different output on the same data. Which is why the accuracy criterion you negotiated at the start is also your maintenance tool. Run the same 200-document sample quarterly and you have a number instead of a feeling.

So the scope ends with an explicit answer to "who owns this on day 91." Either a retainer covering model migrations, monitoring, a quarterly accuracy check and a set number of support hours, or a clean handover where the client takes ownership and you document exactly what they've taken on. The second is legitimate. It just has to be written down, the same way a website handoff checklist is, or "we thought you were handling that" becomes the theme of month four.

Why Fixed Price on an Undefined Data Set Loses You Money

Fixed price is not the enemy. Fixed price on something you haven't measured is.

Your effort on these projects scales with the messiness of data you haven't seen yet, and messiness has a long tail. Your estimate is based on the clean examples the client sent, because those are the ones they were proud of. Your delivery is against everything. Quoting fixed price there isn't confidence, it's writing the client a free option on your time.

Three structures that actually work in a proposal.

Discovery first, then fixed price. Phase one is a paid, fixed-price discovery of one to two weeks with a documented deliverable. Phase two is a fixed-price build quoted afterwards, valid against the data profiled in phase one. The client gets their cost certainty, one step later than they asked for. This is my default, and it sells easily because phase one is small enough to approve without a committee.

Phased delivery with a real go/no-go. Pilot one document type at a fixed price, measured against the accuracy criterion, then a separate priced phase to extend coverage. Say in the proposal that the client can stop after the pilot. It reads as confidence, and it removes the pressure to cram everything into phase one.

Time and materials with a cap and a checkpoint. For genuinely exploratory work: hourly, with a not-to-exceed ceiling and a mandatory review at 50% of budget where either side can walk. Harder to sell to someone who wants a number. The honest line is that the number they want requires knowing things neither of you knows yet, so you can either find them out in a small paid phase or price the uncertainty into a bigger fixed one. Most people pick the small phase.

What I'd avoid entirely: fixed price for "automate our invoice processing" with no accuracy criterion, no data profile and no named integration. That's not a scope, it's an outcome, and outcomes have no boundary. Be suspicious too of an automation so thin it's really a scheduled script with a model call in it, because those get sold at automation prices and delivered as expensive cron jobs.

What I Actually Do Now

Scoping AI automation projects now comes down, for me, to six questions answered in writing before a build price exists: what counts as working and how it's measured, what data was profiled and by whom, what exactly it connects to and who supplies access, what's inside the input boundary and what routes to exceptions, who reviews the output and where, and who owns it after handover.

It isn't clever. It's just that each one, left unanswered, is worth somewhere between a week and the entire margin.

I won't pretend this makes projects run to plan. I still get surprised, and the last few surprises are why some of these clauses exist, which is another way of saying I paid for them. What the six questions change is the category of surprise: from something you absorb to something you rescope.

If you're weighing up an AI automation project and want a second opinion on the scope before you sign it, or you'd rather run discovery properly than guess, that's the kind of thing I do. No promise that your data is better than average. It isn't.