Robotic Process Automation gets pitched as a magic fix for anything repetitive, and that reputation does it a disservice. RPA, in practice, is a piece of software that clicks, types, reads, and copies data between interfaces the same way a person would, using tools like UiPath to record and script that behavior. It is not artificial intelligence, and it doesn't understand what it's doing. It replays a procedure exactly, which is precisely what makes it powerful for the right task and fragile for the wrong one.
The first test I run before recommending RPA is the volume and repetition test. A task that happens twice a month, no matter how tedious, usually costs more to automate and maintain than to just do by hand. A task that happens fifty times a day, with the same steps every time, is a different story entirely. The math that matters is: (minutes saved per run) × (runs per period) versus the hours spent building and, critically, maintaining the bot, because every automation needs occasional babysitting when the underlying website or software updates its interface.
The second test is stability. RPA bots interact with interfaces using selectors, which is a technical way of saying they find buttons and fields by how a page or app is built, not by what the task is trying to accomplish. If the target system's layout changes often, a bot built against it breaks often, and a client paying for 'automation' does not want a support ticket every time a vendor redesigns their dashboard. A process that runs against a stable, rarely-changed system is a much safer automation candidate than one running against a frequently-updated app.
A concrete example from my own work: a retail client needed product listings extracted from a source site and uploaded into their own WooCommerce store, a task that otherwise meant someone manually copying names, prices, descriptions, and images, product by product, for a catalog running into the hundreds of items. That is a textbook RPA case. High volume, repetitive, rule-based, and the source structure was stable enough that a bot built to read it kept working reliably. The same logic extends to syncing data between two systems that don't talk to each other, or pulling structured listings into a platform on a schedule.
Where I steer clients away from RPA is anywhere judgment is actually required on a case-by-case basis, where the 'rules' are really exceptions dressed up as rules. If every third case needs a human decision that can't be reduced to an if/then branch, the bot ends up needing more exception-handling logic than the task was worth automating in the first place. I also steer people away from RPA when a proper API integration already exists or is feasible, because an API call is faster, more reliable, and immune to interface redesigns in a way that a bot clicking through a browser never will be. RPA is often the right tool specifically because an API isn't available, not because it's inherently better than one.
The honest advice, when a client asks 'should I automate this?', is to map the actual process first: how often it runs, how repetitive each run really is, how often the systems involved change, and whether an API already exists. When those answers line up, RPA pays for itself within weeks and keeps paying for itself every week after. When they don't, the better investment is usually a cleaner manual workflow, a simple internal tool, or a proper integration, not a bot wrapped around a problem that was never actually about repetition.
