Every AI business case contains a benefit. It is usually on the second or third page, expressed as a percentage improvement, a number of full-time equivalents released or a rand figure per year. It is the reason the money was approved.
Then it vanishes. Not dramatically. Nobody decides to stop tracking it. The project simply moves into delivery, where the work is about building the thing, and the benefit sits in a document that nobody opens again until someone asks for next year's budget.
This is not unique to AI. Technology programmes have lost their benefits this way for decades. AI makes it worse for two reasons. AI spending is variable and recurring, so an untracked benefit is paid for every month rather than once. And AI use cases tend to touch the same few workflows, which makes overlapping claims more likely.
CloudNala's view is that a benefit without an owner, a baseline, a measurement method and a review date is not a benefit. It is a hope with a number attached. This part looks at where benefits go missing and what a benefit record needs to survive delivery.
Indigo Mutual is fictional, and its systems and figures are illustrative. It is the financial services group from Part 1, which has committed about R96 million to fourteen AI use cases and was recently asked by its CFO which of them had paid off.
Where the benefit goes
Trace any single benefit at Indigo Mutual from business case to the twelve-month mark and the same sequence repeats.
At the business case, the sponsor forecasts a 15% reduction in average handling time in the contact centre. The committee approves it. During delivery, scope changes: the integration with the policy administration system is harder than expected, so the first release only covers short-term insurance queries. Go-live happens on time for the reduced scope. At six months, nobody measures handling time against the original baseline, partly because nobody recorded the baseline and partly because the reduced scope makes the original forecast meaningless anyway. At twelve months, the budget request quotes the original 15% as if it had happened.
Each step was reasonable. The outcome is a claim nobody can defend.
The bottom lane of the diagram is not much more work. The baseline is recorded before the change, from the same system that will measure the outcome. A named executive takes ownership of the benefit at approval, not the project manager. The measures are built during delivery as part of the product, not bolted on afterwards. When scope changes, the forecast changes with it, in writing. And there is a dated review at which the owner presents evidence, not a slide.
Five ways a benefit dies
Indigo Mutual's finance team catalogued how its benefits had gone missing. Five causes covered nearly all of them.
The sponsor moved. The person who signed the business case changed roles within a year in four of the fourteen use cases. Their successors did not consider the forecast theirs. Benefits must be owned by a role and transferred explicitly when people move, just as budget authority is.
The baseline was never recorded. Business cases quoted industry figures or vendor estimates for current performance. Once the AI was live, the old process no longer existed to measure.
Scope changed and the forecast did not. Delivery reality reduced scope, as it almost always does, but the benefit stayed at the original number.
The benefit was not observable. The business case promised "better decisions" or "improved staff experience" with no event or dataset that could show it. Those may be real goods, but they cannot carry a rand figure in a board pack unless someone defines how they will be seen.
The benefit was counted twice. This one deserves its own section.
Double counting
Indigo Mutual had three use cases aimed at its contact centre: an agent-assist tool that suggests answers during calls, a smarter call-routing model and a self-service bot on the app and WhatsApp. Each business case was prepared by a different team, at a different time, with a different vendor.
Each case claimed savings in agent capacity. Agent assist claimed 40 FTE. Routing claimed 25. The bot claimed 30. Together, 95 FTE. When finance looked at the contact centre itself, the work that AI could plausibly remove, on the most generous assumptions, was about 52 FTE. The rest of the contact centre's time was spent on complex claims, complaints and regulatory calls that none of the three tools touched.
Nobody lied. Each team measured its tool against the whole contact centre as if the other two did not exist. The result was a portfolio that promised nearly twice what was physically available.
Double counting is prevented in two ways. First, every benefit is booked against a named benefit pool: a specific workflow, cost line or revenue stream that is finite and measured. Second, the portfolio owner checks, before approval, whether the new claim draws on a pool that other use cases have already claimed. If it does, the claims are reconciled up front, not discovered a year later.
What a benefit record needs
The fix is not a bigger business case. It is a small, durable record per benefit that outlives the project.
| Field | Why it matters |
|---|---|
| Benefit statement | One sentence, observable: "average handling time on short-term queries" not "efficiency" |
| Benefit pool | The finite workflow, cost line or revenue stream it draws on |
| Owner (role and person) | Who presents the evidence, and who inherits it if they move |
| Baseline and date | Measured value before the change, from the system that will measure after |
| Target and range | Expected value, date, and an honest range rather than a point |
| Measurement method | The event, report or dataset that produces the number |
| Known confounders | Other changes in the same period that could explain movement |
| Scope link | Which release delivers it, so a scope change forces a forecast change |
| Review dates | When evidence is presented and who decides on it |
At Indigo Mutual this record now lives in the same register as the use case, maintained by the benefit owner and reviewed by finance. It is one row, not a document. That is deliberate: a benefit that needs a twenty-page document to explain is usually a benefit nobody can measure.
Who owns what
One distinction made the biggest practical difference: separating delivery ownership from benefit ownership.
The delivery team owns building the use case well. It is accountable for scope, quality, timelines and the measurement plumbing. It is not accountable for the benefit, because it does not control whether the business changes the way it works.
The benefit owner is a business executive who controls the workflow where the benefit lands. For the contact-centre use cases, that is the head of customer service, not the AI team. Only someone with authority over rosters, processes and staffing can turn freed agent time into a lower cost or a better service. If nobody with that authority owns the benefit, freed time just becomes slack.
This also answers a question that often stalls AI programmes: "who signs off the benefit?" The benefit owner presents. Finance tests the evidence. The committee decides. Part 5 covers how those levels of confidence are shown to the board, and Part 8 turns the individual records into a portfolio ledger.
A practical start
Organisations with an existing AI portfolio cannot go back and record baselines that were never taken. They can do three things this quarter:
- Name an owner for every material benefit, from the business side, and record it.
- Reconcile the benefit pools. List every claimed saving by the workflow it draws on. Where the claims exceed the pool, cut them now, before someone else does in a board meeting.
- Take a baseline today for anything still changing. Even a late baseline is better than none, as long as it is labelled as such.
For new use cases, the nine approval questions in Part 1 do most of the work. The point is to treat the benefit as something the organisation must actively manage, the same way it manages the cost.
Next: Part 3, Instrument the customer journey, not only the infrastructure. All parts are on the series page.
How CloudNala can help
We run benefit-definition workshops that turn the forecasts in existing AI business cases into owned, measurable benefit records, and we reconcile overlapping claims across a portfolio before they reach the board. For new use cases, we help sponsors set baselines and measurement methods at approval, when doing so is cheap.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Value Review or write to us at consult@cloudnala.co.za