Mapping the post sale customer journey

Most customer journey maps end up as a poster. Five coloured boxes, some emoji faces showing sentiment, a workshop everyone enjoyed, and no automation that fires when a customer actually does something.

The fix is unglamorous. Define every stage by an event you can query, then write the trigger table before you draw anything.

Why the diagram is the last artifact, not the first

A journey map is only operational if each stage boundary corresponds to something your systems can observe. “Customer is getting comfortable with the product” is a feeling. “Second admin invited and three reports created” is a query.

So the build order runs: stage definitions with entry and exit events, then instrumentation audit, then trigger table, then diagram. Teams who draw first invariably discover in week three that half their stages can’t be measured, and they either fudge the definitions or abandon the project.

The bowtie model applied to SaaS

The bowtie extends the funnel symmetrically. Left side: awareness through purchase. Right side: onboarding through renewal and advocacy. The framing matters because for a product at 110 percent net revenue retention, most lifetime revenue arrives after the first signature, and yet most mapping effort goes into the left side.

The post sale stages, each defined by events rather than time:

Notice that no stage is defined by elapsed days. Time-based stages are the single most common reason a map produces badly targeted campaigns, because a customer who took four months to onboard receives adoption content while they’re still stuck on setup. The bowtie funnel covers the model itself in more detail.

The instrumentation each stage needs

Before writing triggers, audit what actually exists. Three layers, and most companies have the first and neither of the others.

Product events. The core value action, first and repeat. Feature-level usage for the three to five features that correlate with retention. Seat invitations sent and accepted. Integration connection and disconnection. Admin login recency.

Account traits. Seat count against contracted seats. Number of distinct weekly active users. Breadth of feature use. Support ticket volume and sentiment. Days since last executive-level login, which is a surprisingly good churn predictor in enterprise accounts.

CRM and billing fields. Contract term and renewal date. Plan tier. Named champion and their last activity. Whether the original champion is still employed, which you can approximate from email bounce and LinkedIn enrichment.

The champion departure signal deserves its own mention. In enterprise SaaS, losing the person who bought is one of the highest-risk events that occurs, and most companies find out at renewal. A bounced email to a named contact should fire a CS task the same day.

The trigger table: the actual deliverable

This is the thing that changes behaviour. Each row links a signal to an action, an owner and a response time.

Signal	Action	Owner	SLA
Setup incomplete after 7 days	Onboarding nudge sequence plus in-app checklist	Lifecycle marketing	Automated, daily
Integration connected	Trigger first value guide, notify CS	Lifecycle marketing	Automated, immediate
No core action in 14 days post-setup	Human outreach from CS, not an email	CS	48 hours
Weekly actives drop 40% month on month	Health flag plus CS call booked	CS	5 business days
Seat usage above 90% of contracted	Expansion play, pricing conversation	Account management	5 business days
Admin email bounces	Champion change task, identify replacement	CS	Same day
Support tickets above 3 in 14 days	Review call offered, flag to product	CS	3 business days
NPS 9 or 10 submitted	Advocacy ask: review, reference or case study	Customer marketing	7 days
Renewal minus 120 days	Value summary report generated and sent	CS with marketing	Automated
Feature X adopted	Cross-sell sequence for adjacent module	Lifecycle marketing	Automated, weekly batch

Ten rows is enough to start and roughly the maximum a team can maintain properly. Companies that build forty triggers end up with a system nobody trusts, because a third of them are broken at any given moment and nobody knows which third.

Worked map one: $12K ACV horizontal product with a self-serve tail

Four stages, product-event driven, almost entirely automated. The buying unit is one to three people, there’s no formal onboarding call below a certain plan tier, and CS capacity is roughly one person per 400 accounts.

The human intervention budget here is tiny, so the map’s job is to identify the 5 percent of accounts worth a call. Everything else runs on lifecycle email and in-app messaging. Lesson 1: Map Your Customer Lifecycle covers building those sequences.

Worked map two: $120K ACV enterprise with a buying committee

Six stages, because the rollout itself is multi-stage and the committee members join at different points.

The key addition is a multi-team rollout stage between adoption and expansion. In enterprise deals the original buying team succeeds, and then the product either spreads to adjacent teams or it doesn’t, and that fork determines renewal far more than the first team’s satisfaction.

Renewal starts at 180 days here, not 120, because enterprise procurement cycles take that long and the value case has to be built before the buyer opens the conversation. The marketing contribution in that window is a value summary report the champion can forward to their CFO, which is a customer marketing asset almost nobody builds.

RACI across marketing, CS and product

The boundary argument between teams is the most common reason a good map stops working. Write it down.

The split that works in practice: marketing owns one-to-many, CS owns one-to-one, and the trigger table is the contract between them. Where a signal could plausibly be either, default to automated first and escalate to human only if the automation gets no response. What is customer lifecycle marketing? covers where marketing’s remit sits in this model.

Where this goes wrong

Three honest failure modes.

Over-instrumentation. A team builds ninety events, forty triggers and a health score with fourteen inputs. Nobody can explain why an account is flagged, so CS stops trusting the flags and works from their own spreadsheet. Start with ten triggers and six events.

Mapping the ideal journey instead of the real one. Workshop maps describe how the team wishes customers behaved. Pull the actual event data for fifty accounts before defining any stage, and you’ll usually find two distinct paths where you assumed one.

No owner for the map itself. The document was built during a quarter when someone cared. Eighteen months later the product has changed twice and nobody has updated it. Assign an owner and a quarterly review date in the same meeting where you approve the map.

The cost is real too: instrumenting this properly takes an engineer two to four weeks of scattered effort plus a marketer’s full attention for a month. That’s a genuine tradeoff for a company under $2M ARR, where a manual spreadsheet reviewed weekly may be the right answer until volume makes it impossible.

What to build first

Build the trigger table. Ten rows. Confirm every signal exists in your data before writing the row, and delete any row where it doesn’t.

Then instrument the onboarding and first value stages properly before touching anything downstream, because that’s where the churn concentrates. The retention content system covers what content fills each trigger, and Customer marketing campaign ideas gives you specific plays to slot into the table.

If you’d rather work through it in a structured format, Lesson 1: map the post sale journey walks the same process with worksheets. The Customer marketing plan template holds the finished map, and the Cost of churn calculator is the number to bring when you need budget for any of it. The SaaS customer marketing hub covers the wider function.