CRM Implementation Strategy: Operating Model Before Software

Problem this solves

You're six weeks into a Salesforce rollout and the project has stalled. Sales ops built 10 years of logic in spreadsheets and email workflows. The CRM is technically installed but nobody's using it because their actual operating model doesn't fit the system — and nobody uncovered this until the data migration was already locked in. You need someone who understands why this happened and how to prevent the collapse that derails 80% of implementations.

Approach

I work backwards from your current operating model, not forwards from the software. First: audit how deals actually move, how your team makes decisions, where the real data lives (it's not where your system of record says it is). Second: map the gap between what you do now and what the system requires — this gap is your real implementation scope, and it's rarely what the vendor estimated. Third: sequence the change in phases that let people see value in weeks 2-3, not month 6. Tools matter, but operating model comes first. If Salesforce is the answer, we make it stick. If it's not, I'll tell you that too — it's happened three times.

Insight

The moment your team says 'the system doesn't work the way we work,' they're not complaining about configuration — they're telling you that someone skipped the operating model piece. Most implementations treat this as a change management problem and run more training. That fails because you're asking people to change how they work without giving them permission to change the business rules that made the old way necessary. The real work is figuring out which rules you should keep and which ones existed only because spreadsheets made them efficient. That conversation has to happen in weeks 2-4, not week 12.

In practice

Mid-market SaaS company, £8M ARR, 35-person sales team spread across three regions. Salesforce was live but adoption stuck at 22% after month three — field reps were still logging deals in email threads because the sales process in Salesforce didn't match how their deals actually moved (their reps had 40% longer sales cycles than HQ expected, so the stage gates in the system were disconnected from reality). We spent week one mapping the actual pipeline — what the field was doing, why, what decisions depended on which data. Turns out the regional teams had developed their own qualification logic because HQ's rules didn't account for a major customer type that paid differently. We rebuilt the pipeline stages to reflect actual deal motion for each customer segment, not one-size-fits-all. Adoption hit 71% in month two and stayed there because reps were logging deals the way they already worked. Revenue reporting accuracy improved from 'roughly correct' to audit-ready. The software didn't change. The operating model did.

Scope and fit

This works best when you're 4-12 weeks into an implementation and something's already signalling a problem — adoption is flat, your team is workaround-heavy, or you're realising the system doesn't fit how you actually operate. It requires senior sales leadership and ops to spend 10-15 hours mapping current state (you have to tell the truth about how things really work, not how the process doc says they work). This is not a full implementation delivery service — I'm not doing your data migration or training your team day-to-day. I'm fixing the strategic decisions that make or break implementations. Works less well if you have zero CRM experience and need handholding through basic configuration; that's better handled by a systems integrator. Also difficult if executive leadership is already locked into a decision and won't revisit it — I can't overrule that.

Expertise

11 years in CRM operations: 8 years scaling Salesforce across 200+ person teams as VP of Sales Operations at a SaaS company, managing go-live, adoption, and the scaling chaos that comes after. Founded a boutique CRM advisory practice focused on implementation strategy, not delivery. I've completed 18-24 engagements across tech, fintech, and SaaS — most of them recovery projects where the initial implementation stalled. Deep hands-on experience with Salesforce configuration, pipeline architecture, and the conversation between sales strategy and system design that separates projects that stick from projects that fail.