Operational automation: which process first, and how to measure it
The first process worth automating isn't the one that takes the most time. It's the one that repeats often, has clear rules, and fails visibly.
The most common question when an organisation starts automating: "which process should we do first?"
The intuitive answer — "the one that eats the most time" — is usually wrong. The process that eats the most time usually eats it because it's complex and full of exceptions, which makes it the hardest to automate and the most likely to fail silently.
There's a better set of criteria.
Four criteria for choosing
Frequency beats duration
A task that takes 3 minutes and runs 200 times a month is a better first target than one that takes 2 hours and runs twice — even when total hours saved are similar.
The reason isn't the hours. High-frequency work gives you enough samples to know what the rule actually is; rare work differs every time, and you'll automate against an unrepresentative sample.
Clear rules, few exceptions
If the rule is "orders under 10 million are approved by the department head" — automatable today.
If it's "depends on the customer, depends on the situation, Lan knows" — not yet. The first step here isn't code; it's asking Lan what the rule really is, writing it down, and letting people argue with it. Very often the writing-down alone produces most of the value, because it converts private knowledge into organisational knowledge.
Failure is visible
This is the criterion most often skipped, and it governs your risk.
Automate "send a payment reminder" wrongly and somebody responds the same day. Automate "allocate landed cost into COGS" wrongly and the auditors find it six months later, when it can no longer be fixed.
Start with the first kind. Build trust on work where errors announce themselves, before touching work where errors stay quiet.
Somebody owns it
An automated process still needs a person who can answer "why didn't it run today?". Without that person, a broken automation just sits there — and it sits in the worst possible way: everything still looks normal.
Three groups worth doing first
In most organisations these three satisfy all four criteria:
Approval routing. Who approves what, at which threshold, and automatic escalation when it's overdue. Clear rules, high frequency, and failures get reported immediately.
State-based reminders. Overdue invoices, stuck orders, contracts nearing expiry, assets due for maintenance. This is the class of work humans do worst — not because it's hard, but because it requires remembering consistently.
Generating the next document in a chain. Sales order to delivery note, delivery note to invoice, invoice to journal entry. The data already exists upstream; re-keying it only creates opportunities to diverge.
Three groups to postpone
Pricing decisions with exceptions. Discounts, special terms, customer-specific deals. The rules are usually far more complex than described, and errors cost real money.
Anything that leaves the building unreviewed. Customer emails, messages, regulatory filings. Draft them automatically, but let a person press send.
Work only one person knows how to do. Not because it can't be automated, but because you don't yet know the real rule. Automating now freezes a rule you don't understand.
How to measure it
Don't measure "number of processes automated" — that metric rewards doing useless things.
Four metrics that reflect real value:
| Metric | Why it's worth measuring |
|---|---|
| Average wait time at each step | This is what customers and staff actually feel |
| Share of cases completing without manual intervention | Measures how well your written rule covers reality |
| Open overdue cases at a point in time | Measures backlog — the thing automation must reduce |
| Manual corrections after the system ran | Measures rule quality; rising means an undescribed exception |
The last one is the alarm. If it climbs, don't patch it with another condition — go back and ask what the real rule is.
A common trap
Automating a broken process produces a broken process that runs faster.
Before automating, run it manually once and answer: is this process currently producing correct outcomes? If the answer is "mostly, we fix it sometimes", then the "we fix it sometimes" part is precisely what you're about to multiply.
In closing
Automation isn't a race to cover the most processes. It's a sequence of moves that transfer knowledge out of people's heads into the system, one process at a time, each one measurable.
Start where the rules are clear and failures are loud. The trust you accumulate there is what earns you the right to touch the harder cases — and by then you'll have the data to do them properly.