Start with repeated friction, not a fashionable tool
The first automation candidate should be a real workflow that already consumes time, creates avoidable checking or delays an important outcome. Starting with a product or an AI feature reverses the decision: the business begins searching for somewhere to use a tool instead of solving a measured problem.
Choose one process with a clear trigger and finish. Examples include routing an approved enquiry, preparing a standard document from verified data or moving completed field evidence into a job record. Keep the first boundary narrow enough to observe from end to end.
- A named process owner
- A visible trigger and finished outcome
- Enough repetition to justify attention
- A current method that can be observed
Score the workflow before automating it
A strong candidate is frequent, reasonably stable, rules-led and connected to an outcome the business values. The required information is available, exceptions can be identified and somebody has authority to approve the changed method.
A weak candidate depends on disputed policy, undocumented judgement or data that cannot be trusted. Automating it can make the same uncertainty move faster while making responsibility harder to see.
- Volume: how often does it occur?
- Friction: where is information copied, checked or chased?
- Impact: what do delay and error affect?
- Stability: are the main rules agreed?
- Evidence: can a before-and-after baseline be recorded?
- Exceptions: what must stop or reach a person?
Repair the process before connecting systems
Follow representative work through the current route. Identify the authoritative record, duplicate fields, approval points, handoffs and the person who resolves an exception. Remove steps that no longer serve a purpose before encoding them.
The smallest useful improvement may be a clearer form, a shared record, a deterministic rule or a notification. AI is justified only where probabilistic behaviour is useful, testable and surrounded by a suitable review boundary.
Example: give each new enquiry an owner and a next action
Suppose a service business copies website enquiries into a spreadsheet and then asks around to find who will respond. The first useful automation might create one lead record, preserve the requested service, notify the responsible person and show that a response is due. It does not need to price the job, schedule a worker or send an invoice.
Before building, decide how repeat submissions are recognised, who covers an absent colleague and what happens when the destination system is unavailable. An incomplete enquiry should reach a review queue, not disappear. This is an illustrative scope, not a measured client result.
- Trigger: a valid enquiry is received
- Finish: one lead record has an owner and an agreed next action
- Human decision: suitability, pricing and any customer commitment
- Exception: missing information or a failed connection remains visible
Write down a baseline you can actually compare
Observe a representative period before changing the route. Count how many items arrive, how much hands-on time they require, how long they wait and how often someone has to correct or chase information. Use the same definitions during the pilot, including exceptions rather than just the easiest cases.
Compare any measured saving with implementation, subscriptions, support and the team's review time. Do not multiply a best-case demonstration by a whole year and call it a proven return.
- Items processed and the types of exceptions
- Hands-on minutes per item, separate from waiting time
- Items missed, duplicated or corrected
- Who spends time maintaining the new route
Define a safe first proof
A first proof should use representative but controlled data and acceptance criteria that describe observable behaviour. State which inputs are allowed, who reviews the result, what happens when a dependency fails and how the old method can be recovered during the trial.
Measure the baseline and the pilot using the same definition. Time saved, error reduction or faster response remains an assumption until live evidence supports it. A polished demonstration is not a production operating model.
- One bounded workflow
- Representative test cases and exceptions
- Named reviewer and stop condition
- Permissions limited to what the proof needs
- A decision date: adopt, change or stop
Know when not to automate
Do not automate a rare task merely because it is annoying, a process that is about to change, a decision nobody owns or an activity where the likely saving is smaller than the lifecycle cost. Security, legal, safety and professional decisions may require qualified review rather than software substitution.
A paid opportunity review should be able to recommend no build. Its value is a clearer process map, a ranked opportunity, explicit risks and a proportionate next step—not a predetermined technology sale.