A Metric Was Wrong Because of Bad Data Entry: Decision Tree

Why this matters

A number on a dashboard is only as good as what got typed into the system that feeds it. The first time a manager catches a report saying something that is obviously false, the natural reaction is to distrust the whole dashboard and stop looking at it. That is the wrong lesson. Most bad numbers trace to one bad habit at the point of entry, not a broken tool. Fix the habit at the source and the number self-corrects; keep blaming the dashboard and you lose the only early-warning system the shop has.

Start here: confirm it is actually wrong before you go hunting

Before assuming an error, rule out the simpler explanation that the number is correct and just surprising. Pull the underlying records behind the metric, not just the summary tile. If a completion rate looks impossibly low, look at the actual list of jobs it counted. Sometimes a real event (a bad week, a system outage, a new employee) produced a real number that only looks wrong because it is unusual.

If the underlying records match the number, the metric is telling the truth and this is not a data-entry problem, it is an operations problem. Stop here and go address the real cause.

If the underlying records contradict the number, move to the next step. Something in how the data got entered or counted is broken.

Step 1: Find where the count and reality diverge

Compare the metric's definition against what actually happened, one record at a time if you have to. The divergence usually shows up in one of a few places:

• A status field never got updated. A job is done in the field but still marked "in progress" in the system, so it is missing from completed-work counts and still showing as open.
• A record was entered against the wrong category, customer, or date. A job logged under the wrong service type throws off every metric sliced by service type, even though the job itself is counted correctly overall.
• A duplicate entry. The same job, invoice, or lead got entered twice, usually because two people touched it or a sync ran twice, and it is now double-counted.
• A blank or default value got left in. A field that should have a real answer was left at its default (zero, "unassigned," today's date) because nobody was forced to fill it in, and the report is quietly averaging in a placeholder as if it were real data.

Identify which of these it is before you touch anything. Fixing the wrong record type wastes time and can introduce a second error.

Step 2: Trace it to a person, a process step, or a system gap

Once you know what kind of error it is, find out why it happened.

• If one person's records are consistently off and nobody else's are, this is a training gap, not a system problem. They likely do not understand what the field means or do not see why it matters. A quick one-on-one walkthrough of the correct entry, with the "here's what this feeds" explanation, usually fixes it for good.
• If the error shows up across multiple people the same way, the field or workflow itself is confusing or too easy to skip. That is not a people problem, it is a form or process problem. Reorder the workflow so the field cannot be skipped, or rename it so its purpose is obvious.
• If the error only happens under time pressure (end of a long day, rushing to close out before a break), the entry step is competing with something more urgent in the technician's head. Move the entry point closer to the moment of work, or make it faster, rather than asking people to remember it for later.
• If it traces to a system sync or import, rather than a human typing something, the fix belongs with whoever maintains that integration, not with retraining a technician who did nothing wrong.

Step 3: Fix the specific bad records, then fix the source

Correct the records you found first so today's number is right. Then, separately, address the cause so tomorrow's number does not repeat the same mistake. Skipping the second half is the single most common failure in this process: the number gets manually patched once, looks fine for a week, and drifts wrong again because nothing about how it gets entered actually changed.

• Update the wrong status, category, or duplicate, and note in the record why it was corrected.
• Close the loop with whoever entered it, focused on the fix, not blame. The goal is a system where the correct entry is also the easiest one.
• Where possible, make the field required, add a validation check, or change the default so the same mistake cannot happen silently again.

Step 4: Decide whether you can trust the number again immediately or need to watch it

If it was an isolated mistake (one person, one bad day, now corrected and understood), you can trust the metric again once the fix is confirmed.

If the same error pattern has shown up more than once, treat the metric as suspect until you have seen it hold accurate for a full reporting cycle after the fix. Note this in whatever review meeting looks at the number, so nobody makes a decision off a figure you are still validating.

The recap

Confirm the number is actually wrong before hunting. Find exactly where the divergence sits, whether it is a status, category, duplicate, or blank field. Trace it to a person, a process, or a system, because each gets a different fix. Correct today's records and fix tomorrow's cause, not just one or the other. Do not let one bad number make you abandon the whole dashboard. Fix the leak, do not tear out the pipe.

References

• U.S. Small Business Administration (SBA), small business record-keeping and data quality practices
• Trade-standard practice for field-service data entry and reporting workflows
• See related: The Dashboard Numbers That Matter; A New Metric Is Worth Adding to the Dashboard or Not