Look for a repeated process with a clear finish
Good candidates have accessible inputs, enough repetition to measure, an identifiable owner and an outcome that can be checked. An enquiry becoming a reviewed brief is easier to evaluate than an open-ended ambition to “automate operations”.
Record the trigger, steps, handoffs, decisions and destination. Observe a sample of normal tasks and exceptions. If nobody agrees on the current process, resolve that uncertainty first: automation will otherwise reproduce conflicting interpretations at greater speed.
Use rules for the predictable steps
Checking whether a required field exists, assigning a known team or updating a timestamp can usually use conventional logic. AI may help where a step involves reading a message, classifying an unusual document or drafting a useful summary.
A practical enquiry flow might validate a form, create a CRM record, ask AI to propose a brief, route the brief for review and then assign the next action. If the integration fails, the original enquiry remains stored and a staff member can see the problem. Each step needs a defined failure path.
Measure the baseline before building
| Measure | What it tells you |
|---|---|
| Hands-on time | How much staff effort is required per completed task. |
| Cycle time | How long the customer or next team waits. |
| Rework and errors | Whether faster processing creates extra correction. |
| Exception rate | How often normal handling is insufficient. |
| Cost per accepted task | Whether the complete process is economical. |
Define an accepted task before measuring it. Producing a draft that someone must completely rewrite is different from finishing usable work. Compare the same task boundary before and after the change.
Calculate value with the operating costs included
An illustrative team handling 300 tasks a month and removing five minutes of work per task would release 25 hours. At an assumed internal cost of £25 per hour, that represents £625 of monthly time value before software, model usage, review and maintenance costs. These are example inputs, not client results or a promised saving.
Released time is not automatically a cash saving. Explain whether it lets the team handle more demand, respond sooner or reduce overtime. Include the one-off implementation cost and consider whether demand changes enough to affect the calculation.
Design the exception queue before the happy path goes live
Identify who receives an ambiguous task, what information they see and how quickly it needs attention. Use stable record identifiers so retries do not create duplicate contacts or send the same message twice. Log the status of each step and make failed tasks recoverable.
Introduce the workflow alongside the existing process, review a representative sample and agree the release criteria. Continue monitoring after launch because source formats, provider APIs and staff practices change. A process that worked during a small trial still needs operational ownership.
Connect the next workflow only when the first is dependable
Expansion should follow evidence: accepted outputs, manageable exceptions and a clear operating arrangement. Reuse reliable components such as identity matching, review queues and audit records, while testing the new task’s own risks.
For practical planning, use the readiness checklist and AI integration guide. The automation FAQs cover common questions about existing tools, failures and support.
Written for Orwell Lab’s practical guide collection. Examples and calculations are illustrative unless a project is specifically identified.
Discuss your own requirements ↗