The Business Automation Roadmap: From Pilot to Production in 90 Days
Two thirds of automation projects are replacing a previous automation project
The AIIM and Deep Analysis Market Momentum Index for 2025, a survey of more than 600 enterprises, contains a quietly damning statistic: 66% of new intelligent document processing projects are replacing an existing system. Not extending one. Replacing one.
The same survey found 78% of enterprises already running AI in their document processing — while 61% of business processes still involve paper. Plenty of technology, bought repeatedly, and the underlying process largely unchanged.
The pattern is consistent enough to name. Organisations do not fail at automation because the tools are bad. They fail because they picked the wrong process, piloted it in conditions that did not resemble production, and had no agreed definition of what success would look like.
- 66%of new projects replace an existing system
- 78%already run AI in document processing
- 61%of processes still include paper
- 49.2%touchless rate at best-in-class AP teams
Key takeaways
- Choose the process with a scoring matrix, not by whoever complains loudest. Volume, rule-clarity and data quality decide feasibility.
- Simplify before automating. Automating a messy process makes the mess faster and permanent.
- The pilot must include the ugly cases. A pilot run on clean inputs tells you nothing about production.
- Design the exception path first. Even best-in-class accounts payable teams only reach 49.2% touchless — humans stay in the loop by design, not by failure.
- Write the scale-or-stop gate before you start, with a number in it. Otherwise every pilot survives on optimism.
Choosing the first process
The first automation sets the organisation's expectations for every one after it. Choose a process that is boring, frequent and well understood — not the most painful one, which is usually painful precisely because it is full of judgement.
Score candidates out of five on each dimension. Anything below 15 total is a poor first choice.
| Dimension | Score 1 | Score 5 |
|---|---|---|
| Volume | A few times a month | Many times a day |
| Rule clarity | "It depends" | Written rules a new hire could follow |
| Input consistency | Every input differs | Structured or templated |
| Data availability | Data lives in someone's head | Already in a system, queryable |
| Cost of an error | Regulatory or safety impact | Caught and fixed downstream |
| Owner engagement | Nobody owns it | A named owner who wants this |
Score "owner engagement" honestly and weight it heavily. A technically ideal process with a disengaged owner will fail; a merely good process with an owner who wants it to work will succeed. Automation projects are adopted, not installed.
Simplify before you automate
This is the step that separates the third of projects that work from the two thirds that get replaced. Before any tool is chosen:
- Remove steps that exist for historical reasons. Ask why each approval exists. Some will have no current justification.
- Collapse channels. One intake route, not five. This single change often delivers a third of the eventual benefit at no software cost.
- Standardise the inputs you control. A form beats a free-text email; a template beats a scan.
- Write the rules down. If two experienced people disagree about what the rule is, you have found the real project.
Only then does tooling matter. This is exactly the sequence the invoice automation guide follows, and why its phase two — simplify — is the one teams most want to skip.
Designing a pilot that means something
Four rules make a pilot informative rather than reassuring:
- Use real, unfiltered inputs. Take four consecutive weeks of actual work, including the malformed, late and unusual cases. Curated samples produce accuracy figures that evaporate in production.
- Run in parallel, not instead. The existing process keeps running. You are comparing, not gambling.
- Measure three things: straight-through rate, error rate on the automated path, and handling time for exceptions. Not "does it feel faster".
- Write the gate first. "We scale if straight-through exceeds X% with error rate under Y%." Agreed by the process owner before the pilot starts, in writing.
Edge cases and the exception path
Every automation has a population of inputs it cannot handle. The mistake is treating those as defects to be eliminated rather than as a permanent, designed part of the system.
Consider the benchmark: Ardent Partners' 2025 accounts payable research found that even best-in-class teams process only 49.2% of invoices touchlessly, against 23.4% for everyone else. The leaders are not the ones who eliminated human involvement. They are the ones who made the remaining half efficient.
A working exception path has four properties:
- A named owner, not a shared inbox.
- A reason code on every exception, so you can count categories.
- A service-level expectation, so exceptions do not silently age.
- A weekly review that converts recurring exceptions into rules.
Track the exception rate as a trend, not a level. A stable rate is a healthy system. A rising rate almost always means something upstream changed — a supplier altered a template, a team stopped filling in a field — and finding that quickly is worth more than a few points of straight-through processing.
The 90-day plan and its gates
| Phase | Days | Work | Gate to pass |
|---|---|---|---|
| 1 · Select | 1–10 | Score three candidate processes; pick one; name an owner | Score ≥ 15 and an owner who wants it |
| 2 · Baseline | 11–20 | Measure current volume, time, cost, error rate | Numbers everyone agrees are real |
| 3 · Simplify | 21–35 | Remove steps, collapse channels, write the rules down | The manual process is measurably simpler |
| 4 · Build | 36–60 | Automate the happy path plus the exception queue | Runs end to end on real inputs |
| 5 · Parallel | 61–80 | Both processes running; work exceptions daily | Pre-agreed gate met two weeks running |
| 6 · Cut over | 81–90 | Close the old path; publish the numbers | Old path closed, metric reported |
Phase 6 matters more than it looks. Until the old path closes, people use it "just in case" and you run two processes at twice the cost — the same trap described in the paperless business system guide.
Governance without bureaucracy
Small organisations do not need a governance committee, but they do need answers to four questions, written down, before an automation touches customers or money:
- Who owns this when it misbehaves at 4pm on a Friday?
- What data does it touch, where does that data go, and how long is it kept?
- What is the blast radius if it runs wrong for a week before anyone notices?
- How do we switch it off without a code deploy?
Where AI models make or influence decisions, the NIST AI Risk Management Framework is a sound, voluntary structure to borrow from — particularly its insistence that risks be identified in context and measured, not assumed away. You do not need to adopt it wholesale to use its questions.
Scaling to the second and third process
The second automation should reuse the first one's parts: the same intake pattern, the same exception queue mechanics, the same reporting. If it does not, you are not building a capability — you are collecting one-off projects, which is precisely how organisations end up in the 66% replacing their own systems.
Three signals that you are ready for the next one: the first automation ran a full month without intervention; the exception rate is stable and understood; and someone other than the person who built it has maintained it. Missing any of the three, consolidate before extending.
Frequently asked questions
How do we know a process is ready to automate?
Score it on volume, rule clarity, input consistency, data availability, cost of error and owner engagement. High volume with clear rules and consistent inputs is the sweet spot; low volume with contested rules is where projects die. The single strongest predictor in practice is whether the process owner actively wants the change, because automation is adopted rather than installed — a reluctant owner will find reasons the exceptions are unworkable.
Should we run a proof of concept first?
Run a pilot on real inputs rather than a proof of concept on curated ones. A demonstration that the technology can work in ideal conditions answers a question you did not need answered; the useful question is what your straight-through rate will be on your actual messy inputs. Keep the existing process running in parallel, and decide in advance what result would make you stop.
What straight-through rate should we expect?
It depends heavily on input quality, but the accounts payable benchmarks are a useful anchor: best-in-class organisations reach 49.2% touchless and the wider average sits around 32.6%. Treat anything promising 90%+ with suspicion unless your inputs are already fully structured. Plan for a permanent human path and make it efficient rather than treating it as a temporary embarrassment.
How long before automation pays for itself?
Cycle-time improvements usually appear within weeks of cut-over, because queues stop forming. Cost savings move more slowly, since they depend on staff time genuinely being redeployed rather than simply freed in principle. A realistic expectation for a single well-chosen process is a visible cycle-time gain inside 90 days and a defensible cost figure at around six months. Anything faster is usually a measurement artefact.
What is the most common reason automation projects fail?
Automating a process that was never simplified. The AIIM research finding that 66% of new document-processing projects are replacements is the visible symptom: organisations buy a tool, wrap it around an undefined process, get a disappointing result, and conclude the tool was wrong. The second most common cause is having no agreed success criterion, which means the pilot never formally fails and never formally succeeds — it just quietly continues.
Sources
- AIIM & Deep Analysis, Market Momentum Index: Intelligent Document Processing Survey 2025 — 600+ enterprises. Source of the 66%, 78% and 61% figures.
- Ardent Partners, Accounts Payable Metrics that Matter in 2025 — source of the 49.2% and 32.6% touchless processing benchmarks.
- NIST, AI Risk Management Framework — voluntary framework for identifying and managing AI risk in context.
Keep reading
All articles →
Nonprofit Process Automation: The Nine Workflows to Automate First
41% of nonprofit leaders name lack of process automation as a top operational problem, and 58% say staffing is their biggest external challenge. Those are the same problem. Here ar
Aug 12, 2026 · 11 min read
How to Build a Paperless Business System That Actually Sticks
Most paperless projects stall because they scan paper instead of removing it. Here is the five-layer system that replaces the paper, the retention rules that keep it legal, and a 9
Aug 12, 2026 · 11 min read
How to Stop a Support Chatbot From Making Things Up
The demo always works. Then a customer asks something the docs don't cover, and the bot answers anyway. Here is the grounding setup — retrieval, refusal, citations, testing — that
Aug 15, 2026 · 9 min read