aibrevo

CRM Implementation Checklist: How to Prepare Before a Vendor Starts

Before any CRM vendor touches your account, you need four things ready: a data audit, stakeholder sign-off on the sales process, a documented current-state workflow, and a written list of integrations — skipping any one of these is the most common reason kickoff week goes sideways.

Key takeaways

  • A CRM implementation project starts before the vendor does — data audit, stakeholder alignment and process mapping done beforehand shorten the paid engagement and prevent expensive mid-project scope changes.
  • Discovery and scoping typically runs about 10% of total implementation budget on most platforms (closer to 15% on Pipedrive and GoHighLevel) — the work you do before kickoff either shrinks that phase or gets absorbed into it at hourly rates.
  • The single most common cause of a rocky first week isn't the platform choice — it's starting configuration before the sales process itself has been agreed on by the people who run it.
  • A written stakeholder sign-off (not a verbal agreement in a kickoff call) on pipeline stages and required fields prevents the most expensive kind of rework: rebuilding automation after the process was 'finalized' twice.
  • If your data isn't clean enough to trust today, don't wait for the CRM to fix it — a lightweight audit before kickoff catches problems while they're still cheap to fix.
Discovery and scoping's share of total implementation budget, by platform Percentage of total CRM implementation budget typically spent on discovery and scoping, by platform: Pipedrive 15%, GoHighLevel 15%, Salesforce 10%, HubSpot 10%, Microsoft Dynamics 365 10%, Zoho CRM 10%, monday.com CRM 10%, Airtable 10%. Source: aibrevo per-platform implementation cost guides, cost-phase breakdowns, 2026. Pipedrive GoHighLevel Salesforce HubSpot Dynamics 365 Zoho CRM monday.com Airtable 15% 15% 10% 10% 10% 10% 10% 10% Source: aibrevo implementation cost guides, cost-phase breakdowns (2026)
Discovery and scoping typically runs 10-15% of total implementation budget depending on platform. See each platform's implementation cost guide for the full phase breakdown.

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.

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.

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

It’s easy to assume everyone shares the same definition of a successful implementation, and it’s a common source of quiet disappointment when they don’t. 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.

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.

Related reading

FAQs

How long before kickoff should we start preparing?

Two to four weeks is realistic for most SMB and mid-market projects — enough time to run a data audit, get stakeholder sign-off on the process, and document your current workflow without rushing any of the three. Enterprise projects with multiple business units often need longer.

Do we need to clean our data before the implementation starts, or can the vendor do that?

Most implementation partners will clean data as part of the project, but deciding what counts as a duplicate, what a stale record even is, and which fields actually matter is a business decision only your team can make well. Handing over a data set nobody has looked at just moves that decision-making into the paid engagement at a slower pace.

Who internally should own the pre-implementation checklist?

Someone with authority over the sales process itself — usually a RevOps or sales-ops lead — not IT alone. IT can own technical prep like access provisioning and integration credentials, but process and field decisions need someone who understands what the data is supposed to mean to the business.

What's the biggest mistake teams make before kickoff?

Assuming the sales team already agrees on how the process works. In practice, every rep has a slightly different mental model of the pipeline, and surfacing those disagreements in a kickoff call — instead of in a pre-kickoff workshop — burns paid discovery time re-litigating something that should have been settled beforehand.

Should we finalize our list of integrations before or during the implementation?

Before, as much as possible. A written list of every tool that needs to connect to the CRM — email, calendar, marketing automation, billing, a support desk — lets the vendor scope integration work accurately upfront rather than discovering a missing connector mid-build and re-quoting.

Do we need executive sponsorship for a CRM implementation to succeed?

Yes, in almost every case. A CRM implementation changes how people do their daily work, and without a visible executive sponsor insisting on adoption, the rollout tends to stall the first time a rep complains that the new process is slower than their old spreadsheet.

Is it worth running a current-state process map if we already know our sales process?

Usually yes — 'knowing' the process and having it written down with actual stage definitions are different things. A written process map surfaces exceptions and edge cases (what happens to a deal that gets paused for six months?) that live only in individual reps' heads until someone asks.

How detailed does the data audit need to be before kickoff?

Detailed enough to produce real numbers: total record count, an estimated duplicate rate from a manual sample, and a completeness check on the fields your reports actually depend on. A vague sense that 'the data's not great' isn't the same as knowing you have roughly 30% duplicate contacts and 40% of deals missing a close date.

Can a small team with no dedicated RevOps person still prepare properly?

Yes — the checklist scales down. A five-person sales team doesn't need a formal steering committee, but it still benefits from one person spending a few hours writing down the actual pipeline stages, checking data for obvious duplicates, and listing the tools that need to connect, before a vendor call starts.

What happens if we skip pre-implementation prep and just start the project?

The work still has to happen — it just happens during the paid engagement, usually at a slower pace because now it's competing with actual configuration time, and often after the vendor has already built against assumptions that turn out to be wrong once the real process surfaces.

Want a second opinion on your setup?

A free 30-minute call with an engineer. A written read on your current setup, whether or not you hire us.