The most corrosive problem in your database
Two records for the same person is the kind of problem that looks harmless and isn't. You have a contact called "Bob Reyes" from a webform last spring, and another called "Robert Reyes" from a trade-show list, and neither record knows about the other. Half the email history lives on one, the deal lives on the other, and the full picture of the relationship lives nowhere. When Bob replies three months later, whoever picks it up is working from half a memory — which is exactly the failure a CRM is supposed to prevent. Duplicates are the quiet tax on everything: they split timelines, inflate your counts, and make every report a little bit wrong in a way nobody notices until a decision rides on it.
This is the deepest cut in any data-hygiene effort, and it deserves its own playbook because the fix is specific: you have to find duplicates reliably, merge them without losing anything, and then stop new ones at the door. Skip any of the three and the problem regrows.
Why duplicates creep in
Duplicates aren't a sign of a sloppy team — they're the natural result of contacts arriving through more than one door. Understanding the doors tells you where to put the locks.
- Multiple entry points. A webform, a manual add, a CSV import, and an email sync each create a record, and none of them check the others first. The same person coming in through two channels becomes two records by default.
- Tiny variations defeat exact matching. "Bob" vs "Robert," "Acme Inc" vs "Acme, Inc.", a personal Gmail on one record and a work address on the other. A human sees one person; a naïve exact-match sees two.
- Bulk imports without a merge step. The single biggest dupe generator is importing a list straight on top of existing data with no dedupe pass. A 2,000-row import lands 300 people you already had, doubled.
The pattern is that duplicates are created at the moment of entry, which is also the cheapest moment to catch them — a theme that decides the whole strategy.
Match on a stable key, not a name
The instinct is to dedupe on name, and it's the wrong instinct, because names are the least stable thing about a record. People go by nicknames, change last names, and get typed differently by every rep. The fix is to match on something that doesn't drift:
- Contacts: match on email. An email address is close to a unique identity — two records with the same email are almost certainly the same person. It's the most reliable single signal you have.
- Companies: match on domain. "Acme Inc," "Acme, Inc.", and "ACME" all share
acme.com. The web domain cuts through every punctuation and capitalization variant that breaks name matching.
For the cases a single key misses — the work-vs-personal-email split, the person who genuinely changed companies — fuzzy signals (similar name plus same company, same phone number) surface candidates a human then confirms. The principle is the same one that governs the MQL-to-SQL handoff: the machine flags what's likely, a person confirms what's real. Auto-merging on a fuzzy guess is how you fuse two genuinely different people into one corrupt record, which is worse than the duplicate you started with.
Merge, never delete
When you've confirmed two records are the same, the operative word is merge, not delete. Deleting the "extra" record throws away whatever history lived on it — the notes, the logged calls, the old deal — and that history is the entire reason the record was worth keeping. A clean merge does three things:
- Combines the timelines. Every note, email, logged activity, task, and deal from both records ends up on one surviving record, in chronological order. The relationship's full history reassembles.
- Resolves field conflicts deliberately. When both records have a phone number and they differ, you choose the survivor — usually the most recent, or the one you trust — rather than letting the system pick blindly.
- Preserves the links. A deal that pointed at the duplicate now points at the survivor; a sequence the contact was enrolled in carries over. Nothing is orphaned.
Get this right and a merge is invisible afterward — the surviving record looks like the relationship was always one clean timeline, because now it is.
Stop new duplicates at the door
Cleaning up duplicates is satisfying and temporary; the records regrow unless you close the doors that create them. Prevention is cheaper than cleanup by an order of magnitude.
- Check at entry. The most valuable place to catch a dupe is the instant a record is about to be created — a webform or manual add that warns "a contact with this email already exists" stops the dupe before it's born.
- Dedupe every import. Never bulk-import on top of live data without a match-and-merge pass. Catching dupes during the import is minutes; catching them next quarter is a project.
- Scan on a cadence. Even with locks on the doors, run a periodic duplicate scan — monthly is plenty — so the few that slip through never pile up. A monthly scan is a coffee's worth of time; a yearly one is a slog.
Let the CRM surface the candidates for you
The reason most teams live with duplicates is that finding them by hand is hopeless — you can't eyeball 4,000 contacts for near-matches. The job belongs to the system.
In Hitt CRM, duplicate detection surfaces likely matches automatically by the stable keys that actually work — the same email across two contacts, the same company domain across two accounts — so the candidates come to you instead of hiding in a list nobody scrolls. You confirm the real matches and merge them into a single contact whose timeline holds every note, task, and deal from both, so the relationship's history reassembles instead of scattering. Because lifecycle stage and lead score are derived from real activity on the record, a merged contact immediately reflects the combined history — and your reports stop double-counting one customer as two. Keeping the database deduped is what keeps every number built on top of it — pipeline coverage, win rate, contact totals — honest.
The one-sentence version
Duplicates are created at the point of entry and quietly corrupt every report and relationship built on top of them, so you fix them by matching on a stable key rather than a name (email for people, domain for companies), letting the system surface candidates for a human to confirm, merging rather than deleting so no note or deal is lost, and then closing the doors — check at entry, dedupe every import, scan monthly — so the cleanup you just did stays done.