Why most CRM strategies are written in the wrong order
The typical sequence runs: recognise the CRM is not working, evaluate replacements, select a platform, then commission a strategy to guide the implementation. By that point the strategy is an implementation plan. The consequential decisions — what problem this solves, whose process changes, who owns what — were made implicitly, by the shape of the software chosen.
This is why the research consensus on CRM failure keeps pointing at people and process rather than technology. It is not that software is unimportant. It is that software cannot make a decision the organisation declined to make. A platform configured around undefined processes faithfully encodes the ambiguity, then makes it expensive to change.
Decision 1: Which customer problem are you actually solving?
"Improve customer relationships" is not a strategy; it is a category. The decision needs to be specific enough that it excludes things — if your CRM strategy does not rule anything out, it will not prioritise anything either.
Specific looks like: new customers get inconsistent onboarding depending on which rep sold them, and that shows up in first-year churn. Or: our service team cannot see commercial context, so escalations get handled without knowing the account's value or renewal date. Or: we cannot tell which marketing spend produced revenue, so budget is allocated by argument.
Each of those points at different work. The first is process design; the second is integration; the third is attribution and definitions. A generic goal points at all three at once, which in practice means a two-year programme that delivers none of them.
Decision 2: Which processes have to change?
This is where CRM programmes get uncomfortable, and where the ones that avoid the discomfort fail. Software installed on top of an unchanged process produces the same outcomes with better logging.
Map how the work happens now — observed, not described. Descriptions come from managers and reflect the process as designed; observation comes from watching the people doing it and reflects the process as run. The gap between them is the entire subject. Every workaround you find is a place the current system does not fit the work.
- Trace one real customer end to end, from first touch through onboarding to renewal, naming every system and handoff
- At each handoff, ask what information is lost and who reconstructs it — the reconstruction work is your cost baseline
- Identify which steps genuinely differentiate and which are conventional; conventional steps should follow the platform's defaults, not your habits
- Decide explicitly which processes change to fit the software and which the software must accommodate — leaving this undecided is how customisation sprawl begins
Decision 3: Who owns each data domain and definition?
Ownership is the element most strategies skip and most failures trace back to. Every core metric needs exactly one documented meaning and exactly one named owner — not a committee, not a function, a person.
Start with the terms that appear in leadership meetings: qualified, pipeline, committed, active customer, churn. In most organisations each has two or three live meanings, all internally reasonable, which is why reports never reconcile. The fix is not a data project. It is a working session where the leaders of sales, marketing, service, and finance agree one meaning each and put their names to it — in a room, together, not circulated by email for silent non-approval.
Then make ownership durable. A registry of metric owners and data-domain owners, maintained inside the system rather than on a slide, is what keeps definitions from drifting the moment the person who set them changes role.
Decision 4: What evidence will prove it worked?
Decide before implementation, because afterwards the available data will conveniently suit whatever story is needed. Pick measures tied to the problem in decision one, capture the baseline now, and be honest about which ones move slowly.
Some measures move within a quarter: manual reporting hours, data completeness on required fields, handoff cycle time. Others take two to three quarters because they depend on new pipeline flowing through the new method — forecast variance is the standard example. Publishing that distinction in advance protects the programme from being judged at month four against a metric that structurally cannot have moved yet.
Where software selection actually belongs
Last. By the time you evaluate platforms you should be able to hand each vendor a written description of your five highest-volume workflows and ask them to demonstrate those specific flows with your terminology and your data. That is a fundamentally different conversation from a standard demo, and it surfaces fit problems while they are still cheap.
It also changes what you are buying. A company that has made these four decisions is buying a tool to execute a designed operating model. A company that has not is buying a hope that the tool will supply the design. The first purchase can succeed on any competent platform; the second fails on all of them.
If you already own the platform
Everything above still applies, minus the procurement. Run the four decisions against the system you have. In most cases the diagnosis is not that the platform is wrong — it is that processes were never designed, definitions were never agreed, and ownership was never assigned, so the configuration drifted into an accidental operating model.
That is repairable without a migration, usually inside a quarter, and worth doing first regardless. If you do replatform, this work has to happen anyway; doing it beforehand means you migrate a designed system instead of exporting the confusion into somewhere new.