B2B SaaS Customer Journey Map Template: Post-Sale Stages (2026)

Every customer journey map tells you the stages. Almost none tells you how to know which stage a customer is actually in today.

I counted. Across 23,513 words on the nine pages ranking for this term in September 2026, the word "template" appears 68 times. The language of proof, words like evidence, entry criteria, exit criteria and definition of done, appears once.

That single gap explains why most journey maps end up on a wall instead of in an operating rhythm. A map that lists stages is a drawing. A map that defines what puts a named account into a stage is a query you can run against your customer base on a Monday morning.

This guide builds the second kind, and it starts where the contract is signed.

What is a customer journey map?

A customer journey map is the sequence of stages a customer moves through with your product, what they are trying to accomplish at each stage, where you meet them, and the observable signals that tell you which stage a given account is in.

Three things it is often confused with, and the differences matter operationally.

A buyer journey describes how someone decides to purchase. It ends at signature. It belongs to marketing and sales, and it is the part most published journey maps spend their effort on.

A funnel is your view of your own process. A journey map is the customer's view of theirs. The distinction sounds academic until you notice that funnels have no stage for "the champion left" or "the workflow broke in week nine," both of which decide renewals.

A lifecycle model is the set of motions your company runs against the customer. That is a different artifact with a different job, and if you want the motion model rather than the map, the LAER model covers it properly: the four motions, their stage gates, and who runs each one.

The journey map answers a narrower question. Where is this account right now, and what does it need next?

Why this map starts after the signature

Most B2B SaaS journey maps published today open at awareness and run through consideration, evaluation and decision before reaching onboarding. That is a reasonable structure for a marketing team.

It is close to useless for the person who inherits the account on day one.

The post-sale journey is longer, it carries the revenue that already exists, and it is the half where the customer's experience is continuous rather than episodic. A buyer interacts with you for weeks. A customer interacts with you for years, and every renewal is a fresh decision to keep doing it.

So this map begins at closed-won. If you need the pre-sale half, build it separately and hand it to the team that owns it. Merging both into one artifact produces a poster that serves nobody, which is the most common form this mistake takes.

The six post-sale stages

These are the stages that survive contact with a real B2B SaaS book. Six is a starting model, not a standard. Your product may compress two of them, and adding a seventh should have to justify itself.

1. Handover. The account moves from the people who sold it to the people who keep it. The customer is re-explaining things they already told someone at your company. The mechanics of this transition are covered in implementation to CSM handoff.

2. Onboarding. Configuration, integration, training and the first real workflow. The customer is spending effort now for a benefit they have been promised but not yet seen.

3. First value. The customer uses the thing that solves the problem they bought for, and it works. This is the first moment the purchase stops being a risk.

4. Adoption. Use becomes routine and spreads beyond the original champion. The product stops being a project and becomes infrastructure.

5. Renewal. The customer decides whether the value they received justifies the next term. This decision is usually made well before the renewal conversation happens.

6. Expansion and advocacy. A second use case, a second team, or a public willingness to recommend you. These are separate outcomes that share one precondition, which is that the first use case genuinely worked.

Onboarding is one row on this map. It is also the stage with the most depth behind it, and rebuilding that depth here would make this page worse, so the seven-stage version lives in customer onboarding best practices.

The column every journey map is missing

Here is the part that turns a diagram into an operating tool.

For each stage, write down the observable condition that places an account in it. Not a feeling. Not a date in a project plan. Something you could look up without asking the customer how they are doing.

Handover is complete when the person now responsible for the account has the signed scope and every commitment sales made, in writing, and the customer has not been asked to repeat information they already gave.

Onboarding is complete when the workflow runs without your involvement. Training delivered is not evidence. A completed implementation checklist is not evidence. The customer doing the thing unaided is.

First value has occurred when the customer independently completes the outcome that was agreed at kickoff, in production, on their own data. Not a demo you drove. Not a training session. The thing they bought, working, done by them. This is also why the definition has to be written down at kickoff: if nobody agreed what first value meant, nobody can declare it later without arguing.

Adoption has occurred when that outcome repeats at the expected cadence, across more than one person, through a period in which nobody from your team intervened. First value is the first time. Adoption is the habit, which is why repetition belongs here and not one stage earlier.

An account is renewal ready when the person who controls the budget has described the value in their own words, before the renewal window opens. Other behaviours worth watching are set out in leading indicators of renewal. If you are discovering value during the renewal conversation, you are not renewing, you are re-selling.

An account is expansion ready when a second use case is showing behaviour rather than interest. Someone is working around a limit, or using a feature that only matters if a second job is being done.

The rule underneath all six: evidence must be observable without asking the customer how they feel. Sentiment arrives late, comes from whoever chose to answer, and rewards politeness. Behaviour gives you an independent signal instead, though it still has to be validated against outcomes rather than trusted on sight.

This is what makes the map queryable. Once each stage has a condition, "which stage is this account in" stops being a judgment call in a meeting and becomes something you can answer for every account at once.

Milestones: the dates you put on the record

Stages are states. Milestones are dated events, and they are what you actually track on an account record.

The lifecycle milestones worth recording:

• Go-live date. The first day the workflow ran in production.
• First value date. The date the evidence condition above was met. Setting a realistic target for it is covered in time to value targets for CSMs.
• First unprompted expansion signal. The first behaviour indicating a second use case.
• First champion change. The date your main contact changed, for any reason. What to do when it happens is a playbook of its own, covered in the champion left the company.
• First renewal. Not the renewal date in the contract. The date the customer confirmed intent.
• First reference. The date they agreed to be named publicly.

Two of those are unusual and both earn their place. Champion departure is often one of the highest-separation renewal signals in B2B SaaS, and almost nobody dates it, which means almost nobody can measure its lead time on their own renewals. Date it and you can. First value date earns its place because it is anchored to observed behaviour rather than to a project milestone, which is what makes time to value honest.

Onboarding milestones, the kickoff, the training session, the configuration sign-off, belong inside the onboarding stage and not on this map. Putting them here is how a lifecycle map quietly turns into an implementation plan.

Metrics for each stage

Keep this layer thin. A journey map that carries every metric your team reports becomes a dashboard specification, and dashboards are not maps.

Four measures actually belong here.

Stage duration. How long accounts spend in each stage. Report the distribution, not the average. The average hides the accounts that are stuck, and the stuck accounts are the entire point of looking.

Stalled count by stage. How many accounts have been in one stage longer than your stated threshold. This is the number that should drive a weekly conversation.

Time to value. Measured from contract signature to the first value evidence condition. Starting the clock later, at kickoff or at go-live, removes your own scheduling and delivery delay from the report without removing it from the customer's experience, and the customer has been counting since they paid. If you also want the delivery-only view, publish it separately and label it post-go-live time to first value rather than letting it replace the honest number. Where the time to value clock starts covers this properly.

Stage conversion. The proportion of accounts that reach the next stage at all. This is the measure that exposes accounts renewing on inertia, the ones that never reached adoption and are paying anyway. You cannot see them in a renewal report, because from there they look identical to your healthiest customers.

Account health, churn rate, NRR and the rest sit alongside the journey rather than inside it. They are covered properly in the customer health score guide and across the metrics library.

Who owns each stage, and what actually breaks

Assigning a department per stage is the easy part, and most published maps do it in one line. Sales owns pre-sale, customer success owns adoption and retention, support owns issues.

That line is true and it prevents almost nothing, because stages are not where accounts are lost. Handoffs are.

Three transitions deserve an explicit gate, because each one has a characteristic way of failing.

Sales to customer success. The failure is not a missing document, and a sales to customer success handoff checklist will not catch it on its own. It is an undisclosed commitment. Something was promised in the room that never reached the people who have to deliver it, and the customer finds out in week six that you did not know.

Onboarding to steady state. The failure is the disappearance. Intensity drops to zero the week after go-live, which is precisely when the customer is most likely to hit their first real obstacle unaided.

Customer success to renewal. The failure is timing. The value conversation starts when the renewal date appears on a forecast, which is months after the customer already formed their view.

For each transition, write down one thing: the condition that has to be true before the handoff happens, and who is allowed to declare it. A handoff with no condition is a calendar event, and calendar events do not protect revenue.

If you want the ownership question at the level of company motions rather than map transitions, that is the LAER model's territory and it is worth reading alongside this.

A worked example

A mid-market account signs in January for a reporting use case, with a workflow that has to connect to their CRM.

Handover, January. The commitments made in the sale are written down, including an integration promise that was made verbally. The condition is met the day the delivery team confirms they can honour it. If they cannot, that is the cheapest moment in the entire relationship to say so.

Onboarding, January to February. Integration built, two teams trained. Not complete when training ends. Complete in late February when the reporting workflow runs on their own data without a call.

First value, March. Their operations lead produces the report on their own data, unaided, and it answers the question they bought the product to answer. That is the first value date. Measured from the January signature, time to value is roughly eight weeks, which is now anchored to something the customer did rather than to a project milestone.

Adoption, March to August. Three more people start pulling reports. Usage continues through a quiet stretch in which nobody from your side intervenes. Adoption evidence is met in May.

Champion change, September. Their operations lead leaves. This gets dated on the record immediately, because the account's entire relationship history sits with someone who is now gone, and the replacement has no reason to value a tool they did not choose.

Renewal, October. The renewal is in January. The value conversation happens in October, with the budget holder, because the evidence condition requires them to describe the value in their own words before the window opens. In this account the new operations lead cannot yet do that, which is exactly the finding you want in October and cannot act on in January.

Notice what the map did. It did not predict the churn risk. It located the account precisely enough that the risk became visible while there was still a quarter left to do something.

Templates: what to use and what most formats cannot do

Template intent dominates this topic, and the honest answer is not the one most template pages give.

The format matters far less than whether the map contains an evidence column. A slide deck, a Figma board and a Canva graphic all produce a map you can present and cannot query. They are communication artifacts. They are genuinely useful for getting a room to agree on the stages, and useless afterwards.

If the map is going to be used rather than shown, it needs to be a table, which means a spreadsheet or whatever your customer platform uses for account fields.

The columns:

• Stage
• What the customer is trying to do
• Entry evidence, the observable condition that places an account here
• Owner
• Expected duration
• Stalled threshold, the point at which this account needs attention
• Primary metric

Seven columns, six rows. That is the whole artifact. A map that needs more than one screen has usually absorbed a process document.

One rule when you fill in the blank page. The evidence has to be something you could look up without asking the customer how they feel. If what you write names a meeting, a date in your project plan or a task your team performed, rewrite it as something the customer did.

Replace every one of them with a figure measured from your own book. They are here to show the shape of a working row.

Two columns in that table do the work. Entry evidence decides which accounts are in the stage. Stalled at decides which of them you talk about this week. The rest is context.

Build the presentation version afterwards if you need one, from the table. Doing it in the other order produces a beautiful map that nobody can act on, which is the normal outcome of a journey mapping workshop.

Do you need journey mapping software?

Usually not.

Dedicated journey mapping tools are built for large organisations mapping many journeys across many products, with research artifacts attached to each touchpoint. If that is your situation they are worth the money.

For a B2B SaaS team mapping one post-sale journey, the map is six rows. The work is not in drawing it. The work is in defining the evidence conditions and then being able to see which accounts meet them, and that second half does not happen in a mapping tool. It happens wherever your account data lives.

The practical test: if your journey map lives somewhere that cannot tell you which accounts are currently in stage four, you have bought a drawing tool.

How to tell your map has gone stale

This is where journey maps quietly die. They are built in a workshop, agreed by everyone, and never checked again.

Four checks, worth running quarterly. Each takes minutes.

Sample five accounts and place them. If two people place the same account in different stages, your evidence conditions are not specific enough yet.

Check the stalled counts. If a stage has no stalled accounts at all, the threshold is too generous and the stage is not telling you anything.

Check stage duration against what you told a customer. If onboarding takes eleven weeks in your data and your sales team says six, the map is accurate and the promise is not. That is a finding worth escalating.

Check whether any stage has stopped being used. A stage nobody places accounts in has either been absorbed into its neighbour or never existed. Delete it.

A map that survives these four checks is describing your business. A map that fails them is describing the business you had when you drew it.

Where these maps break

It includes the pre-sale half. The artifact serves two audiences and neither uses it.

Stages are named after your internal process. If a stage is called "implementation" rather than describing what the customer is doing, the map is a project plan with new labels.

Evidence is a date instead of a behaviour. "Onboarding complete" as a checkbox someone ticks means the map records your activity rather than the customer's progress.

Every account is forced through every stage. Some customers buy one use case and use it well for years. A map that treats them as stalled at expansion generates work that should not exist.

The map is never connected to account data. This is the big one, and it is the reason the evidence column matters more than the drawing. A map you cannot apply to a named account is a description of an average customer, and you do not have any average customers.

Where GainTrace fits

The hard part of this is not the drawing. It is answering "which accounts are in stage four and which of them have been there too long" without building a reporting project to find out.

GainTrace scores accounts on behaviour rather than sentiment, which is the same input the evidence conditions above rely on, and it is configured by a CSM or a CS leader rather than a dedicated administrator. If you want to see what that requires from vendors generally, which platforms need a dedicated admin covers what each one publishes about its own model.

The map is still yours to define. No tool should decide what counts as first value in your product.