Actions

Customer Journey Mapping

Revision as of 00:37, 29 October 2026 by User (talk | contribs) (Created page with "'''Customer journey mapping''' ('''CJM''') is a research and design method for documenting how a defined customer or user experiences the steps involved in achieving a goal. I...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Customer journey mapping (CJM) is a research and design method for documenting how a defined customer or user experiences the steps involved in achieving a goal. It brings together actions, interactions, expectations, difficulties, and reported thoughts or feelings across a bounded scenario. The resulting customer journey map makes that experience visible so teams can investigate barriers, coordinate responsibilities, and identify opportunities for improvement.[1]

The activity differs from its output: mapping is the work of researching, interpreting, and revising the journey; the map is the representation produced. A useful map explains the customer's perspective rather than merely listing an organization's departments, screens, or sales stages. It can include digital and physical channels, waiting periods, repeated steps, and interactions with other organizations.[2]

Customer journey mapping supports customer experience management, service design, and product improvement. Its scope can include purchasing, onboarding, obtaining support, renewing a service, or leaving it. The method is also applicable to public services, where the person seeking an outcome may be a resident or service user rather than a purchaser.[3]

Purpose and scope

Journey mapping addresses the gap between the way an organization delivers separate interactions and the way a customer experiences the overall task. An application may work correctly while the wider journey fails because instructions are inconsistent, information must be resubmitted, or responsibility disappears during a handoff. Looking across the journey makes these connections available for investigation.[4]

The scope identifies whose experience is represented, the goal, the triggering situation, and the start and end points. A map of an administrator activating a software service answers a different question from a map of an employee using that service. Combining these perspectives indiscriminately can conceal important differences. Digital NSW recommends focusing on a defined user and goal, rather than trying to represent an entire service without boundaries.[2]

A journey may branch, pause, move between channels, or end without a purchase. Stages such as awareness, consideration, purchase, and retention can be useful for some commercial journeys, but they are not a mandatory sequence. Stage labels should reflect the activity being studied; a support journey might instead move through recognizing a problem, seeking help, trying a remedy, and confirming recovery.[2][5]

What a customer journey map contains

Formats vary, but maps commonly connect a defined actor and goal with stages, touchpoints, actions, experience evidence, and opportunities. New York State's customer-experience guidance identifies stages, touchpoints, emotions, pain points, and goals as typical elements.[6]

Element Question answered
Customer or user perspective Whose experience is being represented, and in what situation?
Goal and expectations What is the person trying to accomplish, and what do they expect?
Stages and actions What happens over time, including waiting, repetition, or abandonment?
Touchpoints and channels Where does an interaction occur, and through which medium?
Experience evidence What do participants report or demonstrate about their thoughts, effort, and feelings?
Barriers and opportunities What obstructs the goal, and which changes merit investigation?
Responsibility and follow-up Which team can investigate or change the relevant part of the experience?

A touchpoint is a particular interaction, such as receiving an activation message. A channel is the medium through which it occurs, such as email. A stage groups related activity, such as account setup. Keeping these levels distinct avoids treating every page view as a separate phase of the journey.[5]

Thoughts and emotions require evidence. A participant's account of confusion can support an observation about that experience; a page-exit event alone cannot establish what the person felt. Emotional curves are qualitative illustrations unless a defined measurement method supports their scale. Research guidance describes asking participants what happened, what they did, and what they thought and felt, rather than supplying those answers for them.[7]

Current-state, future-state, and hypothesis maps

Two separate distinctions affect how a map should be interpreted: the state it describes and the evidence behind it.

A current-state map describes an existing experience. A future-state map depicts a proposed experience and helps teams consider changes. A hypothesis map records assumptions that need investigation, while a research-backed map reflects collected evidence. An assumption-based map can describe either an existing or a proposed journey. A polished visual does not change its evidential status.[8]

Some practitioners also use day-in-the-life maps to examine a person's wider activities and circumstances, including experiences outside the organization's direct interactions. These can reveal context that a narrowly bounded transaction map omits. Such labels describe useful variations rather than a universally standardized taxonomy.[9]

Future-state proposals should retain their assumptions and unresolved dependencies. Agreement on an attractive future journey establishes a design intention; testing and subsequent observation are needed to establish how customers actually experience it.

How customer journey mapping is carried out

Frame the question and involve responsible teams

The team identifies the customer goal, research question, boundaries, and decision the map will support. It also involves people who understand or can change the relevant touchpoints. Nielsen Norman Group's mapping process combines cross-functional participation, existing evidence, hypothesis formation, customer research, and visual synthesis. It treats an internal workshop as a starting point for investigation, not a substitute for customer evidence.[10]

A bounded question such as why newly contracted customers cannot complete activation is more actionable than a request to map the entire customer relationship. The narrower question determines which participants, records, and service teams are relevant.

Gather existing evidence and identify gaps

Existing material may include interviews, surveys, customer support records, complaints, analytics, and earlier research. The team assembles what is known across departments and records unanswered questions. Staff accounts help locate issues, but their interpretation of customer behavior remains distinguishable from direct customer evidence.[10]

Data sources answer different questions. Transaction records may show elapsed time or repeated attempts; interviews can help explain circumstances and expectations. Missing records do not prove that an interaction never happened, particularly when customers use offline channels or switch organizations. The research plan should address these gaps rather than silently connecting incomplete observations.

Research customers and relevant variations

Interviews and observation can reconstruct events and their context. For experiences unfolding over time, diary studies or repeated contact may help capture activity that is difficult to recall in a single interview. Participants should have relevant experience of the scenario being mapped.[7][10]

Recruitment should cover meaningful differences in the user population, including people who need assistance or use assistive technology. Reviewing only successful digital transactions can miss those who could not proceed. GOV.UK research guidance emphasizes actual or likely users and deliberate attention to recruitment bias and accessibility needs; it does not make one participant count suitable for every research question.[11]

Synthesize and validate the map

Researchers arrange observed events into a sequence, identify common stages, and retain significant differences between experiences. Separate maps or explicit branches may be needed when people follow materially different paths. GOV.UK's experience-mapping guidance recommends comparing individual experiences before deciding how many combined maps to create.[12]

Validation checks whether each important interpretation can be traced to evidence, whether contradictions have been retained, and whether the map is understandable to its intended readers. The result may remain provisional where evidence is incomplete. Internal agreement about a map is useful for coordination, but it is not proof that the represented experience is accurate.

Convert findings into improvement work

The team identifies changes to investigate, the people authorized to act, and the evidence needed to assess results. Some issues involve content or interface design; others require changes to policies, staffing, integrations, or responsibilities. Cross-channel problems may therefore require decisions above the level of a single product team.[4]

The map should remain linked to the resulting work rather than becoming a presentation that is never revisited. A service owner can record which findings led to changes, which were deferred, and when new evidence requires the journey to be reassessed.[3]

Relationship to other maps and analytical methods

Related techniques answer different questions. The boundaries are useful, but terminology is not completely uniform across practitioners.

Technique or artifact Principal emphasis Relationship to customer journey mapping
Buyer or user persona A recurring participant perspective, needs, and context Helps define whose journey is being studied; it does not describe the full sequence of experience.
Empathy map What is known about a person's statements, thoughts, feelings, and actions Can inform a journey map without being chronological.
Experience map A broader experience that may extend beyond one provider Often used for wider context; some organizations use the term for service-specific journey maps.
Service blueprint Customer-facing activity and the people, systems, and backstage processes that deliver it Explains operational dependencies associated with a journey.
Customer journey analytics Patterns in recorded behavior and outcomes across interactions Supplies quantitative evidence that can test or refine a map.
Journey orchestration Coordinating actions and responses during customer interactions Uses insights and data to influence the experience rather than simply represent it.

Nielsen Norman Group distinguishes empathy maps, journey maps, experience maps, and service blueprints by their focus. Its blueprint guidance specifically connects customer actions with visible service activity, backstage work, and support processes.[8][13] Journey analytics and orchestration extend measurement and execution; neither makes a research-based map unnecessary or automatically validates one.[14][15]

The labels customer journey and user journey sometimes indicate different organizational scopes, but are also used interchangeably. The actor, goal, and boundaries are more reliable guides to meaning than the label alone.[1] A sales funnel represents progression toward a commercial outcome; a customer journey can also include unsuccessful attempts, service use, complaints, and cancellation. Likewise, an internal workflow describes how work is processed, while a journey map explains how that work is experienced.

Ownership, tools, and research safeguards

Cross-functional ownership matters because an experience can cross several departments without belonging entirely to any one of them. Researchers and designers can maintain the evidence and map; service or product owners make improvement decisions; frontline, technical, and operational teams explain constraints and implement changes. These are possible responsibilities, not a mandatory organizational structure. The responsible sponsor needs sufficient authority to address issues spanning departmental boundaries.[16]

Maps can be maintained in a table, document, collaborative board, or specialist tool. Software helps organize and share information but cannot establish whether the underlying research is sound.[9] Useful document controls include a named owner, scope, research period, version, evidence links, known limitations, and review triggers. A text or tabular equivalent makes essential findings available to readers who cannot use a complex visual.

Research participation and data handling require explicit safeguards. Participants should understand what is collected, how it will be used, whether sessions are recorded, and who will see the results. Shared maps should avoid unnecessary personal identifiers or sensitive account details. GOV.UK's informed-consent guidance describes these responsibilities for user research; applicable organizational and legal requirements still need to be considered in context.[17]

Assessing map quality and improvement outcomes

Map quality and service improvement are separate questions. Quality concerns whether the map has a clear scope, sufficient evidence, credible representation of different experiences, and traceable findings. Outcomes concern whether changes improve the customer's ability to achieve the goal. Creating more maps, running workshops, or securing stakeholder approval does not itself demonstrate a better service.

Measures should follow the service objective and a testable improvement hypothesis. GOV.UK's performance guidance connects service purpose, intended benefits, hypotheses, data sources, and continuing review.[18] Depending on the journey, useful measures may include completion, elapsed time, repeated contacts, avoidable handoffs, and reported effort. Each needs an explicit population, period, and definition.

A customer effort score can contribute feedback, but survey responses and observed task completion answer different questions. A before-and-after improvement can also reflect changes in customer mix or demand. Evaluation should therefore explain alternative influences rather than attributing every favorable change to the mapping exercise.[18]

Illustrative example: enterprise software onboarding

The following example is hypothetical. It illustrates a map structure and proposed improvement decisions, not findings from an actual company.

A software provider wants to understand why a customer's implementation administrator cannot complete the first successful data import. The chosen journey starts when the administrator receives the activation message and ends when imported records are available for use. The buyer's procurement journey and an employee's later use of the software are outside this map's scope.

Stage and customer goal Illustrative experience to investigate Evidence to seek Possible response and owner
Activate: gain access The invitation reaches the purchaser rather than the administrator. Invitation records and interviews with both roles. Confirm implementation contacts before activation; sales operations.
Configure: connect the source system A prerequisite becomes apparent only after setup has started. Onboarding observations, setup guidance, and failed configuration records. Explain and check prerequisites earlier; onboarding and product teams.
Seek help: resolve an import failure The administrator repeats information when the case moves from onboarding to support. Case history, handoff records, and the administrator's account. Preserve relevant context and assign one coordinating owner; support leadership.
Confirm success: verify usable records Technical completion is reported without showing whether the expected records are usable. Reconciliation checks and customer verification. Add a clearly defined verification step; product and customer success teams.

The team would first test whether these suspected barriers occur and for whom. It would record reported frustration only when supported by research, rather than filling an emotional curve from internal assumptions. Confirmed findings could then inform a future-state map and a service blueprint showing the internal changes required.

For an initial improvement, the provider might test the revised invitation and prerequisite checks with a defined customer group. Proposed measures could include time from invitation to verified first import and repeated contacts during that interval. Successful implementation would still need to be observed. The exercise demonstrates how a map can connect a customer goal, evidence gaps, responsible teams, and an evaluation plan without claiming results prematurely.

Limitations and common mistakes

A map is a selective representation. It cannot reproduce every customer's experience or replace direct research, operational analysis, and professional judgment. Its usefulness depends on the question, evidence, and decisions surrounding it.

Assumptions presented as observations make workshop consensus look like customer research. A single average journey can conceal differences between roles, channels, access needs, or unsuccessful attempts. Unsupported emotional detail creates apparent precision about experiences that were never investigated. These problems are addressed by making evidence and uncertainty visible and preserving material variations.[12][16]

Internal-process substitution occurs when a map follows departmental milestones rather than the customer's goal. Implementation without ownership leaves identified problems unresolved. Stale maps continue to describe interactions that have changed. Outcome overclaims confuse a proposed improvement with demonstrated benefit. A maintained map is most useful as a shared basis for investigation and decisions, with change and measurement carried out through the appropriate service-management arrangements.[3]

See also

References

  1. ↑ 1.0 1.1 Gibbons, S. (2018), Journey Mapping 101, Nielsen Norman Group, 9 December, reviewed 15 July 2026. Article. Accessed 28 October 2026.
  2. ↑ 2.0 2.1 2.2 Digital NSW (n.d.), Customer journey mapping, NSW Government, Digital Service Toolkit. Guidance. Accessed 28 October 2026.
  3. ↑ 3.0 3.1 3.2 Local Government Association (n.d.), Customer or user journey mapping, Transformation Capability Framework. Guidance. Accessed 28 October 2026.
  4. ↑ 4.0 4.1 Government Digital Service (n.d.), Map and understand a user's whole problem, GOV.UK Service Manual. Guidance. Accessed 28 October 2026.
  5. ↑ 5.0 5.1 IBM (n.d.), What is a customer journey map? Article. Accessed 28 October 2026.
  6. ↑ New York State (n.d.), Customer Journey Mapping, New York Experience. Guidance. Accessed 28 October 2026.
  7. ↑ 7.0 7.1 Government Digital Service (n.d.), Researching user experiences, GOV.UK Service Manual. Guidance. Accessed 28 October 2026.
  8. ↑ 8.0 8.1 Gibbons, S. (2017), UX Mapping Methods Compared: A Cheat Sheet, Nielsen Norman Group, 5 November. Article. Accessed 28 October 2026.
  9. ↑ 9.0 9.1 Microsoft (n.d.), What is customer journey mapping?, Dynamics 365. Article. Accessed 28 October 2026.
  10. ↑ 10.0 10.1 10.2 Kaplan, K. (2017), The 5 Steps of Successful Customer Journey Mapping, Nielsen Norman Group, 28 May. Article. Accessed 28 October 2026.
  11. ↑ Government Digital Service (n.d.), Finding participants for user research, GOV.UK Service Manual. Guidance. Accessed 28 October 2026.
  12. ↑ 12.0 12.1 Government Digital Service (n.d.), Creating an experience map, GOV.UK Service Manual. Guidance. Accessed 28 October 2026.
  13. ↑ Gibbons, S. (2017), Service Blueprints: Definition, Nielsen Norman Group, 27 August, reviewed 15 July 2026. Article. Accessed 28 October 2026.
  14. ↑ Bunker, A. (2022), A complete guide to customer journey analytics, Qualtrics, 21 March. Article. Accessed 28 October 2026.
  15. ↑ Bunker, A. (2024), Customer journey orchestration, Qualtrics, 9 January. Article. Accessed 28 October 2026.
  16. ↑ 16.0 16.1 Kaplan, K. (2016), When and How to Create Customer Journey Maps, Nielsen Norman Group, 31 July. Article. Accessed 28 October 2026.
  17. ↑ 18.0 18.1 Government Digital Service (n.d.), How to set performance metrics for your service, GOV.UK Service Manual. Guidance. Accessed 28 October 2026.