RPA: what it actually solves and where it hits a wall

Robotic process automation has had a very good marketing run. The pitch is compelling: software robots that work 24 hours a day, do not make errors, and cost a fraction of a human FTE. For certain tasks, that description is roughly accurate. For others, the gap between the pitch and the experience is significant.

I have worked with RPA in several companies over the past few years. It is a useful tool. It is also a tool that gets oversold, applied to the wrong problems, and then maintained by teams who were not prepared for what operational ownership of a robot fleet actually involves.

What RPA is well suited for

The conditions under which RPA delivers reliably are specific. The process must be rule-based and deterministic - no judgment, no exceptions handled by intuition. The interfaces the robot interacts with must be stable - the same screens, the same fields, in the same positions. The volume of transactions must justify the build and maintenance cost. And ideally, the underlying system does not have an API.

That last point is important. RPA is fundamentally a workaround for the absence of integration. It operates on the user interface of legacy systems because those systems have no programmatic interface. If your legacy system does have an API - even a basic one - a proper integration is almost always better than an RPA robot.

Where it breaks down

RPA robots are brittle. Any change to the interface they interact with - a screen layout update, a label rename, a new validation step - can break the robot. In practice, this means RPA deployments require ongoing maintenance every time the underlying application changes, which in a live business environment is more frequent than expected.

The second common problem is exception handling. Processes that seem simple often have a long tail of edge cases. A robot that handles 90% of transactions automatically is useful. But the 10% that fall outside the happy path need to go somewhere - usually a human queue. If that queue is not designed properly, exceptions pile up and the time savings are partly offset by the management overhead.

The third problem is governance. A large RPA estate - tens or hundreds of robots - is a significant operational commitment. Robots need to be versioned, tested when dependencies change, monitored for failures, and maintained when they break. Companies that expand RPA quickly often find themselves with a fragile automation layer that is hard to audit and expensive to keep running.

How to decide whether it is the right tool

Before approving an RPA project, I ask three questions. First: is there any realistic path to building a proper integration with the target system, even a slow one? If yes, RPA is a short-term fix that creates technical debt. Second: how often does the target application change? If it changes frequently, the maintenance cost will be high. Third: what happens when the robot fails? If the answer is "we do not know yet", that is a gap in the design.

RPA makes sense as a tactical bridge when a real integration is years away and the process volume is high enough to justify it. It does not make sense as a permanent strategic layer.

A note on the vendor landscape

The market for RPA tools in 2018 is active, with several mature platforms and aggressive sales cycles. Most enterprise vendors are pitching RPA as a step toward intelligent automation and eventually AI. That roadmap is plausible in principle. In practice, most companies are not ready for intelligent automation - they are still working on making their basic processes reliable. Start there before adding AI to the automation stack.