The Shared Candidate Pool: Ownership, Duplicate Approaches and the Leaver Problem

A solo desk has no ownership problem. The moment there are three consultants working overlapping markets, the pool becomes a shared asset nobody formally owns, and three failures start arriving on a schedule: the same candidate approached twice in a week, the good names sitting in one person's private notes, and a leaver taking a market with them. None of these is a software problem first. They are rules problems that software can enforce once you have decided the rules.

Three ways a shared pool goes wrong

They show up in this order, usually within a year of the second hire.

• Collision. Two consultants approach the same person for different roles inside a fortnight. The candidate notices even when neither consultant does.
• Hoarding. The strongest names never reach the shared pool, because the consultant who found them is measured on their own billings and has no reason to publish them.
• Evaporation. Somebody leaves and the market knowledge goes with them, because it was never in a system anyone else searched.

Hoarding is the one most firms misdiagnose as a culture problem. It is almost always an incentive problem wearing a culture costume.

A duplicate approach costs more than embarrassment

It is tempting to file collisions under "awkward but survivable". The real cost is three-layered.

• The candidate downgrades you. Two approaches from one firm in a fortnight reads as either disorganised or indiscriminate. Both make the next approach easier to ignore.
• The client sees it. If both consultants put the same person forward on different reqs, the shortlist stops looking like a judgement and starts looking like a database dump.
• You pay twice for the same work. Two people sourced, enriched and wrote to the same person. The second one was pure cost.

Ownership rules that survive a busy Thursday

Most firms have a rule. Fewer have a rule that holds when someone is behind on a deadline.

ATLAS's State of Agency Recruitment benchmark, published 16 March 2026 from a survey of more than 1,000 agency recruiters, found only 34.72% describe their processes as "very well-defined and consistent", with a further 22.22% defined but inconsistently followed. That second group is the one to design for. Assume the rule will be ignored under pressure and make the system do the work.

Three rules that tend to hold, because they are cheap to follow:

1. Ownership is time-boxed, not permanent. Whoever last had a real conversation owns the relationship for a defined window, then it returns to the pool. Permanent ownership is just hoarding with paperwork.
2. Ownership attaches to the conversation, not the search. Finding someone in a search is not ownership. Having spoken to them is. Otherwise the fastest searcher locks the market.
3. A check before the first approach, not a report after it. The rule has to fire at the moment of sending, which is the only moment anybody is paying attention.

What "shared" should and should not mean

Shared does not mean flat. A pool where everyone can do anything to any record is as unworkable as a pool nobody can see.

The split worth drawing:

• Visibility should be wide. Everyone should be able to see that a person exists, that somebody spoke to them in March, and that they are currently in a sequence. That is what prevents collisions, and it costs the finder nothing.
• Action should be narrower. Seeing that a colleague is mid-conversation is useful. Being able to enrol that person in your own campaign without a word is how collisions happen in systems that were supposed to prevent them.
• Attribution should be permanent even when ownership is not. Who found someone, and who first spoke to them, should stay on the record after the ownership window closes. This is the bit that makes consultants willing to publish names in the first place.

In Instalent, members of an organisation share sourcing and outreach, and the shared views carry owner attribution, so a record shows whose work it was rather than appearing as anonymous team property. A list a colleague built through AI candidate sourcing is searchable alongside your own, and sequence state from multichannel outreach is visible on the record, which is the fact that actually prevents a second approach. It is the same argument as talent mapping at team scale rather than desk scale, and the wider agency view sits on solutions for recruitment agencies.

The leaver problem

This is the failure that costs the most and gets planned for the least.

When a consultant leaves, three things walk out with them if the pool was never really shared: the names, the context behind the names, and the knowledge of which companies are worth watching. The names are the least valuable of the three and the only one most firms try to recover.

The practical test is one question, asked before anyone resigns: if your strongest biller left on Friday, could someone else run their market on Monday from what is in the system? If the honest answer is no, the pool is not shared, whatever the software licence says.

What makes the answer yes is not a stricter policy. It is that publishing to the pool has to be the path of least resistance. If a consultant has to do extra work to share a name, the name will not be shared, and no amount of reminding will change that. Talent pipeline covers keeping that pool from going stale once it exists.

What tooling settles, and what it cannot

Honest division of labour.

Software can settle: whether a record is visible to the team, whether somebody is already in a sequence with that person, when they were last contacted and by whom, and whether the attribution survives. Those are facts, and a system that holds them removes most collisions without anyone having to remember a rule.

Software cannot settle: how long an ownership window should be, whether a consultant is rewarded for publishing names, or whether a manager is willing to enforce a rule against their best biller. A tool that makes activity visible will show you exactly who is hoarding. What happens next is a management decision, and no product has ever made that one for anybody.

Want the pool shared and the attribution visible? Get started

Common questions

What is a shared candidate pool?

A candidate database that a whole team can see and search, rather than a set of private lists held by individual consultants. Shared means visibility is wide, not that everyone can act on every record.

How do you stop two consultants approaching the same candidate?

Make the check fire before the first approach rather than reporting the collision afterwards, and make the record show who last spoke to the person and whether anybody is currently in a sequence with them. A rule that depends on someone remembering under deadline pressure will not hold.

Should candidate ownership be permanent?

No. Time-boxed ownership that returns the record to the pool is more workable, and ownership should attach to having had a real conversation rather than to having found someone in a search. Otherwise the fastest searcher locks the market.

What happens when a consultant leaves?

If the pool was genuinely shared, someone else can run that market from what is in the system. The honest test is whether they could do it on Monday if the leaver went on Friday. Names are the least valuable thing that walks out; the context and the market knowledge matter more.

Sources

• The State of Agency Recruitment: 2026 Benchmark Report - ATLAS, 16 March 2026 (survey of 1,000+ agency recruiters; 34.72% describe their processes as "very well-defined and consistent", 29.17% partially defined, 22.22% defined but inconsistently followed).
• SHRM Unveils 2026 Talent Trends Report - SHRM, 27 April 2026 (survey of 2,094 HR professionals fielded 9 to 20 February 2026; 68% reported difficulty recruiting for full-time roles, 53% of those said it had become harder than a year before, which is the pressure under which an ownership rule gets ignored).