The CRM Isn't the Problem
"We're looking at switching our CRM."
Usually the third one. Sometimes the fourth.
Occasionally the tool really is wrong — it can't do something fundamental, the pricing has become absurd, it's being discontinued. That's maybe one in ten.
The other nine times, the new CRM will be disappointing in about four months, for the same reasons as the last one.
What people actually mean
Listen past the stated reason and it's nearly always one of these:
"Nobody updates it." The records are stale, so reports are wrong, so nobody trusts them, so nobody updates it. A loop that's already closed.
"We can't get anything useful out of it." Reports that don't answer the questions you have.
"It's a mess." Duplicate records, inconsistent data, forty custom fields of which six are populated.
"It doesn't do what we need." Occasionally true. Usually it means it isn't set up to.
None of these are properties of the software. All of them follow you to the next one.
Why nobody updates it
The most common complaint, and the most misdiagnosed. It isn't discipline.
The stages don't match reality. If a pipeline has stages like "Send proposal" — a task, not a state — people can't tell whether a half-done thing counts. So records don't move.
It takes too long. Twelve required fields to log an enquiry means the enquiry gets logged later, then not at all.
It doesn't give anything back. A system that only takes input is extra work. One that surfaces what needs attention today is a tool. Most CRMs are configured as the first.
There's a shadow system. Someone's spreadsheet, or the owner's memory. While the real answer lives elsewhere, the CRM is a reporting obligation, not a source of truth.
Change the tool without changing these and the new one is stale by Q2.
Why the reports are useless
The data isn't structured. A free-text source field produces "Facebook," "FB," "facebook ads" and "social" as four different sources. No tool can report on that.
Nothing is required. Fields that are optional are mostly empty, and a report built on half-present data is worse than no report, because it looks authoritative.
You're asking a question the data was never set up to answer. The classic: "why do people say no?" There's no lost-reason field, so there's no answer, and there never will be retrospectively.
Nobody acts on them. If a report is produced and nothing changes as a result, it isn't a reporting problem. It's a decision problem.
Why it's a mess
No deduplication rule. Nobody decided what makes two records the same, so the system can't prevent duplicates and nobody merges them.
No naming convention. "Acme Ltd", "ACME", "Acme Limited" are three companies as far as search is concerned.
Field sprawl. Every time someone wanted to track something, a field appeared. Now there are forty, most are blank, and the blanks make the populated ones look unreliable.
Tag sprawl. Same mechanism, worse, because tags multiply faster. Two hundred tags, four of which mean "interested."
Every one of these is a decision that was never made. A new tool is a clean slate for about three months, after which the same decisions get not-made again.
What actually fixes it
In this order, and most of it before touching any software.
1 · Decide the pipeline
Five to seven stages. Each one a state, not a task. For each: what makes a record arrive, what makes it leave, and how long it can sit there before it's stale.
That last one is what stops a pipeline becoming a graveyard.
2 · Decide what "lost" means
How long without a response before a record is closed? Pick a number.
Without it, nothing ever leaves the pipeline, the total inflates, and the forecast becomes fiction.
3 · Cut the fields
Default to removing. For each one: what decision does this change? If nothing, it's a note.
Six well-populated fields beat forty mostly-empty ones.
4 · Require the few that matter
Two or three per stage transition. Including lost reason, which is the single most valuable field in any CRM and the one most often missing.
Six months of lost reasons will tell you more about your sales process than any analysis of the deals you won.
5 · Make it give something back
A view that shows what needs attention today. Records with no next action. Records past their stage limit.
The moment the CRM tells people what to do rather than only asking them what they did, updating it stops being a chore.
6 · Write the one-page procedure
When to create a record, what's required at each stage, when things get closed. One page.
Then train people on the procedure, not the software.
Do this first, whatever you decide
If you're seriously considering a switch, do the six steps above in your current system first.
Two outcomes, both good:
It gets better and you stay. You've saved a migration and learned what you actually needed.
It's still wrong, and now you know precisely why. You migrate with a specification instead of a hope, and the new system is set up correctly from day one.
Either way you've done the work that determines the outcome. The work the migration was going to let you avoid.
When switching is right
For completeness, because sometimes it is:
- It genuinely can't do something you need, and you've confirmed that rather than assumed it
- Pricing has moved beyond what the value justifies
- It's being discontinued or no longer supported
- It can't integrate with something central to your operation
Notice none of these are "it's a mess."
A CRM records the organisation you already have. If the structure is undecided, a new tool is a clean place to be disorganised.
Thinking about switching?
A free systems audit covers your current structure and whether the problem is the tool.