Dedupe a messy contact list
A Claude prompt that takes overlapping contact lists — webinar exports stacked on event scans stacked on a CRM dump — and collapses them to one verified row per person. Claude handles the matching across versions. Lusha provides the canonical truth that picks which version is right.
Once Lusha is connected in Claude, the connector runs in the background — no special syntax needed. Just paste the merged list and run.
Images on this webpage are for illustrative purposes only. Any named individuals shown in live demo outputs are real, with last names abbreviated for privacy.
The prompt
<context>
I have a contact list with duplicates. Different rows represent the same person captured at different times, in different systems, with different fields. I want to collapse to one verified row per unique person.
</context>
<task>
1. Take this merged contact list (one row per line, with whatever fields each row carries):
[PASTE LIST]
2. Identify duplicates across the rows by matching on:
- Email address (strongest signal)
- LinkedIn URL (strongest after email)
- Name + company combination
- Name + LinkedIn URL where the company is unclear
3. For each unique person, use Lusha to resolve the canonical record:
- Current company and title
- Validated email with confidence grade
- Validated phone with DNC status
- Job start date
4. Collapse all duplicate rows for that person into one verified row. Where input fields conflict (e.g., two different companies on file), Lusha's current employer is the source of truth.
5. Output a deduplicated table:
Name | Current company | Current title | Email | Phone | Number of input rows merged | Conflicts resolved
6. Surface a one-line summary: total input rows, total unique people, total no-matches.
</task>
<constraints>
- Same name at two different companies is two different people — do not merge by name alone.
- If Lusha returns no current record for a unique person, keep the best-available input fields and flag as no-match.
- When two input rows show the same person at different companies, the row whose company matches Lusha's current employer is correct. Flag the other row as stale.
- Do not invent fields. The deduplicated row uses verified data from Lusha or input fields, never guesses.
</constraints>What you'll get back
Input: 8-row merged contact list. Same person appears multiple times in three cases (one with conflicting employer info, one with partial data, one with old vs current company). Two rows are unique. One row is designed to fail to match.
Output: 8 input rows collapsed to 5 unique people. 4 successfully resolved against Lusha. 1 no-match. Below is the real result from running the prompt against the live Lusha connector.
| Person | Verified company | Verified title | Rows merged | Conflict resolved |
|---|---|---|---|---|
| Brian R. | Snowflake | Chief Financial Officer | 2 | Two emails on file — kept Snowflake address, flagged board email as alternate |
| Tori M. | Notion | Global Head of Revenue Operations | 2 | Partial-data row merged with full-data row |
| Namrata R. | Together AI | VP of Revenue Strategy and Operations | 2 | Two companies on file — Notion was previous, Together AI is current (since Jan 2025) |
| Laura F. | DevRev | Head of Revenue Operations and Strategy | 1 | None (unique row, no duplicate) |
| Tyler W. | — | — | 1 | No match — kept input, flagged for re-research |
Names abbreviated for privacy. Full records — including emails and direct dials — are returned inside your Claude session.
The Namrata row is the most useful demonstration. Two input rows showed two different employers — one at Notion (old), one at Together AI (current). The prompt did not pick the wrong one or duplicate the contact. Lusha’s current employer is the source of truth, so the Notion row collapsed into the Together AI row with a “stale” flag.
Why use Lusha
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 “Tori Moss / Notion” and “Tori Moss / —” 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 actually works at right 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 manually re-research or archive deliberately. Data drawn from 300M+ verified contacts under GDPR, CCPA, SOC 2, ISO 27701, ISO 31700, and TRUSTe.
FAQ
How does the prompt know two rows are the same person?
The match cascade runs strongest signal first. Same email — same person. Same LinkedIn URL — same person. Same name plus same company — same person. Same name only — flagged for manual confirmation, never auto-merged. The prompt explains its match reasoning per merge so the user can spot-check.
What if I have the same person at two companies?
That’s the most common real-world case. One row is current, one is stale. Lusha’s current employer is the source of truth. The prompt keeps the current row, flags the stale row, and shows the conflict so the user understands what was resolved.
How many rows can the prompt handle?
A few hundred works cleanly in one session. For larger merges (1,000+ rows), batch by segment or owner. Lusha credits scale linearly — one credit per successful canonical lookup, no charge for no-matches.
Does the prompt preserve any fields from the dropped rows?
When a dropped row had a field the verified row doesn’t (a personal note, a custom tag, a campaign source), the prompt surfaces it on the merged row as supplementary input. The verified contact fields take precedence; the supplementary fields ride along for context.
What about contacts who never matched anything?
No-match rows stay in the deduplicated list, flagged. Three common causes — the contact left the workforce, the input data was malformed, or the company name needs disambiguation. The user reviews the flagged rows separately and either re-searches manually or archives.
Is this the right prompt for cleaning a single CRM export?
If the export came from one system at one point in time, the CRM hygiene prompt is the better fit — it focuses on decay rather than merge. Use the dedupe prompt when the input is a stack of overlapping captures from multiple sources.
Ready to build this?
Get started with Lusha and set up this play in minutes.
