Dedupe is two problems pretending to be one. Three things change when the matching layer and the truth layer are separated cleanly.
Claude handles the matching across rows. Fuzzy name comparison, LinkedIn URL canonicalization, email normalization, partial-data handling — all the work of recognizing that two rows under different spellings or partial data probably refer to the same person. That logic lives in language, not in a SQL join.
Lusha resolves which version is the truth. When two rows describe the same person at different employers, the matching layer can’t pick between them. The truth layer can, because Lusha knows which company that person works at now. Without verified data, the dedupe quietly keeps the wrong row half the time.
No-match rows stay in the output, flagged. A row Lusha cannot resolve doesn’t get silently dropped. It stays in the deduplicated list with a no-match flag, so the rep can re-research or archive it deliberately rather than discovering the gap later.
Data drawn from 515M+ verified contacts, sourced and processed under GDPR, CCPA, SOC 2 Type II, ISO 27001, ISO 27701, and TRUSTe Responsible AI. Full detail in the Trust Center and privacy notice.
FAQ
How do I dedupe a contact list with data from several sources?
Match first, then resolve. Matching is the language problem — recognising that “Rob Smith, Acme” and “Robert Smith, Acme Corp” are one person despite different spellings and partial fields. Resolving is the data problem — deciding which row is current when the two disagree about employer or title. Doing only the first leaves you with a clean-looking list built on whichever row happened to sort first.
How many credits does deduping a list cost?
1 credit per batch of up to 25 unique people. A 500-row list collapsing to 300 unique people costs 12, since you pay per person resolved rather than per input row. Revealing contact details is separate at 1 credit per email and 5 per phone. Deduping before enriching is what keeps that second number down.
What if the same person appears at two different companies?
That is the case worth running this for. Two rows showing different employers usually means one is stale rather than that there are two people. Lusha’s current employer decides it: the row matching the current company is kept, the other is flagged stale rather than merged blindly or kept as a second contact.
How does the prompt avoid merging two different people with the same name?
Name alone is never sufficient, and the constraints state that explicitly. Matching runs on email first, then LinkedIn URL, then name plus company. Two people with the same name at different companies stay separate rows. The risk with name-only matching is not just a merged record — it is a merged record with one person’s email and another’s phone number.
What happens to contacts that never matched anything?
They stay in the output with a no-match flag rather than being dropped. A silently removed row is worse than a flagged one, because nobody knows to go looking for it. Before re-researching, check the company name on those rows — a misspelling is a more common cause than a genuine coverage gap.
Is this the right prompt for cleaning a single CRM export?
Not quite. This one is built for overlapping lists from different sources. For a single export where the problem is decay rather than duplication, refresh stale CRM records is the better fit — it re-verifies each row against live data rather than collapsing rows together. Run dedupe first if the export has duplicates, then refresh.
