The short answer
The first automation should be chosen for its chance of succeeding, not for the size of the prize. A visible success buys support for everything afterwards.
Frequent, rule-based, low risk and wanted by whoever owns it. All four matter.
What makes a good first candidate
| Attribute | Why |
|---|---|
| Happens often | Benefit accumulates quickly |
| Rules are clear | Little judgement to encode |
| Few exceptions | Exceptions are most of the work |
| Low consequence if wrong | Mistakes are recoverable |
| Somebody wants it | Adoption is not a fight |
The last row is frequently decisive. Automating something for a team that did not ask produces a system nobody uses and a reputation problem.
What to avoid at first
- Processes where every case seems to be an exception
- Anything where a mistake is expensive or public
- Processes nobody owns clearly
- Anything depending on a system being replaced soon
- Work that should be eliminated rather than automated
The last point deserves a proper look. Automating a report nobody reads preserves it indefinitely at additional cost.
Understand the exceptions first
- List the cases that do not follow the standard path.
- Estimate how often each occurs.
- Decide which the automation handles and which it passes on.
- Make passing on the case a normal outcome, not a failure.
- Check the residual manual work is genuinely smaller.
Point four matters for design. An automation that handles eighty percent cleanly and routes the rest to a person is a success; one that attempts everything and gets some wrong is not.
Measure before, not just after
Record how long the process takes and how often it goes wrong before you change anything. Without that, the benefit afterwards is an assertion.
It takes an hour and it is the difference between a demonstrated improvement and a claim nobody can check.