Business Case from Real Numbers

Why this matters

Most AI business cases are built on projected savings that no one later measures. That is how budget gets spent and learning does not happen. The projection gets approved, the initiative ships, and the follow-up question — "what did it actually save?" — gets answered with a dashboard that nobody is assigned to maintain. A usable business case starts from the current cost of the work and names the check.

What you will be able to decide after this

• Whether the initiative's numbers survive a skeptical reading — before the money moves.
• What the real cost categories are, including the ones the proposal wants to skip.
• Which assumption the whole case rests on, and whether it is tested.

Core lesson

A usable business case starts from the current cost of the work:

• Time spent today — the actual hours, from the actual people, not the estimate on a slide.
• Error and rework cost — the loops, the corrections, the re-dos, counted.
• Volume — how much work, over what period.
• Downstream impact of delays or mistakes — what a wrong or slow answer costs further along.

Then it estimates the change in those numbers under a realistic adoption scenario — including the cost of verification, integration, change management, and ongoing maintenance. Those four are where the optimism hides. The demo shows the drafting time; it does not show the reviewer time, the plumbing, the training, or the monitoring that starts on launch day.

Optimism is not a number. A projected 60% saving with no named mechanism is a hope. A projected 30% saving with a measured baseline, a named verification cost, and a date to check it is a number.

Worked example

Current state: 4 people spend ~25 hours/week on first-pass ticket triage and drafting. Error rate that requires rework is ~18%. The proposed AI assist: expected to cut drafting time by 40% but add 8–10 minutes of verification per ticket on complex cases. The honest business case shows the net hours — the 40% cut on drafting against the added verification time on the complex share of volume, not a headline. It shows the residual error risk — the 18% does not go to zero because AI misses things and reviewers miss AI's misses. It shows the ongoing cost of monitoring the system — the drift review, the log checks, the named owner. The slide version of this case showed "40% faster." The real version shows three numbers moving in different directions and a date when the after-numbers get collected.

Practice

For the initiative you are evaluating, write the current-state numbers you already have — time, error, volume, downstream impact. Then write the expected change in each, and for every change, write the mechanism: "because …" If a change has no mechanism, mark it as an assumption.

Apply — produce the artifact

Build the one-page business case for a real or realistic AI initiative. Include current baseline numbers, expected changes, all major cost categories (including verification, integration, change management, and ongoing maintenance), and the assumptions that would most affect the result. State how and when the numbers will be checked after launch.

Verify

Have someone skeptical — finance, operations, or a peer who has seen failed initiatives — review the assumptions. If a key assumption is untested or unrealistic, revise or flag it explicitly.

Sources

This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.