Why nearly half of all automation projects fail
The numbers are strikingly consistent across independent sources. Gartner observes that nearly half of all RPA projects fail to scale – the automation works fine in the pilot, then breaks down once real-world processes change in ways it wasn't built for. EY puts the share of RPA projects that fail outright at up to 50 percent. Deloitte attributes 37 percent of the cases it examined to poor change management, and Forrester finds concrete scalability problems in 35 percent of implementations.
Even among large enterprises there's a gap between trying automation and realizing real value from it: McKinsey reports that roughly two-thirds of surveyed companies now use automation in at least one business function – yet only a small group of about 6 percent extracts value that measurably shows up in the numbers. Adoption has become normal. Realizing value hasn't.
The obvious explanation would be bad software, the wrong vendor, immature technology. But that doesn't match what we see in our own projects – the tools involved almost always do exactly what they're supposed to. The real pattern lies elsewhere, and it becomes visible once you place three seemingly separate findings side by side.
The automation half-life: a factor missing from most ROI math
Most business cases do the following math: time saved per instance, multiplied by frequency, multiplied by hourly cost – and there's your payback period. The problem with that math isn't that it's wrong. It's that it only holds for a single day: launch day. Three independent data points show why that value doesn't stay constant afterward – it shrinks.
- Maintenance isn't the exception, it's priced-in reality: industry analyses put it at 10 to 40 percent of the original implementation cost per year, depending on how much the automation depends on interfaces, formats or third-party systems that can change. This cost almost never shows up in the initial ROI math at all.
- Value erodes without active upkeep: without an owner who tracks process changes, analyses show the realized benefit of an automation dropping by 25 to 40 percent within 18 months – not because the software gets worse, but because reality keeps moving around it while the automation stands still.
- Exceptions don't grow linearly, they jump: every automation is built for a defined range of cases. Inside that range it runs reliably. Outside it, it breaks – abruptly and without warning, not gradually degrading the way a tired human would.
Layer these three points on top of each other and a pattern emerges that none of the studies names individually, but that's practically observable: an automation's value is highest on launch day – and declines afterward unless someone actively counteracts it. Call it the automation half-life. The practical consequence is simple: justifying an automation purely on its day-1 value is calculating yourself rich. Realistically, year-two value is lower than year one – unless maintenance and process upkeep are planned in from the start, not added later.
The Bainbridge effect – why exceptions get more expensive over time, not cheaper
The second building block of this framework doesn't come from a recent market study but from a 1983 paper by cognitive psychologist Lisanne Bainbridge titled "Ironies of Automation" – one of the most-cited texts in automation research, yet one that almost never comes up in business discussions about process automation. Bainbridge's core observation: automate the routine part of a process, and the people involved are left with exactly the hardest task – the rare exception that requires intervention. At the same time, automation strips them of the ongoing practice they'd need to handle that exception well.
Applied to business processes: if an automation handles 95 percent of standard cases, the team only works the remaining 5 percent – the most complex, most ambiguous cases, the ones they have the least practice with. This is exactly where the loop closes back to the automation half-life: when the process changes (a new regulation, a new supplier, a new pricing model), more cases land in that exception bucket – handled by a team that's increasingly out of practice at handling it. This is the mechanism behind the Deloitte figure cited earlier, where poor change management is the most commonly named failure cause: it isn't the automation that fails first, it's the human capacity to fill the gaps left around it.
The scoring framework: four factors that show whether a process is genuinely worth it
This framework has a practical consequence: time savings alone is the wrong first filter for "what do we automate first?". Four factors together determine whether an automation holds its value or loses it.
- Frequency: how often does the task run per week? Without sufficient volume, even a cheap automation never pays back – regardless of every other factor.
- Rule stability: do the underlying rules (pricing logic, regulations, forms) change rarely or constantly? Unstable rules are the main driver of the erosion described above – here it pays to stabilize the rules first, then automate.
- Exception rate: how often does a case deviate from the standard path? A well-built automation creates disproportionate value at a high but well-understood exception rate – a poorly built one produces exactly the Bainbridge effect above at that same exception rate.
- Owner: is there a specific person who monitors, adjusts and takes responsibility for exceptions after launch? Without this role, erosion within 18 months is practically baked in – no matter how good the original build was.
The AI Opportunity Scan and the more in-depth Readiness Assessment on this site map exactly these four factors in a structured way – not to spit out a single number, but to make visible where a specific process actually stands on this grid before money goes into building anything.
The costs missing from most calculations
Beyond maintenance and erosion, two more line items are almost always underestimated in early ROI math.
- Exception handling doesn't scale linearly: an automation with twice the exception rate causes more than twice the manual residual effort in practice – because exception cases tend to be more complex than the average case the automation handles. Realistic projections therefore use 70 to 85 percent time savings for normal processes and reserve the often-cited 90-plus percent figures for genuinely highly standardized workflows with very low exception rates.
- Part of the value comes not from cost cutting but from more business: a Forrester report – commissioned by automation vendor SS&C Blue Prism, so worth reading with that in mind – found that roughly three-quarters of measured automation value in the cases studied came from revenue growth, not hours saved. That matches our own experience in practice: faster response time to customers often creates more value than the raw labor cost saved – yet classic hourly-rate math rarely counts that effect at all.
A realistic roadmap
This framework doesn't argue for automating less – it argues for calculating more honestly and planning upkeep in from day one.
- Apply the scoring framework first: frequency, rule stability, exception rate and an owner – before talking tools or budget.
- Budget for maintenance from day one: 10 to 40 percent of implementation cost per year as a fixed line item, not a later surprise.
- Name a specific person who owns the automation after launch – not "the team", a name.
- Check the real benefit after 6, 12 and 18 months, instead of just carrying forward the number from the original business case.
- If the underlying rules are unstable, stabilize the process first, then automate – automating a constantly changing rule just produces errors faster.
Automation still pays off – the failure rates cited here aren't an argument against it, they're an argument against a particular way of planning it. Whoever factors in the automation half-life from the start doesn't end up in the 30 to 50 percent that get disappointed – they end up in the small group that actually realizes the full value.