Nobody notices duplicate contacts on import day. The import succeeds, the count looks right, and everyone moves on. The problem surfaces three weeks later, when two salespeople email the same person about the same thing, or when a report says you generated four hundred leads at a show where you had two hundred and forty conversations.
By then the duplicates have picked up activity history, and merging records that both have emails, tasks and notes attached is a genuinely unpleasant job. It is much cheaper to prevent this in the twenty minutes before the import than to fix it afterwards.
Why events specifically produce duplicates
Ordinary lead flow produces the occasional duplicate. Events produce them in bulk, for four reasons that all happen at once.
The third one is the most overlooked. A meaningful share of the people who visit your stand are already somewhere in your database, because they attended a webinar or downloaded a guide at some point. Your event import does not know that, so it creates a second record with a different email address or a slightly different name, and now the person has two histories.
The fourth is self-inflicted and avoidable. If you rented lead retrieval, you will receive an organiser export containing everyone whose badge was scanned. Importing it on top of your own captures without reconciling first guarantees duplicates, and we covered why that file needs treating as a supplement rather than a source of truth in what lead retrieval actually costs.
Why matching on name always fails
The instinct when deduplicating is to match on name, because that is what a human would do. It is the least reliable key available to you, and it fails in both directions.
It misses real duplicates. The same person appears as Rajesh Kumar, Raj Kumar, R. Kumar and Rajesh Kumar with a trailing space, depending on whether the source was a card, a badge, a registration form or somebody typing. All four are different strings. None of them match.
It merges different people. Any organisation of reasonable size has two people with the same common name. Merging those two records is far worse than leaving a duplicate, because it is silent, and you will not discover it until somebody has a very confusing conversation.
Email is the right key, and it is not perfect
Email works because it is unique by construction. It still has three failure modes worth knowing before you rely on it.
Generic company addresses. Cards frequently print info@ or sales@ rather than a personal address. If three people from one company give you cards with the same generic address, email matching will merge three different humans into one record. Treat any address starting info, sales, contact, hello or admin as not a person, and keep those records separate on the strength of the name.
The same person, two addresses. Somebody registered with a personal Gmail and hands you a card with their work address. Email matching sees two people. This is the residual duplicate rate you cannot design away, and it is small enough to live with.
Transcription errors. A misread character in an email address creates a record that will never match anything and will bounce on first send. This is where a confidence score on the extracted field earns its keep: it tells you which addresses to check rather than asking you to re-read all two hundred.
What each CRM actually does
Import behaviour differs by platform in ways that matter, and vendors change it without announcement, so verify against current documentation before an import that matters.
HubSpot deduplicates imports on email address, which means a row without an email is a guaranteed new record. Hublead’s write-up on finding and preventing HubSpot duplicates names messy CSV imports as one of the largest sources, which matches what event lists look like. The practical consequence: never import an event list with blank email cells.
Salesforce is the one that catches people out. Its documentation on contact and lead imports notes that duplicate leads are identified by name matching during import, which is precisely the key that fails on event data. If you are importing leads rather than contacts, assume the native check will not save you and deduplicate before upload.
Zoho lets you nominate the matching field during import and will skip, update or clone accordingly. That is more control than the others give you and more rope. Set it to match on email and choose update rather than clone, then run a small test batch first.
Our own column mappings for each are on the HubSpot, Zoho and Salesforce guides.
The pre-import checklist
Twenty minutes in a spreadsheet, before anything touches the CRM. In this order, because each step makes the next one work.
Step four deserves a note. When you find two rows for one person, the instinct is to keep the first. Keep the richer one instead: the row that has the voice note transcript, the job title and the event tag, even if it came second. Then copy anything unique from the discarded row into it rather than deleting outright.
Do all of this in a spreadsheet rather than in the CRM. A CSV is reversible and a bad import is not, and the twenty minutes you spend here is the cheapest twenty minutes in the entire event process.
When the duplicates already exist
If you are reading this after the import, the order of operations is different and the priority is stopping the bleeding rather than achieving a perfect database.
First, stop outbound on the affected segment. The immediate risk is two salespeople contacting the same person. That does more damage than the messy data does.
Second, merge rather than delete. Every major CRM has a merge function that preserves activity history from both records. Deleting the duplicate loses whatever emails and notes were attached to it, and somebody will need those in three months.
Third, work by recency. Merge the records created in the last month, which are the ones actively being worked. Historic duplicates are ugly and mostly harmless, and chasing them all is how a cleanup project stalls and never finishes.
Fourth, write down what caused it. If it was the organiser file, note that. If it was two reps capturing separately, note that too. The same show happens next year and the same cause will produce the same result unless somebody recorded it, which is a theme of the booth checklist.
The duplicate you cannot see: one person, two companies
There is a second class of duplicate that email matching will not catch, and it distorts reporting rather than outreach. The same human appears twice because they changed employer between two of your events.
This is genuinely two valid records, so merging them is wrong. But if your reporting counts unique people, they will be counted twice, and if a salesperson opens the older record they will call a company the person left eighteen months ago.
The practical handling is to link rather than merge. Most CRMs support relating records or marking one as former. What matters is that the older record shows plainly that it is historic, so nobody works it by accident. Do not delete it: the history of what that person cared about at their previous employer is frequently the most useful thing you know about them.
You will spot these during deduplication because the name and phone match while the company and email do not. That combination is almost always a job change rather than two people, and it is worth a thirty-second check rather than an automatic rule, because occasionally it is genuinely two people with a common name.
Preventing it at capture rather than at import
Everything above is remedial. The cheaper intervention is upstream, at the moment of capture, and it costs nothing to implement.
Have every capture land in one shared list rather than in individual phones. A duplicate is then visible at the booth, on the same day, when whoever captured it can simply say that they already have that person. Five separate phones make the duplicate invisible until it reaches the CRM, which is the worst possible place to discover it.
Second, capture the email address as a priority field rather than an optional one. If a card has no email, the person who took it is the only human who will ever be able to supply one, and they can do it in ten seconds while the conversation is still happening. Once they have left the hall, a row without an email is permanently a row without an email.
Third, run the same event tag across every staff member from the start of the day. Tags typed individually diverge within an hour, and a list carrying four spellings of one event name cannot be deduplicated by event or reported on afterwards.
The short version
Events produce duplicates in bulk because several staff capture the same visitors, badges and cards double up, many attendees are already in your database, and the organiser file lands on top. Deduplicate on email, never on name, and treat generic addresses as not-people. Normalise case and whitespace before matching. Keep the richest row rather than the first. Verify the event tag survives, or you lose the ability to measure the show at all.
And do it in a spreadsheet, before the import. The twenty minutes there replaces a merge job later that nobody wants and that always takes longer than anyone expects. If you want the export to arrive already carrying the voice transcript and event tag as columns, the CSV export is built for exactly that, and 20 free scans is enough to try it on one show.