How to tell if a process is worth automating

Most automation projects are chosen badly. Not built badly — chosen badly. The process that gets picked is the one that is annoying, or visible, or that someone senior complained about recently. Whether it is the one costing the most is rarely established.

Here is the test we use, in the order we use it.

1. Count it before you judge it

Take the process and write down two numbers: how long one instance takes, and how many instances happen in a month. Multiply.

This step reorders almost every list it is applied to. A quarterly reporting process that consumes two miserable days feels enormous — it is about sixteen hours a quarter. A four-minute task done thirty times a day is forty hours a month. The second one is worth six times the first and nobody was annoyed by it, because it never took long enough to complain about.

Frequency beats duration, nearly always. If you only do one thing from this article, do this one.

2. Ask how rule-shaped the decision is

Now look at what actually happens inside the task. Is the person applying rules, or applying judgement?

Rule-shaped work looks like: if the invoice is from this supplier, code it there. If the enquiry mentions these words, it goes to that team. Extract these five fields. Check this against that. The person doing it could write down what they do, and someone else could follow it.

Judgement work cannot be written down that way, and the tell is that the person keeps saying “it depends”. That is not a failure of explanation — it means the decision is genuinely drawing on context that is not in the document in front of them.

Rule-shaped, high frequency work is the sweet spot. Judgement work at low frequency is the worst possible candidate, and it is very often the one people nominate first because it is the part of the job they find hardest.

3. Find the exceptions before you commit

Ask: how often does this run exactly as described?

The answer is often something like “most of the time, except when the supplier sends a PDF, or when it is a repeat customer, or at end of month”. Those exceptions are where automation projects die. The system handles the clean case, a person quietly handles everything else, and everyone slowly notices that the clean case was only sixty per cent of the volume.

If exceptions are more than a fifth of instances, either design for them explicitly or choose a different process. Do not assume they will be rare in practice because they feel rare in the meeting.

4. Work out what being wrong costs

For each instance, if the automation got it wrong and nobody caught it — what happens?

Sometimes: nothing much, an odd label, fixed in seconds. Sometimes: a customer gets an incorrect quote, or a payment goes to the wrong account, or something goes out under your name that should not have.

This does not decide whether to automate. It decides how. Low cost of error gets full automation. High cost of error gets automation that prepares the work and stops, with a person approving. That second design is less impressive and it is the one that survives contact with a real business.

5. Check you are not automating a broken process

The last question is the one people skip: should this work exist at all?

A surprising amount of repetitive work is there to compensate for something else — a report nobody reads, a duplicate record created because two systems were never connected, an approval step added after an incident in 2019 that nobody has revisited. Automating that work makes it permanent. It stops being visible, so it stops being questioned.

Deleting a process is cheaper than automating it, and considerably cheaper than maintaining the automation for the next five years.

The short version

Frequency times duration, ranked. Rule-shaped, not judgement. Exceptions understood before you build. Cost of error deciding the design rather than the decision. And a genuine check that the work should exist.

If a process passes all five, it is probably worth automating. If it fails the last one, the best technology decision available is to stop doing it.