What AI Automation Services Leave Off the Invoice
Search for AI automation services and every result sells the same thing: your repetitive work, done by software, starting next month. The pages differ in logos and industries and not much else. None of them describes the parts of an automation that are not the automation, which is unfortunate, because those parts are what decide whether the thing is still running a year later.
An automation is not a task performed by a model. It is a task, plus a defined route for the cases the task does not cover, plus a named person who answers for a wrong answer, plus something that notices when it quietly stops working. Providers quote the first of those four. Buyers inherit the other three without knowing they bought them.
What gets demoed is the happy path
Every demonstration you will be shown runs on a well behaved example. An invoice in the expected layout, a support ticket phrased the way support tickets are phrased in the deck, a document that contains the field the extractor is looking for. The demo is honest about what it shows. It is silent about proportion.
Proportion is the whole question. If almost every item that arrives looks like the demo, the automation is close to finished when the demo works. If a meaningful share of items arrive in some other shape, the demo represents a small fraction of the project and the rest of it is unbuilt, unquoted and usually undiscussed.
Nobody in your organisation knows that proportion offhand, which is why it does not come up. The person doing the work knows the exceptions exist because they handle them, and they handle them so routinely that when asked to describe the process they describe the ordinary case. This is not evasion. It is what expertise sounds like.
The exception path is most of the work and none of the quote
Once you accept that some items will not fit, the design question is what happens to them, and there are only a few honest answers. The item is set aside for a person. The item is processed anyway with a flag on it. Or the item is processed anyway with nothing on it, which is the answer nobody chooses out loud and many systems arrive at by default.
The first answer is usually right and it has a consequence worth stating plainly: you have not removed the work, you have split it. Somebody now runs a queue of things the system declined. That queue is real work, it is the harder half of the original job because every easy case has been taken out of it, and it needs an owner and a place in somebody's day. An automation that halves the volume and leaves the difficult remainder unassigned has not saved anything yet.
The second answer needs a rule for what a flag obliges anybody to do. A flag that nobody is required to look at is decoration, and a system that flags a large share of its own output has simply relabelled the queue.
Somebody owns the wrong answer
Every automation eventually produces an output that is confidently wrong, and the interesting question is not how often. It is where that output goes next and who is accountable when it lands.
This is a decision about scope rather than about model quality. A wrong answer that stops inside your own team costs a correction. A wrong answer that reaches a customer, a supplier, a regulator or a ledger costs something else entirely, and no amount of accuracy makes the difference between those two cases go away. It is set by what you connected the output to, which is a choice made at design time and rarely revisited.
The version of this that matters most is the write action: the refund issued, the email sent, the record updated, the order placed. Enumerate those before choosing anything else, and decide for each one whether it may fire unattended, requires a person to confirm, or may only ever be proposed. We work through why that axis predicts cost and blast radius better than any taxonomy in a piece on sorting agents by what they may touch.
Nothing tells you when it stops working
Traditional software fails loudly. It throws an error, the page does not load, the job exits non-zero, somebody is paged. An automation built on a language model fails quietly, because the failure mode is a plausible output rather than a crash. It keeps returning answers in the right shape and the answers stop being right.
The causes are ordinary. The upstream form changed and a field moved. A supplier started sending a new document layout. The mix of incoming work shifted with the season. The model behind the API was updated. None of those announce themselves, and none of them will show up in an uptime dashboard, because the system is up.
So an automation needs a way of being checked that does not depend on somebody noticing. The cheap version is a sample: a small set of items pulled at intervals and looked at by a person who did not do the work. The better version is a fixed set of known cases with known correct answers, re-run on a schedule, where a change in the results is the signal. Neither is expensive. Both are almost always missing, and the absence is invisible until the day somebody works out how long the thing has been wrong.
Sort the work by its tail, not by its volume
The obvious way to pick a first automation is to take the highest volume task, and it is the wrong instinct often enough to be worth naming. Volume tells you the size of the prize. It says nothing about whether the prize is reachable.
The property that predicts reachability is the shape of the tail: how much of the incoming work looks like the common case, and how quickly the remainder fragments into cases that share nothing with each other. A high volume task with a long ragged tail will absorb an enormous amount of effort for a partial result. A lower volume task where nearly everything looks alike finishes, stays finished, and teaches you what your organisation is like to automate.
You can measure this without buying anything. Take a batch of real items from the last month, sort them by how they arrived, and count how far down you get before the categories stop repeating. Do this on paper before anybody writes code, and do it on real items rather than on a description of the process, because the description will be of the happy path for the reason given above.
That is a different question from whether a task is a candidate at all, which turns on whether its input is stable, whether its output can be checked and whether its failure mode is tolerable. We set out that earlier sort in what a small business AI consultant actually does, and it is worth running first. The tail question is what you ask about the tasks that already passed it.
What to put in the statement of work
Five items, each of which turns one of the invisible parts above into something written down and therefore something somebody is answerable for.
- The exception path, named: which cases are set aside, who runs that queue, and how long an item may sit in it.
- The write actions, listed, each marked as unattended, confirmed or proposal only.
- The accuracy check: what gets sampled, how often, by whom, and what result triggers a look.
- The running cost, per month, at today's volume and at a volume you might plausibly reach.
- The handover: what you own at the end, and whether somebody other than the author can change it.
A provider who can answer all five in a first conversation is describing a system. A provider who moves to model names and frameworks is describing a demo.
Do the running arithmetic yourself
The build is quoted once and the running cost lasts as long as the system does, which makes it strange that the second number is almost always somebody else's estimate. Hosted models bill on the text going in and the text coming out, priced on separate lines rather than pooled, so the cost of a workflow is decided by how much context each run carries rather than by how clever the task is.
Take one realistic request from the workflow you are considering and put it through the LLM cost calculator at the volume you actually expect, including the retries and the exception cases. It takes a few minutes and it occasionally ends the conversation, which is the point.
If you are earlier than that, the AI readiness assessment walks the same ground a scoping engagement opens with, across data, use cases, skills and infrastructure. It costs nothing, and a result showing that no workflow stands out yet is a genuine answer rather than a failure. It is considerably cheaper to reach that conclusion before signing than after.