Why do CRM and ERP rollouts fail?

Almost always at adoption rather than installation. The most common cause is that the new system is slower for the person using it than whatever they did before, so the behaviour reverts. Close behind are configuration that does not match how work actually flows, no visible benefit to the person entering data, poor data quality on day one destroying trust, and nobody enforcing the change so the old spreadsheet remains the real system.

How much training does a team actually need?

Far less than most rollouts deliver, but structured very differently. A four-hour walkthrough of the full feature set teaches almost nothing durable. What works is role-specific sessions covering only the five tasks that person performs daily, hands-on in their own real data, delivered as two one-hour sessions a week apart. The second session is where the useful questions surface, because by then people have hit real friction.

Should we run the old process alongside the new system for a while?

It feels prudent and it is the most reliable way to guarantee the rollout fails. As long as the old spreadsheet can produce the numbers, it remains the real system and the new one becomes a place data is copied to afterwards. Set an explicit cutover date, communicate it clearly, and make the old artefact read-only after it. Do the risk reduction through a pilot with one team beforehand, not through indefinite parallel running.

Who should own the system internally?

Someone with genuine authority over how the company works, not just someone assigned the task. The owner decides what a pipeline stage means, resolves whether something is tracked here or there, and onboards new hires. External consultants leave, and if nobody internal holds those decisions the configuration drifts and the documentation goes stale within months. An owner who cannot say "this is how we do it" and have it stick is a mailing address rather than an owner.

How do we know whether the rollout succeeded?

Do not measure logins - they tell you nothing about whether work moved. Ask instead whether records are updated within a day of something happening rather than batched before the weekly meeting, whether the weekly numbers can be produced from the system without anyone assembling a spreadsheet, and whether a colleague could pick up someone's customer from the record alone. The honest test is the last one: has the old spreadsheet stopped being updated? If the shadow system is still alive, the rollout is not finished.

CRM and ERP Rollout: Why Systems Fail at Adoption, Not at Installation

The system works, the data migrated, and three months later half the team is back in Excel. Rollout failure is almost never technical. Here is what actually determines adoption, and how to structure training so it sticks.

The pattern repeats across companies of every size. A CRM or ERP is selected after a long evaluation, configured, populated with migrated data, and launched with a training session. For a few weeks usage looks reasonable. Then the sales team starts keeping their real pipeline in a spreadsheet again, operations quietly keeps the old process running alongside, and within a quarter the expensive system is a place where data is entered afterwards rather than a place where work happens.

The system was not the problem. Almost every failed rollout I have seen failed at adoption, and adoption failures have consistent, addressable causes.

Why People Go Back to Excel

It is slower. This is the biggest single factor and it is rarely acknowledged. If logging a call took twenty seconds in a notebook and takes ninety in the CRM, people will stop logging calls. Every mandatory field, every extra click, every slow page is a tax on the behaviour you are trying to create.

It does not fit how they work. A pipeline stage list designed by management that does not match how deals actually progress produces records that are technically complete and practically meaningless.

There is no visible payoff. If entering data only produces reports for management, the person entering it is doing unpaid work for someone else. Adoption improves sharply when the system gives the user something back - their own follow-up list, their own numbers, one less thing to remember.

The data was wrong on day one. If the first customer someone opens has a stale phone number and a duplicate record, they conclude the system is untrustworthy, and that conclusion is very hard to reverse.

Nobody enforces it. If the quarterly review can be prepared from a spreadsheet, the spreadsheet is the real system regardless of what anyone was told.

What Good Rollout Looks Like

Configure for the process you actually have

Before any training, map how work moves through your business today - not how it should, how it does. Configure the system to match that, then improve it deliberately once people are using it. A system that forces a new process and a new tool simultaneously is fighting two battles at once and usually loses both.

Fix the data before go-live

Deduplicate, standardise formats, fill the fields that matter, and delete what is genuinely dead. This is boring, it takes longer than expected, and it is the highest-leverage work in the entire project. First impressions of data quality determine whether people trust the system.

Train by role, on the daily five

A general four-hour walkthrough of every feature teaches nothing durable. Instead, for each role, identify the five things that person does every day and train only those, hands-on, in their own real data. Everything else can be learned later or never.

Sessions should be short, role-specific, and repeated - one hour, twice, a week apart, beats four hours once. The second session is where the real questions come out, because by then people have hit actual friction.

Write the two-page guide, not the manual

Nobody reads a hundred-page manual. A two-page role-specific guide covering the daily five, kept somewhere people can find it in ten seconds, gets used. Short screen recordings of the common tasks work even better than text.

Name an internal owner

Someone inside the company has to own how the system is used - who decides what a pipeline stage means, who resolves "should we track this here or there", who onboards the next new hire. External consultants leave. If nobody internal owns it, configuration drifts and the guide goes stale within months.

This person needs authority, not just responsibility. An owner who cannot say "we do it this way" and have it stick is a mailing address, not an owner.

Turn off the old way

Running the new system in parallel with the old process feels safe and it is the most reliable way to guarantee failure. Set a date, communicate it clearly, and after it the old spreadsheet is read-only. Not doing this is how organisations end up maintaining two systems forever.

A Realistic Schedule

Phase	Typical duration
Process mapping and configuration	2-4 weeks
Data cleanup and migration	2-6 weeks, overlapping
Pilot with one team	2 weeks
Role-based training and go-live	1-2 weeks
Support-heavy stabilisation	4-6 weeks

The pilot is the step people skip to save two weeks, and it is the one that surfaces the mismatches between the configuration and reality while they are still cheap to fix.

How to Tell If It Worked

Do not measure logins. Measure whether the work actually moved:

Are deals updated within a day of something happening, or in a batch before the weekly meeting?
Can you produce the weekly numbers from the system without anyone assembling a spreadsheet?
When someone is out, can a colleague pick up their customer from the record alone?
Has the old spreadsheet stopped being updated?

That last one is the honest test. If the shadow system is still alive, the rollout is not finished.

For help with a rollout or a system that never got adopted, book a free call. Related: building a custom CRM, custom CRM versus off-the-shelf, and integrating the systems you already run.