Start with repeated friction
The best first use case is rarely the most futuristic. Look for work that happens frequently, consumes skilled time, follows recognisable patterns and has an accountable owner. A useful candidate also has enough historical examples to understand normal cases and exceptions.
Interview the people doing the work. Ask where they wait, re-key information, search for answers, chase approvals or recover from avoidable mistakes. These observations are more valuable than a list of AI features.
Score value, feasibility and risk together
A high-value idea can still be a poor pilot when data is inaccessible, APIs are unavailable or errors could create unacceptable consequences. Score potential use cases on frequency, time/cost impact, customer effect, data readiness, integration effort, exception complexity and control requirements.
- Prefer a bounded workflow with a clear start and finish
- Choose measures that exist before the pilot
- Make a human owner responsible for exceptions
- Avoid irreversible actions in the first release
Design the smallest credible pilot
A pilot should prove whether the operating system works, not just whether a model can produce an impressive answer. Use real but controlled inputs, a small user group and an explicit comparison with the current process.
If the pilot improves the agreed measures without creating hidden work or unacceptable risk, scale in stages. If it does not, stop or redesign. A disciplined no is a valuable result.