CRM data cleansing: an enterprise RevOps guide to safe CRM writes

Most CRM data cleansing advice stops at a checklist: remove duplicates, correct formats, fill blanks and repeat. That is necessary, but it is not enough for an enterprise CRM connected to forms, integrations, enrichment providers and automated agents. The operational question is harder: which proposed change is safe to apply to which record, on what evidence, and at what cost?

This guide gives RevOps and sales operations leaders a repeatable data cleaning process. It distinguishes cleansing from enrichment, shows where duplicate prevention belongs, explains how to handle source conflicts and provides a worked evaluation model. All figures in the charts are illustrative calculations, not TargetWise results, customer outcomes or industry benchmarks.

What a CRM data cleansing programme should produce

A clean CRM is not a database in which every field is populated. It is a database in which each important field has a usable meaning, a known owner and an explicit rule for change. A blank mobile number is usually safer than a switchboard number labelled as a verified direct dial. An unresolved employer is safer than an automatic update that moves the wrong person to the wrong account.

Use five separate tests:

• Identity: does this record represent the intended person or company?
• Uniqueness: is it a new entity, an existing entity or a possible duplicate requiring review?
• Field validity: does the value conform to the expected format and allowed range?
• Evidence: what supports the value, when was it observed and does it conflict with existing information?
• Usability: may this value be used for the intended workflow under the organisation’s own policy?

These tests prevent four common category errors. A syntactically valid email is not necessarily deliverable. A delivered email does not prove current employment. A company-domain match does not prove two subsidiaries are the same legal or commercial account. A populated field is not automatically a permitted outreach channel.

Keep “rejected” and “unresolved” separate. A timeout is not evidence that a person has no work email. A source returning no phone is not evidence that the contact has no phone. This distinction matters when workflows retry automatically or when procurement compares supplier coverage.

Run the data cleaning process in the right order

Sequence matters. If you enrich first and deduplicate later, you can pay several times to research the same person. If you overwrite before resolving identity, the new information can make the duplicate harder to recognise. If you delete before preserving history, you may damage attribution, opportunity reporting or audit evidence.

1. Freeze the baseline. Take a recoverable snapshot, record the extraction time and assign every input an immutable CRM record ID.
2. Quarantine obvious junk. Separate test records, malformed submissions and records that are out of scope. Archive or suppress where deletion would remove useful history.
3. Standardise before matching. Normalise case, whitespace, country codes, phone formats, domains, legal suffixes and controlled vocabularies. Retain the original value.
4. Resolve identity. Decide whether records refer to the same person or company. Use stable identifiers where available and treat fuzzy scores as review signals, not truth.
5. Deduplicate. Select a survivor record, define field-by-field merge rules and preserve associations such as opportunities, activities and consent status.
6. Enrich accepted gaps. Request only fields required by the workflow. Keep found, verified and usable as separate states.
7. Write with controls. Compare the record version immediately before the write, apply only approved fields and log the previous value, new value, reason and policy version.
8. Monitor recurrence. Track which forms, imports and integrations create new problems. A cleanup that does not fix ingestion becomes a recurring expense.

Microsoft Dataverse and HubSpot documentation both illustrate why platform behaviour must be checked rather than assumed. Duplicate detection depends on configured rules and operation type. HubSpot documents that companies created through its API are not deduplicated by company domain in the same way as some manual or import flows. The general lesson is broader: test the exact write path you will automate.

Define the survivor before you merge duplicates

CRM data deduplication is not simply deleting the newer or less complete row. Two records can each contain information the other lacks. One may own the active opportunity; another may hold the more recent employer; a third may contain the valid suppression request. The survivor is therefore a record-level decision, while the merge is a field-level decision.

Start with deterministic keys: CRM record ID, a validated company identifier, a canonical profile URL or a verified work email tied to the intended employment. Then use compound evidence such as full name plus company domain plus location. Names alone are weak. Domains alone can collapse subsidiaries or franchises. Shared phone numbers can join unrelated employees.

Use enrichment to fill accepted gaps—not to define identity

Enrichment and CRM data cleaning overlap, but they are not interchangeable. Cleansing decides what a trustworthy record means. Enrichment attempts to add or refresh particular values. If the identity is ambiguous, another email or phone candidate does not repair the underlying ambiguity.

Request enrichment after deduplication and prioritisation. Send the strongest available identifiers and ask only for fields the workflow needs. Store the returned value, provider, raw status, retrieval time and any available source or verification date. Do not substitute the retrieval timestamp for the date on which the underlying employment or contact fact was observed.

TargetWise documents on-demand person and company enrichment through REST and MCP. Its contact route can request email, phone and optional professional context for a known person; available fields vary. Its documentation also states that a returned business phone is not guaranteed to be a mobile and that work-email lookup does not itself verify deliverability. Those distinctions are exactly what a cleansing policy should preserve.

Define your acceptance ledger before connecting a provider. Use the TargetWise benchmark workflow to structure a representative evaluation of returned fields, latency, errors and usable results.

Measure cost per usable result, not nominal credit price

A cheap lookup can be expensive if it creates review work, duplicate writes or unusable fields. A high match rate can also be misleading when the denominator includes duplicates or records outside the intended market. Fix the denominator before procurement compares suppliers.

For a worked example, assume 10,000 eligible, unique inputs. A provider returns a candidate for 7,500. Identity and current-employer rules accept 6,800. Field evidence and suppression rules leave 6,000 usable results. Suppose supplier charges are £1,200, engineering allocation is £900 and review labour is £1,800. Total cost is £3,900, or £0.65 per usable result. The nominal supplier cost alone would appear to be £0.16 per returned candidate.

Neither number proves accuracy. Accuracy needs a labelled reference set and clear treatment of ambiguous cases. Cost per usable result answers a different question: how much did the complete workflow spend for each output it was willing to use?

Prevent avoidable spend before the first lookup

There is a simple economic reason to deduplicate and suppress before enrichment: every unnecessary record can trigger a paid request, consume rate-limit capacity and create another proposed update to review. The saving is not just the lookup price. It includes the avoided handling cost of a response that should never have been requested.

The calculator below treats duplicates and suppressed records as separate, sequential exclusions. If 20% of a 10,000-record file is duplicate and 5% of the remaining records is suppressed, the controlled workflow sends 7,600 requests rather than 10,000. At £0.12 per attempted lookup, the direct avoided spend is £288. This does not estimate the additional benefit from lower review and reconciliation work.

Design for the failure cases that damage enterprise CRMs

Stale employment. A real person and a real company can still form the wrong current relationship. Keep person identity, employer identity and employment dates separate. Do not overwrite an account association merely because a work email is deliverable.

Ambiguous people. Common names, transliteration and incomplete location data can produce several plausible candidates. Require a stable identifier or sufficient compound evidence. Route ambiguity to review instead of choosing the first result.

Catch-all domains. Domain acceptance does not establish the individual mailbox. Keep the provider’s raw status and your own acceptance decision. Email verification is evidence about a check at a point in time, not guaranteed inbox placement.

Unverified numbers. A phone-shaped value can be a switchboard, shared office line, reassigned number or wrong person. Preserve line type and ownership evidence when supplied. Never relabel an unknown business phone as a verified mobile.

Conflicting providers. Two values should not be averaged or selected by supplier priority alone. Compare the subject identifiers, evidence type and dates. Agreement is not independent corroboration if providers share upstream sources.

Duplicate contacts created by automation. A successful API response does not guarantee that a CRM create operation will deduplicate. Use an immutable write target for updates, a stable external key for creates and an idempotency or job key in your own workflow where supported.

API failures. Authentication errors, rate limits, timeouts and provider failures are operational outcomes. They are not “not found”. Retry only failures classified as retryable, use backoff and stop after a defined budget or deadline.

Source and retrieval dates confused. “Retrieved today” may describe when your system received the response, not when the source observed the fact. Leave unavailable source dates empty. A fabricated current date makes stale evidence look fresh.

Build a measurable CRM data hygiene operating model

CRM data hygiene is the ongoing control layer that prevents another large cleanup. Assign an owner for the dictionary, matching policy, merge rules and exception queue. Monitor by ingestion source so the team can see whether a particular form, event upload or integration is creating the problem.

Use a representative evaluation sample rather than whichever records are easiest. Include multiple countries, parent-subsidiary structures, recent job movers, common names, catch-all domains and records without strong identifiers. Label the truth set before tuning thresholds, then hold part of it back for evaluation. Otherwise the matching rules can appear to improve simply because they were fitted to the same sample.

Set service levels for the exception queue. A threshold that sends 40% of the database to review is not conservative if no team can process the queue. It simply defers decisions until they become stale. Report queue age, decision time and acceptance yield alongside match scores.

Questions procurement should ask before buying a cleansing or enrichment service

• Which workflows are batch, scheduled, real-time or strictly one-record on demand?
• Which fields are found, validated, verified or merely inferred?
• Can the provider return its original status, evidence dates and source context without forcing one opaque score?
• How are companies, people and current employment matched? Which identifiers are required?
• What happens when two sources disagree or when the domain is catch-all?
• How are duplicate requests, retries, asynchronous results and partial failures charged?
• Can writes be staged for approval, restricted by field and reversed with a complete audit log?
• Does the licence permit the intended CRM, agent, resale or embedded-product use?
• What sample will be tested, who labels the reference answer and which segments will be reported separately?
• What is the measured cost per usable unique result after review and integration effort?

Frequently asked questions