What is sitting in the database you already paid for?
Years of people who said yes to being on your file, and no practical way to read them.
The shape is the same on every desk we have looked at. Applicants for roles that closed in 2022. The second and third choice on a shortlist, who were good and were not placed because there was one job. People who had one conversation and were never contacted again, because the role they wanted was not open that month. Then the mess on top: the same person under three records, a mobile number that is three jobs old, a CV attached to a record with no CV field filled in.
So the advert goes out again, and it is paid for, and sometimes it finds somebody who was already there.
Cleaning that up is not only commercial. The Data Protection Commission puts accuracy among the principles in plain terms: controllers "must ensure that personal data are accurate and, where necessary, kept up to date; taking every reasonable step to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay". A database nobody reads is a database nobody is maintaining.
What exactly gets automated?
Four things, in this order, because the last one is worthless without the first.
Dedupe and clean. Records that are the same person are merged on rules you set, not on a guess. Fields are normalised so a location, a discipline and a notice period mean the same thing in every record. Records with nothing usable in them are surfaced as a list rather than left to pad the count.
Re-read the whole database against the brief. Not a keyword search. Each record is read against the brief for that specific role, so a person whose CV describes commissioning panels and fault-finding on a line surfaces for a controls role without ever having typed the words in your search box. This is the step a person cannot do at volume, and the only part of the job that needs the machine at all.
Rank, with the reasoning and the date shown. Each match comes back with a position, the line from the record that justifies it, and when that record was last touched. Age is on the face of the list, because a strong match from 2019 and a strong match from March are not the same proposition, and only the recruiter can price that.
Draft the re-approach in your voice. One message per person, naming the role and saying when they last spoke to you. It sits in a queue for you. Nothing sends on its own.
Why we will not build cold sourcing
Because we would be handing a small agency a process it cannot defend, and calling it a feature.
Start with the sentence the DPC opens its guidance with. The first question a controller should ask before processing is "What is my reason or justification for processing this personal data?", because "any processing of personal data is only lawful where it has what is known as a 'legal basis'". Scraping profiles into a database is processing. It needs a basis before the first record lands, not after somebody complains.
The basis usually reached for is legitimate interests, and the DPC's own guidance is clear about where it lives. It "is likely to be an appropriate legal basis in cases where controllers process data subjects' personal data in a way which they would reasonably expect and which would have a minimal impact on their privacy". The balancing test is put more bluntly still: "If a data subject would not reasonably expect this type of processing of their personal data, or if it would cause unjustified harm to their interests, rights, or freedoms, their interests are likely to override the legitimate interests upon which the controller is seeking to rely."
Read those against the two workflows and they separate cleanly. Someone who applied to your agency for a similar role, and was told you would keep their details, can reasonably expect a call when the next one comes up. Someone whose profile was harvested from a site they joined for another reason cannot.
There is paperwork on top. Where personal data did not come from the individual, the DPC says they must be told within a month, or "if the data is used to communicate with you, at the latest, when the first communication takes place", and told "how they obtained the personal data and whether it came from publicly accessible sources". Every scraped record carries that duty. Ten thousand of them carry it ten thousand times.
And where an approach is a marketing communication, a separate regime applies. The DPC notes that alongside the GDPR "there are rules which specifically apply to electronic direct marketing (marketing conducted by phone, fax, text message and email) which are set out in the ePrivacy Regulations (SI 336 of 2011)", and that the general rule "is that it requires the clear, affirmative consent of the recipient (such as by specifically opting-in)". The exception the DPC sets out is drawn tightly around existing customers and a similar product or service, with a chance to object at collection and in every message. Whether a recruitment approach is direct marketing at all is a question for your own advisers. Our point is narrower: the shape of that exception is a relationship and a record of consent, which is exactly what a scraped list does not have.
So we build one and not the other. It is not a capability gap, it is a choice about what we put your name behind.
What still needs a person
Two things, and they decide whether this works.
Sending. Every message is approved by a person before it goes. Approve them in a batch or one at a time, edit any of them, drop any of them, but the send is a human act. A workflow that both writes and sends is a workflow that can embarrass you at a speed no one can intervene at.
The judgement about the person. Whether it is right to ring someone you placed eighteen months ago, whether a candidate who left the sector wants to hear from you, whether the client will look at someone rejected for a similar role last year. None of that is in the record. It is in the relationship, and it is the part of the desk worth paying for.
Ranking candidates is regulated, and the position is the same one set out on the CV screening page: AI used for the recruitment or selection of people is high risk under Annex III of the EU AI Act, which is a reason to build it with the recruiter deciding rather than a reason to avoid it. That page carries the detail so this one does not repeat it.
Objections and opt-outs stay with people too. The DPC's position on the right to object to direct marketing is that "you can object at any time, and the data controller must stop processing as soon as they receive your objection", and that controllers "are obliged to notify you of this at the time of their first communication with you". The workflow records the objection and stops that person appearing in a match list again. A person confirms it happened.
Retention is yours too. What gets deleted, and after how long, is your policy and your advisers' call. We apply the rule you set, we do not invent one.
How do you know it worked?
Four numbers, and you need them before anything is built.
The proportion of placements in the last twelve months that came from someone already on file when the role opened. Most desks cannot answer that today, and the answer is usually the argument for doing this at all. Duplicate and unreachable records as a share of the book, before and after. Time from taking a brief to having a longlist of internal candidates in front of you. And the response rate on re-approach messages, plus how many of those conversations became a submission.
Take three months of history on the ones you can. If they do not move, the build did not work, and we would rather find that out on your desk than argue about it later.
One thing we will not do is give you a number for what this saves. We looked for a credible published figure on database re-mining and every one we found was written by somebody selling sourcing software. Your own baseline is the only honest measure, so we start with it.
What could go wrong, and how long this takes
Waking up records you should have deleted. A clean-up surfaces people not contacted in eight years, and a re-approach makes dormant data active again. The DPC's storage limitation principle is that personal data "should only be kept in a form which permits identification of data subjects for as long as is necessary for the purposes for which the personal data are processed". Set the retention rule first, then run the match, or the tidy-up quietly becomes an exposure.
The approval step turning into a rubber stamp. Two hundred drafts and one tired Friday afternoon is not oversight, it is a formality with a person's name on it. Batches stay at a size someone will actually read.
A re-approach that reads like a mailshot. The reason your old candidates answer you is that you sound like a person they spoke to. Voice is the asset here, and it is worth the setup time.
Ranking a record instead of a person. A four-year-old record describes who somebody was four years ago. Showing the date beside the score is the defence, and it only works if the recruiter reads it.
How long it takes. Two to four weeks for one desk. A session on what is actually in your database and how it is structured, a build tested against roles you have already filled so you can see whether the person you hired was sitting on file the whole time, a parallel run on two or three live briefs, then handover with the documentation of what runs, what it keeps and who approves the sends.
Then we leave. No retainer, you own what was built. If you want to work out whether this is the right thing to automate first, that conversation is the opportunity review, and it starts with your last five briefs rather than with software. It sits alongside interview kits, keeping the pipeline current and the paperwork after a placement. Both of us are named, with our records, on the about page.
Questions we get asked
Can I automate candidate sourcing without scraping people who never applied to us? Yes, and that is the version worth building. Your own database holds people who gave you their details and expect to hear about relevant roles. A workflow can dedupe those records, read all of them against a live brief, rank the matches with the evidence shown, and draft a re-approach for you to approve. No new personal data is collected, because you already hold it.
Is it legal to contact candidates who applied to us years ago? It depends on what you told them, what basis you hold the data on, and how long you have kept it. The Data Protection Commission's guidance on legitimate interests turns on whether the person would reasonably expect the processing. Someone who applied for a similar role usually would. Storage limitation still applies, so a record kept far beyond its purpose is a separate problem that re-contact makes visible.
Why will Time & Margin not build cold outreach or scraping tools? Because a scraped list has no lawful basis behind it and no relationship to justify one. The DPC's balancing test says that where a person would not reasonably expect the processing, their interests are likely to override the controller's. Add the duty to tell every person how you got their data, and any consent rules that apply to electronic marketing, and it is a liability we will not build for a small agency.
What does re-mining our own candidate database actually involve? Four steps. Duplicate records are merged on rules you set and fields are normalised. Every record is then read against the brief for a specific role, rather than searched by keyword. Matches come back ranked, each with the line from the record that justifies it and the date that record was last touched. Then a re-approach message is drafted in your voice, for a person to approve before it sends.
Does an AI decide which old candidates to contact? No. It ranks and explains, and it drafts. A recruiter decides who is worth approaching, edits or drops any message, and presses send. AI used for the recruitment or selection of people is high risk under Annex III of the EU AI Act, so human decision-making is the design and not a courtesy. Objections and opt-outs are recorded and honoured by a person.