Building
Where AI automation actually pays off
Most automation pilots never reach production. The ones that do share an unglamorous pattern, and it is the opposite of what gets demonstrated at conferences.
7 min read
There is a large gap between what AI automation is demonstrated doing and what it is measured doing inside real businesses. The demonstrations are impressive and unrepresentative.
~95%
Of automation pilots that never reach production
20%
Share of companies capturing three quarters of the economic gains
Baseline
The step skipped by most failed projects
Why most of them fail
The single most common cause is not technical. Projects fail because nobody established what the current process actually costs before replacing it. Without that baseline there is no way to tell whether the automation helped, no way to justify continuing, and no way to know when it quietly stopped working.
The second cause is choosing the wrong process. Automation is usually pointed at whatever is most visibly annoying, which is often the thing that happens rarely and requires judgment — the worst possible profile. Low volume and high complexity is where automation reliably loses.
The processes worth automating are boring, frequent, and measurable. Almost nobody demos those.
What actually works
The engagements that pay back share a shape: high volume, low variation, and a cost per unit that can be counted before and after.
- Moving data between systems that do not talk
- Someone re-typing the same information into a second tool. Unglamorous, constant, and completely mechanical — the highest-confidence automation available to most businesses.
- Sorting and routing what arrives
- Inbox triage, support ticket routing, enquiry classification. High volume, repetitive judgment, and a human still owns the decision at the end.
- Pulling structure out of documents
- Invoices, orders, forms. This is where language models genuinely outperform the rule-based tools that came before them, because the input is messy in ways rules never anticipated.
- Reports someone builds by hand every week
- If a person assembles the same numbers on the same day every week, that is a defined process with a known cost and an obvious replacement.
- First-line customer answers
- Worth it above a real volume of repeated questions, and only where handing off to a person is immediate and obvious. Below that volume it costs more to maintain than it saves.
The order that works
- 01
Count what it costs today
How often it happens, how long it takes, who does it. This is the step that gets skipped, and skipping it is the strongest single predictor of failure.
- 02
Pick the highest volume, lowest variation task
Not the most irritating one. Frequency times unit cost is the number that decides, and it is rarely the task people complain about most.
- 03
Automate the mechanical part, keep the decision
The gathering, sorting, and preparing can be automated without handing over the judgment. Most of the saving is in the preparation anyway.
- 04
Ship it with a fallback
A broken automation must degrade into the manual process rather than into a stopped business. Rolling out gradually with a way back is not caution, it is design.
- 05
Measure against the baseline, then continue
Compare to the number from step one. If it did not move, stop and pick something else rather than adding features to a thing that is not working.
This is the whole of how the automation work is scoped.
How Automate worksFollow-up
Questions this raises.
- What should we automate first?
- Whatever happens most often with the least variation, not whatever is most irritating. Frequency multiplied by unit cost decides, and the winner is usually something dull: data moved between systems, enquiries sorted and routed, or a report someone rebuilds by hand every week.
- Do we need AI, or is ordinary automation enough?
- Ordinary automation is often enough, and it is cheaper and more reliable. AI earns its place where the input is messy in ways rules cannot anticipate — reading documents that arrive in twenty layouts, classifying free text, drafting. Where the rules are knowable, plain integration wins.
- Why do so many automation projects fail?
- Most commonly because nobody measured what the process cost before replacing it. Without that baseline there is no way to show the change helped, no basis for continuing, and no way to notice when it quietly stops working.
- Can we automate a process that changes often?
- Usually not worth it yet. Automation encodes a process as it currently stands, so one that is still being redesigned will need rebuilding as fast as it is built. Settle the process first, then automate the version you intend to keep.