Poor adoption, unreliable data, weak forecasting and work happening outside the CRM can be technical problems. They can also be signs that the system is trying to represent business logic that has never been made clear.
Not which platform you use. What the system actually represents when people work in it.
Possible work becomes an opportunity, moves through a pipeline, then ends as won or lost.
That is closest to us ↓ RELATIONSHIP-LEDAccounts, contacts, emails, calls and notes are there. There is not really a fixed sequence a customer moves through.
That is closest to us ↓ HYBRIDNew business goes through a pipeline. Existing customers mostly live as accounts, contacts, notes and activities.
That is closest to us ↓This is often more revealing than whether the CRM is tidy.
There is somewhere to represent uncertainty before a formal proposal or deal exists.
Anything before that tends to live in conversations, notes or memory.
The business only sees possible work once it has already moved quite far.
The relationship may be well documented while the possible commercial change is not represented at all.
A CRM can contain a rich history of a relationship and still have no explicit place for what might happen next.
The useful question is what disappears before an opportunity is created, what the stage actually means while it is open, and what becomes invisible after the deal is won.
Two deals can sit at the same stage while procurement, technical approval, delivery capacity or stakeholder change make them fundamentally different. Existing customers may also fall outside the pipeline until somebody decides to create another opportunity.
The pipeline can be well maintained and still represent only part of the commercial reality.
The system may know every meeting, email and contact and still have no separate object for "they may buy more", "renewal is becoming uncertain", "a new stakeholder has appeared" or "this commitment changes the relationship".
Management then learns about possible work, risk or change from the person holding the relationship rather than from the system.
The CRM is not necessarily failing. It may simply have been designed to remember relationships, not represent what could happen next.
A £30k prospect may have an opportunity, stage, expected close date and owner. A £200k existing customer that may renew, expand, shrink or leave can still appear as a stable account until somebody creates a new deal.
This is one reason existing revenue can look safer in the CRM than it really is.
An existing customer is not existing future revenue.
Before fixing adoption, data or forecasting, establish what the CRM was designed to represent - and what commercial reality sits outside that model.
People do not use the CRM consistently.
Nobody fully trusts the information already in it.
Sales and Delivery hold different versions of the customer.
The forecast looks reasonable until reality arrives.
Revenue is visible, but the work created by the customer is not.
These symptoms do not prove one root cause. The useful first step is to separate a technical fault from a mismatch between the CRM model and the business.
A broken integration, duplicate records, poor permissions or an unusable interface are real CRM problems. They can and should be fixed as system problems.
But if the same issue returns after cleanup, retraining or reconfiguration, I look at the business logic underneath it: definitions, ownership, handovers, decision points and when information is captured.
Training may help if people do not understand a system that otherwise fits the work.
But low adoption can also mean the CRM duplicates another task, asks for information too late, does not support the decision people are making, or reflects a process that exists on paper but not in practice.
Before adding mandatory fields or another training session, I would separate a knowledge problem from a workflow problem and a genuine usability problem.
Duplicates, failed integrations, import errors, permissions or configuration can damage otherwise well-defined data.
Two people can enter different values correctly if the business has never agreed what a qualified lead, won deal or active customer means.
Records reconstructed after the work happened are less reliable than information captured when the relevant decision or event occurs.
A cleanup project can correct the current record without changing the mechanism that recreates the problem.
Sales can record the deal correctly and Delivery can still inherit information it cannot use.
What was promised, what remains uncertain, what is outside standard scope, which requirements affect effort and who owns the next decision may not travel with the customer.
The CRM then looks complete at the point of sale while the operational cost appears later.
Two opportunities can sit at the same pipeline stage and have very different reasons they may not close: procurement, technical approval, delivery capacity, stakeholder change or a commercial dependency held outside the CRM.
If those differences have nowhere to be recorded, changing the probability percentage does not solve the underlying information problem.
A £50,000 customer and another £50,000 customer can look identical in a sales system while requiring very different delivery effort.
Hours, rework, exceptions, senior involvement and coordination may live elsewhere. The problem is not necessarily that the CRM should become the delivery system. It is whether the business can connect the customer identity across the systems that hold the economic evidence.
Does the business agree what the important customer, opportunity, stage, risk and handover states mean?
Are the events needed to observe those states captured consistently, at the point they happen?
Does the information needed by the next function move with the customer, or have to be reconstructed later?
The same foundation matters for CRM automation and AI. A system needs explicit definitions, observable evidence and clear decision logic before scoring or automation has reliable business context.
Sometimes. But inconsistent use can also come from duplicate work, a workflow that does not match the way the business operates, unclear ownership or a system that asks people to record information after the decision has already happened.
No. Duplicate records, failed integrations and poor configuration are genuine data problems. Unreliable data can also appear when teams use different definitions or reconstruct records after the work has happened.
When configuration, permissions, integrations, duplicate records, usability or technical constraints prevent the system from doing a job the business has already defined clearly.
If the original cause sits in definitions, handovers, ownership or capture timing, improving the current records can remove the symptom without changing the mechanism that recreates it.
I research the business before the first call, then use the conversation to separate a system problem from a process, data or commercial one.
If the CRM works locally but management cannot connect it to Delivery and Finance, the Revenue Visibility Review is designed for that question.
If you are already using a named platform and want to know how this work fits around it, see the CRM and systems pages.
Free · 30 minutes · No presentation to prepare.