# CRM Implementation Checklist

**SoftwareGlimpse** · Updated 15 Aug 2026  
**Type:** IMPLEMENTATION_TEMPLATE · **Stage:** IMPLEMENT  
**JTBD:** Deliver CRM rollout with object/stage/sync gates and pilot exit criteria.

> Pass each rollout gate before you start the next one. Use this between contract signature and launch to gate scope, configuration, integrations, access, and pilot exit — so “almost live” means evidence, not optimism.

## How to use

1. **Freeze the MVP** — Write and date what is in scope for launch; route everything else to a parked backlog.
2. **Assign gate owners** — One person per workstream, plus the dates each gate is expected to clear.
3. **Configure and review** — Build objects, stages, ownership rules, roles, and the boards managers will use.
4. **Connect sync, dedupe, and seats** — Prove email sync and duplicate rules in staging; reconcile the seat roster.
5. **Pilot on real deals** — A small cohort works live opportunities and a manager runs one review from the CRM.
6. **Clear the pilot exit gate** — Close or risk-accept every defect in writing, then hand off to migration and go-live.

## Result key

| Result | Meaning |
| --- | --- |
| Pass | Verified with evidence |
| Partial | Met with limits or a workaround |
| Fail | Does not meet a required check |
| Not tested | No evidence yet — do not invent a Pass |

## Evidence that counts

- Demonstrated in the CRM by the named owner
- Pilot records created during real selling work
- A dated configuration note or admin runbook entry
- Written risk acceptance from the sponsor

## Evidence that does not count

- A task ticked in the project plan alone
- Configuration shown only on sample data in a sandbox
- Verbal assurance that a workstream is nearly there
- A gate passed because the launch date is close

## Checklist

### 1. Scope & ownership gate

Clear this before anyone starts building, or configuration will never stabilise.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1.1 | MVP objects, stages, and fields frozen | Open scope means the build keeps moving and no gate can ever close. | Must-have | Write a dated list of the objects, stages, fields, reports, and automations in scope for launch, and route later requests to a parked backlog. | | | |
| 1.2 | One named owner per workstream | Items owned by “the team” stay amber until someone escalates. | Must-have | Name a person for configuration, data, integrations, seats, training, and support — not a department. | | | |
| 1.3 | Change control agreed | Untracked changes during the build cause regressions nobody can trace. | Must-have | Agree who approves a scope change during build, and where approved changes are recorded. | | | |
| 1.4 | Gate dates on the calendar | A gate without a date quietly becomes optional. | Must-have | Put the configuration review, integration check, pilot start, and pilot exit on the calendar with the gate owner invited. | | | |
| 1.5 | Week-one and week-four measures written | Without a measure, “it went fine” is the only verdict available after launch. | Nice-to-have | Decide what you will look at after launch: deals carrying next steps, sync health, board usage, duplicate volume. | | | |

### 2. Configuration gate

Build the process managers will coach from — and test it before anyone depends on it.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 2.1 | Objects and required fields match the agreed model | Layouts that drift from the data model break reporting long after anyone remembers why. | Must-have | Review account, contact, and deal layouts against the signed model with a second admin, and note every deviation. | | | |
| 2.2 | Stages and exit checkpoints configured | Stages without checkpoints turn pipeline reviews back into opinion. | Must-have | Create a test deal and move it through every stage; confirm each checkpoint behaves the way the process document describes. | | | |
| 2.3 | Owner and next-step convention enforced | Ownership and next action drive every hygiene report you will run afterwards. | Must-have | Confirm an open deal cannot sit without an owner, and that a next-step date is visible on the record and in list views. | | | |
| 2.4 | Roles and sharing tested with sample users | Making everyone an admin is the most common rollout shortcut and the hardest to reverse. | Must-have | Log in as a seller and a manager test user and confirm each sees and edits only what the role matrix allows. | | | |
| 2.5 | Manager pipeline and stuck-deal views built | If managers cannot run the week from the CRM, the team goes back to spreadsheets. | Must-have | Build the board a manager will open on Monday — open deals by owner, stage, and missing next step — and have a manager confirm it works. | | | |
| 2.6 | MVP automations inventoried | Automations built before launch are usually the first thing to break under real data. | Nice-to-have | List each automation in MVP with its trigger and owner, and park the rest in the post-launch backlog. | | | |

### 3. Integration & access gate

Sync, duplicate rules, and seats are part of the build — not paperwork for launch week.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 3.1 | Email and calendar sync working for test users | Sync failures show up as adoption failures, because sellers stop trusting the timeline. | Must-have | Connect at least two mailboxes in staging and confirm a sent message lands on the intended contact and deal. | | | |
| 3.2 | Duplicate rules configured and tested | Duplicates created in the first weeks outlive the project. | Must-have | Run known duplicate pairs through your match rules and confirm the survivor keeps related deals and activities. | | | |
| 3.3 | Day-one integrations connected | An integration deferred to “later” becomes manual work for sellers on day one. | Nice-to-have | Connect each must-have integration in staging and record the direction, the failure mode, and who fixes it. | | | |
| 3.4 | Seat roster matches the launch cohort | Missing seats block work on day one, and spare seats cost money quietly. | Must-have | Compare the licence list against the intended launch cohort and resolve every difference before pilot starts. | | | |
| 3.5 | Admin runbook drafted | Support cannot depend on one person remembering how the build works. | Must-have | Write the steps for adding a user, merging duplicates, fixing a failed sync, and correcting a stage or field error. | | | |

### 4. Pilot exit gate

The pilot is the only gate that tests the build against real behaviour.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 4.1 | Pilot cohort works real deals | Sandbox pilots pass gates that production will fail. | Must-have | Have pilot sellers run live opportunities for an agreed period as part of normal work, not as a scheduled exercise. | | | |
| 4.2 | Stages and next steps hold up in real use | Checkpoints that irritate sellers get bypassed, and the data quietly degrades. | Must-have | Review a sample of pilot deals: are stages accurate, owners set, and next steps current without admin cleanup? | | | |
| 4.3 | Email sync verified on pilot mailboxes | Real mailboxes behave differently from test accounts, especially at volume. | Must-have | Check across the pilot period that sent and received messages land on the correct records for every pilot user. | | | |
| 4.4 | A manager runs one pipeline review from the CRM | The first real test of the build is a manager using it under time pressure. | Must-have | Hold at least one pipeline or forecast review with the CRM board as the only source, and capture what was missing. | | | |
| 4.5 | Defects closed or risk-accepted in writing | Undocumented defects come back as day-one incidents with no owner. | Must-have | List every pilot defect with severity and owner; each must be closed or explicitly accepted by the sponsor. | | | |
| 4.6 | Pilot exit signed before wider rollout | Calendar pressure passes gates that evidence would not. | Must-have | Record a dated sponsor decision to exit pilot that cites the defect list and the gate items above. | | | |

### 5. Enablement & handoff gate

People readiness and ongoing ownership close the implementation, not the configuration.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 5.1 | Role-based training delivered before launch | Training after launch competes with firefighting and usually loses. | Must-have | Run sessions per role: sellers on deals and next steps, managers on boards, admins on seats, merges, and sync. | | | |
| 5.2 | Support intake and coverage named | Issues with no route home become reasons to stop using the CRM. | Must-have | Publish one intake channel with named coverage and hours before the launch date is announced. | | | |
| 5.3 | Ongoing admin ownership assigned | The implementation ends; the CRM does not. | Must-have | Name who owns users and seats, stage changes, duplicate cleanup, and the reporting backlog after launch. | | | |
| 5.4 | Handoff to migration and go-live confirmed | Rollout gates, the data move, and launch day are three different jobs with different failure modes. | Nice-to-have | Confirm data cutover is tracked on the Migration Checklist and launch day on the Go-Live Checklist, each with an owner. | | | |

## Worked example

_Hypothetical Rollout A / Rollout B scenario for teaching the artifact — not a SoftwareGlimpse case study._

**Requirement:** Before pilot exit, every open deal in the pilot pipeline has an owner and a dated next step without admin cleanup.

| Scenario | Result | Note |
| --- | --- | --- |
| Rollout A | PASS | Pilot sellers ran live opportunities for two weeks; at exit, the stuck-deal board showed no unowned deals. |
| Rollout B | FAIL | Pilot ran in a sandbox on sample data, so the gate passed on records nobody had to maintain. |

**Evidence:** Pilot exit review notes plus the CRM stuck-deal view on the pilot pipeline.

## FAQ

**What does this checklist deliberately leave out?**

Vendor evaluation belongs in the CRM Evaluation Checklist and Vendor Scorecard. Moving data belongs in the CRM Migration Checklist. Launch day and hypercare belong in the CRM Go-Live Checklist. This one covers the build: scope, configuration, integrations, access, and pilot exit.

**How is this different from a project plan?**

A project plan tracks tasks and dates. This checklist defines the quality bar for leaving each phase, so a phase cannot start because the previous one ran out of calendar. Use both — the plan schedules the work, the checklist decides whether it is finished.

**What belongs in MVP?**

Whatever weekly pipeline operations need: accounts, contacts, deals, stages with next steps, roles, email sync if required, duplicate rules, and the manager boards. Park clever automations and edge-case fields until after launch.

**Do small teams really need a pilot?**

Scale the cohort down, but keep the gate. Even a handful of sellers running real deals for a week will surface stage, sync, and permission problems that a sandbox never will.

**What if a gate cannot be met before the date?**

Either move the date or have the sponsor risk-accept the gap in writing with a named owner and a fix date. Passing a gate silently is how launch-day incidents are made.

**Who signs pilot exit?**

The business sponsor, using the defect list and the pilot evidence. The implementation lead, admin, data owner, and the manager who ran the pipeline review should all have contributed before that decision.

## Related journey

1. [CRM Business Case Template](https://softwareglimpse.com/resources/crm-business-case-template/)
2. **CRM Implementation Checklist** (this resource)
3. [CRM Migration Checklist](https://softwareglimpse.com/resources/crm-migration-checklist/)
4. [CRM Go-Live Checklist](https://softwareglimpse.com/resources/crm-go-live-checklist/)
5. [CRM Training Plan](https://softwareglimpse.com/resources/crm-training-plan/)

## Related tools

- [CRM Implementation Planner](https://softwareglimpse.com/tools/crm-implementation-planner/)
- [CRM Migration Planner](https://softwareglimpse.com/tools/crm-migration-planner/)
- [CRM Requirements Builder](https://softwareglimpse.com/tools/crm-requirements-builder/?start=1)

---

Source: https://softwareglimpse.com/resources/crm-implementation-checklist/