Four tests every automation candidate should pass before you build it

Every operations team has a list of processes people want automated. The list is almost always ordered by irritation rather than return — the loudest complaint goes first. These four tests reorder it by what the business actually gets back.

Test 1 — Volume × handling time

Multiply the number of transactions a year by the minutes each one takes. If the product is under a few hundred hours a year, the automation will cost more to build and maintain than the labour it replaces. This kills more candidates than any other test, and it kills them in about ten minutes.

Watch for the seasonal trap: a process that runs 400 times in one week and twice a month otherwise looks large in aggregate and small in practice. Capacity recovered during a peak is worth more than the annual average suggests.

Test 2 — Input stability

Automation is brittle where inputs vary. Ask two questions:

• How many formats does the input arrive in? Three PDF layouts is a project. Thirty is a research programme.
• How often does the upstream system change? If the source screen is redesigned quarterly, a screen-scraping robot becomes a permanent maintenance line item.

Where inputs are genuinely unstable, the honest answer is often to fix the intake, not to automate the downstream mess. Standardising a supplier’s file format is unglamorous and frequently returns more than the robot would have.

Test 3 — Decision density

Count the judgement calls per transaction. Rules-based decisions — thresholds, lookups, matching — automate cleanly and predictably. Genuine judgement does not, and the attempt usually produces an automation that handles 60% of cases and a human process to handle the exceptions, which is now two processes to maintain.

The productive question is not “can AI make this decision” but “can this decision be made once, as a rule, rather than repeatedly, as a judgement.” Often it can, and nobody has ever been asked to write the rule down.

Test 4 — Ownership after go-live

Name the person who owns the automation in production before you build it. If that name is a consultant, or the answer is “IT will pick it up,” the automation has an expiry date. Automations fail quietly: an upstream field changes, the bot starts skipping records, and nobody notices for a quarter because the work appeared to be getting done.

An owner needs three things: a weekly measure of throughput, an alert when volume deviates, and the authority to pause the automation and fall back to manual.

Running the tests

Score each candidate 1–3 on the four tests and sum them. Anything scoring 10+ is a build. 7–9 is a build after a specific fix — usually to inputs or ownership. Below 7, the process needs redesign before any tool touches it.

This is deliberately crude. The point is not precision; it is to force the comparison to happen before the budget is committed, on evidence anyone in the room can check.

---

We run this ranking as part of every Process Evaluation, with a projected annual return attached to each candidate.