Where the Value Actually Comes From

Before hunting for use cases, be clear about what a use case is supposed to produce. There are four patterns, they behave very differently, and confusing them is how business cases fall apart under scrutiny.

The four patterns

1. Cost reduction. The same output, less input. Fewer hours on a task, fewer errors to rework, fewer people needed for the same volume.

The catch is the one every finance director raises: saved time is not saved money unless something actually changes. Twenty people each saving thirty minutes a day is ten hours a day of capacity — and precisely zero on the P&L until either headcount changes or those ten hours produce something you would otherwise have paid for. Module 4 treats this properly, because it is the single most common way an AI business case gets destroyed in the approval meeting.

2. Speed. The same output, sooner. Quotes returned in an hour rather than two days. Claims settled same-day. Onboarding that takes twenty minutes instead of a week.

Speed converts to money when it changes a rate: more deals won because you quoted first, less working capital tied up, fewer customers lost while waiting. If it does not change a rate, it is a comfort improvement — which may still be worth having, but should be claimed as that.

3. Quality and consistency. Fewer errors, less variation between people, better decisions at the margin. Often the most defensible pattern because the baseline is measurable: you know your current error rate, or you can find out.

4. New capability. Something you could not do at all before because it was uneconomic at your scale. Reading every customer conversation rather than a sample. Giving every customer a tailored response rather than a template. Reviewing 100% of contracts rather than the ten largest.

This pattern is the most interesting and the most under-exploited, because it does not show up as a line item you can cut. It shows up as work that was never on anyone's plan, and so nobody proposes it.

The visibility bias

The MIT NANDA report identified a pattern worth naming, because you will feel its pull personally: organisations bias investment toward visible, front-office functions — marketing especially — while the higher-return opportunities sit in back-office work that nobody wants to present at a conference.

The reasons are human rather than analytical. Front-office AI is demonstrable to a board, it sounds like innovation, and it is where vendors concentrate their marketing. Back-office AI is invoice matching, claims triage, document extraction, reconciliation, ticket routing — unglamorous, boring to present, and frequently sitting on exactly the characteristics that make AI work: high volume, repetitive judgement, recorded outcomes, tolerable error cost.

The same report also found that pilots based on externally sourced solutions succeeded roughly twice as often as internally built ones — about two-thirds against about one-third. Hold that finding; module 5 is built around it.

For now, take one practical instruction from this: when you build your candidate list in module 2, deliberately look in the places nobody wants to demonstrate.

Which pattern is this proposal claiming?

A discipline to apply to everything that reaches you. Ask which of the four patterns is being claimed, then ask the pattern's own question:

• Cost: what specifically stops being spent, and when?
• Speed: which rate changes as a result, and by how much?
• Quality: what is the current error rate, and how do you know?
• New capability: what becomes possible, and what is it worth?

Proposals that cannot answer their own pattern's question are not ready. Proposals that claim all four at once are almost always claiming none of them — that is a marketing document, not a business case.