The question is not "what is worst?" It is "where is the largest amount of predictable, low-consequence, observable work?" Those are different processes almost every time.

Ask a team what to automate and you will get the thing they hate. Hatred is a real signal — it usually marks work that is repetitive and thankless — but it is a poor ranking function, because the most hated processes are often the ones full of exceptions, judgment, and awkward conversations. Those are the hardest things to automate and the most expensive to get wrong. Starting there is how automation projects earn a reputation for not working.

What follows is the scoring pass we run before building anything. It is deliberately crude. A precise model of a process you have not documented yet would be false precision — and if you have not established how the work actually runs, the ranking is guesswork no matter how many decimal places it carries. If you have not done that groundwork, start with the four sources of truth and come back.

The four properties

01Volume — how much time does it actually consume?

Not how long one instance takes. Frequency multiplied by duration, over a month. A fifteen-minute task done four times a day is a bigger prize than a four-hour task done monthly, and it does not feel that way to anyone doing either of them. Count instances from your systems rather than from memory; people estimate the annoying tasks high and the routine ones low, consistently.

Include the coordination tax. A step that takes ten minutes of work but spends two days waiting in someone's inbox is consuming two days of cycle time, and cycle time is usually what the business is actually paying for.

02Determinism — can the rule be written down?

The real test: could a competent new team member follow your written description and reach the same answer you would, without asking a follow-up question? If yes, the process is deterministic enough. If the honest answer is "they'd need to check with someone," you have found undocumented judgment, and judgment is not an automation candidate — it is a documentation candidate first.

This is the property people misjudge most. A process feels deterministic to the person who has run it for six years because the exceptions live in their head. Write the rule out and the exceptions surface immediately.

03Blast radius — what happens if it goes wrong?

Sort by who absorbs the mistake. Work whose errors stay inside your own operation and are caught in the ordinary course of business is cheap to get wrong. Work that touches a customer, a payment, a regulator, or a permanent record is not — an error there costs money and trust, and it costs them before anyone notices.

Small blast radius should be a starting condition, not a permanent limit. You earn the right to automate consequential work by first proving the governance holds on work where a mistake is survivable. That ordering is the whole argument of what an AI agent should be allowed to do on its own.

04Observability — would you know if it stopped working?

The property nearly every list omits, and the one that decides whether automation is an asset or a slow leak. If a step runs unattended and produces no record, a silent failure is indistinguishable from success until something downstream breaks — weeks later, with no trail explaining when it started.

Before automating anything, answer two questions: what does a correct run leave behind, and who or what looks at it? If the answer to either is nothing, build the record first. An automated process you cannot audit is not a solved problem; it is an unsupervised one.

The ordering rule Volume tells you the size of the prize. Determinism tells you whether it is buildable. Blast radius and observability tell you whether you should go first. A process can be enormous and perfectly deterministic and still be the wrong place to start, if getting it wrong reaches a customer and nothing would tell you it had.

Running the pass

List every recurring process you can name — aim for breadth over precision, twenty or thirty lines is plenty. Then score each one from 1 to 5 on the four properties and multiply. Not because the arithmetic is meaningful, but because multiplication punishes a low score on any single property, which is the behaviour you want: one zero should sink a candidate rather than being averaged away by three strong numbers.

Volume — 1 is under an hour a month, 5 is more than a day a week.
Determinism — 1 is "it depends every time", 5 is "the rule fits on an index card".
Blast radius — score this inverted: 5 means a mistake is invisible outside the team, 1 means it reaches a customer or a ledger.
Observability — 1 is "no record exists", 5 is "every run is already logged somewhere we look".

Sort descending. The top of that list is where to start, and it will usually surprise someone in the room — which is the point. The exercise is worth running even if you never automate anything, because scoring determinism forces you to write down rules that were only ever in someone's head, and that alone tends to shorten onboarding.

Three traps

Automating a process nobody owns

If a process has no named owner today, automating it does not remove work — it hides the work. When it drifts, and it will, there is no one whose job it is to notice. Assign the owner first. The owner of an automated step is the person who reviews its record, which is a much smaller job than doing the step, but it is not zero.

Automating the workaround instead of the work

Long-running operations accumulate steps that exist only to compensate for something else being broken — a reconciliation that only exists because two systems disagree, a status meeting that only exists because nobody trusts the board. Automating those makes the underlying defect permanent and much harder to see. When a process scores well but you cannot say what it is for, that is the signal.

Treating the first build as the finish line

A process automated in March describes March. The business changes; the rule does not, unless something makes it. This is why the loop in our methodology does not end at "build" — the audit and improve steps exist precisely because the first version is always a snapshot of a moving thing.

Where this came from

This scoring pass was not designed at a whiteboard. It is the compressed form of two years of picking first targets — sometimes well, sometimes badly — inside real multi-state operating companies with field crews, seasonal hiring, and the ordinary mess of businesses that were not built to be automated. The observability property is on this list because we once shipped something without it and did not find out for a fortnight.

← All writing