gtmjosh
CRM Data Quality
Chapters
  1. 01 · What Makes CRM Data Trustworthy?
  2. 02 · Run a Baseline Data Audit
  3. 03 · Find and Prevent Duplicates
  4. 04 · Standardize and Validate Records
  5. 05 · Handle Consent, Opt-Outs, and DNC
  6. 06 · Handle Job Changes, Departures, and Churn
  7. 07 · Enrich the Records That Matter
  8. 08 · Resolve Conflicting Values
  9. 09 · Choose What to Buy, Configure, Connect, or Build
  10. 10 · Establish Continuous Checks and Quarterly Audits
  11. 11 · Capstone: Repair a Broken CRM Population
Guide overview →

15 min · Interactive exercise

Chapter 3 of 110 complete

Find and Prevent Duplicates

Set match thresholds, an adjudication tier, survivorship rules, and a protected-record check.

Two records at target Account Ferrow Industrial: Marcus Webb and Marcus Webber. Same first name, near-match surname, same company domain, similar title. A rules-only fuzzy matcher scores this pair high enough to auto-merge under a two-outcome model: merge, or don't. The auto-merge runs. Marcus Webb turns out to be a director-level buyer already mid-evaluation; Marcus Webber is a separate engineering contact who was never on that call. Merging them collapses two people's activity history into one record, with no clean way to undo it.

Matching isn't the hard part

Exact-match signals, a verified email or a platform-supplied ID, are reliable. Fuzzy signals such as name similarity and shared company domain catch more real duplicates and more false positives at similar rates. A three-outcome model beats a two-outcome one: auto-merge when confidence is high enough that review adds no signal, human review when it's plausible but not certain, and no match when it's too low to route anywhere. Account-level merges carry their own, stricter rule: an Account carries Opportunity and contract history, so a wrong merge there is categorically more expensive than a wrong Contact merge, and stays review-only even when Contact merges can safely auto-run.

Adjudicate the pair, protect the customer contact

The duplicate-pair-set fixture holds a high-confidence pair that auto-merges under the survivorship rules, alongside Marcus Webb and Marcus Webber, who route to review instead. Separately, a bulk import created a near-duplicate contact, Rina Fields, by copying Priya Shah's phone number and email domain onto a new record. The match score is high, but Priya has an open Opportunity, so the protected-record rule blocks the merge and routes it to review with that reason stated.

Carry this into your business

A duplicate pipeline that only knows “merge” or “don't” will eventually merge two real people, and there's no undo button for that mistake. Build the review tier before you turn on auto-merge, and protect any record a wrong merge would actually hurt.

GTM Lab

Saved locally
CRM Data Reliability Plan · 0 of 11 sections started

Saved locally to your browser.

Set the policy and run the duplicate-pair fixture

Classify match signals, choose the threshold model, set survivorship and the account-merge rule, then run the fixture.

Fixture: duplicate-pair-set

Ferrow Industrial · two candidate pairs

FIXTURE-DUPLICATE-PAIR-SET
High-confidence pair
Two records, verified-identical email
Ambiguous pair
Marcus Webb (director, mid-evaluation) vs. Marcus Webber (engineering contact)
Shared signals
Surname similarity, same company domain, similar title
Risk if merged wrongly
Collapses two people's independent activity history
Resets every run.
Two signals suggest a duplicate: an identical email address, and a similar name at a similar company. Should the system trust them the same way?
A match score is a number on a sliding scale. How many outcomes should that number actually sort candidates into?
When 2 records merge, their contact-info fields (email, phone, title) may disagree. Which value survives?
The same merge also has 2 separate histories of calls, deals, and notes. What happens to those?
An Account merge carries Opportunity and contract history that a Contact merge does not. Should it follow the same auto-merge rule?

Confirm the protected-record conditions

Open Opportunity, active CS relationship, recent marketing engagement, closed-won

Run the unsafe proposed merge

A bulk import created a near-duplicate of Priya Shah, Rina Fields, by copying her phone number and email domain. The match score is high. Priya has an open Opportunity.

Fixture: unsafe-proposed-merge

Priya Shah × Rina Fields · proposed merge

FIXTURE-UNSAFE-PROPOSED-MERGE
Priya Shah
Acme Manufacturing · Sales-ready · open expansion Opportunity
Rina Fields
Created by a bulk import that copied Priya’s phone and email domain
Match score
High (phone + email-domain match)
Protected condition
Priya has an open Opportunity
Resets every run.

Attempt the merge

Chapter 3 of 110 complete