CRM best practices when the system is bought and stalling
A CRM that is not paying two years in has rarely failed as software. One of four conditions has broken, and the first move is to name which one rather than to run ten practices at once.
What a stalled CRM looks like two years in#
A stalled CRM is still running, still invoiced, and no longer trusted enough to decide anything. Nobody ever declares that. Instead it arrives one workaround at a time. Because of that, CRM best practices for a live system start from a description you recognise rather than from a checklist.
However, the signs are specific rather than moody. Someone rebuilds the pipeline in a spreadsheet before every forecast meeting. The number in the system and the number in the meeting disagree. Meanwhile deals appear in the CRM after they close, and two people quietly keep their own list.
Because these signs are countable, you can test the description this week. First, count seats paid for against seats with a login in the last 30 days. Second, count open deals whose stage last moved more than 14 days ago. Then ask which surface wins the argument in the forecast meeting.
Does the published CRM failure rate say anything about your programme?#
No. The failure rates in circulation disagree with each other, and that spread is not one fact repeated at different volumes. Each figure counted a different population, in a different year, against its own definition of the word failure.
Failure can mean a programme abandoned before go-live. It can equally mean a system that went live and never produced a measured business result. Those are different questions with different answers, so a percentage that does not say which one it counted cannot grade your tenant, and none of them is a finding of ours.
Settle the definition before you accept a verdict. Write down what this CRM would have to do for the business to be worth its next renewal, then measure against that rather than against a headline.
Four conditions: which one is broken in your CRM?#
Almost every symptom on a stalled programme routes into one of the four conditions above: design, decay, disconnection, and ownership. Treat them as a routing table rather than as a list of faults.
Route your loudest symptom into one condition before reading further. For example, notes getting shorter over time is condition one rather than a training gap. In contrast, a field list that has only ever grown is condition four.
| What you can observe this week | The condition it indicates | Who has to own the repair | What visibly changes in 30 days |
|---|---|---|---|
| Records are updated in a Friday batch, and notes get shorter over time. | The condition it indicatesOne: the record serves reporting rather than the work. | Who has to own the repairThe person entering the data, and whoever can give them something back the same week. | What visibly changes in 30 daysThe lag between a real event and its record falls. |
| A full deduplication buys a few quiet months, then the same meeting comes back. | The condition it indicatesTwo: the data decays faster than anyone repairs it. | Who has to own the repairWhoever publishes the weekly number on the three fields the forecast depends on. | What visibly changes in 30 daysCompleteness on those three chosen fields moves. |
| Three teams have each built the same export to reconcile the same two systems. | The condition it indicatesThree: the system sits apart from where the truth lives. | Who has to own the repairThe person who runs the review the spreadsheet exists for. | What visibly changes in 30 daysHow often anyone opens the reconciliation spreadsheet falls. |
| The field list has only ever grown since go-live. | The condition it indicatesFour: nobody owns the operating model. | Who has to own the repairOne named person who can refuse a field request from a senior stakeholder. | What visibly changes in 30 daysThe field count on the deal object falls. |
Therefore take the condition you routed to first, then the cost arithmetic. These CRM best practices are sequenced against that diagnosis.
Condition one: who is the record actually for?#
If your CRM was designed to report upward, the person entering the data pays the cost while somebody else takes the benefit. Because that trade is lopsided, entry quality decays, and no amount of training reverses it.
Show data table
| Segment | Value (%) | Share |
|---|---|---|
| Selling | 40 | 40% |
| Everything else | 60 | 60% |
Selling is the minority of that week, which is the week the record is asking for more of.
Writing in the Harvard Business Review in December 2018, Scott Edinger argued that CRM systems are typically built to serve management reporting rather than the seller doing the work. His analysis of why CRM projects fail (opens in new tab) sets out the case. Although it is eight years old, it still describes what a stall feels like from the inside.
In practice the test is timing rather than sentiment. Records updated in a Friday batch mean the system is a chore. Therefore the fix has to give the seller something that exists only because they entered the data. A working call list qualifies, whereas a mandatory field does not.
Condition two: is your data decaying faster than anyone repairs it?#
Data quality is a rate problem rather than a cleanup project. If records decay faster than anyone repairs them, a full deduplication exercise buys a few quiet months and then the same meeting.
Salesforce surveyed 4,050 sales professionals across 22 countries in August and September 2025 for its State of Sales report (opens in new tab). Among those respondents, 79 percent of high performers said they prioritise data hygiene, against 54 percent of underperformers. Since the publisher sells CRM software, read it as a disclosed vendor survey rather than as independent research.
Show data table
| Item | Share who said they prioritise data hygiene |
|---|---|
| High performers | 79% |
| Underperformers | 54% |
Twenty-five percentage points separate the two groups on one habit.
The CRM best practices worth running here are narrow. Baseline completeness and duplication on the three fields your forecast depends on, publish that number weekly, and change nothing else for a quarter.
Condition three: is the CRM cut off from the systems that hold the truth?#
When the CRM cannot see billing, support, or product usage, it holds opinions while other systems hold facts. Sellers then work from whichever surface is closer to the truth.
In the same Salesforce survey, 51 percent of sales leaders whose teams use AI said disconnected systems are slowing those initiatives down, and 74 percent of the sales professionals surveyed reported focusing on data cleansing. Those are two different groups inside one survey rather than one number. Consequently an integration gap first shows up as a data quality complaint, which is why it gets misfiled as condition two.
Still, the tell is repetition. If three teams have each built the same export to reconcile the same two systems, the gap is structural. Integration glue with its own maintenance rota is software nobody owns.
Condition four: does anyone own the operating model?#
Ownership means one named person who can refuse a field request from a senior stakeholder. Without that person the schema only grows, because adding is free for the requester and expensive for everyone else.
Count the fields on the deal object, the required ones among them, the active automations, and the live reports. If every one of those numbers has only risen since go-live, the condition is confirmed. Although "get buy-in" sounds like governance, buy-in is not a decision right.
Since a rollout at scale is a delivery problem before it is a CRM problem, the same phased-delivery discipline that makes enterprise software projects work applies here too.
What does the broken condition cost you every quarter?#
Compute the cost before the renewal, or the renewal gets signed on habit. Three inputs you already hold will do it: unused seats, time lost to manual entry, and forecast error against actuals.
In August 2023 Nucleus Research published a return of $3.10 for every dollar spent on CRM (opens in new tab), and set it against $4.90 a decade earlier on the same basis, a decline of 37 percent. Its separate 2014 publication (opens in new tab) reported $8.71 per dollar on a different basis, so it is not the upper end of that decline and Nucleus does not read it as one. The useful reading is not the multiple. It is that a dollar of CRM spend cannot be assumed to behave the way the dollars in your original business case did.
$4.90
A decade before 2023
$3.10
2023
A dollar of CRM spend cannot be assumed to behave the way the dollars in your original business case did.
| Option | return per dollar spent on CRM |
|---|---|
| A decade before 2023 | $4.90 |
| 2023 | $3.10 |
Source: Nucleus Research, August 2023
Seats are the easiest of the three inputs to negotiate, which is why they get negotiated first. Which of the three is actually largest is a question only your own numbers answer, so run all three before the renewal is decided on the licence line alone.
Here is the arithmetic the model below runs, on a 13 week quarter. Every term is a number you already hold, except the last one, which is a judgement you set yourself.
Put your own numbers in, then read which line is largest
Unused licences
$11,970 a quarterTime lost to manual entry
$195,195 a quarterForecast error against actuals
$120,000 a quarterTime lost to manual entry
$195,19578 people x 3.5 hours a week x 13 weeks x $55 an hour
Forecast error against actuals
$120,000$4.0M forecast x 12% error, a quarter of the miss carried
Unused licences
$11,97042 seats with no login x $95 a month x 3 months
The largest line this quarter is time lost to manual entry#
Entry time leadingOn your numbers the licence line comes third of three, at $11,970 against $195,195 for time lost to manual entry. That makes the largest line about 16 times the licence line, and the licence line 4 percent of the total. Seats are the easiest of the three to negotiate, which is why they get negotiated first. Run all three before the renewal is decided on the licence line alone.
| Cost line | Rank | This quarter | How it is computed |
|---|---|---|---|
| Time lost to manual entry | 1 of 3 | $195,195 | 78 people x 3.5 hours a week x 13 weeks x $55 an hour |
| Forecast error against actuals | 2 of 3 | $120,000 | $4.0M forecast x 12% error, a quarter of the miss carried |
| Unused licences | 3 of 3 | $11,970 | 42 seats with no login x $95 a month x 3 months |
Modelled, not measured. Every figure above is your own input run through the arithmetic stated beside this model, on a 13-week quarter. The third line rests on a judgement you set rather than on a measurement, so treat it as the softest of the three and check the first two against your billing and your payroll before you take any of it into a renewal.
A worked example: routing one symptom to one condition#
Here is the routing rule applied once, on an illustrative company rather than a client account.
The symptom: her weekly pipeline review always starts with a spreadsheet.
An operations director notices it, and her first instinct is a data cleanup.
Decay is not the driver.
Completeness is unchanged since go-live, so records are not decaying faster than anyone repairs them.
Billing status lives in the finance system.
It is pasted into the CRM by hand every Monday, which is the join the review actually depends on.
Therefore this routes to condition three rather than condition two.
As a result the work is one integration and one retired spreadsheet, owned by the person who runs the review. The cleanup she was about to fund would have changed nothing.
CRM best practices that survive contact with a live system#
The CRM best practices worth funding on a live system have a named owner, a number that already exists, and a single habit change. Everything else is a transformation programme in disguise.
Four hold up in practice, and each repair fixes exactly one condition. That is the property that makes these CRM best practices orderable: you can only sequence repairs that each answer a different question.
If configuration genuinely cannot express what your business does differently, you are at the build-versus-off-the-shelf decision that derails a lot of these programmes.
Which repair comes first?#
Fix the condition your forecast depends on first, because that is where the cost concentrates.
- Repair 1
Connect the system that holds the truth before cleaning the copy.
Cleaning data inside a disconnected system repairs a copy while the source keeps drifting.
- Repair 2
Give the person entering data something back the same week.
It has to be something that exists only because they entered the data. A working call list qualifies, whereas a mandatory field does not.
- Repair 3
Measure decay on three fields rather than auditing all of them.
Baseline completeness and duplication on the three fields your forecast depends on, publish that number weekly, and change nothing else for a quarter.
- Repair 4
Name one person who can say no to a field request.
Naming an owner before the exchange rate improves gives that owner nothing to enforce, which is why this one comes last rather than first.
Governance last is not a demotion, because it is what stops the first three repairs being undone within two quarters.
When should you stop investing in this CRM?#
Stop when the condition you named cannot be owned by anyone inside the company. That is the honest exit, and it is a legitimate answer rather than a failure of judgement.
Three signals argue for stopping. Nobody will accept ownership of the schema. The process the system models has changed twice since go-live and will change again. Or the workarounds now cost more than the system, and a parallel process already exists that you would have to dismantle.
Besides, two situations make these CRM best practices the wrong starting point. If you have not gone live yet, greenfield advice genuinely serves you better. If the product is not selling, the CRM is only the messenger, and a quarter spent on adoption is a quarter not spent on the real problem.
Although a rebuild is sometimes correct, it inherits every unnamed condition from the system it replaces. Therefore read what a custom build like this typically costs before you commit a budget.
How do you know within 30 days that the repair is working?#
Every one of these CRM best practices should move one number within 30 days. Pick a number that already exists and watch its direction. A measure you have to build first is not a test, because building it becomes the project.
Each condition has an obvious candidate, and the routing table above carries them in its last column. For condition one, watch the lag between a real event and its record. Completeness on three chosen fields covers condition two. Condition three is how often anyone opens the reconciliation spreadsheet, and condition four is whether the field count fell.
Direction beats level. Therefore a number rising for two quarters beats a higher one that has fallen, because the higher number is often the one hiding the stall.
Where these CRM best practices take you next#
Route by what you diagnosed rather than by the size of the problem. If you named a condition and it has an owner, the work is internal. Therefore run the 30 day test first, and resist opening a second workstream.
If the diagnosis landed on fit rather than on habit, the platform may be the wrong shape for your business. In that case you can read how we approach custom CRM development when you want a second view.