AI value cases often move too quickly from a technical effect to a financial claim.

A model completes a task faster, so labour cost is assumed to fall. An assistant helps write more proposals, so revenue is assumed to rise. A forecast is more accurate, so inventory or working capital is assumed to improve.

Each outcome is possible. The connection must be demonstrated rather than implied.

A useful measurement model follows a causal chain:

AI capability → changed decision or workflow → changed operational measure → changed financial or strategic outcome

1. Define the business outcome first

Choose the financial or strategic outcome the business is trying to change. Typical value pools include:

  • revenue growth or conversion;
  • gross margin or contribution;
  • avoidable operating cost;
  • productive capacity;
  • working capital;
  • service and retention;
  • quality, compliance or risk;
  • speed to market or decision.

Be precise about the unit of value. “Productivity” can mean faster completion, more output, fewer people, better quality or reduced delay. Those are not financially equivalent.

2. Establish the baseline

Measure how the work performs before the new capability is introduced.

Depending on the opportunity, the baseline may include:

  • volume and demand mix;
  • handling or cycle time;
  • waiting time and handoffs;
  • rework and exception rate;
  • error, quality or compliance rate;
  • conversion, cancellation or retention;
  • cost per completed outcome;
  • staffing and utilisation;
  • model, supplier and infrastructure cost;
  • downstream failure demand.

Use a representative period and cohort. Separate observed data from estimates. Document seasonality or other factors likely to change during the test.

Without a baseline, the project can report movement but not confidently attribute it.

3. Write the value hypothesis as a chain

A strong hypothesis makes every link visible.

For example:

If the capability identifies likely order exceptions earlier, operational teams can resolve them before dispatch. That should reduce cancellation, protect fulfilled revenue and lower avoidable service work.

This is stronger than “AI will reduce cancellations” because it names the changed decision and the operational mechanism.

For each link, define a measure:

  • capability: precision and recall of exception detection;
  • workflow: proportion reviewed in time and action taken;
  • operation: cancellation rate and service contacts;
  • finance: fulfilled revenue and avoidable cost.

4. Distinguish time saved, capacity released and cost removed

This is the most common source of inflated AI business cases.

Time saved

A task takes fewer minutes. This is a real operational improvement.

Capacity released

Enough time is released across a role or team to perform additional valuable work. This becomes value only when the extra capacity is used productively and demand exists.

Cost removed or avoided

Staffing, contractor spend, overtime or future hiring is reduced. This is a financial effect, but it may occur gradually and can involve transition cost.

Do not price every minute at a fully loaded salary and call the result savings. State which conversion mechanism applies.

A useful value model shows:

  • theoretical time released;
  • realistic utilisation of that time;
  • productive use or staffing consequence;
  • timing of the financial effect.

5. Measure quality and demand effects

Faster work can create lower quality, extra review or downstream rework. Conversely, better quality may be the primary source of value even when the task takes the same time.

Track both intended and countervailing effects:

  • acceptance without revision;
  • expert review time;
  • errors and reversals;
  • customer contact or complaint;
  • downstream rework;
  • conversion or abandonment;
  • risk events and near misses.

The correct unit is the completed business outcome, not the model interaction.

6. Include the full cost of the capability

The cost side of the value equation should include more than tokens or licence fees.

Consider:

  • model and infrastructure usage;
  • software and vendor charges;
  • integration and data pipelines;
  • product management and engineering;
  • human review and exception handling;
  • security, risk and compliance;
  • monitoring and evaluation;
  • training, communication and adoption;
  • parallel running and transition;
  • ongoing improvement and support.

Some costs are one-off, some scale with volume and some are shared across opportunities. Make those distinctions visible.

7. Design a credible comparison

The strongest test design depends on the work and risk. Options include:

  • a matched control group;
  • staggered rollout;
  • before-and-after comparison with adjustments;
  • randomised allocation where appropriate;
  • a defined cohort with historical benchmarks;
  • expert blind review;
  • shadow mode before the capability influences decisions.

No method removes all uncertainty. The goal is to reduce the uncertainty that matters to the investment decision.

Watch for confounding effects such as seasonality, changing demand, new incentives, staffing changes or concurrent process improvements.

8. Use leading and lagging measures

Financial value can take time to appear. Use leading measures to understand whether the mechanism is working without allowing them to replace the outcome.

For example:

LevelExample measure
CapabilityRelevant exceptions detected
BehaviourUsers act on the recommendation
WorkflowResolution before the failure point
OperationLower cancellation rate
FinancialRevenue protected

The first four provide evidence about the chain. The fifth is the result.

9. Assign a value owner

A finance partner can validate the method. A technology owner can measure capability performance. The business must own whether value is realised.

The owner should agree:

  • the baseline;
  • the value hypothesis;
  • the conversion assumptions;
  • the measures and data source;
  • the scale, revise and stop thresholds;
  • when value will be recognised;
  • who is accountable for changing the surrounding workflow.

10. Update the case with observed evidence

The original business case is a hypothesis. After Build and Prove, replace assumptions with observed evidence wherever possible.

Show:

  • what changed;
  • what did not;
  • the range of plausible value;
  • the full cost at the tested and expected scale;
  • the remaining uncertainty;
  • the operating changes needed to realise the value;
  • the decision now recommended.

Avoid false precision. A credible range with explicit assumptions is more useful than a single impressive number built on weak conversion logic.

A compact AI value equation

Use this as a starting structure:

Net value = realised revenue or cost effect + risk/working-capital value − full capability cost − transition cost

Then make the realisation mechanism explicit.

For productivity:

Realised capacity value = time released × sustainable adoption × productive utilisation × economic value of the redeployed capacity

For cost:

Realised cost value = staffing or spend genuinely removed or avoided − transition and ongoing operating cost

For revenue:

Realised revenue value = incremental volume or conversion × contribution margin × credible attribution

The standard to use

An AI initiative has a credible P&L case when leadership can see the complete chain from capability to work to operation to finance, the baseline is known, the full costs are included and the assumptions that convert operational change into money are explicit.