5 Mistakes Teams Make Building Customer Journeys

I've been building and breaking customer journeys for over a decade. Forward-deployed growth at Yahoo, second lifecycle hire at Autodesk, and enough notification infrastructure work since to have strong opinions about what breaks. Here are five lesser-known mistakes worth watching for, most of which I've made myself.

1. The volume trap

One journey works, so the team builds another. A second team builds one too. Before long a user is getting onboarding nudges, feature announcements, re-engagement pings, and upsell prompts at the same time, from sequences that have no idea the others exist.

The hard part of the volume trap is that it's almost invisible from inside any single journey. Every sequence can look healthy on its own dashboard. Opens are fine, clicks are fine, unsubs on this journey are within range. The damage is in the overlap, and the overlap isn't instrumented anywhere. You'd need to pull per-user send counts across every journey, every transactional system, and every one-off campaign, then cross-reference with unsub events, to see what's actually happening. Most teams don't have that view because the systems don't share a user timeline. Marketing automation lives in one tool, product notifications in another, transactional email in a third. By the time someone notices the aggregate unsub rate creeping up, the user who opted out did so three journeys ago, and there's no way to attribute the decision to any single sequence.

2. No exit criteria

Most journeys are built with entry conditions and nothing else. A user signs up, enters the onboarding sequence, and keeps getting messages from it no matter what they do next. If they activate on day two, they still get the day-four getting-started email. If they churn on day five, they still get the day-ten feature walkthrough. If they upgrade mid-trial, they still get the trial conversion sequence.

The problem is that journeys get designed around the steps they contain rather than the goal they exist to achieve. Once the goal is met, the journey should end. A user in onboarding should exit the moment they activate. A user in a win-back sequence should exit the moment they return.

Every journey needs exit criteria tied to its goal. If onboarding exists to drive activation, activation ends it. If re-engagement exists to bring users back, a return visit ends it. Without explicit exits, journeys run to their full length by default, and users keep getting messages that no longer match where they are.

3. Channels as an afterthought

A team builds a journey and then picks channels per step based on what's available: email here, push there, in-app where it fits. The content of the message is the real decision. The channel it goes out on is an afterthought.

The result is a payment failure that shows up as an email buried under 40 others, a weekly digest that arrives as a push notification, and a critical account alert that sits in an in-app inbox the user won't see until next week.

Channels aren't interchangeable. Each one carries different expectations about urgency, attention, and what the user is supposed to do next. Push is for now. Email is for later. In-app is for when the user is already here. SMS is for when nothing else will work. Getting this wrong doesn't just hurt performance. It trains users to ignore the channels you're using, because they learn your push notifications aren't urgent and your emails aren't important.

The fix is to pick the channel based on what the message needs from the user, not what's available in the step. If the message needs action in the next five minutes, it's not an email. If the message needs reference later, it's not a push.

4. Designing journeys around your org chart

Marketing owns the welcome sequence. Product owns feature adoption. Sales owns trial conversion. Support owns ticket follow-ups. Each team builds its piece in isolation, and the customer ends up with an experience that makes sense internally and none externally.

CX Today's analysis of why customer journeys stall identified this as a primary breakdown point: what one team knows about the user doesn't reach the next team in time to change what the next message says. Your onboarding sequence doesn't know the user filed a support ticket on day two, so it sends a cheerful "How's it going?" while they're waiting on a fix. Your re-engagement email fires two hours after billing sent a failed-payment notice, because marketing and transactional live in different systems.

Journeys need a single owner or a governance model, even when multiple teams contribute content. Without one, each department is sending its own messages in parallel and calling the sum a customer experience. The test: can a new journey see the state of every other journey a user is in, including transactional sends? If not, your org chart is deciding what your users receive.

5. Time delays where event triggers belong

"Send email 3 days after signup" is the default in most tools. It's also almost always wrong.

The problem with time delays is they assume every user is in roughly the same place at the same time after signup. They almost never are. Three days in, one user has invited their team and shipped to production. Another hasn't logged in since the first session. Both get the same email about "getting started with your first integration," because the journey is built around the calendar instead of around what users have actually done.

Event triggers are built around user behavior. "Send when a user creates their first project." "Send when a user hasn't created a project within 72 hours of signup." "Send when a user invites a teammate but the teammate hasn't accepted." Each message only goes out when the user's state warrants it, so the content matches where they actually are.

Time delays are fine when time itself is the relevant variable: a trial expiration reminder, a renewal notice, a scheduled digest. For everything else, if you're writing a step that starts with "wait 3 days," you're probably building a journey around a calendar when you should be building it around an event.

What these have in common

Every one of these mistakes makes life easier for the team building the journey and harder for the user receiving it. Spinning up another journey is faster than coordinating with the ones that already exist. Skipping exit criteria is easier than defining what success means. Picking a channel by what's available is faster than picking by what the message needs. Letting each team own its own flow is less political than setting up governance. A time delay is simple to configure. An event trigger requires knowing which events your product actually fires.

The fix, in every case, is the slower and less convenient path on the sender side.

This is why we built Courier Journeys: one place to build every customer journey, with shared context across teams and across transactional sends, event-driven triggers and branches instead of calendar-based steps, explicit exit criteria on every path, and channel selection based on what the message actually needs.

See Courier Journeys · Read the docs