Choosing your journey management platform

Last updated: September 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 where a message that fans out to four channels still counts as one send.

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.

• 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 everyone can use. You need an API and SDKs on the engineering side, and a visual canvas with inline template editing on the other, so changing a flow doesn't mean 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.
• API, CLI, and agent access. Anything you can do in the dashboard should be reachable from code, so journeys can be generated, version-controlled, or handed to a coding agent. Check for an MCP server as well as an API: that is what lets an agent build and debug a flow instead of you clicking through one.
• Built-in experimentation. Testing two versions of a message shouldn't mean a second tool or a hand-rolled bucketing scheme. Look for weighted variants on a single send, sticky assignment per recipient, and metrics broken out per variant.
• Observability. Per-step delivery, open, and click data, plus run inspection, so you can see where a journey loses people. Programmatic access to run history matters too, for the times the question comes from a customer rather than from you.

What Courier is

Courier is notification infrastructure with a visual journey builder. It triggers on real-time product events, directly or through 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 notifications as infrastructure. Courier integrates 50+ providers, 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: a notification delivered across email, SMS, push, Slack, and in-app counts as one send, not one per channel, with no per-seat or per-channel fees. The free tier covers 10,000 sends a month and includes journeys, the MCP server, the CLI, and the SDKs.

The same parity applies to the surface you build on. Journeys, templates, brands, routing rules, preference topics, audiences, and tenants are all in the public API, and the dashboard is a client of that API rather than a privileged layer above it. That is what makes it usable by a coding agent: the MCP server exposes the API as 145 tools, and the CLI covers the same ground for scripts and CI. Chapter 2 covers how to build a journey on it.

Customer journeys in production

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

Can an AI agent build and run customer journeys?

Yes, if the platform exposes its full surface as an API rather than just a send endpoint. On Courier, the same public API behind the dashboard covers journeys, templates, routing, preferences, audiences, and tenants, and the MCP server exposes it as 145 tools that a coding agent can call directly. In practice you describe the flow you want, the agent scaffolds the journey and its templates, and you review it on the canvas before publishing.

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.