Robotic process automation sells a seductive promise: point a bot at the boring work a human does today, and the boring work goes away. Sometimes that is exactly right. More often the bot is a bandage over a wound somebody chose not to treat. It keeps a broken step alive, hides it from the people who could have fixed it, and quietly adds a fragile dependency to your estate. This piece gives you a way to tell the two situations apart before you buy a single license.
RPA is a symptom, not a solution
When a team asks me to build a bot, the request almost never arrives as "we have carefully ruled out every cheaper fix and automation is the only path left." It arrives as "a person spends four hours a day re-keying this, can you make a robot do it?" That framing skips the only question that matters: why does a human have to re-key it at all?
A bot does not remove work. It moves the work from a person to a script and then hands you a new job, which is keeping that script alive every time a screen layout, a field label, or a login flow changes. If the underlying step was unnecessary, you have now automated waste and made it harder to see. If the step exists because two systems should be talking and are not, you have papered over an integration gap with the most brittle glue available.
The test I apply first
Before I automate a task, I ask whether the task should exist. If the honest answer is "no, but changing that is somebody else's budget," you do not have an automation opportunity. You have an escalation you are avoiding, and a bot is how you avoid it politely.
That is the whole thesis. RPA is a legitimate tool with a narrow, honest use. Most business cases that reach it never earned the right to. To make that concrete, put every candidate through a four-branch decision tree first.
The four-branch decision tree
There are exactly four honest outcomes for any repetitive task. Fix the process so the step disappears. Configure the system so the tool does the step natively. Integrate the two systems properly so the data moves without a human. Or, only when the first three are genuinely closed, bot it. The order is deliberate: each branch is cheaper to own than the one after it, and a bot is the most expensive thing to maintain, not the least.
Notice what the tree does to the conversation. It stops treating "should we automate this?" as a yes or no question and turns it into "which of four fixes is correct?" A bot is one of four answers, and it is the answer you accept only after the other three are proven impossible, not merely inconvenient.
The ten-question diagnostic
Run every candidate through these ten questions before anyone opens an automation studio. Each answer nudges you toward a branch. If the diagnostic keeps pointing away from Branch 4, you have just saved yourself a maintenance liability. Do this after you understand the current process, ideally with real evidence. If you have not mapped the process yet, start with process mining before automation so you are diagnosing the real flow and not the one people describe in meetings.
| # | Diagnostic question | If yes, look at |
|---|---|---|
| 1 | Would the business outcome be unharmed if this step simply stopped? | Branch 1 |
| 2 | Does the step exist only to satisfy an internal habit or a legacy report nobody reads? | Branch 1 |
| 3 | Would a config change in the ERP remove this step entirely? | Branch 2 |
| 4 | Is the manual work caused by a mandatory field sitting in the wrong module or screen? | Branch 2 |
| 5 | Is the rework driven by upstream data quality that a validation rule could stop at source? | Branch 2 |
| 6 | Does the target system have a supported, documented API or connector? | Branch 3 |
| 7 | Do both systems already sit inside a platform that offers a native integration? | Branch 3 |
| 8 | Is a paid module or license tier available that would do this natively but was not purchased? | Branch 2 or 3 |
| 9 | Is the only reason a human does this that no owner will fund the config or integration? | Escalate first |
| 10 | Is the target a closed legacy or third-party system with no interface at all, now or planned? | Branch 4 |
Nine of the ten questions point somewhere other than a bot. Only question ten, answered honestly and after the rest, opens Branch 4. That ratio is not an accident. It reflects how rarely a bot is the correct answer once you look at the process instead of the symptom.
Three field cases
These are anonymised from real engagements. The pattern in each is what matters, not the vendor names, which I have left out on purpose.
Case 1: the bot that a supported integration replaced in three weeks
A maintenance team ran a bot that opened work orders in one system, read the header and lines, and re-keyed them into a second system used by a contractor. It had run for over a year. It broke roughly monthly whenever either screen changed, and a person babysat it. When I ran the diagnostic, question six answered itself: both systems had a documented REST API. Nobody had checked, because the bot already existed and was treated as done. We built a proper API to API integration in three weeks. It has not broken since, it carries an audit trail the bot never had, and the babysitting hours went to actual maintenance planning. The bot was Branch 3 work wearing a Branch 4 costume.
Case 2: the bot copying data because a field was in the wrong module
A finance user had a bot that copied a cost-centre value from a procurement screen into a project screen for every new requisition. The business case said "saves ninety minutes a day." The real story, surfaced by questions four and five, was that the cost-centre field lived in the wrong module and was not being defaulted at requisition creation. A one-time configuration change made the field populate itself at source. The step vanished. There was nothing left to automate, because there was nothing left to do. This is the most common shape I see: a bot built to move data that should never have needed moving. It was Branch 2 all along.
Case 3: a genuinely correct bot
A client had to submit compliance filings into a legacy government portal. The portal had no API, no bulk upload, no export, and no roadmap for any of them. It was a closed system owned by an authority that would not change it. Question ten answered yes without qualification. A person was spending a full day each week typing the same forms. Here a bot was the right call, because every cheaper branch was genuinely closed, not merely unfunded. We built it, and, importantly, we registered it with an owner and a review date, because a bot against a portal you do not control is a standing risk, not a finished project. This is what Branch 4 actually looks like when it is earned.
The uncomfortable claim
Here is the opinion the three cases lead to. Most RPA business cases are not automation opportunities at all. They are evidence of a licensing or configuration failure that somebody chose not to escalate. The bot is what you build instead of having the awkward conversation about why the paid module was never bought, why the integration was descoped, or why the field sits in the wrong place.
Why this hides instead of fixes
- A bot makes the broken step invisible. Once it runs, the pain that would have forced a fix is gone, so the fix never happens.
- The maintenance cost of the bot lands on a different budget line than the licensing gap that caused it, so nobody connects the two.
- Every bot you build to dodge an escalation makes the next escalation harder, because now there is a working workaround to point at.
I am not saying RPA vendors are selling snake oil. The tooling from UiPath and Microsoft's Power Automate desktop flows is genuinely capable, and for a Case 3 problem it is exactly what you want. The failure is upstream of the tool. It is in the decision to reach for a bot before the tree has been walked. If you are weighing platforms, do it after the diagnostic, using a proper scoring framework rather than a demo that dazzled a stakeholder.
The bot register: discipline for what survives
When a task does reach Branch 4, the work is not done when the bot runs. A bot is a liability with a heartbeat. It depends on interfaces you do not control and it will break. The single most useful governance artefact I hand clients is a bot register that forces two fields most teams never fill in: a named owner and a retirement date. No bot enters production without both.
The retirement date is the point of the whole thing. It is not a promise the bot dies then. It is a forced review: on that date, someone must re-run the decision tree and prove the bot is still the right answer. Nine times out of ten, by review date, an API has appeared, a module has been bought, or the process has changed, and the bot can be retired. Without a date, bots accumulate forever and nobody remembers why they exist.
| Field | What it captures | Example |
|---|---|---|
| Bot ID | Stable reference for logs and incidents | BOT-014 |
| Name / purpose | One line on what it does | Compliance filing to gov portal |
| Systems touched | Every screen or system it drives | Portal X (front end only) |
| Why Branch 4 | The proof no cheaper branch applied | No API, closed authority system |
| Owner | Named person accountable, not a team | J. Rahman, Compliance |
| Built / deployed | Go-live date | 2026-03-10 |
| Retirement date | Forced re-run of the decision tree | 2026-09-10 |
| Fallback | Manual plan if it breaks tomorrow | Revert to manual filing |
| Status | Active, under review, or retired | Active |
If you cannot fill in the owner and the retirement date, you are not ready to deploy the bot. That is the point. The register is a gate, not a spreadsheet you fill in afterwards. For a sector where these traps are especially common, see the specific patterns in RPA in procurement.
Conclusion
RPA is not the enemy. Reaching for it first is. The four-branch tree exists to make you prove, out loud, that fixing the process, configuring the system, and integrating properly are all genuinely closed before a bot is allowed on your estate. Most candidate tasks fall out at Branch 1, 2, or 3, and the ones that do were never automation problems. They were escalations in disguise. When a task does earn Branch 4, register it, name an owner, and set a retirement date, because a bot is the beginning of a maintenance commitment, not the end of a problem.
Independence note: I have no commercial relationship with any RPA or automation vendor and receive no referral fees. The tools named above are cited as widely used examples, not recommendations. Product capabilities and licensing change; verify current details against each vendor's own documentation before you decide.
Written by Muhammad Abbas
CMMS / CAFM Manager & Enterprise Integration Specialist · 22+ years across ERP, EAM, CAFM and enterprise integration.
Work with me