Insights · Sales process
Why sales technology implementations fail, what a sales process actually contains beneath the stage names, how AI has changed the design work, and why none of it helps you until the process is unified.
Umar Gill, F.ISP
Managing Partner, Compose Sales Partners
Last reviewed August 2026 · Next review February 2027
The short version
A sales process defines what you want people to do. It is not a description of how a system works.
Implementations fail because selling was never unified first, not because the software fell short.
Asking sellers what they need and building to it is the most common mistake. Build to a spine that operationalises the strategy.
Flavours for renewals, new business and transactional deals are fine. The spine stays the same.
AI has made process design faster, cheaper and far more accessible than it has ever been.
And an agent can only execute a process that has been specified, which makes this a capability question rather than an efficiency one.
Stage names are the label. The sales process is everything underneath.
I have been designing sales processes for years. Sales processes, quoting and CPQ processes, lead to cash, and the qualification frameworks that sit inside them. In businesses turning over fifty million and in businesses turning over four billion.
The answer has never changed. Every failed systems implementation I have seen failed for the same reason, which is that nobody unified the sales process first, or nobody was properly looking at what the process was supposed to do in the first place.
Most organisations believe they have a unified process because the stages exist in the CRM. The stages are the label. The process is everything underneath.
Umar Gill, F.ISP
Managing Partner, Compose Sales Partners
Every failed implementation I have seen failed for the same reason. Nobody unified how the business sells before they tried to automate it.
Not the stage names, which are usually agreed early and easily. The layers underneath: the value chain, the exit criteria, the activities on both sides of the table, who does what and where the work passes between them, the data captured at each point, and how qualification actually applies. Without agreement on those, a configuration workshop is not implementing a process. It is inventing one, under time pressure, in a room that does not have the authority to make those decisions.
CRM failure rate as reported by Gartner over two decades of study.
Forrester’s figure for the same measure.
Johnny Grow, 2025, against an explicit definition of not meeting stated business objectives.
Successful projects citing clean data migration as a top three success factor. Forrester.
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 causes that come up repeatedly are process and adoption rather than technology.
Clean data migration is a symptom, not a cause. Data is only clean if the process that generates it is consistent.
The order that holds
Uncomfortable, and it holds. Invert it and you encode your inconsistencies into software, at which point they become expensive to change rather than merely annoying. Which is not an argument for a two-year process programme before anybody buys anything. Unify one motion, prove it, implement it, move to the next.
What this looks like in practice
Three regions agree the stage names in an hour and then spend six months discovering they meant different things by them. Quoting rules get built to match what the product teams already do rather than what the commercial model requires. Handoffs never get designed, so the system has no idea who owns the work after a demo.
You cannot automate an agreement that was never reached.
None of that is a software defect. The platform did exactly what it was configured to do. Unify the selling first, and the technology question becomes a question about tools rather than a question about what the business actually does.
A sales process is designed in layers, and each one derives from the one above it. Get the order wrong and everything below inherits the fault.
Most organisations start somewhere in the middle, usually at stage names, and work outwards. It is the reason so many processes look complete on a slide and fall apart the first time somebody asks who does what.
End to end, from demand creation through to a customer who is live and being served. Before any stages exist, you need agreement on what the whole chain is and where sales sits inside it.
The part everybody thinks is the process. Stages, and far more importantly the exit criteria that let a deal move from one to the next. A stage without an exit criterion is a label.
Customer-facing and internal, separated deliberately. What the seller does with the buyer, and what the organisation does around them: approvals, reviews, configuration, legal, credit. Both are real work and only one of them usually gets designed.
Who performs each activity, who approves, who is consulted, and where the work passes between people or functions. Handoffs are where deals stall and where accountability quietly disappears, and they are almost never documented.
What gets captured at each point, and what gets refined as the deal progresses. Data is an output of activity, so it can only be designed once you know what the activity is. This is also where the qualification framework lives, whether that is MEDDPICC, BANT or something of your own.
Only now does it become a systems question. How the design is enforced, automated and recorded. Everything above this line is a business design decision. This line is where it meets the software.
One spine, several flavours
You will need variants. A renewal does not run like a new business pursuit, and a transactional deal should not be forced through a process built for nine-month cycles.
That is fine and it is normal. What should not vary is the spine: the same value chain, the same definitions, the same data captured at the same points. Flavours sit on top of a spine. They do not replace it.
The test
Can somebody new do the job from what is written down?
Not can they find the right screen. Can they work out what to do, who to involve, what has to be true before they move on, and what happens next. If the answer depends on asking a colleague who has been there five years, the process lives in that colleague’s head rather than in the business.
Process defines the data, so the data model is not an IT deliverable. Treating it as one is how organisations end up with systems that technically work and reports nobody trusts. There are two layers, and confusing them causes real damage.
Segmentation 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. 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. Front-to-back organisational data with governance reaching 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 has to be designed rather than left to whoever happens to build the report.
Get the 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.
This work used to be slow, expensive and largely the preserve of organisations big enough to fund a transformation office. That has changed, and faster than most people have adjusted to.
Not the thinking. The thinking is the same as it always was. What has collapsed is the effort of capturing it, documenting it, testing it against scenarios and keeping it current.
Mapping a current state used to take weeks of interviews and a wall of sticky notes. Documenting a target design took weeks more. That work compresses dramatically, so more of the budget goes into the decisions rather than into writing them up.
The effort used to be much the same regardless of company size, which put proper process design out of reach for anybody mid-sized. That gate has come down. A business turning over fifty million can now get to a properly designed process for a fraction of what it used to cost.
A process used to be locked for three years because revisiting it meant reopening everything. Design that is properly documented and modular can be revised in a quarter, which matters when your route to market changes faster than your platform roadmap.
The more interesting one. Some steps exist only because a human had to do them, and may not need to exist at all. Research, preparation, data capture, first-pass qualification. Designing for that is a different exercise from automating what you already do.
What it has not changed
The decisions themselves. What qualified means in your business. Where the handoffs sit. Who approves a discount and at what level. How a renewal differs from a new sale. Those are commercial judgements and they still require people who understand the business to sit in a room and make them.
AI removes the effort of capturing the decisions. It does not remove the need to make them.
Design for what is coming
Design the process for agents as well as people.
If part of your process will be executed by something other than a person within two years, and for most businesses it will, the specification has to be tight enough for that now. A step described loosely enough for an experienced seller to interpret is a step an agent cannot run at all.
Variation is the thing that breaks it, and in most businesses variation arrives from three directions at once.
Regions build local workarounds, usually for legitimate reasons: local legal requirements, tax treatment, language, a major customer with a bespoke arrangement. Each is defensible on its own.
Collectively they mean qualified means three different things, and any global number 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 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 with the same definitions if you want to see the whole picture.
Partner-sourced business is usually last to get proper 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 together, which is the normal condition for most mid-market and enterprise businesses, produce a situation where nobody can answer a simple question about the business without three analysts and a week.
That used to be a reporting problem. You worked around it, the analysts reconciled it, and everybody accepted the numbers were approximately right. That tolerance has gone, because the same variation now decides what AI can and cannot do for you.
of AI projects not supported by AI-ready data will be abandoned through 2026. Gartner.
of data management leaders either did not have, or were unsure they had, the right practices for AI. Survey of 248.
identified by Forrester as the primary factor limiting B2B adoption of generative AI.
Sales is unusually exposed here, 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 a model produces something you can act on.
And AI cannot fix the thing that caused it. It will help with completeness and with some forms of normalisation, and that is genuinely useful. 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.
Which makes the failure mode worse than it used to be. A bad report is visibly bad, so somebody argues with it and it gets fixed. A model built on inconsistent definitions produces a confident, plausible, precisely formatted answer that is wrong in ways nobody can see. It industrialises the inconsistency rather than surfacing it.
The other side of it
The capability now available to an organisation with a unified process and consistent data is real, and available now rather than in three years. Deal scoring that works. Forecast models that are not just weighted pipeline. Automated capture that removes the administrative load that caused half the data problems in the first place.
Organisations that unified their process for dull operational reasons over the last few years are finding they accidentally built the prerequisite for something considerably more interesting.
The part worth sitting with
An agent can only execute a process that has been specified.
Every ambiguity an experienced seller resolves by judgement is a place an agent stops or improvises.
Process discipline used to be an efficiency argument. It is now a capability argument, and the gap between organisations that did the work and those that did not is going to widen.
Eight things worth knowing before you start, learned the expensive way.
Map what happens today so you understand it, then put it aside. If you design forward from the current state you will preserve every workaround in it.
Naming stages takes an hour and feels like progress. Agreeing what has to be true to leave one takes a week and is the actual work. Do it in that order and the names largely write themselves.
Approvals, pricing reviews, legal, credit, configuration. These are where deals actually wait, and they are almost never in the process document.
Who passes what to whom, what has to be complete before it passes, and who owns it afterwards. Undocumented handoffs are the single most common source of stalled deals and of accountability quietly disappearing.
Every field you add is a small tax on every deal. If you cannot name who uses it and what decision it informs, take it out. Sellers can tell the difference between a field that helps them and a field that watches them.
Do not the clean example everybody uses in the workshop. The multi-region, multi-product, complex contracts, partner-involved renewal with a bespoke commercial arrangement. If the process survives that, it will survive the rest.
Local difference is fine when somebody can say what it is for and who approved it. It becomes drift the moment nobody can. Keep a list, review it, and retire the ones that no longer have a reason.
Their input is essential and it belongs at the validation stage. Ask them to break the design rather than to write it, and you get the benefit of their experience without automating their workarounds.
And design it so that doing the job properly is easier than doing it badly. A process built to generate management insight feels like administration and gets treated accordingly. Build it to help somebody do their job, and the data arrives as a byproduct.
Process and platforms · RISE
We design and architect the sales process. Then we help you get it built.
Seventeen years of designing sales processes, quoting and CPQ processes and lead to cash, in businesses turning over fifty million and in businesses turning over four billion. The value chain, the stages and their exit criteria, the activities on both sides, the roles and handoffs, the data at each point, and how the qualification framework sits inside it.
We design it and we govern it. Your systems integrator and platform partners build it, and we stay alongside them so what gets configured is what was designed.
If your systems are working and your numbers still do not reconcile, that is the conversation worth having.
The objections that come up every time this argument is made in a room. Most of them are reasonable.
No, and this is the most common way process design goes wrong. Sellers will describe how they work today, including every workaround they have built to get round the current system, and you will end up automating the thing you were trying to change. Design from what the strategy requires, then ask sellers to break it. Their input is essential and it belongs at the testing stage rather than the authoring stage.
Yes, and you probably should. A renewal does not run like a new business pursuit, and a transactional deal should not be forced through a process built for nine-month enterprise cycles. What should not vary is the spine underneath: the same value chain, the same definitions, the same data captured at the same points. Flavours sit on top of a spine, they do not replace it.
No, 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. AI has also made the design work considerably faster than it was even two years ago, which changes what is realistic in a quarter.
It should not be, and framing it that way is how you lose the field. A process designed to generate management insight feels like administration and gets treated accordingly. Design it so that doing the job properly is easier than doing it badly, and the data arrives as a byproduct. Good reporting is what you get when the process is working, not what the process is for.
AI 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 that it is wrong.
Gartner, “Lack of AI-Ready Data Puts AI Projects at Risk”, February 2025. Survey of 248 data management leaders, Q3 2024. gartner.com
Johnny Grow, CRM Failure Report (2025). Failure rate of 55 percent against stated business objectives.
Gartner and Forrester CRM implementation failure research, ranges as cited.
Forrester research on CRM success factors, and on data quality as a constraint on B2B generative AI adoption.
The published figures vary because every study defines failure differently, so we have quoted ranges rather than picking the most striking number. Everything else here comes from our own experience designing sales processes across businesses of very different sizes. Others will have reached different conclusions, and we would be glad to hear them.
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.
Compose Sales Partners
6th Floor
37 Lombard Street
London
EC3V 9BQ
Compose Sales Partners
20-22 Venture West
Greenham Business Park
Newbury
RG19 6HX
COMPOSE Sales Partners, the COMPOSE Sales Partners logo, COMPOSE Sales Model®, the COMPOSE Sales Model diagram and COMPOSE Sales Kick-Off Model are trademarks used by Compose Sales Partners Limited under licence. PERFORM, RISE and PACE are proprietary frameworks of Compose Sales Partners Limited. All other brands and product names are the trademarks of their respective owners.
