How to Identify High-Impact AI Use Cases


Most companies do not have a shortage of AI ideas. They have a list of forty, a workshop that produced them, and nothing in production six months later.
McKinsey's 2026 survey of 1,719 respondents across 97 countries shows the gap clearly: 80% say AI has improved their own productivity, while 37% report any EBIT impact, essentially unchanged from a year earlier. Individual value is real. Enterprise value is not following.
Identification is not the bottleneck. Choosing well, and choosing few, is.
A workshop rewards volume. Everyone contributes, the wall fills with ideas, and the output is a long list that feels like progress. Nobody leaves the room having decided what will not be built.
The list then meets reality: no owner, no data access, no budget line, and a sponsor who expected a pilot rather than a portfolio. McKinsey puts the share of genuine high performers, organisations attributing at least 5% of EBIT to AI with significant value, at about 6% of respondents, unchanged from 2025.
So the useful question at the end of an identification exercise is not how many ideas you found. It is which three you will fund, and what happens to the rest.
Three things at once: the work happens often, the output can be checked, and someone owns the process today. A use case missing any of the three will stall regardless of how good the idea sounds.
Frequency is what turns a small saving into a real one. A task done twice a year does not justify the build, the maintenance or the governance, however irritating it is.
Verifiability decides whether anyone will trust the output. If a human cannot tell quickly whether the result is right, adoption dies quietly and people go back to doing it themselves.
And an owner is what separates a use case from an idea. If no named person is accountable for the process today, there is nobody to decide the agent is good enough to use.
Start with the people already using AI without being asked. They have done the identification work for free, and their workarounds point at the friction that matters.
Beyond that, three places repay attention. Work that waits on a specialist, where a team is blocked until one analyst, designer or lawyer is free. Work that gets redone, where output bounces between people because the first version was never quite right. And material nobody reads, the transcripts, tickets and reports that accumulate because reading them all is impossible.
What rarely repays attention is the list of things competitors announce. Those are their bottlenecks, visible because they chose to publicise them.
Score on two axes only: how much of the work can realistically be handed over, and whether the team is ready to take it on. Elaborate weighted matrices produce a ranking nobody argues with, which is a sign the exercise decided nothing.
The point of prioritising is to cut. On our engagement with Club Med, the programme surfaced 102 candidate agents with 50 employees trained over two days. Eighteen were kept as quick wins ready to deploy. Fifty-seven were documented as structural projects for later. The rest did not survive.
That ratio is normal and worth expecting. Roughly one in six candidates was worth building immediately, and saying so early is what made the eighteen reach production.
The use cases that return the most are rarely the autonomous ones. They tend to be the simplest: pulling together information scattered across many sources, then turning it into something usable.
Meeting preparation is the example we see work most often. An agent gathers everything the company already knows about the person being met, then afterwards produces the note in the format that team actually uses, drafts the follow-up and surfaces what nobody had to hand.
Nothing about that is impressive in a demo. It also frees more time than most automation projects, because it happens several times a day. Teams reaching for the spectacular use case first is one reason the list stalls.
Write down why, and keep the list somewhere people can find it. A candidate rejected for missing data access this quarter becomes viable the moment that access exists, and nobody will remember unless it is recorded.
Give the rejected ideas a review date rather than a deletion. The reason most of them failed is rarely the idea, and conditions change faster than the list does.
Then resist reopening the exercise. Running a second identification workshop before the first three use cases are live is the most common way a programme produces a hundred ideas and no results.
How many AI use cases should we start with?
Three or fewer, chosen so the first one is live within a quarter. A programme that starts with ten finishes none, because attention rather than budget is the constraint.
Who should identify AI use cases, IT or the business?
The business identifies, IT assesses feasibility. People who do not do the work cannot see where it is wasted, and people who do not know the systems cannot say what is buildable.
Should we start with a quick win or a strategic use case?
A quick win, provided it is real. Its job is to prove the organisation can take something from idea to production, which is the capability the strategic use case will need.
How do you measure whether a use case worked?
Against the objective of the team that owns it, not against the task. Time saved on a task nobody cared about is not an outcome.
Sorting a long list into the three worth building, and documenting the rest honestly, is the first part of our AI First Organization engagement. Book 30 minutes and we will work through yours.