The lists you rebuild every month, built once

Segment rules will be built from the same structured fields the candidate record already carries: skills, seniority, location and radius, availability, notice period, salary band, work authorisation, last-contacted date, source and any custom field you have defined.

Rules will combine with and, or and not, and will be able to reference relative dates. Not contacted in ninety days is a rule. Right-to-work document expiring in the next sixty days is a rule. Added to the database this week and matching an open requisition is a rule, and it is the one that turns a database into a morning worklist.

This is the reason pools are being built after the candidate record rather than alongside it. A segment can only ask questions the data can answer, and a database where availability was captured as a sentence and seniority was never normalised will produce rules that look right and return the wrong people. The structure has to exist first; the segment is a view over it, not a substitute for it.

A pool is the natural audience for a campaign. Rather than selecting rows in a list and hoping the selection is right, you will send to a pool whose definition is visible and reviewable, which is the difference between a targeted approach and a blast.

Consent and suppression will be applied at send time regardless of what the pool contains. A candidate who has opted out of marketing contact will be excluded from the send even if they match the rule, and the send report will say how many were excluded and why.

Applying suppression at send rather than at selection matters because a pool is a moving object and a send is a moment. Somebody can opt out on Tuesday, after the pool was assembled and before the campaign goes out on Thursday, and a system that filtered when the list was built would still contact them. Evaluating consent at the point of sending is slower by a fraction of a second and it is the only version that is correct.

Pools will be able to be private to a recruiter, shared with a desk or visible to the whole agency. A shared pool will show who added each member and when, so a shortlist assembled by three people is still legible to the fourth.

Membership changes will be logged. When a candidate drops out of a dynamic segment because their availability changed, the segment history records it, which prevents the familiar argument about whether someone was ever on the list.

Membership history is also what makes a dynamic segment safe to rely on. A list that silently changes composition is difficult to trust and impossible to audit, and the first time a client asks why a candidate they were shown last month is no longer in the running, somebody needs an answer better than the rule must have stopped matching. A dated join and drop record gives that answer in one line.

A pool will be attachable to a requisition, which submits its members into the pipeline at a chosen stage in one action rather than one at a time.

The reverse will also work. Candidates rejected from a requisition for a reason that is not about their quality, such as the salary band being wrong for this client, can be dropped into a pool on rejection so the next brief at the right band starts with a warm list.

That second direction is the one that compounds. A desk that runs the same kind of search repeatedly rejects a great many perfectly good people for reasons specific to one client, and in most systems those decisions evaporate into a disposition code. Routing them into a pool at the moment of rejection costs the recruiter nothing extra and means the next brief in that band opens with people who have already been screened and spoken to.

Every pool will show the age of its membership and the proportion of members not contacted inside your chosen window. A pool where two thirds of the members have not been spoken to in six months is not a talent pool; it is a list.

Nurture cadences will be attachable to a pool so members receive periodic, relevant contact rather than silence followed by a sudden approach when a job appears.

The freshness measure exists to make a specific bad habit visible. Pools accumulate, because adding somebody is easy and removing them requires a judgement. Within a year a desk can be carrying a dozen pools, several of which describe a market the agency no longer works. Showing membership age on the pool itself, rather than in a report nobody opens, is what turns that from an invisible problem into a five-minute tidy.

Tags and filters ship today. A recruiter can tag a candidate, filter a list on those tags and structured fields, and work the result. That is genuinely useful and it is the primitive that pools are built from, which is why it was built first.

Pools and rule-based segments are in build for the Wave 1 release. What that adds over a tag is everything a tag is not: an owner, a sharing scope, a membership history, a freshness measure, a rule that re-evaluates on a schedule, the ability to submit the whole thing into a requisition at a chosen stage, and consent-aware sending against the membership.

In the meantime a saved filter approximates a static pool for the purpose of finding people, and a tag approximates one for the purpose of grouping them. Neither gives you the history or the automation. If pools are the reason you are evaluating us, say so during the trial and ask for the current build state rather than assuming a roadmap date, because the honest answer changes month to month and we would rather give you the real one.

A pool does not create warmth. Nine hundred people who have never replied to your desk are nine hundred people who have never replied to your desk, whether they sit in a spreadsheet or in a well-named segment with a nurture cadence attached. Grouping them makes them easier to contact and does nothing to make them likelier to answer, and a pool used mainly to make cold outreach feel organised will produce cold outreach results.

A segment also cannot ask a question the data cannot answer. If nobody recorded notice period, no rule can find people available in four weeks. If seniority was never normalised, a mid-level segment returns whatever the job titles happened to say. Building pools on a thin database mostly produces confident lists of the wrong people, which is worse than an empty result because nobody checks it.

And rediscovery has a ceiling. A pool is a view over the candidates you already hold, so it will find the people in your database who fit and it will never find the ones who are not in it. Pools reduce how often you pay to source somebody you already knew. They are not a sourcing strategy on their own, and a desk with a genuinely thin market still has to go and meet people.