How to prioritise AI use cases: a scoring model for value vs feasibility

Most organisations do not have an AI idea problem. They have an AI prioritisation problem. Once you run a few discovery sessions, the backlog fills up fast: the contact centre wants summarisation, finance wants invoice extraction, the CEO read something about agents on a flight, and someone in legal is quietly terrified. Everything sounds plausible. Nothing is obviously first. That is where ai use case prioritisation earns its keep — a repeatable way to rank candidates so you spend your first budget on the things most likely to work, not the things with the loudest sponsor.

The summary you can act on: score every candidate use case on two axes — value and feasibility — plot them, and commit to delivering the high-value, high-feasibility quadrant first. Do it as a facilitated workshop with the people who actually own the data and the process, force real numbers onto the scores, and be ruthless about pet projects that score badly. The output is not a spreadsheet. It is a sequenced roadmap you can defend to a board.

Why you need a scoring model at all

Without a model, AI use case prioritisation defaults to politics. The use case that gets funded is the one with the most senior sponsor, the loudest vendor, or the shiniest demo. That is exactly how organisations end up with an impressive pilot that never reaches production — a pattern we see so often we wrote a whole piece on why most enterprise AI pilots fail. A scoring model does two useful things. It makes the trade-offs explicit, so a decision to fund something risky is a conscious one. And it depersonalises the “no”, so killing a weak idea becomes a data conversation rather than a status fight.

The model does not need to be clever. It needs to be honest, consistent, and applied to every candidate the same way. Complexity is the enemy here — a 40-criteria weighted matrix looks rigorous and gets abandoned by week two. Two axes, a handful of sub-scores each, is enough.

The two axes

Value: what is it worth if it works?

Value has two components, and you should score them separately before combining.

• Financial value. The hard dollars. Hours saved multiplied by loaded labour cost, error reduction, avoided headcount growth, faster cycle times that free up revenue. Be specific: “reduces claims triage from 12 minutes to 4” beats “improves efficiency”. If nobody can put a defensible number on it, that itself is a signal — score it low and note the assumption.
• Strategic value. The things that do not show up cleanly in a spreadsheet: competitive positioning, capability building, customer experience, risk reduction, board optics. Real, but easy to inflate. Discipline it by asking “would we fund this on strategic grounds alone if the financial value were zero?” Usually the answer is no.

Score each from 1 to 5. I weight financial roughly 60 percent and strategic 40 percent for most mid-market clients, but the exact weighting matters less than applying it consistently. If you want a structured way to pressure-test the financial side, our AI ROI calculator and the CFO framework for measuring AI ROI give you the shape of a defensible business case.

Feasibility: how likely is it to actually ship?

Feasibility is where most prioritisation exercises are too generous, because engineers score technical difficulty and forget everything else. Break it into four sub-scores.

• Data readiness. Does the data exist, is it accessible, is it clean enough, and are you allowed to use it? This is the single most common thing that kills a “simple” use case. A brilliant idea sitting on top of data locked in a legacy system nobody can extract from is not feasible this year.
• Technical difficulty. Is this a well-trodden pattern (retrieval-augmented Q&A, document extraction, classification) or genuinely novel? The choice of approach changes the difficulty enormously — see RAG vs fine-tuning vs prompting — and a use case that needs a bespoke agentic workflow is a different beast to one solved by prompting over your existing knowledge base.
• Change and adoption difficulty. How many people need to change how they work, and do they want to? A technically trivial tool that 200 frontline staff will quietly ignore has low feasibility. This sub-score is routinely underrated and routinely fatal.
• Risk and governance load. How much regulatory, privacy, safety, and reputational weight does this carry? A customer-facing use case handling personal information under the Privacy Act and the APPs — or anything inside an APRA-regulated process — needs governance effort that a purely internal, low-stakes tool does not. Higher load lowers feasibility for a first project, even if it does not rule the idea out later. If you are in a regulated sector, factor in the Voluntary AI Safety Standard expectations from the outset.

Score each sub-score 1 to 5 (5 = easy/ready/low-risk), average them, and you have a feasibility number. The four sub-scores also double as a diagnostic: a use case that is high value but scores 2 on data readiness tells you exactly what to fix before it becomes viable.

Plotting the grid

Put value on one axis and feasibility on the other, and every candidate lands in one of four quadrants.

1. High value, high feasibility — do these first. These are your quick wins and your credibility builders. Deliver two or three of these before you touch anything else. They fund the programme politically and financially, and they teach your organisation how to actually ship AI.
2. High value, low feasibility — invest to unlock. Genuinely valuable but blocked, usually on data or governance. Do not attempt these as your first project. Instead, spin up the enabling work — data remediation, a governance framework, a platform decision — so they migrate into quadrant one next cycle.
3. Low value, high feasibility — do if cheap, otherwise skip. Easy to build, not worth much. Fine as filler or as a way to keep momentum, but do not let easy-to-build masquerade as important.
4. Low value, low feasibility — kill these. Hard and not worth it. The only reason they survive is sponsorship. Say no clearly.

The grid does the political work for you. When a senior leader’s favourite idea lands in quadrant four, the conversation is about the scores, not about them.

Be honest about pet projects

Every prioritisation exercise has at least one pet project — the idea that arrives pre-funded in someone’s head. The discipline is not to exclude it. It is to score it on exactly the same criteria as everything else, in the same room, out loud. Sometimes the pet project scores well and you have simply confirmed a good instinct. More often it scores in quadrant three or four, and the value of the exercise is that everyone can see why.

Two guardrails help. First, require a named owner and a real number for the financial value of every candidate, sponsor’s favourite included — vague benefits are the tell of a weak case. Second, separate scoring from decision-making by a day if you can, so the scores are set before the horse-trading starts.

Run it as a workshop, not a survey

Scoring in isolation produces garbage, because no single person knows the data readiness, the technical difficulty, the change load, and the governance weight of every candidate. Run it as a facilitated session with the right people in the room: process owners, a data or platform person, someone who understands the compliance surface, and the business sponsors.

A workable format:

• Before: collect the raw backlog and force each idea onto a one-line “who does what, and what gets better” description. Vague entries get sent back.
• In the room: score value first for the whole list, then feasibility, one sub-score at a time across all candidates — scoring the same dimension for everything keeps the scale consistent. Debate the outliers; the disagreements are where the real information is.
• After: plot the grid, agree the first cohort, and name the unlock work for quadrant two.

The AI readiness questions are a good warm-up to surface the data and governance realities before people start scoring optimistically. If you would rather not facilitate this cold, our AI Readiness Sprint runs exactly this exercise as a fixed-scope engagement, and the self-serve AI readiness assessment gives you a baseline before the workshop.

Turn the grid into a sequenced roadmap

A quadrant chart is a snapshot; a roadmap is a plan. Take your quadrant-one cohort and sequence it: which two go first, what the enabling work is for the next wave, and what the decision points are for the blocked-but-valuable ideas. Attach the business case, the owner, and the governance requirements to each. Revisit the whole grid every quarter — feasibility changes as you remediate data and build capability, and last cycle’s quadrant-two idea is often this cycle’s quick win.

Done well, this exercise is the backbone of an AI strategy: a defensible, board-ready view of what you are doing, in what order, and why. If you want a hand running the prioritisation workshop or turning the output into a funded roadmap, get in touch — it is the kind of first step that saves a great deal of wasted pilot budget later.