Short answer
Score every candidate on volume, repetition, human time consumed, data availability, share requiring judgement, and consequence of error. The first four determine whether automation is worth it; the last two determine what the system is allowed to do unattended. High volume, high repetition, low judgement and good data availability is where the first project belongs — and consequence of error sets the boundary rather than disqualifying the process.
Why intuition picks the wrong process
Asked which process to automate, most teams name the one that annoys them most. Annoyance correlates poorly with value. A task performed twice a week that everybody hates is worth less than a task performed two hundred times a week that nobody notices, and the second one is usually invisible precisely because it has been absorbed into how people work.
The four factors that decide whether it is worth it
- Volume — occurrences per week. Below a threshold, engineering cost never amortises no matter how irritating the task.
- Repetition — whether each instance has the same shape. Sameness is what makes automation reliable rather than merely possible.
- Human time — minutes per occurrence multiplied by fully-loaded cost. This is the value at stake and it should be measured, not estimated from memory.
- Data availability — whether the information the system needs is reachable. If it lives in someone's head or an unexported system, that is a different and larger project.
Data availability is the factor most often skipped and the one that most often kills a project mid-build. Establish it before committing, not after.
The two factors that decide what it may do
Judgement and consequence of error do not tell you whether to automate. They tell you where the boundary sits.
A process with high consequence of error is not disqualified — it is a process where the system prepares and a person authorises. Payment runs are a good example: preparation is highly automatable, release should never be. Treating consequence as a veto rather than a boundary is how organisations end up automating only trivia.
Score it, then argue about the weights
The point of writing the scores down is that the argument becomes explicit. Someone will disagree that a process is genuinely repetitive, or that the data is reachable. That disagreement is the most valuable conversation in the whole exercise, and it cannot happen while the reasoning stays in someone's head.
A recommendation you cannot interrogate is an opinion in a nicer font.
The processes that score well and still should not be first
Two exceptions are worth holding. A process that is about to change substantially — a system migration, a regulatory shift, a restructure — should wait, because you would be automating something with a short remaining life. And a process nobody can fully explain should be investigated before it is encoded, since automating an unexplained step preserves it permanently.
Value — is it worth doing
- Repetition/10
- Human time/10
- Cost of that time/10
- Revenue impact/10
- Data availability/10
- AI feasibility/10
Boundary — what it may do
- Risk if wrong/10
- Implementation difficulty/10
Reading the result
| Value score | Risk | Treatment |
|---|---|---|
| High | Low | Fully automated |
| High | High | Prepare, approve |
| High | Judgement led | Assist a person |
| Low repetition or data | Any | Fix process first |
Six factors establish whether automation is worth doing. Two establish what the resulting system may do unattended. Keeping them separate is why risk sets a boundary rather than acting as a veto.
Last updated 2026-09-05 · Koderead
Related
Apply this to your own business
Eleven questions, scored in your browser, with the arithmetic shown.
Find my AI opportunities