How do you tell whether a CRM problem is really a software problem?
Describe a failed business task: someone cannot identify the current quote, reconcile duplicate accounts, retrieve order context, or close a completed opportunity correctly. Then test whether the failure comes from capability, configuration, data, or working practice. A vendor’s feature list does not establish that your team can complete the task.
Record who needed to do what, which information they expected, what happened, and the consequence. Distinguish software capability from configuration and actual use. A feature listed on a pricing page does not prove that your team can complete the task with your data.
What should you check in the data before changing CRM?
Trace the information needed for the failed task: where it originates, who enters it, where it changes, and which record should govern the decision. Check conflicting definitions and manual copies. Moving inconsistent customer, project, or status definitions into a new platform can reproduce the same problem.
If staff copy the same information into several systems, observe why. It may be an integration gap. It may also reflect incompatible definitions of customer, project, or status. Migrating those definitions without resolving them can reproduce the problem in a newer interface.
What alternatives should you test before replacing a CRM?
Compare keeping the setup, changing the workflow, reconfiguring the CRM, integrating another system, and replacing the platform. Use representative records to test whether each option resolves the actual requirement. The NATA CRM Decision Record below keeps those alternatives visible before a product demonstration becomes the business case.
| Test | Evidence to collect |
|---|---|
| Can the current tool support the task? | A demonstrated workflow with representative records |
| Would configuration solve the problem? | A tested change and its maintenance implications |
| Is another system the appropriate source? | Clear record ownership and a transfer requirement |
| Can the alternative handle exceptions? | A normal case and a failure case demonstrated |
| What does change require? | Data cleanup, migration, training, operations, and support |
This prevents a vendor demonstration from becoming the business case by default.
What should a CRM vendor demonstrate with your workflow?
Ask the vendor to complete a realistic task using redacted or synthetic records, including relevant exceptions such as an incomplete request or revised quote. Show how the next person finds current information and how transfer failures become visible. A clean demonstration should not be the only evidence for the decision.
Keep sensitive production data out of a pre-sales exercise unless the appropriate arrangements are in place. A synthetic record can test much of the workflow without disclosing a customer’s history.
What costs belong in a CRM replacement decision?
Include subscription, setup, migration, cleanup, integrations, staff time, training, maintenance, and exit costs. Identify the person who will own the system after implementation. Distinguish released staff capacity from an actual reduction in spending so the business case reflects benefits the company can substantiate.
Avoid assuming that every hour removed from data entry becomes cash saved. It may release capacity, reduce frustration, or improve follow-up. Those are valuable effects, but their financial treatment depends on what changes in the business.
When is replacing the CRM justified?
Replace the CRM when an important documented requirement cannot be met acceptably by the current arrangement and a tested alternative can meet it at a defensible total cost. Record rejected alternatives, remaining uncertainty, and a recovery route. After implementation, verify the original failed task rather than counting migrated fields.
The GOV.UK Service Standard puts user needs ahead of preselected technology. Applied to a CRM decision, that means demonstrating the work the system must support before committing to the platform.
After implementation, revisit the original failed task. Can the person now complete it with the required information? That is a stronger test than whether the new database contains all the old fields.
Frequently asked questions
Does low CRM adoption prove the platform needs replacing?
No. Low use can reflect duplicate administration, unreliable records, unclear expectations, or unsuitable software. Observe the failed task and test the current setup before selecting a new platform.
Should historical data all move into the new CRM?
Determine what the new workflow needs, which records remain authoritative elsewhere, and what retention requirements apply. Copying every old field can preserve clutter and contradictory definitions without improving the task.
What is the first test after a CRM migration?
Repeat the original task that justified the change with representative records and exceptions. Confirm that the responsible person can complete it, not only that the import finished.
Sources and case basis
This guide presents a working method, not measured client results. Examples are illustrative unless explicitly attributed. Sources linked in the text support the stated principle or published example; they do not validate the NATA worksheet as an assessed instrument. Prepared and revised November 4, 2026.