← Blog

August 5, 2026 · Fedor Erashev, Founder, Gemsift

How to reactivate your candidate database without burning it (2026)

How to reactivate your candidate database without burning it (2026)

Every agency owner I talk to has the same sentence somewhere in the conversation. "We have thousands of candidates in there and we barely touch them."

It is a fair thing to be annoyed about. You paid for those people twice already. Once in job ad spend or sourcing time to get them to apply, and once in the hours you or your team spent reading them. Then they went into the system and the system became a place things go rather than a place things come from.

So you decide to reactivate the base. And this is where most agencies get hurt, because the obvious version of reactivation is the one that damages your list, your domain reputation and your name with the exact people you were trying to win back.

This is the process I would run instead. It assumes you are a small agency, one to twenty people, with a real base and no time.

Contents

Quick summary

  1. Reactivation fails at selection, not at sending. Almost every article on this subject is about campaigns, sequences and nurture. But candidates get angry because the wrong person got the message, not because a message arrived. Fix the picking and the sending gets easy.
  2. Start from a role, never from the list. "We have new opportunities" is the message that kills lists. One specific brief, one specific reason per person.
  3. Your database being searchable is not the same as the right people being surfaced. Keyword and boolean search return the people you already knew to look for. The strongest person in your base is usually the one whose old resume does not use the words you are typing.
  4. Freshness check before outreach, always. A candidate from eighteen months ago may be placed, moved, or in a different career. Sending them a role they are no longer eligible for is how you lose them permanently.
  5. There is a hard legal and deliverability floor. Gmail expects bulk senders to keep spam complaints under 0.30% and to offer one click unsubscribe. In the UK, legitimate interests does not let you ignore PECR. If AI is doing the picking, the ICO's position is that human involvement has to be real, not a rubber stamp.
  6. Sometimes the honest answer is do not bother. If your base is tiny, very old, or in a vertical where situations change every few months, an hour of fresh sourcing beats an hour of archaeology. I say who should skip this below.

Why should you listen to us?

I build Gemsift, an AI-native ATS for recruitment agencies. Our whole product is built on re-reading an existing candidate base against each new role, so I have an obvious interest in you believing your base is valuable. Take the tool recommendation with that in mind.

What I think is worth your time is the research underneath, because most of it came from being told I was wrong. When we first started pitching this idea, the opener said something close to "your database is not searchable". Two recruiters corrected that in the same week. One agency recruiter told me plainly that his entire database is searchable and he rarely starts from scratch. An in-house recruiter on a heavily customised iCIMS told me past applicants are easy to resurface and are already housed under old and similar positions.

They were both right, and that killed a version of our positioning. It also produced the one insight this whole article rests on, which I get into below. A third recruiter, in-house, told me something even more useful: her team had passed on candidates who could have been hired months earlier, and she was actively fixing it, but the fix was not in her ATS at all. It was in the decision process and in revisiting sourced people. So the pain is real and it is frequently not where the software vendors say it is.

None of the numbers in this article are invented. Where I could not find a source I trust, I say so instead of quoting a benchmark. Several widely circulated statistics about database decay turned out to have no traceable methodology behind them, so you will not find them here.

Reactivation is a selection problem, not a sending problem

Read enough vendor content on this topic and you will notice all of it lives on the sending side. Sequences. Drip campaigns. Nurture streams. SMS cadences. Re-engagement automation.

That is the wrong end of the problem. Nobody has ever been annoyed by receiving one relevant, specific, well-timed message about a job that suited them. The complaints, and they are remarkably consistent across review sites and recruiting forums, are all about relevance:

  • A senior person sent a junior role.
  • A permanent candidate sent a contract role.
  • Someone who moved city two years ago sent an onsite role in the old city.
  • A similar job title in a completely different domain.
  • Somebody who already got placed, by you, being invited to apply again.

Every single one of those is a selection failure that automation then amplified and delivered at scale. The sequence tool did its job perfectly. It sent the wrong thing to the wrong person very efficiently.

Which means the useful question is not "what should my re-engagement cadence be". It is "how do I decide who actually fits this brief, out of four thousand people I have not looked at in a year".

The trap: "my database is already searchable"

Here is the insight that came out of being corrected.

Every capable recruiter believes they have this covered, and in a narrow sense they do. They have boolean search. They tag properly. They house past applicants under similar positions. When a role comes in they search, and results come back, and the results are not bad.

The problem is what search is structurally able to return. Keyword and boolean search return people who used the words you typed. Position-based resurfacing returns people whose previous job title resembles the new job title. Both of those return the obvious re-fits.

The candidate you most want out of an old base is almost never an obvious re-fit. It is the person who did the work but described it in their own words. It is the career changer whose title is wrong and whose substance is right. It is the strong applicant who was runner-up for a role that was not quite the right shape, in a vertical you have since stopped covering.

That person is invisible to the search that makes you feel covered. And they are invisible in a specific, nasty way: you cannot feel the loss, because a search that never returns them never tells you they were there. There is no error message for the candidate you did not see.

This is the same mechanism I wrote about in why keyword filters keep rejecting good candidates, except applied backwards in time. On fresh inbound, the filter buries someone this week. On an old base, the filter has been quietly burying the same person every time you searched, for two years.

So the test to run on yourself is not "is my base searchable". Everyone says yes to that. The test is: when did your search last surprise you with someone you would have missed?

Where recruiters actually feel this pain

One honest caveat before the process, because it changes who this article is for.

When I have asked recruiters where the missed candidates actually go missing, they mostly do not say "in my database". They say it happens in the decision, and in not going back to people they had already sourced and talked to. One told me directly that the candidates her team wrongly passed on were not from the ATS at all.

That matters for two reasons. First, if you are hoping a database tool will fix a process where good people get passed over in interviews, it will not. Nothing you buy fixes that. Second, it tells you which segment of your base is actually worth working: not the oldest and coldest records, but the people you already engaged with and did not place. They are the highest yield part of any base, and they are the part most reactivation campaigns dilute by blasting everyone.

The six steps

Step 1: Pick the role first, never the list first

If your reactivation project starts with "let's do something with the database", it will end badly. The only version of this that works starts with a live brief, ideally one where you know the client will actually move.

The reason is mechanical. A specific role gives you a specific bar, which gives you a defensible reason to contact each person, which is the difference between a message someone replies to and a message someone reports as spam. "We have new opportunities" carries no reason. It is also, in the UK, much closer to direct marketing than to a genuine one to one approach about a job, which matters legally. More on that below.

Step 2: Cut the base to a segment you can defend

Before any reading or scoring, slice the base into something you can justify touching. In priority order:

  1. People you interviewed or submitted and did not place. Your silver medallists. Highest yield in the whole base by a wide margin.
  2. People who applied in the last six to nine months, whatever the role.
  3. Contractors whose known availability window is coming up.
  4. Everyone else, and be honest that this tier is mostly archaeology.

Then subtract, hard: already placed by you, do not contact, anyone who unsubscribed, anyone with a client conflict, and duplicates. Duplicate records are the single most common source of the embarrassing double message, because two recruiters at the same agency work two copies of the same person.

Step 3: Re-read for transferable fit, not matching titles

This is the step the whole article is about, and it is the step that is genuinely hard by hand.

You are not looking for people whose old application matches this role. Those you would have found with search. You are looking for people whose substance fits the role even though their old resume does not say the words. Someone who ran the exact migration this client needs but called it something else. Someone whose title was junior at a small company where they were in fact doing the whole job.

Doing this properly means actually reading against the role, including the unwritten parts of the brief that never make it into the job description. That is fine on eighty people and impossible on four thousand, which is exactly the gap software should close and mostly does not. Most "AI matching" features in ATS products still anchor on title similarity, which reproduces the same blindness as boolean search with more confidence and a percentage next to it. The documented failure modes are consistent: title anchoring, semantic overreach where "project manager" and "product manager" collapse into each other, no suppression of already placed people, and old profiles ranking high despite being stale.

Whatever you use, human or machine, insist on one thing: a reason per person, in plain English, that you can read and disagree with. A number on its own is not reviewable, and as I get to below, unreviewable scores are becoming a compliance problem as well as a trust problem.

Step 4: Freshness check before a single message goes out

You now have a shortlist. Do not send yet.

I could not find a credible, methodologically transparent study giving a precise decay rate for agency candidate records, and I am not going to repeat the numbers that circulate without one. What is not controversial is the direction. People change jobs, cities, salary expectations and work authorisation quickly, and contact data goes stale with them.

The closest sourced proxy is business contact data. ZoomInfo's own 2026 research puts contact data decay at 25 to 30 percent a year, and attributes the majority of it to job title changes, meaning a ten thousand record database loses two and a half to three thousand usable contacts a year without upkeep. That is sales contact data rather than candidate data, so treat it as a direction not a measurement. But the driver, people changing jobs, is precisely the thing that makes a candidate record wrong.

So verify before you send:

  • Email validity, so you are not generating hard bounces.
  • Current employment, via a quick look at their public profile. Anyone who started a new job in the last few months usually comes off the list.
  • Anything role critical that expires: work authorisation, certifications, location.

This step feels like admin and it is the step that protects everything else. A bounce hurts your sender reputation. Pitching a role to someone who took another job three months ago tells them you never really knew them.

Step 5: Write one message that proves you remember them

The message is not the hard part once selection is right, but two things matter.

First, lead with the reason. Not "we have a new role", but the specific thing about their history that made you pick them out of thousands. That sentence is only possible to write if step three was done properly, which is a useful test of whether it was.

Second, ask before you pitch. The strongest first touch is usually an update request rather than a full sell: here is why I thought of you, here is the one line version of the role, do you want the details. It gives the person an easy exit, which lowers your complaint rate, and it gets you fresh data on someone whose record was stale.

A shape that works:

You interviewed with us last year for a [role] and were the runner up. A new brief has just come in at [location, type, band] and the part that made me think of you is [the specific thing they did]. Want me to send the details, or shall I update your preferences and leave you be?

Then keep it to a maximum of two or three touches, spaced out, and stop. Segment by role type so you are never sending one blast to a hundred and fifty unrelated people.

Step 6: Protect the list

Two hard floors here, one technical and one legal.

The technical one is real and specific. Google's bulk sender guidance tells senders of more than 5,000 messages a day to keep spam complaint rates reported in Postmaster Tools below 0.30%, and recommends staying under 0.10% for resilience. Marketing and subscribed messages have to support one click unsubscribe with a visible link. You do not need to be at bulk volume to care, because the underlying reputation mechanics are the same at any size: a burst of complaints from an old list degrades whether your future emails reach anyone at all, including your good candidates and your clients.

The legal floor is the next section.

The legal floor, UK and US

I am a founder, not a lawyer, and this is not legal advice. But there are a few things worth knowing before you email two thousand people, because they change the plan rather than just adding paperwork.

UK and EU. There is no single statutory retention period for candidate records. The ICO's position is that retention has to be necessary, proportionate and justified, and its recruitment guidance says that without a clear business reason you should not keep records for unsuccessful applicants beyond the period in which a claim from the recruitment process could be brought, which in the UK is six months. Keeping a base for eighteen months or two years is not automatically unlawful, but it does mean you need a documented reason and a privacy notice that says so.

Agencies commonly rely on legitimate interests to hold and re-contact candidates, and that can work. The trap is PECR. The ICO is explicit that where PECR requires consent for electronic marketing, legitimate interests does not rescue you, and using it anyway makes the processing unlawful. The more your reactivation looks like a broadcast about your services and the less it looks like a genuine approach about a specific relevant role, the closer it drifts to direct marketing and the more exposed you are. Which happens to point in exactly the same direction as the advice in step one.

United States. CAN-SPAM is the floor for commercial email: accurate headers, no deceptive subject lines, a valid physical postal address, a working opt out that you honour promptly. Beyond that it depends on where you and the candidate sit. California's CPRA covers employment related personal information, and Colorado and Texas have their own regimes with their own thresholds, several of which small agencies fall below.

If AI is doing the picking, read this bit. The rules on automated decisions do not exempt candidates just because they are already in your database. Under New York City's Local Law 144, an automated employment decision tool is one that substantially assists or replaces human discretionary decision making, and using one triggers an annual independent bias audit, a public summary of the results, and notice to candidates ten business days in advance. Nothing in that framing distinguishes a fresh applicant from a stored one. If a score is what decides who gets considered, the honest reading is that re-scoring your own base is in scope, and you should ask counsel rather than assume it is not.

The UK direction of travel is the same. In a report published in March 2026, drawing on evidence gathered from more than thirty employers between March 2025 and January 2026, the ICO found employers describing tools as decision support when the decision was in fact fully automated, and said human involvement has to be meaningful and active rather than a rubber stamp. It also wants transparency delivered at the right moment rather than buried in a privacy notice, and a route for candidates to get human review. An earlier ICO audit of AI recruitment tools found some of them collecting far more personal information than necessary and retaining it indefinitely to build large candidate databases without the candidates' knowledge, which is worth sitting with if your reactivation plan involves buying a tool that hoards.

The practical translation is short. Keep a human making the call, keep the reasoning visible so the human can actually overrule it, and be able to explain to a candidate what happened. That is good practice anyway. It is now also the compliance posture.

When not to bother reactivating

The strongest honest case against this whole exercise, since I would rather you not waste the afternoon:

  • Your base is small and you know it personally. Under a few hundred candidates in a niche you cover closely, you already are the index. Software adds nothing you do not have.
  • You work a high churn, high volume vertical. Industrial, hospitality, entry level admin. Situations change every few months and an eighteen month old record is fiction. Fresh inbound wins.
  • The role has genuinely moved. New stack, hybrid where it was onsite, comp band shifted materially. Your old base was assessed against a job that no longer exists.
  • Your records have no notes. If all you have is a parsed resume and no record of what the person wanted, you cannot write a message that proves you remember them, and you will fall back to the generic blast that starts the damage.
  • Your real problem is downstream. If good candidates die in your interview process or in client feedback loops, mining the base just delivers more people into the same leak.

"Your database is an asset" stops being true at the point where most of it is unreachable and irrelevant. Then it is a liability with a storage cost and a compliance surface. Work the top slice, and let the tail go.

What the tools actually do here

Three different things get sold under this heading and they are not substitutes:

Nurture and engagement automation. Sense, Bullhorn Automation (formerly Herefish), Clinch, Talkpush, Gem. These are sending tools. Campaigns, sequences, SMS, drips. They are good at what they do and they solve the second half of the problem. Buy one if your selection is already good and your problem is throughput of contact.

Sourcing and rediscovery platforms. hireEZ, SeekOut, Beamery. Strong search over internal plus external talent, generally built for larger teams. Worth naming honestly: if your issue is that you have too many candidates to read, adding an engine whose job is to find more of them does not help.

Agency ATS platforms with matching features. Recruiterflow with AIRA, Loxo, Manatal, Crelate, Recruit CRM, JobAdder, Vincere, Bullhorn, Zoho Recruit. Most now have a version of "run this role against the base". The differences that matter are whether it fires automatically on every new role or waits for someone to remember to press a button, whether the AI lives in a tier that publishes a price at all, and whether it hands you a reason or a percentage.

I have deliberately not restated competitor prices here, because they move and a stale number in a how to guide is worse than no number. The tier by tier figures, verified against vendors' own pricing pages, are in AI-native ATS for recruitment agencies, which exists to answer exactly that question. The short version from that research: for several of these vendors the published price buys the filing cabinet, and the thing that reads it sits in a quote only tier.

Where Gemsift fits, honestly

Gemsift is an AI-native ATS for recruitment agencies whose current system has become a filing cabinet. You move in with one export file, and it re-reads your whole candidate base against each new role, returning a client ready shortlist with a plain English reason per pick. On reactivation specifically: the re-read fires automatically when you open a new job rather than waiting for you to remember, and it is in every plan including the free one, not gated behind a quote.

Prices as of August 2026, and you should confirm them on the site since they can change: Free at $0 for a base of 100 people with no card, Solo at $99 a month for 1,000, Agency at $299 a month for 5,000 with three seats, Scale from $899 for larger bases. Annual billing takes two months off. You can run it on our sample data without uploading a single real resume, which matters if client confidentiality means you cannot trial tools on live candidate data.

Where it is not the answer, plainly:

  • You need heavy integrations, job board posting or enterprise compliance tooling. Keep a traditional ATS. This is not that, and pretending otherwise wastes your time.
  • You are a pure outbound headhunter. Your problem is finding people who never applied to you. That is sourcing, and you want hireEZ or SeekOut, not us.
  • Your volume per role is in single digits. You can read ten people yourself. You do not need software to tell you who to call.
  • Your base has no notes and you want relationship history back. We can read what is in the documents. We cannot recover a conversation nobody wrote down.

If your problem is the one at the top of this article, four thousand people you paid for and cannot see into, that is the problem the product exists for.

Start free, no card

FAQ

Do I have to clean up my candidate database first?

No, and if a vendor tells you that you do, ask why their tool needs your data pre organised to be useful. Gemsift reads raw resumes rather than depending on tags and field hygiene, so a messy export still works. What you do need before outreach is the suppression list: already placed, do not contact, unsubscribed, duplicates. That is not data cleaning for the software's benefit, it is protecting your list.

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

Two things, usually. When it fires, and what it hands you. Most ATS matching waits for a person to press a button on a specific role, and returns a ranked list with a percentage. The question worth asking your current vendor is whether the re-read happens on every new role without anyone remembering to trigger it, and whether you get a reason you can read and overrule rather than a score you have to trust. If the reasoning is not visible, you cannot exercise the meaningful human review that the ICO now expects.

My database is already searchable. Why would I need this?

Because searchable and surfaced are different things. Boolean search returns people who used the words you typed, and position based resurfacing returns people whose old title resembles the new one. Both work well for obvious re-fits. The candidate worth finding in an old base is usually the one whose substance fits and whose vocabulary does not. Useful self test: when did your search last surprise you with someone you would have missed?

Half the resumes in my base are AI-written now. Won't AI just be fooled by them?

That is the problem this is built for. Gemsift looks at what someone actually did rather than how polished the writing is, cross checks claims against the work history, and flags generic filler and inconsistencies for your review. An AI-written resume is not a weak candidate, so nobody gets disqualified for looking AI. The point is that the strong person who wrote plainly does not sink to the bottom.

I already do this in Claude or ChatGPT. Why would I pay for a system?

If you already paste role context into a model for each brief, you have proved the point: that context is what makes the call good. What you would pay for is the part you rebuild by hand every time. Structure, so you are not reassembling prompts and files per role. Consistency, so the same bar applies across four thousand records and across your whole team rather than one careful chat. A base that remembers, so the re-read happens on the next role without you starting over. If a tuned setup already gives you all of that, keep it.

Is my candidate data safe?

You can evaluate the product on built in sample data without uploading a single real resume, which is the honest answer for anyone under client confidentiality rules. If your agency has data governance requirements, ask us for a data handling summary covering where data lives and how long it is kept before you upload anything, and export or delete whenever you want. I would rather you evaluate it safely than break a policy to try it.

How long can I legally keep candidates in my database in the UK?

There is no fixed period. The ICO expects retention to be necessary, proportionate and documented, and its recruitment guidance says that without a clear business reason you should not hold unsuccessful applicant records beyond the window in which a claim could be brought, six months in the UK. Longer retention for future opportunities is common and can be lawful, but it needs a stated purpose, a justified period, a privacy notice that says so, and an easy opt out. Ask a data protection adviser about your specific setup rather than copying another agency's policy.

Related reading