The pattern
CRM implementations almost never fail on technology. They fail because nobody owned it, the process was never defined, the data was never cleaned, and adoption was assumed rather than supported. Every one of those is a management problem wearing a technology costume.
We have been called into enough struggling implementations to see the same causes repeatedly. None of them are about the platform.
The six causes, in order of frequency
| Cause | How it presents | What it actually is |
|---|---|---|
| No internal owner | "IT set it up and left" | Nobody responsible for it working |
| Undefined process | Endless configuration debates | The business never agreed how it works |
| Poor data | "Nobody trusts the reports" | Migration without cleaning |
| No adoption support | Low usage after month two | Training was a one-hour demo |
| Over-customisation | Fragile, slow to change | Every request said yes to |
| Wrong success measure | "Is it working? Nobody knows" | No baseline was captured |
No owner is the root cause behind the others
An implementation without a named internal owner who has allocated time drifts. Nobody decides between conflicting requests, nobody notices adoption falling, nobody maintains the data. The consultant leaves, and the system slowly becomes something people work around.
- A named person, not a committee.
- Genuinely allocated time — this is not an addition to a full role.
- Authority to say no to customisation requests.
- Accountability for adoption metrics.
- Continuity after the implementation partner leaves.
If nobody internally can be given this role, that is important information. It does not mean proceed with a partner instead — it means the implementation will drift once the partner leaves, which is a reason to reduce scope until it is small enough to be owned part-time.
Configuring an undefined process
A recognisable symptom: configuration decisions that cannot be made because the business does not agree on the process. Teams describe different sales stages, disagree on what qualifies a lead, and expect the CRM to resolve it.
A CRM encodes a process. If the process is contested, the configuration will be contested indefinitely — and the system becomes the venue for an argument it cannot settle.
- Define the stages and their exit criteria before configuring anything.
- Agree what data is mandatory and why each field earns its place.
- Resolve territory and ownership rules explicitly.
- Write it down and get sign-off from the people who will live with it.
- Then configure, and refuse changes that reopen settled decisions without a real reason.
Adoption is a project, not an announcement
| What fails | What works |
|---|---|
| One training session at launch | Support through the first weeks |
| Generic platform training | Training on their actual workflow |
| Mandating data entry | Making it faster than the current way |
| Asking for fields nobody uses | Only collecting what someone acts on |
| Assuming usage | Measuring weekly active usage |
Audit your mandatory fields against actual use. For each one, name the person who acts on it. Fields nobody acts on are pure friction — they slow every record entry and train users to enter whatever passes validation, which then corrupts the fields that do matter.
Recovering an implementation that is not working
- Establish whether it is used — weekly active usage by team, honestly measured.
- Ask users what they work around and why. They will tell you.
- Assess data quality against what reports claim.
- Name an owner if there is not one. Nothing else works without this.
- Simplify — remove fields, automation and process steps that serve nobody.
- Fix the data that undermines trust in reports.
- Re-train on the simplified system, with support.
- Measure again at three months.
Notice that none of those steps is "change platform". Migration resets the sunk cost and reproduces the same failure, six months later and more expensively.
Predictors of success, before you start
- A named owner with allocated time.
- Documented, agreed process.
- A data cleaning plan with effort attached.
- A deliberately limited customisation scope for year one.
- A baseline captured for whatever you intend to improve.
- Budget for support after go-live, not just up to it.
Implementation not delivering? Tell us what users say about it — that usually identifies the cause. See over-customisation warning signs, data migration, and Zoho vs Salesforce.