Robotic Process Automation Explained: What RPA Is and Where It Fits

Robotic process automation, or RPA, is software that does rule-based office work by operating other programs the way a person does: it logs in, reads a screen, copies a value and types it somewhere else. No physical robot is involved. RPA suits repetitive tasks with clear rules and tidy digital inputs, and it struggles whenever screens, rules or data change.

Robotic process automation fits frequent, rule-based, stable work whose inputs arrive as structured digital data, and it hands everything else back to people, according to the practitioner consensus collected in a 2020 structured review in the journal Computers in Industry. The same review notes that this consensus rests mostly on case studies and industry white papers.¹

A rough test of our own follows from that consensus: if you could hand the task to a temporary worker with a one-page rulebook and never get a question back, a bot may manage it. If the temp would keep asking what to do, a bot will struggle too.

What robotic process automation does, in plain terms

Robotic process automation gives software its own login and lets it work through the same screens a person uses. Leslie Willcocks, Mary Lacity and Andrew Craig, who studied early adopters for the London School of Economics, describe its home ground as “swivel chair” processes: take inputs from one system, apply rules, and enter the results into another.²

The reason RPA exists is old software. Many organizations run older systems that are closed to other software, often lacking the application programming interfaces (APIs) that let programs exchange data directly.¹ Connecting them properly is an IT project. A bot skips that project by using the front end, so nothing underneath changes, which is why researchers call RPA “lightweight” IT.³

The LSE researchers’ illustration is an HR specialist who onboards a new hire by logging on and off a dozen systems, from payroll to parking, following standard rules. A bot with its own logon ID can make the same round, leaving the specialist the exceptions.²

RPA is the large-company end of the tools in what workflow automation is and where to start: a no-code platform joins apps through built-in connections, while an RPA bot comes in through the screen. For anyone weighing RPA, the rule is simple: if a job involves copying the same fields between screens all day, that is RPA’s natural territory; if the systems already offer a proper connection, prefer it, because a common criticism is that integrations built through RPA are less sturdy than those built into the core systems.¹

How a software bot does the work

An RPA bot follows a script of small steps, such as open an application, read a field, copy a value and click a button, with branches for the business rules. Commercial RPA products generally combine three parts, the 2020 review by Rehan Syed and colleagues reports: a modelling tool for building bots, an orchestrator that manages their runs, and the bots themselves. Many tools can record a person’s clicks as a script, but the review cautions that such a recording holds only the smooth run, the “happy path,” so the awkward cases have to be built in separately.¹

1. The bot’s way in: it logs in with its own account and works the screen, as a person would, so the systems underneath stay unchanged
2. A direct integration: an API exchanges data with the layers underneath, without going through the screen
3. The weak point: change the screen layout or a business rule, and the bot’s route no longer matches until someone updates it

A bot does exactly what it is told. A person knows that “St. Louis” and “Saint Louis” are the same place; a bot knows it only if a rule says so. Studying Telefónica O2, the UK mobile operator, the LSE researchers concluded that rules written for a robot have to be spelled out in far more detail than instructions for a person.⁴

The practical lesson: building a bot is largely writing down rules people never had to spell out. Before a pilot, ask whoever does the task to list every judgment call they make, even the ones that feel too obvious to mention.

Bots that work beside you, and bots that run alone

RPA bots run in two modes, attended and unattended, according to the 2020 review. An unattended bot works autonomously and suits simple processes that do not vary from case to case, but it can make significant errors on complex ones. An attended bot is started by a person to perform part of a process while that person monitors it.¹

For example, a call-center agent speaking with a customer who has moved house can trigger an attended bot to update the address in several systems during the call; the review lists address changes among attended use cases.¹ The choice follows the task: if a person must start the work, supply a judgment or check the result as it happens, the bot is attended.

Where RPA fits: frequent, rule-bound work between systems

RPA fits work that is highly rule-based, frequent, stable and standardized, arrives as structured digital data, has few exceptions and often touches several systems. Rehan Syed of Queensland University of Technology and colleagues gathered that list from the literature in their 2020 structured review, then judged that the techniques for picking tasks lack empirical validation.¹

The study

Limited evidence

The 13 traits of a bot-ready task, and how little tests them

Across the sources it reviewed, the team found 13 traits said to make a task suit a bot. Besides the rule-based, high-volume, stable and standardized core, the list includes well documented, low in exceptions, highly manual, transactional and interacting with many systems. A minority of sources disagree, arguing that medium volumes, or even temporary processes, can also suit bots. The authors’ verdict on the selection techniques themselves: largely developed by RPA vendors on limited anecdotal evidence, and possibly biased.¹

So treat the list as accumulated experience rather than a proven sorting test: the review found the RPA literature dominated by position papers and white papers built on case studies.¹

The gap RPA fills is specific. Hofmann and colleagues call it a transition element between human work and full-scale business process automation, useful where people are too expensive and a proper IT build is not justified.³

Telefónica O2 shows the trade in numbers. When it tested its business process management software against RPA, a team automated the same SIM-card swap process in about the time the RPA pilot took, but the projections favored RPA, which was forecast to pay back in 10 months across 10 automated processes, against up to three years for the IT-built route. The caveat: these were the company’s own forecasts, from one case study whose research had Blue Prism, the RPA vendor O2 used, as its launch sponsor.⁴

The traits sort real tasks quickly. Keying each week’s supplier invoices from a fixed-format portal export into the ledger passes nearly all of them; settling disputed invoices fails most, because every dispute turns on a judgment and a conversation. When you score a candidate, look hardest at stability and input format, because changed screens, rules and input data are the failure triggers the review names for bots already in use.

Where RPA breaks: changed screens, stale rules and messy data

RPA breaks when the world around the bot changes. The 2020 review names the usual triggers: a changed user interface, such as a new screen layout or resolution, a case that needs a different system, and a changed business rule. The bot then stops or carries on down the wrong path, and a person has to step in.¹

Bots cannot monitor themselves or adapt when business rules change, the review notes, so a bot risks producing wrong results from out-of-date rules. Poor input data does similar damage: a bot fed a case with missing or odd values may perform the task incorrectly.¹

Underneath all of these is one fact: a bot has no common sense. It executes exactly what it was configured to do, as the Telefónica O2 case study puts it, so it looks for each field where the script says it will be.⁴ If a supplier portal moves its export button into a new menu, a person finds it in seconds; the bot keeps looking where the button used to be.

Myth

Bots don't make mistakes.

Fact

A bot repeats its rules exactly, so it does not mistype. When a screen, a rule or the input data changes, it can stop, or keep going and get cases wrong, until a person fixes it.

The company around the bot can break it too. Telefónica O2’s first pilot processed transactions so fast that its fraud and security team went looking for an intruder. Later, the lead virtual machine that orchestrated its bots coped with 20 robots but, in the case study’s words, imploded when the number quadrupled.⁴ The review records a case where IT blocked all non-human users, which stopped the bots from logging on, and warns that bots that work well in one corner often prove hard to scale across a company.¹

The protection is mostly organizational. Before a bot goes live, list the screens, systems and rules it depends on, and name a process owner who is told about every change to them. Tell IT and security before the bot first logs in, and send every case it cannot handle to a queue a person watches.

Is your task ready for a bot?

A task is ready for a bot when it is rule-bound, frequent and stable, its inputs arrive digital and structured, someone named will hear about changes to the screens and rules it touches, and IT and security have signed off. These checks distill the research above; use them to screen candidates, not as a verdict.

The invoice-keying task above passes only if the portal’s export layout stays put and someone in finance hears before it changes.

The evidence behind the main claims, at a glance:

Where the “30 to 50 percent fail” figure comes from

The widely repeated claim that 30 to 50 percent of RPA projects fail traces back to a 2016 paper by the consultancy EY, “Get ready for robots.” It is EY’s experience, not a measured rate: the paper says EY has seen up to that share of initial RPA projects fail, and it gives no sample, no method and no definition of failure. The same paragraph hints at why the figure may run high. EY says it is often called in when a company’s first attempt has failed. A firm hired for rescues would tend to see more failures than one that is not, much as a tow-truck driver would overestimate how often cars break down. The paper also markets EY’s services.⁵

Peer-reviewed research has not filled the gap. The 2020 review found plenty of advice on RPA but no clear framework of what makes projects succeed or fail, and no study we found measured a failure rate.¹

The useful part of the EY paper is its list of common causes, which agrees with the research above: choosing highly complex processes first, treating RPA as an IT project rather than a business-led one, forgetting the infrastructure bots run on, and trying to automate every last case of a process instead of leaving the awkward remainder to people.⁵

Where AI changes what bots can do

Classic RPA follows fixed rules and needs structured digital input; AI extends bots toward messier material such as emails and scanned documents. The 2020 review describes AI and machine learning being added to turn unstructured data into structured data, while noting that the literature gives little detail on how.¹

Take invoices that arrive as scanned PDFs: an AI step might read each one and pull out the supplier and total, then a rule-based bot keys them into the finance system. Because the AI step can misread, the rules after it should check for values that look wrong, such as a total far above that supplier’s usual range, and route those to a person.

Tools that pursue a goal and choose their own next steps are a different design again, explained in how AI agents work and when to trust one.

The bottom line

Robotic process automation is a patch over systems that cannot talk to each other: a bot with a login that copies, checks and types by rule. It pays where work is frequent, rule-bound and stable, and it needs a named owner, because every change to a screen, a rule or an input can break it quietly. The popular failure statistic is one firm’s impression; the causes behind it are the part to plan around.