# AI Business Case Template for CIOs

> A free AI business case template for CIOs taking one AI release to the board: the value lever it moves, the benefit in cash terms, the full cost of Claude and the build, risks, governance and the numbers that decide whether to scale or stop.

Source: https://kowalah.com/resources/templates/ai-business-case-template

## Overview

- **Who it's for:** CIOs, executive sponsors, programme leads and finance partners preparing an AI investment for approval by the executive committee or board
- **When to use it:** After you've chosen a first release, when you need budget approved for it, and again for each release that follows
- **What you get:** A business case the board can test: every benefit tied to a measured baseline, every cost line including usage, and stop criteria agreed before any money is spent

## Get it

- **Claude skill `ai-business-case`:** https://18evqetn8qvaaj3d.public.blob.vercel-storage.com/skills/kowalah-ai-business-case.zip

## How to Use This Template

1. **Start from a prioritised release.** Use the output of our prioritisation framework: one solution, in one domain, with a measured baseline for the value lever it moves
2. **Copy the template, or use the skill.** Use the 'Copy page' button and fill in each section, or download the Claude skill and build the case with Claude from your own numbers
3. **Build the numbers with finance.** Agree the baseline, the benefit formula and the cost lines with your finance partner before the case goes to committee
4. **Write the summary last.** Section 1 goes first in the document but is written once every other section is complete

***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](/resources/templates/ai-use-case-prioritization-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](/resources/ai-program-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](/resources/ai-program-calculator) gives estimated ranges
for each group, and our guides to
[Claude Enterprise pricing and the move from Team](/insights/claude-team-to-enterprise)
and [taking control of your Anthropic spend](/insights/10-ways-to-take-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.

## Frequently Asked Questions

### What should an AI business case include?

The business number the investment moves and its baseline, the release you're proposing, the benefit in cash terms with the formula behind it, the full cost to build and run it (including usage), return and payback as a range, the risks and controls, who governs it, and the measures and stop criteria you'll report at day 90.

### Should we write one business case for the whole AI programme?

Write one for each release. A programme-wide case asks the board to fund a promise; a release-level case asks them to fund one measurable change, reports back at day 90, and earns the next release. The programme budget then grows with evidence rather than ahead of it.

### How do we estimate the benefit before anything is built?

Start from the value lever's measured baseline, set a target, and multiply the change by volume and value per unit. Show a low, expected and high case, and state every assumption. After launch, replace the estimate with the measured result.

### What costs do teams leave out of an AI business case?

Usage. On Claude Enterprise (as of September 2026) the seat fee covers access only and usage is billed on top at API rates, and agents built on Anthropic's API or Managed Agents platform are billed separately under Claude Platform. Two more lines get left out: the time of the business people who specify and test the release, and change enablement.

### How do we account for adoption in the business case?

Make it a line in the benefit calculation. A benefit that assumes every eligible person uses the release every week will not survive contact with the board. Set an adoption assumption per team, measure it from launch day, and report it next to the business metric.

### What are stop criteria, and why include them?

The result at day 90 below which you would not scale the release: for example, weekly use below a set level, or no movement in the value lever. Agreeing them up front makes the case easier to approve, because the board can see the downside is capped.

### Who should own the business case, IT or the business?

The business owner of the domain owns the benefit and signs the numbers. IT and the programme lead own the costs, the delivery plan and the controls. The executive sponsor presents it.

---

Free and ungated, from Kowalah, a UK Anthropic implementation specialist. More templates and skills: https://kowalah.com/resources/templates. Talk to us: https://kowalah.com/contact