Product update

Sourcing is a pool, not a search

A shortlist quietly shrinks as people decline, go quiet or get screened out. A pool held at a target level is topped up instead, without anyone remembering to press the button again.

All posts
EL
The EmployLabs team
· 4 min read
In short

EmployLabs treats sourcing as a pool held at a target level rather than a search run once. It keeps a target number of qualified, not-yet-contacted candidates topped up as outreach draws from it, within a sourcing limit (yours, or a default sized to the role); reaching it stops sourcing and asks whether to raise it.

A shortlist is not a stable object

A search gets run, a list comes back, and for about a day the list is what everyone means when they talk about the role. Then it starts to come apart. Someone declines. Two people never answer at all. One turns out, on a closer read, not to meet a requirement that mattered. None of that is unusual and none of it is failure; it is simply what a list of people does once you start contacting them.

The awkward part is that nothing announces the shrinkage. The list is still there, still the same length on the screen, and the difference between the names on it and the names still in play is something a recruiter carries in their head. A fortnight later the pipeline is a third of what it was and the discovery usually happens on a Thursday, when it is too late in the week to do much about it.

The fix that everyone reaches for is a reminder to go back and source more. That works exactly as well as any process that depends on somebody remembering a dull task while under pressure from other roles. And the reminder is only half the work: the second run has to reproduce the filters the first one used and exclude everyone already contacted, which is either a careful ten minutes or a duplicate approach to somebody who has already said no.

A level to hold, not a job to run

Sourcing on EmployLabs is not a search that happens once. It is a pool that is kept topped up to a target. EmployLabs keeps a target number of qualified candidates who have not yet been contacted, and tops the pool up as outreach draws from it. It does this within a sourcing limit: yours if you set one, otherwise a default ceiling sized to the role. When that limit is reached, sourcing stops and asks whether to raise it. The topping up is not a task anybody is assigned.

The difference is in what is being tracked. A search tracks an event: it ran, it returned this many people, it is finished. A pool tracks a level: this is how many live candidates the role needs, this is how many it has, and the gap between those two numbers is the instruction. When attrition opens a gap, the gap is what gets acted on.

The level counts people who are qualified and not yet contacted. Each time outreach takes someone from the pool, the level drops, and that is what opens the gap. A decline or a silenceis still very different information about a candidate, and it is kept as information, but the count that matters is how many qualified people are waiting.

A search is an event. A pool is a level, and a level can be held.

Nobody is bought twice

Topping up a pool repeatedly creates an obvious hazard: the same strong profile appearing again in every subsequent run, being paid for again, and being sent an approach they have already declined once. Anyone who has run a long search manually knows this problem, because the manual version of it is a spreadsheet nobody enjoys maintaining.

Anyone already seen on a role is not sourced again for it. The refill reaches past them into the part of the market the role has not yet touched, which is the only part worth spending on. That also means the top-ups get progressively more useful: each one goes further into the market rather than recirculating the same names at the front of it.

What this changes for your week

  • You stop babysitting a shrinking shortlist. The number of live candidates on a role is maintained rather than monitored, so it is not one more thing to hold in your head across a dozen open roles.
  • A decline stops feeling expensive. When a good candidate says no, the pool behind them is already being kept topped up, and the reaction to a no can be about the reason rather than about the hole it leaves.
  • There is no restart cost. Nobody has to work out who was already approached before sourcing again, because the pool has not forgotten any of them.

How to use it

  1. Read the ready count rather than the total count. How many qualified people are waiting to be contacted is the number the pool holds; how many were ever sourced is history.
  2. Let a weak candidate go. Screening someone out costs you nothing in pipeline, because the pool refills to the same level either way, and keeping a marginal person on a list to avoid it shrinking is a habit worth dropping.
  3. Treat repeated refills as market information. If the pool needs topping up constantly, the market is answering a question about your brief, and that is a conversation to have with the hiring manager rather than a sourcing problem to push harder on.

Common questions

What happens when candidates drop out of my pipeline?
The pool is topped up. Sourcing on EmployLabs holds a target number of qualified, not-yet-contacted candidates, so as outreach draws from the pool the gap is filled automatically, within a sourcing limit (yours, or a default sized to the role); reaching it stops sourcing and asks you whether to raise it.
Will I end up paying for the same candidate twice?
No. Anyone already seen on a role is not sourced again for it, so each top-up reaches further into the part of the market the role has not yet touched instead of recirculating the same names.
Do I have to re-run sourcing when a shortlist thins out?
No, and that is the point. A search is an event that finishes, while a pool is a level that is held. The gap between the target and the live candidate count is what drives the next sourcing, not a reminder in your calendar.

Related reading

All posts →

See it on one of your own roles

Upload a job description and watch the pipeline run before you commit to anything.