Every team we talk to agrees that bad data costs them something. Almost none of them can say how much. That gap bothered us enough that last autumn we asked a client, a 14-person customer support team at a subscription box company, if we could shadow them for a month and count.
The ask was simple: every time someone had to stop what they were doing because a customer record was wrong, missing, or duplicated, they logged it in a shared sheet with the time it took to sort out. No categorization theory, no tagging system. Just a timestamp and a rough minute count, written down as it happened.
What we counted
Over 19 working days, the team logged 214 incidents. The most common by far was a duplicate customer record, usually created when someone checked out as a guest and then later made an account with a slightly different email. Support agents would find themselves looking at two order histories for the same person, unsure which one reflected reality.
| Issue type | Incidents | Avg. time per incident | Total hours |
|---|---|---|---|
| Duplicate customer record | 86 | 9 min | 12.9 |
| Missing or wrong shipping address | 51 | 6 min | 5.1 |
| Subscription status out of sync with billing | 43 | 14 min | 10.0 |
| Order history missing items | 34 | 8 min | 4.5 |
Add it up and the team spent just under 33 hours over four weeks on problems that had nothing to do with the customer's actual question. At a loaded cost of roughly 22 euros an hour for a support role in that market, that is around 720 euros a month, or a bit under 8,700 euros a year, for one team of 14 people. Scale that across a larger support org and the number stops being a rounding error.
We want to be direct about what this number is not. It does not include the cost of customers who got frustrated and did not stick around, which is harder to isolate and easy to overstate. It also does not include engineering time to fix the underlying causes. It is a floor, not a ceiling, and we think that is exactly why it is useful. Nobody can argue you inflated it.
The team lead told us afterward that the exercise changed how she pitched the fix to her own manager. "I stopped saying it feels slow," she said, "and started saying it costs 720 euros a month, here is the log."
Where the duplicates were coming from
Once we had the numbers, the fix was almost anticlimactic. The checkout flow created a new customer record on every guest checkout, keyed only on order ID, with no matching against existing accounts by email. A two-day engineering fix to check for an existing email before creating a new record cut duplicate creation by an estimated 70 percent within the first month after release, based on a follow-up count the support lead ran on her own.
This is the pattern we see most often: the data quality problem is not mysterious once someone bothers to trace it back, but nobody bothers because it is nobody's job in particular. Support blames the checkout flow. Engineering has a backlog full of feature requests and no ticket that says "duplicate records cost 720 euros a month." The audit is what turns a vague complaint into a ticket with a number attached.
How to run this yourself
- Pick one team, not the whole company. A support team, an ops team, or a sales team that touches customer records daily all work well.
- Ask them to log incidents in a shared sheet for two to four weeks: what happened, how long it took, nothing more.
- Resist the urge to build a fancy tagging taxonomy before you start. You can categorize after the fact once you see what actually shows up.
- Multiply total hours by a loaded hourly cost for that role. Your finance team can usually give you this number in five minutes.
- Bring the total to whoever owns the backlog, along with the three most common issue types. Specific and small beats comprehensive and abstract.
What surprised us
Going in, we expected missing shipping addresses to dominate the list, since that is the complaint we hear most often anecdotally. It came in second. Duplicate records won, and we suspect that is true at a lot of companies that grew their checkout flow quickly and never revisited the customer matching logic. If you run this audit and get a different answer, we would like to hear about it. We have changed our assumptions once already based on a reader's numbers, and we are open to doing it again.
- How do you measure the cost of bad data?
- Track how much time staff spend working around incorrect or missing records over a fixed period, such as two to four weeks, then multiply the hours by a loaded hourly cost. This gives a defensible, if conservative, estimate that does not require guessing at downstream revenue impact.
- What counts as a data quality problem versus a process problem?
- If the same field is wrong or missing across many records in a predictable way, it is usually a data quality problem rooted in how data enters the system. If one person repeatedly makes a different kind of mistake, it is more often a process or training problem.