The workflow that annoys people most is not always the one worth automating first. A better selection uses four dimensions, and a candidate needs to hold up across all of them.
Frequency
Volume creates the return. A task performed forty times a day is a candidate; a task performed twice a quarter usually is not, however irritating it is.
Variation
Count the genuine exception paths. Two or three can be handled. Fifteen means you are automating a decision that has never been defined — and the definition, not the software, is the actual deliverable.
Cost of error
High-stakes steps are not disqualified, but they change the design. They need review, audit trails and a conservative fallback. Automate the preparation and keep the decision with a person.
Integration difficulty
The work is rarely the logic; it is reaching the systems. A workflow crossing three tools with good APIs is straightforward. One depending on a legacy system with no interface and a vendor who charges for access is a different project.
A practical way to rank candidates
- Score each candidate on the four dimensions with the people who run the process
- Estimate hours currently spent, using observation rather than recollection
- Prefer a narrow first workflow that can run unattended within weeks
- Write down what you will measure before starting, so the result is not a matter of opinion
Scoring it in practice
Score each dimension one to five and treat the lowest number as the verdict rather than taking an average. A workflow that runs two hundred times a week but touches a system with no API is not a four out of five; it is an integration project wearing an automation label, and averaging hides exactly that.
Two combinations are worth naming, because they look similar on a spreadsheet and behave very differently. High frequency with low variation is the case automation was built for: the same shape of work, repeatedly, with few branches. High frequency with high variation is the expensive one — the volume makes it look urgent, and the variation means you will spend the budget writing rules for cases that appear twice a year.
A worked example
A finance team asked us to automate supplier invoice processing. Frequency was strong: around three hundred invoices a month. Cost of error was high but manageable, because a person could approve before payment. Integration was reasonable — the accounting system had a usable API.
Variation was where it fell down. Ninety suppliers used their own layouts, eleven sent scanned paper, and four had negotiated terms recorded nowhere except the finance manager’s memory. The right first project was not the automation. It was three weeks spent standardising submission and writing down the terms, after which the same automation became straightforward and considerably cheaper.
Questions to ask the people who run it
- Walk me through the last three times this went wrong — what did you do?
- Which parts do you already do differently from how the process document says?
- What do you check before you trust the output, and what are you checking for?
- If this ran overnight without you, what would you look at first in the morning?
- Who else has to be told when something in this process changes?
The answers usually surface the exception paths the process document omits. That is the point of asking: the gap between the documented process and the practised one is where automation projects overrun, and it is visible in an afternoon if you ask the people doing the work rather than the people who own it.