CRM Implementation: How Not to Waste Six Months
- No invented stats
- Written for UK readers
- 6 min read
- Published 13 November 2026
A CRM implementation fails slowly. Nobody announces it. The system goes live, three people use it properly, everyone else keeps their deals in a spreadsheet or their head, and six months later someone asks why the pipeline report doesn't match reality. The software is rarely the problem. The problem is that the project was run as an IT installation rather than a change to how people work.
This is a sequence that works for teams of roughly three to thirty people. Larger organisations need more governance; a two-person business can compress most of it into a fortnight.
Before you touch the software
Write down what the CRM is for
Not "manage customers" — that's meaningless. Pick two or three outcomes you will be able to check in six months:
- Any manager can see the current state of every open deal without asking a rep.
- No inbound enquiry goes more than one working day without a logged response.
- We can tell which lead sources produce closed business, not just enquiries.
Every configuration decision later gets tested against this list. If a field or workflow doesn't serve one of these outcomes, it's optional, and optional things are what kill adoption.
Agree the pipeline before you build it
The single biggest cause of rework is building stages in the software before the team agrees what the stages mean. Define each stage by an observable buyer action, not by how the rep feels. Our guide to sales pipeline stages covers how to do this properly. Do it on a whiteboard first. Changing a stage definition in a workshop takes five minutes; changing it after 400 deals are in the system takes an afternoon of data cleanup.
Pick a single owner
One named person owns the project, with enough authority to say no. A committee will approve every field request anyone makes, and you will end up with a 60-field contact record nobody completes. If you haven't already chosen a product, our CRM buying guide for small UK businesses covers what to evaluate.
Data migration: the part everyone underestimates
Assume migration takes three times longer than the vendor's estimate, because their estimate assumes clean source data and you do not have clean source data.
The migration checklist
- Inventory every source. The old CRM, the shared spreadsheet, the sales director's personal spreadsheet, Outlook contacts, the accounting system's customer list. Write them all down. There is always one nobody mentions until week three.
- Decide what not to bring. Dead leads older than two or three years, contacts with no email and no phone, duplicate companies from a trade show list in 2019. Archive them to a CSV somewhere safe and leave them out. A smaller clean database beats a large dirty one every time.
- Standardise before import, not after. Fix country and county formats, strip trailing whitespace, normalise company names (decide once whether it's "Ltd", "Limited" or "Ltd."), and make sure phone numbers are in a consistent format. Do this in the spreadsheet with find-and-replace, where it's fast.
- De-duplicate on a stable key. Email domain works well for companies; email address for people. Company name matching alone will miss "Acme Ltd" versus "ACME Limited".
- Run a test import of 50 records first. Check them field by field against the source. You will find at least one mapping error — usually a date format or a picklist value that silently became blank.
- Import in a fixed order. Companies, then contacts, then open deals, then historic activity if you're bringing it. Open deals only — importing five years of closed opportunities adds noise and slows reporting for no real benefit.
- Freeze the old system. Pick a cutover date and make the old system read-only from that morning. Running both in parallel "just for a bit" guarantees six months of split data.
If your existing data is genuinely chaotic, tackle it as its own project before migration rather than during it — see how to clean up a messy CRM.
Configure less than you think you need
The instinct is to replicate every field from the old system plus everything anyone asks for. Resist it. Start with the minimum that supports your two or three stated outcomes, then add fields when someone can explain what decision the field will change.
A reasonable starting set for a B2B team: company, contact, deal value, expected close date, stage, source, and owner. Everything else is a candidate for later. Mandatory fields should be genuinely mandatory — if you make six fields required at deal creation, reps will create deals with junk in them or avoid creating them at all.
One rule worth adopting from day one: every field must have an agreed definition written down somewhere. "Source" means nothing until you've decided whether a referral from an existing customer who first found you via LinkedIn counts as "Referral" or "LinkedIn".
Pilot with real deals, not test data
Give two or three reps two weeks with live deals before rolling out to everyone. Demo datasets hide the awkward cases: the deal with three decision makers at two legal entities, the renewal that isn't really a new opportunity, the prospect who only ever replies on WhatsApp. Your pilot users will surface these, and fixing them for five people is much cheaper than for fifty.
Ask pilot users one question at the end of each week: "What did you have to do outside the CRM this week, and why?" The answers tell you exactly where the configuration doesn't fit the work.
Training and the first ninety days
Two-hour training sessions do not work. People retain the parts they use the next morning and forget the rest.
- Train by task, not by feature. "How to log a call and set the next step" beats "a tour of the activity module".
- Run short sessions, repeated. Three 30-minute sessions across two weeks beats one long one.
- Record the five most common tasks as two-minute screen captures. New starters and the people who were on holiday will use them.
- Make the manager use it in meetings. This is the single strongest adoption lever. If the weekly pipeline review runs off the CRM screen and nowhere else, the CRM gets updated. If the manager accepts a verbal update, it doesn't.
What to measure in the first ninety days
| Check | What it tells you |
|---|---|
| Percentage of open deals with a scheduled next action | Whether the CRM is being used to run work or just to record it after the fact |
| Deals with a close date in the past | Hygiene. This number should stay near zero. |
| Logins per user per week | A blunt measure, but a rep logging in once a week is not using it. |
| Deals created outside the CRM | Ask in the pipeline review. Anything above zero means a process gap. |
Where this advice doesn't apply
If you are a one- or two-person business with a short sales cycle and fewer than 100 active prospects, most of the above is overhead. Import a clean list, set up four pipeline stages, and get on with it. The structure here earns its keep when several people need a shared view of the same deals.
Equally, if you're implementing a CRM as part of a broader systems change — new accounting package, new support desk, a migration off a legacy platform — treat it as a programme with proper sequencing, not a two-week job. The failure mode there is trying to integrate systems that are all moving at once.
The short version
Decide what the CRM must let you do, agree the pipeline on paper, migrate less data than you think you should, configure fewer fields than anyone asks for, pilot with real deals, and make the weekly meeting run off the system. Projects that wander for six months almost always skipped one of the first two steps.
Spotted a mistake or a number we can't back up? Tell us and we'll fix it.