AI business case: separate the evidence from the assumptions

01

Start from one workflow as it runs today

Measure what the workflow costs today, in hours and money, before any AI tool is bought.

Describe one current workflow: who does the work, which decisions it holds, what it costs in time and money, what it means for the customer, and which data and systems it uses. Take the figures from records the team already keeps, such as time sheets, case logs or ticket histories.

A funder needs to know what a claimed benefit will be compared with. HM Treasury's guidance on business cases, written for UK public spending, asks for a metric and a baseline for each benefit. It defines the baseline as "The value of the benefit under business as usual conditions."

Record whether the baseline was measured or estimated. In the Department for Business and Trade's evaluation of its Microsoft 365 Copilot pilot, the diary baseline was an estimate. The time saved was the time a task took with Copilot subtracted "from the estimated time to complete the task without M365 Copilot".

02

Put a source beside every figure

Next to each expected benefit, write where the figure comes from: your own records, a test, the users' estimate or the supplier's claim.

A result reported elsewhere can inform an estimate, but the effect in your own workflow remains an assumption until tested.

Klarna's press release on its AI assistant puts a before and after next to an estimate. Customers "resolve their errands in less than 2 mins compared to 11 mins previously". The assistant is "estimated to drive a $40 million USD in profit improvement to Klarna in 2024".

03

Keep time saved apart from money saved

To claim a cash saving, show lower spending against the baseline; to claim extra capacity, show what work the saved hours can cover.

Name where the hours go: lower cost, more capacity, faster service or more revenue. Hours that change none of these are not a saving on the budget, whatever they are worth at a salary rate.

The Department for Business and Trade found small time savings on most tasks in its pilot. It also wrote: "We did not find robust evidence to suggest that time savings are leading to improved productivity." Productivity was not a key aim of the evaluation, it added, so little data was collected on it.

Participants in the cross-government Copilot trial estimated that they saved 26 minutes a day (7,115 survey responses). The findings report notes that "it was not possible to identify how time saved was spent."

Before a time figure goes into the case, write down which budget line or output it will change, and who will see the change.

04

AI business case example, with invented figures

In a bid team's case, the line the decision turns on is what the freed hours become.

A bid team of four answers requests for proposals.

Evidence: the team's time records show 40 responses last year at about 60 hours each, 25 of them spent drafting first answers.

Assumption from the supplier: its AI tool, working from past responses, halves drafting time. Test: compare drafting time and answer quality on ten comparable requests, with and without the tool.

Assumption from the team: checking the drafts adds four hours a response. Test: record the checking and correction time on the same ten requests.

If both assumptions hold, each response saves 8.5 hours: 12.5 hours less drafting, minus four hours of checking. Across the existing 40 responses, that releases about 340 hours a year.

Assumption with no source yet: the freed hours go into 15 more responses a year at the current win rate.

That forecast needs another check before a pilot. If the other work is unchanged, each response still takes about 51.5 hours. Another 15 would need about 773 hours, so the 340 freed hours do not support the forecast on their own.

The team needs a revised capacity forecast and evidence that enough suitable requests exist. The current win rate remains an assumption for the extra work. If paid costs do not fall, the released hours are not a cash saving.

05

Use the pilot to test the assumption the case turns on

Pick the assumption that would change the funding decision if it proved wrong, and design the pilot to test that one.

Compare time and output quality on equivalent work with and without the tool. The Department for Business and Trade watched users and non-users do the same tasks in its pilot. Copilot users "completed Excel data analysis more slowly and to a worse quality and accuracy than non-users, conflicting time savings reported in the diary study for data analysis."

Tie the next sum to the result. Derby City Council's cabinet report states that Phase 2 of its AI programme "will not commence until the outcomes of Phase 1 have been realised". It adds that risk will be mitigated by "phased payments based on outcomes".

After the rollout, measure the same metric against the same baseline.

If the case assumes people will use the tool well, the training is a cost line too.

06

What to ask before you fund it

Ask these questions of the case before you fund its next phase; each answer should point to a record, a test or a named assumption. For a software purchase, the five questions a business case answers also cover the options, affordability and delivery.

Which workflow does it change, and what does that workflow cost today, from our own records?

For each line of the expected effect, where does the figure come from?

What happens to the time saved: which cost, capacity, service or revenue line moves?

Which assumption does the pilot test, and what result would stop the next phase?

If the leadership team has not yet chosen the workflow, an AI potential clarification starts there, with a session where the team ranks the opportunities and agrees what evidence is needed first.