---
title: "Two recruiters, one candidate: the duplicate problem"
description: Matching on email alone misses most duplicates in a recruitment database. What to match on instead, when to merge, and what a merge must never destroy.
---

[Echo Recruit blog](https://www.echorecruit.com/blog)

# [Two recruiters, one candidate: the duplicate problem](https://www.echorecruit.com/blog/two-recruiters-one-candidate-the-duplicate-problem)

 Written by [Echo Recruit](https://www.echorecruit.com/blog/author/echo-recruit) | Oct 13, 2026, 5:39:32 AM

*The candidate has been called twice this week by the same agency about the same job, and both recruiters think they sourced them.*

In short

- Email-only matching catches the easy duplicates and misses the ones that embarrass you, because people change employers and use a different address each time.
- Detect at the moment of entry, not in a monthly clean-up. A duplicate is cheap to prevent and expensive to unpick.
- Merging is destructive. Decide in advance what survives — history, consent, and ownership are the three that get lost.
- Some duplicates should not be merged at all. Two people genuinely share a name, and merging them is a data breach in slow motion.

Every recruitment database has duplicates, and the reason is structural rather than careless. The same person applies through a job link in 2023, is sourced by a different recruiter in 2025, gets imported in a spreadsheet from a colleague who left, and forwards their CV from a new work address after changing jobs. Four records, one human.

The visible cost is the double approach: two people from your agency contacting the same candidate about the same role, which makes the agency look chaotic and the candidate feel like a lead. The invisible costs are worse. Your pool is smaller than your count says. A candidate who opted out on one record still gets mail on another. And the placement history that would have told you this person is a strong closer sits on a record nobody opened.

## Why email-only matching is not enough

Most systems deduplicate on email address. It is the obvious key: unique, cheap to compare, usually present.

It also misses the majority of real duplicates in a recruitment context, for a reason specific to this industry. **Candidates change jobs** — that is the entire premise of the business — and when they do, the work address on their old record stops working and the new record arrives under a different one. The single most important event in your relationship with a candidate is precisely the event that breaks your matching key.

Then there are the ordinary variations: a personal Gmail on the application and a work address on the CV, plus-addressing, a typo in a manual entry, an apostrophe in a surname handled differently by two systems.

## What to match on instead

Do not look for one perfect key. Score several weak signals and use the total to decide between three outcomes: merge automatically, flag for a human, or do nothing.

 A workable matching scheme

| Exact email match normalised: lowercased, plus-addressing and dots stripped | Conclusive |
| --- | --- |
| Mobile number match normalised to international format | Conclusive |
| LinkedIn or portfolio URL match | Conclusive |
| Same name + same current employer | Strong |
| Same name + an overlapping past employer and date range | Strong |
| Same name + same city | Weak |
| Rule | One conclusive, or two strong |

Name alone is never enough, in any combination, and name plus city is not either — see the section below on why.

The employment-history signal is the one most systems skip and the one that does the real work here, because it survives the job change that breaks the email.

## Catch it at entry

The cost of a duplicate rises steeply with age. Caught at the moment of creation, it is one dialog and five seconds. Caught six months later, two recruiters have logged activity against different records, both have notes, one has a consent record and the other does not, and unpicking it is genuine work that somebody has to be paid to do.

So the check belongs at every point a record can be created — the application form, manual entry, CV import, bulk upload from a spreadsheet — and not in a monthly hygiene job. Monthly clean-ups are how you find out the problem is large; they are not how you fix it.

For the application form specifically, the behaviour matters. A candidate applying again should not be told “you already exist” — that is your internal problem, not theirs, and it reads as a rejection. Accept the application, attach it to the existing person, and let the duplicate handling happen behind the screen.

## Merging destroys things. Decide which.

A merge is not a tidy-up; it is a deletion with a survivor. Three things routinely get lost, and each has a consequence:

1. **1History**Applications, stage transitions, evaluations and notes on the losing record. These must move, not vanish. A candidate who reached final interview in 2024 and whose record was later merged should still show that they reached final interview — otherwise you have quietly deleted the evidence behind a past decision, which is exactly the record you would need if that decision were ever questioned.
2. **2Consent and opt-out**The rule is one-way and worth hard-coding: **an opt-out on either record survives the merge.** If one record says do not contact and the other does not, the merged record says do not contact. Getting this backwards means a merge silently re-subscribes someone who asked you to stop, which is the kind of error that turns into a complaint rather than a tidy-up.
3. **3Ownership**Two recruiters, one commission question. Decide the rule in advance and write it into the comp plan — earliest verifiable contact, or most recent meaningful activity, are both defensible; deciding case by case is not. If the merge tool silently picks a winner, your commission policy is being set by a default nobody chose.

Keep merges reversible for a period, and keep a record that the merge happened. Somebody will merge two genuinely different people, and the only thing worse than that mistake is having no way to see it was made.

## The duplicates you must not merge

Two people share a name more often than intuition suggests, and in some naming traditions considerably more often. Match on name plus city and you will eventually combine two real, unrelated people into one record.

Take that seriously, because it is not a data-quality issue. You would be showing one person's salary expectation, CV, interview feedback and recruiter notes to anyone who opens the other person's file — and if either ever asks what you hold about them, you would hand over a file containing a stranger's employment history. That is a personal data incident, not a merge error.

Which is why the rule above is one conclusive signal or two strong ones, and why name-based matches go to a human rather than to an automatic merge. The asymmetry is deliberate: a missed duplicate costs you an awkward phone call, and a wrong merge costs you considerably more.

In Echo Recruit

Duplicates surface before the second phone call

Applications deduplicate against the existing pool on arrival rather than in a monthly sweep, and potential duplicates surface on the desk before two recruiters ring the same person about the same role. Candidate evaluations are append-only and status transitions are recorded, so history moves with a record rather than being overwritten — a candidate who reached final interview still shows that they did.

## Common questions

Why isn't matching on email enough to find duplicate candidates?

Because candidates change jobs — that is the premise of the business — and when they do, the work address on the old record stops working and the new record arrives under a different one. The single most important event in your relationship with a candidate is precisely the event that breaks your matching key.

What should you match candidate records on?

Score several weak signals rather than seeking one perfect key. Conclusive: normalised email, normalised mobile number, or a LinkedIn or portfolio URL. Strong: same name plus same current employer, or same name plus an overlapping past employer and date range. Weak: same name plus same city. The rule is one conclusive signal, or two strong ones.

What must a candidate record merge never destroy?

Three things. History — applications, stage transitions and evaluations must move, not vanish. Consent — an opt-out on either record survives the merge, always. And ownership — decide the commission rule in advance, because if the merge tool silently picks a winner, your comp policy is being set by a default nobody chose.

[View full post](https://www.echorecruit.com/blog/two-recruiters-one-candidate-the-duplicate-problem)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Echo Recruit"
  },
  "dateModified" : "2026-10-13T05:39:32.790Z",
  "datePublished" : "2026-10-13T05:39:32Z",
  "headline" : "Two recruiters, one candidate: the duplicate problem",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://www.echorecruit.com/blog/two-recruiters-one-candidate-the-duplicate-problem",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60.0,
      "url" : "https://www.echorecruit.com/hubfs/echo-recruit-avatar-green-400.png",
      "width" : 60.000004
    },
    "name" : "Echo Recruit blog"
  }
}
```