Most AI prioritization exercises produce a spreadsheet. Twenty candidates, color-coded by department, sorted by enthusiasm. By the time the meeting ends, the room has agreed that “everything is high impact” and “we need to do them all eventually.” Nobody has been told what to fund first, and nobody has been told what not to do.
That is not prioritization. That is a polite way to defer the decision.
Real AI use case prioritization answers one question: of every workflow we could change, which single one is most likely to ship, move a measurable business outcome, and earn the right to fund the next one? It is a scoring exercise, but the score is in service of a sequencing decision. You are not ranking ideas. You are choosing which workflow gets built next.
This article gives you a framework you can use this quarter. It scores candidates on four axes — impact, effort, data readiness, and measurability — applies hard filters before scoring, and produces a sequence, not just a rank. It is opinionated. It will tell some good-sounding ideas to wait. That is the point.
This piece is part of the larger question of why your AI experiments are failing — most of the time, the answer is not the model. It is what you chose to build.
Why most AI prioritization fails
Most companies do not lack AI ideas. They lack a way to choose between them.
Three patterns repeat across the executives we work with:
Pattern 1: The brainstorm list. Someone runs a workshop. Forty use cases land on the wall. They get clustered by department, voted on with dots, and ranked by gut. The top three look impressive. None of them ship.
Pattern 2: The strategic alignment trap. Use cases are scored by how well they map to the corporate strategy. Every candidate scores high because every candidate can be described in strategy language. The list has no signal.
Pattern 3: The vendor demo bias. The candidate most recently demoed by a vendor moves to the top. It has the clearest mental picture. It also has the least connection to where the company is actually losing money.
The shared failure mode: prioritization frameworks that grade ideas in the abstract, when the question is operational. The right question is not “is this a good AI use case?” It is “is this workflow we can change, in a window we can fund, with the data we have, and a metric the CFO will accept?”
That is a different filter. It produces a different list.
The 60% data-readiness reality
Gartner predicts that through 2026, organizations will abandon 60% of AI use cases that are not supported by AI-ready data — and only 12% of organizations have data of sufficient quality to support AI applications. Prioritization that ignores data readiness is prioritization that pre-orders failure.
The hard filters: rule out before you rank
Before you score anything, run candidates through three filters. These are pass/fail. A no on any filter pulls the candidate off the list.
Filter 1: There is a workflow, not just a wish. Can you describe the work in seven steps or fewer — trigger, sources, rules, judgment, output, review, next action? If the candidate is “use AI in customer success” with no defined workflow underneath, it is not ready to be scored. Send it back to be specified.
Filter 2: There is a named owner. A specific person — usually a director or VP of the function — owns the workflow today and will own it after AI is involved. No owner, no candidate. AI workflows that report to “the AI committee” do not get fixed when they break.
Filter 3: There is a defined output. What does this workflow produce, in what format, for whom, on what cadence? “Insights” is not an output. “A weekly forecast variance summary delivered to the CFO by 8 a.m. Monday” is an output. If the team cannot describe the output concretely, the workflow is not yet legible enough to automate.
These filters typically cut a 40-candidate list in half before scoring begins. That is healthy.
The four-axis scoring framework
Surviving candidates get scored on four axes. Each axis is rated 1 to 5, with explicit anchors so the scores are comparable across reviewers.
This is intentionally simpler than RICE or weighted scoring. AI use cases fail for a small number of reasons; the scorecard should track those reasons and nothing else.
Axis 1: Impact
Impact measures how much a measurable business number moves if the workflow gets changed. It is the only axis that ties to revenue, cost, speed, quality, risk, or recovered capacity.
| Score | Anchor |
|---|---|
| 5 | Moves a number the CFO already tracks; expected delta is material at the business-unit level |
| 4 | Moves a tracked number; delta is material at the team or function level |
| 3 | Moves a tracked number; delta is real but small |
| 2 | Moves a number that exists but is not tracked; you have to instrument first |
| 1 | ”Productivity,” “efficiency,” “insights” — no specific number named |
Hard rule: if you cannot name the number this workflow moves, the impact score is 1. Vague impact is the single most common reason AI pilots get killed at budget review. The companion question — what metric can this workflow move, and what is the baseline — is the topic of The Baseline Is the Strategy and What Metric Can This Workflow Move.
Axis 2: Effort
Effort measures the build-and-ship cost, in calendar weeks and people, to a production-quality version. Not a demo. Not a notebook. A workflow real users depend on.
| Score | Anchor |
|---|---|
| 5 | 4–8 weeks, 2 engineers, one external integration, well-scoped |
| 4 | 8–12 weeks, 2–3 engineers, two integrations, some new context plumbing |
| 3 | 12–16 weeks, 3–4 engineers, multiple integrations, new data pipelines |
| 2 | 16–24 weeks, cross-team coordination, new infrastructure |
| 1 | 6+ months, org change required, new platform decisions |
Score effort honestly. The most common error here is anchoring on the demo build, not the production build. Production AI workflows need evals, guardrails, observability, prompt versioning, rollback paths, and human review surfaces. Those are not optional. They are weeks of work that demo-builders skip and production teams cannot.
Axis 3: Data readiness
This is the axis that kills the most AI projects post-mortem. Score it before you start, not after.
| Score | Anchor |
|---|---|
| 5 | Data exists, is clean, is accessible via supported APIs, and is already used in production reporting |
| 4 | Data exists and is accessible, with minor cleanup or schema work |
| 3 | Data exists but is locked in PDFs, emails, or systems without APIs; significant extraction needed |
| 2 | Data is partial; new collection or instrumentation required |
| 1 | Data does not exist in a useful form; you would be building both the data and the workflow |
The Gartner finding above is not just a statistic. It is a sequencing rule. A workflow with a data-readiness score of 2 should rarely be a first project, regardless of how high it scores on impact. Build the data foundation as a prerequisite engagement, then sequence the workflow afterward.
Axis 4: Measurability
Measurability asks: at the end of the engagement, can you prove the workflow changed the number on Axis 1?
| Score | Anchor |
|---|---|
| 5 | Baseline exists, measurement is automatic, A/B comparison is possible |
| 4 | Baseline exists, measurement requires modest instrumentation |
| 3 | Baseline can be reconstructed; measurement requires new dashboards |
| 2 | Baseline does not exist; you must measure pre-state before you start |
| 1 | The outcome is inherently hard to attribute (e.g., “team morale,” “strategic agility”) |
Measurability is the difference between a workflow you can defend at the next budget cycle and one that becomes shelfware because nobody can prove it worked. This connects directly to the question of usage versus value: a workflow with high adoption and unmeasurable outcomes is indistinguishable from a workflow that nobody uses.
The scoring formula and what to do with it
Multiply Impact × Data Readiness × Measurability, then divide by Effort:
Priority Score = (Impact × Data Readiness × Measurability) / EffortMaximum possible score: 125. Practical first-project scores: 30 and above.
Why this shape, not weighted-sum?
Multiplying impact, data readiness, and measurability means a score of 1 on any of the three drags the priority near zero. That is the correct behavior. A workflow with massive theoretical impact but no measurable baseline should not beat a workflow with moderate impact, ready data, and clean measurement. The multiplicative shape is the rule.
Dividing by effort sequences ties. When two candidates have similar Impact × Data × Measurability products, the one that ships sooner wins. Sooner-to-ship matters because shipped workflows compound: they earn the right to fund the next one. Long-cycle candidates fund nothing while they wait.
This is the same logic the most disciplined AI teams apply intuitively. Make it explicit and the prioritization debate becomes a debate about scores, not gut.
Apply the filters, not just the scores
Two more rules govern what you do with the scored list.
Rule 1: Never fund a candidate scoring 1 on data readiness. No matter how high its other scores look. The pre-work — context engineering, source-of-truth definition, schema repair — becomes a separate engagement with its own measurable deliverable. This is exactly the work Operational AI Opportunity Mapping is designed to surface, and it is the work the rest of the cluster — context management, agent memory, multi-tenant data — gets built on top of.
Rule 2: For your first workflow, prefer effort 4–5 over impact 5. A workflow that ships in 8 weeks and moves a real number is worth more than one that promises to move a bigger number in 9 months. Compounding ships first. This is the same conclusion drawn in Five Signals to Help Pick Your First AI Workflow: the first workflow is not the biggest idea. It is the first place the company can prove a new way of working. The companion piece, how to choose your first AI project, drills deeper into pilot selection criteria for executives.
After the first workflow ships and pays for itself, the calculus flips. The second and third workflows can afford bigger impact bets because the operating model — context, evals, guardrails, oversight — already exists. The cost of the next workflow is marginal.
How this works in practice: a worked example
Consider four candidates from a mid-market industrials company we worked with last quarter (composite, anonymized).
| Candidate | Impact | Effort | Data | Measurability | Score |
|---|---|---|---|---|---|
| AI customer support copilot for L1 tier | 4 | 4 | 4 | 4 | 16.0 |
| Predictive maintenance across plant fleet | 5 | 1 | 2 | 3 | 30.0 |
| AI-generated weekly operating report | 3 | 5 | 5 | 5 | 15.0 |
| Sales forecast variance assistant for FP&A | 4 | 4 | 4 | 5 | 20.0 |
A naive read says predictive maintenance wins. It does not.
Pull predictive maintenance through the filters: data readiness is 2 (sensor data exists but is not yet labeled or schema-aligned), and effort is 1 (six-month build, new infra). Rule 1 sidelines it as a first project — the prerequisite is context engineering across the plant data, not the model.
That leaves the support copilot (16), the weekly operating report (15), and the FP&A forecast variance assistant (20). The forecast variance assistant wins, and the operating report ships in parallel as the second workflow because it has a 5 in measurability and 5 in effort — it is the fastest legitimate win.
That is what a prioritization framework should do: convert a long list into a sequence, with reasons.
For a deeper view of the broader operating model that puts these workflows into production responsibly, see our AI agent strategy framework guide.
Common scoring mistakes
A few patterns to watch for as you score:
- Optimism on effort. If your effort score is based on the prototype your team built last weekend, double it. Production work — evals, observability, security, oversight, prompt versioning — is most of the cost.
- Counting “saved hours” as impact. Saved hours are real, but unless those hours convert to tracked outcomes (capacity redeployed, headcount avoided, response time reduced), they will not survive the next budget review. Score impact on what shows up in the operating numbers.
- Treating measurability as a nice-to-have. A workflow you cannot measure is a workflow you cannot defend. Score it honestly. If it earns a 2 or 1, that is fine — but you must instrument first.
- Letting “strategic” candidates skip the data filter. Strategy is what survives contact with data, not what overrides it.
Where this framework fits in your operating model
A scoring framework is necessary but not sufficient. The prioritization exercise sits inside a larger operating loop:
- Map the candidates — surface the workflows that are already breaking, not the AI ideas already pitched.
- Filter ruthlessly — workflow, owner, output. No exceptions.
- Score on four axes — impact, effort, data readiness, measurability.
- Sequence, do not just rank — pick the first workflow and the second workflow.
- Build with production discipline — evals, observability, oversight, rollback.
- Measure against the baseline — prove the number moved.
- Re-score the backlog — what was a 2 on data readiness may now be a 4 because you built the foundation.
This is the loop. The scoring step is the visible part; the filtering and sequencing steps are where most of the value gets created.
It also maps directly to where AI investment ends up paying off in McKinsey’s State of AI 2025 data: companies that scale AI value are not the ones with the most candidates. They are the ones that ship a small number of workflows that move real numbers, and then compound.
For mid-market companies trying to figure out where to start, the entry point is usually an AEMI assessment — an honest baseline of where your engineering and data foundations are, what workflows are operationally ready, and what should ship first. The scoring framework above is one of the artifacts that comes out of it.
Get a Scored Backlog, Not a Wish List
Stop ranking AI ideas in the abstract. We will work with your team to identify your real workflow candidates, run them through this framework, and hand you a sequenced plan with a defensible first project.
This is one layer of the system underneath the chat box — the part that decides which problem AI gets pointed at in the first place. Most of the value in AI does not come from the model. It comes from picking the right workflow. The rest of the cluster — observability, evals, guardrails, orchestration — exists to make that workflow safe to run in production. None of it matters if the prioritization is wrong.
Frequently Asked Questions
What is AI use case prioritization?
AI use case prioritization is the process of converting a list of candidate AI workflows into a sequenced plan for what to build first, second, and third. It is not just ranking ideas. It applies hard filters (does the workflow exist, is there a named owner, is the output defined) before scoring candidates on impact, effort, data readiness, and measurability — and produces a sequence, not just a rank.
How do you score AI use cases?
Score each candidate on four axes from 1 to 5: impact (does it move a tracked business number), effort (can it ship in production form in a defined window), data readiness (does the data exist in a usable form), and measurability (can you prove the outcome moved). The priority score is (Impact × Data Readiness × Measurability) / Effort. Multiplying impact, data, and measurability means weakness on any of the three drags the priority near zero — which is the correct behavior.
Should I use ICE or RICE for AI use case prioritization?
ICE and RICE were designed for product feature prioritization. They underweight the two factors that kill most AI projects: data readiness and measurability. For AI use cases, use a framework that scores those explicitly. The four-axis model in this article — impact, effort, data readiness, measurability — is a domain-adapted version of ICE/RICE that reflects why AI projects actually fail in production.
What is a good first AI project?
A good first AI project has a defined workflow with a named owner, data that already exists in a usable form, a measurable baseline, and a production build path of 8–16 weeks. It should move a number the CFO already tracks, even if the delta is modest. Compounding matters more than ambition for the first project. See our full guide to choosing your first AI project for the criteria executives should apply.
How important is data readiness when prioritizing AI use cases?
Decisive. Gartner predicts organizations will abandon 60% of AI use cases not supported by AI-ready data through 2026, and only 12% of organizations have data of sufficient quality to support AI applications today. Never fund an AI workflow scoring 1 on data readiness as a first project. Build the data foundation as a separate, measurable engagement first.
How do I prove ROI on a prioritized AI workflow?
Define the baseline metric before you build. Instrument the workflow to produce a comparable metric after deployment. Compare. If the baseline does not exist, your first deliverable is the baseline — not the AI workflow. Measurability has to be designed in, not measured after the fact. The scoring framework explicitly weights this so candidates with no measurable baseline do not get prioritized first.