Why Your CRM Rollout Failed, and What to Do Instead

Most organisations are on at least their second customer relationship management system. The first one is usually described as having failed, though rarely for the reason given.

The software almost always worked. What failed was adoption, and adoption failed for reasons that were predictable before the contract was signed.

The system serves management, not the user

A typical CRM implementation asks a salesperson to record activity, update stages, log calls and forecast accurately. The beneficiaries of that data are the sales director and the finance team.

The salesperson receives, in exchange, a longer administrative day. Where a system takes more from a user than it returns, adoption decays regardless of mandate, and the data degrades until the reports become unusable.

Forecast accuracy is a trust problem

When commission, headcount or credibility depend on the number in the system, people manage the number. Deals get held back, stages get advanced optimistically, and the pipeline reflects incentives rather than reality.

No amount of process discipline corrects this. What helps is separating the forecast used for operational planning from the one used to evaluate individuals, and being explicit that you have done so.

Give the user something back

The implementations that stick tend to deliver something the salesperson actually wants: fewer forms elsewhere, faster quote generation, automatic capture of email and calendar activity, or visibility of what marketing already knows about an account.

If you cannot articulate what the user gains, you are relying on compliance, and compliance produces the minimum viable data entry.

Configure for how the business actually sells

Out-of-the-box pipeline stages describe a generic sales process. Most businesses do not have one. Long procurement cycles, multiple decision makers, channel partners and repeat business all break the standard model.

Where the system does not match reality, users invent workarounds, and the workarounds live in spreadsheets that nobody can report on.

Fixing an implementation you already have

Replacing the system is usually the most expensive available option and frequently repeats the failure with a different vendor.

Start instead by asking three questions. What does this system ask users to do that returns nothing to them? Which required fields exist to satisfy a report nobody reads? Where has the process diverged from what the tool assumes?

Removing obligations is generally more effective than adding training. Most struggling implementations are carrying requirements that were reasonable during the original configuration and have never been revisited since.