Signs Your RPA Implementation Needs Expert Help (Before It Collapses)

Start with what the failure does not look like.

It does not look like an error. There is no red banner, no failed-run alert, no ticket. The scheduler says the job completed. The platform dashboard shows a run-success rate near a hundred percent, and that figure is accurate. The bot started, executed its steps, closed cleanly and logged nothing unusual.

It processed four transactions. Last month it processed nine hundred.

That is the shape of most RPA trouble that reaches a Chief Operating Officer’s desk — Robotic Process Automation, software that drives existing applications the way a person would, clicking through screens and filling fields. The programme is not down. It is quietly doing less than you are paying it to do, and every instrument you built to watch it is reporting green, because you instrumented the bot rather than the work.

So the useful question is not “which of these seven warning signs do I have.” It is narrower and more awkward: when something goes wrong in your automation estate, who finds out first, and how long does it take? Everything expensive follows from the answer.

Who tells you first: the four detection routes, cheapest to worst

Sort your incidents by who raised them. The ordering is a cost ranking, and most estates discover they live in the bottom half.

The distinction between the first two and the last two is the distinction Google’s Site Reliability Engineering team draws between monitoring the internals of a system and testing what a user sees from outside. Their framing is worth stealing precisely: black-box monitoring “is symptom-oriented and represents active—not predicted—problems,” while white-box monitoring, which inspects logs and internal state, “allows detection of imminent problems, failures masked by retries, and so forth” (Google SRE Book, Monitoring Distributed Systems). Most RPA estates have neither. They have platform telemetry, which reports whether the robot ran — not whether the work got done.

The same chapter names the four signals worth watching on any production service: latency, traffic, errors and saturation. Note that traffic — how much demand the system is actually handling — is on that list, and note that a bot processing four transactions instead of nine hundred is a traffic failure with a clean error log. If you monitor only errors, you have covered one signal in four and you have chosen the one your particular failure mode is most likely to evade.

Why the estate gets more fragile the longer it succeeds

The uncomfortable property of RPA is that a bot’s dependencies keep moving after the bot stops changing. A vendor patches a web application and shifts a field. Someone adds a mandatory dropdown to a form. A Citrix session renders at a different resolution. None of this is visible from inside the automation, and none of it appears in a change advisory board paper, because nobody filed a change against your bot.

Google’s SRE authors named this in the context of their own tooling: automation maintained separately from the core system “suffers from ‘bit rot,’ i.e., not changing when the underlying systems change” (Google SRE Book, The Evolution of Automation at Google). They add the sharper point, which applies directly to a monthly or quarterly automation: work “that is crucial but only executed at infrequent intervals and therefore difficult to test is often particularly fragile because of the extended feedback cycle.”

Read that against your own estate. Your highest-risk automations are not your busiest ones. They are the ones that run at period end, where the feedback cycle is a month or a quarter long, and where the first competent observer is the person closing the books.

There is a second compounding effect, and it is organisational rather than technical. A bot built by one developer, documented in that developer’s head, becomes an asset nobody can safely modify once that developer moves on. The estate then splits into automations people will touch and automations people work around. The second category grows.

What the audit evidence actually shows

This is the section where most vendor writing reaches for a statistic about pilot failure rates. Those numbers circulate without denominators, so here are three findings from public audits instead, each with a stated population.

Australia’s national audit office examined fourteen artificial-intelligence models the Australian Taxation Office built and deployed over roughly ten months and assessed how they were monitored in production. For one of the fourteen — seven percent — technical performance metrics had been developed. For ten of the fourteen, seventy-one percent, no monitoring metrics were developed at all. And across all fourteen, the audit office found the agency “did not provide evidence of monitoring the effect of AI models on business outcomes, such as savings to staffing hours, reduced risks, or increased revenue collection” (ANAO, Governance of Artificial Intelligence at the Australian Taxation Office). On benefits realisation the split was: one model with completed closure documentation and an evaluation, eight with closure documentation and no evaluation, five with neither.

That is not a story about a badly run agency. It is a story about the default. Monitoring the business outcome is a separate discipline from monitoring the software, it is nobody’s job by default, and it is the first thing dropped when the build team is measured on throughput.

The measurement gap has a predictable consequence for the numbers you report upwards. The US General Services Administration claimed in its Fiscal Year 2020 financial report that its automation programme had reclaimed more than 240,000 work hours annually. Its inspector general examined the claim and concluded the agency “is not verifying the actual work hours saved with end-users of its bots,” that the 240,000-hour assertion “was inaccurate and unreliable,” and that the agency “is not tracking the costs associated with its bots, which precludes GSA from determining whether the bots are generating cost savings and a return on investment” (GSA OIG, Report A210057/B/5/F24001, 30 November 2023). The headline number survived four years of reporting before anyone checked it against an end user.

A second audit of the same programme found the decommissioning gap. The agency “did not establish an access removal process for decommissioned bots, resulting in prolonged, unnecessary access that placed GSA systems and data at risk of exposure.” It also found something more instructive about how these programmes drift: where the programme did not comply with its own security requirements, “instead of addressing these issues, RPA program management simply removed or modified the requirements” (GSA OIG, Report A230020/B/T/F24004, 6 August 2024).

That last sentence is the one to carry into your next steering meeting. A programme under delivery pressure does not usually fail its controls. It amends them.

The arithmetic of how long you wait

Here is the part that nobody costs, and it is the part that decides the bill.

If a failure is silent, it runs undetected until something looks. If the only thing that looks is a periodic check, then the average failure runs for roughly half the interval before discovery, plus however long triage takes. Lengthen the interval and you spend less on checking and more on damage. Shorten it and you flip that. There is a minimum in between, and it is computable.

The model below is illustrative. It uses round figures to show the shape of the trade-off, not to describe your estate. Substitute your own numbers and it will move.

Assume sixty automated processes; on average one silent failure per process every two years; roughly €240 of rework and correction for each day a failure runs undetected; €45 to verify one process once, meaning a human comparing actual output against expected output rather than glancing at a dashboard; and two days of triage lag once a check raises something.

Annual verification spend falls as the interval lengthens. Expected damage rises linearly with it. Total annual cost, as the interval varies:

• Weekly checks, every 7 days: verification €140,785.71, damage €39,600, total €180,385.71
• Every 14 days: verification €70,392.86, damage €64,800, total €135,192.86
• Every 16 days: verification €61,593.75, damage €72,000, total €133,593.75
• Every 21 days: verification €46,928.57, damage €90,000, total €136,928.57
• Monthly, every 30 days: verification €32,850, damage €122,400, total €155,250
• Every 60 days: verification €16,425, damage €230,400, total €246,825
• Quarterly, every 90 days: verification €10,950, damage €338,400, total €349,350

The minimum sits at 16.55 days, at a total annual cost of €133,526.82. Three things about that result are worth more than the number itself.

Weekly checking is the expensive mistake, not quarterly. Weekly costs €46,858.89 more than the optimum. Monthly costs €21,723.18 more. Over-checking overshoots by 2.157 times as much as under-checking does, in this configuration. The instinct when a silent failure is discovered is to check everything more often, and that instinct converts a damage problem into a labour problem that is larger than the one it replaced.

Fortnightly is close enough. A fourteen-day interval lands within 1.25% of the true optimum. You do not need to hit 16.55 days, and you should not build a process around a decimal. Round to something a team can actually hold.

The optimum does not depend on the size of your estate. This is the counter-intuitive part. The optimal interval is the square root of 730 times the cost of one check, divided by the annual failure rate times the daily loss. The number of processes appears in both the checking term and the damage term, so it cancels out entirely. Ten processes, sixty, three hundred, two thousand — the answer is 16.55 days in all four cases. What changes is the total bill, not the correct interval. An estate of two thousand bots does not need to be checked more often than an estate of ten; it needs to be checked at the same cadence, at proportionally more cost. Programmes that stretch their interval as they scale have the relationship exactly backwards.

Three breakeven points, each solved and substituted back:

• Drive the cost of one verification down to €32.22 — through better instrumentation, a reconciliation query instead of a manual comparison — and fortnightly becomes exactly optimal.
• If a day of undetected running costs only €73 rather than €240, monthly checking is exactly right. Low-value, low-volume processes genuinely do not deserve close attention.
• For weekly checking to be justified, a day of undetected running has to cost about €1,340. That threshold is real, and some processes clear it — anything touching payments, regulatory submissions or customer-visible commitments. The point is that it is a small subset, and naming which processes clear the threshold is a more useful exercise than adopting one cadence for everything.

The counter-metric: what you spend to catch versus what a failure costs

Any interval you pick can be made to look good by reporting only one side of it. So report both, as a ratio, and pre-declare where you expect it to sit.

Verification spend per failure actually caught, against the expected cost of one failure:

• Every 7 days: €4,692.86 spent per catch, against €1,320 of loss per failure — ratio 3.56
• Every 14 days: €2,346.43 per catch, against €2,160 — ratio 1.09
• Every 16 days: €2,053.12 per catch, against €2,400 — ratio 0.86
• Every 30 days: €1,095 per catch, against €4,080 — ratio 0.27
• Every 60 days: €547.50 per catch, against €7,680 — ratio 0.07

The two curves cross at 14.67 days, and the honest target sits just below one — spending a little less to find each failure than the failure costs. A ratio far above one means you are buying assurance you do not need. A ratio near zero means the damage is real and you have simply stopped looking, which is the state most estates are in when someone finally calls for help.

Deliberately, neither side of this ratio is exception rate or cost per transaction. Those are the right measures for a working automation and the wrong ones here: an exception is a failure the bot noticed. This whole piece is about the failures it did not.

Recovery, and the sequencing that makes it survivable

When an estate has drifted this far, the instinct is to rebuild. Resist it long enough to do three things in order.

A managed operations layer — a monitored, staffed capability sitting over the estate rather than inside individual bots — is the usual answer to who runs the checks, and PAteam builds and operates them. But it is worth being precise about what it does and does not buy, because “24/7 monitoring” as a line item is not an argument. What a monitoring layer actually changes in the model above is the cost of one verification: automated volume-floor and reconciliation checks push €45 per check down towards a few euros, which moves the optimal interval down and the total cost down with it. What it does not change is the loss per day of undetected running, which is a property of your process and not of your supplier. If a vendor’s monitoring proposal does not tell you which of those two numbers it moves, it is priced on faith.

What to put in the contract: the escalation path

Most automation support agreements specify response times and say nothing about what happens when the response does not resolve anything. That gap is where recovery engagements die, so write the escalation path before you sign, and write it as a sequence of named states with a clock on each.

Specify who is called, in what order, with what authority. Specify the point at which the supplier is obliged to escalate to a named senior engineer rather than continuing to work a ticket — and put a duration on it, because an unbounded first-line attempt is functionally an unbounded outage. Specify the trigger that converts a recurring incident into a defect requiring a permanent fix at the supplier’s cost, rather than a repeated incident billed each time; without it, a brittle automation becomes an annuity. Specify who can authorise stopping an automation, because the person who first notices a bot writing wrong data is rarely the person permitted to switch it off, and every hour of that hesitation is a day of the damage in the model above.

And specify what the supplier owes you when the failure was silent. If a process ran wrong for three weeks and nobody detected it, the remedy is not a credit against the support fee. It is a written account of why the detection route failed and what changed as a result. Ask for that clause explicitly. The reaction to the request tells you a great deal about how the supplier’s own operations run.

A note on what recovery looked like once

On one European division of a global logistics operator, the work that mattered was not rebuilding automations — it was accepting that the estate’s architecture had to bend to systems the team did not control, and designing detection around the joins rather than inside each bot. The automations that survived were the ones whose output could be reconciled against something independent. The ones that could not be reconciled were the ones that had been failing quietly.

On one legal-operations estate, per-document handling fell from a five-to-eight-minute range to about one minute, and the digital workers were still running a year later — which is the harder half of that claim. Most published automation results describe the first month. The interesting number is whether anything is still running, correctly, after the person who built it has moved on.

Neither of those is a proof. They are the shape of what recovery involves, offered so the mechanism is legible: reconcilable output, independent verification, and a named owner for the interval.

Frequently asked questions