The best first automation is frequent, rule-based, measurable and painful enough that the organization will support changing it.
Score frequency and friction
Count how often the process occurs, how long it takes and how much delay or rework it creates. Anecdotes are useful, but a baseline helps compare opportunities.
Test rule stability
A process with clear inputs and stable decisions is easier to automate. If staff constantly reinterpret policy, redesign and clarify it first.
Design the exception path
Automation is defined by what happens when data is missing, a service is unavailable or confidence is low. Give exceptions an owner and a visible queue.
Measure the operational result
Track cycle time, manual touches, outstanding exceptions and user experience—not merely that the automation executed.
A practical checklist
- Name the outcome in plain language.
- Map the current people, responsibilities and exceptions.
- Separate evidence from assumptions.
- Make ownership, cost and operating risk visible.
- Choose the smallest next step that reduces a material unknown.
What to bring to a first discussion
Bring one real example of the workflow, the people involved, the constraint you feel most often and what a useful outcome would change. You do not need a finished specification.
For direct help with this decision, see Automation that removes repetitive work without removing control.