A journey map spans touchpoints and shows the whole course

What it is

Stringing the in-app screens from cart to pay, while leaving out the in-store question, the logistics text, and the support call, is a channel flow, not a journey. A user journey map unfolds along the touchpoints a person crosses to finish one job: store, app, SMS, phone, email, waiting. If the job is not over, the map must not be cut at a channel boundary. Crossing touchpoints is not collaging every channel’s UI onto one poster. It is showing one person’s whole course in time.

Why it happens

Organizations staff by channel, so material arrives by channel: product has logs, stores have scripts, support has tickets. Each group polishes its own stretch; the join is owned by no one. The person’s task does not stop at the channel line: when a pickup code expires they call the store, and the store tells them to open the app again. Mapped only inside the app, expiry looks like “churn.” With phone and store attached, the loss is a broken join. Time order turns “several interfaces at once” back into “one thing happening in sequence,” which is where the break between two stretches becomes visible.

Studying it

Take one complete job as the unit. Collect every touchpoint actually used on that job, rather than picking a channel and padding users later. Align diary, tickets, logistics events, and call records onto one case timeline and mark channel switches. Compare a single-channel funnel with a cross-touchpoint timeline on how failure is attributed. Outcomes: unmapped touchpoints, switch count, and the rate at which failure is booked to the wrong channel.

Where it stops holding

If the question is only about operability of one screen, do not inflate it into a journey; the journey will dilute the interface evidence. Purely online jobs that finish in one session gain little from extra touchpoints. The inverse trap is drawing every channel the company can imagine, including ones nobody walked—that is a channel catalog, not a course. In B2B, decision maker, operator, and beneficiary are often different people; welding their clocks onto one map needs a split by role or an explicit person-change mark.

Applying it

• Write what counts as the start and end of the job, then list touchpoints that actually occurred; channel names are labels only.
• Mark at least one channel switch per case; if there is none, check whether the job is truly single-channel or the material only came from one system.
• Funnels and page flows may be attachments; they do not replace the journey, which must answer where the person went after leaving this interface.
• In review, hide the stretch that belongs to your own product and see whether a complete story remains. If it dies immediately, you drew an internal procedure.

Related

• Same group: Q4.04.2 Emotion and pain on the map need a source · Q4.04.3 An unverified map is a team hypothesis · Q4.04.4 As-is maps what happens; to-be maps what is wanted — keep them apart · Q4.04.5 Too fine a grain drowns turning points; too coarse hides breaks · Q4.04.6 Maps that cross departments need shared upkeep · Q4.04.7 An unrefreshed map drifts from a changed process
• Adjacent: Q4.05 Service blueprints · Q4.06 Scenarios and storyboards
• Search terms: cross-touchpoint journey mapping · end-to-end journey · channel handoff