CRM Implementation: What Actually Happens, Stage by Stage

A CRM implementation is the work between signing a licence and having a system people actually use. The licence takes an afternoon. The rest of it is six stages, and only one of them is about the software. For what the system itself is and what it holds, see what a CRM is.

The order matters more than the duration. Each stage depends on the one before it being settled, and the common failure is starting at stage three because that is the one that feels like progress.

Stage one: process definition

Before anything is configured, the process has to exist in writing. Stages, who owns each one, what has to be true before something moves forward, what happens at the exceptions, and what the rule is when two people would answer differently.

Most organizations have never written this down. That is not a criticism. Processes accrete through people making sensible decisions over years, and nobody sits down to reconcile them until something forces it. An implementation forces it.

What this stage produces is a written process map, agreed by the people who run it. No software is involved. This is also the stage most likely to be skipped, because it produces a document rather than a screen, and a document does not feel like progress on a software project.

Stage two: data preparation

Everything the new system will hold, inventoried and decided. Where records currently live, which are duplicates, which are dead, which fields matter, and what the rule is when two versions of the same record disagree.

This is usually the largest single piece of work in the project and the most commonly left out of a fixed scope, because its size is not knowable until someone looks. A contact list that appears to hold 4,000 records routinely resolves to 2,600 real ones after deduplication, and the difference is discovered halfway through.

The decisions here are not technical. Which of three versions of a customer’s address is right is a business question. Whoever answers it needs the authority to make the answer stick.

Stage three: configuration

The part everyone pictures. Fields, layouts, pipeline stages, permissions, automation rules and reports, built against the process from stage one rather than against the vendor’s defaults.

Default configurations describe a generic company. They are a reasonable starting point and a poor finishing point. When stages do not match how deals actually move, updating a record becomes an administrative chore disconnected from the work, and people stop doing it as soon as nobody is watching.

Done properly against a defined process, this stage is usually shorter than the two before it. Done without a defined process, it expands without limit, because every decision gets re-litigated as it is discovered.

Stage four: integration

Connecting the CRM to everything else that holds customer data: accounting, email, calendar, website forms, and whatever operational system runs the delivery side.

Every connection not built is a person exporting a file on a schedule that depends on them remembering. That is a permanent staffing cost and a permanent source of error, and it is invisible in the project budget because it lands on someone’s existing job.

Scope this by asking where the same piece of information is entered twice. Those are the connections worth building. Connections built because they are possible rather than because a duplicate entry exists are maintenance you have volunteered for.

Stage five: migration and go-live

Records moved, verified against a count, and the switch thrown. The verification matters more than the move. A migration that completes without an agreed reconciliation is a migration whose errors surface in week three, at which point trust is already gone.

1. 1
   Agree the reconciliation before you migrate

   Record counts by type, a sample check on field accuracy, and a named person who signs off. Doing this after the migration means arguing about whether something was ever there.

2. 2
   Train by role, not by feature

   A salesperson needs their five screens, not a tour of the platform. Feature-led training produces people who have seen everything and can do nothing.

3. 3
   Write the procedure down

   One page per process, describing what a person does rather than what the system does. This is what a new hire reads in month seven, long after the training session is forgotten.

4. 4
   Retire the old thing on a date

   If the previous spreadsheet stays editable, it stays in use, and you now maintain two systems. Set the date before go-live and make somebody accountable for it.

Stage six: the correction period

The stretch after go-live where usage is checked, the design is corrected against what people actually do, and the things that turned out wrong get fixed while somebody still has the context to fix them.

This is the stage that decides whether the previous five were worth doing, and it is the first thing cut when a budget tightens, because by then the system exists and the project feels finished.

The other thing this stage produces is a named owner. One person inside the organization who knows the configuration, can make a change, and is expected to. Without that, the first field that turns out wrong in month three stays wrong, people work around it, and the workaround becomes the process.

Where implementations actually go wrong

• Starting at configuration because it is the stage that feels like progress
• Treating data migration as an IT task rather than a series of business decisions about which record is true
• Scoping the project to end at go-live, so the correction period has no budget and no owner
• Training on features instead of on the specific screens each role touches
• Leaving the old spreadsheet editable, so the organization quietly runs two systems
• Configuring around one strong opinion in the room rather than an agreed process
• Buying a tier above what the process needs, then discovering the extra capability requires the process you have not defined

How long it takes

For a small team on a defined process with reasonably clean data, weeks. Our own fixed-scope Zoho CRM package runs five weeks, including migration and training, and it is fixed precisely because the scope boundaries are drawn where the unknowns are not.

What extends a timeline is almost never the software. It is the two things discovered rather than planned: the process was not agreed, and the data was worse than anyone thought. Both are found in stages one and two, which is the argument for doing them first rather than discovering them during configuration.

Where the process itself is genuinely complex or spans several functions, the honest answer is that the implementation cannot be estimated until it has been mapped. That is what process mapping is for, and it is a smaller and cheaper piece of work than the implementation it scopes.

Frequently asked questions

Takeaways

• Six stages, and only one of them is about software. Starting at configuration is the most common and most expensive sequencing error.
• Data preparation is the largest piece of work and the most commonly excluded from scope. Its size is not knowable until somebody looks, which is an argument for looking early.
• Scope the project to end after the correction period, not at go-live. A system nobody corrected in month three is a system people worked around in month four.
• Leave one named owner behind. It is the cheapest item in the plan and the one that decides whether the rest holds.