The return on AI comes from colleagues changing the way they work, yet most spend still goes on the tool.A new tool in an old process just gives you the old process. The firms getting a return build AI into their core workflows and train people to work differently with it, so they deliver quality at pace. That change is what drives P&L benefit. As budgets get cut, keep the projects where change management is a core line of the delivery plan and someone clearly owns the tooling.
Higher revenue growth (2022-24) at companies led by 'AI-first' CFOs, IBM global study
newsroom.ibm.comEstimated revenue needed to justify 2026 AI infrastructure spending, Sequoia analysis
techcrunch.comShare of finance leaders unable to measure the ROI of AI initiatives, Gartner® estimate
newsroom.ibm.com3 briefings this month, with 2 new figures that passed our source checks.
subscribers read every briefing in full, and get each one on WhatsApp. subscribe free · how we research and check sources
| what often gets reported | what shows a return |
|---|---|
| Licences bought and seats active | Hours or cost removed from a named process |
| Pilots launched | Use cases live in core workflows |
| Prompts run and usage growth | Error rate, cycle time or revenue moved against a baseline |
| Demo results | Value reported in the P&L |
We treat ROI as a design input, not a report at the end. If a use case cannot be tied to a line in the P&L before it is built, it is an experiment, and it should be funded and judged as one.
The organisations that see returns do fewer things, closer to the core of the business, and measure them from day one. Licences and pilots spread across every team produce activity. They rarely produce value.
Hype is an operating problem, not a marketing one. It pulls organisations into three traps: buying the tool before the problem is defined, optimising for something shipped rather than work changed, and pushing data, integration and governance into a phase two that never arrives.
how we help: define the value. →our frameworks: the Lumo method · the value framework
Set a baseline before anything is built: the time, cost, error rate or revenue the use case is meant to move. Assign an owner, agree the target and measure against it in the P&L, not in a demo. Adoption and usage are leading indicators, not the return.
Because value was never defined up front. Projects start from a tool rather than an outcome, sit outside core workflows, and stall at pilot stage. Without a baseline there is nothing to measure the result against.
Well-scoped use cases in core workflows can show measurable value within one or two quarters. Broad platform and licence rollouts take longer, and often never pay back unless they are tied to specific workflow changes.
Pause the spend that has no value case, not the programme. Redirect budget to the few use cases with a clear owner, a baseline and a line in the P&L, and fund anything else as a time-boxed experiment.
Optimising AI work for "we shipped something" rather than "we changed how the work runs". Pilots launch on data nobody trusts, use cases are chosen because a vendor demoed well, and the portfolio fills with demos that never leave proof of concept. The way out is fewer use cases, chosen for the workflow they change and measured against a baseline.