August 2026 · Sales operations · 9 min read

The CRM Implementation Checklist I Wish I Had Started With

Most CRM projects do not fail at go-live. They fail eight weeks later, when people quietly go back to what they were using before.

The rollout is a training problem more than a software problem

I have set up and administered a CRM used across offices in ten countries. I have also watched teams buy expensive software and end up right back in spreadsheets. The difference was almost never the product.

Here is the checklist I use now, in the order the decisions actually have to be made.

Before you choose a tool

1. Write the five questions the system has to answer

In leadership's own words, not in CRM vocabulary. "How many partners went quiet this quarter" rather than "engagement metrics." Everything you build later gets checked against this list. If a field does not serve one of the five, it does not get built.

2. Name the single owner

Not a committee. One person who can say no to feature requests and yes to a rollout date. CRM projects with shared ownership become CRM projects with no ownership, and the symptom is a build that never quite finishes.

3. Decide what you are not doing in version one

Write it down and share it. Forecasting, marketing automation, custom quoting, whatever. Half of implementation politics is people assuming their thing is in scope. Naming what is out costs one paragraph and saves two months.

4. Agree the definitions, on paper, before the build

What counts as a lead. What counts as qualified. When a deal is won. What an "active" partner means. If two offices would answer differently, the definition is not finished.

Every hour spent on definitions before the build saves a day of cleanup after it.

Data migration: bring less than you want to

5. Decide the cutoff

You do not need eleven years of history. Pick a date, migrate what is after it, archive the rest somewhere readable. Nobody has ever thanked a migration for bringing across a 2016 lead.

6. Clean before you import, not after

Duplicates, dead email addresses, inconsistent country spellings, contacts with no company. Fixing these in a spreadsheet is tedious. Fixing them inside a live CRM, after people have started adding records on top, is far worse.

7. Map the fields on paper first

Old field to new field, with a decision for anything that does not map. The unmapped columns are where the interesting information usually hides, and where the arguments happen if you leave the decision to import day.

8. Do a test import with a hundred records

Then have an actual user, not the admin, look at ten of them and say whether they look right. This step gets skipped constantly and catches almost every serious mistake.

Built once, used by everyone, or not built at all

The build

9. One pipeline, unless a second genuinely earns it

Each extra pipeline is a permanent tax on reporting. A different market is not automatically a different pipeline. A genuinely different sales motion is.

10. Stage definitions with entry conditions

Not adjectives. Conditions. "Decision maker identified and a next step scheduled" beats "Qualified", because two people can check the first and only argue about the second.

11. Keep required fields to what is knowable at that moment

If a rep cannot possibly know the answer at that stage, they will type something to move on, and your reports are now built on invented data.

12. Dropdowns over free text, everywhere it is possible

Especially country, source, and disqualification reason. These three are the ones you will want to report on, and free text makes that impossible from day one.

13. Automate reminders, never judgement

Stale deal nudges, onboarding tasks, missing field flags: good. Auto-advancing stages or auto-scoring on thin data: it looks impressive in the demo and produces numbers nobody trusts by month three.

The rollout

14. Train on their work, not on the software

Do not demo the CRM. Take three real deals they are working on right now and put them in together. Twenty minutes of that beats an hour of feature tour.

15. Give them something back in week one

A view that saves them time before you ask them to enter anything. A CRM that only feeds head office is a tax, and people route around taxes.

16. Appoint a local point person per office

Not an expert. Just the person who answers the first small question so it does not have to travel to the admin and wait a day. Where this existed, adoption was quick. Where it did not, the office stayed slow.

17. Set the date the old system dies

And keep it. Parallel running is comfortable and it is why implementations fail. Two systems means one real system and one that is out of date, and it is never obvious which is which.

After go-live

18. Watch adoption weekly for six weeks

Not seat count. Whether records are being updated by the people who own them, or by one heroic administrator keeping the illusion alive.

19. Hold a change queue, not a change stream

Collect requests, batch them, ship every two weeks. Continuous small changes to a live system confuse the people who just learned it.

20. Test it with a question nobody planned for

Around week eight, ask something new: which sources produced our best deals last quarter. If you can answer it from the system, the implementation worked. If you have to email four people, you have a very expensive filing cabinet.

Updated: August 2026