# Mapping the post sale customer journey

> Map the post sale journey with entry and exit criteria, event instrumentation and a trigger table, plus worked maps for 12K and 120K ACV SaaS companies.

Source: https://saas-marketing.net/guides/post-sale-customer-journey-map/
Topic: SaaS Customer Marketing
Type: guide
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/post-sale-customer-journey-map/

## Short answer

A post sale customer journey map defines the stages a customer moves through after purchase, with each stage bounded by a measurable entry event and exit event rather than by elapsed time. The useful output is not a diagram but a trigger table linking each signal to a campaign, an owner and a response time. If a stage has no measurable entry event in the product or CRM, it is not a stage.

## Key takeaways

- Define every post sale stage by entry and exit events, never by days elapsed, or the map cannot be instrumented.
- Ship the trigger table before the diagram: the table is the system, the diagram is documentation of it.
- The bowtie model treats post sale as four stages of equal weight to the pre-sale funnel, not as a single retention box.
- A $12K ACV horizontal product and a $120K enterprise product need different stage counts, not the same map with different labels.
- Up to 75 percent of churn originates in the first week, which is why the activation stage needs the densest instrumentation.

---

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.

Take any stage on your current map and ask: what query returns the list of accounts in this stage right now? If the answer involves a CS manager's opinion or a manually maintained spreadsheet field, it is not a stage. It is a label on a feeling, and no campaign can be triggered from it.

## 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:

| Stage | Entry event | Exit event | Primary owner |
|---|---|---|---|
| Onboarding | Contract signed or first paid invoice | Core setup complete (integration connected, data imported) | CS or onboarding |
| First value | Setup complete | First instance of the core value action | Product plus lifecycle marketing |
| Adoption | First value action | Value action repeated weekly by 2+ users for 3 weeks | Lifecycle marketing |
| Expansion | Adoption threshold met | Seat or tier increase, or new team onboarded | CS plus account management |
| Renewal | 120 days before term end | Renewal signed or churn | CS with marketing support |
| Advocacy | Renewal signed plus NPS above threshold | Reference call, review, or case study delivered | Customer marketing |

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](/glossary/bowtie-funnel/) covers the model itself in more detail.

**up to 75%** Share of SaaS churn that traces back to the first week of use

## 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.

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.

Product renames an event, the automation silently stops firing, and nobody notices for eleven weeks. Every trigger needs a volume alert: if a trigger that normally fires forty times a week fires zero times, someone should get a Slack message. Build that monitoring on day one or the whole system quietly rots.

## 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 four stage map**

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](/courses/saas-lifecycle-email/01-map-your-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.

| Stage | Entry event | Exit event | Notable trigger |
|---|---|---|---|
| Kickoff | Contract countersigned | Implementation plan signed off | No plan in 14 days, escalate to exec sponsor |
| Technical onboarding | Plan signed off | SSO live, data pipeline running, 3 admins trained | IT contact silent 10 days, escalate |
| Pilot team value | Technical setup done | Pilot team hits agreed success metric | Metric missed at 60 days, joint review |
| Multi-team rollout | Pilot success confirmed | Second business unit active for 30 days | No second unit at day 120, renewal risk flag |
| Expansion | Second unit active | Seat or module increase signed | Usage above 85% of seats, AM play |
| Renewal | 180 days before term end | Signed or churned | Champion change at any point, same day task |

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.

| Activity | Marketing | CS | Product |
|---|---|---|---|
| Stage definitions | Consulted | Accountable | Consulted |
| Event instrumentation | Consulted | Informed | Responsible |
| Automated campaigns | Responsible | Consulted | Informed |
| Human outreach on flags | Informed | Responsible | Informed |
| Trigger table maintenance | Responsible | Consulted | Consulted |
| Health scoring model | Consulted | Accountable | Responsible |
| Advocacy and references | Responsible | Consulted | Informed |

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?](/glossary/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](/playbooks/retention-content-system/) covers what content fills each trigger, and [Customer marketing campaign ideas](/guides/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](/courses/saas-customer-marketing-sprint/01-map-the-post-sale-journey/) walks the same process with worksheets. The [Customer marketing plan template](/templates/customer-marketing-plan/) holds the finished map, and the [Cost of churn calculator](/calculators/cost-of-churn/) is the number to bring when you need budget for any of it. The [SaaS customer marketing](/saas-customer-marketing/) hub covers the wider function.

## Frequently asked questions

### What is a post sale customer journey map?

It is a definition of the stages a customer passes through after signing, where each stage has a measurable entry event, a measurable exit event, an owner, and a set of triggered actions. Unlike a pre-sale funnel it is not linear, because customers can re-enter onboarding when a new team adopts the product or a champion leaves.

### What are the post sale stages in the bowtie funnel?

The right side of the bowtie typically runs onboarding, activation or first value, adoption, expansion, and renewal or advocacy. Each mirrors a pre-sale stage in weight and instrumentation. The point of the bowtie framing is that revenue after the first signature usually exceeds revenue from it, so it deserves equal mapping effort.

### How do you instrument a customer journey map?

Define one entry event and one exit event per stage, then confirm each exists in your product analytics or CRM before you finalise the map. Add account-level traits for seat count, feature breadth and support volume. If an event does not exist, either build it or redefine the stage around something you can actually see.

### What is a trigger table?

A trigger table maps each observable signal to a campaign or action, a named owner, and a service level for how fast the response must happen. It is the operational half of a journey map. One row might read: admin seat inactive 14 days, send re-engagement sequence, owner lifecycle marketing, SLA 48 hours.

### Should marketing or customer success own the post sale journey?

Both, split by scale. Marketing owns anything automated and one-to-many: lifecycle email, in-app messaging, feature adoption campaigns, customer content. CS owns anything requiring a human judgement call on a named account. The trigger table is where the boundary gets written down so neither team assumes the other handled it.

### How many stages should a post sale journey have?

Four to six for most companies. A $12K ACV self-serve product often needs four, because the buying unit is small and the signals are product events. A $120K enterprise deal usually needs six, adding a separate stage for multi-team rollout and one for the renewal cycle that starts months before the date.

### How often should a journey map be reviewed?

Quarterly for the trigger table, annually for the stage definitions. Triggers go stale fast because product changes rename events and break automations silently. Stage definitions should be stable, and if they change every quarter it usually means they were defined by opinion rather than by observable events.