How to Conduct Customer Journey Research: Agent Satisfaction Doesn't Guarantee Smooth End-to-End Experience

In one return-study, 187 of the 240 people who contacted support expressed satisfaction with the agent, a rate of 77.9%. Looking solely at the touchpoint, support seems to be performing well; however, among the 600 return initiators, only 360 received the correct refund within the promised time, resulting in an end-to-end completion rate of just 60%. Friendly agents are often remediating upstream breakdowns related to return entry points, shipping labels, and refund processing.

The unit of customer journey research is not a department or a page, but the complete process from when a user forms a goal to when they achieve their outcome. It aims to reconstruct what happened at each step, which online and offline channels were crossed, when the first deviation from the normal path occurred, how the user recovered, and whether the correct outcome was ultimately achieved. A 'journey map' with only touchpoint scores and no clear start, end, or event sequence can easily reward the last remediator while allowing the true source of the problem to remain hidden.

Define the Journey in a Single Sentence First, Don't Start from the Org Chart

'Mall after-sales experience' is too broad; 'evaluating agent service' is too narrow. An executable definition would be: 'Eligible purchasers, from the moment they decide to return an item and take their first action, until the item is handed back and the correct amount is refunded to the original payment method.' This needs to specify:

• Target population: Those who purchased and are involved in the return themselves, or those acting on behalf of others;
• Start point: First search for policies, opening the return portal, or contacting support – not when the company's formal system ticket is created;
• End point: Refund received and amount correct, not warehouse sign-off or support closing the ticket;
• Reasonable window: Based on the time promised to the customer at that moment; those still within the window are marked as 'in progress';
• Channels: Web, app, email, phone, courier, and payment institutions are all included;
• Exceptions: Whether out-of-policy cases, partial returns, exchanges, and disputed orders are treated as separate journeys.

GOV.UK's updated 'Solve a whole problem for users' criteria emphasize that services should be organized around user understanding and needs, not siloed by technology, department, or predefined solutions, requiring teams to connect journeys across the organization. Users don't care if the entry point is owned by the product team, labels by logistics, or refunds by finance; they just know they haven't received their money back yet.

A Journey Map is an Evidence Index, Not a Conclusion Drawn from Colorful Sticky Notes

A verifiable journey map should preserve at least six columns for each event:

GOV.UK's experience map guidance recommends first capturing real events from multiple users, then aligning common stages, and mapping separately when different groups have significantly different experiences; its event card method records what happened, who was involved, what was done, thoughts, and feelings. The map should therefore trace back to participant IDs, event sequences, and sources, not fill gaps with team assumptions.

Use 'First Point of Failure' to Distinguish Root Cause from Subsequent Cascades

The same person might not find the entry point, fail to get a label, contact support, repeat their order details, and then experience a delayed refund. If you count by each touchpoint separately, this one person gives four different teams a 'negative mark' without showing where the cascade began. While retaining all events, you can add a 'first point of failure' field: the location where the journey first deviated from the predefined normal path.

The first point of failure is not a final judgment of blame. Difficulty finding the entry could stem from policy wording, search, navigation, or eligibility rules; label failure could stem from third-party APIs. It merely establishes a chronological order for the investigation, helping teams inspect upstream mechanisms first. Causality and responsibility require further validation through logs, observation, and process owners.

600-Person Return Case: Satisfied Agents Mask 240 Instances of Non-Completion as Promised

The following is illustrative hypothetical data and does not represent any panel provider, merchant, or industry benchmark. The study combined people who opened the return portal, attempted to generate a label, or contacted support about a return into the start frame, and supplemented it with off-site intercepts to capture those who 'couldn't find any entry point.' Everyone had exceeded the pre-defined observation window in the scenario, so those still waiting normally were not counted as failures.

The completion rate is 360 ÷ 600 = 60%, with the denominator including those who partially completed or failed after starting. GOV.UK's completion rate guidance also uses all transactions that started as the denominator, including partial and failed ones, and requires defining the journey's start and end first; if you only surveyed those who successfully got a refund, the denominator becomes the successful, making it impossible to see the true completion rate.

240 people contacted support at least once, representing 40% of the sample. Of these, 187 were satisfied with the agent interaction, representing 77.9%; 156 stated they had to re-provide order, product, or label information that already existed in the system, representing 65% of those who contacted. Agents who are polite and eventually provide an explanation can score high, but the repeated information shows broken context, and the 40% support usage suggests the self-service journey is absorbing a large remediation cost.

Reinsert Support Reasons into the First Failure Point to Know What to Change First

The first three rows total 210 people who neither completed on time nor asked for help; an additional 30 who did not meet the deadline did not contact support. If the support dashboard only categorizes tickets, the team would see 72, 78, and 60 service issues; a journey perspective requires the entry team to reduce erroneous entries, logistics to fix label handoffs, refund teams to handle delays, and a cross-channel team to reduce 156 instances of repeated information.

Priorities shouldn't be based on volume alone. Label failures might lead to lost packages, meaning high severity; refund delays are less frequent but tie up funds and damage trust; entry problems might be quickly improved with content changes. It's recommended to log incidence, impact on the final outcome, user effort, recoverability, risk, and owner before deciding the order of experiments.

Four Data Types Each Contribute a Piece; No Single Type Equals the Complete Journey

• Event & business data: Fairly accurate on timing and status, but doesn't reveal user motivation or capture off-system searches and help-seeking;
• Recent surveys: Useful for estimating experiences and segmenting audiences, but susceptible to recall bias, non-response, and self-reporting errors;
• Interviews, diaries, or AI interviews: Can reconstruct narratives, expectations, and cross-channel processes but cannot reliably estimate population proportions from a small number of cases;
• Support & operational records: Reveal issues and resolutions but only cover those who sought help and often categorize problems by internal queues.

A common combination is: first, interview recent experiencers to identify real steps and unusual paths; second, use surveys to estimate the distribution of first failures and outcomes in the target population; third, use event and support data to validate timing and status; finally, run usability or process experiments on high-priority mechanisms. OECD research on service performance notes that satisfaction can summarize part of service performance, but needs additional metrics like access, responsiveness, and quality to target improvements.

Surveys Should Branch Based on Actual Paths, Not Let Non-Experiencers Rate Every Touchpoint

First, confirm a specific, recent journey and its current status; then, let respondents select the actual events and channels that occurred; chronologically probe for the first anomaly, recovery, repeated effort, and final outcome.People who never called support shouldn't rate agents; those who didn't use courier pickup shouldn't rate it. Creating a single satisfaction matrix for all departments invites guesswork and a flood of 'not applicable' responses.

Emotional questions should be tied to events: 'When you saw the label generation failure, which feeling was closest to yours, and why?' Don't ask participants to recall a smooth overall curve from start to finish. For longer journeys, use event cards or short diaries to reduce recall compression and preserve event dates and evidence sources.

If the Start Frame Relies on Systems, the Earliest Failures May Still be Absent

Sampling only from official return tickets will miss those who couldn't find the entry, didn't understand eligibility, or gave up before creating a ticket; sampling only from tickets would treat those willing to seek help as the entire customer base. You can combine on-site search, entry visits, failure events, support reasons, subsequent sampling of purchasers, and off-site intercepts, while acknowledging who remains uncovered. Weighting can adjust for known structural differences but cannot magically include those who dropped out early and were never observed.

The observation window must also be consistent. Asking 'Have you received your refund?' the day after purchase would incorrectly count normal waits as failures; waiting until all slow cases conclude introduces varying recall lengths. Reports can distinguish between completed within the promised time, completed late, still in progress, clear failures, and lost to follow-up, noting the cutoff date.

The Map Must Be Accompanied by a Service Blueprint and an Action Log

An experience map describes what the user sees; a service blueprint further connects front-stage touchpoints, backstage processes, data handoffs, third parties, and responsible parties. Entry issues correspond to content and navigation; label problems connect to logistics interfaces and exception handling; repeated information connects to identity and order context. A map that doesn't feed into an action log is just wall decor.

Each improvement should log: evidence and base rate, hypothesized mechanism, responsible team, planned change, leading indicators, end-to-end outcomes, risks, and review date. For example, label fix success shouldn't be measured only by API success rates but also by whether the first failure rate, help contacts, repeated information, and timely refunds collectively improve. Correlations are just leads for investigation; phased rollouts or randomized experiments provide stronger evidence for the impact of a change.

Panel providers can configure branches for actual experiences, connect to a recent target sample, and use open-ended questions or AI interviews to recover nodal language; if you link data using order and ticket fields, the research team should minimize identifiers, obtain appropriate permissions, and restrict access. Automated summaries must be traceable to event transcripts, not compress stories with different sequences into a single theme.

What Conclusions Are Sufficient to Drive Cross-Team Improvement

This case can be summarized as: 'Among 600 return initiators who had exceeded the observation window, 60% correctly completed within the promised time frame; 40% sought help at least once. Agent satisfaction was 77.9%, but 65% of help-seekers repeated information already in the system. First failures clustered at entry, label, and refund timeout, indicating high agent satisfaction reflects remediation quality, not smooth end-to-end processes. Next steps should validate entry content, label handoff, and cross-channel context separately, using completion rates and first-failure migration as common outcomes.'

It should not be written as: 'Support is the biggest pain point in the journey,' nor can it declare a department as the cause based solely on observational data. Good customer journey research aligns all teams around a single user outcome, rather than handing the most frustrated sticky note to whoever shows up last.

References for End-to-End Journeys, Completion Rates, and Experience Maps

• GOV.UK Service Manual — Creating an experience map
• GOV.UK Service Standard — Solve a whole problem for users
• GOV.UK Service Manual — Measuring completion rate
• GOV.UK Service Manual — Researching user experiences
• OECD — Serving citizens: Measuring the performance of services for a better user experience