Leakage never reaches the profit and loss account
A general manager can tell you their unit's revenue, their headcount and their cost of goods. Ask what the business lost last month through rework, late decisions, or opportunities that expired while somebody was waiting for a signature, and you will get a range, an opinion, or silence. Those losses are made of many small events, each too minor to appear in a report and each landing in a different cost line.
The consequence for a chief executive is specific. Without a figure for leakage, every proposal to change how work gets done is judged on intent rather than evidence, and the organisation funds the projects that are most visible rather than those that recover the most. The first job is to make a category of loss visible that reporting was never built to show.
Five kinds of leakage, each owned by somebody different
Asked where value is lost, an operating team produces five patterns, worth separating because owner, measurement and intervention differ.
- Rework leakage. Work performed twice because a record was incomplete, a specification was wrong, or a handover was verbal. The only visible trace is the corrected version that reached the system.
- Delay leakage. The interval between a fact becoming available and somebody acting on it. It never appears as a cost, so it survives scrutiny.
- Missed-opportunity leakage. Work that could have been done on Tuesday and was done on Friday, or not at all.
- Coordination leakage. The hours spent by competent people finding out who should decide something, and then finding the answer.
- Visibility leakage. Decisions taken on partial information because the decider could not see the state of the operation. A decision on stale data looks like one taken well.
Reconstruct a single transaction before asking for a report
The fastest route to a defensible number is not a reporting request. It is a forensic reconstruction of one recent transaction, then a second, then a third. Chief executives who do this are usually surprised by the same thing: the transaction looks long, and every step in it is defensible.
- Choose a transaction that went wrong or late, not one that went well. A normal case hides the friction, because normal cases are what the process was designed for.
- Record every event with a timestamp: when the customer asked, when somebody acknowledged, when the decision was taken, when the commitment was met. Ask for timestamps rather than opinions, which are already smoothed.
- Mark each interval that added no value: waiting for a reply, an approval, a second person to check something a system could have checked. These are the leakage points, and there are few.
- Ask who owned each waiting interval. If the answer is that it was simply how the work happened, you have found a structural cost and an absent owner at once.
Friction measures cost more honestly than error counts
Most leakage programmes begin by counting errors, and errors are a poor proxy: they are rare and ambiguous to attribute. Waiting time is countable and attributable to an organisational arrangement.
Baselines worth recording before anything changes
| Measure | How it is counted | What it usually reveals |
|---|---|---|
| Rework hours per 100 transactions | Sampled corrected records, times minutes spent | Whether volume or definition is the constraint |
| Elapsed time per decision | Event timestamps from trigger to commitment | Which handoffs carry the delay |
Where AI is the wrong instrument
Leakage is usually an organisational condition, and organisational conditions are not repaired by adding a system. If specifications are ambiguous, an assistant that drafts more quickly drafts more ambiguity. If ownership of a step is unassigned, a notification arrives where nobody owns it.
Artificial intelligence earns its place in the narrow, high-volume parts: reading unstructured input such as email, chat and scanned forms and turning it into a record, detecting anomalies in an ordinary flow, and drafting a proposed reconciliation for a person to approve. The judgement of whether a customer should wait, or which of two contradictory records is authoritative, stays with a named owner. That boundary defines a controlled rollout, and the engineering behind it is in how Origin engineers enterprise systems.
What the first ninety days should produce
A leakage review is worth running once, in a defined scope with a defined output, rather than continuously.
- Name one executive who owns the result of the review, usually the chief operating officer or a business unit head.
- Select three transactions from a single process under cost pressure, and reconstruct them with an analyst and a finance partner.
- Record each waiting interval and its absent owner on a page.
- Agree the two measures to be tracked monthly, and their baselines, before any system is built.
- Decide which category deserves funding and which is only watched.
- State in writing what would end the work.
The number the chief executive should ask for
At the end of this work, a chief executive should be able to ask a general manager for one figure: the annual cost of leakage in that unit, expressed in hours and in the consequential costs the business actually recognises, with the assumptions listed. Not a percentage improvement, and not a forecast. A defensible number, with its construction visible.
You cannot manage what you have never made visible, and the costliest losses arrive as many small absences rather than one large event.
That number changes the character of the conversation. A request for funding becomes a request for a stated return against a stated baseline, and a proposal to automate a process becomes one option among several for reducing a cost now on the table. The interview technique behind this is in the executive interview questions that reveal hidden AI opportunities, and the arithmetic in the business case for fixing small operational errors.