Chapters
- 01 · What Makes CRM Data Trustworthy?
- 02 · Run a Baseline Data Audit
- 03 · Find and Prevent Duplicates
- 04 · Standardize and Validate Records
- 05 · Handle Consent, Opt-Outs, and DNC
- 06 · Handle Job Changes, Departures, and Churn
- 07 · Enrich the Records That Matter
- 08 · Resolve Conflicting Values
- 09 · Choose What to Buy, Configure, Connect, or Build
- 10 · Establish Continuous Checks and Quarterly Audits
- 11 · Capstone: Repair a Broken CRM Population
15 min · Interactive exercise
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 locallyCRM 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
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
Attempt the merge