Why this article exists

Most writing about RPA is about where it fits.

Knowing where it does not is more useful, because that is where the money gets wasted — on projects that work in a demonstration and become a burden in production.

Here are the cases, with what to do instead.

1. When an API exists

The most common and most expensive mistake.

Why it happens: RPA needs nobody’s permission. You can build it without asking the other system’s owner, without a project, without a conversation.

Why it costs: every vendor update risks breaking it, and you have signed up for maintenance you did not need.

What to do instead: check properly. Ask the vendor. Read the documentation. Look for an export function. Check whether the file has a direct URL — that alone removes most of the fragility from data-retrieval automations.

Ask this question first, every time. It saves more than anything else in this article.

2. When the task needs judgement

RPA follows rules. It does not decide.

Where people get caught: the task looks rule-based until you look closely. “Approve if the amount is under the limit” is a rule. “Approve if it seems reasonable” is not, and it is what people actually do.

Encoding judgement as rules works until reality produces a case the rules do not cover — and it will.

What to do instead: automate the gathering, leave the deciding. The robot prepares, a person decides. That captures most of the time saving with none of the risk.

3. When the volume is low

Building and maintaining an automation has a fixed cost.

Twice a month does not clear it. By the time you have documented the process, built it, tested it, and maintained it for a year, a person doing it by hand would have cost less.

A rough test: if the annual saving is not several times the annual cost, it is marginal. Marginal automations get abandoned when their author leaves.

What to do instead: leave it manual, or find the higher-volume task nearby.

4. When the interface changes constantly

Screen automation depends on screens staying the same.

Some applications update frequently, particularly cloud ones where the vendor ships changes without asking.

You will spend more time repairing than the automation saves.

What to do instead: check whether an API exists, or accept that this task stays manual.

5. When the documents vary

A common misunderstanding.

Invoices, receipts and forms arrive in thousands of layouts. RPA cannot read them — it can find an element on a screen, not extract meaning from a document it has not seen before.

What to do instead: that is a document AI problem. Different technology, and it works well.

6. When the process is not documented

Automating an undocumented process means automating your assumptions about it.

What happens: halfway through the build, you discover the process is not what anyone described. Two people do it differently. There is an exception nobody mentioned.

What to do instead: document it first. Watch it being done, several times, by more than one person. That document is worth more than the automation.

7. When the process is wrong

The one that catches everyone.

If the process has unnecessary steps, duplicated work, or produces a report nobody reads, automating it means doing the wrong thing faster and cheaper.

Ask before building: should this task exist at all?

Sometimes three of the eight steps are pointless. Removing them saves more than automating all eight would have — and costs nothing to maintain.

8. When nobody will maintain it

Every automation needs an owner who receives the alerts and fixes it when something changes.

If the honest answer is that nobody will do this, do not start.

An unmaintained automation does not simply stop being useful. It fails silently while everyone assumes it is working, which is worse than never having had it.

9. When you cannot see failures

Related, and worth stating separately.

If you cannot arrange for failures to reach a person, do not automate anything that matters.

A silent gap in your data is more expensive than the manual work you avoided.

The pattern

Read back through and something is consistent.

RPA is wrong when a better tool exists, when the task is not really mechanical, or when nobody will look after it.

None of those are technology problems. They are questions you can answer before spending anything.

What to ask before starting

Six questions. A “no” on any of the first four is usually a stop.

Does an API, an export or a direct URL exist? If yes — use that.

Is this genuinely rule-based? If it needs judgement, automate part of it.

Is the volume high enough? Weekly at minimum, ideally daily.

Is the interface stable? Frequently changing systems are not worth it.

Who will own it? Name the person.

How will we know if it fails? If you cannot answer, fix that first.

The alternatives, briefly

A setting in your existing system. Most business systems do more than people realise. Check first.

An API integration. More reliable, cheaper to maintain.

A workflow tool. Faster to build than code, readable by a colleague.

Document AI. For varying documents.

Fixing the process. Sometimes the answer is fewer steps rather than faster ones.

Leaving it manual. A legitimate outcome for low-volume work.

The short version

Do not use RPA when an API exists, when the task needs judgement, when the volume is low, when the interface changes constantly, when the documents vary, when the process is undocumented, or when nobody will maintain it.

And do not automate a process nobody has questioned. Making the wrong thing faster is not an improvement.

The best automation decisions include the ones not to build.