Dedupe a messy contact list

Built by: Lusha
Time to build: 1 min
Difficulty: Easy
Tools: Claude ▪ Lusha
Type: Prompt

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

Open in Claude Open in ChatGPT 
<context>
Contact list with duplicates: different rows represent the same person captured
at different times, in different systems, with different fields.
Collapse to one verified row per unique person.
</context>

<task>
1. Merged contact list (one row per line, whatever fields each row carries):
   [PASTE LIST]
2. Identify duplicates by matching on:
   email (strongest signal),
   LinkedIn URL (strongest after email),
   name + company combination,
   name + LinkedIn URL where company is unclear.
3. For each unique person, resolve the canonical record via Lusha:
   current company and title,
   validated email with confidence grade,
   validated phone with DNC status,
   job start date.
4. Collapse duplicate rows into one verified row. Where input fields conflict,
   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. Summary at the top: 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.

PersonVerified companyVerified titleRows mergedConflict resolved
Brian R.[Cloud data platform]Chief Financial Officer2Two emails on file: kept the cloud data platform address, flagged board email as alternate
Tori M.[Productivity SaaS]Global Head of Revenue Operations2Partial-data row merged with full-data row
Namrata R.[AI infrastructure SaaS]VP of Revenue Strategy and Operations2Two companies on file: the productivity SaaS was previous, the AI infrastructure SaaS is current (since Jan 2025)
Laura F.[Dev workflow SaaS]Head of Revenue Operations and Strategy1None (unique row, no duplicate)
Tyler W.——1No match: kept input, flagged for re-research

Names and company identifiers abbreviated for privacy. Full records (including company names, 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 her previous company, one at her current company. The prompt did not pick the wrong one or duplicate the contact. Lusha’s current employer is the source of truth, so the previous-company row collapsed into the current-company 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 two rows representing the same person 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 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.

Related Prompts

Ready to run this?

One data connection. Works in Claude, ChatGPT, your CRM, or any agent you build.

Get free access Read the Docs