CRM Data Quality: Measure and Repair Decision-Critical Data

Define CRM data quality by decision, population, and risk

This page owns measurement and remediation of CRM record quality. The CRM hygiene playbook owns the recurring governance routine; CRM data enrichment owns external data acquisition; integration pages own transport; field-design pages own schema; and migration pages own cutover.

Start with a decision contract. Name the decision, population, fields, source hierarchy, required freshness, critical errors, owner, correction deadline, and downstream consumers. “Our CRM is 92% clean” is not actionable if the score blends empty optional fields with a wrong legal entity, missing suppression, or incorrect forecast amount.

Quality is contextual. A contact title may be sufficient for routing but too stale for committee analysis. An opportunity amount may be acceptable for seller planning but not for finance reporting. Do not publish a universal quality threshold.

Create field contracts for decision-critical data

Create a field contract for data that can change decisions. Typical groups include entity identity, account ownership, contacts and roles, opportunity stage and amount, close date, next step, activities, products and quantities, source attribution, consent and suppression, currency, region, and integration provenance.

Mark fields required only when the decision requires them. Forcing every seller to populate every possible field can produce plausible filler rather than truth. Unknown, not applicable, disputed, and not yet requested should remain distinguishable.

Measure quality dimensions separately

NIST’s Research Data Framework discusses data fitness for purpose and quality characteristics. Apply dimensions separately rather than collapsing them too early:

• Accuracy: the value agrees with appropriate independent evidence.
• Completeness: required values and relationships are present for the decision.
• Validity: the value follows the field’s type, format, range, and business rule.
• Consistency: representations do not conflict across fields, objects, or governed systems.
• Timeliness: evidence is current enough for its use.
• Uniqueness: one real entity is not incorrectly represented as several active entities.
• Relationship integrity: people, accounts, opportunities, activities, and products are linked correctly.
• Provenance: source, transformation, writer, and time are inspectable.

A record can pass format validation and still be wrong. It can be complete and still contain unsupported values. Report dimensions and critical defects separately.

Assign source, provenance, and write authority

For each field, designate a source of truth or an explicit reconciliation rule. CRM may own seller stage, while finance owns invoices and recognized revenue. An identity provider may own user status. A consent or suppression system may override a campaign enrollment. Do not let bidirectional sync silently create two writers.

The ICO’s accuracy guidance addresses reasonable steps to ensure personal data is accurate, source and status challenges, and correction or erasure where appropriate. Applicability is context- and jurisdiction-specific, but the operational lesson is useful: preserve source, distinguish fact from opinion, and provide a correction path.

Write provenance with current value, observed or derived state, source entity and ID, observed-at and ingested-at, transformation and version, writer, authority, prior value, conflict candidates, and correction evidence. A “last modified by integration” label does not reveal the upstream claim.

Audit a stratified labeled sample with explicit denominators

Freeze the eligible population and take a stratified sample across record type, owner, source, age, region, stage, and integration path. Build independent labels from the approved truth hierarchy. Blind reviewers to the CRM value where practical and adjudicate disagreements.

Useful field-level measures include:

• accuracy = correct labeled values ÷ labeled values with known truth;
• required completeness = populated valid required fields ÷ all required fields;
• staleness = values beyond the field’s approved freshness window ÷ eligible values;
• conflict rate = records with unresolved authoritative conflicts ÷ eligible records;
• relationship precision = correct asserted links ÷ all asserted links;
• relationship recall = correct asserted links ÷ all known required links.

Always report denominators and confidence or uncertainty appropriate to the design. A sample of active enterprise opportunities does not establish quality for dormant leads or another region.

Detect duplicates and merge only after identity review

Duplicate detection and merging are different decisions. HubSpot’s deduplication documentation describes automated and manual duplicate-management behavior and edition-dependent capabilities. Product matching does not prove that two records are the same real entity.

Generate candidates using normalized domains, names, emails, addresses, registration IDs, or other approved keys. Review false merges as critical errors. Before merging, choose a survivor; map every relationship, consent state, owner, activity, opportunity, ticket, and external ID; preserve conflicting values; and test downstream integrations.

After merge, reconcile record counts, relationship counts, activities, suppression, attribution, and external references. Keep an undo or restoration plan where supported. Never merge merely to improve a duplicate-rate dashboard.

Use history and freshness without mistaking timestamps for truth

History supports diagnosis but is not complete provenance. Salesforce’s field-history documentation describes bounded tracking of changes to selected fields, including old and new values where supported. Tracking depends on configuration and has field, type, and retention limitations.

Test created, updated, backdated, merged, deleted, restored, reassigned, imported, retried, and replayed records. Measure source-to-CRM latency only when source-event time is reliable. A recently modified timestamp does not prove the underlying business fact is current.

Create expiry or revalidation rules by field and use. A verified domain may remain stable longer than employment, opportunity next step, consent, stage, price, or forecast category. Expiry should create a review state—not invent a replacement value.

Remediate root causes with reconciliation and rollback

Prioritize defects by decision risk, not raw count. Wrong suppression, wrong account identity, cross-customer exposure, and finance-field overwrite deserve different treatment from missing optional notes. Maintain an exception queue with severity, affected decision, source, owner, due date, evidence, correction, reviewer, and closure.

Fix root causes in this order: remove unnecessary fields and duplicate systems; clarify definitions and authority; validate at entry; stage uncertain automated proposals; reconcile integrations; correct labeled defects; then monitor recurrence. Automation should begin read-only or draft-only, use a golden set, inject duplicate/replay/order/permission failures, canary one cohort, and retain a kill switch.

Reconcile before and after changes. Compare counts, field values, relationships, critical exceptions, downstream reports, and audit history. The AI CRM automation guide owns wider automation governance, while data-entry automation owns capture-to-write design.

Treat every dashboard or model fed by a corrected field as a downstream consumer. Re-run its joins, filters, cohort rules, currency handling, and control totals before closing the change. A source record can be corrected while a cached dataset or semantic layer remains wrong. The sales reporting automation guide covers that downstream reconciliation boundary. Record which reports were tested, who accepted the new value, and when the previous version can be retired.

Use a printable CRM data-quality control record

A quality program succeeds when another qualified owner can reproduce the measurement, inspect why a value was trusted, correct it without hiding history, and verify that the remediation did not create a larger downstream defect.