Most AI initiatives that stall share a common origin story. Someone sees an impressive demo, a budget appears, and a team is asked to "find a use case for this". Months later there is a prototype that nobody uses, because it was built to show off a capability rather than to fix a problem anyone had.
The alternative is unglamorous and far more reliable: start from a workflow that is already costing you time, quality or goodwill, and only then ask whether AI is the right tool for it. Often it is. Sometimes it isn't — and finding that out early is a win, not a failure.
What makes a good first use case
Across the assessments we run, the best first candidates tend to share five traits. They don't need all five, but the more they have, the smoother the path from idea to daily use.
- Frequent. The task happens many times a week, so small savings add up and you get feedback quickly.
- Text-heavy. It involves reading, writing, classifying or summarising — the things language models are genuinely good at.
- Bounded. The inputs and the desired output are reasonably well defined, so you can tell a good result from a bad one.
- Recoverable. A mistake is annoying rather than catastrophic, or there is a natural point for a person to check the result.
- Owned. A specific team feels the pain and wants it fixed, and someone in that team will champion the change.
Classic examples include triaging incoming requests, drafting first replies to common customer questions, extracting fields from documents, and answering internal policy questions. None of these will make headlines. All of them free up hours that people would rather spend on judgement and relationships.
Map the work before you design the system
Before anyone writes a prompt, sit with the people who do the work today. Watch a few real cases from start to finish. Where does information come from? Which decisions are mechanical and which require context that lives in someone's head? Where do things wait? Which steps exist only because two systems don't talk to each other?
This mapping usually reveals that the opportunity is smaller and more specific than the original idea — and therefore much easier to deliver. "Automate customer support" becomes "draft replies for the twenty question types that make up most of our tickets, and route everything else to a person with a summary attached". That is something you can build, measure and improve.
Score opportunities honestly
Once you have a handful of candidates, rank them on three axes. Value: how much time, money or quality is at stake if this works? Feasibility: is the necessary data available and accessible, and is the task within what current models do reliably? Risk: what happens when it gets something wrong, and who would notice?
A use case that scores high on value but low on feasibility belongs on the roadmap, not in the first pilot. One that scores high on feasibility but low on value is a nice experiment, not a transformation. The sweet spot is a moderately valuable, clearly feasible, low-risk workflow — because its main job is to build confidence and capability for everything that follows.
The first pilot's real deliverable is not the automation. It's the organisation's belief, backed by evidence, that this can work here.
Define success before you build
Agree on what good looks like while everyone is still neutral. That usually means a small evaluation set of real examples, curated by the team that does the work, with the outputs they would consider acceptable. Add a few operational measures — time per task, share of cases handled without escalation, cost per run — and a qualitative check: do the people using it actually want to keep using it?
Writing these criteria down has a useful side effect. It forces the conversation about acceptable error rates and human review to happen early, instead of in a tense meeting after the first visible mistake.
Leave room to say no
Finally, give the pilot a genuine exit. If the evaluation shows the task is beyond what today's models do reliably, or the data simply isn't there, stopping is the right call. You will have spent a few weeks, learned a great deal about your processes, and avoided a much more expensive failure later. The next candidate on the list is usually waiting.
Starting with the workflow is slower for the first week and faster for every month after it. It's the difference between AI as a project and AI as part of how work gets done.