How to build a talent pool that actually gets used
Most talent pools are spreadsheets that someone built with good intentions in a quiet week and nobody has opened since. The names are still there. The phone numbers are three jobs out of date. When a brief lands, the consultant starts a fresh search, because they already know the pool will not help.
That is the real failure, and it is not a tooling problem. A pool only pays for itself when a consultant opens it first, before they do anything else, and finds someone they can actually ring today. Everything below is aimed at that one test.
Build the pool around demand, not around supply
The usual instinct is to pool everyone good you meet. That produces a long list organised by nothing, and a long list organised by nothing is a worse search than starting over.
Build it the other way round. Look at what your desk has actually been asked to fill over the last twelve months, group those roles into the five or six that keep repeating, and pool against those groups only.
A healthcare desk in Brisbane might find its repeat demand is theatre nurses, aged care RNs and practice managers. That is three pools, not one. An engineering desk might find it is site engineers, project engineers and contract administrators. The groups are specific enough that you know what you are looking at when you open one, and broad enough that each gets used often enough to stay alive.
If a group has not come up in a year, it does not get a pool. You can always start one when the demand appears.
The three things that make a record worth keeping
A pooled person needs enough on the record to decide whether to call them, without opening anything else. In practice that is three things.
What they actually do, in your words not their title. Titles travel badly between employers. "Project Engineer" at a tier one contractor and "Project Engineer" at a fifteen-person civil firm are different jobs. Write the one line you would say to a client: "runs $5-15m civil packages, RMS experience, has done both design-and-construct and hard dollar."
What would move them. This is the field everyone skips and the one that decides whether the call works. Money, commute, a manager they are tired of, wanting to get off nights, wanting a permanent role after a run of contracts. If you do not know, write that you do not know, which is itself useful.
When you last spoke, and what was true then. Not when the record was created. When a human last had a conversation with them.
Everything else, the CV, the certifications, the right-to-work status, can live in the file. These three decide whether you pick up the phone.
Decay is the whole problem
A talent pool is not an asset that sits still. It rots at a predictable rate and the rate is faster than most people assume.
Rough shape of it: a tradesperson or a contractor can change availability in a fortnight. A permanent professional is usually stable for six to eighteen months, then moves. Mobile numbers survive job changes, work emails do not. So a pool built twelve months ago and untouched is mostly fiction, and the half of it that is still accurate is indistinguishable from the half that is not.
This is the point at which most agencies decide pooling does not work. The honest conclusion is narrower: pooling without maintenance does not work.
The maintenance that actually fits on a desk is small and regular rather than large and occasional. Thirty minutes a week, working the oldest records first, is enough to keep a few hundred people current. A quarterly "clean the whole thing" session never happens, and when it does happen it takes a day and the information is stale again by March.
One trick that costs nothing: every time you speak to someone for any reason, update their record before you make the next call. Not at the end of the day. The note you write sixty seconds after a conversation is worth five times the note you write at 5pm from memory.
Keep the pool and the client list apart
A pool of people and a list of companies are two different objects that want two different fields, and merging them is the most common way a good pool dies.
Candidate records want availability, what would move them, and when you last spoke. Company records want a status, who owns the hire, and a next-touch date. Run them in one undifferentiated sheet and within a few weeks neither view is trustworthy, because the columns are doing double duty and half of them are empty for any given row.
If you are running on spreadsheets, that is two tabs with different headers. If you are on a CRM, it is two record types. Either is fine. One merged thing is not.
How to tell whether it is working
Three numbers, none of which require a tool to count.
How often it gets opened first. When a brief lands, does the consultant go to the pool before they go anywhere else? If the answer is no, nothing else matters and the problem is that the pool has not earned trust yet.
Hit rate on a call. Of the pooled people you ring about a live role, how many are contactable and open to a conversation? Below about a third and your records have decayed past usefulness.
Time from brief to first submitted candidate. This is the one a client notices. If pooling is working, this number falls, and it falls most on the role groups you pooled deliberately.
Count these for a quarter before deciding whether pooling is worth the time on your desk. The answer genuinely differs by market: in a candidate-short trade where the same forty people circulate, a pool is the whole business. In a market with deep supply and roles that change shape constantly, a fresh search each time may honestly be cheaper.
Where the time goes, and the part worth automating
Here is the arithmetic, with the assumptions stated because this is a model and not a measurement from anyone's desk.
Say a consultant pools against four role groups, two hundred people in total. At thirty minutes a week of maintenance they touch roughly ten to fifteen records, which means each record gets refreshed about every four months. That is enough for permanent professionals and not quite enough for contractors, who need a lighter touch more often.
The expensive part is not the maintenance. It is the first build: working out who exists, reading enough of each profile to know whether they belong in the group, and writing the one-line description. For two hundred people, at five to eight minutes each if you are being honest about the reading, that is somewhere between sixteen and twenty-six hours. Which is why most pools never get built properly, and why the ones that do get built are usually assembled from whoever happened to apply.
That initial read is the piece worth handing off. Describing a role group in plain words and getting back a ranked set of people with the evidence against each requirement is the same job a consultant does in those twenty-odd hours, and it is the half of it that does not need a recruiter's judgement. Rectask Sourcing does that part: you write the brief the way you would explain the role group to a colleague, and every profile comes back read and checked against each must-have.
The judgement half, what would move this person, whether they would suit this particular site manager, whether they are worth a call today, stays with you. That is the part worth your twenty hours.
Common questions
How many people should a talent pool have?
Fewer than you think. Two hundred live, current records across four role groups beats two thousand stale ones, because the test is whether a consultant trusts it enough to open it first. Size it by how many you can realistically keep current at thirty minutes a week.
How often should a talent pool be updated?
Continuously and in small amounts, rather than in a quarterly cleanup. Update a record every time you speak to that person, and spend a short fixed slot each week on the oldest records. Contractors and tradespeople need touching more often than permanent professionals.
Is talent pooling worth it for a small agency?
It depends on whether your market repeats. If the same roles come back every few months and the candidate supply is tight, a pool is the highest-return thing on the desk. If every brief is different and supply is deep, a fresh search each time may genuinely be cheaper, and it is worth measuring rather than assuming.
What is the difference between a talent pool and a database?
A database is everyone you have ever collected. A pool is a deliberately chosen, actively maintained subset built around demand you expect to see again. The difference is maintenance and intent, not size.
