Most failed automation projects were not built badly. They were pointed at the wrong process. Choosing the target well is the highest-leverage decision in the whole effort, and it is a decision you can make systematically rather than by instinct.
Start by watching, not asking
Asking a team which tasks waste their time produces a list of the most irritating work, not the most expensive. Irritation and cost correlate poorly: a five-minute task done forty times a week costs far more than the hour-long task everybody complains about.
The more reliable method is to look at where work actually accumulates — inboxes, shared folders, spreadsheet trackers, and the recurring meetings that exist only to chase status. Those are symptoms of a process with no owner and no automation.
Build the inventory
List candidate processes with four numbers against each. You do not need precision; you need enough to rank them relative to one another.
- How often it runs, per week
- How long one instance takes, measured rather than guessed
- Who does it, and their fully loaded hourly cost
- How many systems it touches
The four tests a candidate must pass
Frequency alone does not make a process automatable. Before committing, check it against four conditions. A candidate failing any of them is not disqualified forever, but it is a poor first project.
- Repeatability: the steps are broadly the same each time
- Describability: you could teach it to a new hire in a morning
- Observable inputs: the information needed arrives somewhere a system can reach
- Checkable output: someone can tell whether the result is right
Score, then sort
Multiply frequency by handling time by hourly cost for the annual cost of each process. Then discount by how confidently it passes the four tests. The highest-scoring process after that discount is usually the right first target, and it is rarely the one people nominated.
Systems touched is a proxy for build effort rather than value — useful as a tiebreaker between two similar candidates, and a reason to prefer the simpler one first.
The traps that look like good candidates
Two categories reliably disappoint. The first is the process everyone hates: usually hated because it is genuinely complex or politically contested, neither of which automation fixes. The second is the rare-but-painful process, where annual volume is too low to repay the build no matter how unpleasant each instance is.
A third, subtler trap is the process that only one person understands. It can be automated, but the mapping work is substantial and depends entirely on that person's availability.
Map it before you build it
Once a target is chosen, document how the work actually happens — not how the process documentation says it happens. The gap between the two is where the workarounds live, and the workarounds are usually the part that matters.
This step frequently pays for itself independently. It is common to find steps that exist only for historical reasons and can be removed outright, which is cheaper than automating them.
Define done before you start
Agree what success looks like and how it will be measured before anything is built, using a measure you already track. Capture the baseline while the process is still manual. A baseline reconstructed afterwards is the most common reason automation results end up disputed.
Frequently asked questions
How do we find automation candidates if nothing is documented?
Look at where work piles up rather than at documentation. Shared inboxes, spreadsheet trackers, recurring status meetings, and folders full of near-identical documents all indicate a repetitive process that nobody owns, which is exactly the profile of a good candidate.
Should we automate the process people complain about most?
Usually not first. The most-complained-about process is often complex or politically contested rather than simply repetitive, and neither of those is solved by automation. High-frequency, low-drama work almost always produces a clearer early result.
How many processes should we evaluate at once?
Evaluate broadly and build narrowly. Inventorying ten or fifteen candidates is cheap and gives you a ranking, but the first build should target a single process so the result is unambiguous.
What if the process changes every few months?
Then design for that from the start, keeping the variable parts configurable rather than fixed in code. A process that changes often is still automatable; it just should not be built as a rigid sequence that needs an engineer for every adjustment.
Do we need to fix the process before automating it?
Often yes, at least partly. Mapping usually surfaces steps that exist only for historical reasons. Removing them is cheaper than automating them, and automating a broken process simply makes the broken outcome arrive faster.
