Contact data quality is a relationship-safety issue when it determines who receives outreach, not simply a database-maintenance issue. Judge a record by whether identity, role relevance, recency, permission context, and suppression status make the next contact action appropriate and reviewable.
What contact data quality actually means
I keep a composite RevOps field note for a failure that never looks dramatic at first. The record is full: name, title, company, email, country, owner. Then the next action breaks. The person moved roles, the company is a duplicate, the territory came from an old import, or no one knows which source should win. What failed? Not field population. The record looked valid but couldn't safely carry the decision placed on it. That's the practical meaning of contact data quality: required fields must be accurate, complete enough, current, consistent, unique, and traceable for the action. One database-wide percentage can't answer a workflow question it can't see. A bounce exposes an unusable address, but delivery doesn't prove role, company match, authority, permitted use, or relevance. So I ask: What are we about to do, which fields can change that decision, and which unknowns mean proceed, review, or stop? Then I separate integrity from fitness. Integrity asks whether a value stays coherent through storage, transfer, permissions, and history; quality asks whether that value supports the intended decision. A controlled system can preserve the wrong country perfectly. I need both answers: what does this value mean now, and how did it get here? The UK Government Data Quality Framework treats dimensions, measurement, improvement, and ownership as one managed practice; it doesn't supply a universal sales score.
- Integrity defect: inspect mappings, permissions, transfer, and history.
- Fitness defect: return to the action, its critical fields, and the evidence for proceed, review, or stop.
- Both defects: preserve lineage so another operator can explain and reverse a wrong transition.
Measure the fields that gate the next action
What do I score? Only fields that can gate the action: identity, company match, role, reachable channel, geography, owner, source, last verification, and any applicable suppression state. I inspect accuracy, sufficient completeness, freshness, consistency, uniqueness, and traceability, but I don't average away a fatal defect. If country controls territory, a wrong country stops routing even when optional profile fields are filled. Then I watch duplicate merges, routing corrections, validation failures, bounces, and manual overrides by source, workflow, and owner. Those are clues, not universal targets. I open affected records; the trend tells me where to sample, not what caused the defect. The same logic appears in a reviewable prospecting flow: you can give OKKI Go product, buyer type, country, and exclusions; it returns candidate companies with business context; you review them before selectively unlocking a company; and the result is a chosen shortlist that may lead to contact discovery. Does that certify the underlying data? It doesn't. It creates a checkpoint where fitness can be inspected before the next action. I still need evidence behind each critical field, and I stop when one unresolved value can change identity, territory, suppression, or recipient selection.
Use states instead of false precision
I use four states instead of false precision. Verified for this action means the required observation, source, and review are current enough for the named decision. Usable with a disclosed limitation means the uncertainty is visible and cannot change that decision. Unresolved means competing values or missing lineage could change the action, so the record waits for review. Unsafe means identity, territory, suppression, or recipient selection could be wrong, so the dependent step stops. What would happen if this field were wrong? That question keeps a high average from overruling a fatal defect. I can still trend states by source, segment, workflow, and owner, but the threshold belongs to the action's risk. It tells me where a decision is weakening and where a reviewer must intervene; it doesn't pretend every team, channel, or database shares one acceptable percentage. When a state changes, I keep the observation, reason, reviewer, and prior state together. When reviewers disagree, I preserve the disagreement rather than smoothing it away. That note lets the next operator trust the decision without mistaking a status label for evidence, and it gives us a precise point to revisit when new information arrives.
Trace the first bad transition
Once a field fails its action test, I resist the tidy-up reflex. Cleaning the visible value without finding its first bad transition schedules the same repair again. I put the failed action beside the field history and walk backward: Was the value typed into free text, mapped into the wrong import column, overwritten by a weaker source, separated from its verification date, copied into a duplicate, or left behind when the person moved? The first bad transition tells us which control failed; the last symptom only tells us where somebody noticed. I mark the earliest point where the value and its evidence diverge, because that boundary shapes the repair and identifies the owner who can prevent recurrence. I keep the raw observation beside each transformation so a reviewer can distinguish source from inference. I also split channel trouble into two questions. Could the message or call reach the recorded destination? Did that destination still belong to the intended person, company, and role? Syntax checks, send status, bounces, and call outcomes help with the first. Identity, company context, source, and recent verification are needed for the second. Otherwise we'll call a contact correct because one email delivered, or discard a useful identity because one address failed. Neither conclusion follows. I close the case only when I can name the first divergence, the failed control, and the decision put at risk.
Four origins produce different remedies
My next note is blunt: different origins need different remedies. Capture errors call for clearer definitions and constraints. Import errors call for mapping tests, quarantine, and rollback. Cross-source conflicts call for precedence rules that preserve both observations until review; natural decay calls for a new observation, not cosmetic normalization. Which origin am I looking at? A bounce may be a stale address, malformed import, or receiving-domain problem. A duplicate may be a matching defect, two business units, or different people with similar names. That's why I keep source, timestamp, transformation, prior value, current value, reviewer, and reason together. The record shows whether the defect entered at capture, transfer, reconciliation, or maintenance rather than where it surfaced. Validation tests a rule; enrichment adds or updates an observation. Neither can decide identity while matching logic, source strength, and uncertainty are hidden. Salesforce documents status, assignment, conversion, and history as separate lead concepts—an operating example, not proof that an implementation is correct. If we can't reconstruct why an owner or status changed, a tidy current record may hide the cause. I preserve history to compare observations, explain a handoff, reverse an overwrite, and show what remained uncertain. The remedy is complete only when it changes the failed transition without erasing the evidence that exposed it.
Remediate the cause before adding more data
Once I've found the first bad transition, I repair in an order I can reverse. I isolate records that could trigger a harmful action, preserve the raw value and lineage, resolve identity before merging duplicates, standardize format without changing meaning, validate syntax and allowed values, and reconcile conflicts with explicit precedence and review. Only then do I enrich against a dependable matching key, retaining the new source, timestamp, confidence, and replaced observation. The old value may explain an earlier action or a conflict another reviewer must reverse. Drafting gives us another checkpoint. You can provide OKKI Go company context and product materials; the system produces an outreach draft; you confirm the recipient, subject, and body before sending; and the result is a reviewed message with send status and failure reasons visible. Does that prove the contact is accurate? No. It lets the operator catch mismatched identity, context, or channel before use. I finish by rerunning the protected workflow at the same checkpoint, using the criteria that exposed the defect. If the correction doesn't change the expected result, I haven't closed the diagnosis—I've only changed a field. If it does, I record the control that prevented the bad transition and the owner who will maintain it.
A governance review should also inspect the record that was not used. Rejected, suppressed, unresolved, and stale contacts reveal whether the system protects relationships before an email is drafted. Keep those outcomes visible beside successful matches; otherwise the dashboard rewards usable records while hiding the decisions that prevented an inappropriate approach.
Resolve identity before enrichment
Deduplication is an identity decision, not spelling cleanup. I compare stable identifiers where they exist, then inspect company, role, and source context; matching names alone don't establish one identity. I keep competing values, timestamps, lineage, and confidence visible while a reviewer decides whether records belong together. Why keep the old observation? It may explain an earlier action or show that two systems use different definitions. I won't treat a newer timestamp as proof of a better value. If the pair remains ambiguous, I mark it unresolved and stop the dependent action instead of making a confident merge we can't explain later. That pause protects the next decision while leaving evidence available for another reviewer. Only after identity is resolved do I validate structure and allowed values, reconcile conflicts, and enrich from a dependable key. The new observation keeps its source and timestamp, and it doesn't silently erase the value it replaced. I then rerun the protected workflow and record whether the correction changed the expected result. That test separates a real remediation from cosmetic cleanup. The safe order remains reversible: isolate action risk, preserve lineage, resolve identity, validate without changing meaning, reconcile, enrich, and verify the workflow.
Govern contact data as a changing asset
Contact data changes as people and organizations change, so maintenance isn't a calendar refresh. A bounce, duplicate, import exception, routing override, conflicting enrichment, stale verification date, or repeated correction opens a review; it isn't the verdict. I track resolution time and recurrence by origin, keeping the sample window, matching rule, unresolved cases, and reviewer disagreements visible. Are we sampling decisions that carry risk? If a small segment drives routing failures, I won't let a large low-risk segment wash it out. A useful trend points back to a field, failure origin, owner, and protected action. Ownership turns that trend into a control. After you inspect early candidates, you can give OKKI Go revised criteria; the system returns a corrected route; you review it and choose a company to unlock; and the result is an explicit selection instead of an assumed match. The documentation doesn't establish source coverage, legal status, or a contact-accuracy rate. I assign each checkpoint to the failure origin, choose one recurring defect, and watch whether prevention changes recurrence. Regulated questions go to qualified privacy or legal owners; UK regulator guidance identifies accuracy within its scope, not as a global conclusion. Can we connect defect, origin, owner, action, and change? If yes, the metric guides repair. If not, it merely describes the database.
- Field owner: meaning, sources, volatility, verification, and action threshold.
- System owner: capture, mappings, permissions, transfer, and history.
- Data steward: competing values, lineage, and unresolved identity.
- Workflow owner: the evidence required to proceed, review, or stop.
- Qualified privacy or legal owner: regulated scope and jurisdiction.
Frequently asked questions
What is contact data quality?
Contact data quality is the fitness of required contact fields for a named action. It combines accuracy, sufficient completeness, freshness, consistency, uniqueness, and traceability rather than relying on one generic score.
Which contact data quality metrics matter most?
Measure the states and failures that protect the action: verified or unresolved critical fields, duplicate merges, routing corrections, validation failures, bounces, manual overrides, time to resolution, and recurrence by source. Targets must be set from the team's own risk and workflow.
Is email deliverability the same as contact data quality?
No. A bounce can reveal an unusable address, but delivery does not prove that the person's role, company match, authority, source, or permitted use is correct. Deliverability is one downstream signal.
Should a team validate or enrich contact records first?
Resolve identity and preserve source history first. Then validate format and allowed values. Enrich only when the matching key is dependable, and retain the new source, timestamp, confidence, and replaced observation.
Julian Hartwell
Julian Hartwell is an independent B2B sales intelligence analyst covering contact databases, company data, decision-maker profiles, direct dials, prospect lists, and buying signals. He applies the ISO/IEC 25012 data-quality model while examining field accuracy, coverage, freshness, duplicate rate, match confidence, and source transparency. His evidence-led guides help revenue teams compare prospecting platforms, define acceptable data thresholds, and build account lists that support reliable territory planning and outreach.