A scoring model for ranking AI use cases

Every AI readiness assessment ends with the same problem. You have twenty candidate use cases, credible sponsors for most of them, and capacity for two. The list has to become an order, and the order has to survive a board conversation.

Most scoring models fail because they optimize a single axis — usually a value estimate that nobody believes. The model below uses three, and the third is the one teams routinely leave out.

Axis 1 — Economic value

Not strategic value. Not "AI readiness". The annualised effect on a line item someone in finance already tracks: revenue, gross margin, cost to serve, or working capital.

Force the estimate into that shape and roughly a third of the candidate list evaporates on contact, because the sponsor cannot name the line. That is not a loss. A use case whose value cannot be located on the P&L will lose every prioritization fight it ever enters, and it is cheaper to discover that now.

Score it as a range, not a point. A use case worth $2M–$12M is a different bet from one worth $6M–$8M, and a point estimate hides that.

Axis 2 — Feasibility, weighted by data you control

Feasibility is usually scored as model difficulty, which is the least informative component. The binding constraint is almost always the data: whether it exists, whether it is reachable, whether you own it, and whether it stays stable.

Weight the score by how much of the required data sits inside systems you control. Data from a vendor whose contract renews in eight months is not the same asset as data from your own transactional database, and a feasibility score that treats them identically will send you into a dependency you cannot renegotiate.

The binding constraint is almost never model difficulty. It is whether the data stays stable and whether you own it.

Axis 3 — Reversibility

How expensive is it to be wrong? This is the axis that gets skipped, and it is the one that determines sequencing more than either of the others.

A ranking change on an internal tool is cheap to reverse: ship it, watch it, roll it back on Thursday. A model that touches pricing, credit decisions, or anything a customer sees at the moment of purchase is not — the cost of being wrong includes trust you cannot buy back, and sometimes a regulator.

High reversibility is what lets you move fast without governance theatre. Low reversibility is where the governance actually belongs. Conflating the two is why so many AI programmes are simultaneously too slow on the safe work and too casual on the dangerous work.

Putting it together

Score each axis one to five. Do not average them — averaging lets a strong value score hide a fatal feasibility problem. Read them as a triple and sort into four groups:

• High value, high feasibility, high reversibility — start here, this quarter, regardless of how unglamorous it looks.
• High value, high feasibility, low reversibility — worth doing, but it needs the governance and a slower rollout. Sequence it second.
• High value, low feasibility — this is a data project wearing an AI project's clothes. Fund it as one, with a data owner and a longer horizon.
• Low value — say no in the room, in writing, with the reason. Unkilled use cases come back every planning cycle and cost more each time.

The output is not a score. It is a sequenced roadmap with the economics attached and the reasoning legible to whoever has to fund it. That is the artifact the board is actually asking for when it asks for an AI strategy.