The first use case decides whether an AI program gets a second one. Choose well and you have a working workflow, a measured result and an organization that trusts the method. Choose badly and you spend a quarter proving that AI does not work for something it was never suited to — and the budget for the next attempt is harder to find.
This guide covers how to select a first use case: the criteria, the traps, a worked scoring method, and a short list of candidates that tend to pay back fastest in a small business. It is the companion to How to Adopt AI in a Small Business.
The best first use case is usually the least interesting one in the room. Boring, frequent and checkable beats ambitious, novel and unverifiable.
The four criteria
A first use case should pass all four.
Frequent. It happens weekly or daily. A task performed twice a year will not repay the setup effort, however much time it consumes when it happens.
Expensive. It consumes meaningful senior hours, or carries meaningful risk. This is what determines the size of the prize.
Verifiable. A person can tell within minutes whether the output is right. This is the criterion most often ignored and the one that decides whether the use case can be adopted safely.
Contained. It touches one team, one data set and one output format. Contained use cases can be designed, delivered and measured within a quarter.
Score each candidate against the four. Where a candidate is strong on three and weak on verifiability, it is not ready — narrow it until the check is cheap.
The traps
Most bad first choices fall into one of six traps.
| Trap | What it looks like | Why it fails |
|---|---|---|
| The impressive choice | “AI strategy for the whole business” | Too broad to verify or deliver |
| The politically charged choice | “Reduce headcount in X” | Adoption depends on resistance, not design |
| The unverifiable choice | “Improve decision quality” | No cheap check, so no safe adoption |
| The rare choice | “Annual board strategy review” | Too infrequent to repay the setup |
| The cross-functional choice | “One AI workflow across sales, finance and ops” | Combines every verification problem at once |
| The tool-led choice | “We bought X, find a use for it” | The workflow is designed backwards from the product |
A useful antidote: list the candidate use cases first, then ask which tool each needs. Where the tool comes first, the use case has effectively been decided by a purchase.
A worked scoring method
Score each candidate from 1 (weak) to 5 (strong) on the four criteria, then multiply rather than add, because a zero on any one criterion fails the whole use case.
A worked example for a ten-person services firm:
| Candidate | Frequent | Expensive | Verifiable | Contained | Result |
|---|---|---|---|---|---|
| Draft monthly client report commentary | 5 | 5 | 5 | 5 | Proceed |
| Summarize incoming client emails | 5 | 3 | 4 | 4 | Second wave |
| Build an AI pricing model | 3 | 5 | 2 | 2 | Not ready |
| Draft marketing content at volume | 4 | 3 | 3 | 3 | Third wave |
| Answer support queries autonomously | 4 | 4 | 2 | 2 | Not ready |
The winner is unremarkable, and that is the point: the report commentary is frequent, expensive in senior time, verifiable against frozen figures, and confined to one team.
See The AI Use-Case Prioritization Matrix for the full scoring framework.
A short list that tends to work
Across small businesses, five first use cases recur as sensible starting points.
- Drafting recurring documents — reports, client updates, proposals — from frozen data.
- Summarizing long inputs — contracts, transcripts, research, email threads.
- First-pass research — competitor and market briefs, with every citation checked.
- Structuring unstructured notes — meeting notes into actions, tickets into themes.
- Drafting responses — support replies, follow-up emails, standard correspondence.
Each has a cheap check, which is why they appear on every serious list. See the AI Use-Case Library for the workflows behind each.
What to do before you start
Four things, all small.
- Name the accountable owner — one person who signs off the output.
- Capture the baseline — hours per cycle, error rate, and where corrections currently appear.
- Define the check — what is verified, by whom, and how it is recorded.
- Agree the data rule — what may and may not go into the tool for this use case.
Without the baseline there is no measurement; without the check there is no safe adoption; without the data rule there is an avoidable risk. None of the four takes more than an hour to settle.
Narrowing a use case that is not ready
Most promising use cases fail only on scope, and scope is the easiest thing to change. Three narrowing moves fix the majority of candidates.
- Restrict the output. Instead of “draft the report”, try “draft the narrative section from these frozen figures”. The narrower output has a cheaper check.
- Restrict the input. Instead of “research the market”, try “summarize these eight named sources”. The bounded input makes verification possible.
- Restrict the audience. Instead of “produce content for clients”, try “produce first drafts for internal review”. Internal output carries a lower cost of error while the workflow matures.
Apply the narrowing move that restores the cheap check, then re-score. A use case that cannot be narrowed to a verifiable output is not a first use case; it may be a third one, once the organization has the habits.
When the first use case should be smaller than you think
There is a persistent instinct to make the first project prove the whole thesis. It rarely does. The first use case exists to prove that the method works — that a workflow can be designed, a check can be run, a baseline can be beaten and an owner can be named.
Judged by that standard, a small use case is as valuable as a large one and considerably more likely to succeed. The second and third use cases are where the ambitions belong, because by then the playbook format, the data rule and the verification habit already exist and cost nothing to reuse.
A useful rule: choose the first use case you could deliver in ninety days even if two people were absent. That constraint removes most of the risk without removing the value.
Common mistakes
- Starting with the widest use case available. Scope is what makes the first project deliverable.
- Choosing by enthusiasm. The most excited team is not automatically the best first adopter.
- Skipping the verifiability test. The check decides whether the use case survives contact with real work.
- No baseline. The result cannot be shown, so the program is judged on impressions.
- No named owner. The workflow is designed and then nobody runs it.
- Choosing three use cases at once. One working workflow beats three half-built ones.
Frequently asked questions
What makes a good first AI use case?
Frequent, expensive, verifiable and contained — with a cheap check, a named owner and a captured baseline. The least exciting candidate usually wins.
What is the most common mistake in choosing a use case?
Ignoring verifiability. If a person cannot check the output in minutes, the use case cannot be adopted safely, however much time it appears to save.
How many use cases should we start with?
One. A single working workflow produces the evidence, the playbook and the confidence that make the second one straightforward.
Should we start with the department that is most enthusiastic?
Not necessarily. Enthusiasm is useful, but verifiability and a willing owner matter more. The best first adopter is a team doing frequent, checkable work with someone accountable for quality.
How long should the first use case take?
From selection to a measured result in about ninety days for a contained use case. Longer usually means the scope was not contained enough.
What if the first use case fails?
Then the failure should be informative: was it the choice, the workflow, the data or the training? Write down the cause, because it determines whether the next attempt is a fix or a different candidate.
Can a use case be made smaller rather than abandoned?
Usually, yes. Restrict the output, the input or the audience until the check is cheap again, then re-score. A use case that cannot be narrowed to a verifiable output is not ready to be first.
Does the first use case need to save money?
No, though it helps. The first use case primarily needs to prove the method: a designed workflow, a real check, a captured baseline and a measured result. A modest saving proved properly is worth more than a large one asserted, and it is the evidence the second use case is approved on.
Should the first use case be one the business already does well?
Usually yes. A task the team understands has a known standard to check against, which makes verification cheap and the pilot fast. Where the process is poor, document it first.
Next step
Score your candidates on the four criteria, pick the highest-scoring contained use case, and settle the owner, baseline, check and data rule before you begin. See Building an AI Adoption Roadmap for the sequencing, or book an AI adoption call to run the selection with you.
Sources
- Selection criteria and scoring reflect standard project-selection practice applied to AI adoption: frequency, cost, verifiability and containment, with a baseline captured before change.
No statistic in this article is invented; where figures appear in the linked guides, they are cited there with their source and date.