AI use cases, how to prioritize the ones worth doing
A simple method to rank a list of AI ideas by impact, feasibility and risk, so you can decide what goes first without relying on gut feeling.
Almost every organization reaches the same point: a list of twenty AI ideas, each with an internal champion, and no shared criteria for deciding which one goes first.
Sorting that list is a business decision, not a technical one. And four questions are enough to do it.
The four questions that sort the list
1. What is it worth if it works? Not in adjectives — in numbers. Hours per month, cost per case, conversion points, days of delay. If nobody can estimate the value within an order of magnitude, the use case isn't defined well enough yet.
2. Is the data available? Available means three things at once: it exists, it can be accessed without a six-month project, and its quality is good enough. This is the filter that eliminates the most candidates.
3. What happens when it gets something wrong? An error in an internal suggestion gets corrected. An error in a customer communication or a financial calculation has consequences. Low cost-of-error cases make better starting points — not because they matter less, but because they let you learn without exposure.
4. Who will use it every day? If there's no named owner who needs the solution to do their job, the project has no sponsor and quietly dies in month three.
A two-axis matrix, not a five-factor model
With the answers in hand, place each case on two axes: impact (what it's worth if it works) and ease (data availability, integration, cost of error).
- High impact, easy: this is where you start. There are usually fewer candidates here than people expect.
- High impact, hard: these are the strategic projects. They go second, and they should be split into stages.
- Low impact, easy: useful as practice for the team, but not enough to justify a programme.
- Low impact, hard: drop them, even when they're technically the most interesting items on the list.
The value of the matrix isn't the chart — it's the conversation it forces. When two departments argue about where a case belongs, what they're really surfacing are assumptions nobody had made explicit.
The patterns that tend to work first
Across industries, early successful cases keep repeating:
- Classify and route. Requests, complaints, applications or CVs that arrive in volume and need to reach the right place.
- Extract data from documents. Invoices, contracts, delivery notes, forms. The work is tedious, the output is verifiable, the saving is immediate.
- Draft the first version. Replies, proposals, product descriptions, reports. A person still decides, but starts from 70% done.
- Search your own knowledge. An assistant over manuals, policies or internal documentation stops the team from losing hours hunting for answers.
- Summarize and prepare. Calls, meetings, a customer's history before an interaction.
They look unspectacular in a presentation and pay for themselves quickly in operations.
What to postpone
Not because they lack value, but because they make poor first projects:
- Anything that requires unifying data from five systems before showing any result.
- Automated decisions without human oversight in sensitive processes.
- Cases where errors are hard to detect: if nobody notices the output is wrong, there's no way to correct course.
How to test a case before committing budget
A two-week exercise is usually enough to decide. Take a representative sample of real cases, run them through the candidate solution, and compare against what the human team produced.
What you measure: in what share of cases the output was usable without correction, how much time was saved, and what kinds of errors appeared. That tells you whether to proceed, narrow the scope, or drop it.
The exercise is cheap, and it avoids the most expensive situation of all: discovering in month six that the use case was never viable.
A list you revisit, not a document you file
Prioritization isn't a one-off exercise. Every implementation changes the board: it unlocks data, builds capability and shifts what the team believes is possible. Cases parked in the hard zone often become accessible after the first project ships.
That's why the list is worth revisiting each quarter, with real results from what's already live on the table.
Frequently asked questions
How many use cases should we tackle at once?
One or two in the first stage. Opening five fronts in parallel dilutes the team's attention and makes it impossible to attribute results to any single initiative.
What makes a use case a good starting point?
High volume, a measurable outcome, accessible data and a low cost of error. If a wrong output is easy to spot and cheap to correct, the risk of learning is low.
Should we start with the department that asks for it, or the one with the most impact?
Where the two overlap. A high-impact area with no internal appetite produces a tool nobody uses; an enthusiastic but marginal area won't move the business.