Journey Mapping
Part of Customer journey mapping
Identifying handoffs that create customer effort
Find the transfers in a customer journey that lead to repeated details, chasing and lost progress, and record what still needs checking.
A handoff may create customer effort when a request moves between teams, systems or channels and the person must repeat details, wait without an update, chase progress or work out the next step. Mark each transfer on the journey map beside its customer consequence. A transfer alone is not evidence of a problem: check what happened to the person’s progress and whether any extra step was necessary.
Mark the join, not just the teams
Take a bounded task, such as requesting a replacement for an item that arrived damaged. Trace it from the first attempt to an outcome the customer can confirm. Mark where the request leaves a form for a service queue, moves to a specialist or returns to the customer for more information. This is an illustrative case, not an audited service.
At each join, record what the customer was trying to achieve, where the request came from, who or what received it, what information accompanied it and what the customer had to do next. Include transfers the customer cannot see. An internal move may matter if it leads to a missed update or a second request for the same details.
Internal Transfers: When They Add Value vs. Create Effort
- Pros: Ensures expertise match
- Specialist handling complex issues improves resolution quality
- Cons: Causes repeated effort
- Customer must re-explain, upload documents, wait without update
- Pros: Clear handoff documentation
- Summary of prior context helps prevent gaps
- Cons: Lack of shared systems
- Teams can’t access previous interactions; customer bears burden
Look for evidence of extra work
A map may show a customer re-entering an order number, explaining damage twice, uploading the same photograph again or contacting support to learn who owns the case. Record the repeated action and its context. Some verification or additional evidence may be necessary; check its purpose before treating it as avoidable.
Put the customer’s timeline beside the available case record. The record may show when queues changed and what staff could see, while the customer can describe work outside those systems. Neither view alone necessarily explains the cause. If an agent asks for details already supplied, check whether the receiving team could access and use them and whether a fresh check was required.
A small handoff log can focus the investigation:
| Join | Possible customer consequence | Question to check |
|---|---|---|
| Form to service team | No acknowledgement received | Did the request arrive, and was a response promised? |
| Service team to specialist | Customer repeats the issue | What summary did the specialist receive? |
| Specialist to customer | Customer chases a decision | Who owned the next update, and when was it due? |
The rows are illustrative possibilities, not findings about a particular service.
Customer Effort Triggers at Handoffs
- Repeated ActionRe-entering order number, explaining damage twice, uploading same photo again
- Chasing ProgressContacting support to learn who owns the case or when a decision is due
- Missing AcknowledgementNo confirmation the request arrived or response promised
Separate the symptom from the cause
“Customer called again” is an event. Possible explanations include missing status information, an overdue decision or an answer that did not solve the original problem. Check the case and customer account before choosing one. Map returns to an earlier team as well as forward transfers; a loop may point to unclear ownership.
Finish by marking each handoff as supported by evidence, uncertain or needing operational investigation. Record the customer consequence and who can investigate it. The map shows where effort may occur. Deciding whether routing, information sharing or a service rule should change requires a closer look at the process and a later check of the customer outcome.
Investigating Handoffs in a Customer Journey
- Trace the request from start to confirmed outcomeBounded task: e.g., replacement for damaged item
- Mark each transfer point (join)Form → service team, service team → specialist, specialist → customer
- Record what the customer had to do nextRepeat details, chase updates, provide more info
- Check case records and customer timelineCompare system logs with customer experience
- Distinguish symptom from causee.g., 'called again' may mean missing status or unclear ownership
