
Your Best Candidate Probably Applied Once Already
Most hiring tools file applications under the job post they arrived through, so a candidate you interviewed four months ago is invisible when you open a new role. Here is what a talent pool actually changes.
Open a new role in most hiring tools and you start from zero. Not because you have no candidates -- because the ones you have are filed under a job post that closed. The person you shortlisted in March, interviewed twice and lost to a counter-offer is still in your database. She is just three clicks deep inside a requisition nobody opens any more.
For a small hiring team in India running four or five roles a year, this is the single most expensive habit in the process. You paid -- in job board spend, in screening hours, in interview panel time -- to learn that a specific person is good. Then you threw the conclusion away and paid again.
The problem is filing, not data
Every application ShortlistAI receives already carries the useful parts: a parsed resume, an AI score against that role's job description, expected CTC, current CTC where the candidate gave it, notice period, years of experience, and the stage they reached. None of that is thin.
What was missing was a second way in. Applications were reachable only through the post they arrived on, and every index in the database was keyed on the post. So the data existed and the question "who have we already seen who could do this?" had nowhere to be asked.
The Talent pool page (/hire/talent) is that second way in. It collects every application your organisation has ever received, across every role, into one searchable list. It collects nothing new. It is a different query over data you already had.
The same person, not three rows
The bigger half of the change is duplicate handling. Someone who applied to three of your roles used to be three unrelated rows with nothing joining them, which meant that while you were reviewing their newest application you had no idea they had reached the offer stage on a different one.
They are now one candidate with a history. Identity is the lowercased email address, and it is worth being blunt about why: it is the only stable identifier a candidate supplies. Names are typed differently every time -- "Asha Menon", "asha m", "MENON ASHA" -- and phone is optional. Two genuinely different people sharing a mailbox would be merged into one entry. That is rare, it is visible on screen when it happens, and the alternative is failing to recognise the same person at all, which is the whole point of the feature.
Each candidate row shows:
- Times applied -- how many separate roles they have come through.
- Furthest stage reached, not the latest one. Someone who got to Offer on one role and was rejected on another reads "reached offer". Reaching an offer and then being turned down still tells you more about a person than never having been looked at.
- Best AI score they have ever received, across roles -- not the score from their most recent application, which may have been for a role they were a poor fit for.
- Notice period, expected pay where they gave it, and a link to their resume.
Blanks get backfilled sensibly. If their newest application skipped the phone number but an older one had it, the older value fills the gap -- but a newer value is never overwritten by an older one. Without that rule the pool would look emptier than your data actually is.
What you can filter and sort on
Search matches name or email as a substring, so "meno" finds "Menon". On top of that:
- Minimum years of experience
- Maximum notice period in days
- Furthest stage reached, at least X
- Repeat applicants only -- people who have applied to more than one of your roles
And sorting by best score, experience, most recent application, or times applied.
One deliberate behaviour: a missing value is not a match. If you filter for "at least five years" and a candidate never told you their experience, they are excluded rather than included. Silently padding the results with unknowns would hand you a list you did not ask for.
The page loads up to 2,000 applications and says so on screen when it has hit that cap, rather than truncating quietly and letting you believe you are looking at everything.
What this is good for
The obvious use is a new role: before spending anything on sourcing, filter the pool for the experience band you need and a notice period you can live with, sorted by best score. If three of them already reached your interview stage on a similar role, you have a shortlist before the job post goes live.
The less obvious use is the repeat-applicant filter on its own. Someone who has applied to three of your roles in a year is telling you something. Whether that is enthusiasm or scattergun applying is a judgement call, but at least now it is a judgement you get to make instead of one you never see.
Where it sits
The talent pool is part of Advanced Hiring, which unlocks on the Business plan and up -- the same gate as hiring posts, public apply links and AI shortlisting. The five-day free trial grants Business-tier access, so you can point it at your existing applications before paying anything. If your organisation has already run roles through ShortlistAI, the pool is populated the moment you open it. There is no import step, because there is nothing to import.
If you are hiring and you already have applications sitting in closed posts, that is the first place to look.
Put this advice into action
Build your ATS-ready resume in 90 seconds — powered by Gemini AI. Free, no credit card needed.