The process people complain about most is not always the best first automation. Good candidates are repetitive enough to matter, stable enough to describe and bounded enough to recover when something goes wrong.
Look for operational drag
Start with queues, spreadsheets, shared inboxes and repeated copying between systems. Ask where work waits, where the same information is checked twice and where staff keep private checklists to make the official process work.
These clues reveal friction. They do not yet prove automation is the answer.
Score frequency, clarity and consequence
A frequent process with clear inputs and modest consequences is usually a better first candidate than an occasional process involving high-stakes judgement.
Document the normal path, the known exceptions and the person who owns the outcome. If the normal path cannot be explained, automation will encode confusion.
Choose a visible measure
Useful measures include handling time, queue age, rework, approval turnaround and exception rate. Pick one or two that reflect the actual reason for changing the process.
Hours saved can be useful, but only if the released capacity is real and the new workflow does not create hidden review work elsewhere.
Design the failure path first
Decide what happens when information is missing, an integration is unavailable or the system is uncertain. A safe workflow pauses, preserves context and gives a person a clear next action.
Recovery is part of the product, not an edge case to solve after launch.