Suppose a task previously took six hours and an AI-assisted version takes one. Multiply the five hours saved by the number of employees, the frequency of the task and a wage rate, then compare the result with the implementation cost. The calculation looks like an investment case, but it leaves several important questions unanswered. When can the organisation actually change the workflow? How will the recovered capacity become financial value? Will the chosen technology remain available through the payback period?
These questions run on three different schedules. The capability clock describes how quickly models and tools improve, change price or disappear. The operating clock describes how quickly the enterprise can integrate systems, validate output, redesign roles and handle exceptions. The economic clock describes when those changes produce lower cost, additional revenue, better asset utilisation or another measurable financial outcome.
The schedules interact, but they do not automatically align. A defensible business case needs to show how a technical improvement passes through operating change into an economic result, with the dependencies, cost and accountabilities stated at each stage.
Clock one: capability moves first
Model performance can improve sharply between procurement cycles. Costs can fall. New modalities appear. A provider can deprecate a model before the enterprise has finished standardising the last one. This creates a strange investment problem. The technical component with the shortest useful life may sit inside a programme whose approval, integration and adoption take years.
A pilot can therefore prove that a capability exists without proving that the chosen component will still be the right—or available—component when the workflow reaches scale. The obvious response is to preserve flexibility. But flexibility is not free. Multi-model routing, abstraction, evaluation suites, observability and replacement testing are additional operating assets. They belong in the cost of the solution rather than being treated as optional technical hygiene.
The capability clock also creates recurrent cost. The model that made the original business case work may need to be replaced, re-evaluated or repriced before the investment has paid back.
Clock two: the enterprise absorbs change slowly
Demonstrating a capability is the starting point for operating change. It does not establish how quickly the enterprise can make that capability part of its normal work. The enterprise must connect data, permissions and systems; define exceptions; decide who approves output; create monitoring; redesign roles; train users; change policy; and determine what happens when the model is unavailable or wrong.
In consequential workflows, it must also establish provenance, independent review, testing and evidence. This work determines whether the technical capability can become a reliable operating process. Its cost and timing belong in the original investment case.
The operating clock is constrained by dependencies the model does not remove:
- Sales cannot book revenue from a proposal the delivery organisation cannot fulfil.
- Finance cannot close faster if upstream data remains unreconciled.
- A bank cannot remove review simply because a memo was generated faster.
- A healthcare workflow cannot transfer clinical responsibility to a language model.
- Engineering cannot apply one productivity gain across code with radically different integrity requirements.
As generation becomes faster, integration, acceptance and organisational change can account for a larger share of the elapsed time. Improving the model further may have little effect on those constraints.
Clock three: saved time is not yet economic value
Recovering time creates capacity. Management still needs to decide how that capacity will be converted into a measurable outcome and who is accountable for making the conversion happen. A worker who saves five hours does not hand five hours of cash back to the company. The capacity is fragmented across people and weeks. It may be consumed by more work, waiting, meetings or quality improvements. Some of those are valuable; none should be labelled cost reduction without a mechanism.
There are only a few ways recovered capacity becomes financial value:
Cost removed. Roles, contractors, overtime or future hiring are actually reduced.
Throughput increased. The same resources process more demand and demand exists to absorb it.
Revenue improved. Faster response, better conversion, greater retention or a new product changes cash inflow.
Risk or loss reduced. Fewer errors, claims, write-offs or control failures produce a measurable avoided cost.
Capital efficiency improved. Assets, inventory or working capital turn faster.
Everything else may still be worthwhile, but it is not the cash return commonly presented to an investment committee. The conversion mechanism must identify an owner. “Employees will use the time for higher-value work” is not a mechanism. Which work? What constraint prevented it before? How will the capacity be aggregated? Which metric will show that it occurred?
Replacement, verification and accounting do not need to be rediscovered here. The arguments are developed in The Model Will Be Gone Before the Product Is, The Verification Shadow and Two Numbers You Will Be Asked For. For this business case, the important move is simpler: put those obligations on the original schedule rather than treating them as technical housekeeping after approval.
If replacement requires regression testing, policy review, prompt changes, revalidation or user retraining, it is part of the economic clock. If generated work is capitalised or later challenged, provenance and useful-life rationale are part of the finance schedule. These are recurring operating characteristics of a system whose probabilistic component and supplier ecosystem continue to change.
Build the business case as three linked schedules
A more defensible investment case has three explicit schedules.
1. Capability schedule
- Expected model and vendor lifecycle
- Pricing sensitivity
- Replacement triggers
- Evaluation and portability assets required
- Expected refresh or migration cost
2. Operating schedule
- Integration and data readiness
- Verification and acceptance design
- Exception rates and fallback process
- Role and policy changes
- Time to scale by workflow population
- Replacement and revalidation procedure
3. Economic schedule
- Gross time or quality improvement
- Net accepted-output improvement
- Specific conversion mechanism
- Owner of the conversion
- Cash, revenue, risk or capital metric
- Recognition timing and useful-life assumption
The schedules should connect. A capability change should show where it creates operating work. Operating adoption should show when and how it produces economic realization. The financial model should include a revalidation or replacement event if one is likely inside the payback period.
An illustrative credit-memo workflow shows the difference.
| Schedule | What changes | Business-case entry |
|---|---|---|
| Capability | The memo generator reduces first-draft work from 6.0 analyst hours to 1.2, but the model provider releases a major version twice a year. | Book the accepted-output gain from CAC-005, not the draft-time gain. Add semiannual evaluation and prompt-regression work. |
| Operating | Review rises from 2.0 hours to 3.4 hours, exceptions rise from 8 percent to 18 percent, and credit policy needs deterministic checks outside the model. | Fund reviewer capacity, exception handling and control automation before declaring capacity recovered. |
| Economic | Expected total effort falls from about 8.24 hours to 5.26 hours per memo. A 2,000-memo portfolio recovers about 5,960 hours before conversion costs. | Count cash value only where underwriting capacity, contractor spend, overtime or cycle-time revenue changes. Otherwise classify the benefit as capacity or quality. |
The example is deliberately stylized. Its purpose is to keep the three clocks connected: model improvement, operating absorption and financial conversion each need their own owner and date.
Four questions for the investment committee
What exactly is being counted? Generated output, accepted output, capacity recovered or value realized are different measures.
Who converts the capacity? The owner should be able to state which budget, headcount plan, throughput target or revenue metric changes.
What happens when the component changes? The business case should contain the cost and elapsed time of replacement, not simply a statement that the architecture is model-agnostic.
Which useful life is being assumed? The answer should reflect the actual refresh and support strategy for the software population, not an inherited convention.
A model can improve within a quarter while the surrounding workflow takes two years to redesign. The cost saving may then depend on a later change to the hiring plan, and the original model may require replacement before that change occurs. Combining those events into one assumed adoption curve hides both the timing risk and the work required to realise the return.
The investment committee should require separate technology, operating and economic schedules, linked by explicit dependencies and named accountabilities. That gives it a basis for deciding whether the opportunity is worth funding and for checking whether the promised value is actually being realised.