How do you stop two agencies submitting the same candidate?

Rarely because anyone is behaving badly. Contract workers register with several agencies deliberately, since that is how they stay in work, and a role released to a whole panel at once is a role every supplier on it will search their own database for. The same qualified person surfaces in several of those databases and gets put forward by whoever moves first, and often by two or three of them within a day. The behaviour is a rational response to how work is distributed, which is why the remedy is a rule and a check rather than an instruction to suppliers to be more careful.

Three things, in writing, before a role is released. Which event establishes a claim — normally the first complete submission recorded in the system, not the first phone call or the first email. How long a claim lasts once established, so a supplier who put someone forward last year cannot resurface and bill for a hire they had nothing to do with. And what happens when the candidate was already known to you directly, from a past application or your own talent pool, which is the case suppliers dispute most and the one most rules leave unwritten. Publishing the rule matters more than which version of it you pick, because the argument you are preventing is about ambiguity rather than fairness.

At submission, before a reviewer sees the profile. Each incoming record is matched against people already in your database and against submissions already received from other suppliers on the same role, and a suspected match is flagged at that moment. The cost of moving the check later rises steeply: a duplicate spotted at screening wastes a reviewer's time, and one spotted at offer means two organisations have each invested real effort in a placement only one can be paid for. Vendor management exists partly for this reason, because the check has to sit on the intake path rather than in a report somebody reads afterwards.

Both errors are real and they are not symmetrical. A missed match lets the dispute happen anyway. A wrong match merges two different people, which is worse: it corrupts a record, may expose one candidate's history to a conversation about another, and is hard to unwind once notes and stages have accumulated on the merged version. Systems typically match on email address, phone number and approximate name, and the sensible posture is to surface suspected pairs for a person to confirm rather than to merge automatically on a fuzzy signal. Candidate deduplication is detection; deciding which record survives is a separate step that deserves a human.

Long enough that a supplier who genuinely introduced someone is protected, short enough that an introduction does not become an annuity. Programmes usually attach a defined window to a submission, after which the person returns to open status and can be put forward again by anyone, including your own team. What the window should be is a commercial judgement rather than a technical one, and it belongs in the supplier agreement rather than in a system setting somebody changes quietly. Whatever you choose, apply it identically to every supplier — an ownership rule that bends for the supplier who complains loudest stops functioning as a rule at all.

Submit the same person twice yourself, from two supplier accounts, and watch what the second submission does. A flag that appears only in a nightly report is not a control. Then submit the same person with a different email address and a slightly different spelling of their name, which is what actually happens, and see whether the match still fires. Then check what a supplier is told: silence looks like acceptance and produces the dispute anyway. Do all three in a trial rather than after purchase, because this is the feature most often described in a demo and least often exercised against the messy data it exists for.