// Recruitment Technology, Recruitment Strategies
Why Your Consultants Still Keep a Spreadsheet Beside the CRM
Published: 02 October 2026,
8 min to read
The bottom line
The spreadsheet your consultants keep beside the CRM is a precise piece of unpaid product research. Every column in it names a view, a filter, a note field or a pipeline report your system cannot produce. Audit those files before you ban them, because the columns are the specification for the CRM your team needs.
Side files outlive every CRM rollout
Ask a consultant on a billing desk to open the file they actually work from on a Monday morning. It is rarely the CRM.
A CRM spreadsheet sitting next to a six-figure system reads like a training failure. Most agency leaders treat it as one. The usual response is a policy. No side files, everything in the system, spot checks every month. The files go quiet for a quarter. Then they come back, because nothing about the need that created them has changed.
Those columns are a list of requirements. Almost nobody reads them.
What does the CRM spreadsheet beside your system actually record?
Four things, in most agencies. A working view of live roles, and the context behind a candidate that no system field holds. Then a forecast the system will not assemble, and a list that can go to a client without a rebuild.
None of that is exotic. Each one is a job the consultant must finish before Friday. The file beside the system is the shortest route to finishing it.
The pattern is not confined to a handful of agencies. Atlas research with more than 1,000 agency recruiters found that 56.16% describe their recruitment technology setup as functional but fragmented. The tools work individually. People move between them to complete a single task. A side file is what that fragmentation looks like at desk level.
- A live-roles view, filtered the way that desk works rather than the way the system ships.
- Free-text notes the system has no field for, such as why a candidate will not move below a number.
- A recruiting pipeline spreadsheet for the Monday meeting, assembled by hand because the CRM reporting tools need a ticket and a wait.
- A client-ready list that can be sent without being reformatted first.
Why does banning the side file make your CRM data quality worse?
Because the work carries on somewhere you cannot see it. A policy moves the file from a shared drive onto a laptop. The agency loses its only map of what the system is missing.
Then the second-order costs arrive.
The European Spreadsheet Risks Interest Group collects the research on this. It finds that around 50% of spreadsheet models used operationally in large businesses have material defects. Detection is weak too. Across ten studies, 1,025 participants found an average of 60% of the errors in the spreadsheets they examined. A forecast built from a hand-keyed Excel spreadsheet is wrong in ways nobody catches in a Monday meeting.
The compliance exposure is quieter and more expensive.
Candidate and client data held in an untracked file has no user permissions, no audit trail, no version history and no deletion schedule. When the consultant leaves, that data goes with them. Or it sits on a drive long after it should have been cleared. The same split creates data silos across a recruitment business. Two systems hold the same pipeline, and the team trusts neither.
Manual data entry is the tax every desk pays for the gap, levied twice. Once into the system, once into the file beside it. That double handling is the clearest sign that CRM adoption is failing for structural reasons rather than cultural ones.
How do you read a shadow spreadsheet as a requirements document?
Collect the files first, with no penalty attached to handing one over. You get honest copies only once, so make the first ask the safe one.
Then work through them in order. The finished list is shorter than anyone expects, and it was written for free by the people who use the system every day.
- Column-map every file, writing each column as the question it answers for that desk.
- Count how many desks repeat the same column, because anything that appears on four or more desks is a product gap rather than a personal preference.
- Sort each gap into one of two piles: something the system could already do but nobody configured, and something the system has no way to capture.
- Date every file and record how often it is updated, since a daily file is load bearing and a quarterly one is probably dead.
- Give each confirmed gap a named owner and a decision, either configure it or replace the system that cannot deliver it.
What would a CRM have to do for the spreadsheet to close on its own?
Produce any view on request. Capture context without anyone typing it. Hold the history, and keep it current enough that the next consultant trusts it. Clear those and the side file stops earning its place.
The first is a reporting problem.
Describe a report in plain language and get it back as a live chart. That removes the main reason a forecast gets rebuilt in Excel every week. This is how custom recruitment dashboards work inside Atlas. The platform is an AI-powered CRM that uses agentic AI to strip admin out of agency workflows. You describe the breakdown you want, by consultant, by team, by desk or by stage. The dashboard takes shape as you ask for it. Charts update in real time, so the Monday number comes out of the system.
The second is a capture problem.
Free-text context ends up in a side file because typing it into a system is slower than remembering it. An AI note taker that joins the call and writes the record removes that trade. Ocean Red Partners credits it with lifting discovery meetings converted into live roles from 50% to 75%. The same consolidation let the firm drop several external tools.
The third is memory.
Every email, call, meeting and note attaches itself to the record. That is the work of total recall of your recruitment data and the AI agents that keep it current. A dormant database stops being the place where context goes to die. A consultant who trusts the record stops keeping a private copy of it.
Frequently asked questions (FAQs) on shadow spreadsheets and CRM adoption
Usually they signal a capability gap rather than a knowledge gap. A consultant who builds a side file has already learned the system. They know exactly what it will not give them. If the same columns appear across several desks, the shortfall sits in the product or the configuration. More training will not close it.
A ban removes the evidence without removing the demand, so the files move somewhere less visible. Collect and audit them first, fix what the audit exposes, and the files close on their own. Retiring a file because the system now does the job holds far better than retiring it by policy.
Map each column to the question it answers, then count how often that column repeats across desks. Separate gaps the system could already fill with configuration from gaps it has no way to capture. Note how often each file is updated, because the daily ones carry real operational load.
A standalone file sits outside your user permissions and your retention schedule, with no audit trail attached. You cannot prove who accessed a record, and you cannot reliably delete it on request. Those files also leave the business when the consultant does. The exposure lasts long after the desk is handed over.
It can remove most of the reasons one gets created. Dashboards generated from a plain-language prompt handle the reporting gap, and automated note capture handles the context gap. What remains is genuinely new work, which is worth building into the system rather than keeping on the side.
Rank them by how many desks share the gap and how often the file is touched. A column that appears on eight desks and gets updated daily is costing the business hours every week. A column one consultant updates each quarter can wait, or be closed deliberately with an explanation.
What the desk looks like once the side file closes
The spreadsheet beside the CRM is the cheapest requirements research your agency will ever be handed. Read the columns. You have a list of what the system must produce before anyone trusts it with their desk.
The week changes when those gaps close. The forecast gets pulled instead of built. The context behind a candidate is already on the record. The hour spent reconciling two versions of the same pipeline goes back into calls and client work. Putting that week within reach is what Atlas is built for.
If your team still keeps a file beside the system, those columns are worth an hour this week.
