RPA has a complicated reputation and for good reason — the gap between what gets promised in a sales cycle and what actually happens after implementation is wide enough that a lot of organizations have become skeptical. Not because the technology doesn't work, but because the conditions for it to work don't get set up properly.
The implementations that deliver real results and the ones that become maintenance nightmares are often using the same platforms, sometimes even the same vendors. What separates them is process selection — what got automated, and whether anyone asked hard questions about it before building.
What makes a process worth automating
Not every repetitive task is a good automation candidate. The ones that hold up tend to share a few things.
Volume is the most obvious. A bot that saves eight minutes per transaction looks different at 2,000 transactions a month than at 80. At low volumes the maintenance overhead can easily exceed the time saved, and the only winner is the person who sold the implementation.
Rules matter more than volume though. RPA bots follow instructions precisely and handle nothing that isn't explicitly defined. A process where a human regularly reads context, weighs factors, or makes calls based on experience that isn't written down anywhere — that process is going to produce a lot of exceptions the bot can't handle. A process where the human is essentially doing the same thing the same way every time, just slowly and manually, is what automation was built for.
Stability is the one that tends to get underweighted. Bots interact with systems through their interfaces. When a screen changes, a field moves, or a vendor updates their portal, bots break. A process that runs against a system that changes frequently is going to require constant maintenance. A process that runs against something stable — legacy ERP, internal tooling that never gets touched — is much lower-risk to keep running.
Which specific processes across industries meet these criteria is covered in detail in this guide on who uses RPA and what they're automating.
The process selection mistake most teams make
The most expensive mistake in RPA isn't choosing the wrong platform. It's automating the process as it currently exists without asking why it works that way.
Manual processes in most organizations have accumulated steps over years that nobody questions anymore. Workarounds for system limitations that were addressed two years ago and never cleaned up. Redundant checks that made sense in a different era. Informal steps that someone added after an incident and that have just stayed. Automating all of that faithfully encodes the inefficiency into the bot. The result is something that runs faster but is still fundamentally broken.
Before automating anything, it's worth understanding which steps are genuinely necessary and which are artifacts. Sometimes that review reveals that the process itself should change before it gets automated. Sometimes it reveals that the whole thing could be eliminated with a small system configuration that nobody bothered to make. The automation project, if nothing else, forces a conversation about the process that should have happened a long time ago.
Exception handling is where pilots look better than production
Most pilots test the happy path. The transaction goes through cleanly, the data is formatted correctly, all the expected fields are populated, the downstream system accepts it. The bot handles it perfectly and the demo looks great.
Production data isn't like that.
Real data has formatting inconsistencies, missing fields, edge cases that appear rarely enough that nobody remembered to include them in the requirements. Real processes have exceptions that humans handle informally — a piece of information is missing so they check a second source, something looks wrong so they flag it rather than processing it, an unusual case shows up and they use judgment about how to route it.
When those situations hit a bot that wasn't built to handle them, one of two things happens. The bot fails loudly and someone has to investigate. Or worse, it fails silently — processes the transaction incorrectly and moves on, and nobody knows until something downstream is wrong.
Teams that map exception paths carefully before building, and design explicit handling for each one, ship bots that hold up in production. Teams that map the happy path and plan to handle exceptions later end up rebuilding significant portions of their automation after go-live.
The maintenance reality
Bots require ongoing attention. This is the part of RPA that tends to be underrepresented in ROI projections and overrepresented in the experience of organizations that have been running automation for a year or two.
Systems change. Vendors update portals. Internal applications get new releases. Processes get modified. Any of these can break a bot, and the team that built it has to fix it. At a small scale this is manageable. As the bot count grows, so does the surface area for things to break, and without deliberate operational structure the maintenance work starts crowding out new development.
The organizations that handle this well tend to build ownership into the program from the start — each bot has a defined owner, monitoring is in place to catch failures before they pile up, and there's a process for getting notified when system changes are coming rather than discovering them after a bot is already broken. None of this is complicated. It just has to be set up intentionally rather than figured out reactively after the third production incident.
The comparison of which departments have built the most durable programs and why is worth reading before building out an automation practice — this detailed breakdown of RPA adoption by industry and department covers what the successful programs have in common.
The question worth asking first
Before any bot gets built, one question is worth sitting with longer than most teams do: is automating this process solving the right problem?
Sometimes yes — the process is necessary, high-volume, rule-based, and the main issue is that it takes too much human time. Build the bot.
Sometimes the process exists because of a system limitation that could be addressed directly. Or it's redundant. Or a small workflow change could eliminate it entirely. In those cases, automation makes a problem permanent rather than fixing it.
The teams that build programs worth having ask this question consistently, for every candidate process, before writing a single line of bot logic. It slows down the start. It's why their automation is still running two years later.
