29 May 2026
Measuring the ROI of an AI project: what leadership actually needs
How to measure AI ROI without falling for vanity metrics: the KPIs leadership actually cares about, the baseline to define before the AI project starts, and the simple value story that survives the board room.
Leadership is not asking for a magic score. It is asking for defensible value.
When leadership asks how to measure the ROI of an AI project, the real question is rarely a finance exercise in the narrow sense. What they want to know is whether the project removes a real operational constraint: wasted time, costly errors, limited team capacity, blocked revenue, or unmanaged process risk. In other words, AI ROI is not primarily an elegant spreadsheet. It is credible evidence that the initiative creates business value somewhere the company actually cares about.
In client work with teams such as Brut, Pathé, and ESCP, my starting point is therefore not "what model accuracy can we show?" but "which decision, workflow, or workload gets better in a way the business can feel?" An AI project becomes legible to leadership when measurement stays attached to the real work. If the system shortens editorial preparation, reduces manual rework, or increases the throughput of support or ops teams, then KPI, measurement, adoption, and return on investment become serious topics rather than presentation theater.
The four KPIs that usually matter most in an AI project
In practice, four KPI families usually cover the real value story. The first is time saved, but only when measured against meaningful volume. Saving five minutes on a rare task changes nothing. Saving five minutes across 4,000 monthly cases changes cost, capacity, and service levels. The second is error reduction: fewer corrections, fewer escalations, fewer manual reviews, fewer cases that need to be reopened. The third is adoption, because a system nobody uses creates no AI ROI regardless of how impressive the demo looks. The fourth is direct business impact: more revenue, protected margin, better conversion, or faster handling of requests tied to commercial outcomes.
The key is not to choose these KPIs generically. They must reflect the specific shape of value in the workflow. With Brut, that may mean shortening part of a content production cycle. With Pathé, it may mean making an operational chain more reliable where every mistake creates delay and coordination cost. With ESCP, it may depend heavily on adoption of an internal tool, because without adoption there is no durable measurement of business value at all. Good AI ROI measurement is contextual. It follows the workflow carrying the value.
ROI is designed before the first sprint, not after the demo
A common failure pattern is to talk about measurement too late. Teams build first, demo second, then try to invent a return-on-investment narrative afterward. That is backward. Before the first sprint starts, the project needs a simple baseline: current task time, current error rate, volume processed, human effort involved, service expectation, and one named owner for measurement. Without a baseline, the AI project may look promising but it will be impossible to defend the result in front of a skeptical leadership team.
I also prefer expectation ranges over heroic promises. For example: target a 20 to 30 percent time reduction on a tightly scoped workflow, or a measurable drop in manual rework after eight weeks of live usage. That framing protects the project from overclaiming. It also makes room for the way value often appears in real deployments: first time saved, then better quality, then potentially revenue impact once adoption is strong enough. Leadership generally responds better to staged value than to inflated certainty.
The measurement traps that destroy credibility
Bad metrics are usually easy to spot. Number of prompts written, tokens consumed, workshops held, demo satisfaction, users invited, AI features shipped: all of those can be useful activity metrics for the delivery team, but they say almost nothing to leadership about outcomes. They measure effort or excitement, not value. That is why vanity metrics damage trust so quickly in an AI project. They create movement on paper without proving that anything important changed.
Even adoption can become a vanity metric when handled badly. A high adoption rate only matters if usage actually replaces friction or improves a business KPI. Likewise, a faster model is not a better outcome if the error rate rises and wipes out the gain. The rule is straightforward: measure business outputs, not only technical inputs. An AI project becomes much easier to defend when the measurement discipline is outcome-first from day one.
Build an ROI story that can survive the board room
The strongest ROI story often fits on one page. Starting point, working hypothesis, selected KPIs, expected adoption level, gain per case, monthly volume, implementation cost, run cost, and payback window. If you can say, "across 2,500 monthly cases we save seven minutes on average and reduce manual rework by 18 percent, with 68 percent adoption after two months," you already have a board-room-ready story. The measurement does not need to be perfect. It needs to be readable, honest, and tied to how the team actually operates.
In the end, leadership does not want a lecture on finance. It wants a simple case that survives three questions: where is the value, how are we measuring it, and what must be true for the return on investment to be real? Answer those clearly and the discussion changes. You move out of vanity metrics and into a language leadership can use: AI ROI, business value, adoption, tradeoffs, and evidence that the system is improving an actual business outcome rather than following a trend.