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.

The short answer. The best processes to automate first are those that are frequent, governed by a rule you can write down, low-consequence when they go wrong, and visible when they fail. Those are four properties: volume, determinism, blast radius and observability. Score each from 1 to 5, multiply, and rule out anything that scores 1 on blast radius or observability. The first step, before you score anything, is to look at how the work actually runs today: who does it, in what order, and where it waits.

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 a scoring pass to 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 tend to overestimate the annoying tasks and underestimate the routine ones.

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 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. How to document a process covers writing it down.

The rule should also be stable, and the inputs should arrive in a consistent form. A rule that changes every quarter needs an owner who will change the automation with it. And a step that goes wrong often is not automatically a good candidate: a repeated mistake usually means an unclear rule or inconsistent inputs, and automating it repeats the mistake faster. Fix the rule or the inputs first.

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. Running, reporting and working are three different things; how to tell whether an automation is actually working goes further.

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 instead of averaging it away against three strong ones. Then apply one rule the arithmetic cannot: anything that scores 1 on blast radius or observability is not a first candidate, whatever its total. A process scoring 1, 5, 5, 5 multiplies to 125 and would outrank a steady 3, 3, 3, 3 at 81; if its 1 is observability, fix the record before you automate it.

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 makes the work easier to teach.

Typical examples

These are illustrations, not rules; your own scores decide. Work that tends to score well first: moving the same data between two systems, assembling a recurring report from the systems of record, routing inbound requests to the right owner, and scheduled reminders and status chasing. Work that tends to score badly first: pricing exceptions, disputes, hiring and termination decisions, and anything that makes a commitment to a customer.

What is an automation-first approach, and should you take one?

"Automation first" is used two ways. In one, it is a design rule: build every new workflow so it can be automated from the start, with structured data and defined handoffs. In the other, it is a default: when a problem comes up, ask how to automate it before asking anything else, and leave to people only what is left over. Software vendors, IT services firms and test-automation teams use both, and most are careful to say it is not about replacing people. A third use puts automation ahead of AI: standardize and connect the repeatable work before asking AI to reason over it.

We agree with the instinct under it. Automation should be a first option, not a last resort, and work whose data and handoffs are written down is easier to automate. Where we part ways is the order. Putting automation first skips the step that decides whether it works: knowing how the work runs today. A process described from memory is not the process that runs, and automating the description repeats the gap faster instead of closing it.

Our order is look, baseline, automate. Look first: map how the work actually runs, who does each step and where it waits. Then put the baseline in place: project management, connected systems and written processes. Then automate what scores well on the four properties above, with a person approving what matters. AI belongs in the third step, on top of the baseline, not in place of it.

So should you take an automation-first approach? As a habit of asking "could this be automated?", yes. As a sequence, automate first and sort out the process later, no. The scoring pass above is how the two fit together: it tells you which of the things you could automate you should automate first. The three traps below are what the other order tends to produce.

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.

← All writing