Workflow automation: how to find the process worth automating first

Automation is a fixed cost that pays back per execution. A task performed forty times a day pays back its automation almost immediately; a task performed once a quarter almost never does, no matter how painful it is.

Look for the tasks so routine nobody complains about them anymore: copying orders from email into the system, matching payments to invoices, updating a status board. Their invisibility is exactly what makes them expensive. They've been absorbed as 'just how things work'.

Some manual tasks fail cheap: a typo in an internal note costs nothing. Others fail expensive: a mistyped dispatch address, a payment matched to the wrong invoice, a patient record attached to the wrong file. The cost isn't the error itself. It's the detection delay. Manual errors tend to surface days later, when unwinding them costs ten times the original task.

At one client, reconciling payments by hand was 'only' 20 hours a week, but the real driver for automating it was the handful of mismatches per month that each took days to trace. The hours justified the project; the error cost is what made it urgent.

The best automation candidates are tasks where a competent person follows rules they could explain: if the invoice number matches and the amount matches, reconcile; if not, flag it. If the person doing the task makes genuine judgment calls (assessing, negotiating, weighing context), full automation will produce garbage and erode trust in the system.

The practical pattern for judgment-heavy work is partial automation: let the system handle the 80% of cases that follow the rules and route the genuinely ambiguous 20% to a human review queue. You keep the judgment, lose the drudgery.

Score your candidate processes on all three factors. The winner is almost never the flashiest project. It's usually something mundane like order intake or reconciliation that scores high across the board.

Then scope the first version smaller than feels natural. The goal of the first automation isn't to eliminate the job; it's to prove the pattern works, build trust in the system, and learn where the real edge cases are. Every successful automation program we've been part of started with one boring, high-frequency, rule-clear process and grew from there.