Automation Anxiety: RPA Promised a Digital Workforce and Delivered a Mirror
A tool that automates a broken process does not fix it; it makes the break permanent, faster, and harder to see.
The digital workforce that never sleeps — except at night
The dashboard mounted in the automation centre of excellence shows a reassuring number: one hundred and twenty bots in production, running around the clock, tireless. The steering committee likes that number. It has appeared in three board packs and, once, in the annual report, usually within a sentence of the phrase digital workforce. What the dashboard does not show is the team of six people who arrive before seven each morning to check which of those tireless workers fell over during the night, and to coax the important ones back into service before the business day opens.
I have watched a version of this scene play out in more organisations than I can easily count, and the details rhyme every time. A bot built to lift supplier invoices from a mailbox, key them into the finance system, and match them to purchase orders. A quiet change to an email template upstream, or a new field added to a supplier portal, or a service pack applied to the ERP over a weekend. Monday morning the bot is still “running” — the monitoring says green — but it has been dutifully entering blanks, or matching to the wrong line, for two days. Nobody notices until a supplier chases a payment. The centre of excellence adds an exception handler, writes a runbook, and moves on. The green light was always the most dangerous thing on the screen.
We were promised something different. The pitch for robotic process automation, at its height, was a workforce you could provision like software: spin up a hundred digital workers over a weekend, each one cheaper and more reliable than the human it relieved, each one scaling without hiring, holiday, or attrition. It was a beautiful promise, and it arrived at exactly the moment organisations most wanted to hear it — cost pressure meeting a technology that seemed to convert directly into headcount saved. The promise was not a lie. But it described a destination most of us never reached, and it quietly mis-sold the thing RPA is actually good for.
What the bots actually found
Here is the claim I want to argue plainly, because the industry has spent five years talking around it. RPA did not give most organisations a digital workforce. It gave them a mirror. And what the mirror showed — the real condition of their processes, their data, and their operating model — turned out to be worth far more than the labour the bots saved, and to be far less comfortable to look at.
You learn this the moment you try to automate a process rather than describe one. The process map, lovingly maintained by the improvement team, has fourteen steps. The work, as actually done, has closer to two hundred — because Sandra in accounts payable knows that invoices from three particular suppliers always come in the wrong format and have to be handled by hand, and because the “standard” credit check is skipped whenever sales escalates, and because a whole class of transactions routes through a spreadsheet nobody will admit exists. None of this is in the map. All of it is in the work. A human absorbs it without thinking. A bot cannot. To automate the process you must first see it, completely, exceptions and all — and most organisations had never once seen their own processes at that resolution.
That is the uncomfortable gift. The bot is a pitiless documentation exercise. It cannot proceed on tacit knowledge, cannot use judgement, cannot quietly correct an upstream mistake the way a person does forty times a day without mentioning it. Every one of those silent human corrections becomes a visible exception the moment you try to hand the task to a machine. Automation does not reward good processes so much as it exposes bad ones, in daylight, with a price tag attached.
The organisations that got the most from automation were rarely the ones with the best technology. They were the ones willing to treat what the bots revealed as the real finding — and to fix the process rather than paper over it with another exception handler.
This is why the anxiety around RPA was always slightly misdirected. The public worry was about robots taking jobs. The private worry, in every operations leadership team I sat with, was quieter and sharper: if a bot can be taught to do this, why did we ever have twelve people doing it — and what does that say about how we run the place? The anxiety was never really about the robots. It was about what they made visible.
The maintenance tax nobody costed
The business case is where the mirror is least flattering. Pilots are seductive because they are chosen to be: a single, stable, high-volume process, a clean run, a headline number. The trouble begins at scale, and it begins with a cost almost no early business case included — maintenance.
A bot is not an employee; it is a tightly coupled dependency on every system it touches. It has no tolerance for change and no ability to adapt to it. Every interface it reaches across is a promise that nothing upstream will move, and in a live enterprise something upstream is always moving. So the digital workforce needs a support function — developers to rebuild bots when applications change, a monitoring capability to catch silent failures, a governance layer to stop citizen-built automations multiplying in the dark. That function is real, it is skilled, and it is permanent. It is the tax on the whole estate, and it grows with every bot you add.
Consider the shape of it, drawn from a composite that will be familiar to anyone who lived through a scaled programme:
| Measure | Pilot business case | Reality at two years |
|---|---|---|
| Processes automated | 1 flagship | 40 across three functions |
| Headline FTE “saved” | 12 | 12 (still quoted) |
| Support team stood up | 0 | 4 (developers, monitoring, governance) |
| Bots requiring rework each quarter | assumed near zero | roughly a third of the estate |
| Net FTE benefit, honestly counted | 12 | closer to 3 |
Nothing in that table is a failure of the technology. The bots did exactly what they were built to do. The failure was one of framing: a capital-project mindset applied to what is really an operating commitment, a one-off saving booked against a recurring cost. The savings were banked and celebrated in year one; the maintenance crept in quietly across years two and three, funded from a different budget line, so the two never met on the same page. The programme looked like a triumph and a disappointment at the same time, which is precisely what you would expect from a number that was only ever half-counted.
“A bot is not a worker you have hired. It is a dependency you have taken on — and dependencies do not take holidays, but they do break every time something they lean on moves.”
“But it paid for itself” — the strongest defence, and its limit
I want to take the counter-argument seriously, because it is a good one and it is often made by people who were in the room. It runs like this: RPA delivered real, measurable value — millions of transactions processed, tens of thousands of hours genuinely returned, paybacks inside a year that few technology investments can match. It was never sold as permanent architecture; it was always a bridge — a fast, cheap way to relieve a pain point while the proper system change worked its way through a multi-year roadmap. Judged as a bridge, it did its job. Demanding that it also transform the enterprise is moving the goalposts.
That defence is largely right, and I would not argue with it on its own terms. For a narrow, stable, high-volume, rules-based task — the kind that sits between two systems that will not be integrated for three years — RPA was and is a sensible, even excellent, choice. Hours were returned. Backlogs cleared. People were freed from genuinely deadening work. Where the claim was modest, it held.
The limit is what happened to the bridge. A bridge is supposed to be temporary, and almost none of them were. The “proper” integration slipped, as integrations do; the roadmap was re-planned; the bot that was meant to last eighteen months is still load-bearing at four years, quietly holding up a process everyone has forgotten is held up by tape. The modest, honest, tactical case for RPA was sound. What undid it was that the tactical solution became permanent infrastructure without ever being funded, governed, or documented as such. We did not over-buy the bridge. We under-planned for the day it stopped being one — and then we built forty more beside it.
What automation is really for
So here is where I land, five years into watching this wave rise and settle. The value of robotic process automation was never mainly the labour it displaced. It was the diagnosis it forced. Point a bot at a process and you learn, in a way no maturity assessment or process-mining slide ever quite delivers, exactly how your organisation actually works — where the tacit knowledge lives, which controls are theatre, how far the documented process has drifted from the real one, and what it truly costs to keep the lights on.
The organisations that will carry something forward from this era are not the ones with the largest bot estates. They are the ones that treated automation as a lens: that used the discipline of “make it machine-executable” to finally see, and then fix, the processes underneath — and automated the good version rather than embalming the bad one. Those that did the opposite, that raced to a bot count and reported the gross saving while the net quietly eroded, have mostly built themselves a fragile second estate to maintain, and learned less than they think.
There is a further wave of automation coming — the vendors are already selling “intelligent” and “cognitive” capabilities, machines that read documents, weigh evidence, and handle the very exceptions today’s bots choke on. Whether that wave keeps its promises is not yet knowable from here, and I would be wary of anyone who claims it is. But one lesson from this one will transfer whatever comes next, and it is the whole of my argument: a tool that automates a broken process does not fix it; it makes the break permanent, faster, and harder to see. Get the process honest first. The machine, whatever machine it turns out to be, is the easy part.