NOTE: To use this template, copy the content using the “Copy page” button above, then fill in each section for your release. Use your reporting currency throughout; the worked example is in pounds.

AI business case template

This template makes the case for one release: one solution, in one domain, moving one value lever the board already cares about. It is written for a CIO taking an AI investment to the executive committee or the board, and it is built to answer the questions they ask before they approve it.

Start with a release you have already prioritised. Our AI use case prioritisation framework gets you there: board goals, the domain, the value lever and its baseline, and an ICE-scored set of use cases. This template turns that release into a decision.

Prefer to build it with Claude? Download the free skill above and add it to Claude. It interviews you for the numbers, applies every rule on this page as it goes, and writes both the one-page summary and the full case. It can also review a draft you already have.

It works at the level of one release. To size a whole programme across several domains, use our AI Programme Cost Calculator first.

What the board will test

The board’s question	Where the answer is
Which of our numbers does this move?	Section 2
What exactly are we buying?	Section 3
What is it worth, and how do you know?	Section 4
What does it cost to build and run?	Section 5
When do we get the money back?	Section 6
What could go wrong?	Section 7
Who is accountable?	Section 8
How will we know it worked, and when would we stop?	Section 9

---

Section 1: the one-page summary

Write this last. It goes first in the document, and it’s the page that gets forwarded, so it has to make the argument without the rest.

Title. A claim, not a label: “Cutting inbound lead response from a day to minutes by Q2”, not “AI Business Case”.

Headline. One sentence, in this frame:

[Team or business unit] should [recommended action] by [date]. This will result in [outcome], while avoiding [cost of the problem] created by [problem].

If you can’t fill the frame from facts you have, you don’t have a business case yet. The gaps are your list of questions for the business owner.

Decision requested	Approve [amount] to build and run [release name] for [period]
Business metric it moves	[Value lever], from [baseline] to [target] by [date]
Expected profit benefit	[expected] a year (range [low] to [high])
Total cost, year one	[amount], of which [amount] is usage
Payback	[months] in the expected case
First result reported	Day 90, to [steering committee / board]
Stop criteria	[The result below which we would not scale]
Executive sponsor	[Name]
Business owner	[Name]

---

Section 2: the problem, in the board’s numbers

Board goal this serves	[The metric on the board deck, e.g. revenue growth, operating margin]
Domain	[The end-to-end process, e.g. marketing and sales]
Value lever	[The metric at the top of the domain, e.g. sales cycle length]
Baseline today	[Measured value, date measured, source]
Target	[Value and date]
Cost of doing nothing	[What the gap costs a year if it stays where it is]

Use metrics the organisation already reports. A measure invented for the business case is the quickest way to lose the room. If you can’t state the baseline with a source, measure it before you submit the case: it’s the number the day-90 report compares against.

Then write the problem statement in two or three sentences. It needs four things: who is affected, what it costs, which company goal it hits, and why it’s getting worse. A stable problem gets deferred; a worsening one gets funded. Two frames that work:

Despite trying [previous fix], we still can’t [desired outcome] because [problem], which has cost us [cost].

Every [frequency], at least [number of people or items] are affected by [problem], costing us [cost]. If it isn’t addressed by [date], [how it gets worse].

---

Section 3: the release you’re proposing

Solution	[e.g. a lead scoring engine]
Use cases in this release	[The agents or workflows, with their ICE scores]
Who uses it	[Teams and number of people in scope]
How the process changes	[One sentence: the redesigned process, not the tools]
Claude surfaces	[e.g. Claude Enterprise, Claude Code, agents on Claude Platform]
Systems it connects to	[e.g. CRM, Microsoft 365]
What must be true for it to work	[e.g. access to the CRM data, a business owner with two days a week, an executive sponsor]
In scope
Out of scope
Target go-live	[Date; six to eight weeks from start for a release scoped to one outcome]

Name the preconditions honestly. They make the case read as analysis rather than a sales document, and they protect the people who sponsor it if one of them later fails.

---

Section 4: the benefit, in cash terms

Start with a short before and after for one person who will use the release: what their Tuesday looks like now, and what it looks like after go-live. It’s what makes the room care. The table is what makes it act.

Every benefit line needs a formula, a volume, a value per unit and an adoption assumption. Keep time saved and money made on separate lines, and don’t count the same gain twice.

Benefit	Formula	Volume	Value per unit	Adoption assumption	Revenue or cost side	Annual profit
Time returned	Hours saved per task × tasks a year × loaded hourly cost			% of eligible people using it weekly
Faster cycle	Days saved × items a year × value of a day
Higher conversion	Change in rate × volume × value per conversion
Cost avoided	Spend no longer needed (contractors, tools, rework)
Total

Convert to profit the way finance will. A benefit in a revenue domain reaches profit at your margin: at a 20% EBITDA margin, extra revenue adds a fifth of its value to profit. A benefit in a cost domain is profit in full. Mixing the two overstates revenue plays and understates cost plays.

State what the time returned is used for. Hours saved are only worth money if they go to other work, a smaller hiring plan or lower overtime. Say which, and agree it with finance.

---

Section 5: the full cost, including usage

Cost line	What it covers	Year one	Ongoing (per year)
Claude seats	Seat fee for the people in scope
Claude usage	On Claude Enterprise, usage is billed on top of the seat fee at API rates (as of September 2026; check your agreement)
Agent and API usage	Agents built on Anthropic’s API or Managed Agents platform, billed separately under Claude Platform
Build	Design, build, integration and testing, internal or external
Business time	The owner, subject experts and testers who specify and accept the release
Change enablement	Claude Champions, foundation sessions, communications
Run	Support, monitoring, model and prompt updates
Total
of which one-time investment	Build, business time, set-up, launch enablement

Usage is the line that moves, and it moves with how people use Claude, not how many have a seat. Model it as counts of people in three groups, plus the agents you run:

Usage group	Who	How to size it
Everyday users	Writing, research, summarising, analysis	Everyone licensed who isn’t in the two groups below, including people who rarely open it
Power users	Heavy daily use, long documents, sustained analysis	A named count, not a percentage of headcount
Agentic developers	Claude Code and agent building, all day	A named count; the most expensive group per person
Production agents	Agents that run without a person at the keyboard	Per agent, by runs a month; it scales with transaction volume, not headcount

Set spend limits so the worst case is a pause, not an invoice. Our AI Programme Cost Calculator gives estimated ranges for each group, and our guides to Claude Enterprise pricing and the move from Team and taking control of your Anthropic spend cover how.

---

Section 6: return, payback and a range

	Low	Expected	High
Adoption assumption
Annual profit benefit
One-time investment
Ongoing annual cost
Net annual benefit (benefit − ongoing cost)
Payback in months (one-time investment ÷ net annual benefit × 12)
Three-year net value (3 × net annual benefit − one-time investment)
Cash-on-cash (net annual benefit ÷ one-time investment)

Show the low case with the same care as the expected one. A case that still pays back in the low scenario is the one the board approves.

Is your number normal? McKinsey’s Rewired (Lamarre, Smaje and Zemmel, second edition) measured 20 successful technology and AI transformations. 17 of the 20 became cash accretive within two years (4 within one), and 14 returned at least twice their one-time investment in annual EBITDA. A release that pays back well outside those ranges needs its assumptions checked, in either direction.

---

Section 7: risks and how you’ll control them

Risk	Control	Owner
Data handling and UK GDPR (or your data protection regime)	Data classes agreed with the DPO; security review before build
Data residency	Position confirmed for each Claude surface used
Connector permissions	Scoped to the release; reviewed at the checkpoint
Low adoption	Claude Champions named before go-live; usage measured weekly from launch
Spend overrun	Organisation and group spend limits set before users arrive
Scope creep	Scope changes agreed formally at steering committee
Dependency on other work	[Named dependency and date]

---

Section 8: governance and decision points

Role	Name	Accountable for
Executive sponsor		Presents the case; chairs the steering committee
Business owner		The benefit and the value lever; signs off acceptance
Programme lead		Plan, status reporting, cost
Security and compliance		The checkpoint before build
Finance partner		The baseline, the benefit formulas, the cost model

Decision point	When	Who decides
Approve the case	Now	Executive committee / board
Go or no-go on the build	After design, before build starts	Steering committee
Go-live	After acceptance testing	Business owner
Scale, change or stop	Day 90	Steering committee, reported to the board

---

Section 9: how you’ll measure it, and when you’d stop

Measure	Baseline	Target at day 90	Stop below
Weekly active users in scope
Uses per person per week
Value lever
Cost per week (seats and usage)

Stop criteria are the results at day 90 below which you would not scale the release. Agree them now. They cap the board’s downside, which makes the case easier to approve, and they protect the programme from a release nobody uses.

---

Worked example: the benefit calculation for a lead triage agent

The figures below are illustrative, to show the method. They are not benchmarks.

A lead triage agent routes every inbound lead within minutes instead of the next working day, in the marketing and sales domain. The value lever is conversion from inbound lead to qualified opportunity.

Input	Value
Inbound leads a year	4,800
Lead-to-opportunity conversion today	12%
Target conversion	14%
Share of leads the agent handles (adoption)	90%
Opportunity close ratio	25%
Average first-year deal value	£40,000

Revenue benefit = 4,800 leads × 90% handled × 2 percentage points more conversion × 25% close ratio × £40,000 = £864,000 a year in the expected case.

This is a revenue-side domain, so convert it to profit at the margin. At a 20% EBITDA margin the profit benefit is £172,800 a year, and that’s the figure to set against the full cost in Section 5.

Run the same calculation at 1 point of improvement and 80% adoption for the low case, and 3 points and 95% for the high case.

---

Before it goes to committee

Read the case once as your CFO would, and ask three questions:

1. Could a vendor have written this? Cut any sentence that sounds like one.
2. Is every number sourced? Trace each figure to a system, a document or a named person. Anything you can’t trace comes out or becomes a clearly marked assumption.
3. Does the headline stand on its own? It’s the one sentence every reader sees.

---

Implementation notes

• One release per case. Fund the next release from the result of this one.
• Show your formulas. Every figure in Section 4 should trace back to a baseline, a volume and an assumption someone can challenge.
• Put usage in. A case with seats but no usage will be wrong by the second invoice.
• Price adoption in. The benefit depends on people using the release every week, so the case should say how many will, and how you’ll get them there.
• Agree stop criteria before you start. It’s the clearest signal to a board that the programme is run with discipline.