Designing use cases
Pick three to five use cases per team that are cheap to try and valuable if they work.
What makes a good use case
A use case is a job that a person hands to their agent. It has a prompt, the sources it needs, and a way to tell whether it worked. Good first use cases:
- repeat weekly or more often, so the time saved adds up;
- use sources you can connect today;
- produce an answer you can check, because it cites a file, page, issue or topic;
- leave something in the ledger, so the next person benefits too.
Three to five per team is enough. Fewer leaves people without a habit. More spreads the pilot thin.
Run a use-case workshop
Allow 60 minutes with the pilot team and one champion.
- Collect (15 minutes). Everyone lists questions they asked or answered in the last month, decisions that were reopened, and incidents that felt familiar.
- Map (10 minutes). For each item, note where the answer lives today: a repository, a space, a project or a file.
- Score (20 minutes). Score each item with the table below.
- Choose and write (15 minutes). Take the top three to five, and write each one as a card.
Score each candidate
Score each criterion from 1 to 3, then add up the scores.
| Criterion | 1 | 2 | 3 |
|---|---|---|---|
| How often it comes up | Monthly or less | Weekly | Daily |
| Sources ready | Needs a source that's coming soon | Needs a new source connected | Already connected |
| Value when it works | Minutes saved | Hours saved, or fewer mistakes | Prevents repeat incidents or rework |
| Easy to check | Hard to verify | Partly verifiable | A citation you can check in a minute |
| Fits the namespace plan | Needs per-person permissions | Needs a namespace of its own | Fits a namespace the team already has |
Drop any candidate that scores 1 on Sources ready or Fits the namespace plan: Workstate can't do it yet. From the rest, take the highest totals. Break ties by effort, and prefer the one that needs no new source.
An illustrative scoring
Illustrative
A support team scored five candidates:
| Candidate | Often | Sources | Value | Check | Namespace | Total |
|---|---|---|---|---|---|---|
| "Is this a known issue?" from Jira and the ledger | 3 | 3 | 3 | 3 | 3 | 15 |
| Draft replies from the help pages | 3 | 3 | 2 | 3 | 3 | 14 |
| Record workarounds as defect topics | 2 | 3 | 3 | 3 | 3 | 14 |
| Summarise escalations from Slack | 3 | 1 | 2 | 2 | 3 | Dropped |
| Answer questions about one customer's contract | 2 | 2 | 3 | 3 | 1 | Dropped |
The team started with the first three. The Slack use case waits for the Slack connector. The contract one needs each account manager to see only their own customers' contracts, which needs per-document permissions.
Write each use case as a card
text
Use case: [short name]
Who: [role]
When: [the moment it comes up]
Prompt: [what the person asks their agent]
Sources: [repository, space, project or upload source]
Ledger habit: [what gets recorded, and in which project]
It worked if: [what you can observe]For example:
text
Use case: Is this a known issue?
Who: Support agents
When: A ticket describes an error
Prompt: Search Jira and the ledger for a known issue matching this ticket. Say whether it's resolved, give the workaround, and cite the issue.
Sources: Jira SUP and ENG projects; the help center space
Ledger habit: New workarounds become defect topics in project "support"
It worked if: The reply cites an issue or topic, and a spot check finds the citation correctPut the cards on the team's page. The onboarding kit has a template for it.
Avoid these
- "Summarise everything." Search returns the best matches for a question, not a digest of a whole source.
- Use cases that need a source that's coming soon, such as Slack or Google Drive.
- Use cases that need per-document permissions, such as each manager seeing only their own team's reviews.
- Answers nobody can check. Without a citation to open, there's no way to trust the answer.
Ideas by team
Each team page lists jobs to start from: