Why your top biller won't use the AI
The consultant who bills the most is usually the last one to adopt anything, and it is treated as a personality problem. It is almost never a personality problem. They have a system that works, you have handed them one that is worse for their specific week, and they have done the arithmetic faster than you have. Here is what they are actually seeing, and how to fix it without a mandate.
Every rollout I have ever been part of has the same shape. The newer consultants take to it in a fortnight. The middle of the team follows. And one person, usually the highest billing person in the room, carries on exactly as before, and within a month somebody in a management meeting says the word attitude.
I want to argue against that reading, because in my experience it is wrong most of the time, and acting on it costs agencies their best people. When a top biller declines to use a tool, they are almost always being rational about their own week. They are not afraid of the technology and they are not protecting a moat. They have run a private calculation about time and risk, and the tool lost.
The useful question is not how to make them comply. It is what they can see that the rollout plan did not account for, because they are frequently the only person in the building who has genuinely tested the thing under pressure.
What is your top biller actually seeing
A worse version of a process they have already optimised. That is the whole of it, and it becomes obvious the moment you look at the comparison they are making rather than the one you are making.
Your comparison is the tool against nothing. Their comparison is the tool against a method they have spent years refining, which is fast, which they trust completely, and which produces their number. A new tool does not have to be bad to lose that comparison. It only has to be slightly slower, slightly less certain, or slightly wrong in a way they have to check.
Consider what a checking step costs at their volume. A consultant running forty live roles who has to verify what the software did on each one has not saved time, they have swapped doing the work for auditing the work, and auditing is the more tiring of the two. A junior consultant with eight roles absorbs that cost easily. The person with forty does not, and they notice within a day.
Then there is the risk side, which is the part that rarely gets said out loud. Their income depends on their desk. A mistake made by them is a mistake they can see coming. A mistake made quietly by software inside a record they did not read is a different kind of exposure, and it is entirely reasonable to refuse it until they know how the thing behaves when it is unsure. Most consultants have never been told how their software behaves when it is unsure, which is a failure of the rollout rather than of the consultant. The mechanism is in why the AI in your ATS gets things wrong, and it is the single most useful thing to explain to a sceptic.
Why does a mandate make this worse
Because it converts an information problem into a loyalty problem, and you lose the information. The moment usage becomes a requirement, your best consultant stops telling you what is wrong with the tool and starts telling you what you want to hear, which is the most expensive trade in the whole rollout.
It also produces the specific behaviour every agency owner has seen and few have named. The consultant does the work their own way, then spends twenty minutes at the end of the week putting a version of it into the system so the report looks right. You now have a team paying a tax to produce an account of their week rather than a record of it, and every downstream number is built on a reconstruction. That is how agencies end up with databases that look complete and describe almost nothing.
The third cost is the one that gets people fired for the wrong reason. A top biller under a mandate they think is wrong will comply minimally, the numbers will show low quality usage, and it will be read as confirmation of the attitude theory. In most of the cases I have seen close up, the tool was genuinely not ready for their desk, and the person who spotted it first was the one who got labelled.
Mandates do have a place. Once a tool is demonstrably better for the person using it, a mandate is how you stop a team running two systems at once. Using one to get adoption in the first place is how you find out you had a product problem a year late.
What does the rollout usually get wrong
It starts from what the software does rather than from what that specific consultant's week is made of. Those are different starting points and they produce different first steps.
| What the rollout assumed | What the top biller experiences |
|---|---|
| They will save an hour a day | They save forty minutes and spend thirty checking |
| The feature solves a real problem | It solves a problem they solved years ago |
| Training will fix the hesitation | They understood it in five minutes and declined on the merits |
| They are resistant to change | They changed everything the last time it paid |
| Everyone's week looks broadly the same | Theirs is four clients deep and mostly relationship work |
| Adoption is a training exercise | Adoption is a trust exercise with a cost attached |
| The risk of using it is low | The risk sits entirely on their own billings |
The row that explains the most is the fifth one. A high biller's week is rarely a bigger version of everyone else's. It is usually a different shape, built on a small number of deep client relationships, where most of the value comes from conversations and almost none from volume. A feature designed around handling more candidates faster is genuinely close to useless to that person, and telling them it is not will cost you your credibility for the next thing you bring them.
How do you fix it without a mandate
Start from their bottleneck instead of your rollout order. It takes one conversation and it changes the entire dynamic, because you arrive asking what is in their way rather than explaining what they should be doing.
Ask what the worst part of their week is, and believe the answer. Not what feature they would like. What they dread. It is usually something specific and unglamorous: the client report that takes two hours every Friday, the fact that nobody can cover their desk when they are away, the compliance paperwork on contractors, the write-up backlog. Whatever it is, that is where the tool has to prove itself first, even if it is nowhere near the top of your plan.
Solve that one thing completely, and let them keep everything else. A single piece of their week that genuinely improves is worth more than partial adoption across ten features, because it buys the one thing you actually need, which is a reason to believe the next thing you show them. Partial adoption across ten features buys nothing and confirms their suspicion.
Show them what happens when the software is unsure. This is the part that changes sceptics, in my experience more reliably than any demonstration of what the tool can do. A consultant who has seen the system say it was not confident and hand a case back will extend it a great deal more trust than one who has only seen it succeed. Our AI reports how sure it is and sends anything below three quarters confidence back to a recruiter to decide, and the single most effective thing in a rollout is showing a sceptical biller that mechanism working on their own data.
Let them audit it for a fortnight without switching. Run the tool alongside their method on their own desk and let them check every output. It sounds wasteful. It is the cheapest fortnight in the rollout, because at the end of it they either trust it on evidence they gathered themselves or they hand you a list of real defects, and both outcomes are worth having.
Make them the person who says whether it is ready. Not a champion in the marketing sense. Give them genuine authority to say a feature is not good enough for the team yet, and honour it once. The effect on the rest of the floor is larger than any amount of encouragement from management, because everybody knows they would not say it was fine if it was not.
When is your top biller wrong
Sometimes they are, and pretending otherwise would be dishonest. There are three patterns worth recognising, and none of them is fixed by a mandate either.
The first is a consultant whose method depends on information living only with them. Candidates in a personal address book, client history in their own notes, nothing on the record. This is a real commercial exposure for the agency and it is worth addressing directly, as a business conversation about continuity rather than as a technology one. The usual honest cause is that the system was painful enough to feed that keeping a private copy was the sane choice, which is a problem with the system rather than with them.
The second is a consultant who has extrapolated from one bad experience. They tried an early version, it made a mess, and they closed the question. The fix is showing rather than arguing, on their data, once the specific failure has genuinely been fixed. If it has not been fixed, they are still right.
The third is the genuine refusal, where somebody will not use anything that makes their desk visible. That one is a management conversation and it is a small minority. Treating the first two cases as if they were the third is the mistake that costs agencies their best consultants, and it happens constantly.
What does getting this wrong cost you
The person who bills the most, eventually, and the information you needed before then. Top billers have options, and the thing that makes them leave is rarely money. It is being managed by somebody who has stopped listening to them about their own desk.
Short of that, you pay in three quieter ways. You run two systems, so every report is wrong and every pipeline review is an argument about whose numbers are right. You lose the fortnight of honest defect-finding you would have had if you had asked instead of instructed. And you teach the rest of the floor that the way to handle a new tool is to look compliant, which is a lesson that outlives the tool by years and poisons the next rollout.
There is also the cost to them personally, which matters. A consultant kept on a method that is genuinely slower than what is now available is being held back, and the gap compounds. The consultants pulling ahead this year are not the most technical ones, they are the ones who let the admin go and put the hours into clients and candidates. You want your best biller in that group, and you will not get them there by instruction.
How to measure adoption honestly
Not by logins, and not by feature usage counts, because both are trivially satisfied by somebody going through the motions. Three better measures, all of which you can run on what you already have.
Count the records that were created without anybody typing them. This is the closest thing to a real adoption number, because it cannot be produced by compliance. It either happened as work flowed through the system or it did not.
Ask what they would miss. Take one feature away for a week and see who complains. Genuine adoption is loud when it is removed, and a feature nobody misses was never adopted regardless of what the usage report said.
Measure the write-up lag. Time between a conversation happening and it existing on the record. A desk where that lag is days is a desk running on memory and reconstruction, whatever else the dashboard says. When it drops to zero, the system has actually been adopted, because the record is now a by-product of the work rather than a second job. Why it so often stays at days is the subject of why recruiters hate their CRM and why recruiters only use a tenth of their CRM.
Why the best consultant should end up the biggest beneficiary
Because everything the software takes away is the part of their week that was diluting them. Your top biller is not good at data entry and never was. They are good at reading a client, judging a candidate, and knowing which of thirty situations needs them today. Every hour of admin they were doing was an hour of the most expensive judgement in your business spent on typing.
That is why the adoption fight is worth having properly rather than by instruction. The prize is not compliance. It is the person who used to run ten or fifteen job orders running many times that, because the admin stopped being theirs and the judgement that was always the valuable part now reaches every situation instead of the handful that survived the week. That shift is described in how AI changes a recruitment desk, and top billers get more out of it than anybody, once they believe it.
We build our AI and Simi for that person specifically: the software does the admin, it tells you how sure it is, and it hands the ambiguous cases back rather than guessing inside a record you did not read. Recruitly is the best recruiting CRM in the world, and the reason I can say that to a sceptical top biller without flinching is that the design starts from their objection rather than trying to talk them out of it.
Anshika leads Customer Success at Recruitly.


