A convincing dashboard can answer the wrong question
Imagine a fictional service company whose CRM reports 42 open requests. One team closes a request when it sends a reply. Another closes it only after the customer confirms the issue is resolved. The dashboard faithfully counts the stored statuses, yet its total cannot reliably tell a manager how much work remains. A technical check that finds no empty fields would miss the central problem. The teams disagree about what “open” means. A number can be correctly calculated from its inputs while being unfit for the decision it is supposed to support.
Quality is therefore relative to use. An address list could be adequate for postal delivery even when it lacks phone numbers. The same list could fail a callback process. The UK Government Data Quality Framework describes dimensions such as completeness, validity, accuracy, uniqueness, consistency and timeliness. They offer useful lenses for examining a dataset. None gives a universal score that settles every practical question. State who uses the information, for which purpose and with what possible consequence before setting a threshold.
Define the unit before counting it
Write one plain sentence explaining a critical measure. Specify which records count, which do not, which system supplies them and when the measurement occurs. In the fictional company, an “open request” might mean an incoming request without a documented answer or a justified closure at the end of the working day. This definition does not force consistent behavior by itself. It gives people a rule against which to examine entries and compare results. A frequently updated KPI is not automatically a trustworthy one.
Separate a missing value from an incorrect or outdated value. An empty delivery address is visible. A well formatted old address can pass a validation rule and still send a parcel to the wrong place. A valid date format does not establish that the event happened on that date. Two reports can agree because both inherited the same mistake from an earlier step. Trace selected entries back to the original event or document. Comparing two derived screens alone may only show that a shared error has spread consistently.
Build a check you can repeat next month
Choose one pending decision and list the fields that influence it. Take a manageable set of cases from different days, sources and unusual situations. For each, record four things: stored value, original evidence, observed difference and potential effect on the decision. If you cannot find evidence, label the case “not verifiable” rather than declaring it right or wrong. This worksheet helps a team locate a problem. A handpicked set of cases is not a statistically representative estimate of all records, so avoid presenting its error rate as one.
Routine rules can flag absent required fields, duplicate identifiers, impossible date sequences and unexpected changes. Such a check should make an exception visible, not quietly replace it with a guessed answer. When performing data integration, also compare definitions before matching column names. “Customer” might mean the paying organization in finance and the person who contacted support in another system. Those are not necessarily the same unit. Combining them automatically can create attractive reports with misleading totals.
Repair the cause, not only the chart
When you find an error, follow its path. Was the information never captured, copied into the wrong field, transformed under a changed rule or summarized under an ambiguous label? Editing a report cannot solve a form that creates the same mistake tomorrow. Give important fields an owner who can define their meaning and decide how corrections are documented. Keep the old and new value or a trace of the change when it matters. Silent replacement makes later questions much harder to answer.
Prioritize by the likely effect and frequency of an error. A wrong invoice address may matter far more than an empty optional note. A rare but serious mistake might call for human review rather than mass automated changes. More collection does not automatically improve quality either. If a field is not needed for the purpose, gathering personal information merely creates another item to protect and maintain. Make access proportionate to the information and keep the amount collected purposeful.
Sometimes the disagreement is legitimate
Sales and accounting may report different revenue figures. One might be wrong, or they may use different periods, return rules or definitions. Put the calculation rules side by side before trying to force the totals to match. Explain which view supports which decision. Even a consistent value in a database can be unsuitable for a report that asks a different question. Record the source and limits of a number so that colleagues can tell what it does and does not describe.
Finally, check again after changes. Products, forms and workflows evolve while old validation rules keep running. A small regular review of the fields that drive decisions can outperform a one time cleanup. Watch whether errors in those cases become less common and whether the underlying decision is now better supported. Revise a rule if the process has changed and document why. Good data quality is not an impossible promise of perfection. It is a defensible understanding of where information can be relied on and where uncertainty remains.
Common questions
Are complete records automatically good data?
No. A filled field can be wrong, outdated or defined differently by two teams. Trace a consequential example to its original event and ask whether an error would alter the intended decision.
Where should a small team start?
Choose one upcoming decision and the few fields on which it relies. Check exceptions and their source there before starting a general cleanup of every record in the system.