Ask a management team which processes should be automated and you get a wish list shaped by frustration. Frustration is a poor guide — the most irritating process is often irritating because it happens rarely and nobody has practice at it.
Here is a more structured way to walk through a company and come out with a genuine shortlist.
Follow the queues, not the complaints
The most reliable indicator is where work waits. Look for the trays, folders, inboxes and statuses where items sit before someone gets to them.
A queue means arrival exceeds handling capacity. That is a structural signal, and unlike a complaint it is visible in your systems. Ask where things pile up and how long they typically sit — the second number is often more revealing than the handling time.
Ask what people do first thing on Monday
Recurring administrative work clusters at predictable times. The tasks people describe as "getting through the backlog" are usually routine, volume-driven and text-heavy — the exact profile that suits AI.
Similarly, ask what has to be finished before someone can go on holiday. That surfaces work that only one person can do, which is both a risk and a candidate.
Find where the same information is retyped
Any point where a person reads from one system and types into another is a candidate. This is dull, error-prone, and it happens far more than most managers realise because nobody reports it as a problem — it is just how the job works.
Ask people to describe their morning literally, step by step. Retyping shows up immediately when described concretely, and never when described in the abstract.
Look at what is asked repeatedly
If colleagues frequently ask the same person the same questions, that is a knowledge retrieval problem with a clear shape. It also has a hidden cost: the interruptions land on your most experienced people.
Notice what is not done
Some of the best opportunities are not slow processes but work that never happens because nobody has the hours: analysing complaints for patterns, reviewing old contracts, keeping documentation current, following up dormant enquiries.
These do not appear on any list of painful processes, because they do not appear at all. Ask what people would do if they had a spare day a week — the answers are often more valuable than the tasks they currently resent.
Then filter honestly
Take the candidates and check each against four things: does it happen often enough to matter, is it mostly language work rather than calculation, is a wrong answer caught before it does damage, and can someone articulate what a good result looks like.
Anything failing the third or fourth test is not ready — not necessarily unsuitable, but requiring work on the process before any automation.
Pick the boring one
Given a shortlist, the temptation is to choose the most strategically impressive item. For a first project, choose instead the one with the clearest success criteria and the cheapest failure.
The purpose of the first project is not the saving. It is learning how your own organisation responds — where review really happens, who adopts, what your data is actually like. That knowledge makes every subsequent project faster, and you would rather acquire it somewhere forgiving.
