Stop paying twice for the same candidate

Matching runs in layers. An exact match on a normalised email address or a phone number reduced to its international form is treated as near-certain. Below that, a fuzzy comparison of name variants, current and previous employer, education and the shingled text of the resume produces a confidence score.

Name matching alone is deliberately weak evidence. There are a great many people called David Smith, and a system that merges on name will destroy records. The score only becomes actionable when two independent weak signals agree, such as a matching employer history and a matching resume fingerprint.

The asymmetry in the scoring is intentional and it is worth understanding before you tune it. A missed duplicate costs you an awkward second phone call and a record that has to be merged later. A wrong merge silently combines two people, and the damage shows up months afterwards in a submittal to a client with somebody else's career history attached. The defaults are set to make the first mistake rather than the second, and that is the trade a conservative threshold is buying.

When a recruiter adds a candidate manually, a likely duplicate is shown before the record is created, with the two profiles side by side and the differences highlighted. The recruiter can open the existing record, merge the new information into it, or confirm that these really are two different people.

Bulk imports run the same check. The import preview reports how many rows matched existing records, and lets you decide once for the whole file: skip, merge into the existing record, or create anyway and flag for review. That decision is recorded against the import so the choice can be audited later.

Entry time is the only moment when the decision is cheap. The person adding the record has the resume open, remembers the conversation, and can tell in two seconds whether the David Smith already in the system is the one they just spoke to. A month later that context is gone, and the same decision takes ten minutes of reading two activity streams. That is why a monthly clean-up never actually happens: the work grows and the information needed to do it shrinks.

A merge is designed to keep both activity streams. Emails, calls, notes, submittals, interviews and stage changes from both records land on the surviving profile in chronological order, each still attributed to the recruiter who logged it.

Field conflicts are resolved explicitly rather than by last-write-wins. Where two records disagree on current employer or salary expectation, the merge screen shows both values and asks. The discarded value is kept in the merge record, so a bad merge can be understood and, within a retention window, reversed.

Silent field resolution is where most merge tools do their quiet damage. Taking the most recently updated value looks sensible until the most recently updated record is the thin one a sourcer created from a public profile, and the salary expectation the candidate actually stated in a conversation eight months ago is overwritten by a blank or a guess. Asking is slower by a few seconds per conflict and it is the difference between a merge that improves a record and one that degrades it.

In an agency, the question behind most duplicates is who owns the candidate. The merge preserves the earliest genuine first-contact event and its owner, rather than whichever record happened to survive.

Ownership rules are configurable: first contact wins, most recent meaningful contact wins, or ownership is held by the desk rather than the individual. Whichever rule you use, the merge applies it consistently instead of leaving it to whoever clicked the button.

The word genuine is doing real work in that first sentence. A record created by a bulk import of a purchased list is not first contact, and neither is a scrape of a public profile. The event that counts is one the candidate took part in, which is the same definition the retention clock uses, and it is deliberately narrow because the alternative is an ownership system that rewards whoever imports the largest file.

A background pass scores the existing database and produces a review queue ordered by confidence, so the highest-certainty pairs can be cleared quickly and the ambiguous ones can be left alone.

The queue is worked in bulk. Pairs above a confidence threshold you set can be merged as a batch, with a report of what was merged and a window in which the batch can be undone. Nothing is merged silently.

The pragmatic advice is to stop before the queue is empty. In any database of real size there is a long tail of pairs that sit at middling confidence, where two people genuinely might be one person and nothing in the record settles it. Working that tail costs hours and produces the merges most likely to be wrong. Clearing the top of the queue and leaving the ambiguous middle for entry-time checks to resolve naturally is the better use of an afternoon.

The matching logic ships today. Records arriving through parsing, import and manual entry are scored against the existing database using the layered comparison described above, and likely matches are surfaced rather than silently created.

The dedicated merge interface is in build for the Wave 1 release. That is the side-by-side conflict screen, the reversible bulk merge, the merge record that keeps the discarded values, and the background sweep that produces a ranked review queue over the existing database. We describe those in the design tense because they are being written now, not because they are hypothetical.

In the meantime a flagged match is a prompt to a recruiter, who can open the existing record and work it rather than creating a second one, which prevents most of the duplicates that would otherwise be created but does not clean up the ones already there. If deduplication of a large legacy database is the reason you are evaluating us, ask for the current build state before you commit to anything. That is a better conversation than discovering the gap in week three.

It cannot tell you whether two records are two people. It can tell you how much evidence there is either way, and the honest ceiling on that evidence is low for common names in large markets with thin records. Two contractors with the same name, the same city and no email on either record are not resolvable by any amount of scoring, and the correct behaviour is to refuse to guess and put the pair in front of somebody who can ring one of them.

It also does not fix the process that produces duplicates. Two desks working the same market with no shared ownership rule will keep colliding, and merging the results every month treats the symptom. The merge is a clean-up; the fix is a decision about who owns which market and what happens when two recruiters reach the same person in the same week, and that decision is not something software can make for a business.

And nothing here reaches copies that have left the tenant. A shortlist forwarded to a client, a spreadsheet a recruiter keeps for their own pipeline, an export taken before the merge ran: those are all still out there with the old record in them. That is an argument for exporting less rather than an argument against merging, but it is worth saying plainly because deduplication inside one system is frequently sold as though it tidied the whole world.