B2B deduplication fails when a team asks one question—“Are these two rows the same?”—for several different entities. A contact can be duplicated while the company is not, a company can have several legitimate domains, and two people can share a name. The workflow should therefore deduplicate accounts and contacts separately.
Normalize comparison fields without overwriting the originals
Create helper fields for matching: - lowercase and trim email; - normalize domains by removing protocol and common `www` prefixes; - standardize phone digits plus country code when known; - normalize LinkedIn or other profile URLs; - create a simple canonical company-name form for comparison.
Keep the original values. “ACME, Inc.” and “Acme” can normalize to the same comparison key while the display name remains intact.
Do not strip so aggressively that distinct companies collapse. “ABC Plumbing” in Dallas and “ABC Plumbing” in Denver may be unrelated.
Resolve exact contact duplicates first
Exact email is usually a strong contact key. If two rows share the same current business email, inspect whether they represent the same person. If they do, merge rather than delete blindly.
Choose field precedence: - first-party CRM/customer data can outrank third-party enrichment; - a newer verified title can outrank an older title; - explicit opt-out status must outrank an imported “active” flag; - source and verified date should travel with the winning field.
HubSpot, for example, automatically deduplicates contacts by email and companies by domain in common workflows. Even if you use another CRM, that separation is a useful mental model.
| Entity | Starting key / Review | |
|---|---|---|
| Contact | Normalized exact email | Shared aliases, suppression, source history. |
| Company | Normalized domain | Parent, franchise, location, rebrand. |
| Fuzzy candidate | Name similarity | Confirm location, phone, domain; do not auto-merge. |
Deduplicate companies with domain plus context
A primary corporate domain is often the strongest account key, but it is not infallible. Holding companies can own multiple domains, franchises can share one brand domain, and a company can rebrand from one domain to another.
Start with exact domain matches. Then review company name + location, legal entity identifiers if available, and parent-company relationships.
Maintain an alias table: old company name, old domain, current account ID. That prevents a rebrand from creating a brand-new opportunity when it is actually the same customer.
Use fuzzy matching only to create a review queue
Fuzzy company-name similarity is useful for finding candidates such as “Smith & Co LLC” versus “Smith and Company.” It should not automatically merge records by itself.
Create thresholds: - high-confidence exact keys can auto-merge; - likely matches go to human review; - weak similarity stays separate.
For contacts, same first/last name at the same company can be a review hint, but not proof. Common names make name-only merges dangerous.
Decide what happens to conflicting fields
A merge is a data-governance decision. If record A says “VP Sales” from 2025 and record B says “Chief Revenue Officer” verified last week, keep the newer title and the older value in history if useful.
For phone numbers, you may retain multiple labeled values instead of choosing one. For company size, preserve source and date because vendor estimates vary.
Never let a merge remove an unsubscribe, legal hold, or do-not-contact marker. These controls should be unioned, not selected by recency.
Measure duplication before and after imports
Before importing a vendor file, calculate: - exact email matches to existing contacts; - exact domain matches to existing accounts; - fuzzy account matches requiring review; - new contacts at existing accounts; - truly new accounts.
This tells you how much of a purchased list is incremental. A 10,000-row file that contains 4,000 existing contacts is not a 10,000-lead acquisition.
After the import, run the same checks and count accidental account splits or contact duplicates.
Before allowing an automatic merge, define the exact match rule, the fields that must be populated, and the records that are excluded. A shared company domain alone is not enough to merge contacts; a shared brand domain may represent separate franchise locations. Run the rule against a labeled sample of known duplicates and known non-duplicates, then inspect false matches before applying it to the full database.
Preflight imports, APIs, and syncs
Do not assume a CRM applies the same duplicate rule to every way a record can enter. Before enabling a vendor import, API integration, or two-way sync, check which fields that path actually uses as unique identifiers. HubSpot documents email/domain matching for common contact and company creation workflows, while also noting that API-created companies are not automatically deduplicated by company domain. For supported imports, a record ID or custom unique-value field can make updates deterministic; if the identifying field is absent, rows may create new records.
Before the full load, export a backup, run a small representative batch, and inspect both matched and unmatched rows. Compare expected creates, updates, and possible duplicates with actual results. Keep source, imported-at date, and batch ID so a bad batch can be isolated and corrected.
For any merge, preview the surviving record, field precedence, associations, activities, and protected controls before applying it. Record the surviving ID, merged IDs, match rule, timestamp, and changed fields in a merge log. The final result should leave a clear account-contact hierarchy and explain why each canonical record and suppression survived.
