Can you trust AI to update your CRM records?
Yes, under three conditions, and almost no product in this market meets all three. Here they are, along with how to check before you let anything write to your database.
Ask AI about this
This is the question agencies ask last and should ask first. Everything else about AI in recruitment software is a matter of convenience. This one decides whether your database is still worth something in three years.
The instinct most owners have is either to switch it all on because it saves time, or to switch it all off because it cannot be trusted. Both are wrong, and the useful position is in between and quite specific.
Condition one: it must be able to decline
A language model always answers, because producing an answer is what it does. There is no internal moment where it notices a question was unanswerable.
Left alone with your records, that means every ambiguous case gets resolved rather than flagged. The email that says send this to Sara, when you have a Sarah and a Sara Collingwood, produces a confident assignment. The CV with no dates on the last role produces a plausible date. Each of those records then sits in your database looking exactly like the ones that are right.
The fix is not a better model. It is a product that asks for a confidence figure alongside the answer, compares it to a threshold, and below that threshold writes nothing and gives the case to a person. Ours draws that line at three quarters. The number itself is unremarkable; the existence of the route out is the whole thing.
Ask any vendor to show you their software handling a genuinely ambiguous case. Bring your own, because the ones in the demo will not be ambiguous.
Condition two: you must be able to tell afterwards
Six months from now, someone will look at a record and need to know whether a human checked that value or the software inferred it. If your CRM cannot answer that, every inferred value is permanently indistinguishable from a verified one, and the whole database inherits the doubt.
This is the condition most products fail, and it fails quietly. The software writes to the same field in the same way a person does, with no mark, and a year later nobody can separate the two.
What you want is that every AI-set value carries its origin and, ideally, what the software was sure about when it set it. Then a doubt about one field stays a doubt about one field rather than spreading across everything.
Condition three: the old way still has to work
The third condition is about what happens on a bad day. Models are slow sometimes, providers have outages, and a well-built product declines rather than guesses, which means some work does not get done by the software.
In a product built properly, the previous method is still there underneath and simply runs. The recruiter may not notice anything. In a fragile one, the feature stops and somebody discovers it at four o'clock on a Thursday with a client waiting.
Ask what happens to each AI feature when the model is unavailable. It is a plain question and the answer arrives immediately from anyone who has thought about it.
Where I would let it write, and where I would not
Even with all three conditions met, I would not switch everything on at once. Some fields are cheap to get wrong and some are expensive.
| Let it write | Let it suggest only |
|---|---|
| Call and meeting notes on the record | Who owns a client relationship |
| Sorting replies by intent | Fee and commercial terms |
| Structured details pulled from a CV | Pipeline stage on a live process |
| Tags, categories and topics | Anything a client might ask you to evidence |
| Flagging a client who has gone quiet | Anything related to right to work or compliance |
The rule behind the two columns is how expensive the mistake is and how likely anybody is to notice it. A wrong tag is discovered and fixed. A wrong relationship owner quietly reroutes commission and nobody says anything for a quarter.
How to roll it out without a bad quarter
Turn it on for one thing, on one team, for a month. Pick something in the first column, ideally call notes, because the error is visible immediately and the time saving is obvious.
Then read fifty records at the end of the month, chosen at random rather than by the software. You are looking for two numbers: how often it was wrong, and how often it declined. A system that never declines is guessing somewhere, and that is worth more attention than the error rate.
Only then widen it. Every agency I have seen have a bad experience with AI in their CRM switched everything on at once and had no way to tell afterwards which values came from where.
The short version
Trust it to write when it can decline, when you can tell afterwards what it did, and when something sensible happens on the days it cannot run. Those three conditions are not difficult to build and most products do not have them, which is a statement about priorities rather than about technology.
Ask for all three, bring your own ambiguous case to the demo, and start with the cheap fields. Done that way, this is one of the few things in recruitment software that genuinely gives you hours back.
Lokesh is Founder and Head of Engineering at Recruitly.
