Business
Operational errors aren't down to people not paying attention
· 4 min read ·
There was a mistake in an order. You investigate, trace it back to the person who typed the wrong quantity, have a word with them, ask for more care. Everyone leaves the conversation feeling the matter is closed.
Three months later it happens again, with someone else. And at that point it isn't inattention: it's a spot in the operation where it's easy to get it wrong, and nobody has fixed it.
Errors live in the handovers
If you track where mistakes happen, you'll almost always find them in the same kind of place: the moment information changes hands or systems.
Someone reads a number off one screen and types it into another. Someone forwards an email and the attachment gets left behind. Someone marks a task as finished without the document they should have attached, because nothing stopped them.
The work itself — understanding the request, deciding the price, delivering it — is rarely where the mistake happens. It happens in the transcription, the part nobody considers real work, and which, for that very reason, gets done with half the attention.
Three ways to make the error hard to make
In order of effectiveness, and none of them takes a big project.
Take transcription out of the loop. If the data already exists in one system, the other one should fetch it instead of someone copying it across — that's integration work, and it's worth reading first about what goes wrong when you connect systems without deciding who's in charge. It's the only method that removes the whole category of error instead of just reducing it.
Swap free text for choices. A field where you can type anything accepts "Ltd.", "Limited", "ltd" and an extra space. A list with five options accepts five things. Almost all data inconsistency comes from free-text fields that never needed to be free text.
Don't let it move on without the essentials. If a process can't close without the proof document, the system has to enforce that — it isn't enough for it to be written in the procedure. Use this sparingly: a form with twelve mandatory fields ends up filled in with "xxx".
The error that gets fixed and the error that spreads
There's one distinction that changes everything's priority: does the error stay where it was born, or does it travel?
A mistake in a field that only exists in one place gets fixed in thirty seconds as soon as someone spots it. A mistake in a piece of data that's copied to three other platforms now exists in four places, and fixing it in one doesn't fix it in the others — the next day a sync brings the old value straight back and the correction vanishes without explanation.
So when you have to choose where to invest, start with the data that circulates — and with the quality of what's already there, as we've covered in why data rots on its own. That's what multiplies mistakes, and it's also what wastes the most time for whoever's trying to work out what happened.
Count before you fight
A note on method, because it's easy to spend money in the wrong place. Before changing anything, spend a month logging mistakes: what happened, at which step, and how long it took to fix.
A spreadsheet with thirty rows is enough to see the pattern, and the pattern is usually far more concentrated than you'd expect: two or three points in the operation account for most of it. That's where you act.
The rest — the one-off mistakes that happen once and never again — leave them alone. Armour-plating the operation against everything costs more than the errors it prevents.
Is there an error that keeps repeating in your operation?
Tell us what it is and at which step it happens. We'll see if it can be made impossible instead of just kept corrected.