Customer journey map vs user journey map. What each one actually shows.

The short answer. Two different altitudes, not two names for the same thing.

A user journey map is a product and UX tool. It follows one user through one defined task inside a specific interface: signing up for a trial, completing a checkout, finding a setting inside an app. It shows screens, clicks, decision points and moments of friction at a fine grain, usually condensed into a single session that lasts minutes rather than months.

A customer journey map is a commercial and customer experience tool. It follows a person's entire relationship with a business, from the first time they hear about it through to renewal, expansion or churn, across every channel that touches them: an advert, a sales call, an onboarding email, a support ticket, a renewal conversation months later. It works at a much wider altitude, and it usually spans several products, teams and systems that no single owner controls end to end.

The confusion between the two is common because both use the word "journey" and both produce a horizontal map with stages across the top. But a user journey map answers "where does this person get stuck trying to do this one thing," while a customer journey map answers "where does this relationship weaken across everything we do." Those are different diagnostic questions, and building the wrong one for the problem in front of you wastes the time spent mapping it.

Nielsen Norman Group, the UX research firm whose journey mapping training many product teams train on, draws the same line: a journey map for a single user's task is a UX artefact built from usability observation, while a customer journey map is a strategic, cross-channel document built from research across the whole relationship, including moments the product team never sees, a call with support, a conversation with a reseller, a complaint posted publicly rather than raised through a ticket. The tools tend to follow the same split in practice. User journey maps are usually built in a product or design tool, Figma, FigJam, a whiteboard sketch of a flow, because they need to sit next to the actual screens they describe. Customer journey maps are usually built from CRM data, support logs and interview notes stitched together in a document or a tool like Miro, because no single product screen contains the whole story.

How they differ. Scope, owner, timeframe and what breaks each one.

The clearest way to separate them is to line the two up against the same five questions, since the differences are consistent across almost every business that runs both.

The ownership line matters more in practice than it looks on paper. A user journey map sits comfortably with a product or design team because they can act on nearly everything it surfaces: rewording a field label, removing a step, fixing a broken redirect. A customer journey map almost never sits with one function alone, because the weak point it finds, a lead going cold after a demo, a customer who feels ignored between onboarding and their first renewal call, usually sits between two teams rather than inside one. That is why customer journey work tends to land with marketing, customer success or a RevOps function with the authority to change a handoff, rather than with whichever team happens to run the workshop.

The two maps also fail differently when built badly. A user journey map built without watching a real person attempt the task turns into a flowchart of how the team assumes the product works, not how it actually behaves under a confused first-time user. A customer journey map built without pulling data from every channel it claims to cover, support tickets, CRM notes, actual call recordings, turns into a marketing persona exercise dressed up as research, accurate about the story the business tells itself and wrong about what customers actually experience.

Which you need and when. Match the map to the actual complaint.

The fastest way to choose is to state the problem in one sentence and see which map the sentence points to. "Visitors abandon our signup form at the payment step" is a user journey problem: narrow, inside one flow, fixable by whoever owns that screen. "Customers stop responding to us around month four even though the product works fine" is a customer journey problem: it spans onboarding, support and account management, and no single screen fix will touch it.

A practical test that holds up most of the time: if the fix you expect to make lives inside one system, a form, an app screen, a checkout flow, start with a user journey map. If the fix you expect to make requires two teams to agree on a handoff, a definition, or who owns a moment in the relationship, start with a customer journey map. Teams that skip this test tend to build the map they already know how to build, a designer defaults to a user journey map, a marketer defaults to a customer journey map, rather than the one the actual problem calls for, and then wonder why the finished map does not explain the complaint that prompted it.

Company stage changes which map earns priority first, too. A very early-stage product with a handful of users often gets more value from a tight user journey map of its core flow, since the product itself is still the main source of friction. A business with an established product but a retention or expansion problem usually gets more value from a customer journey map, since the product is no longer the constraint, the surrounding relationship is. Building the wrong one for the stage you are at is a common way founder-led teams spend a workshop day and come away with a map nobody uses again.

Team size affects the decision too, in a way that is easy to miss. A five-person startup where the founder still handles support, sales and product decisions barely needs a formal distinction between the two maps, because one person holds the whole picture in their head regardless of which document gets drawn. The distinction starts to matter, and starts to cause real friction if ignored, once a business splits into separate product, marketing and customer success functions, each with its own tools and its own partial view of the customer. That is usually the point a business first asks me which map it needs, because it is also the point nobody in the room can see the whole journey unassisted any more.

How Lauren would decide. The question I ask before agreeing to run either workshop.

When a client asks me to run a journey mapping session, the first thing I do is refuse to book the workshop until I have the complaint in one sentence, for exactly the reason above. I have sat in kickoff meetings where a UX lead and a head of customer success both said "we need a journey map" about the same product, and genuinely meant two different exercises, one wanting a click-by-click view of a broken onboarding screen, the other wanting to understand why customers who finished onboarding cleanly were still churning at month six. Running one workshop to satisfy both would have produced a map too detailed to present to leadership and too shallow to fix the actual screen.

In hospitality tech specifically, where I do a lot of this work, the split shows up constantly between a booking widget's user flow and a guest's actual relationship with the property across a stay. A guest can move through a booking widget's user journey without a single moment of friction, four clean screens, a fast confirmation, and still leave a quietly disappointed customer because nobody owned the gap between "booking confirmed" and "checked in," where a room type substitution or a missed special request lands with no clear owner. Fixing the booking widget and fixing that gap are two different projects, needing two different maps, and conflating them is the single most common reason a journey mapping exercise produces a nice-looking document that changes nothing.

My rule with clients: build the narrow map first if the complaint is genuinely narrow, and resist the temptation to widen it into a full customer journey exercise before the specific screen or flow is actually fixed. A customer journey map is the right next step once the narrow fixes are exhausted and the complaint keeps recurring anyway, which is usually the clearest sign the weakness has moved outside any single team's control. For the fuller method behind building the wider map properly, see our guide to what customer journey mapping actually is, and for the document itself, what a customer journey map should include.