What does keeping everyone informed cost you today?
Not one big block of time. Fifteen small ones, and they land in the gaps where the actual work was supposed to go.
A candidate messages on Tuesday to ask whether there is any news. A client rings on Wednesday to ask where the shortlist is. Neither of those conversations moves the role forward by an inch, and both of them have to be answered, warmly, by the person who is in the middle of writing a brief. Then Friday arrives and the CRM gets an hour so that Monday's pipeline is not a work of fiction.
The honest way to describe the cost is that a recruiter's week splits into judgment and typing, and on a calendar the two look identical. Nobody bills separately for the second one.
There is one published figure worth putting beside that, and it is British. Totaljobs surveyed 748 HR leaders and People Management reported on 19 August 2025 that "Recruiters spend an average of 17.7 hours per vacancy on administrative work", including "2.5 hours scheduling interviews and another three hours processing post-interview notes", with manual data entry named by 61 per cent of them as a common issue. That research is UK, not Irish, we found no Irish equivalent, and it is an order of magnitude rather than a promise.
The number that matters is yours. Take your live candidates this morning and ask, for each one, how many days since they last heard anything from you. The worst answer on that list is the size of the problem.
What exactly gets automated?
Four things, and the fourth is the only one anybody notices.
Capture. The call, the meeting, the CV sent, the interview booked, each landing against the right record from your mail and calendar without anyone retyping what already happened. The record becomes a by-product of doing the work rather than a second job that happens after it.
Surfacing the silence. Every live candidate and every open role carries a date for when they last heard from you. Anything past the gap you set appears on a list. That is the whole trick, and it is unglamorous: silence is hard to remember and easy to measure, so it gets measured.
Drafting the update. The client update and the candidate update, written from what the record holds, in your format, with the facts already in place. Who is at what stage, what moved this week, what you are waiting on and from whom. The recruiter is editing a draft that is already accurate instead of assembling one from memory and a mailbox.
The summary that used to be Friday. The pipeline view for a role, or for a desk, assembled rather than typed up by whoever is still at their desk at five.
Why will we not let the system decide a candidate's status?
Because inferred status is where these builds go wrong, and it goes wrong loudly.
A system that reads your inbox and concludes things will eventually read "we will come back to you next week" and mark a candidate rejected. It is not a stupid reading. It is just wrong often enough to matter, and the wrongness does not sit quietly in a database. It becomes a status, the status becomes a drafted message, and the message goes to a real person who was still in the process. You do not get to un-send that, and the candidate tells other candidates.
So the machine proposes and the recruiter confirms. A suggested stage change arrives with the email or the calendar entry that prompted it sitting beside it, which makes accepting it a second's work and correcting it two seconds. That ratio is the design. Oversight that costs more than doing it yourself is oversight that gets switched off inside a month.
There is a data protection reading of the same point. The Data Protection Commission's summary of the accuracy principle is that 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", and it adds that "controllers should accurately record information they collect or receive and the source of that information". A guessed status is an inaccurate record about a named person, held in your system, under your name.
Where an update carries the outcome of an assessment rather than a scheduling fact, the position on AI in recruitment decisions is set out in full on the CV screening page, and this page does not repeat it.
What still needs a person?
The messages that carry a decision, and the rules that everything else runs on.
The rejection. What you say to someone who did not get the job, and how quickly you say it, is most of what they will remember about your agency. It can be drafted. It is not sent unread, and if a rejection is the only thing on the list that you write yourself every time, the page has still done its job.
The bad news to a client. That the role will not fill at that rate, or in that location, or with that job title. That is a judgement about a relationship and a market, and it does not belong in a status field.
The rules underneath. Which record wins when the same person exists twice, what counts as gone quiet for a two-week contract as against a six-month search, which client wants a weekly note and which wants to be left alone until something happens. You set those at the start and you change them when the desk changes.
The send. Approve in a batch or one at a time, edit any of them, drop any of them, but a person presses send. Anything that both writes and sends can embarrass you faster than you can intervene.
Retention is yours as well. Automatic capture makes a pipeline record grow faster than a manual one ever did, and 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". What gets deleted, and when, is your policy and your advisers' call. We apply the rule you set.
How do you know it worked?
Four numbers, and you want them before anything is built.
The longest gap on the board: for every live candidate, days since they last heard something from you, and specifically the worst one rather than the average, because the average hides exactly the person who is about to withdraw. The proportion of live records whose stage is actually true, checked by hand on a sample of twenty, which almost nobody has ever measured and which is usually the finding that starts the conversation. Time from something happening to the client knowing about it. And the count of inbound "any update?" messages in a week from clients and candidates combined, because that is the number this workflow exists to reduce.
Take three months of history on the ones you can reconstruct. 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.
We will not give you a figure for what this saves. Every published number we found for CRM automation and recruiter admin was written by somebody selling the software, and the one honest figure we do carry is British and labelled British. Your own baseline is the only measure worth having.
What could go wrong, and how long does it take to put in?
Updates that say nothing. A weekly note that reads "no change" for three weeks trains a client to stop opening it, and then the one that matters goes unread too. An update earns its place by carrying a fact or asking for a decision. If there is neither, the honest thing is to send nothing and say so at the start.
Capturing more than you need. Point a capture rule at a mailbox and it will happily hoover up a personal thread, a supplier argument and a conversation about someone who is not a candidate at all. The DPC puts data minimisation as processing that is "adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed". Scope the capture to the roles and the records it is for, at build time, not after the first surprise.
A file you would rather not hand over. Under Article 15 a candidate can ask what you hold. The DPC lists what they get: confirmation that their personal data is being processed, a copy of it, and, where the data did not come from them, "any available information as to its source". The controller must act "within one month of receipt of the request", extendable "by two further months" where the request is complex. Automatic capture makes that bundle considerably bigger, which is a good reason to write notes you would be content to read back to the person they are about.
One report per client, invented weekly. Every client asks for their update in a slightly different shape, and a workflow that says yes to all of them stops being a workflow. Agree the format once, per client, at the start.
How long it takes. Two to four weeks for one desk. A session on what your clients and candidates actually ask for and how often they ask. A build tested against roles you have already run, so you can see which chase it would have prevented. A parallel run on two or three live roles while you update people the way you always have, so the comparison is real. Then handover, with the documentation of what captures, what it drafts and who approves it.
Then we leave. No retainer, you own what was built, and you can change a threshold without calling us. 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 roles rather than with software. It sits alongside the database you already have and the paperwork after a placement.
Questions we get asked
Can a recruitment CRM update itself? Most of the typing, yes. Calls, emails and meetings can be captured against the right record without anyone retyping them, records that have gone quiet can surface on a list, and the client and candidate updates can come back drafted from what the record holds. What a system should not do is decide a candidate's status on its own. A recruiter confirms every stage change before anything goes out.
How do I keep candidates updated without typing every message? Draft from the record, approve in a batch, send. Each live candidate carries the date they last heard from you, and anyone past the gap you set appears on a list with a message already written from where they actually stand. You edit or drop any of them. The messages that carry a rejection are the ones worth writing yourself, and the workflow leaves those to you.
Should an AI decide when a candidate's status changes? No, and this is the part of these builds that goes wrong most often. A client saying they will come back next week is not a rejection, and a system that reads it as one will send a real person the wrong message. Ours proposes a change, shows the email it read, and waits. A recruiter accepts or corrects it, which takes seconds and keeps the record true.
Can a candidate ask to see what our CRM says about them? Yes. Under Article 15 of the GDPR a person can obtain confirmation that their personal data is being processed, a copy of that data, and, where it did not come from them, any available information as to its source. The Data Protection Commission says a controller must act within one month of the request, extendable by two further months where the request is complex.
How long does it take to set up automated pipeline updates on one desk? Two to four weeks. A session on what your clients and candidates actually ask for and how often, a build tested against roles you have already run so you can see what it would have caught, a parallel run on two or three live roles while you update people as normal, then handover with the documentation of what captures, what it drafts and who approves it. No retainer.