How to prioritize AI use cases
AI use case prioritization works best at the level of a single task. List the work your team repeats, score each task on six factors (value, frequency, feasibility, data readiness, harm if wrong, and reviewer availability), and hold any task that fails one of two stop rules. Then pilot the top one or two against a measured baseline.
What is an AI use case?
An AI use case is a specific task with four parts: a defined input, a defined output, a person who uses or checks that output, and a way to tell whether it worked. If you cannot name all four, you have a goal, not a use case. "Use AI in customer service" is a goal and cannot be scored. "Draft answers to the ten most common emailed questions for a staff member to send" is a use case: it has a frequency, a time per instance, an obvious reviewer, and a clear way to be wrong.
NIST's voluntary AI Risk Management Framework (opens in a new tab) asks for the same discipline: define the business value or context of use (MAP 1.4), examine the potential costs of AI errors, including non-monetary costs (MAP 3.2), and take viable non-AI alternatives into account (MANAGE 2.1). The non-AI point matters: some tasks on your list are better solved with a template, a form, or a checklist. NIST notes that the framework is being revised (opens in a new tab) as of October 2026.
How to identify AI use cases: the task inventory
Ask each person to list the tasks they repeat. For the most common ones, time at least 20 real instances over at least two weeks of normal work, and include the back-and-forth: the clarifying email, the re-check, the correction.
OpenAI's guide, Identifying and scaling AI use cases (opens in a new tab), suggests three places to look: repetitive low-value tasks, skill bottlenecks, and work where people get stuck on ambiguity. Also look at what people already do with AI on their own; as the shadow AI post argues, unapproved use is a demand signal as well as a control gap.
Record each task on a worksheet like this one (the filled rows are hypothetical). Fill in the last two columns while the task is fresh; they feed the harm and reviewer scores.
| Task | Who does it now | How often | Minutes per instance (timed) | Input | Output | What a wrong output would cost | Who could check it |
|---|---|---|---|---|---|---|---|
| Summarize a service call into the job record | Technician | About 20 a day | 6 | Technician's voice note | Job record entry | Missed follow-up or wrong part ordered | The technician, before closing the job |
| Draft a quote from job notes | Estimator | About 8 a day | 25 | Notes, photos, price list | Customer quote | Underpriced job or lost bid | The estimator |
| [Your task] |
Why impact and effort are not enough
Many frameworks use a two-axis grid, such as the impact/effort quadrant in OpenAI's guide, which scores each use case on its value to the company and the effort it requires. That is a reasonable first sort, but it leaves out two questions that decide whether a use case can run safely: how bad a wrong output is, and whether anyone has time to catch it. The scoring sheet below adds both, and splits impact and effort into four factors you can check.
Value scores deserve humility too: the same tool can be worth very different amounts to different people. In a study of 5,172 customer support agents published in 2025, Brynjolfsson, Li, and Raymond (The Quarterly Journal of Economics (opens in a new tab)) found that a generative AI assistant raised issues resolved per hour by 15% on average, with substantial heterogeneity across workers: less experienced and lower-skilled workers improved both the speed and quality of their output, while the most experienced and highest-skilled workers saw small gains in speed and small declines in quality. That is one setting and one task type, so treat value scores as estimates until a pilot measures them.
The AI use case prioritization scoring sheet
Score each task from 1 to 5 on six factors. Higher is always better, so harm and reviewer availability are scored as safety, not danger. The anchors are an editorial tool, not a standard; use 2 and 4 for cases in between.
| Factor | Question | 1 means | 3 means | 5 means |
|---|---|---|---|---|
| Value | What changes if this task gets faster or better? | Little anyone would notice | Noticeable time back for one person or role | Frees real capacity or improves something customers notice |
| Frequency | How often does it happen? | A few times a year | Weekly | Many times a day |
| Feasibility | Can an approved tool do it with your inputs? | Needs custom work or is unproven | Works in a quick test, with extra setup or cleanup | Works in a quick test today |
| Data readiness | Are the inputs available, current, and allowed in the tool? | Scattered, on paper, or restricted | In one place, but out of date or inconsistent | In one place, current, and permitted |
| Harm if wrong | How bad is a wrong output that gets through? | Could hurt a person, cost real money, or create legal exposure | Costly or embarrassing to fix, but recoverable | Minor, and caught before anyone outside sees it |
| Reviewer availability | Is a qualified person in the loop with time to check? | Nobody qualified has time | Someone qualified could check it if other work moves | The person who checks it today already would |
How to fill in the sheet
- Score value and frequency from the timed inventory, not from memory.
- Score feasibility from a short test with an approved tool on a handful of real, non-sensitive examples, not from a vendor demo.
- Score data readiness by running each input through the five questions in data readiness for AI: reachable, permissioned, current, structured enough, and correct and owned.
- Have the person who does the task and the person who would check the output score it separately. A gap of two or more points usually means they picture different versions of the task or different failures; talk it through and record the agreed score and why.
Add the six scores for a total out of 30. Then apply two stop rules, whatever the total:
- Harm stop. A 1 on harm if wrong holds the task.
- Reviewer stop. A 1 on reviewer availability holds the task.
For a task held on harm, an AI risk assessment register records how it could fail and which controls would have to be in place before you score it again.
Leave the factors unweighted the first time. If you add weights later, write down why, so the next person can argue with them.
Turn scores into decisions
The total ranks the list; it does not decide it. Give every task one of four decisions and record the reason beside it.
| Decision | When it applies | What happens next |
|---|---|---|
| Pilot | Passes both stop rules, ranks near the top, and can be timed against a baseline | Write the pilot terms below and start |
| Prepare first | Valuable, but data readiness or feasibility is low, or a needed fallback does not exist yet | Fix the inputs or design the fallback, then re-score |
| Try a non-AI fix | A template, form, checklist, or plain automation would do the job | Test that first; re-score only if it falls short |
| Hold | Fails a stop rule | Revisit when the risk is reduced or a reviewer has time |
Break ties in favor of the task that scores higher on harm if wrong and reviewer availability; it is the safer place to learn.
Worked example: a hypothetical heating and cooling company
In this illustrative example, a fifteen-person heating and cooling company scores six candidate tasks:
| Task | Value | Frequency | Feasibility | Data readiness | Harm if wrong | Reviewer | Total | Decision |
|---|---|---|---|---|---|---|---|---|
| Summarize service calls into the job record | 3 | 5 | 4 | 4 | 4 | 4 | 24 | Pilot first |
| Draft replies to online reviews | 2 | 3 | 5 | 5 | 3 | 5 | 23 | Pilot alongside; owner approves each reply |
| Write seasonal maintenance reminders | 3 | 3 | 5 | 3 | 4 | 4 | 22 | Try a non-AI fix: clean the customer list and test a mail-merge template |
| Draft quotes from job notes | 5 | 5 | 3 | 2 | 2 | 4 | 21 | Prepare first: consolidate the price list, then re-score next quarter |
| Answer after-hours calls | 4 | 4 | 3 | 3 | 2 | 3 | 19 | Prepare first: design the human fallback before testing |
| Pre-screen job applicants | 2 | 1 | 3 | 3 | 1 | 2 | 12 | Hold: harm stop |
The highest-value task, quote drafting, is not first: its data is not ready, and a wrong quote costs real money. The reminder emails may not need AI at all. After-hours calls sit in the middle because nobody has designed the fallback; the AI receptionist decision guide covers what that fallback and a pilot would need.
From a ranked list to a first pilot
For each task marked Pilot, write down four things before anyone starts:
- Baseline. The volume and time per instance you timed in the inventory.
- Success threshold. The result that would justify keeping it, such as total time, including review, falling by a set share with no error reaching a customer.
- Stop condition. The result that ends the pilot, whatever else looks promising.
- Owner. The person who calls stop or continue.
A pilot without those becomes a demo that never ends, as why AI pilots stall explains. To time the pilot against its baseline, with review and rework counted as cost, use the one-page worksheet in how to measure AI ROI. Re-score the whole list each quarter: data gets cleaned, tools improve, and a held task may become ready.
For an outside view, the AI Adoption Assessment that starts Cleland & Co.'s AI Strategic Advisor engagement produces a use-case inventory scored on value and feasibility and a prioritized roadmap, and it can recommend waiting or stopping.
