Picture a mid-size distributor whose order-handling system saves $42,000 a month in its second month. Finance puts that figure on a slide, multiplies it by twelve, and the board approves year two on the strength of it. In month eleven the same metric is re-measured, the same way. The system is now saving $27,000 a month. The budget still assumes $42,000.
Nothing has broken. The system is running, the users are logging in, and the dashboards are green. The business case has simply been written as if value were a fixed asset, when in practice it behaves more like a perishable one. In my work I now ask for one thing before any AI budget is approved: an expected half-life.
The number on the slide in month two
Month two is the most flattering moment to measure an AI system. The easiest work has been automated, the team is paying attention, and the process around the tool is still fresh. That figure is real. The error is in treating it as a run rate that will repeat for twelve months, and then for another twelve.
When a board approves year two on a launch number, it is approving a forecast nobody made. No one wrote down how fast the benefit would fade, so the implicit assumption is that it will not fade at all. That assumption rarely survives contact with a real operation.
The example in this post is a composite. It is illustrative and is not drawn from a single client, but the shape of it is one I see repeatedly.
What a flat number hides
Take the composite distributor. The build cost $120,000. Running it costs $9,000 a month, or $27,000 a quarter. In month two the gross monthly benefit measured $42,000.
The static case is simple arithmetic. Twelve months of $42,000 is $504,000 gross. Subtract $108,000 of run cost and $120,000 of build cost and year one nets $276,000. The case then assumes that figure repeats.
Now the re-measurements, taken with the same method each time:
- Month 5: $36,000 a month
- Month 8: $31,000 a month
- Month 11: $27,000 a month
That is roughly 86% of the benefit retained each quarter, about 4.8% lost each month. It implies a half-life of around 14 months. Apply that curve and year-one gross benefit is about $408,000, not $504,000. Net of the same costs, year one is about $180,000, roughly 35% below the static case.
The year-one gap is uncomfortable, but it is not the most important finding. The curve also tells you when the system stops paying its way. Gross benefit reaches 1.5 times the run cost, $13,500 a month, around month 25. It falls below the run cost itself, $9,000 a month, around month 33. The static case never showed either date, because a flat line never crosses anything.
That second date is the one a CFO or COO can plan around. It turns a vague worry about "whether this will keep working" into a calendar entry with a budget attached.
Four reasons value fades that are not the model
When I ask a leadership team why the benefit fell, the first answer is usually that the technology must have gotten worse. Occasionally a model or prompt change plays a part. Far more often the causes are on the business side. In the composite distributor there are four, and they are the four I see most often.
- The easy work ran out. The system took the simple order types first. Once those were automated, there was less of that work left to save.
- The mix shifted. The orders arriving became more complex, and complex orders save less per order than simple ones.
- People routed around the tool. Two teams began handling rush orders by hand because it felt faster under pressure. Usage fell without anyone deciding it should.
- A price moved. A supplier price change reduced the saving on each order. In this region, currency and import-price shifts can do the same thing to a business case within a single quarter.
None of these is a failure of the system. All of them are ordinary movements in a living business, and all of them reduce what the case is worth. A case that cannot absorb them was never really a forecast.
How to put a half-life in the case
The fix is not complicated. It is a discipline of four steps, written into the document the board approves.
- State the half-life up front. Write an expected decay rate and the break-even date into the case itself. A rough estimate is enough. A visible assumption can be corrected, while a hidden one cannot.
- Fix the cadence. Re-measure the same metric, by the same method, every quarter. Keep the launch baseline on the page beside each new reading so the curve is always visible.
- Decompose any drop before acting. Split the change into volume mix, usage, price and quality. Each points to a different response, and treating them all as a technology problem wastes money.
- Pre-commit the decision. Agree now what happens when gross benefit crosses 1.5 times run cost: refresh the system, reinvest in a new use, or retire it. Deciding in advance removes the pressure of deciding late.
The 1.5 times threshold matters because it leaves room. Refreshing or replacing a system takes months. If you wait until the benefit equals the run cost, you have already been paying for a system that returns nothing for a while. In the composite, 1.5 times arrives around month 25, which leaves roughly eight months to act before the benefit falls below the run cost.
What to ask your team this quarter
If you are six to eighteen months into a first deployment and a year-two budget is on the table, these are the questions I would put to the team before approving it.
- What did this system save in its second month, and what does it save now, measured the same way?
- What decay rate does the current budget assume? If the answer is none, what is a defensible one?
- On what date does gross benefit fall below our monthly run cost at that rate?
- When benefit drops, which of the four causes is responsible: mix, usage, price or quality?
- What did we agree we would do at 1.5 times run cost, and who owns that decision?
If your team cannot answer the first question, begin there. A single honest re-measurement this quarter is worth more than a polished forecast built on a number that is nine months old.
An AI system is not a failure because its value fades. Almost every operational improvement fades, because the business around it keeps moving. It becomes a failure when nobody wrote down how fast, and nobody chose a date to decide what comes next. Put the half-life in the case, and the retire-or-refresh date stops being a surprise and becomes a plan.
