The Honest Calendar of a CRM Implementation: Five Phases and Where the Weeks Go

Most CRM timelines are quoted against the wrong finish line. The software is ready in days, but an implementation is finished when your team has run a complete sales cycle inside it and the forecast it produces is the one leadership uses. For a mid-sized company, that is a matter of months, and the months are predictable if you know which phases consume them.

Start by defining "done"

Ask three people when a CRM project ends and you get three answers. The vendor says it ends when the instance is configured. The project manager says it ends at go-live. The head of sales says it ends when she can stop keeping her own spreadsheet.

Only the third definition is worth planning around. Use something concrete:

• Every active deal lives in the CRM and nowhere else.
• The weekly pipeline review runs from the live system.
• At least one deal has gone from first contact to closed inside the new setup, so every stage has been exercised by a real case.
• The forecast pulled from the system is within arguing distance of the number leadership commits to.

Once you plan against that definition, a quote of "two weeks" stops being wrong and starts being incomplete. Two weeks may well cover the configuration work. It does not cover the decisions that come before it or the cycle that has to happen after it.

The five phases

The ranges below are reasonable planning figures for a company with one or two sales teams, a handful of connected systems and an existing book of business to move. They are not benchmarks. Use them to check whether a proposal has accounted for each phase at all.

Some of these overlap. Integration can start while configuration is being finished, and data cleanup can start on day one. Even with sensible overlap, an end-to-end figure of three to five months is normal for this size of company. If your sales cycle is nine months, the last phase stretches accordingly, because you cannot validate a late-stage process with deals that have not reached it.

Phase 1: process discovery

This phase produces a document, not a system, which is why it is the first thing cut from a tight proposal. It should answer questions the software cannot answer for you:

• What are the stages a deal actually passes through, as opposed to the ones on the old slide?
• What observable fact moves a deal from one stage to the next? "Customer confirmed budget in writing" is an exit criterion. "Feels warm" is not.
• Who owns an account when two reps have a claim on it? What happens to ownership when a rep leaves?
• Which approvals exist, at what thresholds, and who can grant them?
• What does finance need from a closed deal in order to invoice it?

The time here goes into disagreement, not documentation. Two regional managers will describe "qualified" differently. Resolving that on a whiteboard takes an afternoon. Discovering it after go-live, with both definitions already baked into six months of data, takes much longer.

Phase 2: design and configuration

This is where the CRM becomes yours or stays generic. The actual clicking is fast. What takes time is deciding what the fields, stages and permissions should be, and resisting the temptation to add one of everything.

Three things deserve more attention than they usually get.

Required fields. Each one is a cost charged on every record forever. Require what a stage transition truly depends on and leave the rest optional.

Permissions. Who can see which accounts, who can edit a closed deal, who can export. This looks like administration and is really policy. A permissions model that is too open causes trouble with large accounts. One that is too closed breaks handoffs between sales and service.

Automation. Assignment rules, reminders, stage-triggered tasks. Each rule is small. Thirty of them interact, and nobody can predict the result without testing. Budget time to test with realistic records.

A large share of the CRMs later described as "it never really worked for us" failed here: fields nobody fills in, stages that describe how someone wished the team sold, and automation that fires at the wrong moment.

Phase 3: integration, where the calendar usually slips

A CRM that exchanges data with nothing is an expensive contact list. The value arrives when a web form creates a lead, an email thread attaches itself to the right deal, a closed deal becomes an invoice, and a support ticket is visible to the account owner.

Integration is the phase with the widest range because it depends on systems you do not control. The questions that decide its length:

• Does the other system have a usable API? Modern SaaS products generally do. An older on-premise billing or ERP system may offer only file exports or direct database access.
• Which direction does data flow, and which system wins a conflict? If a customer's address differs in billing and in the CRM, which one is correct? Decide per field, in writing.
• How are records matched? Two systems almost never share an identifier. Matching by company name will fail on the first "Inc." versus "Incorporated".
• What happens when a call fails? Retries, queues and alerts are the difference between an integration and a demo.

There are three ways to connect two systems, and they are not equivalent. A native connector provided by the vendor is the cheapest to start and the least flexible. An integration built against documented APIs costs more upfront and survives interface redesigns. Screen automation, where a script operates the user interface the way a person would, can be the only option for a system with no API, but it breaks whenever the screen changes and should be treated as a temporary bridge with a planned replacement.

One piece of advice shortens this phase more than any tool: do not integrate everything for launch. Pick the two connections that eliminate the most retyping, usually email and calendar plus whichever system creates leads. Ship those. Add billing, support and the rest in a second wave, when you know which ones the team actually misses.

Phase 4: data migration and pilot

Loading data is mechanical once the mapping is agreed. The time goes into cleanup: duplicate accounts, contacts with no company, deals stuck in a stage for two years, and the question of how much history to bring across.

Run the pilot in parallel with the tail end of migration. One team, one manager, real deals, real integrations, for two to four weeks. The pilot team should be representative, not handpicked for enthusiasm. Its job is to find the cases the design missed while the cost of changing course is still low.

Expect the pilot to produce a list of changes. That is the point of it. A pilot with no findings usually means the team was not really working in the system.

Phase 5: rollout and stabilization

Overruns happen here more often than anywhere else in the project, and technology is seldom to blame. Go-live is a date. Stabilization is a behavior change across every rep and manager, and it only completes when the old habits have nowhere left to live.

Plan for:

• Short, role-specific training on real records, repeated after two or three weeks when real questions exist.
• A weekly change window, so fixes requested by the field arrive quickly and predictably.
• A firm date on which the old system or spreadsheet becomes read-only.
• Managers running reviews from the CRM from the first week.

The last item decides more than the other three combined. A team whose manager still asks for a spreadsheet will maintain the spreadsheet.

What stretches a timeline, and what safely shortens it

Notice what is absent from the right-hand column: working faster. Rushing configuration to hit a date gives you a system that looks complete, because the fields and stages are all there, and that nobody trusts, because the decisions behind them were never made. You then pay for the skipped work during rollout, at a much worse exchange rate.

Order matters more than velocity

The order that survives contact with a real sales team is plain. Understand the process first, configure only what you have understood, connect other systems to a settled configuration, and put a single pilot team on the connected result before anyone else touches it. Each step produces the inputs the next one needs. Reversing any two means doing one of them twice.

When you read a proposal, check it against that sequence. Ask where process discovery is. Ask which integrations are in the first wave and how each is built. Ask what the pilot is and who is in it. Ask what "done" means and whether the price covers the stabilization period or stops at go-live. When a proposal answers all four in writing, the go-live it promises becomes a commitment you are entitled to enforce.

Are you about to commit to a launch date?

Before you do, it is worth having the five phases mapped against your own pipeline, systems and data. That mapping is the kind of written plan Trivo produces in a Two-Week Discovery, and it belongs to you whether or not we build what follows.