Candidate Ownership Rules for Multi-Desk Staffing Firms

Candidate ownership is a commercial rule wearing a technical costume. When two desks have worked the same person and a placement happens, who gets credited determines who gets paid. If the system cannot answer that cleanly, the argument happens in a meeting instead, and it happens every month.

Where candidate ownership disputes come from

Four scenarios cover almost all of them, and every multi-desk firm will meet all four.

Time. Recruiter A sourced the candidate two years ago for a different role. Recruiter B placed them this week. Who owns the fee?

Split relationships. Recruiter A owns the client. Recruiter B owns the candidate. Who owns the placement?

Departure. A candidate applies directly through your careers page, having been sourced years ago by a recruiter who has since left. Who inherits?

Overlap. Two desks in different verticals both have live roles the candidate fits. Who contacts them, and what happens if both do?

None of these are software problems. They are policy questions that software has to encode, and firms that treat them as configuration decisions end up with a policy nobody chose.

The three permission models, and who each suits

Open

Everyone sees everything. It suits small teams with a collaborative culture and a team-based comp plan, and it works well right up until individual commission enters the picture. At that point, openness stops being a culture and becomes an argument.

Desk-scoped

Recruiters see their own desk fully and other desks partially, usually enough to know a candidate exists without seeing the full history. This is where most multi-desk firms land, and it works because it separates two things that are usually collapsed together.

Strict ownership

A candidate belongs to a recruiter and is invisible or locked to everyone else. This is right for executive search and confidential mandates, and it carries a real cost: your firm's pooled data stops being pooled, which undermines the entire argument for maintaining a shared talent pool.

Visibility and access are two different permissions

This is the distinction that makes desk-scoped models work, and collapsing it is the most common configuration mistake.

Seeing that a candidate exists is what prevents duplicate outreach, wasted sourcing and the situation where two recruiters call the same person on the same day.

Being able to contact them is what ownership protects.

Separate the two and a recruiter can discover that the person they were about to source is already owned by a colleague, request access, and have a conversation. Collapse them and you get either a free-for-all or a database where half the records are invisible to half the team.

Ownership has to expire

The rule most firms are missing entirely.

An ownership claim that never lapses turns a shared database into a set of private territories. A recruiter who touched a record once in 2022 can block a live role in 2026, and nobody can override it without a management conversation.

A workable rule: ownership is established by meaningful contact and lapses after a defined period without further contact. Six months is a common setting. After that, the record returns to the shared pool.

This does two things at once. It stops dormant claims blocking live work, and it rewards the recruiters who actually maintain relationships over the ones who touched a record once and filed a claim.

What happens when a recruiter leaves

The scenario every ownership policy eventually meets, and the one most are silent about.

A recruiter departs holding ownership of several hundred candidate records and a handful of client relationships. Three questions need answers written down before it happens, not during the exit interview.

Who inherits the records?

The usual answers are the desk lead, a named successor, or the shared pool. Defaulting to the shared pool is the cleanest and it removes any incentive for a departing person to sit on relationships.

What happens to placements in flight?

A candidate at offer stage when their recruiter leaves is the most fragile situation in staffing. Whoever picks them up needs the complete history, which is only possible if the conversation was captured to the record rather than living in someone's phone.

Does the departing recruiter get paid on subsequent placements?

This is a commission question, not a permissions question, and it should be settled in the employment contract rather than inferred from a software setting. But the system has to be able to represent whatever answer you chose, which is why the policy comes first.

Client ownership is the more valuable half

Most firms spend their energy on candidate ownership and leave client ownership loosely defined, which is the wrong way round.

A candidate relationship is worth one placement fee. A client relationship is worth every role that client will ever give you. Yet the rules governing who owns an account, what happens when a second desk sells into the same company, and who is credited when a dormant client returns are usually informal.

Three things to define explicitly: what establishes client ownership, whether it covers the whole company or a specific business unit, and what happens when the contact who knew you moves to a different employer. That last one is the most common source of genuine ambiguity, because arguably the relationship moved with them.

What to configure, in order

1. Desk structure. Which desks exist and what defines each: vertical, geography, client, or role type.
2. Ownership trigger. What action establishes ownership. Sourcing, first meaningful contact, or submission. Pick exactly one.
3. Expiry. How long ownership survives without further activity.
4. Cross-desk rules. What happens when a candidate fits two desks: notify, request access, or automatic split.
5. Client ownership. Separate from candidate ownership, and usually the more valuable of the two.
6. Visibility versus access. What a recruiter on another desk can see, as distinct from what they can do.

Because the right answer differs by firm size, desk structure and how people are paid, we configure these at the organisation level and let the client's management team set the policy. A default that suits a 200-person RPO is wrong for a six-person search firm, and inheriting somebody else's is how firms end up with rules they never chose.

How ownership flows into reporting and payout

Every performance number is downstream of ownership, which is why getting it wrong is expensive in ways that are hard to trace.

Recruiter conversion rates are wrong if attribution is wrong. Desk margin is wrong if placements are credited to the wrong desk. Commission calculations that do not match the system's ownership record get corrected by hand, every month, forever, and the corrections become a permanent tax on your finance function.

Configure this before you have a year of data in the system. Reattributing historical records is unpleasant enough that most firms decide to live with the mess instead, which means the mess becomes permanent.

The four rules that prevent most disputes

If you take nothing else from this post, these four written on one page will prevent the majority of ownership arguments.

One trigger, written down

Ownership is established by a single named action. Not "whoever worked hardest", which is what every dispute resolves into when the trigger is vague.

A stated expiry

Six months without contact and the record returns to the pool. This alone resolves the most common dispute, which is a stale claim on an active candidate.

A cross-desk rule decided in advance

Notify, request access, or split. Decide once. Resolving each overlap individually means every case becomes a negotiation between two people who are both incentivised to win it.

An escalation path with a named person

Somebody decides when the rules do not cleanly apply, and everyone knows who that is beforehand. Disputes escalate badly when the escalation route is invented after the disagreement starts.

What a good ownership policy does not do

Two honest limits.

It does not stop people gaming it. Any trigger can be gamed. If ownership is established by first contact, someone will send a message to a hundred people to claim them. The trigger has to be paired with a definition of meaningful contact and a manager who reads the activity, which is a management job rather than a software one.

It does not resolve genuine disagreement. If two recruiters both contributed materially to a placement, no rule produces an answer everyone accepts. What a rule does is make the outcome predictable in advance, which is different from making it feel fair, and predictability is the more valuable of the two.

Frequently asked questions

Ownership in RPO and embedded models

The rules above assume a contingency or search desk. Two models break them.

RPO. When your team is delivering as an extension of a client, candidate ownership sits with the client rather than with your recruiter, and your internal attribution becomes a purely commercial matter between your own people. The permission model has to keep each client's candidates separated from the others, which is a different problem from desk ownership.

Embedded and on-site. A recruiter working inside a client is generating candidates for that client alone. Whether those records join your firm's shared pool afterwards is a contract question, and it should be settled in the agreement rather than by whatever your system does automatically. Getting this wrong is a commercial dispute rather than an internal one.

Where to start

Write the ownership policy on one page before you touch a single setting. Ownership trigger, expiry period, cross-desk rule, and what happens when someone leaves.

If your firm cannot agree on that page in a room, no configuration will resolve it. The argument will simply reappear later as a support ticket, and by then it will have a commission cheque attached to it.