Start with work that is frequent, rules-led, measurable, and costly to coordinate. Do not start with the most impressive AI demo or the process with the loudest sponsor.
Start with the work, not the technology
A useful automation opportunity begins with an observable workflow: who starts it, what information moves, which decisions occur, and what a finished outcome looks like. Naming a technology first usually narrows the diagnosis before the problem is understood.
Map the current path using real examples. Include waiting, chasing, copying, checking, reformatting, and correction—not only the official process documented in a playbook.
- High enough volume to matter
- Repeated steps or recurring information movement
- A clear beginning and end
- An owner who can validate the change
Separate information work from judgement
AI is strongest when it helps collect, classify, summarise, route, draft, or reconcile information. Human ownership should remain explicit wherever context, accountability, client trust, or consequential judgement matters.
The right design is often not full automation. It is a shorter path in which machinery prepares the evidence and a person makes the decision.
- Automate collection and preparation
- Augment analysis with traceable inputs
- Keep approvals visible
- Escalate ambiguity instead of hiding it
Score candidates against five practical tests
Compare workflows using frequency, time consumed, error or delay cost, feasibility, and risk. A modest workflow that runs every day can create more value than a dramatic process used once a quarter.
Add a confidence score for the baseline. If nobody knows how often the work happens or how long it takes, measure it briefly before estimating returns.
- Frequency and volume
- Hours and waiting time
- Error, delay, or opportunity cost
- Data and system readiness
- Operational, privacy, and client risk
Agree the baseline before building
Choose one or two measures that reflect the reason for changing the workflow. Examples include turnaround time, manual touches, rework, completion rate, or hours spent each week.
A baseline protects the project from vague success claims. It also reveals whether the constraint moved elsewhere after the change.
- Use a defined measurement period
- Record exceptions, not just averages
- Name who validates the number
- Set a review date before implementation
Choose a first project that can teach the organisation
The best first workflow is valuable enough to matter but bounded enough to understand. It should expose how the team handles data, approvals, exceptions, ownership, and adoption without putting a critical operation at unnecessary risk.
Treat the first implementation as a reusable operating pattern. Document what was automated, what remained human, how exceptions were handled, and which measure changed.