Automate a frequent, understood process whose output a named person can check. The best first candidate is usually a bounded preparation task, such as assembling a recurring report or drafting an onboarding pack. Look for dependable inputs, a manageable consequence of failure and a clear way back to the existing process.
The most frustrating task is not automatically the best starting point. It might be frustrating because nobody agrees how it should work. Automating that uncertainty can make the confusion arrive faster. First make the process and its owner explicit.
What are you actually choosing?
Describe a candidate as a single workflow: when something happens, use these permitted inputs to prepare this output for this person. For example, “each Friday, prepare a draft operations summary from the agreed sources for the operations lead”. “Automate operations” is too broad to estimate or test.
Record where the task starts and ends. Does the scope stop at a draft, include a review screen or extend to updating another system? Each additional action creates dependencies and exceptions. A first pilot needs an output that still has value when the person declines the next step.
Which conditions should rule a candidate out for now?
Use these questions before assigning scores. They are practical screening gates, not a complete legal or security assessment:
- Can the team use the required data and systems for this purpose?
- Is there a sponsor and an operating owner who can make decisions?
- Can a failure be detected, contained and handled by a person?
- Can the team return to its current process without losing essential work?
- Is there enough source evidence to check the output rather than judge how convincing it sounds?
A missing answer is a preparation task. A high potential time saving does not cancel it out. Work involving significant commitments or sensitive decisions may need a different project and specialist review before it is a sensible first pilot.
How can you compare the remaining processes?
Use the scorecard below with the people doing the work. Give each factor 0, 1 or 2 and write one sentence of evidence beside the score. Two means more favourable for a first pilot. The total is a discussion aid, not a validated prediction of return or a pass mark.
| Factor | 0 | 1 | 2 |
|---|---|---|---|
| Recurrence | Rare | Occasional | Regular |
| Current effort | Small or unknown | Some friction | Recorded material effort |
| Input quality | Unavailable | Needs preparation | Accessible and consistent |
| Process stability | Changes constantly | Some variation | Clear repeated pattern |
| Output checking | No clear check | Expert judgement needed | Clear, feasible checks |
| Review capacity | No time allocated | Limited availability | Named time and owner |
Do not hide disagreement inside an average. If the sponsor gives input quality a two and the operator gives it a zero, inspect a real sample together. You may weight the factors differently, but state the reason before scoring, so the method does not simply justify a favourite idea.
What would an illustrative comparison show?
Illustrative scenario, not a client result: a team considers weekly reporting, new-client onboarding and automatic customer refunds. Reporting has a regular trigger and accessible sources, but its current effort still needs measuring. Onboarding has a useful output but several different project types. Refunds carry financial consequences and an unclear exception policy.
The team might shortlist the report, measure a few representative runs and narrow onboarding to one project type. It would hold refunds until the authority and exception rules were resolved. This is a judgement about readiness and consequences, not proof that reporting will deliver the highest return.
The point of comparing candidates is to expose the missing work. A supposedly simple report can lose its advantage if most of the effort is chasing unavailable data. A clear onboarding template may become the better pilot once the real examples are inspected.
What should you measure before building?
Keep a small baseline that reflects normal and awkward cases. Record the volume, preparation time, review time, corrections and delays. State who measured it and when. If you are estimating, label the estimate and use a range rather than presenting it as an observed saving.
Agree the same measures for the pilot. Include work shifted to reviewers, service charges and maintenance. A faster draft that needs longer checking may not improve the complete process. My website intelligence dashboard illustrates another useful distinction: a readiness signal can help organise work without proving a commercial outcome.
Does the task actually need AI?
Check whether a rule, integration, spreadsheet or template could do the job. Fixed calculations and straightforward routing often benefit from predictable logic. AI can help when source material varies or the task needs a draft explanation, but it adds uncertainty that must be checked.
A sensible workflow may combine both: ordinary software fetches approved figures, formulas calculate changes, AI drafts a summary and the owner approves the interpretation. Choose the least complicated approach that satisfies the agreed task.
What does a useful first-pilot brief contain?
End the selection process with one page naming the trigger, inputs, output, owner, excluded actions, checks, exception route and baseline. Add the access dependencies, available reviewer time and conditions for stopping or extending the pilot. Keep a manual fallback until the workflow has earned wider use.
If the candidates are still unclear, an AI readiness assessment is a way to map the work before implementation. If one process is already well understood, use the brief to discuss a scoped build. The next commitment should be tied to evidence, not the highest score alone.