*Last updated: July 2026*

## Key takeaways

- A customer journey is a sequence of automated messages triggered by user behavior, not by a fixed calendar.
- Event-driven journeys respond to what a user does in real time; campaigns send the same sequence to everyone on a schedule.
- Journey management raises trial-to-paid conversion, catches churn early, and prompts expansion when accounts hit limits, without an engineering ticket per campaign.
- Every journey is built from nodes: triggers, branches, delays, data fetches, throttles, AI steps, and multi-channel sends.

## What is a customer journey?

A customer journey is a series of automated messages triggered by what a user does in your product: a welcome when they sign up, a follow-up when they activate a key feature, a check-in when they go quiet, an escalation to account management when expansion signals appear. A [journey platform](https://www.courier.com/platform/journeys-customer-engagement-platform) runs all of it automatically, across every channel, without custom engineering per flow.

![Customer journey workflow: a trigger fanning out through branch, delay, and send nodes across email, SMS, push, and in-app](//images.ctfassets.net/z7iqk1q8njt4/5HbZnyJj0bmAeiSSyGBWCO/655cc5460478afec0ce787f50f4ad7d2/Frame_163979__3_.png?w=600)

Most journey builders use a visual canvas: a graph where every step is visible at once, from the trigger that starts a run to the nodes that branch, wait, and send. It keeps a multi-step lifecycle readable for the whole team, and edits to steps, copy, and timing ship without a deploy.

## Event-driven journeys vs. campaigns vs. marketing automation

Each tool has a different relationship with timing and behavior.

A fixed campaign sends the same sequence to everyone on schedule: day 3 intro, day 7 feature highlight, day 14 expiration warning. The user who activated on day 2 still gets the day-3 "here's how to use it" note, and the power user still gets the churn-prevention sequence. The schedule can't see what the user did, so the message lands at the wrong moment.

An event-driven journey adapts. Activation fires its branch and the generic onboarding stops. When an account hits a limit, the upgrade prompt arrives right then, not three weeks later on a calendar.

| | Customer journey platform | Marketing automation | Email campaigns |
|---|---|---|---|
| **Triggers** | Product events, behavioral signals | Form submissions, time-based | List segments, manual |
| **Response time** | Sub-second event processing | Minutes to hours | Batch, often daily |
| **Best for** | Lifecycle messaging, activation, retention | Lead nurture, campaign management | Announcements, newsletters |
| **Non-technical access** | Visual builder for PMs and lifecycle teams | Campaign designers | Email composers |
| **Channels** | Email, in-app, SMS, push, Slack, Teams | Primarily email | Email only |

The strongest stacks use both: a journey platform for behavior-driven messaging, campaign tools for broad announcements.

## Why customer journey management matters

The point is to let your product respond on the user's timeline, not yours. Someone activates a feature at 11pm and the follow-up arrives when it's relevant, not when a nightly batch runs. Someone stalls mid-onboarding, and the journey notices and follows up instead of marking them complete.

The outcomes are concrete: higher trial-to-paid conversion from well-timed activation guidance, less churn from catching disengagement early, and more expansion from prompting upgrades when accounts approach a limit. Iteration also leaves the engineering queue, so lifecycle teams ship experiments faster. [Companies that get personalization right generate 40% more revenue](https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-value-of-getting-personalization-right-or-wrong-is-multiplying) than those that don't, and in B2B software that gap shows up directly in conversion and retention. Teams like LaunchDarkly, Twilio, and DroneDeploy run this lifecycle messaging on Courier; Chapter 3 covers how.

## Where journeys fit in the user lifecycle

The same patterns repeat across the lifecycle, whether you build developer tools, project management software, or a healthcare platform:

- **Onboarding and activation** guide new users to first value, adapting to what each user has and hasn't done so power users skip beginner content.
- **Retention** watches for signals that precede churn (usage drops, a two-week absence, a key collaborator leaving) and escalates from a useful tip to a direct check-in to a CSM alert.
- **Expansion** works from the opposite signal: usage near a limit, repeated access of a locked feature, teammates added to an account.

Chapter 4 turns each of these into a production-ready blueprint, including industry variants for SaaS, healthcare, HR tech, and marketplaces.

## The building blocks of a journey

A journey is a graph of nodes, and each node does one thing:

- **Trigger** starts a run from a product event (via [Segment](https://www.courier.com/docs/external-integrations/cdp/segment)) or a direct API call.
- **Branch** evaluates conditions (account tier, activation state, last login) and routes each user down the path that fits.
- **Delay** waits for a duration or until a specific time in the user's timezone.
- **Throttle** caps how often a journey can reach a user, preventing over-messaging.
- **Batch and digest** roll a burst of events into a single summary message instead of firing a separate send for each.
- **Fetch data** pulls live context from your APIs mid-run so decisions use current state, not stale trigger data.
- **AI** runs a model like GPT-5.5, Claude Opus 4.8, or Claude Fable 5 inside the run to score users, generate copy, or classify profiles.
- **Send** delivers the message across email, in-app, SMS, push, Slack, or Teams, with [preferences](https://www.courier.com/platform/preferences-management) applied at send time.
- **Experiment** turns a single send into a test of up to 10 weighted template variants and reports results per variant, so you can compare versions and promote one.
- **Cancel** stops a run's pending steps when the user takes the action you were driving, so you stop messaging someone who already converted.

Triggering a journey is a single API call or a Segment event. Everything downstream (which messages go out, in what order, on which channels) lives in the journey, not your application code, so you reshape the flow without touching the trigger. Chapter 2 builds a full journey around that, from trigger to send.

## Glossary

| Term | What it means |
|---|---|
| Customer journey | A sequence of automated messages and actions triggered by user behavior across channels. |
| Trigger | The entry point that starts a journey run, from a Segment event or an API call. |
| Node | A single step in a journey (trigger, branch, delay, throttle, fetch, AI, send, or exit). |
| Branch | A node that evaluates conditions and routes a user down one of several paths. |
| Throttle | A control that limits how often a journey can send to a user in a time window. |
| Digest | A single summary message that rolls up many events collected over a time window, instead of one message per event. |
| Experiment | A single send split across 2 to 10 weighted template variants, with results per variant; you promote one manually once you've seen enough. |
| Run | One user's execution of a journey, with its own state and inspectable history. |
| CDP | A customer data platform (like Segment) that collects behavioral events and routes them to tools such as a journey builder. |
| Omnichannel | Coordinated delivery across several channels (email, in-app, SMS, push, Slack, Teams) from one journey; also called multi-channel messaging. |
| Preference management | User-controlled settings for which messages they receive and on which channels. |

## Frequently asked questions

### What is a customer journey in B2B software?

A customer journey is a sequence of automated messages triggered by user behavior rather than a fixed schedule. When a user signs up, activates a feature, hits a limit, or goes inactive, the journey responds with the right messages across the relevant channels, and stops when the user completes the intended action.

### When should I use a customer journey instead of a marketing campaign?

Use a journey when the right message depends on what a specific user actually did. Campaigns are the better fit for broad, time-based sends that go to everyone at once, like a newsletter or a launch announcement. Journeys are the better fit for behavior-driven lifecycle messaging: onboarding that adapts to activation, retention that reacts to a usage drop, expansion that fires when an account nears a limit.

### How do customer data platforms like Segment connect to journey tools?

A customer data platform collects behavioral events from your product and routes them to downstream tools. When you configure [Courier as a destination in Segment](https://www.courier.com/docs/external-integrations/cdp/segment), your application calls `analytics.track("feature_activated", {...})`, Segment forwards the event, and the matching journey starts immediately, with no custom webhook handlers and no batch-sync latency.

### Do I need engineering to build and change customer journeys?

You need engineering once, to send events and trigger journeys; after that, product and lifecycle teams edit the flow on the visual canvas without a deploy. The trigger is an API call or a Segment event, and everything downstream (branches, timing, copy, channels) lives in the journey builder, so changing an onboarding sequence doesn't require a pull request.

Customer journeys trigger messages from user behavior, not a schedule. Learn how they differ from campaigns, why they matter, and the nodes that build them.

What Is a Customer Journey? B2B Guide & Examples

Customer Journey Management Explained

*Last updated: July 2026*

## Key takeaways

- A journey starts one of two ways: a direct API call or a Segment event. Everything after the trigger lives on the canvas, not in your application code.
- You build a journey by connecting nodes (send, branch, delay, fetch, throttle, AI, exit), each configured in a side panel.
- Templates are channel-specific and built inside send nodes, with Handlebars for personalization.
- Test mode and run inspection let you step through a journey against sample or real data before and after it goes live.

## The visual canvas

Journey design happens on a visual canvas. You drag nodes from the palette onto the graph, connect them, and configure each one in a side panel. Execution runs from the trigger downward: a node runs, then hands off to the next. Because the whole flow (branches, delays, copy, channels) lives on the canvas, product and lifecycle teams change it without a deploy, and engineers keep the trigger as the only integration point.

![Courier Journeys node palette: trigger, delay, throttle, fetch, branch, AI, and channel sends](//images.ctfassets.net/z7iqk1q8njt4/4Jsnf4UoSwSi9TUZyG9VjS/59c78f043651ff29591408ba0e22dc22/journey_nodes.png?w=600)

## Triggers: API and Segment

A journey starts one of two ways, and most products use both.

**API triggers** invoke a journey directly from your backend, for flows tied to your own application logic. Trigger it with the Courier SDK:

```javascript
import { CourierClient } from "@trycourier/courier";

const courier = new CourierClient({ authorizationToken: process.env.COURIER_API_KEY });

const { runId } = await courier.journeys.invoke("trial-onboarding", {
  user_id: "user_123",
  data: { plan: "enterprise", trial_days: 14 },
});
```

The call returns a `runId` and a `202`. Courier validates `data` against the trigger's schema and walks the graph asynchronously. SDKs are available for Node.js, Python, Go, Ruby, Java, PHP, and .NET; see the [SDK overview](https://www.courier.com/docs/sdk-libraries/sdks-overview).

**Segment triggers** start a journey when a matching [Segment](https://www.courier.com/docs/external-integrations/cdp/segment) event arrives, so you instrument your product once and route behavioral events to journeys without writing new backend calls. Use API triggers for transactional flows, Segment triggers for behavioral lifecycle journeys.

### Setting up Segment

Add Courier as a Segment destination:

1. In Segment, open the Destinations catalog and add Courier.
2. Pick the source to send from (your production JavaScript or server-side source).
3. Paste your Courier API key.
4. Enable the destination.

Your product's existing calls then flow to Courier:

```javascript
analytics.track("trial_started", {
  plan: "enterprise",
  trial_days: 14,
});
```

The event name (`trial_started`) becomes a trigger you can select, and the properties become `data` your journey branches on and personalizes with. `identify` calls keep profile traits current; `group` calls associate users with organizations for account-based journeys. RudderStack works the same way through its Courier destination.

## Send nodes and templates

A send node delivers one message on one channel. When you add it, you pick the channel (email, SMS, push, in-app, Slack, Teams) and build the template right there. Each channel gets the controls it needs: email has subject lines and HTML, SMS counts characters, Slack uses Block Kit. Omnichannel delivery works by combining send nodes with a branch that falls back to whichever channel a user has: Slack if a `profile.slack_token` exists, else push, else email.

### Personalization with Handlebars

Templates use Handlebars to pull from trigger data and the user profile, so `Hi {{profile.first_name}}, your {{data.plan}} trial has {{data.trial_days}} days left` renders per recipient. Conditionals let one template serve many segments:

```handlebars
{{#if (condition (var "profile.plan") "==" "enterprise")}}
  Your enterprise features are active.
{{else}}
  Upgrade to unlock enterprise features.
{{/if}}
```

## Branching and conditional logic

A branch node evaluates conditions and routes each user down the first matching path, with a default path for everyone else. Conditions read from three sources: trigger data (`data.setup_completed`), profile attributes (`profile.company_size`), and results from earlier sends (`refs.welcome_email.status`).

| Condition type | Operators |
|---|---|
| Equality | is equal, is not equal |
| Text | contains, does not contain, starts with, ends with |
| Number | greater than, greater than or equal, less than, less than or equal |
| Presence | exists, does not exist |

Group conditions with AND or OR, and nest groups for more complex logic. A common pattern: after a welcome email and a three-day delay, branch on setup completion. Setup done routes to advanced tips; not done routes to setup help. Step references keep you from re-nudging someone who already engaged, so a branch on `refs.welcome_email.status` equal to `CLICKED` skips the reminder.

## Delays and timing

A delay node pauses a run in one of two modes:

- **Duration**: wait a fixed span, written as an ISO 8601 duration (`PT1H` for one hour, `P3D` for three days).
- **Until**: wait until a specific time, like 9am in the user's timezone tomorrow.

Courier uses `profile.timezone` for timezone-aware delays and defaults to UTC when none is set. Pair delays with quiet hours so routine messages land during business hours and only critical ones override.

![Time-of-day delivery windows in a Courier journey](//images.ctfassets.net/z7iqk1q8njt4/5vCkuNRRukbQxwxkjicazG/9d3d5395537800092320ee2241bde502/time_of_day_journeys.png?w=600)

## Fetching external data

A [fetch data node](https://www.courier.com/docs/platform/journeys/nodes/fetch-data) makes an HTTP request mid-run and merges the response into the run's data, so a branch downstream decides on live state instead of stale trigger data. Configure the URL (with interpolation like `https://api.yourapp.com/accounts/{{profile.account_id}}/health`), the method (GET, POST, PUT, or DELETE), and auth. How the response combines with existing run data depends on the merge strategy:

| Strategy | Behavior |
|---|---|
| `overwrite` | Deep-merges the response into run state; response values win on conflict. |
| `soft-merge` | Adds only fields that don't already exist; keeps existing values. |
| `replace` | Replaces the entire run state with the response. |
| `none` | Discards the body (fire-and-forget). |

Add a branch after the fetch to handle failures: route users whose `data.health_score` exists one way and failed fetches another.

## Throttling, batching, and digests

A [throttle node](https://www.courier.com/docs/platform/journeys/nodes/throttle) limits how often a run passes a point within a window. Scope it per user (cap one user's sends), global (cap total volume across users), or dynamic (cap by a key you pass, like account ID). Set a `max_allowed` and a `period`, and a burst that exceeds the cap is suppressed.

Batching and digests roll a burst of events into one message: instead of 20 comment alerts in an hour, a user gets a single summary.

## The AI node

The AI node runs a frontier model inside the journey and returns structured data the rest of the flow acts on. Pick a model (GPT-5.5, Claude Opus 4.8, Claude Fable 5, and other OpenAI and Anthropic models), write a prompt with `{{variable}}` interpolation from journey data, and define an output schema (form mode for simple fields, JSON mode for complex shapes). The response is parsed to that schema and merged into the run.

![Courier Journeys AI node returning a structured churn-risk score that routes the journey](//images.ctfassets.net/z7iqk1q8njt4/6rUjXqKFrsEIp8pI6eHBEA/fe402b201fd857fdb276c2aab40dfe9e/journeys_ai_node.png?w=600)

Four things it does without an external service:

- **Generate content.** Tailored subject lines and body copy per recipient, instead of maintaining dozens of template variants.
- **Score and route.** Assess churn risk, intent, or engagement and return a category your branch reads.
- **Enrich profiles.** Classify a user into a persona or derive attributes, and persist them to the profile so every future journey starts with richer context.
- **Produce structured data.** Return JSON that a downstream fetch node writes to your CRM or warehouse.

Web search is available for Anthropic models; it adds two credits per run and counts toward input token usage. Test the node in the editor with sample inputs, and run inspection shows the full prompt, the raw response, and the parsed output.

## Experiments

A send node can run an experiment instead of a single template: it holds 2 to 10 template variants and splits traffic across them, so you can compare subject lines, copy, or layouts on one send without branching the journey. Each variant is a full template you edit inline, and each carries a relative weight, so weights of 60/30/10 keep most traffic on your current template while testing two alternatives.

Courier assigns recipients with a bucketing key you pass in your data, like a user or workspace ID: it hashes the key so the same recipient always lands in the same variant. Assignments stay sticky when you change weights, and only re-bucket if you add or remove a variant or change the key.

The Results and Metrics views break delivery, open, and click data out per variant. When you've seen enough, you promote a variant: its template becomes the only one on the node and the experiment ends. Promotion is a manual decision; Courier doesn't pick a variant for you.

## Testing and run inspection

Before publishing, use test mode: provide sample event data and watch each node execute, so you can confirm a branch routes a user who finished setup differently from one who didn't. After publishing, [run inspection](https://www.courier.com/docs/platform/journeys/run-inspection) steps through a real user's run node by node, showing the data at each step and where it errored.

![Courier message logs showing delivery status and channels attempted per run](//images.ctfassets.net/z7iqk1q8njt4/2sUPzNQPZ9lvTOdEQepbu7/90683c82670a58fab671b715159ff346/Screenshot_2025-11-25_at_10.29.13â__AM.png?w=600)

Message logs show delivery status, channels attempted, and errors, searchable by user, template, or journey. The common failures:

- The recipient has no contact info for the target channel.
- The user opted out of the message topic.
- A branch routed the user past the send node.
- A provider rate limit was hit.

Analytics roll up completion rates, drop-off points, branch usage, and per-channel engagement, so you can see where a journey loses people. Chapter 4 turns these mechanics into full lifecycle blueprints; Chapter 3 covers what to look for in a platform.

## Frequently asked questions

### Can I build a journey in code instead of the visual canvas?

Yes. The Journeys API lets you create a journey, define its templates, wire the node graph, publish it, and invoke runs from your backend, and the canvas and API act on the same journey. Teams often design on the canvas and invoke from code, or manage the whole lifecycle programmatically when journeys are generated or kept in version control.

### How does Courier receive events from Segment?

Configure Courier as a destination in your Segment workspace, and Segment forwards `track`, `identify`, and `group` calls automatically. Track events appear as triggers you can map to a journey, with no webhook code on your side. The [Segment integration guide](https://www.courier.com/docs/external-integrations/cdp/segment) covers the full setup.

### How do I stop a journey when a user converts early?

Cancel the run. Configure the journey to cancel when a specific event fires, for example `trial_converted`, and Courier stops all pending steps for that user immediately. This keeps you from messaging someone who already did the thing you were driving.

### How do I debug a journey that isn't sending messages?

Open run inspection and find the user's run; each node shows whether it's pending, completed, or errored, along with the data it saw. The usual causes are a profile with no contact info for the target channel, a user who opted out of the topic, or a branch condition that routed them away from the send node.

### Can one journey run for many users at the same time?

Yes. Each user has an independent run with its own state, so one user on day 3 has no effect on another starting day 1. Throttle nodes and cross-journey frequency caps control how often any single user is reached.

Build a customer journey in Courier: API and Segment triggers, send nodes, branching, delays, fetches, throttling, the AI node, experiments, and run inspection.

How to Build a Customer Journey in Courier

Building Customer Journeys with Courier

*Last updated: July 2026*

## Key takeaways

- The core requirement is real-time behavioral triggering: a journey has to fire on product events as they happen, not on a batch sync.
- A platform serves the whole team when engineers get an API, product managers get a visual builder, and lifecycle teams edit templates without a deploy.
- Channel breadth, provider flexibility, native throttling, and preference management separate infrastructure from a single-channel tool.
- Courier is notification infrastructure with a visual journey builder: one platform for the team, 50+ providers, and per-send pricing.

## What to look for in a journey platform

Whether you build it yourself or adopt a platform, journey management has to do a few things well. These are the criteria that matter:

- **Real-time behavioral triggers.** The platform should start a journey the moment a product event fires. Anything that syncs data in hourly or nightly batches misses the moment that made the message relevant.
- **A builder the whole team can use.** Engineers need an API and SDKs; product and lifecycle teams need a visual canvas and inline template editing, so they can change a flow without shipping code.
- **Channel breadth (omnichannel).** Email and SMS are the baseline. Lifecycle messaging also reaches in-app, push, and workplace channels like Slack and Microsoft Teams, from the same journey.
- **Provider flexibility.** You should be able to choose a strong provider per channel and swap one without rewriting code.
- **Throttling and preferences.** Native frequency caps and topic-based preferences keep coordinated journeys from turning into noise.
- **Observability.** Per-step delivery, open, and click data, plus run inspection, so you can see where a journey loses people.

## What Courier is

Courier is notification infrastructure with a visual journey builder. It triggers on real-time product events, directly or through [Segment](https://www.courier.com/docs/external-integrations/cdp/segment), runs the workflow on a canvas the whole team can edit, and delivers across every channel. The way Stripe abstracts payment complexity behind one API, Courier abstracts channel APIs, authentication, template rendering, delivery tracking, and preferences: your application calls Courier instead of SendGrid, Twilio, Firebase, and Slack directly, and you swap a provider by changing configuration, not code.

Two things follow from treating messaging as infrastructure. Courier integrates [50+ providers](https://www.courier.com/platform/notification-infrastructure), so you pick a strong one per channel and add a channel by enabling a provider rather than building an integration. And it meters per send: one message fanned out to email, SMS, push, and Slack counts once. Chapter 2 covers how to build a journey on it.

![One journey delivering across email, SMS, push, in-app, and chat providers](//images.ctfassets.net/z7iqk1q8njt4/4g11UbzSHwujy30SKCxAY4/40053ac585d75a5ba115a9f5d3710714/Frame_163979__2_.png?w=600)

## How teams run journeys on Courier

[LaunchDarkly](https://www.courier.com/use-cases/launchdarkly) powers its Feature Workflows on Courier. When an engineer schedules a flag release or requests approval, Courier routes the message to Slack, Microsoft Teams, or email and tracks it until it resolves, with no custom queue logic. Moving approvals into the tools engineers already watch cut approval time internally.

[DroneDeploy](https://www.courier.com/blog/courier-inbox-complete-notification-center-web-mobile) processes large map files for construction site drone mapping, and their journeys fire status updates across in-app and email when rendering completes, replacing manual polling.

> "With Courier, we added a beautiful inbox and in-app push notifications in a matter of weeks. Notifications are not our core competency, so it made complete sense to integrate rather than build out and support our own implementation."
>
> **James Pipe, VP of Product, DroneDeploy**

[Twilio](https://www.courier.com/use-cases/twilio) consolidated the fragmented tools behind its Console (Segment, SendGrid, and hand-coded logic) onto Courier, giving 10 million developers one real-time, branded inbox instead of scattered systems.

> "The inbox depth and multi-channel integrations allowed us to choose one notification platform for all products and teams."
>
> **Raghav Katyal, Technical Lead, Twilio**

## Frequently asked questions

### Does Courier replace Segment or work alongside it?

Courier works alongside Segment. Segment is a customer data platform that collects behavioral events and routes them to downstream tools; Courier is the platform that sends based on those events and manages delivery, preferences, and analytics. Configure Courier as a [Segment destination](https://www.courier.com/docs/external-integrations/cdp/segment) and events flow in to trigger journeys, while Courier sends engagement data back so your analytics tools see it alongside product usage.

### Should you build journey infrastructure or use a platform?

Build it yourself only if messaging is core to your product and you want to own the whole stack. For most teams the scope is larger than expected: event consumers, a workflow engine, delay queues, conditional evaluation, multi-channel dispatch, preference management, and analytics, all before the first message goes out, plus the ongoing maintenance. A platform covers that layer so your team designs flows instead of operating infrastructure.

### Can the whole team use one journey platform, or do engineers own it?

A cross-team platform lets each role work the way it wants on the same journey: engineers trigger and manage journeys through the API, product managers build and edit flows on the visual canvas, and lifecycle teams edit templates inside send nodes without a deploy. That avoids the split where transactional messaging lives in engineering and lifecycle messaging lives in a separate tool, which fragments analytics and preferences.

### What should a customer journey platform support?

At minimum: real-time event triggers, a visual builder, branching and delays, throttling and preferences, and delivery across email, SMS, push, in-app, and workplace channels. Beyond that, provider flexibility (so you can swap providers without code changes) and per-step analytics are what separate infrastructure you can rely on from a single-channel tool.

What to look for in a customer journey platform: real-time triggers, a visual builder the whole team can use, channel breadth, and provider flexibility.

How to Choose a Customer Journey Platform

Choosing Your Journey Management Platform

*Last updated: July 2026*

## Key takeaways

- A journey's length should match the lifecycle phase and the signals available, not a fixed calendar; a four-step journey that reacts to behavior beats a twelve-step one that fires regardless.
- The highest-value branches happen after you have enough behavioral data to route confidently, usually a few days in.
- Cancel a journey the moment its goal is met, so you stop messaging someone who already converted.
- The same patterns adapt across SaaS, healthcare, HR tech, and marketplaces by changing the channels, data, and constraints, not the structure.

Each blueprint is built from the nodes in [Chapter 2](https://www.courier.com/guides/how-to-build-customer-journeys/building-customer-journeys-with-courier).

## Trial conversion

The trial-to-paid journey is where most product-led growth investment concentrates. The goal is helping users reach the activation milestones that predict conversion before the trial ends.

| Day | Trigger or check | Action |
|---|---|---|
| 0 | `trial_started` | Welcome message, personalized by `{{data.use_case}}` |
| 1 | Logged in? | If no, a login reminder via push or SMS |
| 3 | Feature activated? | Yes: next-step tips. No: getting-started help |
| 5 | Team invited? | If no, an invitation prompt with team value |
| 7 | Fetch engagement score | High: expansion talk plus a sales Slack alert. Medium: usage tips. Low: CS outreach |
| 13 | Final day | Conversion message, tailored to engagement level |

![A trial conversion journey on the Courier canvas with branching by activation](//images.ctfassets.net/z7iqk1q8njt4/SC7dGKZHtjGrN7fJP9KcW/9a100cdd1ee0b666c38ee72064c4f212/generic_journeys.png?w=600)

The branches at day 3 and day 7 are where behavior-driven journeys beat static sequences: by day 7 the journey has enough data to route confidently. When a user converts before the trial ends, cancel the run using the `runId` from the original invocation and start a post-conversion onboarding journey instead.

## Churn prevention

Churn prevention journeys spot at-risk accounts before they cancel and route each to the right intervention. The most reliable early signals are engagement drops, not stated intent to leave.

Define risk tiers from behavioral data, then let the [AI node](https://www.courier.com/guides/how-to-build-customer-journeys/building-customer-journeys-with-courier) score each account and return a level plus a one-line reason:

```
[Trigger: daily_risk_check]
  -> AI node: score churn risk -> { risk_level, reason }
  -> Branch on risk_level
       high   -> CS Slack alert + outreach task -> wait 3 days -> escalate if no contact
       medium -> usage tips with the reason -> wait 7 days -> re-check
       low    -> feature discovery -> wait 14 days -> re-check
```

The `reason` field makes outreach feel specific instead of automated, and no scoring model has to be built or hosted. Cancel the journey when the account upgrades, when CS marks it contacted, or when usage recovers; running a churn journey at an active user creates friction.

## Feature adoption

New features often launch with one announcement and no follow-through. Adoption journeys deliver education at the moment a user hits the relevant context. "You can export your data" three days after signup is noise if the user has no data yet; the same message when they create their first report and try to share it is useful.

Structure adoption journeys around context signals: a user reaches a milestone that makes the feature relevant, or activates a related feature that usually precedes it, with a time-based fallback only for users who never hit the trigger. Track the `feature_activated` event to measure what share of recipients actually adopted the feature inside the journey window, which separates adoption that works from clicks that go nowhere.

## Expansion and upsell

Expansion journeys watch for growth signals and route each to the right conversation.

For per-seat pricing, monitor seat fill rate. When an account reaches 80% of its limit, a `seat_utilization_update` event triggers the journey: it messages the account owner with current utilization and the upgrade path, alerts the CSM, and starts a seven-day follow-up. A branch first checks whether an expansion conversation happened in the last 30 days, so accounts already in one are suppressed rather than messaged again. Don't wait for 100%: accounts that hit the wall without a conversation tend to churn.

Advanced-feature usage is another expansion signal. When an account activates multiple advanced features, send a message about the capabilities they're approaching that need a plan upgrade, framed around what they're trying to do, not upsell pressure.

## Enterprise onboarding

Enterprise accounts need coordinated onboarding across stakeholders who each need different information. Map contacts to roles at setup and run a timeline per role:

- **Technical contact**: integration guides, API docs, SSO setup.
- **Administrator**: user management, policy and security configuration.
- **Executive sponsor**: success metrics, business case, QBR scheduling.
- **End users**: feature tutorials, quick-start guides, training schedules.

Track technical milestones (SSO configured, first integration live, provisioning set up) as product events, and have journey steps check milestone completion before advancing. Incomplete milestones past a deadline escalate to the CSM. Courier's [tenant architecture](https://www.courier.com/docs/platform/tenants/tenants-overview) keeps each enterprise customer's configuration isolated while the journey logic stays shared.

## Patterns by industry

The structure holds across industries; the channels, data, and constraints change.

### SaaS

[B2B SaaS](https://www.courier.com/solutions/saas) trial onboarding follows the trial conversion blueprint above. The differentiator is routing on product usage: developer-focused users get API and SDK docs, dashboard users get UI walkthroughs, driven by a `feature_type` property on the same `feature_activated` event.

### Healthcare

[Healthcare platforms](https://www.courier.com/solutions/healthcare) face HIPAA constraints: no protected health information in email or SMS, yet patients need timely reminders. The pattern is channel separation enforced at the journey level. Appointment reminders escalate across channels (email with prep instructions at day 7, an SMS confirmation at day 3, a final reminder at day 1), and lab results branch on sensitivity: normal results send with a portal link, abnormal results notify the provider first. In-app messages can carry detail because the app requires authentication. Trusted Health coordinates staffing across hospital systems on this pattern, keeping sensitive details in authenticated in-app delivery and using email for the rest.

### HR tech

[HR platforms](https://www.courier.com/solutions/hr) serve many companies with different policies and channel preferences. [Tenant-based routing](https://www.courier.com/docs/platform/tenants/tenants-overview) defines the journey once and respects each company's setup through group associations. New-hire onboarding, benefits enrollment with reminders at 14, 7, and 1 day before a deadline, and performance-review cycles all run as journeys that batch reminders into digests and respect quiet hours. Lattice runs this pattern for its performance-review cycles.

### Marketplaces

[Marketplaces](https://www.courier.com/solutions/marketplace) coordinate parties with competing needs. The same `order_placed` event splits into a buyer path (email confirmations, tracking, delivery) and a seller path (push for immediate awareness, detailed emails, payout confirmations), with disputes escalating to support when an SLA approaches. High-volume sellers get throttling so updates arrive at a manageable frequency. Side coordinates real estate transaction milestones between agents and clients on this multi-party pattern.

## Running journeys in production

Users are never in one journey at a time, so coordination is what keeps a good journey from becoming noise.

- **Frequency caps.** Set a cross-journey limit (for example, five messages a day) so a user in onboarding, a re-engagement journey, and an announcement doesn't get all three at once. The cap suppresses lower-priority sends at delivery time.
- **Cancellation.** End obsolete journeys when a user hits a milestone; canceling by tag stops a group of related journeys at once, like all trial journeys when an account converts.
- **Priority.** System alerts outrank feature highlights; support updates outrank marketing.
- **Preferences and quiet hours.** Group messages into [topics](https://www.courier.com/platform/preferences-management) users opt into per channel, default critical topics to opt-in and marketing to opt-out, and let quiet hours hold routine messages while critical ones override.
- **Personalization.** Use Handlebars with profile and event data (`Hi {{profile.first_name}}`, `activating {{data.feature_name}}`) so one template serves many segments. Every trait sent through Segment's `identify` call becomes a variable.

## Frequently asked questions

### How many steps should a customer journey have?

Match the length to the lifecycle phase and the signals you have. Trial onboarding usually spans 7 to 14 days with three to eight touchpoints depending on engagement; post-purchase sequences often run 30 to 90 days. Add a step only when it serves a goal based on real behavior. A four-step journey that reacts to signals outperforms a twelve-step one that fires regardless.

### How do you measure whether a journey is working?

Track completion rate (the share of users who reach the goal event) and drop-off points (which steps see the highest exits), then compare the paths of converted and non-converted users to see where they diverge. Courier's message logs show delivery, open, and click data per step; layer that on product analytics that track the goal event. A journey that generates clicks but no feature activations is measuring the wrong thing.

### How do you prevent a user from getting the same journey twice?

Check whether the user already completed the goal before starting the journey, for instance whether they're already on a paid plan or already activated the feature. Cancellation handles the case where the goal is met mid-journey, and frequency throttling prevents re-entry within a defined window even if the trigger fires again.

### How many journeys can run for one user at once?

There's no hard per-user limit, but a user in more than three or four active journeys is probably getting more messages than any single journey would send. Set cross-journey frequency caps so total daily volume per user stays bounded; the cap applies at delivery time and suppresses lower-priority sends once the limit is reached.

### What should a journey do when a user ignores every message?

After a set number of sends with no engagement, drop to a low-frequency maintenance mode instead of continuing the cadence. For a trial user who hasn't opened anything by day 7, send one final message at day 13 rather than the full mid-journey sequence. For an unresponsive churn-risk account, route to CS for direct contact. Continuing to send to disengaged users hurts deliverability and adds no value.

## Ship customer journeys with Courier

You now have the full picture: what a customer journey is, how to build one node by node, what to look for in a platform, and the patterns that hold up in production. Building this yourself means event consumers, a workflow engine, delay queues, conditional evaluation, multi-channel dispatch, preference management, analytics, and now AI, before you send a single message. Courier handles that layer so your team designs the flow and ships changes without a deploy, while engineers keep one integration point.

> **Ready to build customer journeys that respond to what users actually do?** [Talk to a solutions expert](https://www.courier.com/request-demo) or [get started for free](https://app.courier.com/signup) with 10,000 sends a month.

**Related resources:**
- [Understanding customer journey management](https://www.courier.com/guides/how-to-build-customer-journeys) (Chapter 1)
- [Building customer journeys with Courier](https://www.courier.com/guides/how-to-build-customer-journeys/building-customer-journeys-with-courier) (Chapter 2)
- [Courier Journeys product overview](https://www.courier.com/platform/journeys-customer-engagement-platform)

Journey blueprints for trial conversion, churn prevention, feature adoption, expansion, enterprise onboarding, across SaaS, healthcare, HR, and marketplaces.

Customer Journey Patterns and Best Practices

How to Build Customer Journeys

Learn how to build event-driven customer journeys that respond to product behavior: triggers, branching, AI, multi-channel delivery, and platform selection.

How to Build Customer Journeys: The Complete Guide

Your product already knows when a user activates a feature, invites a teammate, or goes quiet for two weeks. A customer journey turns those signals into the right message at the right moment, automatically, without a new engineering ticket for every campaign. This guide covers what customer journeys are, how to build one, how to choose a platform, and the patterns that hold up in production. It starts with the concept and goes deep into implementation, so you can arrive knowing nothing about customer journeys and leave ready to ship.

How to Build Customer Journeys

Highlights

Contents

Products

Solutions

Platform