Choosing your first automation: a scoring method that beats intuition

The first automation in a business is never really about the process. It is about whether anyone believes in the second one.

Which is why choosing it by intuition goes wrong so often. Intuition selects the process that annoys people most, and the most annoying process is frequently the one with the highest judgement content, the worst data, and the strongest opinions attached — a combination almost designed to produce a disappointing first result.

Here is a scoring method that has held up better for us.

The four factors

Score each from 1 to 5.

Volume (V). How often does this run? Daily beats monthly. A process that runs four times a year cannot repay much, regardless of how irritating it is each time.

Structure (S). How much of the work has a defined right answer? Not "could a person do it quickly" but "could the rule be written down". If a step requires knowing the customer, negotiating, or weighing something ambiguous, that step is judgement — though the steps either side of it usually are not.

Reach (R). How many people or downstream processes benefit? A process that unblocks three departments scores higher than one that helps one person, even if the hours saved are similar — because the second automation gets funded by visible benefit, not by a spreadsheet.

Friction (F). How hard is it to reach the data and systems? Score this inversely: 5 means clean APIs and available data; 1 means a closed system with screen-only access.

Then:

Priority = (V × S × R) ÷ (6 − F)

The denominator is deliberately harsh. Integration difficulty is the factor most consistently underestimated, and dividing by it rather than subtracting keeps it dominant.

A worked example

A distribution business with four candidates:

Invoice matching wins by a wide margin, and it is not the process anyone complained about. The complaints were about quote preparation — which scores poorly because the work is genuinely judgement-heavy (S = 2), so automation would address the visible symptom and deliver much less than expected.

Board reporting is the classic trap. High reach, everyone would notice, the finance director is enthusiastic. Monthly volume means it can be excellent and still barely repay the effort.

Two processes that look ideal and are not

The one that is about to change. If the process is under review, a new system is coming, or a regulation changes next year, you are automating something with a known expiry date. Wait, or automate only the stable part.

The one owned by nobody. A process spanning three departments where each owns a step and nobody owns the outcome will produce excellent technical work and no adoption. There will be no one to decide the exceptions, and exceptions are where the design questions live. Find an owner first; if you cannot, that tells you something.

After you have a candidate

Three checks before building.

Measure the baseline. Cycle time, volume, error rate, where work waits. Without this you cannot demonstrate the result, and you will not be able to defend the second project when someone asks what the first achieved.

Walk the actual process, not the described one. The process people describe is always tidier than the one they run. The undocumented exception handled by one person on Fridays is usually the requirement that determines the design.

Decide what the recovered capacity is for. Before starting. Teams that decide in advance get a return; teams that do not absorb the time invisibly and then struggle to explain what changed.

Where AI fits in this

Notice that none of the above mentions AI. That is intentional.

Structure (S) is what determines the technique. High-structure work is deterministic automation — rules, integrations, workflow. It is unglamorous, reliable, and where most of the value in most businesses still sits.

Language models change one thing specifically, and it is a significant thing: they raise the achievable score on processes whose inputs are unstructured. Work that arrives as email, documents or free text used to score low on Structure because the input was unstructured, even when the decision was perfectly rule-based. That is now often addressable.

So the practical use of AI here is not "which process should we use AI on". It is: re-score your candidates, and see which ones move.

---

If you want to size the opportunity before choosing, the automation opportunity calculator puts a number on the repetitive work across your business, with every assumption published next to the result.