RPA: calculate the return before building, not after

The question put to an RPA provider is almost always "what does it cost to automate this process". The right question is "does this process deserve automating", and it is answered before pricing the build.

Time it, do not ask

Time estimates supplied by teams are systematically wrong, in both directions. We have measured gaps ranging from minus forty to plus twenty-five per cent on the same processes.

They overestimate when the process is painful: the person remembers the hard cases. They underestimate when it is routine: nobody counts the interruptions, restarts and checks.

The only reliable method is direct observation: sit next to the person, time several real runs, and also measure the real frequency over a rolling twelve months — not the theoretical frequency.

The full formula

Annual gain calculates simply:

Gain = (unit time × annual frequency × loaded hourly cost) × real automation rate

The last factor is the forgotten one. A robot rarely handles one hundred per cent of cases: it handles the nominal ones and returns exceptions to a human. A realistic rate sits between seventy and ninety-five per cent depending on process variability.

Cost has three components:

• Development, once.
• Licences, every year, often underestimated.
• Maintenance, every year: the item RPA projects ignore most. A robot breaks with every screen change in the target application. Budget between fifteen and twenty-five per cent of the build cost per year.

The decision threshold

Our rule: if payback exceeds eighteen months including three years of maintenance, we recommend not automating.

The processes that most often fail that test:

• Those run fewer than twice a month. The absolute gain is too small.
• Those whose rules change every quarter. Maintenance cost exceeds the gain.
• Those handling highly variable cases. The real automation rate falls below fifty per cent and a human has to check everything anyway.

Documenting the refusal

When a process does not pass, write down why. That document has real value for the client: it helps them arbitrate subsequent internal requests without redoing the study.

It is also the best test of the relationship with your provider. A provider who has never recommended against automating a process has probably never done the calculation.

The theoretical-gain trap

A gain of one thousand eight hundred hours a year only becomes a saving if those hours are reallocated or removed. If they are simply given back to people who stay in the same role with the same nominal workload, the gain exists in quality of life but not in the profit and loss account.

That is not an argument against automation: it is an argument for saying honestly, from the outset, which kind of gain is targeted. Projects that promise a budget saving and deliver working comfort are the ones that leave the worst memory.