AI use cases: how to choose the first one worth doing
A scoring method and a one-week exercise for choosing the first AI use case your organisation should commit to.

A scoring method and a one-week exercise for choosing the first AI use case your organisation should commit to.
TL;DR
Ask a leadership team for AI use cases and you will get 40 ideas in an hour. Ask which one they would bet a quarter on and the room goes quiet. The list was never the hard part.
This post is about the second question. It covers what makes a good first use case, where to look for one in operations, marketing, and HR, a scoring method you can run with your own team, and the kinds of use case I would keep off the first list.
A good first AI use case is one where success is likely, measurable, and visible to the people doing the work. It earns the trust you need for the second and third projects. A spectacular idea that stalls in month two costs more credibility than it was ever going to earn.
In practice, strong first candidates share six traits:
Because the failure modes are well documented, and most of them are locked in at selection. At least 30% of generative AI projects were expected to be abandoned after proof of concept by the end of 2025, due to poor data quality, weak risk controls, escalating costs, or unclear business value. Poor use-case selection combined with a lack of business value sits at the top of the list of causes.
Scale tells the same story. Only 22% of companies have advanced beyond the proof-of-concept stage, and only 4% are creating substantial value. My view is that most of the projects in the other 78% were technically possible and the wrong first bet.
Look where skilled people spend time on work that is repetitive, text-heavy, and checked by someone anyway. That pattern shows up in every function, with different specifics.
Score each candidate from one to five on the five criteria below, and multiply by the weight. The weights reflect a first project, where learning safely matters more than maximum upside. For later projects you can shift weight from cost of error towards value.
| Criterion | Question to ask | Weight for a first project |
|---|---|---|
| Value | If this works, what number moves, and by roughly how much? | x2 |
| Frequency | How many times a week does this task happen? | x1 |
| Data readiness | Can we get the inputs today without a new integration? | x2 |
| Cost of an error | What happens if the output is wrong and nobody catches it? (score five for "very little") | x3 |
| Ownership | Is there one leader who wants this and will change the process? | x2 |
The scores are a conversation tool, and a precise total matters less than the discussion it forces. When two executives score data readiness differently, you have found something worth knowing before any money is spent.
Keep anything that makes or shapes decisions about people off the first list. Recruitment screening, performance ratings, and credit decisions carry legal weight in most jurisdictions. Under the EU AI Act, CV-sorting software for recruitment is classed as high-risk, and in South Africa, POPIA restricts decisions based solely on automated processing that profile a person. These can be good later projects with proper governance. They are poor places to learn.
I would also hold back on customer-facing chat where a wrong answer reaches a customer directly, and on anything where the honest fix is a better process. Some candidates will turn out to need rule-based automation instead of AI, which is cheaper and more predictable.
Choosing a first use case works like choosing which station on a production line to improve first. You pick the one with steady volume, a clear specification, and an operator who wants the change.
The adoption step hides in Friday. If the team doing the work is not part of the decision, the use case will be technically successful and practically ignored, which is how AI pilots fail most often.
Choose a task that happens often, has clear inputs and outputs, uses data you already have, has one owner, and is cheap to get wrong. Score candidates on value, frequency, data readiness, cost of error, and ownership, then discuss where scores disagree.
Drafting, summarising, classifying, and searching text are the most common starting points, because a person can check the output. Examples include standard email responses, meeting summaries, policy questions, and content repurposing.
One or two. A small number lets the team learn how to change a workflow properly, and that skill transfers to every project after it.
Usually not. Internal use cases with a human reviewing the output let you learn where the model fails before a customer sees those failures.
A use case is a single task or workflow where AI is applied. A strategy decides which use cases matter, in what order, and what has to be true across data, people, process, and tooling for them to succeed.
If you want a scored starting point before you run the exercise, the AI Readiness Diagnostic is free and shows which of the five readiness dimensions is likely to limit your first use case.
Ready to move from reading about AI to getting your organisation ready for it? Start with the diagnostic.
Take the AI Readiness Diagnostic