Automation decisions should begin with a recurring business problem, not a tool demonstration. A task is a good candidate when its inputs are understandable, its rules are reasonably stable and somebody can recognise a wrong result before it causes damage.
Start with a five-day task log
Record the trigger, steps, people involved, frequency and typical handling time. Include interruptions and rework. “Answer enquiries” is too broad; “copy a completed website form into the customer record and notify reception” is a workflow you can inspect.
Score each candidate against four questions:
- Does it recur often enough to justify maintaining a system?
- Can you define the required output and acceptance criteria?
- Are exceptions identifiable and assignable to a person?
- Can the team recover if the automation stops?
Pilot a bounded slice
For example, route completed enquiry forms while leaving pricing decisions with the team. Test duplicates, missing details and requests sent outside opening hours. Compare handling time and routing accuracy with the previous process. Record supervision and correction time as well as time saved.
Do not automate a process nobody owns. A broken handoff can become faster without becoming better. Appoint a workflow owner, define who receives failures and keep a manual alternative available.
The first useful automation usually makes a small promise reliably. Choose one measurable outcome, such as correctly assigning enquiries, and review it after a defined trial. Expand only when the team understands both normal operation and recovery.