Customer Journey Orchestration Patterns

Last updated: May 2026

Journey Orchestration in Practice

Customer journey orchestration turns product data into coordinated, multi-step communication. Instead of sending notifications based on time alone ("send email on day 3"), orchestrated journeys respond to what users actually do: which features they activate, where they get stuck, whether they come back.

The patterns below represent common B2B SaaS journey types with concrete structures. Each journey is built in Courier's Journeys builder using the node types described in this guide.

Trial Conversion Journeys

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

Journey Structure

What Makes This Work

The branching at day 3 and day 7 is where behavior-driven journeys outperform static sequences. Users who activated a feature get different messaging than users who didn't log in again. By day 7, the journey has enough behavioral data to make confident routing decisions.

LaunchDarkly routes developer users toward API documentation and SDK guides while routing dashboard users toward UI features. The product sends the same event (feature_activated) but with a feature_type property that the journey branch node reads.

Cancellation

When users convert before the trial ends, cancel the journey using the run ID from the original invocation. Send a post-conversion onboarding journey instead.

Churn Prevention Journeys

Churn prevention journeys identify at-risk accounts before they cancel and route them to the appropriate intervention.

Risk Signals

The most reliable early signals are engagement drops, not explicit intent to cancel. Define risk tiers based on behavioral data:

• High risk: No login in 14+ days AND no team activity
• Medium risk: Usage down 50%+ week-over-week for two consecutive weeks
• Low risk: Single key feature unused after 30 days

Each tier routes to a different intervention. High-risk accounts go to direct CS outreach. Medium-risk accounts get product education focused on the dormant features. Low-risk accounts get feature discovery nudges.

Journey Structure

[Trigger: daily_risk_calculation event]
  → Branch: risk_score
    → "high" → Send CS alert to Slack + assign outreach task → Wait 3 days → Check if CS contacted → Escalate if no
    → "medium" → Email with usage tips + feature highlights → Wait 7 days → Check if usage recovered
    → "low" → Feature discovery email → Wait 14 days → Check engagement

When to Stop

Churn prevention journeys should cancel when the account upgrades, when CS marks them as "contacted," or when usage recovers. Running a churn prevention journey at someone who's actively using the product creates friction.

Feature Adoption Journeys

New features often launch with announcement emails and limited follow-through. Feature adoption journeys provide sustained education delivered at the moment users encounter the relevant context.

Context-Triggered vs Time-Triggered

The difference between useful feature education and spam is timing. "You can use our export feature" sent three days after signup is noise if the user hasn't generated any data to export. The same message sent when a user creates their first report and tries to share it is directly useful.

Structure feature adoption journeys around context signals:

• User reaches a milestone that makes the feature relevant (triggered delivery)
• User activates a related feature that commonly precedes adoption (triggered delivery)
• User has been in the product long enough that not using the feature is notable (time-based fallback only)

Measuring Adoption

Track the feature_activated event for each feature being promoted. Journey analytics show what percentage of recipients activated the feature within the journey window. This distinguishes adoption journeys that work from ones that generate clicks without actual adoption.

Expansion and Upsell Journeys

Expansion journeys identify accounts showing signals of growth and route them to the right conversation at the right time.

Seat Utilization Monitoring

For per-seat pricing, monitor seat fill rate. When an account reaches 80% of their seat limit, route a notification to the account owner showing their current utilization and the path to upgrading. Don't wait until 100%: accounts approaching limits without a conversation tend to churn when they hit the wall.

[Trigger: seat_utilization_update event where utilization >= 0.8]
  → Check: has expansion conversation happened in last 30 days?
    → No → Email account owner + Slack alert to CSM → Start 7-day follow-up sequence
    → Yes → Suppress (avoid repetition)

Feature Usage as Expansion Signal

Advanced features often indicate readiness for enterprise plans. When accounts activate multiple advanced features, route a targeted message about the capabilities they're approaching that require a plan upgrade. Frame it as capability expansion, not upsell pressure.

Multi-Party Coordination

Lattice, used by 5,000+ companies for performance management, coordinates communications between HR administrators, managers, and employees during performance cycle launches. When a performance cycle opens, the journey routes cycle details to HR admins, reminder sequences to managers to complete their reviews, and employee notifications when their reviews are available. Each party receives relevant information on the right timeline.

Enterprise Onboarding Journeys

Enterprise accounts require coordinated onboarding across multiple stakeholders. A single onboarding sequence sent to one contact misses the technical, administrative, and executive stakeholders who each need different information.

Multi-Stakeholder Routing

Map contacts to roles at account setup:

• Technical contact: Integration guides, API documentation, SSO configuration
• Administrator: User management, policy configuration, security settings
• Executive sponsor: Success metrics, business case materials, QBR scheduling
• End users: Feature tutorials, quick-start guides, training schedules

Each role's journey follows its own timeline with its own content. Courier's tenant architecture keeps each enterprise customer's configuration isolated while sharing journey logic.

Milestone Tracking

Enterprise onboarding success depends on completing specific technical milestones: SSO configured, first integration active, user provisioning set up, initial training completed. Track each milestone as a product event. Journey steps check milestone completion before advancing. Incomplete milestones trigger escalation to the CSM after defined deadlines.

How do you measure whether a journey is working?

Track completion rates (what percentage of users reach the journey's goal event) and drop-off points (which steps see the highest exit rates). Compare converted users' journey paths to non-converted users: where do they diverge? Courier's message logs show delivery, open, and click data per step. Layer this on top of 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 receiving the same journey twice?

Use journey conditions to check whether a user has already completed the goal event before starting. For trial journeys, check whether the user is already on a paid plan. For feature adoption journeys, check whether the user has already activated the feature. Cancellation handles cases where the goal is reached mid-journey. Frequency throttling prevents re-entry within a defined window even if the trigger fires again.

How many active journeys can run simultaneously per user?

Courier doesn't impose a per-user limit on concurrent journeys, but practical limits exist. Users in more than three or four active journeys simultaneously are likely receiving more notifications than any single journey would generate alone. Set cross-journey frequency caps in Courier's throttle configuration to limit total daily notifications per user across all active journeys. The cap applies at delivery time, suppressing lower-priority sends when the daily limit is reached.

What should a journey do when a user doesn't respond to any messages?

After a defined number of sends with no engagement, transition to a low-frequency maintenance mode rather than continuing the same cadence. For trial users who haven't opened any emails after day 7, shift to one final message at day 13 rather than continuing the mid-journey sequence. For churn risk accounts that don't respond to automated outreach, route to CS for direct contact. Continuing to send to disengaged users damages deliverability and provides no value.

Start building journeys in Courier. The free tier includes 10,000 notifications per month and full access to the Journeys builder. Or request a demo to walk through your journey requirements.