Chapter 1
How event-driven customer journeys differ from fixed campaigns, why lifecycle messaging needs to respond to product behavior, and the components that make journey management work — including triggers, branching, omnichannel delivery, and AI-powered personalization.

Last updated: May 2026
If you've ever activated a feature and received an email an hour later walking you through exactly how to use it, you've been inside a customer journey. If you've gone quiet during a trial and gotten a check-in three days later asking what was getting in the way, that was a journey too. The best B2B products respond to what you actually do, not what a marketing calendar says you should receive.

A customer journey is a series of automated messages and actions triggered by what users actually do in your product. Think of it as your product paying attention: welcoming someone on day one, following up when they activate a key feature, checking in when they've gone quiet, escalating to account management when expansion signals appear. The journey platform is what makes this happen automatically, at scale, across every channel, without requiring engineering time for each new campaign.
Most journey builders organize as a visual canvas: a graph where every step in the lifecycle is visible at once. Triggers start the flow, a user signs up, activates a feature, hits a usage limit. Branch nodes evaluate conditions and route users to different paths. Delay nodes control timing. Send nodes dispatch messages across channels. Data fetch nodes pull in external context mid-flow.

The canvas makes complex multi-step lifecycles readable to everyone on the team, not just the engineer who built it. Edits to steps, branches, copy, and timing happen without code or deploys, which matters when a lifecycle team needs to iterate on an onboarding sequence without filing an engineering ticket. Courier's journey builder gives engineers the API control they need, product managers the visual canvas they need, and lifecycle teams the template editor they need, all on the same workflow.
Every tool has a different relationship with timing and user behavior. The distinction matters more than most teams expect when they start building lifecycle messaging.
| Customer Journey Platform | Marketing Automation | Email Campaigns | Custom Build | |
|---|---|---|---|---|
| Trigger types | Product events, behavioral signals | Form submissions, time-based | List segments, manual | Anything you build |
| Real-time response | Sub-second event processing | Minutes to hours | Batch, often daily | Depends on implementation |
| Best for | Lifecycle orchestration, activation, retention | Lead nurture, campaign management | Announcements, newsletters | Fully custom workflows |
| Non-technical access | Visual builder for PMs and lifecycle teams | Campaign designers | Email composers | Engineering-only |
| Channel support | Email, in-app, SMS, push, Slack, Teams, chat | Primarily email | Email only | Whatever you integrate |
| Risk if misused | Over-messaging power users | Email fatigue | Message-blind users | Maintenance debt |
The strongest lifecycle messaging stacks use these layers together. A journey platform built on multi-channel routing handles behavioral orchestration, while campaign tools handle broad announcements. Each does what it's actually good at.
A fixed campaign sends the same sequence to everyone on the same schedule. Day 3: intro email. Day 7: feature highlight. Day 14: trial expiration warning. The appeal is simplicity. The problem is that these sequences don't know what any particular user has actually done.
A user who activated a feature on day 2 still receives the day-3 "here's how to use this feature" email. A user who became a power user in the first week still receives the churn-prevention sequence. The message arrives at the wrong moment and feels automated, because it is.
An event-driven journey adapts. When someone activates a feature, the activation branch fires immediately and the generic onboarding sequence stops. When usage spikes, escalation sequences pause. When an account hits a limit, the upgrade message arrives at the moment the user is experiencing the friction, not three weeks later on a schedule. The difference isn't just technical. It's the difference between messaging that feels attentive and messaging that feels like a batch job.
User expectations in B2B software have shifted. Products that send generic day-3 emails alongside tools that respond to what users actually do feel noticeably different. The context-aware product wins the mental model, it feels like it's paying attention, because it is. Research shows that companies that get personalization right generate 40% more revenue than those that don't. In B2B software, that gap shows up directly in trial conversion and retention rates.
The whole point of journey management is to let your product respond on the user's timeline, not yours. Someone activates a feature at 11pm, the follow-up should arrive when it's relevant, not when a batch job runs. Someone misses an onboarding step because they were pulled into a meeting, the journey should notice and follow up, not mark them as complete. Journey platforms exist so that every user gets a sequence shaped by what they've actually done, without engineering a custom flow for each scenario.
From a business perspective, the outcomes are concrete. Journey management increases trial-to-paid conversion by delivering activation messages at the right moment. It reduces churn by catching disengagement early when there's still time to intervene. It expands accounts by surfacing upgrade prompts when users are actively hitting limits. And it moves iteration out of the engineering queue, when lifecycle teams can update a journey without a deploy, experiments ship faster.
Journey management applies across the entire user lifecycle. The specific flows vary by product, but the patterns repeat whether you're building developer tools, project management software, or a healthcare platform.

Onboarding is the highest-use place to start. The journey begins at signup and guides users to first value, connecting an integration, sending a first message, inviting a teammate. Branch logic adapts the sequence based on what each user has and hasn't done, so power users don't get beginner content while struggling users get more support. Activation journeys operate on the same principle but at later milestones: a user unlocks a capability and the journey reacts immediately with guidance most relevant to their account state.
Retention journeys watch for behavioral signals that precede churn. Usage drops below a threshold, the last login was two weeks ago, a key collaborator left the account, any of these can trigger a response while there's still time to change the outcome. The sequence escalates gradually: a useful tip first, a direct check-in next, a CSM alert if the pattern continues. Expansion journeys work from the opposite signal: usage near a limit, repeated access of a locked feature, multiple teammates added to an account. These moments carry intent, and the right message at the right moment converts.
Twilio manages a customer engagement platform processing nearly one trillion digital interactions annually. Rather than expanding their deprecated Notify API, they chose Courier to orchestrate messages across their developer ecosystem, infrastructure that responds to behavioral signals in real-time, not batch marketing workflows.
LaunchDarkly built event-driven messaging workflows around their feature flag approval process. When someone requests a new flag or needs approval to change an existing one, the journey routes the message immediately to the right approvers and tracks state until resolution, no manual follow-up required.
"We were able to build the in-app notification experience that we wanted with excellent support and communication from the Courier staff."
Lucy Wonsower, Software Engineer, LaunchDarkly
DroneDeploy processes large map files and videos for construction site drone mapping. Their journeys trigger status messages when rendering completes, routing updates across in-app and email based on user session state, replacing manual polling with event-driven delivery.
"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
If you're evaluating journey platforms or building customer journeys, some capabilities are mandatory and others separate a basic workflow engine from infrastructure your whole team can rely on.

You need event-driven triggers that respond in real-time to product events and user attributes, not overnight batch syncs. Behavioral signals are only useful if the journey reacts to them at the moment they fire. Courier's automation API accepts triggers directly or through integrations with Segment and RudderStack so your existing event pipeline connects without custom webhook work.
A visual journey builder lets non-technical team members build and iterate without engineering tickets. When lifecycle teams can update an onboarding sequence without a PR, experiments ship faster and engineers stay focused on product work. Branching and conditional logic is what makes journeys actually respond to behavior, branch nodes evaluate account tier, feature activation state, usage level, and last login date, routing each user to the path that fits where they actually are. Without branching, every user gets the same sequence regardless of what they've done.
Delivery timing controls when messages land: delay for a duration, wait until a specific time in the user's timezone, or schedule around quiet hours. Throttle controls prevent over-messaging by capping how often any journey can reach the same user, daily limits, cooldown periods, and global frequency management across all journeys combined. Omnichannel delivery across email, in-app, SMS, push, Slack, and Teams reaches users where they are, with routing rules and user preferences applied automatically at send time.
Fetching data from external APIs mid-journey is what separates adaptive messaging from static sequences. Account health scores, current subscription status, recent support tickets, pulling these at the moment they're needed means journey logic makes decisions on real-time state, not stale properties from the original trigger event. Data syncing pushes outputs back to your systems: enriched profile attributes, engagement events, and model outputs flow downstream to your data warehouse, CRM, or CDP without custom integrations.
Courier's AI node is the newest addition to the journey builder, and it changes what's possible without building models. Add GPT-5.5 or Claude Opus 4.7 at any step in a workflow and the model can generate personalized message content for each recipient, eliminating template variant sprawl, score users for churn risk or purchase intent from data already in the journey, and classify or enrich profiles mid-flow. The model output becomes data: branch on it, persist it to the profile, push it downstream. A journey can assess engagement, generate tailored content, and route accordingly without any ML infrastructure on your side.
Analytics and observability answer which journey steps have high drop-off, which conditional branches most users follow, and which messages drive the outcomes you're optimizing for. Without visibility into journey performance, iteration is guesswork.
Building lifecycle messaging infrastructure from scratch means event consumers, a workflow execution engine, delay queues, conditional evaluation, multi-channel dispatch, preference management, an analytics pipeline, and now AI integration, all before you've sent a single message. Most teams that attempt this find the scope larger than expected, and the ongoing maintenance larger still. Courier cuts that to days.
Here's what triggering a customer journey looks like with Courier's API:
Copied!
import { CourierClient } from "@trycourier/courier";const courier = new CourierClient({ authorizationToken: "your-api-key" });await courier.send({message: {to: { user_id: "user-123" },template: "feature-activated-onboarding",data: {feature_name: "advanced_reporting",account_tier: "trial"}}});
That one call triggers the full journey: the right sequence activates by account tier, channels select based on user preferences, timing adapts to their timezone, AI steps run mid-flow, and every touchpoint is tracked. Courier supports Node.js, Python, Ruby, Go, Java, PHP, and .NET SDKs. For a full implementation walkthrough covering journey design, branching, AI nodes, and omnichannel routing, see Chapter 4: Building Customer Journeys with Courier.
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 system responds with appropriate messages across the relevant channels. Unlike campaigns that follow a calendar, journeys adapt to what each user actually does, and stop when users complete the intended action.
Marketing automation platforms are designed for campaign management and email programs, batch sends, form-triggered nurture sequences, scheduled broadcasts. They struggle with consuming product usage events in real-time and triggering conditional workflows based on behavior. Customer journey platforms respond to behavioral events in sub-second time, serve the cross-functional teams that modern B2B companies run, and increasingly incorporate AI to personalize and route messages without manual template maintenance.
Customer data platforms collect behavioral events from your product and route them to downstream destinations. When you configure Courier as a destination in Segment, behavioral events flow automatically from your product to your journey builder. Your application calls analytics.track('feature_activated', {...}), Segment receives it, and Courier triggers the appropriate journey immediately, no custom webhook handlers, no latency from batch syncs.
Courier's AI node lets you run GPT-5.5, Claude Opus 4.7, and other frontier models at any step in a journey. The most common uses are generating personalized message content for each recipient without maintaining template variants, scoring users for churn risk or purchase intent and branching the journey based on what the model returns, and enriching user profiles with derived attributes that persist for every downstream step. The model runs inside workflow execution, not as a separate system you have to build and maintain.
Over-messaging typically comes from multiple journeys targeting the same user simultaneously without coordination. The solution is two-layered: per-journey throttle controls that limit how often a specific journey can message a user, and global frequency management that enforces limits across all journeys combined. Courier's journey builder includes both, plus preference management that lets users opt out of specific message categories entirely.
Ready to build customer journeys that respond to what users actually do? Talk to a solutions expert to see how Courier can help, or get started for free with 10,000 messages per month.
© 2026 Courier. All rights reserved.