A customer journey map and a process map can describe the same service while telling very different truths.
The process map asks:
How does work move through the organisation?
The journey map asks:
How does a person pursue a goal and experience progress, uncertainty and effort over time?
Neither view is universally better. Problems arise when a team uses one and assumes it has answered the other.
The unit of analysis is different
A process map is organised around work:
- receive request;
- validate data;
- approve;
- schedule;
- complete;
- close.
A journey map is organised around customer progress:
- recognise a need;
- understand options;
- decide whether to trust the offer;
- begin;
- wait and stay informed;
- use the result;
- recover or seek help.
Department boundaries may be invisible to the customer until a hand-off creates repetition or delay.
What each map should contain
| View | Primary content | Strong use |
|---|---|---|
| Customer journey map | Goal, stages, actions, touchpoints, questions, emotion, effort and evidence | Identify end-to-end experience problems |
| Process map | Activities, decisions, sequence, roles, inputs and outputs | Analyse workflow and control |
| Service blueprint | Customer actions plus frontstage, backstage, systems and support processes | Connect experience failures to delivery design |
If the problem is “customers do not know who must act next,” begin with the journey. If the problem is “approval records are duplicated between systems,” begin with the process or blueprint.
A journey is not a funnel
A funnel aggregates movement:
- visits;
- sign-ups;
- activations;
- renewals.
A journey explains what happens and why at the level of a defined actor and scenario. Funnel data can identify where loss occurs. Interviews, observation and service evidence help explain the experience around that loss.
Use both, but do not substitute one for the other.
A journey is not an organisation chart
Weak stages:
Marketing → Sales → Operations → Support
Customer-centred stages:
Discover → Evaluate → Commit → Prepare → Use → Resolve
The second set can reveal that the customer repeatedly explains the same need across three internal teams.
Current and future states require different evidence
A current-state map represents the best available account of what people experience now. Claims should be linked to:
- observed behaviour;
- interview events;
- analytics;
- support records;
- operational data;
- explicit assumptions.
A future-state map represents an intended experience. It should contain:
- design hypotheses;
- operational dependencies;
- measures;
- tests.
When teams mix the states, a desired process can be mistaken for reality.
Mini-case: technically fast, experientially slow
An IT support service reports:
- median technical fix time: four hours;
- overall elapsed time: up to two days;
- repeated device questions after channel transfer;
- no visible signal showing whether the customer or support team must act.
The process map shows that every ticket follows the approved workflow. The journey map reveals:
- the customer repeats information;
- responsibility becomes invisible;
- a missed reply creates a long wait;
- closure does not explain what to do next.
The service does not primarily need faster technical work. It needs a clearer hand-off and recovery experience.
When to add a service blueprint
Once the journey exposes a problem, add the delivery layers:
- customer action;
- visible employee or system response;
- backstage work;
- supporting systems;
- policy or rule;
- failure point;
- owner and measure.
For the IT case, the blueprint may show that chat and ticket systems do not share structured device information and that no state represents “waiting for customer.”
The journey identifies the experience problem. The blueprint connects it to a system mechanism.
Choose the smallest useful view
Use a journey map when:
- the experience crosses channels;
- teams optimise locally;
- waiting and uncertainty matter;
- the customer goal starts before first contact;
- a future experience needs design.
Use a process map when:
- sequence, responsibility and control are the main questions;
- variation or rework must be analysed;
- a standard operating procedure is needed;
- inputs and outputs must be verified.
Use a blueprint when the decision requires both perspectives.
Practical next step
Take one service problem and write it twice:
- as an internal process question;
- as a customer-progress question.
Choose the view that better matches the decision. If both are necessary, build the customer journey first and add backstage layers only where they explain important moments.
The same service in three maps: a worked example
Take the IT support scenario above. The rows below are a proposed mapping exercise, not evidence of a measured service improvement.
| Moment | Journey map: customer progress | Process map: internal sequence | Blueprint: connection to delivery |
|---|---|---|---|
| Request help | “Has someone understood my problem?” | Receive request and validate required fields | Visible acknowledgment; backstage creation of the ticket and routing owner |
| Transfer channel | “Why do I have to repeat my device details?” | Transfer the ticket to a specialist | Data passed between chat and ticket systems; explicit acknowledgment by the receiving owner |
| Wait for an answer | “Is the next action mine or yours?” | Request information, wait and resume | Visible waiting status; responsibility for reminders and a recovery route |
| Close the issue | “What should I do if it happens again?” | Verify resolution and close the ticket | Customer confirmation plus an accessible follow-up instruction |
Which map should you start with?
Start with the journey when the unresolved question concerns customer progress, effort or uncertainty. Start with a process map when it concerns sequence, responsibilities or rework. Add a blueprint when the decision needs a trace from an experience problem to the people, systems and policies that produce it.
How to test the proposed change
Choose a small set of real tickets using the same inclusion rule. Check whether the waiting owner is clear, device information survives transfer and closure explains the next step. Record exceptions and elapsed waiting time before and after the test; do not infer success solely from a diagram or a faster technical-fix metric. Any sample size must fit the decision and available evidence.
Use Customer Journey Mapping to build the experience view, BPMN for explicit events and exception routes, and Service Blueprint to connect frontstage and backstage. If the main question is delay and rework across the whole flow, use Value Stream Mapping.
References
- Service Design Tools. “Journey Map.” Method overview (opens in a new tab).
- Nielsen Norman Group. “Customer Journey Map Template.” Template (opens in a new tab).
Continue with the tool
Use the Customer Journey Mapping guide to define the actor, evidence spine, critical moments and improvement measures.