How to build an AI business case: a template for UK SMEs

What is an AI business case?

An AI business case sets out the expected costs, benefits, risks and assumptions of a proposed investment so leadership can approve, revise or reject it. Define the baseline and success measure before purchasing a tool. A worked example is useful only when its workload, capacity and cash assumptions are consistent.

This guide gives a structured template, a defined set of benefit categories, a worked example, and a one-page format suitable for board approval. It is designed for UK SMEs and mid-market firms making investments in the £10,000 to £250,000 range, where formal business-case discipline pays for itself but enterprise-grade governance is overkill.

What belongs in an AI business case

An AI business case has five sections, each with a clear purpose. Skipping any section reliably produces a case that does not survive scrutiny.

1. Problem statement. What are we trying to solve, and what is the current cost of not solving it? Quantify the cost in pounds, hours, or error counts where possible. "We need AI" is not a problem statement; "we spend 28 hours a week reconciling supplier invoices and the error rate is 4%" is.
2. Proposed solution. Which AI tool or approach, and why this one over the alternatives? Reference the build vs buy assessment that led to this option being recommended over off-the-shelf, configure, or do-nothing.
3. Costs. One-off plus ongoing, over a defined period (three years is the standard horizon for SME AI investments). Include implementation, licensing, hosting, training, change management, and an explicit contingency.
4. Benefits. Quantified in at least one of the three benefit categories below, with payback as the summary metric. Include only evidenced benefits.
5. Risks and sensitivity. What has to be true for the benefits to land? What happens to the case if a key assumption is wrong by 25%, 50%, or 100%? Naming the sensitivities up front is what separates a credible case from a marketing brief.

A measurement plan should identify who owns the baseline, how adoption will be recorded and which benefits can actually be realised. Treat projected time savings separately from a reduction in cash expenditure.

Three benefit categories and a payback metric

Separate benefit categories from the payback metric below. The first three describe sources of business value; payback summarises their timing. Together they cover the case and exclude the vague claims that make business cases unconvincing.

• Time saved. Hours per week freed up, costed at the average fully-loaded hourly rate of the affected role. Time saved counts only when it can be redeployed to higher-value work or when it is a measurable headcount avoidance, not as a vague productivity claim.
• Cost avoided. Spend that is eliminated or reduced. Examples: third-party services no longer needed, error-correction overhead reduced, customer support costs reduced, recruitment costs avoided through internal capacity gain. Each line item should reference a real current cost.
• Revenue unlocked. New revenue enabled by the AI deployment. Examples: faster sales cycle, higher conversion rate, new product capability that justifies a price increase, grant or contract funding secured because of the AI capability. Revenue cases are stronger when there is a comparable baseline.
• Payback period. Months or years until cumulative benefit exceeds cumulative cost. Not a benefit in its own right, but the summary metric that makes the other categories comparable across competing investments.

Use only the benefit categories supported by the evidence. Claiming benefits without evidence is a credibility liability, not an asset.

Hard vs soft metrics (and why hard metrics should lead)

Hard metrics are quantified in pounds, hours, percentage points, or defect counts. Soft metrics are qualitative: employee satisfaction, decision speed, brand perception, employee retention. Both are real, and both have a place in an AI business case.

The reason hard metrics should lead is that business cases led by soft metrics do not get approved by finance functions and do not survive scrutiny after deployment. Six months in, when the CFO asks "did the £40,000 investment pay back?", a case built on "improved decision speed" cannot answer the question. A case built on "average ticket handle time reduced from 12 to 8 minutes, with the released capacity measured separately from any cash saving" can.

Use soft metrics as supporting evidence, not as primary justification. A typical structure: lead with the hard metric in the headline benefit; reference the soft metric in the narrative; capture both in the post-deployment measurement plan. Where the hard metric proves out, the soft metric usually has too. Where the hard metric does not, the soft metric on its own will not save the investment from being labelled a failure.

Worked example: customer service AI for a 40-person UK SME

The example below is illustrative. Every figure is indicative for a UK SME of the stated size and is not a quoted fee from The AI Consultancy.

Problem. A 40-person firm has four agents handling 80 tickets a day across the team. At 12 minutes per ticket, that is 16 agent-hours a day, or four hours per agent. Other duties and service coverage must be measured before drawing a conclusion about spare capacity or a proposed fifth hire. This example assumes 250 working days a year and constant ticket volume for the arithmetic below.

Solution. Deploy an AI triage and drafting tool integrated with the existing helpdesk. The tool drafts initial responses, suggests knowledge-base articles, and routes complex tickets directly to the senior agent. Build vs buy assessment recommended an off-the-shelf enterprise SaaS deployment over a custom build because the workflow is standard and time to value matters more than ownership.

Costs (Year 1). Tool licence £15,000; implementation and integration £8,000 one-off; staff training and change management £2,000 one-off. Total Year 1 cost £25,000. Years 2 and 3 ongoing licence £15,000 per year.

Projected capacity. Reducing handle time from 12 to eight minutes saves 320 minutes, or five hours 20 minutes, across the team each day. At the same 16 agent-hours devoted to tickets, theoretical capacity rises from 80 to 120 tickets a day, not from 320 to 480. Annual time released would be about 1,333 hours if all tickets achieve the reduction. This is a forecast, not a measured outcome or evidence that a hire can be avoided.

Payback. The stated costs total £55,000 over three years: £25,000 in Year 1 and £15,000 in each subsequent year. At constant volume the projected time released totals 4,000 hours over three years. Recovering £55,000 would therefore require at least £13.75 of realised value per released hour across that period. This is a break-even threshold, not a cash-saving forecast. No payback date can be established until finance confirms which hours create additional contribution or avoid expenditure, and when.

Sensitivity. Test the reduction on a representative ticket sample, including exceptions and rework. At half the projected time saving, only 2,000 hours are released over three years and the value required to cover £55,000 rises to £27.50 per hour. Allow for adoption, quality, volume and service-level changes. A planned hire is a separate staffing decision, not an automatic benefit of faster handling.

Run your own version of this calculation using the AI ROI calculator, and substitute your own role costs, ticket volumes, and adoption assumptions.

Sensitivity analysis: what you must flag

Four sensitivities should be called out explicitly in every AI business case. A case that ignores any of these is incomplete, regardless of how strong the headline numbers look.

1. Adoption rate. If staff do not use the tool, the benefits do not land. Define a minimum adoption threshold (typically 60% of the affected staff using the tool weekly by Week 8) and note what happens to the case if adoption is below that. Adoption is the single most common reason AI investments under-deliver. See our AI change management and employee adoption guide for the structural patterns that drive adoption rates.
2. Data quality. If the AI is pointed at unstructured, outdated, or inconsistent data, outputs degrade and benefits shrink. Quantify the data preparation work in the cost section, and flag the case as dependent on the data work being completed before the AI goes live.
3. Process change. If workflows are not redesigned to take advantage of the tool, the time saved is not real time. A 4-minute reduction in ticket handle time is only useful if those minutes are redeployed; left unredeployed, they vanish into longer breaks and slower starts. Flag what process redesign is in scope and who owns it.
4. Vendor risk. If the vendor changes pricing, terms, or deprecates the product, the business case re-opens. Note the vendor's last pricing change, the contract length, and the deprecation notice period. For the diligence questions that should be answered before signing, see our AI vendor selection and due diligence checklist.

The one-page board format

Senior approval depends on the case fitting on one page. Anything longer is not read in the meeting. Use the structure below; anything that does not fit goes in an appendix.

• Problem (3 lines). What we are solving and the current cost of not solving it.
• Solution (3 lines). Which approach, why this one over alternatives, and the maturity classification (pilot, production).
• Costs (table). Year 1, Year 2, Year 3, including implementation, licensing, training, contingency.
• Benefits (table). Hard metrics only on the front page. Soft metrics in the appendix. Stated in pounds, hours, or percentage points per year over three years.
• Payback (1 line). Months or years to break-even, plus three-year net.
• Top 3 risks (3 bullets). The three sensitivities most likely to derail the case, with the threshold and the mitigation for each.
• Recommendation (1 line). "Approve a £X investment to achieve Y over Z, with the first checkpoint at month N."

If the case requires more than one page to make, the case is not yet ready for the board. Compress, decide what is essential, and move the rest to the appendix.

Common mistakes that sink AI business cases

Three patterns reliably produce business cases that get rejected at the board or fail post-deployment. The first is a benefits column built on category-fit ("we need AI to keep up") rather than on quantified outcomes. The second is a costs column that omits internal staff time, change management, and the data preparation work needed before the AI can produce useful outputs. The third is a missing or token sensitivity section, which signals to the board that the proposer has not stress-tested their own case. None of these are AI-specific failures; they are business-case failures applied to an AI investment.

Where to start

If you are about to make the case for an AI investment, start with the problem statement and quantify the current cost of inaction in pounds and hours. From there, the solution and costs follow naturally. Use three benefit categories and payback as a summary metric to structure the upside, include only evidenced benefits, and run sensitivities on adoption, data quality, process change, and vendor risk. Compress the result onto one page and walk it through with finance before you take it to the board. For broader strategy resources, see the AI strategy section of the Knowledge Hub. To run a structured business-case assessment for a specific use case, see our AI strategy service or run an internal first pass using the AI ROI calculator.