Why CRM projects fail, and what to do instead

Ask a business about their last CRM implementation and you will usually hear a version of the same story. It was configured, everyone was trained, and within four months the sales team was back in a spreadsheet, with the CRM updated retroactively on Friday afternoons so the pipeline report would look plausible.

The software worked. Nobody used it. That is the failure mode, and it is almost never technical.

The root cause: systems modelled on the process nobody follows

Every business has two processes. There is the one in the sales playbook — seven clean stages, defined exit criteria, a diagram. And there is the one that actually happens, where a deal jumps from first contact to negotiation because a customer already knew what they wanted, where two salespeople share an account informally, and where the most important qualification detail lives in a WhatsApp thread.

CRM implementations are almost always built on the first process. The people who specify them are the people who wrote it. So the system demands stage transitions that do not match reality, fields that do not apply, and data entry with no payoff for the person entering it.

At that point the CRM becomes a reporting tax — work done for management, producing nothing for the person doing it. It will be minimised, deferred, and eventually faked.

Design principle: every input must return something to the person entering it

This is the single most useful rule we apply.

If a salesperson logs a call, something should come back — a scheduled follow-up, a pre-filled proposal, a reminder that arrives at the right time, a customer history they would otherwise have to reconstruct. When entering data pays the person entering it, adoption stops being a training problem.

When it does not, no amount of training or mandate fixes it. You get compliance theatre.

What we do differently

Map the real process, including the workarounds. We sit with the people doing the work and ask what they actually do, including the parts that are technically off-process. Those workarounds are the requirement, not a deviation from it.

Build fewer fields. Every field is a tax on every record. If a field will not change a decision, it should not exist. Most CRM specifications can lose a third of their fields with no loss of insight.

Automate the handoffs. Deals are lost in the gaps — between marketing and sales, between sales and delivery, between a promise and the follow-up. Automating those transitions removes work rather than adding it.

Agree definitions before dashboards. Half of all reporting disputes are two people using "qualified lead" to mean different things. Settle that first and the dashboard ends arguments instead of starting them.

Where AI genuinely helps

AI in CRM is oversold, but not uniformly. It works reliably for:

• Summarisation — turning a long thread or call transcript into the three things that matter.
• Classification and routing — sending an inbound enquiry to the right person without a human triaging it.
• Extraction — pulling structured data out of documents, emails and forms so nobody retypes it.
• Drafting — first-pass replies and follow-ups for a human to approve.

Every one of those removes work. That is why they get adopted.

Predictive lead scoring is the common counter-example. It requires more clean historical data than most mid-sized businesses have, and when it is wrong it is confidently wrong, which trains people to ignore it. We treat it with caution and say so.

Buy or build?

For most businesses, buy. A standard platform configured well and adopted properly beats a custom system nobody wanted.

Build when your process is genuinely a competitive differentiator, when per-seat licensing at your headcount exceeds build cost over three years, or when you have spent years bending a platform to fit and are still working around it.

That last one is the honest signal. If your team has built a shadow system in spreadsheets alongside the CRM, the CRM is the wrong shape.