Automation projects fail for predictable reasons. Someone automates the most visible task rather than the most expensive one, or they automate a process that was broken to begin with and simply make it break faster.
**Start with frequency multiplied by pain**
A task that takes ten minutes and runs twice a day costs far more per year than a task that takes four hours and runs once a quarter. Rank candidates by total annual hours, not by how tedious they feel in the moment.
**Fix the process before you encode it**
Automating a bad process locks it in. If a workflow has three approval steps that exist only because of an incident five years ago, remove the unnecessary steps first, then automate what remains.
**Design for the failure case from day one**
The real work in automation is not the happy path. It is what happens when the upstream API is down, the document is malformed, or a human needs to intervene. Build the exception queue, the retry policy and the alerting at the same time as the feature.
**Measure the result**
Record the baseline hours before you start. Without that number you cannot demonstrate value, and the next automation project becomes much harder to justify.
Not every repetitive task deserves a script. A simple filter for deciding which manual processes are worth automating first.
