Glossary
AI use case
An AI use case is one specific job you intend the technology to do, described narrowly enough that you could look at the result afterwards and say whether it worked.
In plain terms
A use case is not a department, a technology or a wish. It is one job, done by somebody, often enough to be worth improving, where you could hold up the result and say yes or no. Compare two versions of the same idea. The first is that we should use AI in customer support. The second is that we should draft first replies to refund requests, for a support colleague to edit before sending. Only the second can be built, judged or abandoned.
Why it matters
Everything downstream depends on it. You cannot evaluate a tool without one, because every product demonstrates impressively against no criteria; you cannot price the work, because the volume is undefined; and you cannot tell whether the pilot succeeded, because nobody agreed what success meant. Most AI projects that quietly stop were never actually stopped. They ran out of momentum because no one could say what would have counted as working, so the answer defaulted to the loudest opinion in the room.
How it works
Name the job, not the field. The unit is a task somebody currently performs, with a recognisable beginning and end, not a department or a capability. If you cannot name the person who does it today, the use case is still an ambition and will behave like one: it will survive every meeting because there is nothing in it specific enough to disagree with.
Say who checks the output and against what standard. A use case includes its own acceptance test, and writing that test is usually where the vagueness surfaces. Without one the honest position is that nobody knows whether the thing works, and in practice that position persists for months while everybody assumes somebody else is forming a view.
Establish the volume before anything is built. How often the job happens decides whether it is worth automating at all, and it is the number that turns a cost per answer into a cost per month. A task done four times a month rarely repays the effort of building around it, however irritating those four times are to the person doing them.
Choose something the organisation can already do by hand. If nobody can produce a good version of the output manually, nobody can judge the automated version either, and the work has no standard to improve against. That does not rule the idea out, but it does change the first step: somebody has to make a few good examples before anything is measured.
Write down what failure looks like, in the same document. A use case with no described failure mode has not been thought about, because every real one has cases where the output is unacceptable and somebody has to catch them. Naming those cases early is what turns a vague worry about accuracy into a specific, checkable list.
Two descriptions of the same idea
Seen in the wild
Draft the first reply to a routine inbound request, for a person to edit before it goes out, which is a defined job with an obvious check.
ChatGPTAnswer internal questions from documents the team already maintains, where a wrong answer is visible because the source is shown beside it.
GleanSummarise a recurring set of records into a standing weekly note, where the volume is known in advance and the output is read by a named person.
Notion AI
Common misconceptions
People assume
Our use case is that we want to use AI in operations.
In fact
That is a department and a hope. It cannot be built or judged, and it will absorb budget until somebody narrows it. The narrowing is the work, and doing it early is much cheaper than discovering afterwards that three teams were building against three different unstated definitions.
People assume
We should start with the highest-value process.
In fact
High value usually means high stakes, which makes the checking expensive before anybody has learnt what acceptable output looks like. Starting somewhere repetitive and low-stakes builds that judgement cheaply, and the judgement is what makes the valuable work possible later.
Questions
- How narrow is narrow enough?
- Narrow enough that you could look at one output and say whether it was acceptable, without convening a meeting. If two reasonable colleagues would disagree about whether a given result counted as success, the definition still has work left in it and the disagreement will surface later at a worse moment.
- Should a use case name a tool?
- No, and naming one early is a common way to get stuck. Describe the job, the check and the volume first, then evaluate tools against that. A use case written around a product tends to become a description of that product's features rather than of your work.
- How many should we run at once?
- Fewer than feels ambitious. Each one needs somebody who owns the checking, and that attention is the genuinely scarce resource rather than licences or budget. Teams that run one to completion learn more than teams that run five to the halfway point.
- What if the job cannot be done by hand today?
- Then you have no standard to judge output against, and that is worth knowing before building. It does not rule the work out, but it changes the first step: somebody has to produce a few good examples manually so there is something for the automated version to be compared with.
Key takeaways
- A use case is one job with a beginning, an end and somebody who does it today.
- It includes its own acceptance test, or nobody can say whether it worked.
- Volume decides whether the work repays the effort, so establish it early.
- Pick something the organisation can already do by hand, so there is a standard to judge against.
- A departmental ambition is not a use case and will absorb budget until it is narrowed.
Last checked July 2026