- The tool is the last decision, not the first.
- Document your actual sales process — not the ideal one — before opening a single demo.
- Change management is the implementation. Reps will use a system that helps them sell and ignore one that doesn't.
- Five first-90-days mistakes: configuring for the ideal process, too many fields too early, no data quality owner, measuring adoption by logins, treating go-live as the finish line.
You've been given the mandate. Implement a CRM. Make the sales team more organised, improve visibility, drive better outcomes. The timeline is aggressive. Everyone has an opinion about which tool to use. The vendors have already started emailing.
Here's the thing most CRM implementation guides won't tell you: the tool is the last decision you should be making, not the first. The organisations that get CRM right — the ones where adoption is high, data is clean, and the system actually drives behaviour — almost always spent more time on process design before the tool choice than they spent on the implementation itself.
The ones that get it wrong pick a tool in week one, spend three months configuring it to match how they think their sales process works, discover that their sales process doesn't actually work that way, and end up with a system that nobody uses and a contract they can't exit for two years.
Here's a framework for doing it in the right order.
Step 1: Document What Your Sales Process Actually Is — Not What You Think It Is
Before you open a single demo or read a single comparison article, spend two weeks doing one thing: talking to your sales reps about how they actually sell. Not how you want them to sell. How they do it today.
The questions that matter: How does a lead first come in? What's the first thing a rep does with it? What information do they need to know before they make contact? What does a good discovery call look like? When do they know a deal is real versus just interesting? What are the three or four moments in a deal where something has to happen for it to keep moving? What kills deals most often?
You are building a process map, not a pipeline. Most CRM implementations start by defining pipeline stages — Prospecting, Qualification, Proposal, Close — which are labels, not a process. A process describes what happens at each stage: what the rep does, what the customer does, what information needs to be captured, and what triggers the move to the next stage.
This exercise will take longer than you expect and surface more disagreement than you expect. That's the point. Every place where two reps describe the same situation differently is a place where the CRM will produce bad data if you don't resolve it first.
Step 2: Choose the Right Tool for Your Sales Motion
Once you understand your process, you can choose a tool that supports it rather than fighting it. The most important variable is not feature count — it's fit with your sales motion.
| If your sales motion is... | You likely need... | Avoid over-engineering with... |
|---|---|---|
| High-volume, short-cycle (under 30 days) | Lightweight CRM with strong automation — HubSpot, Pipedrive, or a modern AI-native option | Salesforce's full enterprise suite. The overhead kills velocity at this scale. |
| Mid-market, 30–90 day cycles | A CRM with solid workflow automation, playbook support, and forecast tools | Custom-built systems. You need vendor support and regular feature updates. |
| Enterprise, multi-stakeholder, 90+ day cycles | Salesforce or Microsoft Dynamics — the complexity is justified at this scale | Lightweight tools that can't handle territory management, approvals, or complex reporting. |
| Founder-led or early-stage (under 5 reps) | Something you can configure in a day — Notion CRM, Attio, or HubSpot free tier | Any platform requiring a dedicated admin. You don't have the capacity yet. |
The build vs buy question rarely needs much deliberation at the CRM layer. Building a custom CRM is a significant ongoing engineering commitment — schema changes, mobile support, security updates, reporting requests that never stop. Unless your sales process has genuinely proprietary logic that no commercial platform can accommodate, buy and configure. The edge cases where custom makes sense are much rarer than the enthusiasm for building one usually suggests.
Step 3: Change Management Is the Implementation
This is the part most implementation plans treat as an afterthought. It isn't. The technical configuration of a CRM takes weeks. Getting a sales team to actually use it takes months, and the outcome is determined almost entirely by decisions made before a single field is configured.
The first principle of CRM adoption is that reps will use a system that makes their job easier and ignore one that doesn't. That sounds obvious. Most CRM implementations violate it anyway — they're designed for management visibility, not rep productivity. Fields are added because managers want reporting, not because reps need them. Pipeline stages are created to match the forecast model, not the actual sale. The system becomes a thing reps do for their manager, not a thing that helps them close deals.
To avoid this, involve reps in the configuration process before it's finished. Not as a courtesy, as a requirement. Ask them: what would make this system worth opening? What information would help you before a call? What takes too long to log right now? You won't be able to accommodate every answer, but the ones you can incorporate will dramatically improve adoption.
The second principle is that the manager's behaviour sets the standard. If the CRM is bypassed in pipeline reviews — if decisions are made from memory and spreadsheets rather than the system — reps learn instantly that the CRM doesn't matter. The most powerful adoption lever available to a sales leader is using the CRM visibly and consistently in every deal conversation.
Mistakes to Avoid in the First 90 Days
Mistake 1 — Configuring for the ideal process rather than the current oneIt's tempting to use the CRM implementation as an opportunity to redesign your sales process. Resist this. Implement the process you have, get adoption, then improve. Trying to change process and technology simultaneously is a reliable way to achieve neither.
Mistake 2 — Adding too many fields too earlyEvery field you add is a field a rep has to fill in. Start with the minimum viable set of data you actually need to run the business — stage, close date, value, next step, and one or two deal-specific fields. Add fields only when you have a specific use case for the data. Most CRMs end up bloated with fields that were added speculatively and never used.
Mistake 3 — No data quality ownerA CRM without someone responsible for data quality degrades quickly. Duplicates accumulate. Fields get used inconsistently. Closed deals don't get updated. Assign one person — usually in RevOps or Sales Ops — with explicit responsibility for data hygiene, and give them the authority to enforce it.
Mistake 4 — Measuring adoption by loginsLogin rates are a vanity metric. The real adoption signal is data completeness and timeliness — are reps updating opportunities before pipeline reviews rather than during them? Are next steps being logged? Is the forecast being built from system data rather than manager overrides? Measure those things instead.
Mistake 5 — Treating go-live as the finish lineThe implementation is not complete on go-live day. It's complete when the CRM is the primary system reps use to manage their deals. That typically takes 60–90 days of consistent reinforcement after go-live. Build that into your plan and your expectations.
The Right Question to Ask Before You Start
Q1: Can you write down your sales process in five to seven steps, with a clear definition of what has to be true for a deal to move from each step to the next? If the answer is no — or if two sales leaders would write different versions — resolve this before you evaluate a single vendor.
Q2: Who owns adoption post-launch, and what does success look like at 30, 60, and 90 days? If you don't have answers to both parts of this question, you have a tool selection project, not an implementation project.
A CRM that's configured correctly and adopted poorly produces worse outcomes than a simple spreadsheet used consistently. The technology is not the intervention. The behaviour change is.