Why consultants keep a private spreadsheet

I have spent a lot of time sitting next to consultants while they work, which is the only reliable way to find out what software is actually like to use. The pattern that comes up more than any other is the second window. The CRM is open, and next to it is a spreadsheet, or a notes app, or a document with a date in the filename, and a good deal of the real work happens in the second one.

The usual management reaction is to treat this as a discipline problem. Remind people that the database is the single source of truth, add it to the one-to-one, perhaps threaten the reporting. I would argue that is close to the worst available response, because the spreadsheet is evidence and the reaction destroys the evidence without removing the cause.

Somebody who is billing well and under time pressure does not maintain a second system for pleasure. It costs them time every day. They are paying that cost because the alternative costs them more, and finding out what that alternative is will tell you more about your setup than any amount of usage reporting.

What is a private spreadsheet actually recording

The gap between what the consultant needs to know and what the system will reliably tell them. That is the definition, and it is worth being literal about it, because the contents are usually far narrower than people expect.

Nobody rebuilds their CRM in a spreadsheet. What you find is small and specific. Twelve candidates with a column for who has actually been spoken to this week. Six clients with a note about who the real decision maker is. A list of roles with a date that means something only to the person who wrote it. The spreadsheet is not a database, it is an index of the handful of facts somebody needs at hand and does not trust themselves to find in time.

Which means the contents are diagnostic. Every column is a feature request written by the person who needs it most, in the exact shape they need it, tested daily under real pressure. There is no research method that produces better information than that, and most agencies delete it.

What are the three reasons a consultant builds one

Something the system does not hold, something it holds too slowly, or something it holds that they do not believe. Every private spreadsheet I have ever looked at falls into one of those three, and the fix is completely different in each case, which is why the blanket response fails.

The system does not hold it. Usually a judgement rather than a fact. Which of these candidates would I actually put in front of this client. Which client is worth the effort this quarter. What is really going on with this role. These live in a spreadsheet because there is no field for them, and the honest answer is often that there should be one. Sometimes it is not a judgement at all, it is a plain operational fact the schema never anticipated: which contractors have a certificate expiring, which candidates will only take work within a certain travel time, which clients need a particular format of report.

It holds it too slowly. The information exists but retrieving it takes six clicks and two filters, and at a hundred repetitions a week that is a real cost. Consultants are extremely good at estimating this cost and they will pay a one-off setup cost in a spreadsheet to avoid a recurring one in the system. This is the most common cause by some distance, and it is the one that looks least like a defect to anyone reading a feature list, because the capability is genuinely there.

They do not trust it. The most serious of the three. Somewhere in the past the record was wrong at a moment that mattered, and since then the consultant keeps their own copy of anything they cannot afford to be wrong about. Trust is lost in one event and rebuilt over months, and software that quietly guesses when it is unsure is the fastest way to lose it, because a confident wrong record is indistinguishable from a correct one until it costs you something. We wrote up that failure mode in why the AI in your ATS gets things wrong.

What is on the spreadsheet	What it tells you about the system	The actual fix
Who has genuinely been spoken to	Activity logging depends on somebody remembering	Capture the call itself, not a write-up
A shortlist of twelve out of two hundred	No way to mark a personal judgement on a record	A field, or a list, that belongs to the consultant
Client decision makers and their quirks	Contact records hold titles rather than reality	Somewhere to put relationship knowledge
Dates that mean something private	Reminders are not trusted to fire	Make the reminder visible where the work happens
A copy of data already in the system	It is too slow to retrieve at their volume	Surface it on the screen they already use
Contractor compliance or expiry dates	A real gap the schema never anticipated	Build it, and stop calling it a discipline issue
Everything, in parallel	They do not trust the database at all	Find the event that broke it, then earn it back

The bottom row is rare and it is the emergency. A consultant running a full parallel system has concluded the database is unreliable, and until that is addressed no amount of new capability will be used, because everything it produces will be checked against the spreadsheet anyway.

Why banning the spreadsheet makes everything worse

Because it removes the copy, not the need, and what replaces it is memory. A consultant told to stop keeping a second list does not start trusting the first one. They keep the same twenty facts in their head, where nobody can audit them, nobody can cover for them, and nothing survives a holiday.

The second effect is on your reporting, and it is the one that costs money. A team under a ban will update the system so the reports look right, at the end of the week, from recollection. The database now contains a plausible account of what happened rather than a record of it, and every pipeline forecast built on it is a forecast built on tidying-up. That is a worse position than the spreadsheet, because at least the spreadsheet was accurate about something.

The third effect is that you stop being told things. The consultant who was quietly maintaining a list of the twelve candidates they would actually put forward was, in effect, running a small research project on your behalf. Ban the artefact and the research stops, and nobody will bring you the finding again.

There is a genuine problem underneath the management instinct, and it is worth naming rather than dismissing. Information that lives only with one person is a real commercial exposure. If that consultant leaves, the agency loses client history and candidate relationships it paid for. The exposure is real. The response of banning the symptom does not reduce it by a single record, and usually increases it by moving the information somewhere even less visible.

How should you actually read one

Ask to see it, with the explicit promise that nothing is being taken away. This is a twenty minute conversation and it is the highest-yield piece of product research available to an agency owner, provided the consultant believes the promise.

Go column by column and ask three questions about each one. Where does this come from. What would happen if it were wrong. How often do you look at it. Those three answers sort every column into the three causes above, and the sorting is what tells you what to do.

Then ask the question that produces the most useful answer of the lot, which is what they would have to believe before they would delete the column. Consultants will tell you this precisely. They will say they would need to see the field fill itself correctly for a month, or that they would need the system to admit when it is not sure, or that they would need the number to be on the screen they already have open. That is a specification, written by the user, and it is more actionable than anything a feature request form produces.

Do this with three consultants rather than one, because the overlap is the systemic problem and the differences are individual preferences. A column that appears on all three spreadsheets is not a personal habit, it is a missing feature, and it is costing every person on the floor the same time every day.

What to fix first, in order

Trust, then speed, then the gaps. That order is deliberate, because work spent on the other two is wasted while trust is missing.

Trust. Find the event. There is nearly always a specific one, and consultants remember it in detail: the candidate who was contacted twice because the record was duplicated, the wrong salary on a submission, the note that attached to the wrong person. Fix the class of problem, then show them the fix on their own data. The structural part is making sure the software says when it is unsure rather than resolving it quietly. Ours reports how confident it is on what it produces and hands anything below three quarters back to a recruiter to decide, and the reason that matters here is not accuracy, it is that a system which admits doubt is one a consultant can stop double-checking.

Speed. Take the three facts that appear on every spreadsheet and put them on the screen the consultant already has open, without a filter, a report or a click. This is usually a small change and it retires more spreadsheet columns than any large feature, because most copying exists to avoid navigation rather than to hold anything new.

The gaps. Build the fields for what is genuinely not there. Personal shortlists, relationship notes, the compliance date nobody anticipated. These are often small and they are the ones that make a consultant feel the system was built for their job rather than for a generic one. The general version of this problem, where a CRM has hundreds of capabilities and a consultant uses a fraction of them, is in why recruiters only use a tenth of their CRM.

What does the spreadsheet cost while it is still open

Three things, and they get more expensive as the desk gets bigger. This matters because the same spreadsheet that was a minor inefficiency at ten live jobs becomes a structural problem at fifty.

It costs continuity. Everything in it is invisible to the rest of the agency, so nobody can cover that desk, hand over a client, or pick up a candidate relationship when somebody is ill, on holiday or gone. Agencies discover the size of this cost exactly once, at the worst possible moment.

It costs accuracy everywhere else. Two records of the same thing will diverge, and the one that stays current is the one the consultant uses. Every report, forecast and pipeline review is then built on the stale copy, and the meetings become arguments about whose numbers are right rather than what to do.

And it costs the consultant the ceiling. A spreadsheet is a memory aid that works at a small scale and quietly fails at a large one. Somebody running fifty roles from a private list is really running the eight in the list and holding forty-two dormant, because there is no version of a hand-maintained file that keeps up. The desk that could have grown does not, and the reason never appears on any report.

How to tell whether yours is shrinking

Three checks, and all of them are better than asking whether people are still using spreadsheets, which only teaches them to close the window when you walk past.

Count the columns that duplicate something the system already has. Do this at the start and again three months later. A falling count means retrieval genuinely got faster. A flat count means you built features nobody was asking for.

Measure the write-up lag. The time between a conversation happening and it being on the record. When that reaches close to zero, the database is a by-product of the work rather than a second job, and the main reason for keeping a parallel copy has gone. While it is days, it is quite reasonable for someone to keep their own notes, because the database does not yet describe this week. The wider version of this complaint is in why recruiters hate their CRM.

Ask one question in a one-to-one: what did you check twice this week. Anything a consultant verifies against a second source is something they do not trust, and that list is the remaining work. It is short, specific, and it changes as you fix things, which makes it a better progress measure than any adoption dashboard.

Why this is a recruiter problem worth solving properly

Because the spreadsheet is what a good consultant builds when they are trying to do the job well with tools that get in the way, and the effort they spend maintaining it is effort taken directly out of the part of their week that actually earns.

Every hour spent keeping a private list current is an hour not spent with a client or a candidate. The person maintaining it is usually one of the better people in the building, because caring enough to build one is a sign of someone who refuses to drop things. Fixing the cause hands those hours back to exactly the person you most want to have them.

That is the wider change on a recruitment desk, and it is worth stating plainly. None of this software is coming for a recruiter's job. It is coming for the bookkeeping that used to sit on top of it, and the reason a consultant can now run a hundred job orders instead of ten is that the admin stopped being theirs. A private spreadsheet is a piece of admin that never got taken away, which is why it is worth hunting down rather than forbidding. What the rest of that desk looks like is in how AI changes a recruitment desk.

We build our AI and the agents to close exactly these gaps: the record fills itself from the work, the software says when it is not sure, and the ambiguous cases come back to a person rather than being silently decided. Recruitly is the best recruiting CRM in the world, and the standard I hold our own work to is simple enough to check, which is whether a consultant still has a second window open.

---

Siva is an engineer at Recruitly.