A CRM, or the spreadsheet
The spreadsheet is not the problem. The problem arrives the week a third person needs to write to it, and that moment announces itself clearly enough to plan around.
In short
A spreadsheet is the right tool until more than one person needs to write to it, or until something has to happen automatically when a field changes. Those are the two thresholds. Below them a CRM adds cost and admin for nothing. Above them the spreadsheet stops being a record and becomes several copies that disagree. The common failure is not moving late, it is buying a CRM and never deciding who updates it and at what point in their day.
The six real options
A spreadsheet, honestly maintained
Fast, free, and understood by everyone. Perfectly adequate for one person tracking a manageable list, and it stays adequate for longer than most software vendors would like.
A shared database tool
The middle ground: multiple editors, real field types, views per person, and light automation, without the weight or the process assumptions of a full CRM.
A proper CRM
Earns its place when several people write to the same records, when history has to be attributable, and when something needs to happen automatically as a deal moves.
The CRM you already pay for
Frequently there is one, bought for a reason nobody remembers, configured to about ten percent. Switching it on properly is faster and cheaper than evaluating anything new.
Neither, fix the follow up
If deals are lost because nobody followed up on day three, no tool fixes that. A named owner and a scheduled time beats any amount of software, and it works this week.
A CRM nobody updates
Not an option anybody chooses, and the most common outcome anyway. It is worse than the spreadsheet, because the reports look authoritative and are quietly wrong.
Why the CRM usually fails at the same point
The spreadsheet gets blamed for a problem it did not cause. It works perfectly well for one person holding a list in their head and writing it down. What breaks it is a second and third person needing to write to it in the same week, at which point it stops being a record and becomes several copies that quietly disagree.
That is the real threshold, and it announces itself. Somebody asks which version is current. Two people update the same row on the same afternoon. A deal is followed up twice, or not at all, because each of them assumed the other had it. None of that is a software problem yet, but it is the moment the software question becomes legitimate.
The second threshold is automation. When something has to happen because a field changed, a spreadsheet needs a person to remember, and people reliably do not. A reminder on day three is worth more than any report, and it is the single feature that most often repays a subscription.
What derails the move is almost never the choice of tool. It is that the process was never written down, so the CRM gets configured against whatever the loudest person believes the stages are. Six weeks later the fields do not match how the work happens, updating it feels like paperwork, and it stops.
That is the state worth avoiding, because it is strictly worse than the spreadsheet. The reports still render. They look official. They are built on records last touched two months ago, and somebody makes a resourcing decision on them.
The order that works is unglamorous. Write down the five stages the work actually moves through. Name who updates the record and at what point in their day. Then pick the simplest tool that supports exactly that, which is frequently something already paid for and switched off.
Spreadsheet or CRM
Eight factors, read across. The first row settles most cases on its own, and the last row explains why so many CRM projects end up worse than what they replaced.
| Factor | Spreadsheet | CRM |
|---|---|---|
| People writing to it | One comfortably. Two with discipline. Three is where it breaks. | Any number, with a record of who changed what and when. |
| History | Whatever version history captured, which nobody ever opens. | Every change, attributable, with a timeline on each record. |
| Automation | Manual, or a script one person wrote and only they understand. | Native. Something happens when a field changes, without anybody remembering. |
| Reporting | You build it, and rebuild it each time the sheet changes shape. | Standard reports that stay correct as the data grows. |
| Direct cost | Effectively nothing. | A subscription per person, plus setup, plus the time to train people. |
| Indirect cost | Time spent checking which copy is current, and deals lost in the gap. | Admin nobody enjoys, unless the tool visibly makes their day easier. |
| Time to useful | Minutes. | Days, and far longer if the process was never written down. |
| How it fails | Two versions, both edited, neither correct, and nobody notices for a month. | Nobody updates it, so the reports are confidently wrong and decisions get made on them. |
A spreadsheet that is honestly maintained beats a CRM that nobody updates, every time. The decision is not about capability, it is about how many hands touch the record and whether anything has to happen on its own.
Five questions before you buy anything
These take an afternoon between them. The third and fourth are the ones that decide whether the tool survives contact with the team.
- How many people write to it in the same week?One is a spreadsheet. Two is a spreadsheet with an argument coming. Three or more editing the same records is the clearest signal there is, and it arrives before anybody names it.
- Does anything need to happen automatically?A reminder on day three, a task when a stage changes, an email when a form is filled. If yes, that is the case for a system rather than a sheet, and it is usually a stronger case than the reporting.
- Can you describe your process in five stages?Write them down before evaluating anything. A CRM configured against a process nobody agreed on encodes the disagreement, and then every report inherits it.
- Who updates it, and when in their day?Name the person and the moment. After every call, or at the end of the day. A CRM without that answer becomes an expensive archive of last quarter within about six weeks.
- What are you already paying for?Check the tools you already have before buying. The finding is routinely that one of them does most of this and was configured to a fraction of its capability because nobody was given the job.
Questions we get
When exactly should we move off the spreadsheet?
When a third person needs to write to it, or when something has to happen automatically as a record changes. Either one on its own is enough.
Revenue and headcount are poor triggers. Plenty of large companies run parts of the business on a sheet perfectly well, and plenty of small ones needed a system a year ago.
Which CRM should we pick?
Almost always the simplest one that supports the process you wrote down, and preferably one you already pay for. The differences between the mainstream options matter far less than whether people update it.
Evaluate against your written stages rather than against feature lists. Feature comparisons are won by whoever has the longest list, not by whoever fits.
Our team will not update the CRM. What do we do?
Find out what it costs them. Usually it takes too long, it asks for fields nobody needs, or it gives them nothing back. All three are fixable and none are a discipline problem.
The version people update is the one that saves them time on the same day they use it. If it only serves reporting upward, it will keep being abandoned.
Can we keep using a spreadsheet alongside a CRM?
For analysis, yes, exporting and slicing is normal. For anything anybody writes to, no. Two places to update means one of them is always wrong and nobody can tell which.
Pick one system as the source. Everything else reads from it.
How long does moving take?
The data import is a day. Agreeing the stages and who owns updates takes longer and is the part that decides whether it works.
If somebody quotes a migration in hours, they are describing the import and not the change.
Is a database tool enough instead of a CRM?
Often, yes, particularly for a small team with a process that does not look like a standard sales pipeline. You get multiple editors, real field types and light automation without the assumptions.
The limit shows up when you need sequences, call logging and forecasting as first class features rather than as things you build.
What should we do before buying anything?
Write the five stages down and agree them out loud, then check what the tools you already pay for can do. Both take an afternoon.
This routinely removes the purchase entirely, and when it does not, it makes the setup dramatically faster.
What is the single most valuable feature?
A reminder that fires on the third day. Most lost deals are not lost to a competitor, they are lost to nobody following up, and that one automation repays a subscription faster than any report.
Everything else is useful. That one is the reason to move.
More in the guides and every answer in one place.