Key takeaways
- Spreadsheets are genuinely good at the early stage — flexible, free, and instantly understood.
- They break on four specific things: concurrency, ownership, history, and reminders.
- The tell is not size. It is the appearance of a second copy of the sheet.
- Moving is mostly a process exercise; the data import is the easy half.
It is worth saying plainly: spreadsheets are a legitimate way to run early sales. They cost nothing, everyone can already use one, and they bend to whatever shape your process happens to be this month. Any argument that starts with “spreadsheets are unprofessional” is not worth listening to.
The problem is narrower and more mechanical than that. A spreadsheet is a document, and a sales pipeline is a process. Four specific things go wrong at the seam.
1. Concurrency: two people, one truth
A shared sheet handles two people typing in different rows. What it handles badly is two people holding different beliefs about which copy is current. Someone downloads it to work offline, someone else filters and forgets to clear the filter, a third person duplicates the tab before a risky edit. Now there are three versions and no way to tell which is right.
The failure is silent. Nothing errors; the numbers just quietly stop agreeing, usually discovered in a meeting where someone quotes a figure nobody else recognises. A brokerage with a dozen agents working shared portal leads hits this within a week.
2. Ownership: the column that lies
Most sales sheets have an “Owner” column, and it is almost always stale. Nothing enforces it, nothing notices when a row sits unowned, and nothing objects when two rows for the same company have different owners. The column records an intention, not a fact.
The cost shows up as the thing every sales manager has seen at least once: two reps calling the same lead in the same week, or a lead nobody calls because each assumed the other had it. That is the first of the five signs a team is overdue for a CRM.
3. History: cells overwrite, they do not accumulate
This is the deepest of the four, and the hardest to work around. When a deal moves from “Demo” to “Proposal”, you change the cell. The previous value is gone. So is the date it changed, and who changed it.
That means a spreadsheet can tell you where every deal is right now, but not how it got there — which is where all the useful questions live:
- How long does a typical deal sit at proposal stage before it closes?
- Which stage do deals most often die at?
- Has this lead gone quiet, or did we simply not contact them?
- What did the customer object to the last three times we spoke?
A notes column tries to solve this and turns into a wall of undated text that nobody reads before a call.
4. Reminders: a sheet cannot chase you
A spreadsheet is entirely passive. It will happily hold a row that has had no activity for six weeks and never mention it. The follow-up discipline has to live somewhere else — a personal calendar, a task app, a rep’s memory — and whatever it lives in, it is invisible to everyone else and it leaves with the person.
What you gain, and what you give up
Moving to a CRM is a trade, and it is fair to name both sides. You give up total flexibility: a CRM has opinions about what a deal is, and you work within them. In exchange, the four failures above stop being your problem — state is enforced rather than agreed, history accumulates instead of overwriting, and the system chases the follow-up rather than waiting to be asked.
For a team of one, that trade is not obviously worth it. For a team of four, it usually is. The point where it flips is the point where you are spending real time reconciling what is true rather than acting on it.
A spreadsheet answers “what do we have?”. A pipeline has to answer “what happens next, and who is doing it?” — and that is a different kind of question.
Making the move without a painful migration
The import is the easy part — a CRM will take a CSV of your sheet. The work worth doing sits either side of it.
- Agree what your stages mean first. Write a one-line exit criterion for each. This is the whole exercise in building a pipeline that moves deals, and skipping it is why migrations feel messy.
- Clean the sheet before importing, not after. Deduplicate, drop dead rows, and fix the owner column. Importing mess produces a CRM full of mess and a team that concludes the CRM is the problem.
- Import the deals you are actually working. Historic closed-lost rows can come later, or not at all.
- Delete the sheet. Or make it read-only. Running both in parallel “just for a while” is the most reliable way to end up with neither being trusted — see why sales teams stop using the CRM.
Done in that order, most growing teams are up and running the same day rather than running a migration project.
Frequently asked questions
- Can I just build a CRM in Google Sheets?
- You can get surprisingly far with data validation, a change-log sheet and scripted reminders. What you are building at that point is a CRM with one maintainer and no support, and the effort tends to exceed the cost of a simple tool well before it is finished.
- How many leads before a spreadsheet stops working?
- There is no reliable row count, because the constraint is people rather than volume. One person tracking 500 leads in a sheet is often fine. Four people tracking 80 shared leads usually is not, because that is where concurrency and ownership start failing.
- Will I lose my spreadsheet history when I move?
- No — keep the sheet as an archive. Import the deals that are currently in play and leave closed history where it is. Very few teams go back to pre-migration rows, and keeping the archive costs nothing.