There is a specific moment where AI automation projects go wrong, and it is almost never the moment people expect.
It is not the build. It is not the client. It is the forty seconds on a call where someone says so roughly what are we looking at? and you say a number out loud before you have any idea what you have agreed to. Everything painful that happens over the following six weeks was decided in those forty seconds.
This post sits between two others in this series. The discovery call is where you collect the evidence. The proposal is where you present the offer. What follows is the part in between that nobody writes down: turning what you heard into a number and a boundary you can actually live inside.
Automation estimates fail differently from software estimates
Ordinary software estimates are wrong because building takes longer than you thought. That failure is boring, well documented, and roughly symmetrical - you miss by 40 percent, you eat it, you move on.
Automation estimates fail asymmetrically, because you are not estimating your own work. You are making a claim about someone else's data, someone else's process, and someone else's tolerance for a system that is right most of the time.
Three things are hiding in every automation quote:
- Their data is worse than they described. Universally. Not because clients lie, but because the person describing the process has not looked at the raw inputs in two years. They are describing the version in their head.
- The process they described is the happy path. The exceptions are handled by a person who has been doing it so long they no longer experience the exceptions as decisions.
- The definition of working is unset. On a normal build, working means the tests pass. On an AI build, working means an accuracy rate somebody has to agree to, and if nobody names that number before you start, it defaults to perfect.
Every over-run I have seen described traces back to one of those three, and all three are visible before you quote if you know what to ask.
The $80 Report — free
An AI was given $80 and told to make money. 156 days later: $5.00. This is all 7 side-income methods it tested, what each one actually returned, the effort each cost, and the four that returned nothing.
Sent instantly, no cost. You’ll also get one email a week on what we tried and what it made. Unsubscribe any time.
Scope the workflow, not the request
Clients do not bring you workflows. They bring you a sentence: we want to automate our invoice processing, can AI handle our inbound leads, we spend too long on reports. That sentence is a symptom, not a specification, and quoting against it is quoting against fog.
The move is to make them walk it. Not describe it - walk it, in the present tense, with the actual screen open:
Show me the last one you did. Where does it arrive? What do you open first? Then what? What made you pause there? What happens when it is not like that one?
Twenty minutes of that reliably surfaces things that never appear in a summary. A field that gets copied into a second system nobody mentioned. A rule that exists only in one person's judgement. A step that turns out to be two steps because a colleague checks something on Fridays. An approval that has to happen before anything is allowed to go out.
You are looking for the shape of the work, and specifically for the boundary of it. The single most valuable output of scoping is not what is in - it is the line where the project stops.
The five questions that collapse an estimate
If you take nothing else from this post, take these. Each one has, in practice, changed a quote by a factor of two or more.
- How many of these per week, and how bad is the worst week? Volume determines whether this is a script or a system. Fifty a week and four hundred a week are not the same project. Ask for the peak, not the average - the peak is what has to survive.
- How many different formats does this arrive in? One clean template is a weekend. Eleven vendor-specific PDF layouts, three of which are scans, is a month. This is the single biggest driver of variance in document work and it is almost never volunteered.
- Who do I get access from, and how long does that take? The API key, the sandbox account, the read permission on the folder. In organisations of any size this is measured in weeks and gated by someone who has never heard of you. It is not billable and it is not optional, and it belongs on the timeline as an explicit dependency with a name attached.
- What happens today when it goes wrong? This is the exception tail, and it is where the hours live. Ask for the last three weird ones. If they cannot think of any, they are not remembering, so ask the person who actually does the task.
- What accuracy is good enough, and who decides? Push until you get a number and a name. Not it should be accurate. Something closer to 18 out of 20 correct, judged by Sarah in a single session. This is the same acceptance test that later triggers your invoice, which is why getting paid starts here rather than at the end.
Estimate in three layers, because they scale differently
Do not estimate a project. Estimate three things that behave nothing like each other, then add them.
Layer one: the happy path. The clean case, working end to end. This is the part you are good at estimating and the part that feels like the whole job. It is usually 20 to 30 percent of the real total. Estimate it honestly and resist the urge to pad it - the padding belongs in layer two, where it is defensible.
Layer two: the exception tail. Malformed inputs, missing fields, the vendor who sends photographs of paper, the duplicate that must not be processed twice, the case that needs a human. This layer scales with the messiness you found in question two, not with the complexity of the happy path. As a starting heuristic: multiply the happy path by 1.5 for a genuinely clean single-format process, by 2.5 for typical business data, and by 4 or more when you have seen the inputs and they are scans, free text, or anything a human typed under time pressure.
That multiplier is not padding, and it matters that you can say so out loud. Padding is fear priced in. This is a real, nameable body of work - the difference between a demo and a system somebody can leave running unattended. When a client asks why the number is what it is, the exception tail is the answer, and it is a much stronger answer than a vague appeal to complexity.
Layer three: the seam. Everything that is not your code and not your decision. Credentials, environments, their IT policy, the review meeting that takes eleven days to schedule, the security questionnaire, the one integration whose documentation was last updated in 2023. Estimate this in calendar time rather than hours, because that is the unit it actually consumes, and put it on the timeline as dependencies with owners' names next to them. Clients accept this readily when it is visible in advance. They resent it enormously when it appears in week five as an excuse.
What to do about the thing you have never built
There is always one. The integration you have not touched, the document type you have not parsed, the model behaviour you are not sure holds up at their volume.
The wrong responses are the two obvious ones: guess high and lose the deal, or guess low and fund their R&D out of your own weekend.
The right response is to timebox it and get paid for the timebox. A four-hour spike against their real data, quoted as a small paid discovery, answers the question with evidence instead of optimism. You are not building anything - you are running the ugliest twenty inputs they have through a rough version and looking at what falls over.
Two things come out of that, and both are worth more than the fee. You get an estimate grounded in their actual data rather than an idealised version of it. And you find out, cheaply and early, whether this project is one of the ones that should not be taken at all. A spike that fails is a good outcome that cost four hours instead of six weeks - the same logic we apply to killing our own experiments.
It also has a useful side effect on the sales side: the client watches you do real work on their real problem before committing serious money, which is frequently a more persuasive answer to how do I know this will work than anything in the objection-handling playbook.
Turning an estimate into a scope you can defend
An estimate is a number. A scope is a boundary. The number is worthless without the boundary, because without it the number silently becomes a ceiling on an unbounded amount of work.
Three things convert one into the other.
Phase it, and make phase one small. The first phase should be the smallest thing that produces real value and can be demonstrated - one document type, one workflow, one department. Not because clients cannot afford more, but because a delivered phase one is worth more to both of you than an in-progress everything. It proves the approach on their data, it gets money moving early, and it means the second phase is quoted with knowledge instead of assumptions. It is also how you avoid discovering in week six that you priced the whole thing wrong.
Write down what is not included. A short, unemotional list. Historical backfill of the last three years. Anything involving their legacy system. Training their staff beyond one handover session. Changes to the source process itself. This list prevents more disputes than any other paragraph in the document, and the reason is that clients are not trying to get free work - they simply assume that anything adjacent and unmentioned was implied.
Attach a change mechanism, not a change refusal. New requests are healthy. What kills margins is absorbing them silently. Have a one-line standing answer ready: happy to add that, it is roughly this many hours, here is what it does to the date, want me to send a change order? Most extras evaporate once they acquire a price, and the ones that survive are ones the client genuinely values. That is also the on-ramp to the conversation about raising prices with existing clients later on.
The honest part about estimating with AI in the loop
There is a version of this article that would tell you AI makes estimating easier because the build is faster. The build genuinely is faster. That is not the same claim.
What actually happens is that the cheap part gets cheaper and the expensive part stays exactly where it was. Generating the first working version of a workflow now takes hours instead of days. Determining what the workflow should be, what the edge cases are, whether the output is trustworthy, and what happens on the day it is confidently wrong - none of that got faster, and it is now a larger share of the project than it used to be.
Which has a direct consequence for how you quote. If you estimate in build hours, AI tooling will push your quotes steadily downward toward a number that does not cover the work that actually matters, and you will find yourself busier and poorer. The judgement, the verification, and the exception design are the deliverable now. Price those. We have written before about the seven things that break when you automate with AI, and every one of them is a scoping failure wearing a technical costume.
Common questions
Should I give a number on the discovery call?
Give a range with a stated basis, never a figure. Something like: projects of this shape usually land between four and eight thousand - I will confirm once I have seen a sample of the actual documents. This does the two useful things at once. It filters out anyone whose budget is a tenth of that before either of you invests more time, and it establishes that the number depends on evidence you have not yet been given. Refusing to say anything at all reads as evasive and loses deals you wanted.
How do I estimate when I have never done a project like this?
Estimate the first phase only, keep that phase deliberately small, and sell the spike. Your first few projects are partly paid learning and it is healthier to admit that internally than to pretend otherwise and then feel cheated. What you must not do is quote a large fixed price on an unfamiliar problem - that is the specific mistake that turns a first client into a three-month unpaid apprenticeship. The wider version of this is in delivering your first project.
Fixed price or hourly?
Fixed price on anything you have scoped properly, because it rewards you for being fast and clients strongly prefer a known number. Hourly on genuine unknowns and on open-ended advisory work, where a fixed price is just you absorbing their uncertainty for free. The hybrid that works well in practice: fixed price for the phase, hourly for changes outside it. Which model suits which kind of offer is covered in how to price AI products and services.
The client will not tell me their volume or show me sample data. What now?
Treat that as information rather than an obstacle. Sometimes it is confidentiality, which a mutual NDA or a handful of redacted samples resolves in a day. Sometimes it means nobody actually knows the volume, which is itself a finding worth telling them. And sometimes it means the project is not real yet. In every case, the correct response is the same: quote the paid discovery phase, not the project. You cannot responsibly price a system against data you have been refused.
How much should I add for maintenance?
Quote it separately, as a recurring line rather than a buffer inside the build price. Something in the range of 10 to 20 percent of the build cost per year covers model updates, format changes at their vendors, and the drift that affects every automation over time. Presenting it as its own item is more honest, easier to say yes to, and turns into the recurring revenue that makes this business viable at all - the argument made properly in the retainer playbook.
The short version
Make them walk the workflow instead of describing it. Ask for peak volume, format count, access ownership, the last three exceptions, and the accuracy number with a name attached. Estimate the happy path, the exception tail, and the seam as three separate things, because they scale on completely different axes. Timebox anything you have never built and charge for the timebox. Phase it small, write down what is excluded, and price changes cheerfully instead of absorbing them.
None of this makes an estimate correct. Estimates are not a skill you eventually master - they are a claim about a future you do not control. What this does is make an estimate survivable, which is the achievable goal, and it moves the discovery of bad news from week six to week zero, where it is still cheap.
If you want the checklists and templates this business actually runs on rather than a set of principles to reconstruct yourself, they live in the AI Operator's Toolkit.
From the people who ran this experiment: The AI Operator's Toolkit costs $19 at money-lab.app/products. The prompts and templates behind the workflow above — the same ones this site is run with. Refundable for 30 days, no questions asked.