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.

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.

Prevent the next cleanup

Require stable IDs on exports and imports. In systems that support record IDs, use them when updating existing data rather than matching only on names. Store source, imported-at date, and original batch ID.

The final deduplication outcome should leave a clear account-contact hierarchy, not merely fewer rows. Sales should know which company is canonical, which contacts belong to it, which values were preserved, and why a suppression or historical field survived the merge.

Deduplicate people and companies at different levels

For people, normalized email is usually a strong identifier when it is present and reliable. For companies, normalized website domain is often more stable than company name alone. HubSpot, for example, documents automatic contact deduplication by email and company deduplication by domain in relevant workflows.

Normalize before comparing: lowercase domains, remove URL protocols and common `www` prefixes, standardize phone formatting, and separate legal suffixes from core company names when using fuzzy matching. Keep the original value for audit purposes.

Do not automatically merge every fuzzy name match. `ABC Plumbing LLC` and `ABC Plumbing Supply` may be different businesses. Use a confidence tier: deterministic matches can merge automatically; ambiguous matches should enter a review queue with address, phone, and domain context.

Keep a merge log For automated merges, record the surviving ID, merged IDs, match rule, timestamp, and fields that changed. A merge log lets the team reverse a bad rule and explains why historical campaign activity now appears on one record. It also reveals which imports create the most duplicate work.