Automation programmes rarely fail at the build stage. They fail at selection. The first candidate process is usually whichever one a senior person found most irritating, and irritation is a poor predictor of return.
Five factors will tell you most of what you need to know before you commit a budget. None of them require a tool, and all of them can be answered in a fortnight.
1. Volume: is there enough of it?
Automation has a fixed cost to build and a recurring cost to maintain. Both are largely independent of how often the process runs. A process executed forty times a month has to be extraordinarily painful to justify either.
The useful figure is not transactions but total annual minutes: frequency multiplied by handling time. A five-minute task run two hundred times a day is a far better candidate than a two-hour task run weekly, even though the second one feels worse to the person doing it.
2. Variability: how similar is each execution?
Rule-based work with consistent inputs automates well. Work requiring judgement about ambiguous inputs does not, and no amount of tooling changes that.
A practical test: ask two experienced people to process the same twenty items independently. If they agree on nineteen, the process is rules-based enough to automate. If they agree on twelve, you have discovered that the process contains undocumented judgement, and automating it will encode one person's version of that judgement as though it were policy.
3. Exception rate: what does the unhappy path look like?
This is the factor most assessments skip, and the one that most often kills the business case after build. If a third of transactions divert to a human, the automation is handling the easy two-thirds while the hard third still needs a team.
Before anything else, classify the exceptions by cause. In accounts payable, for example, the top causes are usually predictable:
- Missing or incorrect purchase order references
- Goods receipt not yet posted at the time of invoice
- Price or quantity tolerance breaches
- Suppliers not present in master data
- Duplicate submissions across intake channels
Several of those are caused upstream and can be fixed without any automation at all. Fixing the cause removes the exception permanently; automating around it means maintaining the workaround forever.
4. System stability: what is underneath it?
Automation sits on top of systems that change. Every upgrade, interface redesign and field addition is a potential break, particularly for UI-level automation.
Ask three questions about every system the process touches:
- 1Is it scheduled for replacement or major upgrade in the next eighteen months?
- 2Does it expose an API, or will automation have to drive the interface?
- 3Who tells you when it changes, and do they know the automation exists?
A process running against a system due for replacement next year is a bad candidate regardless of how well it scores on everything else. A process running against a well-documented API is a considerably better one than its volume alone would suggest.
5. True cost: what is it actually costing you today?
Business cases tend to use loaded salary cost multiplied by hours, which overstates the benefit unless those hours are genuinely redeployed. If three people spend 20% of their time on a process and you automate it, you have not saved 0.6 of a person unless that capacity goes somewhere useful.
The costs that are frequently larger and almost always omitted:
- Error correction — the downstream cost of mistakes, including the ones caught late
- Cycle time — what the delay itself costs in working capital, customer experience or penalties
- Key person risk — what happens when the one person who understands it takes leave
- Opportunity cost — what skilled people would do instead
Scoring it
Score each factor one to five and look at the shape rather than the total. A process scoring highly on volume and stability but poorly on variability may be worth automating in part — the consistent 60% straight through, the rest to a review queue. A process scoring well everywhere except system stability should wait until the underlying replacement lands.
| Factor | Strong candidate | Weak candidate |
|---|---|---|
| Volume | High total annual minutes | Infrequent, even if painful |
| Variability | Experts agree on outcomes | Outcomes depend on who handles it |
| Exception rate | Low, or causes are fixable upstream | High and structurally variable |
| System stability | API access, no replacement planned | UI-only, upgrade imminent |
| True cost | Capacity has a clear redeployment | Savings are notional headcount |
The output nobody expects
A good assessment produces two lists. One is the ranked automation pipeline. The other is the list of processes you should not automate, with the reasoning recorded.
The second list is the more valuable of the two. It stops the same candidate being proposed every six months, and it is the clearest evidence that the assessment was an analysis rather than a sales exercise.