How to Create an AI Business Case

Frame the decision before describing the technology

Write one decision sentence: who must decide what, by when, and within which authority. Then define the present problem using a stable baseline. Record the affected workflow, current volume, service level, error or rework pattern, people involved, data boundary, and consequence of leaving the problem unchanged. Separate measured facts from estimates and assumptions.

The 2026 UK Green Book describes five linked dimensions for a business case: strategic, economic, commercial, financial, and management. Its requirements apply to specified UK public spending, not automatically to every organization. Used as a thinking framework, however, the five dimensions prevent a narrow cost calculation from standing in for strategic fit, deliverability, or risk. The companion HM Treasury business-case guidance sets out a step-by-step Five Case Model process and was updated in June 2026.

State measurable objectives without presuming that AI is the answer. For example: “Reduce median triage time from 18 to 12 minutes by 31 March while keeping every high-consequence request under human review.” A weak objective—“deploy an AI assistant”—confuses the proposed intervention with the outcome.

Sources: [1] [2]

Compare options on one evidence ledger

Always include the current process, a non-AI improvement, and at least one bounded AI option. Add “defer and collect evidence” when uncertainty is material. Compare every option using the same fields:

Use a claim-to-case ledger with columns for claim ID, case dimension, statement, claim type, source, source date, calculation, confidence basis, accountable owner, verification test, and status. A forecast is not an observed result. A supplier estimate is not an independent baseline. Time saved per draft is not a cash benefit unless the organization explains how released capacity will be used.

The NIST AI Risk Management Framework Core says AI risk work should document context, roles, impacts, measurements, monitoring, and risk treatment across govern, map, measure, and manage. It is voluntary and does not approve a proposal. Use its outcomes as prompts for evidence gaps: intended use, people affected, third-party dependencies, human oversight, monitoring, incident handling, and leadership responsibility.

• objective contribution and affected groups;
• one-off and recurring cost ranges, with basis dates;
• expected benefits, timing, and named evidence owners;
• data, integration, supplier, review, and change-management dependencies;
• failure modes, reversibility, exit cost, and residual risk;
• operational capacity needed to verify outputs and handle exceptions;
• assumptions that could change the ranking; and
• a test that would disconfirm each material claim.

Sources: [3]

Build the five cases as one connected model

For the strategic case, connect the baseline problem to organizational objectives and name constraints. For the economic case, compare alternatives and show whose costs and benefits count. For the commercial case, record supplier capacity, switching constraints, data rights, intellectual-property terms, and exit provisions. For the financial case, show cash timing, internal labor, contingency, and sensitivity. For the management case, define ownership, stages, controls, measurement, rollback, and review dates.

Cross-link repeated claims rather than copying them. If the financial case assumes a 30 percent reduction in review time, the management case should identify how review time will be measured and who will act if the result is smaller. If the commercial case relies on one provider, the risk section should show the exit test and migration cost. Record disagreement and missing evidence instead of smoothing it into confident prose.

AI can classify source material, generate an initial option list, check arithmetic, or challenge omissions. Preserve the exact inputs and cited records for material claims. An accountable author should verify calculations, contractual facts, and source meaning before the case reaches an approver.

Worked business-case evidence ledger

Suppose a synthetic customer-operations team receives 8,000 internal requests each month. A four-week sample shows a median triage time of 18 minutes and a 6 percent routing correction rate. The decision is whether to fund a twelve-week intervention before the annual peak.

The team compares four options: keep the current workflow, simplify the intake form, add deterministic routing rules, or pilot AI-assisted classification with human confirmation. Its ledger records that an initial AI demonstration used only 120 easy requests, so the claimed 70 percent automation rate is marked “unsupported for planning.” The team constructs a stratified 600-request historical test set, freezes category definitions, and finds 83 percent correct first-route suggestions overall but only 61 percent for privacy-related exceptions.

The revised AI option retains human confirmation for every request and blocks automated routing for the exception category. Its financial case includes reviewer time, evaluation work, monitoring, supplier fees, security review, and a 20 percent contingency. The management case defines three gates: representative offline test, limited live pilot, and expansion review. Expansion stops if high-consequence exceptions fall below the pre-set acceptance threshold or if the review queue grows.

The recommendation is a bounded pilot, not a full rollout. The decision record states that the intake-form option remains the fallback and that no productivity or service outcome has yet been demonstrated. Every claim in the executive summary links back to the ledger row, calculation, and owner.

Verify the case before approval

Ask an independent reviewer to reproduce material calculations and trace each executive-summary claim to the ledger. Re-run the ranking under lower benefits, higher review costs, delayed integration, and supplier exit. Confirm that option scopes are comparable and that the preferred option does not receive more favorable assumptions. Check that the named approver has authority for the spend, data use, residual risk, and operational change; those may be different decisions.

Return the case for repair if the baseline cannot be reproduced, a credible alternative is omitted, benefits lack a use plan, dependencies have no owner, or the delivery plan has no stop condition. Approve only the stated stage and conditions. Log the decision, evidence version, dissent, expiry, and next review date.

Two Prune can place a participant in a realistic business-case simulation and observe how they frame the decision, navigate evidence, use AI support, verify claims, and communicate tradeoffs. That produces assessment evidence about observed work in the simulation. It is not investment advice, procurement approval, assurance, proof of business impact, or an automated employment decision.