How to Find and Remove Duplicate Contacts

The duplicate contacts that hurt you don't look like duplicates. Your CRM's built-in tool catches john.smith@acme.com listed twice. It does not catch j.smith@acme.com and john.smith@acme.com sitting in two records, or "Acme Inc" filed separately from "Acme Corp," or the same person who filled out a form as "Jon" in 2023 and "Jonathan" last quarter.

Those are the records that split a rep's history in half, double your account count, and route the same prospect to two SDRs. The consumer "merge all duplicates" button that dominates every search result solves exact-match collisions on a phone. It does nothing for the near-matches that make up most of the duplication in a B2B database. This is how to find the duplicates exact matching misses, merge them without losing data, and stop new ones from forming on the next import.

Step 1: Understand why duplicate contacts form in the first place

Duplicates are a side effect of having more than one way into your CRM. A contact enters from a form fill, then again from a trade-show list upload, then a third time when a rep adds them by hand after a call. Each entry uses a slightly different spelling, a different email alias, or a different company name, so the CRM treats them as three people. The problem is not that anyone made a mistake. It is that nothing normalized the values before they landed.

Once you see the entry points, the pattern is obvious: the same human or account arrives through channels that never agree on formatting. A name is "Bob" in one source and "Robert" in another. A company is "Acme, Inc." in a purchased list and "Acme" in a self-reported form. An email is personal in a PLG signup and work-domain in a sales-entered record. None of these match on a literal string compare, so every native dedupe tool walks right past them.

The takeaway is that you cannot prevent variation at the source without rejecting half your inbound. You can only reconcile it after. That reconciliation is a matching problem, and it is the next step.

Step 2: Find the duplicates exact matching misses with fuzzy matching

Clay's own Dedupe is exact-match, case- and whitespace-sensitive, on a single column, so to catch near-matches you build a workflow: normalize the keys with formatters, compare with a Lookup Rows match and an AI similarity score, then pick the surviving values. That catches the easy 10% the exact-match tools find, then surfaces the duplicates that actually cost you.

Bring your contacts into Clay from HubSpot or Salesforce through the native integration, no CSV export required. Then build the comparison keys. Normalize the email to its root by stripping dots and plus-tags from the local part and lowercasing the domain, so j.smith@acme.com and John.Smith+crm@acme.com both reduce to jsmith@acme.com. Normalize the company name by lowercasing and dropping legal suffixes (Inc, LLC, Corp, Ltd) and punctuation, so "Acme, Inc." and "Acme Corp" both reduce to acme. Match people on the normalized email plus a name-similarity check, and match accounts on the normalized domain. Two records that looked unrelated to the CRM now collapse into one match group.

You can run the name-similarity judgment with AI rather than a brittle string-distance rule, which handles "Bob" versus "Robert" and "Liz" versus "Elizabeth" that pure character comparison gets wrong. Here is a prompt you can drop into an AI column to score whether two records are the same person:

Score every candidate pair, then keep the groups above a confidence you trust: 90 and up for auto-merge, 70 to 89 for human review.

Step 3: Decide the survivor and merge field by field

Merging is choosing the best value for each field, not picking a row and deleting the other. The common failure is "keep the newest record." The newest record is often the thinnest: a rep typed a name and an email after a call and skipped everything else. The older record might hold the verified phone, the correct title, and the activity history. Survivorship means assembling one complete record from the best parts of each, not crowning a winner.

Go field by field. For each field, the surviving value is the most complete and most trustworthy one across the group, regardless of which record it came from. Email: keep the verified work address over the personal Gmail. Phone: keep the populated direct dial over the blank. Title: keep the specific "VP of Revenue Operations" over the generic "Manager." Company: keep the normalized canonical name. The result is a single record richer than any of its inputs.

This is the difference that compounds across a whole database. At Sana, the team rebuilt CRM trust by enriching and reconciling accounts at scale rather than letting reps patch records one at a time.

That confidence is the real output of a clean merge: a record a rep does not have to re-verify before every call.

Step 4: Merge safely back into HubSpot or Salesforce

The merge is only safe if it preserves activity history and writes back without creating new records. A contact's emails, calls, meetings, and deal associations are the reason the record matters. Lose them in a sloppy merge and you have a clean-looking record with no memory. Before you write anything back, confirm the merge keeps every activity timeline from every record in the group attached to the survivor.

Work the write-back the way Clay's own team teaches it in the CRM enrichment course. Treat lookups as read-only: pull records into Clay, build and check your match groups and survivor values, and change nothing in production while you do. When you are ready to write, test in a Salesforce sandbox first so a mistake never touches live data. Use the Salesforce Update record action keyed on the Record ID so the surviving record updates in place. Clay prevents duplicate creation by default, and the duplicate records are merged or archived on the Salesforce side. Writes to Salesforce cannot be undone. Keying on the record ID is the safeguard that stops the cleanup from becoming the next source of duplicates.

The end state is one live record, zero new records, and the full history attached. That is the whole point of keying on the record ID rather than letting the cleanup insert fresh rows.

Step 5: Prevent duplicate contacts at the point of entry

Cleaning once doesn't last; the next import refills the database unless you dedupe at entry. A one-time cleanup feels like a win for about a week. Then a new list lands, the same near-matches slip in, and you are back where you started. The only durable fix is to run the same normalize-and-match logic on every new record before it gets written, not just on the batch you cleaned today.

Set the dedupe check as a standing step on the inbound path. New records (form fills, list uploads, manual adds) flow through Clay, get normalized on the same keys you used in Step 2, and get checked against existing contacts. A clear match updates the existing record instead of creating a new one. A near-match below the auto-merge threshold routes to a review queue rather than silently doubling an account. Run it on a schedule so it processes new arrivals continuously, the same way a refresh list keeps enriched data current.

With the rule on, new arrivals update, merge, or queue for review, and the duplicates-created counter stays at zero. Switch it off and the same records all create fresh rows. That gap is the difference between cleaning once and never having to run the project again.

Common failure modes when removing duplicate contacts

Three mistakes turn a dedupe project into wasted effort. The first is blind "merge all": trusting a one-click button that only collapses exact string matches, so every near-match duplicate survives and you declare victory over the easy 10%. The second is keeping the newest row instead of the best value: the new record overwrites a richer old one, and you lose the verified phone or the real title to save a worse version. The third is re-creating duplicates on the next import: you clean today, skip the entry-time check, and a list upload next month rebuilds the mess because nothing normalized the new arrivals.

All three come from treating deduplication as a cleanup task instead of a standing matching system. Exact-match tools miss the duplicates that hurt, newest-row merges destroy data, and one-time cleanups expire. The fix in each case is the same logic applied at the right moment: normalize before you compare, merge by best value per field, and run the check at entry so it never has to be a project again.