Quick Navigation
- The measurement problem
- Why measurement is hard
- The AI value chain
- Calculating ROI
- Attribution — proving AI caused the outcome
- Metrics design
- Reporting to leadership
- The measurement framework in one diagram
- Cheat sheet
The measurement problem
There's a conversation I've been in with leadership teams more times than I can count.
They've invested significantly in AI. The team has built things. Pilots ran. Tools deployed. And then comes the question nobody has prepared a good answer for: what are we getting for this investment?
The team scrambles. They count models deployed. They count prompts processed. They list features shipped. And leadership hears activity, not value.
The problem isn't that AI creates no value. The problem is that nobody set up the measurement before starting.
AI measurement is not about counting things the AI did. It's about connecting AI activity to business outcomes — revenue, cost, risk, capability — in a way that leadership trusts.
flowchart TD
DEF["Define\nWhat does success look like?"] --> ATTRIB["Attribute\nProve AI caused the outcome"]
ATTRIB --> MULTI["Multiple Value Types\nFinancial · Risk · Capability"]
MULTI --> REPORT["Report\nClear, regular, trustworthy"]
The biggest reason organisations can't prove AI ROI is they never defined what value looks like before starting. Measurement must be designed before the initiative, not constructed after the fact.
Try it yourself — The value definition test
For your current or planned AI initiative, answer these four questions. Any blank answer means you haven't defined value. Do that before building anything.
| Question | Your answer | If blank, risk |
|---|---|---|
| What outcome are we targeting? | No direction | |
| How will we measure it? | No proof | |
| What does success look like? | No finish line | |
| What's our baseline today? | No comparison |
Why measurement is hard
Measuring AI ROI is harder than measuring traditional IT ROI. AI creates indirect, distributed, and sometimes intangible value that resists simple calculation.
Three factors make it uniquely challenging:
flowchart TD
HARD["Why AI Measurement Is Hard"]
HARD --> H1["Indirect Value\nAI influences decisions,\nit doesn't make them directly"]
HARD --> H2["Distributed Impact\nValue spreads across\nmany teams and processes"]
HARD --> H3["Delayed Returns\nCapability building pays off\nmonths or years later"]
| Challenge | Why it's hard | What to do |
|---|---|---|
| Indirect value | AI recommends, humans decide — who gets credit? | Measure decision quality before and after AI |
| Distributed impact | One AI system touches many processes | Track value at each point of impact |
| Delayed returns | Capability building takes time to pay off | Include leading indicators, not just lagging ones |
| Counterfactual problem | Would the outcome have happened without AI? | Use controlled experiments or baselines |
The counterfactual is the gold standard: what would have happened without AI? In practice, you approximate it. A/B testing gives the highest rigour — a randomised control group without AI. Before/after comparison is medium rigour but practical. Matched comparison is medium-high. Expert estimation is low but sometimes the only option.
AI measurement is hard because value is indirect, distributed, and delayed — not because it doesn't exist.
Try it yourself — Your measurement challenge
For your AI initiative, which challenges apply? Your most present challenge is where to invest measurement effort first.
| Challenge | Present? | How you'd address it |
|---|---|---|
| Indirect value — AI influences decisions, doesn't make them | ||
| Distributed impact — value spreads across many teams | ||
| Delayed returns — capability building takes time | ||
| Counterfactual problem — can't prove AI caused the outcome |
The AI value chain
AI doesn't produce business value directly. It produces outputs that influence decisions that produce outcomes that create value. Understanding this chain is essential to measuring correctly.
flowchart LR
ACT["AI Activity\nModels built, tools deployed"] --> OUT["AI Output\nPredictions, automations, insights"]
OUT --> DEC["Decision Changed\nHuman or system decided differently"]
DEC --> IMPACT["Business Impact\nRevenue, cost, risk, capability"]
| Link | What it measures | Example metric |
|---|---|---|
| AI Activity | What was built or deployed | Number of models in production |
| AI Output | What AI produces | Predictions generated per day |
| Decision Changed | How behaviour changed | Decisions made with AI assistance (%) |
| Business Impact | What value was created | Revenue increase, cost reduction |
Most teams only measure the first two links. Activity and output metrics are easy. Decision and impact metrics require connecting AI to business processes — harder, but essential.
The gap between "output generated" and "decision changed" is the adoption gap. If people aren't using the AI output, no value gets created downstream. That's why adoption measurement matters.
Leading indicators — adoption rate, time saved per task, user satisfaction — predict future value. Lagging indicators — revenue impact, cost reduction, risk incidents prevented — confirm past value. You need both. Leading indicators let you course-correct. Lagging indicators let you report credibly.
Try it yourself — Your value chain map
For your AI initiative, map the four links. If you can't fill the last two rows, you're measuring activity, not value.
| Link | Your metric | Current baseline |
|---|---|---|
| AI Activity — what was built? | ||
| AI Output — what does it produce? | ||
| Decision Changed — how did behaviour change? | ||
| Business Impact — what value was created? |
Calculating ROI
Leadership wants a number. The honest answer requires a framework that accounts for both tangible and intangible returns.
flowchart TD
ROI["AI ROI"]
ROI --> COST["Costs\nDevelopment · Infrastructure\nTalent · Operations"]
ROI --> BEN["Benefits\nFinancial · Risk · Capability"]
COST --> TOTAL_COST["Total Cost of Ownership"]
BEN --> TOTAL_BEN["Total Value Created"]
TOTAL_COST --> CALC["ROI = (Benefits - Costs) / Costs × 100"]
TOTAL_BEN --> CALC
Cost categories to account for: development (data preparation, model building, testing), infrastructure (compute, storage, tools, licences), talent (AI team salaries, training, hiring), and operations (monitoring, maintenance, updates). Don't forget the opportunity cost — what else could have been done with the same investment.
Benefit categories: revenue (new revenue or increased conversion), cost reduction (process automation, efficiency gains), risk reduction (fewer incidents, better compliance), and capability (new abilities the organisation didn't have before).
| Benefit type | Example |
|---|---|
| Revenue | AI-powered recommendation increases sales by 5% |
| Cost reduction | Customer service automation saves 200 hours/month |
| Risk reduction | AI fraud detection prevents £500K in losses |
| Capability | Real-time personalisation not possible before |
Capability value is the hardest to quantify — and often the most strategic. An organisation that can now do something it couldn't do before has gained an option value that may not show up in this quarter's numbers but matters enormously for competitive positioning.
Try it yourself — Your ROI calculation
For your AI initiative. If you can't fill this in, you haven't quantified value. That's your first measurement gap.
| Category | Your estimate |
|---|---|
| Annual Benefits | |
| Revenue impact | £ |
| Cost reduction | £ |
| Risk reduction (estimated) | £ |
| Capability value (estimated) | £ |
| Total annual benefits | £ |
| Annual Costs | |
| Development (amortised) | £ |
| Infrastructure | £ |
| Talent | £ |
| Operations | £ |
| Total annual costs | £ |
| ROI = (Benefits - Costs) / Costs × 100 | % |
Attribution — proving AI caused the outcome
Correlation is not causation. Just because an outcome improved after AI was deployed doesn't mean AI caused the improvement.
flowchart TD
ATTRIB["Attribution Methods"]
ATTRIB --> A1["A/B Testing\nRandomised control\nHighest rigour"]
ATTRIB --> A2["Before/After\nCompare periods\nPractical baseline"]
ATTRIB --> A3["Matched Comparison\nSimilar groups with/without AI\nMedium-high rigour"]
ATTRIB --> A4["Expert Estimation\nDomain experts estimate\nLow but better than nothing"]
| Situation | Recommended method | Why |
|---|---|---|
| Can run a controlled experiment | A/B testing | Highest rigour |
| Cannot run experiments but have historical data | Before/after with controls | Practical and reasonable |
| No clean comparison possible | Expert estimation | Better than nothing — document assumptions |
The higher the stakes, the higher the attribution confidence needed. A low-risk internal tool might be fine with expert estimation. A customer-facing AI system that affects revenue needs something stronger.
Try it yourself — Your attribution plan
For your AI initiative. If you can't answer these, you can't prove AI caused the outcome. That's your attribution gap.
| Question | Your answer |
|---|---|
| What attribution method will you use? | |
| Can you run an A/B test? | |
| If not, what's your baseline? | |
| How will you handle confounding factors? |
Metrics design
There are infinite things you could measure. The art is choosing the few that matter — and measuring them consistently.
| Criterion | Question |
|---|---|
| Aligned | Does this metric connect to a business outcome? |
| Measurable | Can we actually measure this with available data? |
| Attributable | Can we reasonably attribute this to AI? |
| Actionable | If this metric moves, can we do something about it? |
| Time-bound | When will we measure this? How often? |
The KPI framework by initiative type:
| Initiative type | Leading KPIs | Lagging KPIs |
|---|---|---|
| Automation | Tasks automated, time saved | FTE equivalent, cost reduction |
| Decision support | Decisions assisted, accuracy improvement | Decision quality, outcome improvement |
| Customer experience | Response time, personalisation rate | NPS, CSAT, retention |
| Risk management | Alerts generated, cases reviewed | Incidents prevented, losses avoided |
Leading indicators enable course correction. Don't wait for lagging results to know something's wrong.
Try it yourself — Your metrics dashboard
For your AI initiative, what 5 metrics would you put on a dashboard? If any metric doesn't have an owner and frequency, it won't get tracked.
| Metric | Type | Frequency | Owner |
|---|---|---|---|
| Leading / Lagging | |||
Reporting to leadership
The best measurement in the world is useless if leadership doesn't understand or trust the report.
flowchart LR
INV["Investment\nWhat we spent"] --> ACH["Achievement\nWhat we delivered"]
ACH --> LEARN["Learning\nWhat we discovered"]
LEARN --> NEXT["Next\nWhat we're doing"]
The leadership report structure:
| Section | Content | Time |
|---|---|---|
| Investment summary | Total spend, breakdown by category | 2 minutes |
| Value delivered | Benefits realised, with attribution | 5 minutes |
| Initiative status | What's in pilot, production, planned | 3 minutes |
| Key learnings | What worked, what didn't, what we'd do differently | 3 minutes |
| Next steps | Upcoming initiatives, resource requests | 2 minutes |
Four principles matter: be honest — report failures as clearly as successes, because credibility depends on it. Be specific — "saved 200 hours/month" beats "improved efficiency." Be consistent — same metrics, same format, every time. Be forward-looking — leadership cares about what's coming, not just what's done.
Try it yourself — Your leadership report
Draft your next leadership update using this structure. If you can't fill this in, you're not reporting — you're just tracking activity.
| Section | Your content |
|---|---|
| Investment summary — what we spent | |
| Value delivered — what we achieved | |
| Initiative status — what's in pilot, production, planned | |
| Key learnings — what worked, what didn't | |
| Next steps — what's coming |
The measurement framework in one diagram
flowchart TD
DEF["Define\nWhat does success look like?"] --> CHAIN["Value Chain\nActivity → Output → Decision → Impact"]
CHAIN --> ROI["ROI\nBenefits minus costs"]
ROI --> ATTRIB["Attribution\nProve AI caused it"]
ATTRIB --> METRICS["Metrics\nLeading + Lagging"]
METRICS --> REPORT["Report\nHonest, specific, regular"]
The discipline:
Define before you measure. The biggest reason organisations can't prove AI ROI is they never defined what value looks like before starting — and without that definition, every initiative ends the same way, with leadership asking "what did we get?" and the team scrambling to construct a narrative after the fact.
Cheat sheet — all the key terms
| Term | Plain English | Where it fits |
|---|---|---|
| AI Measurement | Quantifying AI's contribution to business outcomes | Every AI initiative |
| Value chain | Activity → Output → Decision → Impact | Where value gets created |
| ROI | All benefits minus all costs, divided by costs | Financial return |
| Attribution | Proving AI caused the outcome, not just correlation | Credibility |
| Counterfactual | What would have happened without AI? | The gold standard |
| Leading indicators | Early signals of future value | Course correction |
| Lagging indicators | Confirmed value delivered | Executive reporting |
| Capability value | New abilities the organisation didn't have before | Strategic value |
| A/B testing | Randomised control group | Highest attribution rigour |
| Expert estimation | Domain experts estimate AI's contribution | When data isn't available |
How to know if this landed
You'll know this has landed when someone defines what success looks like and how they'll measure it before any AI initiative starts. When they've captured baseline metrics before deployment — so before/after comparison is possible. When they track both leading and lagging indicators — not just activity metrics. When they've chosen and documented an attribution method for each initiative. When their leadership reports include failures as clearly as successes. When they can answer "what did we get for this investment?" with specific numbers, not narratives. And when they report capability value alongside financial value — not just the easy numbers.
What the numbers don't show — but the workshop does
The baseline exercise is the one that produces the most immediate behaviour change.
I ask teams to list the baseline metrics they captured before their current AI initiatives. The room goes quiet. Nobody captured baselines. Which means nobody can prove improvement — only activity.
The moment of recognition — watching people realise they've been measuring effort instead of impact — is the moment the measurement habit starts to form. From that point on, before any new initiative starts, the first question is: what's the baseline?
The attribution conversation produces the most uncomfortable moments. Teams that have been claiming every improvement as AI's contribution suddenly have to defend that claim. Some can. Most can't. The ones that can usually have an A/B test or a clean before/after with a control group. The ones that can't learn to say "we believe AI contributed, and here's our best estimate of how much" — which is a far more credible position than claiming certainty they don't have.
The leadership reporting template tends to resolve a conversation that's been happening for months: how do we talk about AI value without sounding like we're either overselling or underselling? The structure — investment, achievement, learning, next — gives them a format that works. Honest, specific, consistent, forward-looking. Teams that adopt it usually see executive confidence improve within one reporting cycle.
Book a Workshop
Ready to prove your AI's value — with confidence and rigour?
or
1-day workshop includes value chain mapping for your specific AI initiatives, ROI framework design with cost and benefit categories, attribution method selection for each initiative type, metrics design workshop for leading and lagging indicators, leadership dashboard template, and measurement playbook for ongoing use.