Skip to content Last reviewed: August 2026 | Next review: February 2027
Most organisations believe they have a unified sales process because the stages exist in the CRM. But stage names are only the visible label.
The real process is everything underneath: how leads are defined, routed, accepted and converted; how opportunities are created; what must be true before a quote is produced; who approves what; and how a contract becomes booked revenue.
When that underlying process is not unified, technology can work exactly as specified and still deliver very little. The system records activity, but the business does not get clarity.
“Stage names are the label. The sales process is everything underneath.”
CRM failure rates have been studied for two decades and barely moved. Gartner has reported figures between 50 and 70 percent, Forrester around 47 percent, and independent 2025 research from Johnny Grow puts it at 55 percent using an explicit definition of failure as not meeting stated business objectives. The range is wide because everybody defines failure differently, which is worth remembering before quoting any single number.
What matters is the shape rather than the precision. Platforms have improved enormously over twenty years. The failure rate has not improved with them. If better software is not producing better outcomes, the constraint is somewhere else, and the two causes that come up repeatedly in the analyst literature are process and adoption rather than technology. Forrester’s work identifies clean data migration as one of the top three success factors in CRM implementation, cited by roughly seven in ten successful projects.
Clean data migration is a symptom, not a cause. Data is only clean if the process that generates it is consistent.
For a single-product business selling in one country through one motion, process variation is a nuisance. You can absorb it.
Complexity changes that, and it arrives from three directions at once.
Different regions build different local workarounds, usually for legitimate reasons: local legal requirements, tax treatment, language, a major customer with a bespoke commercial arrangement. Each is defensible on its own. Collectively they mean the word "qualified" carries a different meaning in three regions, so any global number built on top is an average of things that are not the same.
Multi-product businesses accumulate process by acquisition and by product line. The software business runs one motion, the services business another, the maintenance renewal business a third. Each was correct when it was built. None of them were designed to coexist.
Direct, inside, partner and marketplace motions all need to land in the same system with the same definitions if you want to see the whole picture. In practice partner-sourced business is usually the last thing to get proper process treatment, which is why partner pipeline is the least trusted number in most businesses that have one.
Any one of these is manageable. All three, which is the normal condition for a technology business between £100m and £1bn, produce a situation where nobody can answer a simple question about the business without three analysts and a week.
This is the part that gets skipped, so it is worth being specific about scope. Unifying the sales process means agreeing the following as one design, then permitting deliberate local variation on top of it rather than discovering accidental variation underneath.
Lead management: Definition of a lead, sources, routing rules, service level for acceptance, what happens on rejection, and the conversion event that creates an opportunity. Most disputes between sales and marketing are traceable to this being undefined rather than to either function underperforming.
Opportunity management: Creation criteria, ownership, stages and their exit criteria, splits between teams, close and loss reasons, and what happens when a deal spans multiple products or regions.
Quoting and configuration: What can be quoted, by whom, at what discount level, with what approval path, and how a quote relates to the opportunity record. This is where multi-product businesses tend to break first, because product-specific quoting logic resists standardisation harder than anything else in the chain.
Contracting: Approval workflow, signature, execution, and the handover into fulfilment and billing. The step most likely to be sitting outside any system, in an inbox.
Booking and revenue recognition: The point at which sales stops and finance starts, and the definitions that have to agree across that line.
Renewal and expansion: Often designed separately, or not designed at all, and then bolted onto a process built for new business.
The test is simple. Take one deal type and walk it end to end across two regions and two products. Every point where the answer differs is either a deliberate design decision or an accident. Most organisations have never done this walk and are surprised by the result.
Process defines the data. Which means the data model is not an IT deliverable, and treating it as one is how organisations end up with systems that technically work and reports nobody trusts. Revenue operations should own the design and the governance. Sales has to supply the commercial definitions that go into it.
There are two layers, and confusing them causes real damage.
Segmentation framework and how accounts are assigned to it. Territory and region definitions. Route-to-market classification. Product hierarchy as sales uses it, which is frequently not how finance or engineering structures it. Opportunity type, sales motion, competitive position, loss reason taxonomy. Stage exit criteria. These are commercial design decisions expressed as fields, and sales has to own them because nobody else can define them correctly.
Legal entity and customer hierarchy, unique identifiers, addresses, credit and tax status, product master, currency. This is front-to-back organisational data with governance that reaches well beyond sales, and sales is a consumer of it rather than an owner.
The friction sits at the join. Sales wants to see a global account as one relationship. Finance needs it as multiple legal entities. Both are right, and the reconciliation between them has to be designed rather than left to whoever builds the report.
Get this layering wrong and the consequences are familiar. Segmentation that cannot be applied consistently. Territory definitions that do not reconcile to the comp plan. Pipeline by product that does not tie to the revenue plan. Every one of those is a data model problem wearing a reporting problem’s clothes
Once the process is unified and the data model is agreed, the technology question becomes tractable, which is exactly why so many organisations reach for it first. It is the part that looks tractable.
CRM sits at the centre as the system of record. Around it sits an integration layer that most businesses at this scale end up running: prospecting and engagement platforms such as Outreach or Salesloft, enablement and content platforms such as Highspot or Seismic, CPQ, contract lifecycle management and e-signature, commissions and incentive compensation, partner relationship management if you have a channel, digital adoption tooling such as WalkMe, conversation intelligence, and forecasting.
Every one of those integrates against the process and the data model. If a stage means different things in two regions, the enablement platform cannot serve the right content, the forecasting tool cannot weight the pipeline, the commissions engine cannot calculate correctly without manual adjustment, and CPQ approval routing has to be configured three ways.
The sequencing rule is uncomfortable and it holds. Process, then data model, then platform selection, then configuration. Organisations that invert it end up encoding their inconsistencies into software, at which point the inconsistencies become expensive to change rather than merely annoying.
Which is not an argument for a two-year process programme before anybody buys anything. That fails differently, by delivering a beautiful process design into a business that stopped waiting eighteen months ago. The workable answer is to unify the process for one motion, prove it, implement it, and move to the next, accepting that the estate will be inconsistent while you do it.
This is the part that has changed, and it has changed faster than most sales organisations have adjusted to.
Gartner predicts that through 2026, organisations will abandon 60 percent of AI projects that are not supported by AI-ready data, following a survey of 248 data management leaders in which 63 percent either did not have or were unsure they had the right data management practices for AI. Forrester has identified data quality as the primary factor limiting B2B adoption of generative AI.
Nothing about that is specific to sales, but sales is unusually exposed, because sales data is mostly generated by people entering it under time pressure rather than by systems.
The chain runs one way. Process determines what gets captured and when. Capture consistency determines data quality. Data quality determines whether an AI model produces something you can act on. Break the first link and everything downstream inherits the fault, at speed and at scale.
The failure mode is worse than the pre-AI version. A bad report is visibly bad, so somebody argues with it and it gets fixed. A model trained on inconsistent stage definitions produces a confident, plausible, precisely-formatted forecast that is wrong in ways nobody can see. It industrialises the error rather than surfacing it.
There is a version of this that is encouraging. The AI capability now available to a sales organisation with clean process and consistent data is a real advantage and it is available now rather than in three years. Deal scoring that works, forecast models that are not just weighted pipeline, automated capture that reduces the administrative load that caused half the data problems in the first place, and agents that can execute steps of a process that is defined well enough for them to follow.
That last point is the one worth sitting with. An agent can only execute a process that has been specified. Every ambiguity a human seller resolves by judgement is a place an agent stops or improvises. The organisations that unified their process for boring operational reasons over the last few years are now finding they have accidentally built the prerequisite for something considerably more interesting.
Process discipline used to be an efficiency argument. It is now a capability argument, and the gap between organisations that did the work and organisations that did not is going to widen rather than narrow.
Five objections come up every time this argument is made in a room. Most of them are reasonable.
“We are global. A single process is unrealistic, and imposing one would break how our regions actually sell.” Partly right, and the framing is wrong. The argument is not for uniformity. It is for a designed core with deliberate local variation on top, versus accidental variation underneath that nobody documented. Local legal, tax and language requirements are real and permanent. A region using a different definition of a qualified opportunity because somebody configured it that way in 2019 is not. The test for any variance is whether you can name the reason and the owner.
“Our new CRM implementation will fix this.” It will not, and the implementation is the moment the problem becomes permanent. Configuration decisions get made under time pressure by people trying to hit a go-live date, and whatever ambiguity exists in the process gets resolved into the build by whoever is in the room that afternoon. You are not deciding whether to design the process. You are deciding whether to design it deliberately or have it designed for you by a systems integrator’s configuration workshop.
“We cannot stop the business for two years to fix process.” Correct, and you should not. That is why the sequencing is per motion rather than enterprise-wide. Unify one, prove it, implement it, move to the next. Big-bang process programmes fail for the same reason big-bang system implementations do, and there is reasonable evidence that phased rollouts outperform them substantially.
“This is revenue operations work, not sales leadership work.” It is revenue operations work. RevOps should own the design, the build and the governance, and in most organisations at this scale it is the only function positioned to hold the whole picture.
But it cannot be done by RevOps alone, and this is where it usually goes wrong. Sales sets the commercial definitions, because nobody else can say correctly what qualified means, how segmentation works, or when a deal is genuinely committed. Finance owns the booking and revenue recognition boundary and the master data that sits behind it. Product owns the hierarchy that sales then has to consume in its own structure. IT owns the platform architecture and the integration estate. Systems integrators and platform partners bring the implementation patterns and know where the configuration constraints actually are.
RevOps holds the pen. It does not hold all the answers, and a process design produced without those parties in the room will be technically coherent and commercially wrong. The version that fails most often is not the one where sales refused to engage. It is the one where RevOps was left to work it out alone because everybody agreed it was their job.
“AI tooling will clean the data anyway.” It will help with completeness and with some forms of normalisation, and it is useful for that. It cannot resolve a definitional conflict, because there is no ground truth to resolve it against. If two regions mean different things by the same stage, no model can tell you which one was right. It will produce a confident answer and you will not be able to tell it is wrong.
The pattern across all five is the same. Each objection is really an argument for deferring the work, and each deferral makes the work larger and more expensive rather than smaller.
This is RISE: infrastructure and execution. Process, data, execution rhythm and technology, in that order, because that is the dependency chain.
RISE is the layer everything else runs on. PACE cannot work without it, because a play with no traceability cannot be evaluated and an academy with no adoption data cannot be improved. PERFORM cannot be planned without it, because capacity models, coverage design and quota setting all depend on data that means the same thing everywhere it is measured.
It is also the least visible of the three, which is why it is chronically underfunded. Nobody puts a data model on a board slide. The consequences of not having one show up on every board slide, attributed to something else.
The Diagnostic starts here more often than clients expect. A pipeline problem or a forecast problem is frequently a process problem that has been visible for years in a form nobody recognised.
If your systems are working and your numbers still do not reconcile, that is the conversation to have. Get in touch.
Browse more perspectives from our team of operators and advisors.
The best first step is a simple conversation about where your sales organisation stands, and what to fix first. No pressure, no pitch.
A practitioner-led sales transformation practice anchored on the COMPOSE Sales Model®.
Copyright © Compose Sales Partners Limited. COMPOSE Sales Partners, the Compose Sales Partners logos, COMPOSE Sales Model is a trademark and service mark of COMPOSE Sales Partners Limited. PERFORM, PACE, and RISE are proprietary frameworks of COMPOSE Sales Partners. Other brands and product names are the trademarks of their respective companies.
Optimized by Seraphinite Accelerator
