Robotic process automation is good at one thing: repeating the clicks and keystrokes a person would otherwise make, reliably and without getting bored. That is useful. It is also the reason RPA so often disappoints. A bot copies the process exactly as it is, including the detours, the rework loops and the steps that exist only because two systems were never connected.

If the process is sound, a bot makes it cheaper. If the process is broken, a bot makes it fail faster, at higher volume, with fewer people watching.

What “broken” looks like

Few processes are broken in an obvious way. The signs are usually quieter:

  • The same data is typed into two systems because nobody built the integration.
  • Some steps exist only to check the output of an earlier step that everyone knows is unreliable.
  • Different people do the task differently, and each of them thinks their way is the standard.
  • Exceptions are handled by email, and nobody knows how many there are.
  • The documentation describes how the process worked two reorganizations ago.

Automating any of these preserves the problem. Worse, it hides it. When a person re-keys an invoice and spots a wrong supplier number, they fix it. A bot passes it along.

Design first, then decide what to automate

Process design does not need to be a long consulting exercise. For a single workflow it can be a few focused sessions with the people who do the work, built around five questions:

  1. What is the outcome? Describe it in business terms: an order confirmed, a claim paid, a customer onboarded. Not “the form is filled in”.
  2. What are the inputs, and where do they come from? Every input that arrives unstructured (an email, a PDF, a phone call) is a future exception.
  3. Which steps add value and which only move data? Data-moving steps are candidates for removal through integration before they are candidates for a bot.
  4. Where are the decisions? Separate rule-based decisions from judgment calls. Only the first kind should run without review.
  5. What goes wrong, and how often? Count exceptions over a few weeks before designing anything. Estimates from memory tend to be optimistic.

Only after this should anyone pick a tool. The answer may be RPA. It may also be an API integration, a change to a form, a rule in the CRM, or simply deleting a step that turned out to be unnecessary.

When RPA is the right choice

RPA earns its place under specific conditions. Use it when most of these hold:

  • The process is stable and documented, and the people doing it agree on the steps.
  • Inputs are structured, or can be made structured upstream.
  • The systems involved have no usable API, or a proper integration would take longer than the process is expected to live.
  • The screens and fields the bot touches rarely change.
  • A named owner will notice when the bot stops and knows what to do about it.

If the last condition is missing, do not build the bot. Unowned automation is how RPA programs turn into maintenance debt.

Treat bots as a bridge

A sensible way to think about RPA is as a bridge across a gap that will eventually be closed properly. Imagine a distributor whose order system cannot talk to its carrier’s booking portal. A bot that books shipments buys time, and that can be worth a lot.

The plan should still include the real integration, and the bot should be switched off when it arrives. Write that retirement condition into the project from the start. Otherwise the bridge becomes permanent infrastructure that nobody designed to last, and every change to the portal’s screens becomes an incident.

A short pre-automation checklist

  • Is there a current process map that the people doing the work recognize as accurate?
  • Have exceptions been counted rather than guessed?
  • Has every data-moving step been checked for an integration alternative?
  • Is it written down which decisions the bot may make on its own?
  • Is there a named owner and a way of monitoring the bot?
  • Is there a condition under which the bot will be retired?

Any “no” on this list is not a reason to give up on automation. It is the work to do first, and it is usually smaller than the work of maintaining a bot built on a shaky process.