What a Loss Rate Drop From 50% to 5% Really Teaches You
Cutting a loss rate from 50% to 5% only means something if you measured it correctly before and after. Here's how to do that.
The Number Nobody Actually Measured
A manufacturing manager tells you scrap has "always been around half." An operations lead says order errors are "pretty bad but manageable." A finance controller shrugs at stock discrepancies because "that's just how retail is." In every case, there's a number everyone agrees is bad, and nobody has actually measured.
This is the starting point for most automation projects in small and mid-sized companies: a rough sense that a process leaks value, without a baseline that says how much, measured how, over what period. So when a new system goes in — a scheduling tool, a reconciliation script, a CRM that replaces a spreadsheet — the team feels things have improved, but nobody can say by how much, because there was nothing solid to compare against.
The story of a loss rate falling from roughly half to roughly a twentieth is striking precisely because it implies a number was tracked with enough rigor, before and after, to make that comparison credible. That rigor is the actual lesson. Not the percentage. The method that produced it.
Most PMEs skip this step. They automate first, feel better second, and try to justify the spend after the fact with anecdotes. That order is backwards, and it's why so many automation projects get quietly abandoned at renewal time — not because they didn't work, but because nobody can prove they did.
Why a Vague Baseline Kills a Good Project
When the "before" state isn't measured properly, three things go wrong later.
First, you can't tell if the automation is the actual cause of any improvement. Sales might be up because of a new CRM — or because a competitor closed, or because a new rep joined the team the same month. Without a clean baseline and a defined measurement window, every result is guesswork dressed up as proof.
Second, you can't catch a partial failure. An automation that fixes 60% of the problem looks like a win if you only have a vague "it feels better" comparison. It looks like unfinished work if you had a real number to aim at. The second view is the one that gets you to actually finish the job.
Third, you lose the argument internally. A manager who wants budget for phase two of an automation needs a chart, not an impression. "We think it's better" doesn't survive a budget review. "We went from 42 errors a week to 4" does.
The fix isn't complicated. It's just rarely done with discipline, because measuring the problem feels like a delay when everyone wants to jump straight to the fix.
How to Measure the Real Gain Before and After Automating
- Pick one metric that represents the loss directly — scrap units, re-entry hours, order errors, late invoices — not a proxy, and define exactly how it's counted (per week, per order, per unit produced).
- Capture the baseline over several normal cycles, not one unusual week. A single bad or exceptionally good week will distort the comparison in either direction.
- Write down the exact scope of what the automation touches, and what it doesn't. If it only covers order entry and not shipping errors, don't credit it with shipping improvements.
- Keep the measurement method identical after deployment — same counting rules, same time window, same people reporting it — so the comparison isn't comparing two different things by accident.
- Note anything else that changed at the same time: new staff, a new supplier, a seasonal shift. If something else moved, say so, rather than attributing all the gain to the automation.
This is slower than just deploying and hoping. It's also the only way to know, three months later, whether the project paid for itself or whether it needs adjusting.
What Proof Looks Like
Once the system is live, the number to watch isn't a single snapshot — it's the trend over the same cycle length you used for the baseline. A real gain holds up over several consecutive periods, not just the first one. If the metric improves once and then drifts back toward the old level, the automation hasn't fixed the underlying process; it's masked it temporarily. A gain worth reporting is one that stays stable once the novelty wears off and the team stops paying extra attention to the new tool.
Measure Your Process Before You Automate It
ArkonLabs builds custom business software and measured automations designed around a baseline you can actually verify, not a promise you have to take on faith. If a process in your business is leaking time or money and you want a number before and after, get in touch through www.arkon-labs.com.