A bot that clicks through a screen works until someone moves a button. Then it fails quietly, and the first person to notice is usually finance at month-end close.
Where Brittle Bots Come From
Most RPA breakage isn't a bot bug. It's a dependency nobody tracked. The bot was built against a UI the vendor controls, and the vendor ships updates on its own schedule. A renamed field, a new login prompt or a reordered menu is enough to stop a run.
The failures cluster in the same places:
- Screen-scraped CRM and ERP entry. Bots that key data into forms break on every UI release.
- Report downloads. A bot that exports a file and reformats it fails when a column moves.
- Cross-system lookups. Matching a customer in the ERP to the CRM by clicking through search screens is slow and fragile.
Inventory Before You Rebuild
Start with a list of every bot, what it touches, who owns it, and how many times it failed last quarter. Most teams find that a handful of bots cause most of the exceptions. Those are your candidates, not the whole fleet.
Rank them by the cost of a failure. A bot that feeds the pipeline report is a nuisance. A bot that posts to the ledger during month-end close is a risk.
Move Off the Screen Where You Can
If the system has an API, use it. An API call is a contract the vendor has to honor, and a UI is not. Where there's no API, a scheduled export into a governed table beats a bot clicking through a browser every time.
Keep RPA for what it's actually good at: legacy systems with no other door in, and short-lived bridges while a migration is under way.
Give Every Bot an Owner and an Alarm
A bot without an owner is an outage waiting for a date. Assign a named owner, log every run, and alert on the first failure rather than the third. Add a simple reconciliation check, such as record counts in versus records out, so a bot that runs but does the wrong thing still gets caught.
That last check matters most. A loud failure costs you an hour. A silent one costs you a restatement.
What to Measure
Track bot failures per month, mean time to repair, and the share of automations running on an API or governed data feed instead of a screen. If the first two aren't falling and the third isn't rising, you're maintaining bots instead of retiring the risk.
Our Take
When we review an automation estate, we rarely recommend ripping out RPA. We recommend shrinking the screen-dependent part of it. Fewer bots on tighter data feeds means fewer 2 a.m. failures, cleaner month-end close, and a source of truth your team doesn't have to babysit.