How to Prioritise AI Use Cases: A Scoring Framework

You have a whiteboard full of AI ideas and one budget line. Prioritising AI use cases is the work of turning that list into an ordered shortlist before any money moves. The method is mechanical, not magical. You inventory the repeatable processes, score each on a fixed rubric, combine the scores into one number, and cut to the few that justify going first. This guide walks the framework step by step, the way an operations, finance or IT manager would run it by hand on a Monday.

Quick Answer. To prioritise AI use cases, inventory every repeatable process, score each on ROI, Suitability and Risk, combine the three into one comparable number, then sort and cut to a top three. Scoring every candidate on the same rubric replaces gut-feel selection with a defensible shortlist. The numbers, not the loudest voice, decide.

Step 1: Inventory the processes, not the ideas

The first mistake in AI use case prioritisation is scoring the wrong unit. Teams tend to list tools ("a chatbot," "Copilot") or departments ("automate finance"). Neither can be ranked, because neither has a measurable cost, volume or error profile. The unit you score is a process, a repeatable piece of work a person does many times. Examples: invoice processing, order entry, ticket triage, quote preparation, document classification, data re-keying between systems, supplier onboarding.

Write them down without judging them yet. A useful inventory for an SMB runs to a few dozen entries, not hundreds. The point of listing everything first is to defeat the most common bias in prioritisation. That bias is scoring only the use cases someone already championed. If the inventory is drawn from "what the vendor demoed" and "what a competitor mentioned," the rubric is rigged before it runs. The back-office processes with the cleanest payback never make the list to be scored. MIT's 2025 Project NANDA study traced the dominant AI failure to exactly this kind of selection bias rather than to the technology ². The majority of generative-AI budgets went to visible sales-and-marketing use cases, while the cleanest returns sat in unglamorous back-office work. A complete inventory is the cheapest defence against repeating that pattern.

Step 2: Score each process on ROI, Suitability and Risk

With the inventory built, score every entry on the same three axes. This rubric mirrors the way analysts frame the question and aligns with established practice. Gartner's 2025 use-case framework scores candidates on business value and implementation feasibility for the same reason. A fixed rubric makes opportunities comparable ¹. AI Priority Map uses three axes rather than two. It splits feasibility into Suitability and Risk, so that the cost of an error is scored separately from the difficulty of the build.

ROI: the size of the prize. Estimate annual hours spent on the process, multiply by loaded labour cost, and apply a conservative automation rate measured for that specific process, never assuming 100%. Net out the build, licence and oversight cost, plus an error-handling overhead. The output is an annual net benefit and a payback period. The discipline that matters is doing this for every candidate on the same basis, so a finance director can check like with like.

Suitability: how well the work fits today's AI. Score how rules-bounded and repeatable the work is, how clean and structured the inputs are, and whether the task is the kind of text-or-data work current models handle reliably. A high-volume, well-structured process scores high. A one-off judgement call with messy inputs scores low.

Risk: the cost of getting it wrong. Ask three questions a manager already knows the answers to. What does a single error cost? How visible is that error to a customer or regulator? And how expensive is the human oversight needed to catch it? These questions map directly onto the NIST AI Risk Management Framework's map-measure-manage logic, applied at the level of one process rather than the whole organisation ³. Risk is the axis that protects you from the most expensive-looking idea on the board.

Step 3: Combine into one number and rank

Three separate scores do not make a decision. One combined number does. The simplest defensible combination is ROI + Suitability − Risk, the structure AI Priority Map calls the Agent Opportunity Score. ROI and Suitability are added because you want a large, achievable prize. Risk is subtracted because a high cost of error should pull a candidate down the list no matter how large its prize. The exact weighting and the 0–100 normalisation are set out in the Agent Opportunity Score guide. That is where the exact arithmetic lives.

Sort the table by the combined score and the list orders itself:

Watch the credit-decision row. It carries the highest ROI of the four and still misses the top three. Its Risk (an automated pricing or credit error is expensive and customer-facing) is subtracted out. That is the whole point of combining before ranking. The most lucrative-looking process is often not the one to automate first. A gut-feel shortlist would have championed it. The rubric demotes it on the evidence.

Step 4: Cut to a shortlist — and decide what goes first

A ranked table of twelve is not yet a plan. Draw the cut line at three. A top three is small enough for one operations team to resource and sequence. It is large enough that if one candidate stalls on a data or integration problem, two remain. Everything below the line is not discarded. It is staged on the ranked list, ready to be pulled up once the first automation lands.

The shortlist still leaves one decision the score does not make for you: which of the three goes first. The highest combined score is the usual answer, but not always. For a first project you often want the candidate with the highest Suitability and lowest Risk, the cleanest, safest win, even if its ROI is not the largest. An early visible success builds the internal confidence that funds the next one. That sequencing call is its own piece of work, covered in which processes to automate first. The score ranks the candidates. A human still chooses the first move.

Who scores, and what to do when they disagree

The framework promises that the numbers decide rather than the loudest voice. That promise is only kept if the numbers are set carefully. A score is a judgement written as a digit, and a digit inherits whatever bias produced it. So the scoring procedure matters as much as the rubric.

Score with the people who do the work, not only the people who own the budget. The person running invoice processing knows the real exception rate. A department head knows the headline. On ROI the gap between those two views is usually large, and it is always in the same direction.

Have people score independently before anyone speaks. This is the single cheapest control in the whole exercise. In a room, the first number said out loud becomes the anchor, and later scores cluster around it. Independent scoring first, discussion second, costs one extra email and removes that effect entirely.

A disagreement is information, not a problem to smooth over

When two people score the same process very differently, the instinct is to average them and move on. That throws away the most useful thing the exercise produced. Almost every wide gap resolves to one of four causes, and each has a different fix.

The last row is more common than it sounds. "Invoice processing" can mean supplier invoices in one person's head and customer billing in another's. A scoring session surfaces that confusion cheaply, which is worth the session even if no automation follows.

⚠️ On Risk, do not average. ROI and Suitability are estimates and an average of two estimates is reasonable. Risk is a claim that something could go badly, and one person having seen a failure the other has not is not a reason to split the difference. Take the higher score and record why.

Check that the ranking survives being wrong

A ranked list feels precise. The inputs behind it are estimates, so the ranking is only useful if it is stable under estimates being somewhat off. That check takes ten minutes and almost nobody does it.

Move the top candidate's ROI down by a quarter and the runner-up's up by a quarter. Then look at the order again. If the top three are unchanged, the ranking is robust and you can commit to it. If they reshuffle, you have learned something more valuable than the original list: the difference between those candidates is inside your own margin of error, and the choice between them should be made on something the score does not capture, such as which team has capacity this quarter.

Do the same on Risk, in the direction that hurts. Raise the risk score of your favourite candidate by one band. A favourite that survives that is a genuine favourite.

When to score again

Re-score when an input the scores depended on has actually changed, and not on a calendar. Three events qualify. A process changed shape, so its volume or its inputs are no longer what you scored. A blocker cleared, so an integration you had marked infeasible is now available. A candidate completed, which frees the capacity assumption every remaining score was made against.

Write down the reason, not only the score

Each score should carry one line of reasoning beside it. Not a paragraph. One line, naming the assumption the number rests on: "60% automation rate, because 40% of these arrive as scanned PDFs".

This costs a few minutes during the session and pays back twice. The first time is immediately, because writing the reason is what surfaces a disagreement that a bare number hides. Two people can write 7 for entirely different reasons and never discover it.

The second time is months later. A ranked table without reasoning ages into a list of numbers nobody can defend. Someone asks why the credit decision scored low, and the honest answer becomes "we discussed it at the time". With one line per score, the answer is on the page, and re-scoring means editing an assumption rather than starting the whole exercise again.

⭐ The completed-project trigger is the one most teams miss. The scores below the line were set while your team was fully committed. Once the first automation is stable and running, the suitability of the next candidate has genuinely improved, because the people who would run it now have both time and one deployment's worth of experience. The list you built three months ago was correct then and is quietly out of date now.

When this framework breaks down

A scoring framework is a tool, and recommending it universally would be the same gut-feel error in a different coat. It breaks down in three honest cases.

When the inventory is biased, the rubric launders the bias. A clean rubric run over a list of only the use cases someone already wanted produces a confident-looking ranking of the wrong candidates. The framework is only as good as the completeness of Step 1. The score cannot recover a process that was never listed.

When the real constraint is data or integration, not selection. Some SMBs already know their top process but cannot automate it because the data lives in a system nobody can integrate with. Then the binding constraint is integration debt, and scoring will only confirm a process you already suspected. The pre-flight questions in 50 questions to ask before implementing AI surface that kind of blocker before you spend a scoring session on it. Many of those questions feed directly into the Suitability and Risk scores.

When weights are applied carelessly. Treating all three axes as equal is wrong in regulated work, where the cost of an error should dominate. A scoring framework is a discipline for thinking, not a substitute for it. If Risk in your sector routinely outweighs ROI, weight it accordingly and say so, rather than hiding the judgement inside an equal-weighted average.

What to do on Monday

Open a spreadsheet. List your repeatable processes in column A. Add columns for ROI, Suitability and Risk, score each row on the questions above, and put the combined score in the last column. Sort descending, draw a line under row three, and you have a defensible shortlist. It is built in an afternoon, with the arithmetic visible to anyone who challenges it.

You might rather have it done rigorously: the full process inventory, the calibrated scoring, the ranked top three, plus a phased implementation roadmap and an IT brief your team or integrator can act on. That is what AI Priority Map's AI Foundation Audit delivers, in a 40–90 minute guided wizard, with the package within 24 hours and a money-back guarantee if no process with measurable savings is found. Either way, the move is the same one the broader AI opportunity assessment for SMBs makes its core argument. Score the processes first, and let the numbers, not the loudest pitch, decide the order.

Summary

Prioritizing AI Use Cases — let the numbers decide
│
├─ Score processes, not ideas
│   ├─ Unit — a repeatable process, not a tool or department
│   └─ List everything — a complete inventory defeats bias
│
├─ Three axes per candidate
│   ├─ ROI — the size of the prize, on the same basis
│   ├─ Suitability — how well the work fits today's AI
│   └─ Risk — the cost of getting it wrong
│
└─ Combine, rank, cut
    ├─ One number — ROI + Suitability − Risk, then sort
    ├─ Highest ROI ≠ first — risk can demote the big prize
    └─ Cut to three — resourceable, and one can stall

Related insights

• AI Opportunity Assessment for SMBs: Rank Your Top 3 Wins — the cornerstone overview this how-to puts into practice.
• What Is the Agent Opportunity Score? — the exact ROI + Suitability − Risk arithmetic behind the ranking.
• Which Processes to Automate First — choosing the clean first win from your shortlist.
• 50 Questions to Ask Before Implementing AI — the pre-flight diligence that feeds your Suitability and Risk scores.

Last updated: June 2026. Version 1.0.