The best first AI use case is rarely the most ambitious one. It is a familiar task that happens often, has a clear owner and can be made better without placing a customer, payment or important decision beyond a person’s view.
Start with the work
Look for friction people can describe without mentioning AI
Ask where work waits, gets copied twice or relies on somebody remembering the next step. A slow reply to an enquiry, an inbox full of routine questions, notes that never become actions and information retyped between systems are all more useful starting points than a broad request to ‘use AI’. They describe an operational problem that can be observed before anything changes.
Speak to the people doing the work, not only the person buying the software. They know which exceptions matter, what information is missing and where a shortcut would create more work. If nobody can explain the current process from start to finish, map it before considering automation.
Choose carefully
Pick a task that is repeated, visible and containable
A first pilot needs enough repetition to show whether it helps, but it should not be the process that carries the highest consequences. Preparing a first response, sorting routine documents or turning meeting notes into a draft action list can be sensible. Final pricing, financial approval, employment decisions and sensitive customer cases need more caution and are poor places to begin without a mature control model.
Containment means deciding what the system may prepare, what it may update and where a person must review it. That boundary makes the experiment easier to explain to staff and easier to stop if it is not helping.
- It happens often A task performed every day or week gives a small improvement room to matter.
- The outcome is clear You can say what good looks like: a faster reply, fewer handovers or a complete record.
- A person can check it The first version prepares, flags or routes work instead of quietly making an important decision.
- The input is available The information needed already exists in an inbox, form, document or approved system.
Before the pilot
Set a modest baseline before changing anything
You do not need a large measurement programme. Record a normal week: how many items arrive, how long they wait, where people chase information and what gets missed or corrected. A few real examples are more useful than a vague sense that the team is busy.
Then choose one or two measures that match the problem. For an enquiry process, that might be time to acknowledgement and the number of enquiries needing a second chase. For meeting follow-up, it might be whether actions have an owner and due date by the next working day. Decide this before the pilot so the result is not judged by enthusiasm alone.
Test in the open
Treat the first version as a pilot, not a promise
Give the test a named owner, a small group of users and a review date. Use real variations, not just the easy example that made the demonstration look good. Include an incomplete request, an unusual document, a customer who needs a human response and a day when a connected system is unavailable.
At the review, keep the question simple: did the work become faster, more consistent or easier to manage without introducing unacceptable rework or risk? A pilot that proves AI is not the right answer has still prevented a larger mistake. Sometimes a clearer form, a better template or a conventional rules-based automation is the better result.