Two quotes land on your desk. One proposes workflow automation, the other RPA, and both promise to stop your team retyping the same data. The workflow automation vs RPA question comes down to one thing: how the software gets into your systems. Get that right and the rest of the decision follows.
Below is a plain comparison, four questions to decide between them, and the mistakes that sink first projects.
What workflow automation is
Workflow automation connects your systems directly, through the connection points (APIs) they were built to offer, and moves work between them according to your rules. An invoice arrives, gets matched to its purchase order in the ERP, goes to the right approver and posts to accounts once approved. Nobody copies anything.
Because it talks to systems directly, it is fast, it doesn't care what a screen looks like, and it rarely breaks when a vendor redesigns an interface. Its limit is just as clear. It needs a way in. If a system offers no connection point, workflow automation can't reach it.
What RPA is
Robotic process automation uses software robots that work a computer the way a person does. The bot logs in, clicks through screens, reads fields and types values, in the same order every time, and records each action.
In a 2016 McKinsey interview, Professor Leslie Willcocks of the London School of Economics described RPA's natural home as "swivel chair" processes: someone takes inputs from email or spreadsheets, applies rules and keys the results into a system such as an ERP or CRM. In the case studies he examined, first-year returns ranged from 30% to as much as 200%.
RPA's strength is that it needs nothing from the systems it works. Its weakness is the same fact turned around. When a screen changes, the bot can stop.
Workflow automation vs. RPA side by side
Workflow automation | RPA | |
|---|---|---|
How it reaches your systems | Direct connections: APIs, databases, file feeds | Through the screen, like a person |
Suited to | Modern ERPs, CRMs, accounting and cloud apps | Old desktop software, supplier and government portals, banking websites |
Speed per item | Very fast | Roughly the pace of a quick human, without breaks |
What breaks it | API changes, which vendors usually announce | Screen and layout changes, which often arrive without warning |
Upkeep | Low once built | Ongoing, since bots need updating when screens change |
Reads messy documents or makes judgment calls | Only with an AI step added | Only with an AI step added |
Audit trail | Every step logged in the workflow | Every action logged, often with screenshots |
Four questions that decide it
Run each process through these questions one step at a time. The answer often changes from step to step.
1. Does the system offer a direct connection?
If yes, use workflow automation for that step. A direct link is quicker to run and breaks less. Ask your vendor or IT team whether an API or a scheduled export exists before anything else.
2. Is the screen the only way in?
Old desktop programs, portals run by customers or government agencies, and banking websites often give you nothing but a login page. That is where an RPA bot earns its place.
3. How often does that screen change?
A government portal that changes once a year is a fine bot target. A supplier site that is redesigned every quarter will cost you in repairs. Put that upkeep into the comparison before you choose.
4. Does the step need reading or judgment?
Neither tool can read a contract or decide whether an unusual claim is valid. If a step needs that, it calls for an AI agent with a person approving the outcome, while the workflow or bot handles the steps around it.
Why first RPA projects disappoint
RPA is easy to start and easy to get wrong. EY, drawing on RPA work across 20 countries, reported seeing as many as 30% to 50% of initial RPA projects fail, and put the cause down to how projects were planned rather than the technology. The usual mistakes are familiar:
Automating a process that is messy or changes weekly, instead of tidying it first.
Choosing RPA for a system that already has a perfectly good API.
No plan for who looks after the bots after launch.
No business case written before the build, so nobody can say later whether it worked.
Scaling is hard whichever tool you pick. In Deloitte's 2022 global intelligent automation survey of 479 executives, the top barriers were process fragmentation, lack of a clear vision, lack of IT readiness and resistance to change. Switching tools fixes none of those.
When you need both
Most real processes mix modern and old systems, so the honest answer is often a combination. Take a distributor's order-to-invoice process:
Orders arrive by email and through two customer portals.
A bot logs in to each portal and downloads new orders and changes.
A workflow creates the sales orders in the ERP through its API and checks stock.
Anything unusual, such as a changed delivery date or a price that doesn't match the contract, goes to a person with the difference marked.
Once the goods ship, the workflow raises the invoice and posts it to accounts.
The bot covers the two portals that offer no other way in. The workflow does the rest. Each tool sits where it is strongest, and your people see only the exceptions.
Notice that a person still decides every exception. That matters more than which tool runs a given step. Your team keeps control of anything unusual, and the automation keeps a record of every item it touched, so a customer query months later takes minutes to answer.
What to ask before you sign either quote
Which steps use a direct connection, which work through a screen, and why?
What happens when an item doesn't fit the rules? Who sees it, and how quickly?
Who updates the automation when a system or portal changes, and what does that cost each year?
Where do the logins and the data live? They should sit in your own accounts, under your control.
How will we see what it did? Ask for a dashboard or log showing items finished, items handed to a person and the reason.
Can it run beside the team for a few weeks before we switch over?
A vendor who proposes one tool for every step, whatever the systems involved, is selling the tool they happen to have. A good proposal explains its choice step by step.
Frequently asked questions
Is RPA cheaper than workflow automation?
It can be cheaper to build, because it needs nothing from the target system. Over a few years, upkeep can close that gap if the screens it works change often. Compare the total cost over the life of the automation, including repairs.
Can RPA work with very old software?
Yes, and that is one of its main uses. A bot can type into the screens of a decades-old desktop program field by field and check that each entry saved, so you keep the system and your team stops retyping.
Is AI replacing RPA?
AI handles reading and judgment, which RPA never did. Bots still have a job wherever a screen is the only way into a system. A common pattern pairs them: the bot fetches and enters, the AI reads and drafts, and a person approves.
Which should we try first?
Start with the process that costs your team the most hours, then let the systems involved choose the tool. If every system has an API, start with workflow automation. If the painful part lives in a portal, start with a bot.
If you'd like help mapping a process step by step, our workflow automation and RPA projects both begin with a free 5-day audit of one team, ending with a fixed price for the first build. Or book a 30-minute call and walk a founder through the process that annoys you most.
