The failure mode nobody puts in a risk register
Ask a operations leader about risk and they will describe a fire, a fraud, a regulatory breach. Almost nobody will describe a rate of handing errors. Yet in most operating businesses, the recurring losses are not dramatic events; they are a steady accumulation of small, individually defensible mistakes: the wrong quantity, the missed attribute on an invoice, the order confirmed verbally and never written down, the deadline that moved without anyone agreeing it moved.
Each of these is individually small. Some of them would be found before they cost anything. The problem is not their size; it is their number, and the fact that no single person owns their total.
Why the aggregate stays invisible
Small operational errors scatter across the cost structure in a way that makes them nearly impossible to see. A wrong shipment becomes a compensation payment. A mis-keyed price becomes a margin reduction somewhere else in the ledger. A late confirmation becomes a stock-out that a planner absorbs by re-ordering. A missed instruction becomes an escalation, and an escalation becomes a manager's time.
Because each consequence lands in a different account and a different budget, no single report contains them. The operations team sees volume, the finance team sees margin, the commercial team sees customer sentiment, and the aggregate error cost appears in none of them. It has to be constructed deliberately, which is why it is usually not.
Building the estimate without a data programme
A first estimate does not require a data engineering project. It requires three numbers from three places, and a small number of assumptions that are stated rather than hidden.
- The rate. Pick one process and count the proportion of transactions that are touched after they are first recorded. A correction, a re-processing, a follow-up question, a credit. This is countable from the system of record for most processes, and countable from a two-week sample for the rest.
- The unit cost. What does one correction actually consume? The approximate minutes of the person correcting it, the handling and administrative cost, and any downstream cost that follows from the correction. Most organisations can produce a defensible range for this within an hour of discussion.
- The rate of consequence. Of the errors that occur, what proportion become visible to the other party, and what proportion of those become a compensated event? This ratio is the multiplier that turns a handling cost into a loss, and it is the number most often omitted from the estimate.
Multiplied together, these give an order of magnitude. It is not a precise figure and it should not be presented as one, but it is derived from the business rather than from a benchmark, and it is enough to decide whether the order of error is worth addressing. The discipline of keeping that distinction clear is the subject of calculating the value of enterprise AI.
Illustrative: what a small rate can be worth
Consider a hypothetical distributor of temperature-sensitive materials handling a thousand order lines a month through a mix of messaging applications, spreadsheets and an order system. Assume, purely for illustration, that the observed correction rate is four percent, that each correction consumes forty minutes across handling and re-entry, and that one corrected order in twenty results in a compensated shipment.
On those assumptions, the handling cost is straightforward, and it is the smaller of the two figures. The consequential cost comes from the multiplier: a small number of lines a month, each of them spoiling or being paid for, against the value of the material. The general lesson is not about this industry — it is that the multiplication of a low rate by a high consequence is exactly what makes error programmes economics rather than hygiene, and exactly what makes it invisible when the consequence is spread across dozens of small events a year instead of a few large ones.
Where the fix usually lies
Having established that the aggregate matters, the next question is where in the chain the errors are introduced. The answer is rarely distributed evenly, and it is rarely where the business expects.
- At capture, where a required attribute has no defined home and is reconstructed later from context, memory or a forwarded message.
- At handoff, where one party's output is another party's input and the transformation between them is informal.
- At definition, where two parts of the business use the same term for different things, so both are correct and the record is wrong.
- At exception, where the routine path is well handled and the unusual case is handled by whoever happens to notice it.
Each of these is a different kind of work, and each has a different owner. The last one is the most common and the least addressed: exceptions are where operational losses concentrate, and they are usually handled by the most experienced people, which is why the organisation rarely sees them. The mechanisms for making exceptions visible and accountable are covered in designing AI workflows with approval and exception handling, and the semantic work that often has to precede it in business ontology explained.
The programme this justifies
Small errors are rarely fixed by a single intervention. They are addressed by a standing capability: definitions that are owned rather than inherited, checks that run when the record is written rather than when someone remembers, exceptions that surface automatically and reach a named owner, and a review that looks at the rate rather than at the individual incidents. The difference between that capability and a sequence of one-off corrections is that the rate falls and stays down, which is what turns a tolerated annoyance into a measurable operating result.
The programme is worth funding precisely because the alternative is not zero. It is the current rate, compounding across every transaction, for ever, funded implicitly by the people closest to the work.