An ATS, a CRM and a spreadsheet: which one is right?

None of the three, and that is exactly the problem. The useful question is not how many systems you pay for, it is how many places hold the same fact. Every copy ages at its own speed, none of them warns you when it starts lying, and whoever discovers the gap is almost always a client.

We argue the same thing about agents: the right metric is not how many of them there are, it is how many places your context is copied. The problem is older than AI and concerns your software first, with the difference that divergence between an ATS and a spreadsheet has been running for years without anybody ever calling it an incident.

How many tools do you actually have?

More than you think, and far fewer than you run, which is the interesting part.

Available measurements put the number of HR and recruiting applications an organisation runs at around fifteen, with roughly nine applications per enterprise in the Sapient Insights surveys. An analysis of interviews conducted by a vendor across more than eight hundred agencies gives a higher figure still, some twenty tools mentioned, against four to six genuinely opened each day. That figure comes from a supplier and I give it with that reservation, but the gap it describes is one everybody recognises on the ground.

That gap is the subject. The tools nobody opens any more do not disappear, they go on holding addresses, statuses and notes somebody will eventually consult and believe. A shared spreadsheet that tracked three assignments in 2023 is still being opened by a new joiner in 2026, precisely because it is faster than the ATS.

To that add the broader finding: 76% of organisations report suffering from data silos and 68% work on disconnected platforms. In other words divergence is not an implementation accident, it is the normal state of an organisation that has not decided otherwise.

The real cost is not the licence

It is in the recopying, and it is paid in the time of people whose hours are expensive.

One vendor puts it at ninety minutes per recruiter per day spent copying candidate records, client notes and billing information from one system to another. The figure is self-interested and I do not take it at face value; what is verifiable in your own firm, though, is how many times the same information is entered twice, and watching one person work for a day establishes it.

The visible cost stops there. The invisible cost is elsewhere, and it shows up as incidents that never look like a data problem. A candidate submitted twice to the same client by two consultants who were not looking at the same record. Account ownership disputed internally because two systems name two owners. A wrong availability date that leads somebody to promise an impossible start. Each of those is treated as human error, and each was a divergence between two copies.

The rule that settles it: one fact, one owner

Every fact has an owning system, every other copy is read-only, and synchronisation runs in one direction. It is short, it is dull, and I know of nothing else that holds.

We apply exactly that rule to our own code, where it is written out in full and checked at every review: every piece of information exists in one place, everything else references it. The reason is the same in both worlds. A fact with two representations is a fact that can contradict itself, and the contradiction is always found by a user rather than by a test.

What it demands in practice fits in three decisions, taken once and written somewhere new joiners read. Which system owns a candidate’s status in a process, which system owns the client relationship along with its commercial owner, and which system owns a consultant’s availability and assignment end date. The choice itself matters less than people think; what breaks an organisation is half the team updating one and half the other.

When a copy is genuinely necessary, and there are good cases, it gets declared as one. You say which of the two prevails, you make it run in a single direction, and you write it next to the field. A documented copy is a design; a copy nobody declared is a bug waiting.

The same rule decides what Balt writes at a client: it does not copy a fact from one system into another, it goes and reads it where it prevails, at the moment it is asked. That is slower than an overnight sync and it avoids creating one more copy, which is the only progress that counts here.

Why the spreadsheet always comes back

Because it wins on the only criterion that matters at the moment somebody opens it: it is faster than the official system.

A consultant tracking eight candidates on an urgent assignment picks thirty seconds of spreadsheet over four screens in an ATS, and they are right in the moment. Banning the tool changes nothing about that calculation, it simply moves it out of sight: the same mechanism as the clandestine use of unauthorised tools, which mostly proves no suitable tool was provided.

The answer that works is less ambitious than a ban and more effective. You accept the spreadsheet for what it is, a working draft, you give it an explicit lifespan, and you decide what has to go back into the owning system at the end. An acknowledged draft that gets emptied harms nobody; a draft that became permanent is a source of truth nobody declared.

What an agent plugged into this changes

It reconciles nothing, and that is what to keep in mind before connecting it.

Faced with two versions of the same fact, an agent picks one and returns a coherent, reasoned and wrong answer. It is the formulation we have argued for a long time: the better the agent, the more a bad record costs, because a human distrusts a stale record while an agent reasons on it. A forgotten spreadsheet suddenly becomes a cited source.

The corollary is more encouraging than it sounds. You do not have to clean your whole database before starting: you have to decide, for the three or four facts the agent will touch, which of your systems prevails. That is a decision rather than a data project, it takes one meeting, and it pays off immediately even if you never connect an agent at all.

It also makes the access question secondary but real: the system named as owner still has to answer, which brings you back to what an agent needs from an ATS.

Should everything be consolidated into one system?

It is the most effective answer to the copy problem, and it has a price worth stating.

A single system removes the question by construction: there is only one place a candidate’s status is written. In exchange, a tool covering ATS, CRM and billing is rarely the best at all three, and switching systems is a heavy project that costs months of productivity before returning any.

So the honest trade-off is not “consolidate everything or nothing”, it is deciding how many copies you accept to maintain and who answers for them. Two systems with a one-directional sync and a named owner work perfectly well. Five systems with no owner never work, whatever the integration budget.

If the question is live in your firm because the stack has become unmanageable, it calls for comparison work this blog does not do. We publish Cobalt, which brings together the ATS and the CRM of this trade, and its blog compares recruitment software for agencies and IT services firms with the seriousness the subject deserves. What Balt does is different and complementary, and the boundary between the two is described in Cobalt and Balt.