Insights · Guide
How to Prioritize AI Use Cases
How do you prioritize AI use cases?
Most organizations have more AI ideas than capacity to deploy any of them properly. The method for choosing what to do first scores each candidate workflow on three dimensions (value, feasibility, and risk) and uses those scores to pick one that can actually be built, operated, and measured. Value must be volume-anchored. Feasibility usually dominates. Risk is a gate, not a variable to average away.
65-word direct answer
Key takeaways
- Score value on volume-weighted impact, not percentage improvement alone. A 2% gain on a task done 400 times a month beats a 40% gain on a task done twice a year.
- Feasibility usually determines the winner. High value with low feasibility is a research project, not a first implementation.
- Risk is a gate, not a dimension to average into a single score. A high-risk use case changes the oversight requirement and may disqualify it as a starting point entirely.
- Several conditions disqualify a candidate regardless of its scores: no named owner, no measurable baseline, data that cannot lawfully be used, no system access, or a one-off task rather than a repeating workflow.
- The second use case should reuse something the first one built: an integration, a data connection, or a governance pattern. Adjacency is a strategy.
The real problem: too many ideas, not enough capacity
After an AI awareness session or a vendor demonstration, most organizations end up with a list of ten to thirty candidate workflows. Everyone agrees that several of them are promising. Nobody agrees on which one to do first, so the list sits in a shared document while the enthusiasm cools.
The bottleneck is not ideas. It is the capacity to deploy any single workflow properly: integration against real systems, real permissions, a baseline captured before anything changes, trained operators, and a named person accountable for the outcome. That takes weeks of focused work. Splitting attention across four candidates at once produces four half-built things rather than one working one.
Prioritization is the decision that makes the rest of the work possible. It is not a ranking exercise to satisfy a planning ritual. It is the choice that determines whether anything ships.
Three dimensions: value, feasibility, risk
Score each candidate workflow on three dimensions. Use the scales in the next section. Collect the scores before the group discussion; individual scoring followed by comparison surfaces disagreement that consensus-in-a-room conceals.
The three dimensions are not equal, and they are not combined into a single number. Feasibility filters out what cannot be done now. Value distinguishes what is worth doing. Risk determines what oversight the workflow requires and whether it belongs in the first implementation at all.
Scoring scales, defined in observable terms
Each point on each scale is described in terms that a person can observe without a judgment call. “Medium” is not a point. It is an escape hatch. These descriptions are designed to force a specific choice.
| Score | Value (volume × impact) | Feasibility (data + access + owner) | Risk (consequence of error) |
|---|---|---|---|
| 1 | Rare or trivial: the task happens fewer than 10 times a month, or the time involved is under 5 minutes per instance. Even a perfect result would not be noticed. | Significant blockers exist with no clear resolution path: data is in an inaccessible system, legal or privacy constraints are unresolved, no one owns the process, no administrative access to the relevant systems. | Negligible: an error produces an obvious artifact (broken link, missing field) that the operator sees immediately and corrects before it leaves the system. No external consequence. |
| 2 | Low but real: the task happens 10–50 times a month, or involves 15–30 minutes per instance. A meaningful improvement on this workflow would be noticeable in aggregate over a quarter. | Blockers are identifiable and resolvable in weeks, not months: one permission decision outstanding, data is in a system the team has access to but has not yet connected, a process owner exists but is not yet confirmed. | Low: an error may leave the system but is quickly detected and corrected. The affected party is internal, the consequence is a rework step, and there is no reputational or financial exposure. |
| 3 | Moderate: the task happens 50–200 times a month, or involves 30–60 minutes per instance. A 20% improvement on this workflow would free at least one person's meaningful time over a month. | The path to launch is clear: data is accessible and reasonably clean, system access can be obtained within the current IT process, a process owner is named, no outstanding legal or privacy flags. | Moderate: an error may reach a client, partner, or funder, but the damage is bounded and reversible: a correction can be sent, a record amended, an apology made. Operational but not existential. |
| 4 | High: the task happens 200–500 times a month, or involves more than one hour per instance. A 15% improvement on this workflow would produce measurable organizational impact in a quarter. | Launch-ready with one sprint of integration work: data is clean and accessible, system integration is technically straightforward, permissions are granted or grantable within a week. | High: an error has direct external consequence. A wrong client communication goes out, a regulatory filing contains an error, a financial figure is misstated. The consequence is costly to reverse. |
| 5 | Very high: the task happens more than 500 times a month, or is on the critical path for a revenue or compliance obligation. Even a 5–10% improvement at this volume produces significant impact. | Integration work is already partially done or trivially achievable: the team has built something similar, the API is documented and access is already approved, and the process owner is actively sponsoring the work. | Critical: an error causes material harm (a financial loss, a compliance breach, a safety implication) that is difficult or impossible to reverse. Reputational damage is likely. |
Score each dimension independently. Do not average them. Use the scores to structure a conversation, not to replace it.
Why feasibility usually determines the winner
The most common sequencing error is picking the use case with the highest value score and treating feasibility as a secondary concern. The reasoning seems obvious: start with the biggest problem, deliver the biggest result. In practice, this approach fails often enough that it deserves a specific name. Call it the exciting-idea trap.
High value with low feasibility is a research project. It requires resolving a data access problem nobody owns, a permissions decision that has been pending for six months, or an integration with a legacy system that has no API and was last touched by someone who has left. Each of those resolutions requires a stakeholder who has other priorities and no urgent reason to move. The implementation stalls, not because the AI capability failed, but because the organizational conditions were not in place.
A workflow that scores 3 on value and 5 on feasibility will ship. A workflow that scores 5 on value and 2 on feasibility will teach the team what organizational friction looks like and leave them with nothing running at the end of the quarter.
The practical rule: among workflows with value scores of 3 or above, choose the one with the highest feasibility score. Feasibility 4 or 5 means you can complete the work in the current planning cycle with the people and permissions you already have. That is the definition of a first implementation.
First-hand experience
What stalled projects have in common
Across the implementation engagements that have stalled (the pilots that never became operations), the pattern is consistent. The chosen workflow was selected for its ambition rather than its tractability. It required a data connection nobody had built, a permission level nobody had approved, or a process owner who turned out to be a committee rather than a person. None of those conditions were invisible at the start. They were underweighted because the opportunity looked too good to slow down for.
The projects that shipped were not always the most exciting ones on the original list. They were the ones where the data was already clean enough, the system access was already granted, and the person accountable for the outcome was already identified before the work began. Feasibility is not a bureaucratic constraint. It is the condition that separates a first implementation from a research project.
Risk is a gate, not a score to average away
The most dangerous move in use-case scoring is averaging value, feasibility, and risk into a single composite number. It permits a use case with a risk score of 5 to appear viable because it has a value score of 5 and a feasibility score of 4. The math says 4.7. The reality is that a workflow whose errors produce material financial or compliance consequences cannot be a first implementation, not because it is forbidden, but because a first implementation is not a mature operation.
A first implementation is where the team learns to govern. The review point is being designed for the first time. The operator training materials are being written. The escalation path is being tested. Doing all of that for the first time on a workflow where errors are costly or irreversible is not ambitious. It is a governance design failure waiting for a bad day.
Risk should be read differently at each score level. A risk score of 1 or 2 means the workflow is appropriate for a first implementation with a standard human-in-the-loop review at sensible intervals. A score of 3 means the workflow needs a defined review point before output leaves the system, and it should not be the first project if a lower-risk alternative exists. A score of 4 or 5 does not mean the workflow is never appropriate. It means it requires mature governance, tested escalation, and an organization that has already run at least one implementation successfully. Build up to it.
Do not use averaging to make a high-risk workflow look safe. Treat risk as a prerequisite filter: if the risk score is 4 or 5, the workflow is conditionally disqualified as a first project unless no lower-risk candidates exist with adequate value and feasibility.
Principle
Averaging value, feasibility, and risk into one number is not a prioritization method. It is a way of hiding the risk score.
What disqualifies a candidate entirely
Some candidates should not be scored at all, not because they have low scores, but because a necessary condition for any implementation is absent. Spending time scoring them wastes meeting time and creates false momentum.
No named process owner. A workflow without a specific, identifiable person whose job includes it running correctly has no one to make decisions about the review point, the escalation path, or what happens when the output is wrong. “The operations team” is not a process owner.
No baseline obtainable. If the current state of the workflow cannot be measured before anything changes (because there are no records, because the task is done informally, because the volume is genuinely unknown) then a meaningful measurement of improvement is impossible. The project cannot report results against evidence.
Data cannot lawfully be used. If the workflow involves data with confidentiality obligations, retention constraints, or jurisdictional requirements that have not been assessed, using that data in an AI workflow is a compliance decision, not a technical one. Proceed only after qualified review.
No system access, with no clear resolution path. If the integration requires access to a system that the team does not control and cannot obtain access to through a defined internal process within the planning cycle, the workflow is not feasible on any useful timeline.
One-off rather than repeating. A workflow that will happen once (a specific report, a specific event) does not benefit from the overhead of a proper implementation. The setup cost exceeds the return. Frameworks are for repeating work.
Worked example: scoring six candidate workflows
This is an illustrative example constructed to show how the scoring method works in practice. It is not drawn from a real engagement and does not represent any actual organization or client. The scores reflect the conditions described in each scenario, not real measured data.
| Workflow | Value (1–5) | Feasibility (1–5) | Risk (1–5) | Risk gate? | Rank |
|---|---|---|---|---|---|
| Inbound inquiry triage: route incoming requests by type and urgency to the right queue | 4 (high volume, 200+ per month; moderate time per instance; clear operational impact) | 5 (email data is accessible, routing rules are documented, process owner is the operations lead) | 2 (routing error means a delay or a misrouted message, corrected on next review; no external financial consequence) | No (appropriate for first implementation) | 1st |
| Knowledge base answering: answer staff questions from internal documentation with citations | 3 (moderate volume; saves lookup time; value accumulates over time rather than immediately) | 4 (documentation exists, access is grantable; main work is connecting to the document store) | 2 (a wrong answer directs staff to review the source document; no automatic external output) | No (appropriate for first implementation) | 2nd |
| Invoice coding: apply GL codes to incoming invoices before approval routing | 4 (high volume, routine task; significant staff time per month in aggregate) | 3 (accounting system access requires IT approval not yet obtained; data is clean) | 3 (a miscoded invoice delays approval and requires a correction; no permanent financial harm) | No (viable once access is resolved) | 3rd |
| Grant report drafting: produce first-draft narrative sections from program data | 3 (occurs 6–8 times a year; high time-per-instance; funder relationship is high-stakes) | 3 (program data is in multiple systems; drafting process is not standardized yet) | 3 (a poor draft goes to a staff editor; external consequence depends on review quality) | No (viable, but needs process standardization first) | 4th |
| Board reporting: compile monthly board packet from financial and program data | 3 (monthly; high time-per-instance; moderate volume) | 2 (financial data requires CFO-level access not yet secured; board format varies by meeting) | 4 (a data error in a board packet has governance and reputational implications) | Conditional (high risk disqualifies it as a first project; defer until governance matures) | Deferred |
| Social content scheduling: draft and schedule posts from an editorial calendar | 2 (low volume relative to organizational priorities; moderate time saving) | 4 (social accounts are accessible; scheduling tool has an API; process owner is identified) | 1 (a poor post is caught before publication or deleted after; no lasting harm) | No (very low risk; viable but low value makes it a later addition) | 5th |
Inbound inquiry triage ranks first because it combines high value, the highest feasibility, and low risk. Board reporting is deferred despite decent value because its risk score of 4 disqualifies it as a starting point under this method. Social scheduling is viable but not a priority at this organization's scale. Invoice coding is third by score but may move earlier once the access question is resolved; feasibility is the only blocker.
Sequencing the second use case: the adjacency principle
Once the first workflow is running and measured, the temptation is to go back to the original list and pick the next-highest scorer. That is not always the right move.
The second implementation should prefer adjacency, meaning a workflow that reuses something the first one built. If the first implementation built an integration with the inbound email system, the second workflow should, if at all possible, work from that same data source. If the first workflow established a governance pattern and a review point for low-stakes output, the second one can inherit that pattern rather than design it from scratch.
Adjacency produces two compounding benefits. First, the technical work is shorter: part of the integration is already done. Second, the organizational learning compounds: the team already knows how to operate a workflow through that system, and they trust the review pattern because they have used it.
A simple test for adjacency: ask whether the second workflow reuses the same integration, the same data source, the same review point structure, or the same operator team. If it reuses none of those, it is not adjacent. It is a new project in all but name. That is sometimes the right choice, but go in knowing the full cost.
Prioritization checklist
Run this on each candidate before scoring. Items marked as disqualifiers remove the candidate from the session without scoring. Everything else informs the score.
Is there a named process owner (a specific person, not a team)?
If no: disqualify. Add to a list of workflows to return to once an owner is identified.
Can a baseline be captured before anything changes?
If no: disqualify. Measurement without a baseline is anecdote. The project cannot report results.
Is the data involved assessed for legal and confidentiality constraints?
If not assessed: disqualify pending qualified review. Do not assume the answer is fine.
Is system access obtainable within the current planning cycle?
If no clear path: score feasibility as 1. If a path exists but is not yet complete: score 2.
Does this workflow repeat? Is the frequency countable?
If it is a one-off task: disqualify. Implementation overhead is not justified.
Score value: what is the monthly volume, and what is the time or cost per instance?
Calculate the aggregate before assigning a score. A 1% improvement at 1,000 instances per month beats a 50% improvement at 10.
Score feasibility: is data accessible, clean enough, and in a system you can connect to?
Score each condition separately if helpful, then average for the dimension score.
Score risk: what is the worst realistic consequence of an error, and can it be reversed?
Use the scale definitions. Do not assume the review point you will design compensates for a high risk score. You have not designed it yet.
Apply the risk gate: is the risk score 4 or 5?
If yes: provisionally disqualify as a first project. Flag it for a later implementation cycle once governance is mature.
Among remaining candidates, rank by feasibility score, then by value score.
Choose the candidate with the highest feasibility among those with value scores of 3 or above.
Confirm: does the chosen workflow have adjacency to anything already built?
If not the first implementation, check whether the winner reuses an existing integration, data path, or governance pattern.
Common prioritization mistakes
These patterns appear regularly enough to name. Each one produces a specific failure mode.
- Scoring by enthusiasm. The workflow that generates the most discussion in the room gets the highest score. Enthusiasm is not a proxy for value, feasibility, or risk. It is a proxy for whoever in the room is most invested in a particular idea. Collect individual scores before group discussion.
- Letting the loudest department win. The department with the most organizational influence nominates a use case, advocates for it through the scoring process, and wins, not because it scored highest, but because nobody wanted the argument. Scoring in advance of the meeting and presenting the scores together reduces this.
- Picking the biggest problem. The biggest problem is often the biggest problem for structural reasons that AI cannot resolve. A workflow where the actual constraint is staffing, organizational ownership, or data quality does not become easier to implement because AI is involved. Score based on what AI can plausibly change, not on the size of the pain.
- Averaging risk into a composite score. A workflow with scores of 5 (value), 4 (feasibility), and 5 (risk) has an average of 4.7. It is not a good first project. Averaging conceals the risk score rather than addressing it. Treat risk as a filter, applied before the ranking.
- Choosing by tool availability. “We already have a subscription to this product, so let's find something to do with it.” Tool availability is not a reason to choose a workflow. It is a vendor sales argument disguised as a prioritization input. Start with the workflow, then identify the tool. The reverse produces implementations that fit the tool rather than the work.
Limitations of this method
This scoring method works best for organizations choosing among several candidate workflows for a first or second implementation. It is designed for repeating operational workflows where a person could perform the task given enough time. It is not designed for workflows that require AI to do something no person could do.
The 1–5 scales produce relative rankings, not absolute ones. Two organizations scoring the same workflow on “value” may produce different numbers because their monthly volumes differ. The scales are tools for structured conversation and comparison within a single organization, not standards for comparing use cases across organizations.
The risk gate is a practical heuristic, not a regulatory standard. Organizations in regulated industries (financial services, healthcare, legal) should apply their own compliance frameworks alongside this method, not in place of them. The risk scoring here does not substitute for a qualified legal or compliance review where one is required.
This method also does not address the sequencing of a full portfolio over multiple planning cycles. It answers the question of which workflow to do first, and which to do second given adjacency. For a longer-horizon AI program plan, additional considerations apply that are outside the scope of a prioritization guide.
For more on what happens after you have chosen a workflow, see the Practical AI Adoption Framework and the article on how to move an AI pilot into production.
External references
Independent material relevant to AI implementation sequencing and risk. Listed because useful, not as endorsement of any single framework.
Frequently asked questions
How many use cases should we score in a prioritization session?
Between five and ten is a workable range. Fewer than five may mean the organization has not generated enough options; more than ten usually means the disqualifier filters were not applied first.
Run the disqualifier checks before the scoring session. Candidates without a named owner, without a capturable baseline, or with unresolved data constraints should be set aside before the session begins, not during it. Arriving at the session with a pre-filtered list of five to eight candidates keeps the conversation focused.
What if all our candidates score low on feasibility?
That is a readiness finding, not a prioritization failure. It means the organization has AI ideas but has not yet resolved the conditions that make implementation possible: system access, data clarity, named process owners, or resolved confidentiality constraints.
The right response is to identify the specific blocker for the most promising candidate and make resolving that blocker a short-term goal. Usually one or two blockers are shared across many candidates; resolving them once unlocks several workflows simultaneously. See the AI implementation readiness criteria for a structured assessment.
Can we run two use cases at the same time?
You can, but the cost is real. Each implementation requires focused integration work, operator training, and governance design. Running two in parallel means both receive divided attention, which tends to extend each one's timeline and increase the chance that one of them stalls at integration.
The better rule: start the second use case when the first is in daily operation, not when the build phase is complete. “Complete” and “in daily operation” are different conditions: the second one means operators are actually using it, the review point is working, and early measurement has begun.
How do we handle a high-priority use case that scores poorly on feasibility?
Treat it as a project in its own right to resolve the feasibility blockers, separate from the main implementation work. Name the blocker, name who owns resolving it, and set a date for reassessment.
A feasibility blocker is usually one of three things: an access decision that needs a specific approver, a data-quality issue that needs a scoped cleanup, or a process-ownership question that needs a leadership decision. Each of those has a specific resolution path. The mistake is leaving the workflow on the priority list without a named plan for the blocker. It sits there consuming attention without moving.