Candidate Data Decay: What a Stale Recruitment Database Actually Costs
- Illumini
- 2 days ago
- 4 min read
Updated: 1 day ago
Candidate data decay is the rate at which records in a recruitment CRM stop being true. The record itself never changes. The person it describes carries on changing jobs, numbers and salary expectations without telling anyone.
Take a candidate registered in March 2024 with a job title, a salary expectation, a mobile number and a work email address. By now they have probably changed at least one of those, quite possibly all four. The record still looks complete. Every field is populated, the CV is attached, the notes are there. That is the awkward part, because a stale record and a current one look identical on screen.
Which fields go first
They do not all decay at the same speed, which matters when deciding what to check.
Work email addresses fail immediately and completely. The day a candidate leaves an employer, the address stored against their record stops working, and most agencies store the work email because that is what was on the CV. Personal addresses last longer. Mobile numbers are the most durable field an agency holds, which is why a database with good mobile coverage retains value even when much of the rest of it has gone out of date.
Job title and employer both break at the same moment, on a job change, and they break in a way that is worse than a blank field. An empty field prompts a consultant to go and check something. A field that is confidently wrong just gets believed.
Salary expectations decay more quietly. Someone who wanted £55,000 two years ago will not want £55,000 now, and the stale number is the reason a consultant scrolls past them for a £68,000 role. Availability, notice period, location and right to work status all move on their own schedule, without anyone being notified.
Decay hides people rather than just misleading you
The obvious cost of a stale field is a wasted call. The larger one is a search that never surfaces the right person at all.
Boolean search runs against fields as stored. A candidate whose record says Junior Analyst, because that was their title in 2022, does not appear in a search for senior analysts, even though senior analyst is now exactly what they are. They are sitting in the system, they are probably the best match in it, and the search cannot reach them.
Nobody counts this, because there is no way to notice a search result you never received.
The cost you pay twice
Agencies routinely buy job board credits and licence seats to source candidates already sitting in their own CRM. The record existed. It was either unfindable, for the reason above, or untrusted.
Distrust is the more expensive of the two. Once a consultant has rung five stored numbers and reached three dead lines, they go back to the job board, and that is a rational decision on their part. The database then gets used less, which means it decays faster, which means it produces even less. Most agency databases are somewhere inside that loop, and the loop usually gets blamed on consultant behaviour rather than on data.
The compliance angle
UK GDPR sets out an accuracy principle and a storage limitation principle. Personal data should be accurate and kept up to date where necessary, and should not be held for longer than is needed for the purpose it was collected for. Most agencies process candidate data on the basis of legitimate interests, which carries an expectation that the processing remains justifiable over time.
A database that is never enriched or reviewed drifts in the wrong direction on both counts. It grows, while the proportion of it you can evidence a reason to hold shrinks. Records accumulate that nobody has verified, contacted or reviewed in years. If the ICO ever asks when a particular record was last checked, "we do not track that" is a difficult answer to give.
The commercial waste and the compliance exposure come from the same root, which is that nobody owns the question of whether a record is still true.
Why manual updating never happens
It is nobody's job, and the incentives make sure it stays that way.
Consultants are measured on billings this quarter. Updating a record that will not place this month is the most rational thing on the list to skip, so it gets skipped, more or less universally, without anyone ever deciding to skip it. Data cleaning projects tend to appear after a system migration or when a new operations hire arrives, run enthusiastically for six weeks, and then stop. Calling that a discipline problem misses what is going on. Nothing that only pays back in twelve months survives contact with a monthly target.
Working out your own decay rate
You can measure this in an afternoon.
Check what proportion of your records were last modified more than 12 months ago.
Check what proportion hold a personal email or a mobile, rather than only a work address.
Pull a random sample of 100 candidates registered two years ago and manually verify where each one works now. The proportion that have moved is your decay rate. Apply it to the full database.
Put that number next to your job board and licence spend for the same period, and estimate how much of it went on candidates you already had.
Most owners have never run the third step. The result is usually higher than expected, and it is the only version of this number that carries any weight internally, because it came from your own data rather than a vendor's.
What candidate enrichment does about it
Candidate enrichment is the process of automatically updating and augmenting existing CRM records against current information, rather than asking a consultant to re-verify them by hand.
Illumini's Candidate Enrichment works against records already held in Bullhorn, Vincere or Itris, updating employer, job title and contact fields on a cycle. It runs in the background, so records are enriched whether or not anyone remembers to do it, and consultants see the result as better shortlists rather than as another system to log into.
The database as a depreciating asset
An agency's CRM is usually the largest sunk cost on its books and the only significant one carried at full value indefinitely. Every other asset gets a depreciation schedule. Data does not, partly because nobody agrees on the rate, and partly because the loss never appears in a management account.
It turns up elsewhere instead. Shortlists take longer, job board spend creeps up, and experienced consultants quietly decide it is faster to start from scratch.




Comments