How to rediscover past applicants for a new role (2026): sort by the reason they were rejected, not by how well they match

A job order lands on Monday morning. Before you spend anything on advertising it, somebody says the sensible thing: we must have people for this already.

So you press the match button, or you run a search, and you get a list. Near the top are two people you placed last year, someone who told you in March they were staying put, and a candidate whose CV describes a job they left eighteen months ago. Somewhere below that, buried, are three people who would actually be perfect. You do not find them, because by result eleven you have stopped believing the list.

The usual explanation is data quality, and you have probably been told to fix your tagging. That is not the interesting part. The interesting part is that your system is answering a question you did not ask, and it is answering it correctly.

Your ATS did not store candidates. It stored verdicts. And a verdict has no expiry date, because nobody ever built a field for one.

Contents

• Quick summary
• Why should you listen to us?
• The silver medalist reflex points at the wrong pool
• What your ATS actually stored
• Which reject reasons expire
• The four pools, in the order that works
• What the match button cannot know
• Check decay before you contact anyone
• The 45 minute run on a new job order
• The re-approach message
• The legal floor, UK and US, August 2026
• When this is not worth doing
• Where Gemsift fits, honestly
• FAQ

Quick summary

• "Rejected" is not a quality label. It is a verdict about one candidate against one brief for one client on one date. Most of the reasons behind it expire. Your ATS records the verdict and throws away the expiry.
• Match scores rank on similarity, which is the wrong axis. The useful question on a new job order is not "who resembles this spec" but "whose reason for being turned down no longer applies."
• Silver medalists are the smallest and most oversold pool. Real finalists are worth calling first because they are cheap to check, not because they are the best fit. They were measured against a different brief and still came second.
• The reject reason field already exists in your ATS and it is wired to the wrong things. In Bullhorn and Recruiterflow it drives reports and automated rejection emails. It does not drive the re-match.
• Contact data and job titles decay faster than the record admits. US median job tenure was 3.9 years in January 2024 and 2.7 years for workers aged 25 to 34, so a two year old CV misstates a meaningful share of your base.
• The legal floor moved twice this year. Illinois notice duties have been live since 1 January 2026, the EU deferred its high-risk employment AI obligations to December 2027, Colorado replaced its AI Act with a framework starting January 2027, and NYC's rules explicitly cover employment agencies.
• Do the small version. Four pools, in order, forty five minutes, before you pay a job board anything.

Why should you listen to us?

I build Gemsift, an AI-native ATS for recruitment agencies, so I have a commercial interest in you deciding that your current base is underused. Read this with that in mind. I have written it so it works on the system you already have, because most of it is a change in the order you do things rather than a purchase.

Two things ground the specifics. First, primary sources read this month rather than recalled: ICO guidance, vendor help documentation, the BLS tenure release, and the actual status of four AI-in-hiring laws, all quoted closely enough that you can check me. Second, conversations with owners of small agencies about what happens when they go back to the base on a live role.

One thing I want to be direct about, because this topic is thick with it. I went looking for hard numbers on whether re-engaged past applicants really do place faster or cheaper than fresh candidates, and I could not find an independent study that establishes it. What is in circulation is vendor case studies with undisclosed methodology and unnamed samples. So this article argues from mechanism and from primary sources, and where I have no number I say so instead of borrowing a confident one. If you have seen credible data on this, I would genuinely like to read it.

The silver medalist reflex points at the wrong pool

Everybody reaches for the same pool first. The runners-up. The candidate who reached the final two and lost. The industry has a warm name for them and a decade of content explaining that they are your cheapest placement.

Call them, by all means. They are quick to check and the conversation is easy. But notice what the label actually tells you: this person was measured closely against a specific brief, by a specific client, and was not chosen. If your new role is genuinely the same brief for a similar client, you are re-running an assessment that already returned a negative. If your new role is different, then their status as a runner-up is evidence about a spec that no longer exists.

There are two more structural problems with leading on this pool.

It is tiny. In a five to twenty person agency, the number of people who reached a client final round in the last six months, in the right job family, and are still on the market, is a couple of dozen at most. You can work that list from memory. It does not need software and it will not fill your desk.

And it is the pool with the strongest survivorship bias in the stories people tell. Everyone remembers the finalist they placed in 48 hours. Nobody writes up the fifteen rediscovery attempts that produced stale numbers and polite non-answers.

The much larger and much better pool is sitting one step earlier in the funnel, and it is invisible because of how it is labelled.

What your ATS actually stored

Here is the mechanical claim, and everything practical in this article follows from it.

When a recruiter closes out a candidate, the system records an outcome. Rejected. Disqualified. Not progressed. Attached to that, if anyone bothered, is a reason. Then the role closes, the client moves on, the market moves, and that record sits there carrying a single word about a decision whose context has evaporated.

Consider a real shape of this. In February you had a role: senior backend engineer, hybrid in central London, three days on site, up to £90,000, client insists on financial services background. A candidate applies. Strong, but wants fully remote, and asks for £100,000. You mark them rejected. Reason, if you typed one: salary and location.

In August a new role lands. Backend engineer, fully remote, £85,000, a startup that does not care about sector. That candidate is now close to ideal. Their record says rejected.

Nothing about the person changed. The brief changed. But the field in your system does not distinguish between "this person is not good" and "this person did not fit that", and neither does anything reading the field.

This is the whole problem in one sentence: your base is full of verdicts that expired without anyone marking them expired.

Once you see it, the right query on a new job order changes shape. You are not looking for people who resemble the spec. You are looking for verdicts whose reason no longer applies.

Which reject reasons expire

This is the part worth stealing. Sort your reject reasons into three buckets. Once, on paper, for your desk. It takes twenty minutes and it changes how you work the base forever.

Two notes on using this.

The reasons in the top block are where the placements are. They are also, unhelpfully, the reasons recruiters are least likely to have written down, because at the time they felt too obvious to record.

And the last row is the only one that must be enforced mechanically. Everything else in the table is a prompt to look again. An opt-out is not a prompt. If your system cannot reliably tell you who has opted out, fix that before you run any of this.

The four pools, in the order that works

Work these in sequence on a live job order. Stop when you have enough people to submit, which is usually in pool two or three.

Pool 1: expired-reason rejects, last 18 months. People turned down for a reason in the top block of the table above, for a role in the same job family. This is your best pool and almost nobody queries it, because it requires reading reasons rather than matching skills. If your reject reasons are structured and searchable, filter on them directly. If they are free text, search the note text for the words your team actually types: too expensive, wanted remote, too senior, no fintech, client went with internal.

Pool 2: recent client-stage candidates. Submitted to a client or interviewed by one in the last six to nine months, same job family. Small, high signal, fast to check. Read every record properly, there will not be many.

Pool 3: applicants to adjacent roles who were never properly read. People who applied to something similar and were screened out at CV stage in a batch. You are not looking for a match here, you are looking for the ones a batch screen would predictably have missed: the career changer, the person who described the same work in different vocabulary, the non-linear CV. This is the same failure mode as keyword filters burying strong candidates, applied retrospectively.

Pool 4: everyone else. The rest of the base. This is where the match button points you first and where you should arrive last. It is the biggest pool, the oldest, the most decayed, and the least contextualised. It is worth reading properly with a system that can read properly. It is not worth skimming a ranked list of.

The ordering principle is not size and it is not match quality. It is how much context you still have. Pools 1 and 2 come with a documented reason and a recent date. Pool 4 comes with a file and a shrug.

If your base is large enough that pools 1 to 3 are still thousands of people, the constraint has moved from selection to reading, and the three kinds of rediscovery tooling are the relevant comparison.

What the match button cannot know

Worth being precise about the tooling, because the gap is specific rather than general.

Agency ATSs do have the field this depends on. Bullhorn documents a Reject Reason field, and a Reject Origin value associated with it so that users can identify why a candidate was rejected and where the rejection originated. Recruiterflow lets an admin customise disqualification reasons in Workspace Settings, and its documentation is explicit that reasons cannot be deleted, only archived, so that they stay attached to records that already used them. That is good data modelling.

Now look at what the documentation says those reasons are for. In Recruiterflow's own words, disqualification reasons feed reports, and you can build a Recipe to send a rejection email automatically to candidates disqualified for a specific reason. Reporting and automated rejections.

So the field exists, it is well designed, and it is wired to analytics and to sending people bad news. What it is not wired to is the thing you need on a Monday morning, which is: show me the people whose reason for being turned down does not apply to this new role.

That is the honest shape of the gap in 2026. It is not that AI matching is fake. Semantic matching over resume text is genuinely better than the boolean it replaced. It is that all of it ranks on similarity to the new spec, computed against the record as it was stored, while the information that would actually re-open the right candidates sits in an adjacent field driving an email template.

Two consequences follow, and they explain the complaints you see on G2 and in recruiting forums about matching returning already-placed or obviously wrong people.

A matcher has no negative signal. It does not know the candidate ghosted you, that the client disliked them, or that they told you in March they were staying put, unless someone encoded it in a way the ranking consumes. Workflow status is not talent intelligence, and matching tools expose that difference brutally.

And a matcher reads a fossil. The document it scores was true on the day it arrived. Which brings us to decay.

Check decay before you contact anyone

The record describes the person as they were when they applied. How wrong that is depends almost entirely on age.

The most recent US Bureau of Labor Statistics tenure figures, from January 2024, put median tenure with a current employer at 3.9 years, the lowest since January 2002, and at 2.7 years for workers aged 25 to 34. BLS runs this survey every two years so there is no 2026 figure yet. Take the implication rather than the decimal: for the age band that makes up most agency inbound, the median person changes employer roughly every two and a half years. A CV that is two years old is describing a job a large share of your base no longer holds.

For contact details, I am not going to quote a decay percentage at you, because the numbers in circulation come from B2B sales data vendors and are not measured on candidate records. The direction is not in dispute and you can measure your own rate for free: take fifty records from two years ago, try the emails, count the bounces. That number is yours and it is worth more than a borrowed one.

The practical rule is one step, and it is the step everyone skips. Before you send anything, check the person's current title and location. It takes fifteen seconds and it prevents the single most damaging version of this outreach, which is approaching a director about the junior role they applied for three years ago. Candidates notice that immediately, they read it as evidence that nobody looked, and they are right.

Contact fewer people, having actually looked at each one. This is the same discipline that makes database reactivation work rather than burn: the failure is in the selection, not the sending.

The 45 minute run on a new job order

Before you spend on advertising, run this. It assumes a small team with no time and a base that is nowhere near clean.

1. Write the brief properly, including what it is not. Five minutes. Must-haves, location and remote policy, band, seniority. Then the part that matters here: list two or three reasons a good candidate might have been turned down before that do not apply to this role. Remote is fine now. No sector requirement. Band is lower, so the too-expensive people from the £90k role are in range.
2. Query the expired reasons, not the skills. Ten minutes. Filter or text-search on the reject reasons you listed in step one, restricted to the same job family and the last eighteen months. If this returns nothing, your reasons were never recorded, which tells you something worth fixing going forward.
3. Pull recent client-stage candidates. Five minutes. Submitted or client-interviewed in the last six to nine months, same family.
4. Read the records, do not scan the scores. Fifteen minutes. Twenty to thirty records, properly. You are deciding whether the old reason is dead, not whether the CV matches.
5. Check current title and location on the shortlist. Five minutes for eight to ten people.
6. Check contactability before writing anything. Opted out, objected, or asked not to be contacted: excluded, no exceptions. Then check they are not live on another of your processes.
7. Write individually. Five minutes for five messages. See below.
8. Only now decide whether you still need to advertise. Often you do. But you will be advertising for the gap that is left, not for the whole role.

Two things to notice about the shape of this. The AI match over the whole base is not in the list, and that is deliberate: treat it as a reading list you work through afterwards if pools 1 to 3 come up short, not as the starting point. And the largest single block of time is reading. That is not inefficiency, that is the job. The reason software is interesting here is that reading is the part that does not scale, not the searching.

The re-approach message

The reason mass re-engagement damages an agency's name is not that the emails were sent. It is that they were obviously not written.

Rules that make a re-approach read as human:

• Name the previous role and roughly when. "We spoke in March about the backend role at the insurance client." It proves the history is real, and it gives them a memory to attach you to.
• State what is different in the way that matters to them. This is the whole message. "That one needed three days on site, which was the blocker. This one is fully remote." You are showing them you remember the actual reason, which almost nobody does.
• One specific detail from their background. Evidence that a person opened the record.
• Ask, do not pitch. One question, easy to answer, no obligation.
• Four to six sentences. If you cannot personalise it in six sentences, you have not read the record and you should not send it.

What to delete on sight: "I came across your profile" when you already worked with them. "We are always looking for great people like you." Any sentence that would be equally true of two hundred other recipients. And anything describing them at the seniority on the old CV before you have checked.

One honest note on volume. This does not scale to a blast, and that is the point rather than a limitation. Ten messages that reference the real reason will out-perform two hundred that do not, and they will not cost you the base.

The legal floor, UK and US, August 2026

Two separate questions here, and agencies routinely conflate them. May I still hold and contact this person, and may I re-score them with AI. Not legal advice, and take advice on your own situation, but this is the floor as I read the primary sources this month.

UK: can you contact them at all. The ICO's recruitment and selection guidance is clear that data protection law does not set timescales, and equally clear about the default. In its own words, you "must not keep information for longer than you need to", and its worked example says that unless there is a clear business reason, an employer should not keep recruitment records for unsuccessful candidates beyond the statutory period in which an applicant can bring a claim arising from the recruitment process.

The operative bit for rediscovery is the ICO's test for keeping candidate information for a new purpose. You must review whether you need a different lawful basis, you must have previously informed candidates that you will keep their information for another purpose and explained what that purpose is, and you must destroy what you do not need. Read that middle condition carefully, because it is the one that decides whether your base is workable. If your application process never told candidates you would keep their details for future roles, the future-roles use was not disclosed, and no amount of retrospective legitimate-interest reasoning fixes that. The ICO's own example of doing it properly is an employer telling candidates on the application form that it will keep the top ten scorers for six months in case further vacancies arise.

If you are an agency in England, Wales or Scotland you also sit under the Employment Agencies Act 1973, and in Northern Ireland the Employment (Miscellaneous Provisions) (NI) Order 1981, which carry their own record obligations. Those are about keeping records, not about permission to market to people, and the two get muddled constantly.

So the defensible UK position: disclosure at collection, a written retention period you actually apply, easy and honoured opt-out, and a role-specific relevant approach rather than a blast. Indefinite retention just in case is not defensible, and a "do not contact" flag whose origin nobody remembers should be treated as binding rather than as noise.

US: mostly notice and rights, state by state. Applicant data has been fully within scope of California's CCPA and CPRA since January 2023, so applicant notice at collection, access, deletion and correction rights apply to candidate records. Several other states have since brought applicant or HR data into scope with meaningfully different carve-outs, so do not assume that a California-shaped policy covers you everywhere. Separately, and this catches people out: re-screening a past applicant for a new role generally makes them an applicant for that new role, with the recordkeeping and non-discrimination duties attaching to the new decision rather than the old one.

AI scoring: four things moved, and two of them moved in your favour.

• New York City, Local Law 144. If you use an automated employment decision tool to substantially assist screening for a role in NYC, you need an independent bias audit within the past year, a public summary of it, and candidate notice. Note who is covered: the rules apply to employment agencies using an AEDT on behalf of employers to screen NYC-based candidates, not only to end employers. Penalties run from $500 to $1,500 per violation, with each day a violation continues treated as separate. On 2 December 2025 the New York State Comptroller published an audit concluding that the enforcing department's enforcement had been ineffective, citing failures in complaint intake and superficial review of posted audits. Weak enforcement to date is not a strategy, and public criticism of a regulator is usually followed by more enforcement rather than less.
• Illinois, HB 3773. In force since 1 January 2026 as an amendment to the Illinois Human Rights Act. It prohibits AI use in employment decisions that produces discriminatory effects, including using zip code as a proxy for a protected class, and requires notice to candidates when AI is used. The Department of Human Rights has rulemaking authority here and its proposed notice rules have been through withdrawal and revision, so the statutory duty is live while the exact form of a compliant notice is still settling. Give notice now, in plain language, rather than waiting for the final rule.
• EU AI Act, deferred. Employment uses of AI, including recruitment and selection, remain high-risk. But the Digital Omnibus package, given final Council approval on 29 June 2026, moved the compliance deadline for high-risk employment AI from 2 August 2026 to 2 December 2027. What did not move: the general transparency duties took effect on 2 August 2026 as planned, and the ban on emotion-recognition AI in the workplace has been in force since February 2025. If you place into the EU you are a deployer, and you have more time than you were told last year, not a pass.
• Colorado, replaced. The original Colorado AI Act was postponed from 1 February 2026 to 30 June 2026, and then superseded: the governor signed SB 26-189 on 14 May 2026, replacing it with a narrower framework focused on disclosure and transparency around automated decision-making technology in consequential decisions, effective 1 January 2027.

The practical version of all four, for an agency of one to twenty people. If your tool ranks or scores candidates, assume it is in scope somewhere you operate. Tell candidates you use it. Keep a human making the final call and be able to demonstrate that. Do not treat a score as the decision. And keep the record of which role each re-approach was for and why that person was selected, because that log is what turns "we used AI" into "we used AI defensibly".

When this is not worth doing

I would rather you skip this than do it badly.

• Your base is under a few hundred people. You already know them. Reading the whole thing yourself is faster than any process.
• Nobody ever recorded reject reasons and there are no notes. Pool 1 does not exist for you. Work pools 2 and 3, and start recording reasons from today, because in six months this article becomes usable.
• Your base predates any disclosure that you would keep details for future roles. Then the honest move is a permission-first approach or leaving it alone, not creative reasoning about lawful basis.
• You are an outbound headhunter with low inbound. Your base was never the asset. Sourcing is a different job and this whole article is about the wrong thing for you.
• The role is genuinely novel for your desk. No adjacent history means no adjacent pool. Go advertise.

Where Gemsift fits, honestly

Gemsift is the AI-native ATS an agency moves into when its current ATS has become a filing cabinet. You import with one export file, and when you open a role it re-reads your whole candidate base against that role and returns a client-ready shortlist with a plain English reason per person rather than a percentage.

Against the argument above, here is the design intent and its limits, stated fairly.

The re-read fires when you open a role, which addresses pool 4 directly. Most of the value in an agency base is lost to nobody looking, not to looking badly, and a system that reads the base on every new job order does not depend on somebody remembering to.

Because it reads documents rather than matching stored keywords, pool 3 is the case it is actually built for: the person who described the same work in different words, or whose CV is not linear, and who a batch screen predictably dropped.

What it does not do is invent context that nobody captured. If your team never wrote down why a candidate was turned down, no system can re-open that verdict for you, mine included. Reading a document tells you what a person did. It does not tell you that a client found them abrasive in an interview nobody logged. That gap is real and I would rather name it than let a demo imply otherwise.

And a plain English reason per pick is not a compliance programme. It helps, because a reason you can read is a reason you can overrule and a reason you can show. But the notice, the opt-out handling, the human-in-the-loop record and, if you touch NYC roles, the bias audit are yours to run whatever software you use.

Prices as of August 2026, and confirm them on the site since they change: Free at $0 for a base of 100 people with no card, Solo at $99 a month for 1,000 people, Agency at $299 a month for 5,000 people with three seats, and Scale from $899 for larger bases or more seats. Annual billing gives two months free. Full export as CSV or JSON is on every plan including the free one, which is the leverage you should insist on from any vendor including this one. You can also run it against built-in sample data without uploading a real resume.

Where it is not the answer:

• You need heavy integrations, job board posting, or enterprise compliance tooling. Keep a traditional ATS. This is not that.
• You are a pure outbound headhunter. Your problem is people who never applied to you, which is sourcing.
• Your volume per role is single digits. Read them yourself, you will be faster.
• You want the relationship history back. We read documents. A conversation nobody wrote down is not recoverable by any software.

A fair test rather than a demo: take a role you filled from advertising in the last quarter, run a re-read of your base against that same role, and check whether anyone on the resulting list was already sitting in your system when you paid to advertise it. If the answer is nobody, your base genuinely was empty and you should stop reading articles like this one.

Start free, no card

FAQ

Are silver medalist candidates actually worth going back to?

Yes, but call them because they are cheap to check, not because the industry says they are your best pool. A runner-up was assessed closely against a brief that no longer exists and still came second. In an agency of five to twenty people the genuine pool of recent client-stage runners-up in the right job family is a couple of dozen at most, which will not fill a desk. The larger and better pool is people rejected earlier for a reason that has since expired. I went looking for independent data quantifying the silver medalist advantage and could not find any that was not a vendor case study, so treat the confident percentages in this category with suspicion.

How far back is it worth going in the database?

Eighteen months is the practical default for reasons-based rediscovery, stretching to two years for senior or niche roles where movement is slower. Past that, two things compound: the document is describing a job a large share of people no longer hold, and your lawful basis for holding the record at all needs to be something you can point at. If you find yourself justifying a five year old CV, the question has stopped being about recruiting.

How is this different from the AI matching already in my ATS?

Your ATS ranks candidates by similarity to the new job, computed against the record it parsed when the resume arrived. That is useful and it is not what re-opens the right people. The information that decides whether a past applicant should be reconsidered is why they were turned down last time, and in the systems I checked that field drives reports and automated rejection emails rather than the ranking. So the matcher confidently returns people who resemble the spec, including ones you already placed and ones who told you no, while the candidate whose only blocker was a commute that no longer applies sits below the fold.

Can I email past applicants about a new role, legally?

In the UK the deciding question is usually whether you told them at application time that you would keep their details for future roles. The ICO's test for using candidate information for a new purpose requires that you previously informed candidates of that purpose and explained it, alongside reviewing your lawful basis and destroying what you do not need. If that disclosure was never made, retrospective reasoning does not fix it. In the US it is mostly notice and rights, led by California but with meaningfully different state carve-outs, and re-screening a past applicant for a new role generally makes them an applicant for that role with fresh duties attaching. Either way: honour opt-outs mechanically, keep a written retention period you actually apply, and approach people about a specific relevant role rather than broadcasting.

My reject reasons are all free text or missing. What do I do?

Work pools 2 and 3 for now, and start recording reasons from today with a short controlled list rather than a long one. Five to eight options that map to how your team actually talks, phrased so that later you can tell "not good" apart from "did not fit that brief". Both Bullhorn and Recruiterflow support customising this, and in Recruiterflow reasons can only be archived rather than deleted, so old records keep their history when you tidy the list. Do not launch a database cleanup project. Those are unbillable, diffuse, and small agencies never finish them.

Does AI re-scoring my own candidate base trigger the AI hiring laws?

Assume yes if it ranks or scores people, then check your jurisdictions. NYC's Local Law 144 explicitly reaches employment agencies using such a tool on behalf of employers to screen NYC-based candidates, and requires an annual independent bias audit, a public summary, and candidate notice. Illinois has required notice since 1 January 2026. The EU's high-risk employment obligations were pushed to 2 December 2027 by the Digital Omnibus, and Colorado's replacement framework starts 1 January 2027, so two of the four deadlines people were braced for have moved back. The constant across all of them is unglamorous: notice, a human making the final call, and a record showing it.

Should I just do this in ChatGPT or Claude with an export of my base?

For one role, honestly, yes, and several recruiters I talk to do exactly that. Export the last eighteen months, paste the brief, ask which reject reasons no longer apply. It works and it costs nothing. What you are rebuilding by hand each time is the structure: assembling the export, keeping criteria consistent across roles and across your team, keeping the base current so next quarter's role can use it, and having a record of what was decided and why. If you are happy rebuilding that per role, keep doing it. That is the honest comparison and it is a real one.

---

Regulatory positions and vendor behaviour in this article were read from primary sources in August 2026: ICO recruitment and selection guidance, vendor help documentation, the BLS Employee Tenure release for January 2024, and current status of the NYC, Illinois, Colorado and EU instruments named above. Laws and products both change, sometimes quietly. Confirm current status before you rely on any of it, and take legal advice on your own situation rather than mine.

Related reading: the shift to AI-native recruiting · how to search your own candidate database · how to reactivate your candidate database · candidate rediscovery software, three machines under one label · ATS for a small recruitment agency