How to decide whether a process should be automated
Frequency, variance, cost of error, and who owns the exception. The scoring sheet we use in every audit.
Most teams can list a dozen things they would like to automate. Fewer can say which of those would actually pay back. We use four questions to sort them before any build starts.
1. How often does it happen?
Frequency multiplies everything. A ten-minute task done forty times a day is more valuable than a two-hour task done once a quarter. Count real occurrences from the last month, not estimates.
2. How much does it vary?
Automation handles the cases you designed for. If every instance of a process looks different, most of the work moves into exception handling. We look for processes where at least 70–80% of cases follow the same path.
3. What does a mistake cost?
A wrong tag on a support ticket is cheap to fix. A wrong payment is not. High cost of error does not rule automation out, but it means adding validation and a human approval step, which changes the effort estimate.
4. Who owns the exception?
Every automation produces cases it cannot handle. If no one is responsible for those, they pile up silently. A process is ready to automate when there is a named person or team who will work the exception queue.
A process is ready to automate when someone owns the cases the automation cannot handle.
Putting it together
- 01Score each question 1–3.
- 02Multiply frequency by minutes saved for a rough weekly value.
- 03Discount for variance and cost of error.
- 04Drop anything without an exception owner until it has one.
The result is rarely surprising, but it is useful to agree on. It turns a long wish list into a short, ordered roadmap that the whole team can defend.