How to Score an AI Use Case Before Anyone Buys Software

Because tools are the cheapest part to talk about and the hardest part to unwind once the contract is signed. PwC's 28th Annual Global CEO Survey found 56% of CEOs say GenAI improved time efficiency, 32% say it increased revenue, and 34% say it increased profitability. Then IBM's May 6, 2025 CEO study asked a stricter question and got a stricter answer: only 25% of initiatives delivered the ROI leaders expected. The gap is not that executives are lying. It is that they are grading different things. One is sentiment about promise. The other is the return on a specific bet.

A score forces the room onto the second question before any money moves. One workflow. One owner. One number the workflow is supposed to move. One path to finding out whether it actually moved. That is the discipline we use in a 10x audit, because the fastest way to waste an AI budget is to fund something that still sounds good after the nouns are removed.

This is also where the fractional ai officer seat earns its keep. Someone has to be allowed to say, out loud, that a use case with no baseline is not a use case yet and that a workflow with no accountable owner is a political wish wearing a technical costume.

Score each proposed use case from 1 to 5 on four dimensions, then multiply by the weights below.

1. Value, 35%. If the workflow does not move a cost, revenue, quality, risk, or capacity number the business cares about, the rest is theater.
2. Feasibility, 25%. The model may exist and the integration may still be a mess. This is where teams confuse a good demo with a buildable system.
3. Risk, 25%. NIST's AI Risk Management Framework says AI risk work has to be practical and operationalized. That means the workflow needs a real control boundary, not a promise to be careful later.
4. Time to evidence, 15%. Faster learning gets a smaller weight than value, but it still matters because a use case that cannot produce evidence soon enough tends to survive on politics.

The weighting is lopsided on purpose. Value gets the biggest share because the use case exists to move a real number. Feasibility and risk tie because a buildable unsafe workflow is still a bad bet, and a safe workflow you cannot actually implement is not a bet at all. Time to evidence matters less than the other three, but it still decides sequencing because learning in six weeks is worth more than confidence in a slide deck.

A 5 means the evidence is already in the room. A 1 means the room is mostly guessing.

For value, a 5 has a named business metric, current baseline, volume, and a believable mechanism for improvement. A 3 has a real pain point but loose math. A 1 sounds like "people will save time" with no number attached.

For feasibility, a 5 means the workflow is narrow, repetitive, and technically boring in the best sense. Inputs are reachable, outputs are clearly defined, and the team already knows where the ugly edge cases live. A 1 depends on brittle integrations, unstructured exceptions nobody has mapped, or model behavior the team cannot evaluate. When that is the shape, pay for discovery first or hand the job to a custom AI build only after the workflow gets smaller.

For risk, score high only when wrong answers can be caught before they cause damage. NIST's AI RMF 1.0 and the companion playbook keep coming back to the same idea: trustworthiness has to be built into use, not stapled on at launch. If the workflow touches regulated data, sends customer-facing messages, or changes money movement, the score falls fast unless the human review path is explicit and the evaluation set exists before launch.

For time to evidence, a 5 means the team can collect a clean baseline now and see a result inside one quarter. A 3 means the signal exists but needs cleanup. A 1 means the only proof would arrive after the budget season changed, by which point the workflow will still be living on narrative.

Four conditions suspend the math.

1. No accountable business owner. A technical sponsor is not enough. Someone has to own the workflow change and the number attached to it.
2. No baseline. If nobody knows the current cycle time, error rate, or labor cost, the use case cannot prove improvement.
3. No lawful data path. If the data rights, retention rules, or access model are unresolved, the use case is deferred until they are not.
4. No reversible failure mode. If a wrong output sends money, customer commitments, or regulated content with no review step, the test stops here.

Those are not edge cases. They are the main way shiny AI requests waste a quarter. A weighted score compares candidates that are eligible to be tested. It does not rescue a request that still fails basic operating discipline. That is why the best backlog owners write the hard stops down before the first workshop instead of inventing them when the most political request lands.

Take a support team that wants AI to draft first-pass replies for tier-one tickets. This is an illustrative example, not a benchmark and not a claim about any company's measured result.

It scores well on value because the workflow usually has volume, repeatable intents, and a baseline the team already tracks: handle time, reopen rate, escalation rate, and CSAT. It scores well on feasibility because the task is constrained and the knowledge sources are reachable. It does not get a perfect risk score because customer-facing language can still cause damage if the model invents policy, misses account nuance, or replies with the wrong tone. Keeping a human in the loop is not optional in the first phase. It gets a strong time-to-evidence score because the team can test against a live ticket slice inside weeks, not quarters.

That lands the example at 78 out of 100. Good enough to test. Not good enough to let the model answer customers on its own. The result is a bounded pilot with acceptance criteria, reviewer ownership, and a stop rule. If the same room tried to score autonomous outbound prospecting, the risk and reversibility bands would collapse and the hard-stop rule would likely kill it before the total mattered.

That is the whole reason to use one scorecard across unlike ideas. The loudest request and the best first request are rarely the same thing.

Use bands, not decimals.

• Test: 75 to 100, provided every hard stop clears. Fund a bounded pilot with one owner, one metric pack, one review date, and one stop condition.
• Defer: 55 to 74, or any use case that would otherwise score well but still fails one hard stop. Name the missing evidence and park it until that specific issue is fixed.
• Reject: below 55, or any workflow whose downside stays unacceptable even after guardrails. Write down why so the room can stop relitigating it next month.

A defer is not a polite yes. It means the workflow is not ready to absorb money yet. Most of the time the missing work is boring and worth doing anyway: baseline collection, cleaner permissions, a shorter exception path, or a sharper owner. That is why the best scoring sessions often end with infrastructure work at the top of the queue and the glamorous use case pushed back a month.

McKinsey's 2026 survey adds another reason to be strict here. Forty-four percent of respondents say AI is scaling across the enterprise, but only 37% report any EBIT impact and only 6% qualify as high performers. The companies getting value are not the ones with the most ideas. They are the ones willing to sequence fewer bets and redesign the workflow around them.

A score like 78 is only useful if everyone in the room understands what it is not. It is not a forecast. It is not a benchmark. It is not a guarantee that the vendor demo will survive contact with your data.

Four rules keep the math honest.

1. Score in whole numbers only. If someone wants a 3.7, they do not understand the evidence well enough yet.
2. Keep written evidence beside every score. If the value score says 4, the supporting baseline and owner should be written in the same row.
3. Use the same scoring team across candidates. Changing the room changes the score more than changing the workflow.
4. Rescore quarterly. Feasibility rises after shared data pipes exist. Risk can fall after controls improve. Time to evidence usually gets shorter after the first two builds.

This is also where executive discipline matters. IBM's 2025 CEO study says 64% of CEOs admit fear of falling behind drives some technology investment before the value is clear. A scorecard is a defense against that exact impulse, but only if the room agrees in advance that a mediocre score means no deal today.