The vendor delivered thirty bots, ran the go-live, invoiced the final milestone, and stopped answering emails around week six. That was last October. This morning the Operations Director found a support ticket that had been open eleven days, went looking for the person who understood the bot logic, and discovered that person had been a contractor who rolled off in March.
Thirty bots. No documentation worth the name. No owner. No monitoring. Nobody in the building who can say with confidence which of those thirty ran successfully yesterday.
If that is roughly your position, then how to recover from a failed RPA implementation is the only automation question that matters right now, and the advice you are about to get from most of the market will be wrong in a specific and expensive way.
Here is our take, and it is not the commercially convenient one: recovery is the wrong word for what you need. You do not need thirty bots rescued. You need somewhere between six and ten of them running properly, and the other twenty switched off. The industry sells recovery as salvage, because salvage sounds like protecting your investment. Salvage is what keeps you stuck.
The sunk cost is already gone, and pretending otherwise is what traps you
There is a conversation that happens in almost every recovery engagement, usually in week two, usually with a CFO in the room.
We present the audit. Of the thirty automations, eight are running reliably and delivering real transaction volume. Six are running but processing so little that the maintenance cost exceeds the benefit. Nine are broken in ways nobody noticed. Seven are duplicates, abandoned experiments, or automations built for a process that changed a year ago.
Then someone says: but we paid for thirty.
You did. That money is spent, and it is spent whether you maintain twenty-two automations that do not earn their keep or switch them off this quarter. The original invoice is not an argument for anything. It is history. The only live question is what the estate should look like going forward, and the answer is almost always much smaller than what you currently own.
This is the part that separates a genuine recovery from a vendor extending your original mistake. Every bot retained is a permanent maintenance liability. Keeping a bot that handles forty transactions a month, because it cost money to build, means paying to monitor and repair it forever in exchange for almost nothing. Multiply that across twenty automations and you have manufactured the exact cost problem the program was meant to solve.
A smaller, governed estate beats a large, fragile one on every measure that matters. Reliability, cost to run, and the credibility of the next business case you take to the board.
Learn how PAteam runs managed RPA operations.
Your program did not fail because RPA is bad. It failed because bot count was the KPI
Look at how the original program was governed and the failure becomes almost inevitable in hindsight.
The business case was approved on a number of processes automated. The vendor was paid against a delivery schedule measured in bots shipped. The steering committee reviewed a slide each month showing cumulative automations live, and that line went reliably up. Everyone involved was incentivised to build. Nobody was incentivised, funded, or held accountable for whether last quarter’s bots still worked.
So the estate grew and the reliability of it quietly went the other way, and because the reporting measured build rather than run, the divergence was invisible until something visible broke.
This is why so many programs stall at the point of scaling. Building a bot is a project. Running a bot is an operation. Those are genuinely different disciplines with different funding models, different skills, and different rhythms, and almost every failed implementation was scoped, priced, and staffed entirely as the first one.
Your previous vendor built you a fleet of thirty vans and handed over thirty sets of keys. What nobody bought was the depot, the service schedule, the dispatcher, or the mechanic. The vans were fine on delivery. Nine months of unmaintained running is what put them where they are.
Recovery, honestly described, is mostly about building the depot and admitting you never needed thirty vans.
Audit first, and expect the audit to be uncomfortable
The most common way recovery engagements fail is that somebody starts fixing bots in week one. It feels productive. It is almost entirely wasted, because you cannot know which automations deserve repair until you know what the estate actually does.
So the first move is a proper inventory, and it takes two to three weeks for an estate of this size. Not a spreadsheet review. Actual transaction data.
For every automation we want four things. What volume is it genuinely processing, measured against what the business case assumed. What is in its exception log, and has anyone read that log in the last ninety days. What does it depend on, and which of those dependencies have changed since it was built. And who, by name, is meant to own it.
That last question is the one that produces silence in the room.
The output is a decision, not a report. Retain and stabilise. Decommission. Or rebuild properly, because the process underneath it is sound but the automation was not. In our experience a large minority of a neglected estate lands in the decommission column, and clients find that number harder to accept than any technical finding in the audit.
It is also the finding that saves the most money.
What we actually rebuild, and why the bots come last
Once the estate is understood, the sequence runs in an order that feels counterintuitive to most operations leaders, because the automations are the last thing we touch.
We start with the run model. Monitoring that tells you bot health without anyone opening a spreadsheet. Alert thresholds that fire before a business user notices missing output rather than after. An exception queue with a named person reading it daily and an SLA on response. A defined escalation path for a 2am failure. Ownership assigned to individuals, not to a team.
Then we separate build from run, formally and in the budget. As long as the same people carry both, run loses to build every single time, because build is visible and run only becomes visible when it fails. That single structural change does more for estate stability than any amount of code quality work.
Only then do we touch the automations, triaged strictly by business consequence. Compliance-exposed first. High volume next. Everything else after. And for each retained bot, the work is usually not repairing what broke, it is adding the exception handling that was never designed in the first place, because the original build only ever handled the path where everything goes right.
Then the handover, which is where your previous vendor genuinely failed you. Runbooks, monitoring access, incident procedure, and enough training that your team operates the estate confidently within about ninety days, with us as the escalation layer rather than the only people who understand it. If a recovery leaves you dependent on the recovery partner, it has reproduced the original problem with a different logo.
Across recovery engagements, PAteam typically reaches a stable governed estate within 90 days and ROI on the recovery investment inside six months. Our Robotic Operations Centre provides the ongoing monitoring layer that was missing, which is the specific reason the second attempt holds when the first did not.
At Kirkendall Dwyer, a legal operations client, our digital workers took document processing from five to eight minutes down to one minute. The number we are prouder of is what happened afterwards: the estate scaled to support 117% caseload growth on 43.8% labour cost growth, because it was governed from the start.
See how PAteam structures RPA recovery and managed operations.
Our honest take: some of those bots should not be rebuilt as bots at all
This is the part that costs us revenue to say, so read it as intended.
A number of the automations in your estate were built between 2019 and 2023 to move data between systems, read documents, and make simple routing decisions based on rules. That was the sensible technology choice at the time. For a meaningful portion of that work, it is no longer the sensible choice, and rebuilding those bots exactly as they were is nostalgia dressed up as recovery.
Document handling with variable formats, classification work, anything where the rules were always slightly wrong and a human quietly corrected the output: that work has moved. Rebuilding it as brittle UI automation means paying to maintain something that will break on the next interface change, when a different approach would not break at all.
The opposite caution applies too, and it is just as important. Plenty of what those bots do is high volume, deterministic, and fully rule-bound, and for that work RPA remains the right, cheap, boringly reliable answer. Replacing a functioning rules-based bot with something probabilistic because AI is the current conversation is a different and equally expensive mistake.
The judgment call is per process, and it is exactly the judgment your previous vendor was not paid to make. We will make it in the Discover phase, and sometimes the recommendation reduces the size of our own engagement. That is the trade. We would rather run a smaller programme that survives than a larger one you call us back about in two years.
Frequently Asked Questions
How do we tell the difference between a failed implementation and a normal maintenance backlog?
Ask whether an operating model exists. If bots break but there is a named owner, a live health dashboard, and an incident process, you have a backlog and a resourcing conversation. If nobody can tell you which bots ran successfully yesterday without manual checking, and no one has read the exception logs in months, the implementation failed regardless of how many automations are technically deployed. Bot count is not evidence of anything.
Do we need to change RPA platform to fix this?
Very rarely. In the estates we audit, the platform is almost never the binding constraint, and replatforming costs you the full implementation spend again plus a year or more of delay while doing nothing about the governance gap that caused the failure. The new platform then fails the same way. Fix the operating model, run the estate for two quarters, and reassess the platform only if a real capability gap remains.
What does a recovery engagement cost relative to the original programme?
Scope it as a percentage of your original spend rather than a fixed figure, because it turns entirely on estate size, documentation quality, and how much survives the audit. What is more useful for your board paper is the comparison: replatforming means paying the full build cost again plus twelve to eighteen months, and abandonment writes off the whole original investment permanently. Recovery is reliably the cheapest route to the value the original case promised. Ask us for a fixed-scope audit price and you will have a real number in three weeks instead of a range.
Our previous vendor left almost no documentation. Is the estate salvageable?
Largely, yes, but reverse-engineering undocumented automations adds real time, roughly one to two weeks per fifteen to twenty bots depending on complexity. The uncomfortable part is that for some of them the reconstruction effort exceeds anything the bot delivers, and the correct answer is to switch it off. Discovering that is not a failure of the audit. It is the most valuable thing the audit produces.
How do we avoid ending up here again with the next partner?
Three questions, asked before you sign. How long do you train developers before they touch client production work. What exactly does your run model look like after go-live, contractually. And can you name a client estate you still operate today, with current volume numbers. PAteam trains RPA developers for six months against a market norm of one to three, and our Robotic Operations Centre exists specifically because the absence of that run layer is what produced your current position. A partner whose contract ends at go-live is selling you the same shape of problem.
What to take from this
Stop trying to save thirty bots. The money is already spent and every automation you retain is a permanent maintenance liability, so the goal is the smallest estate that delivers real volume, properly run. Ten reliable automations will beat thirty fragile ones on cost, credibility, and every operational measure you report upward.
The programme failed because it was measured on bots shipped and funded as a project, with nothing paying for the run. Fix that and the second attempt holds. Skip it and you will be here again with a different vendor and a larger write-off.
And be willing to hear that some of those processes should not go back to being bots at all. That call is per process, it cuts in both directions, and it is the judgment nobody was paid to make the first time.
