Which AI use cases
actually deliver results?

What marks AI use cases that actually deliver results?

AI use cases that deliver results share four traits: high volume with low variation, a mistake whose cost is known and affordable, a human check already built into the process, and data that already exists and is already used for decisions. Technology doesn't feature in any of those four traits. Almost always, it's the assistant that can do everything, the prediction model with no decision behind it, the use case with no owner in the business, and the automation of a process that should be scrapped instead, that stall.

What happens to AI use cases that start by collecting data?

AI use cases that start with collecting data first push back at least a year. Sometimes that's the right investment, but then it's a data project, not an AI use case.

Which AI use cases don't go first when prioritising?

AI use cases that score below 15 points don't go first; there are usually five questions that decide the priority, each scored from 1 to 5. The five questions cover volume, variation, data readiness, safety and pull.

Source: article by Dave Willemstein. Updated: October 2026.

The pattern behind the winners

In use-case sessions, the same kind of ideas always float to the top: a chatbot that knows everything, a system that predicts the market, an assistant that makes meetings unnecessary. They're appealing because they sound big. They stall because they're vague.

The use cases that do make it share four traits. None of those traits is about technology.

1. High volume, low variation

A task that occurs a thousand times a month in roughly the same way is a better candidate than a task that occurs ten times a year and is different every time, even if that second task is more expensive per occurrence.

The reason is practical: at high volume, a small improvement pays for itself quickly, you can measure quickly whether it works, and there's enough material to improve the system. At low frequency, it takes a year before you know whether you have anything.

A concrete example: summarising customer calls (thousands a month, similar structure) is a better first use case than drafting the annual plan, however valuable that annual plan is.

2. The cost of a mistake is known and affordable

Every AI application makes mistakes. The question isn't whether, but what that mistake costs and who notices it. This question gets skipped too often, and it determines after the fact whether the use case is sustainable.

Three categories:

• Affordable and visible: a wrongly suggested summary that the user sees and corrects immediately. Ideal candidate.
• Affordable but invisible: a slightly wrong stock forecast that only shows up in the quarterly figures. Usable, provided you set up monitoring.
• Costly and invisible: a wrongly rejected credit application. Only do this with a solid control structure, and rarely as a first use case.

3. There's already a human check in the process

This may be the strongest predictive trait. If someone in the current process already reviews, checks or signs off, you already have the most important safeguard in place. You're changing that person's role from doer to checker, and that's a much smaller change than it sounds.

Conversely: if a process runs fully automatically with no human involvement, and you want to put AI into it, you'll need to add that check yourself. That costs time, money and buy-in, and it makes the business case smaller than the original calculation suggested.

4. The data already exists and is already in use

Not "the data is available", but "the data is already used to make decisions". That difference is significant. Data already in use has already been cleaned up, already defined, and already has an owner. Data that sits somewhere but isn't used for anything is almost always worse quality than everyone assumes.

A use case that starts with "first we need to collect data" pushes back at least a year. Sometimes that's the right investment, but then call it a data project, not an AI use case.

Four patterns that almost always stall

The assistant that can do everything

"We're giving everyone an AI assistant" isn't a use case, it's a licence. Without defined scenarios, usage stays stuck around ten per cent, and then the organisation concludes that AI "doesn't work". Pick three to five concrete tasks, build ready-made starting points for them, and only add freedom later.

The prediction model with no decision behind it

A prediction nobody acts on is an expensive dashboard. Before you start: who looks at this prediction, what does that person do differently at outcome A versus outcome B, and do they have the mandate to do it? If any one of those three answers is missing, stop.

The use case with no owner in the business

If the only enthusiast sits in the innovation team or the data team, and there's nobody in the business who benefits, the use case won't survive the first reorganisation. Find the person whose quarterly target becomes more achievable because of it. If you can't find them, it's a nice idea, not a priority.

The use case that automates a process you should scrap instead

This is the most painful one. On analysis, it regularly turns out that the process we want to speed up mainly exists because another system is poorly set up. AI then makes that process cheaper, which means nobody ever scraps it. Always ask first: why does this step exist, and what happens if it disappears?

A practical scoring question

When prioritising a list, there are usually five questions I score each use case against, from 1 to 5:

• How often does this task occur? (volume)
• How predictable is the shape of the task? (variation)
• Does the data needed already exist, and is it in use? (data readiness)
• Is there already a check in place, or do we need to add one? (safety)
• Is there an owner in the business who benefits? (pull)

Use cases that score below 15 points don't go first. Not because they're bad, but because your first two use cases need to succeed: the rest of your roadmap depends on it.