AI Strategy3 November 20269 min read

After the Hype — Part 1 of 5

Faster emails are not a business case

An AI assistant that saves fifteen minutes a day per person sounds like a large saving until you ask where the fifteen minutes went. Part 1 of After the Hype sets out the five links between task speed and a business result, and why most AI business cases assume all five hold.

#AI Value Realisation#AI Adoption#AI Strategy#AI Governance

A common AI business case in South African organisations right now has a familiar shape. Take the number of staff with access to an assistant. Multiply by the minutes it saves each of them per day. Multiply by working days and an average cost per hour. The result is a large number in rand, usually much larger than the licence bill, and the case is approved.

The arithmetic is not wrong. The assumption underneath it is. It treats a minute saved on a task as a minute of value delivered to the organisation. In practice, most of those minutes disappear somewhere between the person's screen and the income statement, and nobody notices because nobody was asked to follow them.

The AI hype is correcting, and that is healthy. CloudNala has already argued that the boardroom honeymoon is over and value has to be proved, that consumption is not value, and that the useful unit of cost is cost per accepted outcome. This series, After the Hype, picks up from there. It asks what an organisation should do differently once it accepts those points. This first part deals with the claim that sits under most productivity business cases: that faster tasks mean a more productive organisation.

Tsitsikamma Hardware Group is fictional, and its systems and figures are illustrative. It is a building-supplies retailer headquartered in George, with branches across the Garden Route and Eastern Cape and a trade desk that quotes for builders and contractors. Last year it gave an AI assistant to about 1,100 office and branch staff.

The fifteen-minute arithmetic

Tsitsikamma's business case said the assistant would save each user about fifteen minutes a day on email, quotes, summaries and documents. At 1,100 users and roughly 220 working days, that is about 60,000 hours a year. At a blended cost of R250 an hour, the case claimed R15 million of productivity against a licence cost of under R5 million.

A year later the finance director asked a simple question. If the organisation gained 60,000 hours, where are they? Headcount had not changed. Overtime had not fallen. The trade desk was not quoting more jobs. Branch service times were about the same. The assistant was popular and people said it helped. The R15 million was nowhere to be found.

This pattern is not unique to Tsitsikamma. A recent Emerald Book commentary makes the same argument forcefully, using an illustrative copilot rollout to show how minutes per employee turn into an impressive figure that never reaches the bottom line. The commentary is polemical and some of its figures are unsourced, so we use it for the argument, not the numbers. The argument itself holds: time saved is not the same thing as value created.

Five links between minutes and money

Between a minute saved on a task and a change in the organisation's results there are five links. Every one of them can leak.

Minutes saved only become value if they survive four more linksCONVERSION LINKMinutes savedper taskSurvey estimates,not timed samplesTime actuallyfreedReview, rework,checking outputCapacityredeployedAbsorbed intomeetings, slackConstraintrelievedBottleneck issomewhere elseCost, revenue,service or riskNobody stoppeda cost
Each link loses some of the time saved at the first one. A business case built on minutes saved per task assumes every link holds. The leaks shown in the bottom row are the usual reasons they do not. Tsitsikamma Hardware Group's case is fictional and illustrative.

1. Minutes saved per task. Even the starting number is softer than it looks. Most business cases take it from user surveys or vendor estimates. Self-reported speed is unreliable. In METR's 2025 randomised study of experienced open-source developers, 16 developers working on 246 real tasks took 19% longer with AI tools allowed, while believing afterwards that the tools had sped them up by 20%. METR has since said those early-2025 results no longer reflect current tools, and its February 2026 follow-up points towards a speed-up, while warning that its newer data is weak evidence because of selection effects. The lesson is not that AI makes people slower. It is that people's sense of how much faster they are is a poor measuring instrument, in both directions.

2. Time actually freed. A draft produced in thirty seconds still has to be read, corrected and sometimes rewritten. For short, low-stakes emails the review is quick. For a quote with prices, delivery terms and product codes, it is not, because an error costs money. Tsitsikamma's trade staff found that the assistant drafted quote replies quickly but that checking prices against the system took as long as before, so the time freed per quote was much smaller than the drafting speed suggested.

3. Capacity redeployed. Suppose ten minutes a day really are freed. Ten minutes spread across a day in two- and three-minute fragments does not become a new task. It becomes a slightly less rushed day, a longer lunch or another meeting. That is not worthless, but it is not the R15 million in the business case. Freed time only becomes capacity when someone decides what it will be used for.

4. Constraint relieved. Even redeployed capacity only raises output if it is applied at the constraint, the step that limits how much work the whole process can complete. This is the link that business cases most often skip, and it deserves its own section.

5. Cost, revenue, service or risk changes. Finally, a change in output only becomes value when something on the income statement, the service record or the risk register moves. If the organisation keeps the same people, the same overtime and the same contractors, the cost line has not changed. That is the point made in When AI tooling is a substitution, and when it is just another cost: a saving exists when a cost stops.

The step that sets the pace

Tsitsikamma's trade desk is a good illustration of link 4. The assistant roughly doubled the number of quote replies the desk could draft in a day. Even taking that at face value, a trade order does not end with a quote. It goes through a stock check, then a credit approval for the builder's account, then delivery booking.

Faster quote replies, the same number of ordersTRADE QUOTE-TO-ORDER PROCESS, CAPACITY PER DAYAI ADDED HEREDraft quote reply60 → 120 a dayUNCHANGEDStock check70 a dayCONSTRAINTCredit approval40 a dayUNCHANGEDDelivery booking90 a dayTrade orders completed: about 40 a day before the assistant, about 40 a day after
Tsitsikamma's trade desk doubled the quote replies it can draft, but trade orders still pass through credit approval, which clears about 40 accounts a day. Output is set by the slowest step, so completed orders did not move. Figures are illustrative.

Credit approval clears about 40 accounts a day, because two people in the credit team check each application against bureau data and the account's payment history. Faster quotes simply mean a longer queue in front of the credit team. Completed orders stay at about 40 a day. The trade desk is busier sending quotes that wait.

This is not a failure of the AI. It is a failure to ask where the constraint was before choosing where to apply the AI. Had Tsitsikamma looked at the process first, it would have found that the biggest gain available was in credit approval: pre-assembling the bureau extract, payment history and account notes into one summary for the credit officer, who still decides. That is a narrower, less exciting use case than an assistant for everyone, and it is the one that would have moved orders. Part 2 of this series looks at why narrow, embedded use cases like that one tend to earn their keep.

Three ways time saved becomes value

There are only three honest routes from task speed to organisational value. A credible business case names which one it is relying on.

RouteWhat has to happenEvidence that it did
A cost stopsA vacancy is not refilled, overtime or contractor spend falls, or a planned hire is avoidedThe budget line that fell, and the decision that made it fall
Throughput rises at the constraintThe freed capacity is applied at the step that limits outputMore completed units (orders, claims, cases) at the same cost
Quality improvesFewer errors, returns, complaints or rework, because people have time to checkError or rework rates against a recorded baseline

Each route has an owner and a decision attached. Someone decides not to refill a post. Someone redesigns the process so that freed capacity reaches the constraint. Someone measures error rates before and after. If no decision is attached, the route is not real, and the business case is relying on hope.

There is a fourth outcome that is legitimate but should be called by its name: better working conditions. Staff who are less rushed, less bored and less likely to leave are worth something, and retention has a real cost. But that is a people case, not a productivity case, and it should be argued and measured as one.

Rewriting the business case

The fix is not to stop funding productivity tools. It is to replace the minutes-times-headcount calculation with a conversion statement for each material use. Tsitsikamma now asks every AI business case above a modest threshold to answer five questions:

  1. Which task, and how was the time saving measured? Not a survey of how people feel, but a timed sample of the task with and without the tool, including review time.
  2. Where does the freed time go? Name the work it will be redeployed to, or the cost that will stop.
  3. Is that work at the constraint? Show the process and the step that currently limits output.
  4. Which line moves, and by when? A budget line, a throughput figure, an error rate or a service measure, with a date.
  5. Who owns the conversion? A named manager who will make the redeployment or cost decision, not only the person who owns the tool.

A case that cannot answer questions 2 to 5 may still be worth funding as a cost of doing business, like email or spreadsheets. AI consumption is not AI value explains when that is a reasonable choice. The difference is that it is funded and reported honestly, not as a R15 million productivity gain that nobody can find.

What to do with the case you already approved

Most organisations already have a productivity rollout running on the fifteen-minute arithmetic. Three steps make it honest without turning it into a crisis.

Re-measure one task properly. Pick the highest-volume task the assistant is used for and time a sample of it, with review, against the same task without the tool. That gives a defensible link 1 figure instead of a survey estimate.

Map one process end to end. Choose a process where the assistant is heavily used and find the constraint. If the AI is being applied upstream of a bottleneck, as at Tsitsikamma's trade desk, decide whether to move the effort to the constraint.

Reclassify the remainder. For uses that cannot show a conversion route, record them as a cost of doing business, managed for licence utilisation and security, and remove the productivity figure from the benefits report. The benefits ledger described in The Boardroom AI Test series is the right place to record that decision.

None of this says AI assistants are a mistake. Many people genuinely work better with them. It says that the value of a tool used by a thousand people is decided by what the organisation does with the time, not by the tool. That is a management question, and it was always going to be.

Next: Part 2, Narrow, embedded and boring: where enterprise AI earns its keep. All parts are on the series page.

How CloudNala can help

We review AI productivity business cases and the rollouts already running on them. We re-measure the highest-volume tasks, map the processes where the tools are used to find the real constraint, and rewrite each case as a conversion statement with a named route, a named owner and a measurable line. Where a use cannot show a route to value, we help you reclassify it honestly rather than defend a figure nobody can find.


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