How to Match an Apollo, ZoomInfo, or LinkedIn Sales Nav List Against Your CRM (Before You Import)

Every quarter, an SDR pulls a fresh list out of Apollo, ZoomInfo, or LinkedIn Sales Navigator. It matches the ICP, the titles look right, and the plan is to import it into Salesforce or HubSpot on Monday.

Then Monday happens. The AE assigned to Acme Corp gets an alert that an SDR just enrolled her account in an outbound cadence. A closed-won customer receives a "have you considered our product?" email. Duplicate accounts pile up because "Acme, Inc." in the import doesn't quite match "Acme Corporation" in Salesforce. The RevOps lead spends the rest of the week firefighting.

The fix isn't better native duplicate rules — those aren't going to catch fuzzy company name variations any time soon. The fix is a pre-import pass with fuzzy matching that segments the prospect list into what's safe to import and what isn't.

Why Prospecting Lists Overlap With Your CRM

Apollo, ZoomInfo, and LinkedIn Sales Navigator all work off giant contact and company databases. When your SDR builds a list matching "SaaS companies, 50-500 employees, engineering leaders in the US," the tool returns everyone in its universe who matches. That set will include:

• Companies your AEs are already working (open opportunities)
• Companies that are current customers
• Companies you've marketed to for years (existing MQL/SQL history)
• Prior evaluators who went dark or churned
• Genuinely net-new companies you've never touched

The first four groups are the ones you don't want SDRs cold-emailing. The fifth is the whole point of the exercise. On the average B2B sales org, 20-35% of any freshly-pulled prospecting list falls into groups 1-4.

Why Native CRM Duplicate Detection Doesn't Save You

Salesforce, HubSpot, and every other CRM has a duplicate rule engine. On paper, it should catch this. In practice, it catches exact matches and misses the interesting cases:

• Different company name spellings. Apollo returns "Acme, Inc." Your CRM says "Acme Corporation." Duplicate rules that require exact name match ignore these.
• Personal vs corporate email. ZoomInfo has jane.smith@acme.com. Your CRM has jsmith@acme.com. Native rules match on email exactness — they miss.
• Nickname vs formal name. LinkedIn shows "Bob Smith, VP Engineering." Your CRM has "Robert Smith, VP Engineering." Same person, different first name.
• Contact at a subsidiary. Apollo says the contact works at "Acme Cloud." Your CRM has them under the parent "Acme Corporation." Native rules don't collapse those.
• Rebrands and re-orgs. The company renamed last year. Apollo has the new name; your CRM still has the old.

None of those are edge cases. All of them are common. That's why RevOps teams end up doing pre-import matching outside the CRM.

The Approach: Two Passes, Account First Then Contact

The workflow that works is a two-pass fuzzy match:

1. Pass 1 — Account match. Compare each prospect's company to your existing Accounts (or Companies) in the CRM. Flag matches as "existing account."
2. Pass 2 — Contact match. For the prospects whose company is a match, additionally check whether the person is already a Contact/Lead on that account.

This gives you three clean buckets by the end:

• Existing contact on existing account — do not import.
• New contact at existing account — check with the account owner before enrolling in outbound.
• New contact at new account — safe to import into net-new outbound.

Step 1: Export Both Lists to CSV

Export from Apollo / ZoomInfo / LinkedIn

Whichever prospecting tool you're using, export the list you want to import. Standardize on these columns before matching:

• first_name
• last_name
• title
• email
• company_name
• company_domain — critical. If Apollo/ZoomInfo doesn't export it directly, derive it from the email domain.
• country
• employee_count or company_size

LinkedIn Sales Navigator exports are the messiest because Sales Nav doesn't officially support bulk export — most teams use a third-party tool (Evaboot, Wiza, Bardeen) or the Recruiter data export. Whatever you use, land the same columns.

Export from your CRM

Two exports:

1. Accounts (or Companies in HubSpot): account_id, account_name, domain (or website), country, owner, type (Customer / Prospect / Partner), lifecycle_stage.
2. Contacts + Leads: contact_id, account_id, first_name, last_name, email, title, status.

Include closed-lost and dormant contacts. The whole point is to catch prospects who have any prior history.

Step 2: Match Accounts First

Upload both files to a fuzzy matching tool. On the left: your prospecting export. On the right: your CRM Accounts. Configure the match like this:

Set match mode to company so the matcher normalizes legal suffixes (Inc, Corp, GmbH, Ltd, Pty Ltd, etc.) and handles common abbreviations.

Run the match. Every prospect row now has a best-guess CRM account plus a similarity score. In practice:

• Score 90+: Same company. Merge with the CRM account.
• Score 75-90: Very likely same company. Worth reviewing — parent/subsidiary or rebrand cases live here.
• Score below 75: Different company. Prospect is net-new.

Step 3: Filter by CRM Account Status

Now that you know which prospects overlap with existing accounts, apply your routing rules. A typical split:

The routing table is where RevOps earns its keep. It's worth codifying it once, sharing with sales leadership, and applying it programmatically to every list import going forward.

Step 4: Match Contacts (Second Pass)

For prospects whose company matched an existing account, run a second, narrower fuzzy match: person against the existing contacts/leads at that account.

Configuration:

• Email domain match as a hard filter — only compare against contacts whose email domain matches the prospect's.
• Last name (40%) — strongest signal. Casing and spelling variants get normalized.
• First name (30%) — use a mode that handles nicknames (Bob = Robert, Liz = Elizabeth, etc.) if the tool supports it.
• Title (30%) — helper for common names ("John Smith" appears twice at one company — is it the CTO or the CFO?).

Prospects with a contact-side match score of 85+ are already in the CRM; skip them. Prospects with a score below 85 are new contacts at an existing account — route them per the table above.

Step 5: Prepare the Import File

At this point the original prospecting list is split into three CSVs:

1. do_not_import.csv — existing customer contacts, do-not-touch. Keep for audit.
2. route_to_owner.csv — new contacts at existing accounts. Send to the account owner with the source (Apollo / ZoomInfo / LinkedIn) noted. Owner decides.
3. net_new_import.csv — safe for outbound. Import to CRM, route to SDR queue.

Only net_new_import.csv goes through the normal import path. The other two either get filed away or handed to specific owners.

One important detail: for the route_to_owner.csv file, include the matched CRM account ID alongside each prospect. When the owner decides to add the contact, they can attach it directly to the existing account without creating a duplicate. This one column saves hours of cleanup later.

How Often to Do This

Every prospect list before it hits the CRM. That's the rule.

SDRs typically pull lists weekly or biweekly. A pre-import fuzzy match on each one takes 15-20 minutes once the workflow is set up. That's a small tax to avoid the two much larger costs it prevents: cold-emailing customers, and cleaning up duplicate accounts every quarter.

Some RevOps teams automate this end-to-end — a Zapier/Make/n8n flow that watches a Google Drive folder for new prospect CSVs, runs them through the fuzzy matcher, and drops the split files into three destination folders. Whether you automate it or run it manually, the same principle applies: the list gets matched before it gets imported.

Common Mistakes to Avoid

Trusting the CRM to catch it. If your team's plan is "import it, and Salesforce duplicate rules will flag anything." that's the plan that leads to a marketing incident. Native rules only catch exact matches. Fuzzy matching outside the CRM is the only reliable safeguard.

Matching only on company name. Company names are noisy. Domains are structured. Anchor the match on domain first, name second — not the other way around.

Forgetting closed-lost. A prospect who went dark 8 months ago is not a net-new lead. Include closed-lost opportunities and dormant leads in the CRM-side export.

Assuming personal emails imply new contacts. If Apollo returns jane.smith@gmail.com and your CRM has jsmith@acme.com for the same "Jane Smith, VP Engineering" at Acme — that's the same person. Match on name + title + company, not just email.

Not saving the "matched" CSV. The do_not_import.csv and route_to_owner.csv files are your audit trail. Save them. Next quarter, when someone asks "why aren't we outbounding Acme?" you can show them.

Bottom Line

Prospecting tools return the whole universe of ICP-matching contacts — and that universe overlaps heavily with anyone your team has ever talked to. Native CRM duplicate detection catches maybe 30% of the overlap. The other 70% either creates a duplicate account or drops a customer into a cold outbound cadence.

A 20-minute fuzzy match before import fixes it. Match domain + name for accounts. Match name + email domain + title for contacts. Split the list into three buckets and route each one correctly. That's the difference between a growing pipeline and a Monday morning apology email.

Related Reading

• Deduplicate a Contact List Before Importing Into Your CRM
• Match Tradeshow Attendee Lists Against Your CRM
• Find and Merge Duplicate Accounts in Salesforce