Customer journey map
Trace one customer's task through touchpoints, actions and experiences, keeping evidence and unobserved stages visible.
Use a journey map when a customer moves between touchpoints but teams see only their own part. Define the person, goal and journey boundaries, then connect stages. This concerns the customer's experience; an internal process map or a storyboard of a proposed solution answers a different question.
One customer and task, start and end boundaries, touchpoint and action records in time order, the person's statements, and missing stages or assumptions.
An evidence-linked journey with unknown stages, friction and handoff questions, and proposed ownership and improvement checks.
How to use it
- Define one customer, goal, start and end. Mark the map as current experience or a proposed future experience, keeping the two separate.
- Order stages from the records, allowing returns, pauses and missing stages rather than a compulsory funnel.
- For each stage, record touchpoint, action, experience and evidence ID. Mark unsupported experiences as unknown.
- Identify friction, information gaps and handoffs; distinguish the record from a possible explanation.
- Choose one check or trial, propose an owner and observation method, and preserve purchases or effects that have not occurred.
Keep its limits in mind
A journey need not be linear or end in a purchase. Separate observed current experience from a proposed future experience; do not invent conversion to complete the final stage. Label feelings as self-reported or assumed. One person's path is not a group rate, and improvement opportunities still need testing.
Finding an information gap after a coffee subscription trial
Fictional teaching example: Grove Coffee recorded J1's journey from discovering a subscription to receiving a trial pack and completing one follow-up interview. J1 has not subscribed. The task is to understand price, delivery and pause rules before a first subscription. No confirmed pause-rule answer or maintenance owner is supplied.
On a small screen, scroll across the diagram to read it.
Set the boundaries: Keep one person and the first-subscription task. J1-O1 covers discovery and comparison; J1-O2 and J1-I1 cover the trial and interview. Stage 4 remains unobserved.
Keep experience attributed: J1 said the taste suited them and pause rules were unclear. This statement does not mean J1 intends to subscribe, or that an unclear rule caused the lack of a subscription.
Result and handoff: The map identifies a question about the rule answer and its maintenance role. It proposes asking support and operations, followed by a check with J1. None of those proposed actions or their effects has occurred.
J1 is a separate teaching case from U1 in the Empathy Map guide. Do not pool the records. Stage 4 is unobserved; a comment about taste is neither a subscription decision nor a conversion rate.
Next step: The researcher should confirm who can explain and maintain pause rules, check J1's understanding, and separately record any later decision and the actual reason.
Three reasons to pause a journey-mapping workshop
Use a journey map when the handoff between touchpoints matters to one person’s task. Begin by naming that person or a clearly researched group, the goal and the start and end boundaries. Keep the customer’s actions visible even when the organization changes departments. A department handoff matters because of what the person experiences, not because a box needs to appear on the chart.
Pause if the team is combining different people into a single apparently observed path. Separate their records before synthesizing a pattern. Pause if the map shows only the company’s preferred sequence; label it as a proposed future experience and obtain current evidence. Pause if every stage has an invented feeling. A missing emotional record should remain unknown, not become “frustrated” because a long wait sounds frustrating.
Keep source IDs beside actions and statements. An observed screen label, a person’s report of uncertainty and a team’s explanation of a backend failure are three different things. The map can hold all three only if their status is clear. One journey cannot establish a population rate, and an unobserved final stage should not be completed with an imagined purchase or satisfied customer.
Choose the map that answers the current question
The useful output depends on what is missing. You may need a current customer account, an internal operational path or a proposed design. Keep these as connected but separately labeled artifacts rather than blending them into a story that looks fully observed.
| Method | Material needed | Output |
|---|---|---|
| Customer journey map | A person, task, touchpoints and attributed records | Experience across stages with evidence gaps |
| Business process flowchart | Actual roles, decisions and exception paths | How the organization routes the work |
| Storyboard | A proposed situation and sequence | A design story to discuss and test |
| Stakeholder analysis | Affected roles, authority and contact records | Whose input or decision is still needed |
Worked case: a repair request with no confirmed visit
This is a separate fictional repair-service case, not J1’s coffee-subscription journey above. Tenant J2 wants to know when a repair visit will happen. The invented packet has four records. J2-O1 shows a form receipt at 09:00 on day one. J2-O2 shows the ticket status “assigned” at 12:00, with no appointment displayed. In interview J2-I1 at 15:00, J2 says, “I still do not know whether someone will come today.” J2-O3 records a 16:00 support call offering a day-two 10:00–12:00 slot; acceptance is not recorded.
The map starts with submission and ends at the proposed visit. No technician arrival, completed repair or satisfaction result is supplied. The time labels describe this invented sequence only. Do not combine them with a service-level promise, a waiting-time average or the coffee example’s stages. The interview supports J2’s uncertainty at that moment; it does not establish anger throughout the journey.
Arrange the records in time, then add interpretation in a separate column. The gap is between a status label and the appointment information J2 needs. The material does not establish why the information was absent or whether an internal dispatch task failed. Those are operational questions for a different record set.
| Stage and source | Observed or reported | Unknown / proposed check |
|---|---|---|
| Submit: J2-O1, day 1 09:00 | Receipt displayed | Whether the receipt explained appointment timing |
| Check: J2-O2, day 1 12:00 | “Assigned,” no appointment displayed | What the label means and who maintains it |
| Ask: J2-I1 and J2-O3 | Uncertainty reported; next-day slot offered | Whether J2 accepted and understood the offer |
| Visit: after the call | No observation supplied | Arrival, repair outcome and J2’s later account |
Turn an information gap into a reviewable handoff
Conclude narrowly: “For J2, the displayed status did not provide a confirmed visit time; a later call offered a slot whose acceptance remains unknown.” Do not conclude that dispatch caused all complaints or that the offered slot solved the problem. First ask support and operations to confirm the meaning of the status, the appointment process and who can maintain accurate wording. Ownership and permission to change the interface are still to be agreed.
Then propose checking the wording with the person: can they distinguish a received request, an assigned technician, an offered slot and a confirmed appointment? These are suggested checks, not claims that the checks have happened. A clearer label must reflect the actual service state; writing “confirmed” cannot create a booking. Keep future design ideas on a separate map with their assumptions.
At review, append the actual reply, acceptance status and any later visit record. Preserve the first map so a changed explanation remains traceable. Check whether the person understood the information and whether the service occurred as separate outcomes. If investigating other tenants, define the sample and record each path before making a group claim; repeated calls or repeated status checks are not automatically different people.
Check your work
- Each stage links touchpoints and actions to evidence, or explicitly marks an unobserved stage.
- Self-reported experience, observed behavior and team interpretation remain distinct.
- Opportunities have not become achieved improvements; handoff ownership retains its actual confirmation status.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.