The B2B buyer journey is usually drawn as a funnel and experienced as something much messier: several people, each at a different stage, revisiting decisions as new information arrives and new stakeholders appear.
The stages below are still useful, as long as they are treated as things that happen rather than as a sequence everyone follows in order.
Stage 1: Problem identification
Something is not working. Often nobody has named it yet, and the organisation is absorbing the cost without noticing.
Who is involved: usually one person who feels the pain directly.
What they need: language for the problem, and evidence that others have it too. Content that helps someone recognise and articulate a situation they are living with.
What stalls it: the problem not being painful enough to prioritise. Many deals die here and never appear in any pipeline.
Stage 2: Solution exploration
They are researching what can be done. Not yet which vendor — which approach.
Who is involved: the original person, perhaps a colleague.
What they need: explanations of the approaches available, with honest trade-offs. Comparisons of methods rather than products.
Why it matters: this is where the evaluation criteria are formed. A vendor who shapes the criteria at this stage has a substantial advantage later, and it is the stage most content programmes underserve.
Stage 3: Requirements building
They are defining what a solution must do. This is where the buying group expands and the process becomes organisational.
Who is involved: the originator, their manager, likely IT or security, possibly finance.
What they need: specifics. Capability detail, integration information, security documentation, implementation requirements.
What stalls it: a requirement nobody anticipated — a compliance obligation, an integration with a system you had not heard about, a procurement policy.
Stage 4: Vendor selection
Comparing specific options against the criteria formed earlier.
Who is involved: the full buying group, which in mid-market and enterprise purchases commonly runs to six people or more.
What they need: comparison material, evidence from similar organisations, pricing, and answers to each stakeholder’s specific concern. Each person has a different question and they are not asking yours.
What stalls it: an unaddressed objection from someone you never spoke to. This is why multi-threading matters.
Stage 5: Validation and approval
Building the internal case. Budget approval, legal review, security assessment, procurement.
Who is involved: your champion, plus people you may never meet.
What they need: material that works without you in the room. A one-page business case, a return calculation they can adjust, security documentation, standard contract terms.
What stalls it: almost everything. This is where deals slip most, and the cause is usually that nobody mapped the approval process early enough. See pipeline stages for how to make this visible.
Stage 6: Purchase and implementation
The contract is signed and the real test begins. A purchase that does not get adopted becomes a cancellation at renewal.
What they need: a clear implementation plan, defined success criteria and early evidence that it is working. See customer onboarding.
Why it is not linear
Three things break the sequence routinely.
People join late. A new stakeholder at stage five brings stage two questions, and the group loops back.
Stages run in parallel. Security review often starts before vendor selection is complete.
Priorities change. A reorganisation, a budget freeze or a more urgent problem can send a late-stage deal back to nothing.
The practical response is to assume the loop rather than to fight it: make the earlier-stage material easy to find at any point, and keep the champion supplied with things they can forward.
The buying group
Treating the journey as one person’s path is the most common error. Research on B2B purchasing consistently finds multiple people involved, each with a different concern.
A rough map: the originator feels the problem, the economic buyer approves the money, the technical evaluator assesses whether it works, the security reviewer assesses risk, the end users judge whether it makes their work better, and a procurement function negotiates terms.
Any one of them can stop the deal. Most sellers speak to two.
What this means practically
Three implications worth acting on.
Multi-thread deliberately. One relationship is a single point of failure. Make it a stage requirement to have engaged at least three people.
Arm the champion. They do most of the selling internally, in rooms you are not in. Give them material designed to be forwarded, not material designed to be presented by you.
Publish what procurement needs. Security documentation, standard terms and compliance information, publicly available. This removes weeks from the stage where most deals stall, and almost nobody does it.
Mapping your own, with real data
Generic journey maps are a starting point. The useful version is built from your own closed deals.
Take ten recent wins and ten recent losses. For each, reconstruct what happened: when the first contact occurred, who was involved and when each person appeared, what material they consumed, how long each phase took, and what the decisive moment was.
Interviews beat CRM records here, because the CRM holds what the seller did and the buyer remembers what mattered. Ask the champion what nearly stopped it, and ask the losses what the alternative offered that you did not.
Ten of each is usually enough to see the pattern, and the pattern is almost always different from the assumed one in at least one important respect — a stakeholder nobody was tracking, a stage that takes twice as long as believed, or a piece of information everyone asks for that you do not publish.
Where the time actually goes
Teams consistently misjudge which stage consumes the cycle.
The assumption is that evaluation and negotiation dominate. In practice, the long stretches are usually before first contact, while the buyer researches privately, and after verbal agreement, while the purchase works through security, legal and procurement.
Both are addressable and neither is addressed by better selling. The first is a content and discoverability problem; the second is a documentation and process-mapping problem. Shortening a cycle usually means working on those two rather than on the parts where the sales team is most active.
Shortening the cycle
Most attempts to shorten a sales cycle focus on the parts the seller controls, which are not the parts that take the time.
Three changes have a disproportionate effect. Publish the security and compliance documentation so the review starts before the deal reaches that stage. Map the approval process explicitly during discovery rather than discovering it at the end. And give the champion a forwardable business case early, so the internal selling runs in parallel with the evaluation rather than after it.
None of these involve pushing harder, and all of them remove weeks from the stages where deals actually sit.
Frequently asked questions
How long is a typical B2B buyer journey?
It varies enormously with deal size — weeks for small purchases, six to eighteen months for enterprise. A large part of it happens before any vendor is contacted.
How much research happens before contacting a vendor?
A substantial majority of the journey, by most estimates. This is why content covering the early stages matters even though it is the hardest to attribute to revenue.
Should the journey map be per persona?
The stages are shared; what each role needs at each stage differs. One map with a column per role is more useful than separate maps.
How do I know which stage a deal is in?
By what the buyer has done, not by what you have done. See pipeline stages for exit criteria based on buyer actions.
