# Dedupe
Dedupe, short for deduplication, is the process of identifying and removing duplicate prospect records across lists, campaigns, and sources so the same person never receives the same message twice from the same team. It sounds trivial. It is one of the harder operational problems in outbound at scale. The cost of getting it wrong shows up in two ways, duplicate sends that annoy the prospect, and overlapping campaigns that compete for the same buyer's attention from the same company.
The mechanics are harder than they look because the same human appears under many identifiers. The email address at the previous company. The current email at the new company. A personal Gmail used in a webinar signup. The LinkedIn URL that is the only thing stable across all of them. Without a deliberate identity resolution layer, each of these records looks like a different prospect, and the team's outbound system happily sends the same person three messages from three campaigns.
Why it matters
The most visible cost of poor dedup is the angry reply. A senior buyer who receives three slightly different cold emails from the same vendor in a week will reply once, and the reply will not be positive. The buyer will assume the vendor is running aggressive automation without the discipline to manage it. The reputational damage outlasts the campaign.
The less visible cost is the dilution of reply rate data. If the same prospect is in three campaigns, the reply they send to one campaign does not flow back to suppress the other two. The team optimizes the wrong campaign. The data drifts.
The third cost is internal, multiple reps working the same accounts without realizing it. RevOps teams in mid-size companies regularly discover that two SDRs were both prospecting the same Fortune 500 account from different angles, with neither aware of the other. The handoff is messy and the buyer's perception is worse than if neither rep had reached out.
For agent-driven outbound, dedup becomes more important rather than less, because the agent can move faster than a human at building overlapping lists. Without strong dedup enforcement, the agent will efficiently produce a duplicate-send fire.
Common pitfalls
The first is treating dedup as a list-build step rather than a send-time step. A list deduplicated on Monday is no longer deduplicated by Friday after another list was added. The right pattern is dedup at the moment of send, against the team's full historical contact record, not just against the current campaign.
The second is using email as the primary key. Email is the most common dedup field in outbound tools by default. Email changes with each job change. The same person at a new company appears as a new record. The team sends. The prospect notices.
The third is missing the suppression-list integration. A prospect who unsubscribed last quarter or marked an earlier message as spam should be suppressed across all future campaigns. Without a global suppression list that all campaigns check, the same prospect gets re-touched indefinitely. This is also a CAN-SPAM compliance issue, not just a politeness issue.
The fourth is over-suppressing. A prospect who replied "not now, ask me in six months" should not be in the same suppression bucket as a hostile unsubscribe. A useful dedup system carries a state per prospect (open, contacted, replied, not-interested, hard-suppress, do-not-contact) rather than a binary include/exclude.
How it shows up in agent-driven workflows
In Coil specifically, dedup runs at the org level across all campaigns, sources, and historical contacts. The data model carries a stable contact identity (LinkedIn URL where available, falling back to email, then to fuzzy name+company match) and every send is checked against the org's full contact history.
For agent-driven outbound, this matters because an agent building a list will produce duplicates relative to manual lists the team built last quarter. The agent does not know what the previous lists contained. The platform does. Dedup at the platform level catches this without the agent having to be aware of it.
The pattern that does not work is asking the agent to handle dedup in-prompt. Models are not reliable at multi-step identity resolution across thousands of records. The right division is structured dedup in the platform, free-form judgment in the agent.
The other useful dedup pattern is cross-rep awareness in multi-user organizations. A team where multiple reps share an org should see when a prospect is already in another rep's campaign, with the option to defer or coordinate. The members API surfaces this at the org level so an agent acting on behalf of one rep does not step on another rep's work.
Related concepts
Lead enrichment introduces the duplicate problem at scale, running multiple providers produces overlapping records that must be deduplicated.
ICP determines which records belong in the team's working set. Records outside ICP can be dropped rather than deduplicated.
Cold outreach is the activity that fails most visibly when dedup is broken. Reply rate hides it. Angry replies expose it.
RevOps is the function that typically owns dedup policy and tooling. In smaller teams the founder owns it whether they want to or not.
For Coil's specific dedup behavior across prospect and Sales Nav scrapes, see the relevant product pages.
Frequently asked questions
Why is dedupe so hard?
Because the same person appears under different identifiers across sources. The email at company A from three years ago. The current email at company B. The LinkedIn URL that is stable across both jobs. The personal email used in a webinar signup. Without a strong identity resolution layer, all of these look like different records.
What is the right primary key for dedup?
LinkedIn URL is the most stable identifier for senior B2B contacts because people maintain it across job changes. Email is unreliable because it changes with each job. Phone numbers are stable but rarely available. The pragmatic approach is multi-key: match on LinkedIn first, then email, then phone, then fuzzy name+company.
How often should dedup run?
Before every send, every time. Lists drift between when they were built and when they are used. New prospects added today may overlap with prospects added last week. Running dedup as a one-time cleanup step at list-build time leaves leakage that compounds over months.