Choose a task you can describe from beginning to end
A useful first automation has a recognisable trigger, a clear output and a person accountable for the result. “Improve sales with AI” is too broad. “Prepare a draft response for incoming enquiries and send it to the account owner for review” is something a team can examine and test.
List the steps people perform today. Mark where information is copied, where judgement is used and where work waits for another person. Some of those delays may be fixed through a simpler process without AI.
Measure the current process
Record weekly volume, time per item, checking time and the frequency of exceptions. Use a representative period. A single unusually busy afternoon can make a weak business case look attractive.
Also record quality. A faster process that sends the wrong information or creates duplicate records may simply move the work into a more expensive clean-up queue. Define what a good output looks like before choosing the technology.
Try a conservative worked example
Illustrative example: 100 items a week at six minutes each take ten hours. If automation reduces the total handling time, including review, to three minutes per item, the team reclaims five hours a week. At an assumed £35 per hour over 52 weeks, that is £9,100 of annual staff capacity before running costs.
These are hypothetical figures, not client results. Adjust for holidays, uneven demand, adoption and the effort needed to manage failures. If the available capacity is worth less than the project and operating costs, narrow the scope or choose a different task.
Check information and accountability
Identify the source of truth, the access needed and the person who can resolve conflicting records. Decide which information may reach external tools and whether redacted examples can be used during early scoping.
Keep human review for consequential decisions. Define what happens when an output is uncertain, a required field is missing or a connected system is unavailable. An unattended workflow with no owner is not a complete operating model.
Set a small acceptance test
Choose representative inputs, including awkward examples, and compare the output with your agreed standard. Test duplicate submissions and failed requests as well as successful runs. Record whether a retry can repeat a customer-facing action.
Agree a pilot review point. Compare total handling time, error rates and operating costs with the baseline. Expand only when the evidence supports it. If the first task does not justify a build, that is a useful decision too.