CRM Implementation Checklist: How to Prepare Before a Vendor Starts

A CRM implementation project doesn’t start when the vendor sends a kickoff invite — it starts weeks earlier, when someone on your team decides what “ready” actually means. Discovery and scoping is baked into every implementation’s cost structure, typically 10-15% of the total budget depending on platform. The question isn’t whether that work happens; it’s whether it happens before the paid engagement starts, when it’s cheap and unhurried, or during it, competing with actual build time.

This checklist covers the four things worth having in place before a vendor — or an internal admin — starts configuring anything: a data audit, stakeholder alignment on the sales process, a documented current-state workflow, and a written integration list. None of these require CRM expertise. They require someone on your team spending focused time answering questions only your team can answer.

Why pre-kickoff prep matters more than platform choice

Most guidance on CRM projects focuses on which platform to pick — a legitimate question covered in our CRM buyer’s guide — but platform choice matters less to a rocky rollout than most people assume. The far more common failure pattern is a technically sound implementation on the right platform that stalls in the first month because the underlying process was never actually agreed on, or the data that got migrated was never actually clean.

A vendor can only configure what you tell them. If your team hasn’t settled on what a “qualified lead” means, or whether a deal can skip a pipeline stage, the vendor will either guess (and probably guess wrong) or burn discovery-call time getting your team to argue it out live — at a slower, more expensive pace than a pre-kickoff workshop would take. Preparation doesn’t eliminate the work; it moves the work to before the clock is running and lets the paid engagement focus on configuration instead of decision-making.

Step 1: Audit your data honestly, before anyone asks you to

Before a migration is even scoped, someone should look at your current data with an honest eye. How many contacts and companies look like duplicates? How consistently are picklist fields populated — “Enterprise,” “enterprise,” and “ENT” all meaning the same thing is a common finding? How many records that matter to your reporting are missing a required field?

This doesn’t need to be exhaustive. A structured sample — pull 200-500 records and manually check field completeness and obvious duplicates, then extrapolate — gives you real numbers instead of a vague sense that “the data’s not great.” If you already know a migration is coming, our CRM migration guide and the companion piece on data cleaning before migration go deeper on the mechanics of de-duplication and standardization. For pre-implementation purposes, the goal is narrower: know your actual numbers before anyone quotes you a migration timeline based on guesses.

The output of this step should be a short written summary — total record count, an estimated duplicate rate, and a list of which fields your leadership’s weekly reports actually depend on, with a completeness percentage for each. That document alone will save real time in a scoping call, because it replaces “our data’s messy” with something a vendor can actually price against.

This isn’t a minor housekeeping step. Gartner’s 2025 research on agentic AI projects built on CRM data found that roughly 40% will be scrapped or stalled by 2028, and the cited reason isn’t the AI itself, it’s the data quality underneath it. Any team planning to layer AI-driven scoring, routing or forecasting on top of a new CRM within the next year or two is effectively building on whatever data quality baseline gets set during this audit step — a shaky foundation here doesn’t just risk a rocky rollout, it risks the automation project that’s supposed to come after it.

Step 2: Get the sales process agreed on, in writing, before anyone configures anything

Every sales team believes it has a defined process. Very few have it written down in a way that survives contact with actual edge cases. Before kickoff, run a short internal exercise — even just a whiteboard session with sales leadership and two or three individual reps — to answer:

• What are the actual pipeline stages, in order, and what specifically moves a deal from one to the next?
• What happens to a deal that stalls — does it get demoted, marked as a separate status, or just sit?
• Which fields are genuinely required to move a deal forward, versus nice-to-have?
• Who owns a lead the moment it comes in, and how does that ownership get assigned?

The value here isn’t the document itself — it’s surfacing disagreement early. It’s extremely common for a sales manager and two reps to describe “the process” three different ways, each confident theirs is right. If that disagreement gets discovered during a live kickoff call with a vendor billing by the hour, it gets resolved under time pressure, usually in favor of whoever’s loudest. If it gets discovered internally beforehand, it gets resolved properly — and the vendor configures against a process your team has actually agreed to, not one improvised in the room.

Get explicit sign-off — an email thread, a shared doc with named approvers, anything with a paper trail — from whoever has authority over the sales process. Verbal agreement in a meeting is the single most common source of “wait, that’s not what we said” disputes three weeks into a build.

Step 3: Document your current-state workflow, not just the ideal one

A process map of how sales should work is useful. A process map of how it actually works today — warts included — is more useful for implementation purposes, because it surfaces the exceptions a vendor needs to design around. Does a specific type of deal (an upsell, a renewal, a referral) actually move through a different path than new business? Does anyone maintain a shadow spreadsheet because the current system can’t handle something? Is there a step nobody talks about because it’s technically against policy but everyone does it anyway?

None of this needs sophisticated tooling — a simple flowchart or even a bulleted list per deal type is enough, as long as it’s honest about current reality rather than aspirational. The point isn’t to preserve bad habits in the new system; it’s to make sure the vendor knows about them so a deliberate decision gets made — fix it, replicate it, or explicitly retire it — instead of the exception silently falling through the cracks because nobody mentioned it existed.

Step 4: Write down every integration before you get a quote

Integration count and complexity move implementation cost and timeline more than almost any other variable, across every platform. Before scoping starts, write a complete list of every tool that needs to connect to the CRM: email and calendar, marketing automation, a billing or invoicing system, a support desk, an ERP if relevant, and any internal tool with an API. For each one, note whether the connection needs to be one-way or bidirectional, and roughly how critical real-time sync is versus a daily batch update being fine.

This list does two things. First, it lets a vendor scope integration work accurately in the initial quote rather than discovering a missing connector mid-build and re-quoting — a common source of budget surprises. Second, it forces your own team to notice integrations they’d been quietly assuming would “just work” without anyone actually checking. Our CRM integrations guide covers what typically breaks when this step gets skipped, by integration category.

Step 5: Line up stakeholder time before the project starts, not during it

A CRM implementation needs meaningful time from people who aren’t full-time on the project — sales leadership for process sign-off, an IT contact for access and credentials, someone from finance if billing integration is in scope, and end users for training and feedback sessions. Projects that stall mid-build often stall not because the vendor is behind, but because a key stakeholder’s calendar has no room for a 30-minute review call for two weeks.

This shows up in a predictable way: a vendor finishes a pipeline configuration and sends it for sign-off, and the one sales director who can approve it is traveling for the next ten days. The build sits idle, the vendor’s team either moves on to a different client’s work or bills idle hours waiting, and the two-week delay quietly becomes a three-week delay once the director is back and needs a day to actually review it properly instead of rubber-stamping it between meetings. None of this is the vendor’s fault or the stakeholder’s fault individually; it’s a scheduling problem that a five-minute calendar-blocking conversation before kickoff would have prevented entirely.

Before kickoff, get rough calendar commitments from each stakeholder for the likely project duration. This is a five-minute conversation that prevents a genuinely common failure mode: a technically finished build sitting unreviewed because the one person who can approve the pipeline stages is unreachable.

Step 6: Agree on what success actually looks like before go-live

Success needs an explicit, written definition before kickoff, because different stakeholders quietly carry different ones, and the gap only surfaces after go-live when it’s too late to renegotiate cheaply. Before kickoff, get explicit agreement from stakeholders on what “done” and “working” mean: is success full rep adoption within 30 days, a specific reduction in manual data entry, a defined set of reports leadership can trust on day one, or some combination? Write these down as a short list, not a vague aspiration.

This matters because “the implementation didn’t go well” is a surprisingly common complaint even on technically well-executed projects, and it usually traces back to mismatched expectations rather than a real defect. A sales leader who expected instant forecast accuracy and a vendor who delivered a correctly configured pipeline with three months of history still to accumulate are both technically right and still going to have an uncomfortable conversation if nobody agreed in advance on what “success” meant on day one versus day ninety. Setting this expectation explicitly — including a realistic timeline for when harder-to-measure benefits like forecast accuracy actually show up — prevents that conversation from happening at all.

What belongs in a written scope agreement before you sign anything

A scope agreement needs specifics, not a platform name and a dollar figure. Before signing with any implementation partner — internal team or outside vendor — get in writing: the exact pipeline stages and required fields to be built (not “a configured pipeline,” but the actual stage list agreed in step 2 above), which integrations are explicitly in scope and which are explicitly excluded, an estimated record count for data migration, a defined number of revision rounds included per deliverable, and a named point of contact responsible for sign-off on each side.

The integrations-in/integrations-out distinction matters more than it sounds. A vague scope line like “standard integrations included” invites disagreement the first time your team assumes a tool is covered and the vendor assumes it isn’t — usually discovered mid-build, at the worst possible time to renegotiate price. The CRM integrations guide covers what typically breaks by integration category, which is useful context to have before writing this section of the scope document, not after.

Revision rounds are the other line item that gets skipped and then argued about later. “Two rounds of pipeline configuration revisions included” is a specific, checkable commitment; “we’ll work with you until it’s right” sounds generous in a sales call and becomes a source of friction the moment round four rolls around and one side thinks it’s included, the other thinks it’s billable.

Step 7: Decide access, roles and security settings before the vendor needs them

Access provisioning is the prep step most often left until the vendor asks for it mid-build, which is exactly when it causes the most delay, because “who should see what” turns out to be a business decision, not an IT ticket. Before kickoff, decide: who gets admin access versus standard user access, whether reps should see only their own deals or the full pipeline, whether commission-sensitive fields (deal value, close probability) need role-based restrictions, and whether the company already has single sign-on (SSO) infrastructure the CRM needs to plug into rather than running its own separate login.

This matters more than it sounds like it should, because role and permission structures are foundational to how the CRM gets built, not a setting toggled after the fact. A vendor who configures a flat permission structure because nobody specified otherwise, then has to retrofit role-based visibility once someone in finance objects to reps seeing each other’s commission-relevant numbers, is redoing real configuration work that a five-minute decision before kickoff would have avoided. The same applies to SSO: if your company already runs Okta, Azure AD, or Google Workspace SSO, deciding whether the CRM integrates with it is a decision that affects onboarding flow, password-reset process, and security posture, and it’s considerably easier to build in from day one than to bolt on after users already have standalone credentials they’re used to.

A short written access matrix — role name, what that role can see, what that role can edit, and whether SSO applies — is enough. It doesn’t need to be a formal security document unless your industry’s compliance requirements call for one, but it does need to exist somewhere the vendor can reference instead of guessing or defaulting to “everyone sees everything,” which is the default most implementation teams fall back on when nobody specified otherwise, and the default that’s hardest to walk back once reps are used to seeing data that should have been restricted from day one.

Common kickoff-week failure patterns, and which prep step prevents each one

Most rocky kickoff weeks trace back to one of a small number of repeatable patterns, and each one maps directly to a specific piece of the checklist above.

The team can’t agree on a pipeline stage in the first discovery call. This is step 2 surfacing live instead of in a pre-kickoff workshop — a sales manager and two reps each describe the process differently, and the disagreement now eats billable discovery time instead of getting resolved beforehand at no cost.

The vendor asks for a list of integrations and the team improvises one on the spot. This is step 4 skipped — a tool everyone assumed would “just work” turns out to need a custom connector, discovered mid-call instead of written down in advance, which either delays scoping or gets missed entirely and surfaces as a mid-build surprise.

A data sample the vendor pulls looks far messier than anyone expected. This is step 1 skipped or done too casually — nobody ran even a lightweight audit, so the real duplicate rate and field-completeness numbers were unknown going in, and now the vendor is discovering (and billing for) what a 200-record manual sample would have surfaced for free beforehand.

A finished deliverable sits waiting for approval because the one person who can sign off is unavailable. This is step 5 skipped — no calendar commitments were confirmed before the project started, so a genuinely finished piece of work stalls for reasons that have nothing to do with the vendor’s pace.

Go-live happens, and within two weeks leadership says the implementation “didn’t go well” despite a technically correct build. This is step 6 skipped — nobody wrote down what success actually meant before the project started, so a technically sound implementation gets judged against an expectation that was never made explicit, let alone agreed on.

None of these patterns are platform-specific, and none require unusual bad luck to occur — they’re the predictable result of skipping one specific piece of prep, which is exactly why they’re avoidable with a few focused hours of work before the vendor call, not a structural flaw in the implementation itself.

A realistic pre-kickoff timeline

For a typical SMB or mid-market project, the four preparation steps above don’t need to happen sequentially or consume weeks of full-time effort. A realistic timeline looks like: week one, someone runs the data audit and drafts the integration list in parallel; week two, a short workshop with sales leadership and two or three reps produces the process map and surfaces disagreements; by the end of week two or into week three, sign-off is collected in writing and stakeholder calendar commitments are confirmed. Two to three weeks of part-time effort from one or two people is enough for most projects — this isn’t a second full-time job, it’s focused attention at the right moments.

Enterprise projects spanning multiple business units or requiring coordination across several stakeholder groups reasonably take longer, since alignment itself becomes a bigger undertaking with more people whose sign-off actually matters. The principle scales regardless of size: better to spend the extra time before the clock on a paid engagement starts than to discover misalignment mid-build.

Preparation looks different depending on what you’re actually doing

If this preparation is happening ahead of a first-ever CRM implementation, the checklist above covers the full scope of what matters. If it’s happening ahead of switching an existing CRM to a new platform, the data audit and cleaning work is more involved — enough that it’s covered in its own dedicated guides on data cleaning before migration and the full CRM migration guide, both worth reading alongside this checklist rather than instead of it. And if the goal is simply choosing which platform to implement in the first place, that decision belongs before any of this — see the CRM buyer’s guide for how to match a platform to your team size and process complexity.

What “ready” actually looks like

By the time a vendor starts, a genuinely prepared team has: a short written data-audit summary with real numbers, documented and signed-off pipeline stages and required fields, an honest current-state process map including known exceptions, a complete integration list with criticality notes, and calendar commitments from every stakeholder whose input the project needs. None of this requires CRM expertise — it requires someone willing to spend a few focused hours turning “we know our process” into something a vendor can actually build against.

Teams that skip this and go straight to a kickoff call aren’t skipping the work — they’re just doing it later, slower, and under worse conditions. A free 30-minute scoping call is a reasonable next step once this groundwork is done; it’s also a reasonable place to sanity-check whether your prep is thorough enough, before signing anything.