The Journey Works for New Users but Fails on Return

What the journey problem looks like and why it affects the business

A journey that works for a first visit can fail when a person returns with saved work, a changed need, a different device or a new question. Treating the return as fresh acquisition hides memory, state, support and trust conditions.

Separate what the returning user expects to remember, what state may persist, what has changed and how recovery works when identity or context is uncertain.

This guide is for product leads, customer-experience leads or service owners. Budget approval sits with the product or customer executive accountable for retention, repeat completion, support effort, trust and the cost of treating returning users as new.

The named owner holds decision authority; specialists contribute evidence within their remit, but contribution does not replace accountable ownership.

Define the task and continuity returning users need. Customer-identity reconciliation and analytics implementation belong to their specialist guides.

Agree the user outcome, evidence and decision authority before choosing an intervention. Technology or AI cannot replace that work. Treat the handoff as a user-facing interface: define what must survive, who accepts it, what a user can see, and how a person recovers when the interface fails.

What to expect in the working pack

Use the working pack as you follow the guide. Start with the charter, assign stable evidence IDs and update decision and review fields at each checkpoint. Its entries need supporting sources; the workbook alone is not evidence:

• Start here: Read the decision sequence, evidence labels, required inputs and stop conditions before changing the handoff.
• Journey charter: Record the user outcome, start, end, included routes, exclusions, consequence and authority.
• Journey map: Connect user tasks to context, channels, systems, handoffs, owners and unresolved questions.
• Evidence register: Separate observed facts and participant statements from interpretations, inferences and unknowns.
• Friction and failure log: Record symptoms, affected routes, severity, recurrence, consequences and competing explanations.
• Intervention and acceptance: Link each proposed change to an owner, dependency, test, guardrail, rollback and decision.
• Outcome and recovery: Observe task and value outcomes alongside assistance, interruption, recovery, exceptions and harm.
• Review and change log: Govern versions, evidence changes, approvals, reopen triggers, replacement and retirement.

Use the same evidence, issue and intervention IDs across sheets so a reviewer can move from a claim to its source, consequence, proposed change and decision. Seed rows are illustrative and must be replaced or confirmed with authorised organisation-specific evidence. Do not enter participant names, contact details, recordings, free-text case notes or unnecessary personal information. Store sensitive evidence in a controlled repository and record only a permitted reference. The workbook does not create consent or lawful authority.

What evidence distinguishes the real cause

The visible symptom does not establish the cause. Build one dated evidence set before changing copy, forms, workflow, systems, provider configuration or channel policy.

Label every material statement. Use VERIFIED only where a current, attributable source supports the statement and its permitted use. Use OBSERVED for a behaviour, event or participant statement without turning it into a population claim. Use INFERRED where evidence supports but does not prove the explanation. Use PROPOSED for a future design or decision. Use UNKNOWN where evidence is missing. Use REQUIRES VALIDATION where the claim must be tested before it may govern investment or public copy.

Three competing explanations deserve deliberate testing: Returning users are routed through first-use steps that contradict expectation. Saved state is absent, stale or unavailable under device or support conditions. A changed need is mistaken for an identity or interface problem. Record contrary cases as carefully as confirming cases. A diagram, analytics trend, ticket count or stakeholder consensus can indicate where to investigate, but none proves why the condition exists. Preserve the distinction between a user statement, an observed event, an operational interpretation and a causal claim.

The research standard should cover the whole problem and the routes people actually use. GOV.UK Service Manual: Researching user experiences provides the general research frame, while GOV.UK Service Standard: Provide a joined-up experience across channels helps identify the user task and context beyond the organisation's visible touchpoint. GOV.UK Service Standard: Make sure everyone can use the service is relevant to joined-up handoffs and route continuity. Where the journey crosses channels or teams, preserve those interfaces instead of hiding them inside one stage.

Accessibility is part of journey evidence and acceptance, not a final compliance check. The Web Content Accessibility Guidelines 2.2 include requirements relevant to complete processes, errors, focus, status, interruptions and accessible authentication. Test with disabled users and people who need support where the decision may affect them. Check keyboard operation, focus order, error identification, status announcements, contrast, zoom and time limits where relevant. Do not claim universal access from an automated check alone.

Personal information must be handled under the organisation's approved privacy and research process. POPIA, the Protection of Personal Information Act, is the primary South African statutory source. This guide is not legal advice; the Information Officer or qualified adviser retains legal authority. Record purpose, minimum necessary fields, permitted use, access, retention, deletion, correction and withdrawal arrangements before collecting identifiable evidence. Do not paste personal data into AI tools or private packs unless an approved environment and lawful authority exist.

Stop and re-charter if the decision is unnamed, the population cannot be bounded, the evidence cannot be used lawfully, assisted, interrupted or excluded users cannot be represented, the owner lacks authority, the receiving team rejects the handoff, or the proposed work crosses the scope boundary. Record UNKNOWN when evidence is missing.

How to fix it step by step

Step 1: Define the journey decision

Open Start here and Journey charter. State the decision as a choice an authorised person must make, not an ambition such as improve the experience. Name the affected population, route, start condition, end condition, economic consequence, owner and decision date. Then describe the user's observable task and what counts as progress. If the request contains several decisions, split them into separate records and keep this guide bounded. Do not proceed when the owner cannot pause, reject or reverse the proposed change.

Use the first step to turn a vague handoff complaint into an accountable decision. A receipt, click, ticket or internal status is not automatically user progress. Ask which user state must change and which organisational consequence makes the decision worth making. Record the alternative definitions in the Evidence register and mark them INFERRED or REQUIRES VALIDATION until authority resolves them.

Step 2: Collect and label the evidence

Create E01–E05 records before collecting conclusions. For every source record its date, population, route, context, limitation, confidence, permitted use and controlled reference. Combine user research, observation, operational records, analytics and support evidence only when their definitions and time windows are compatible. Keep participant names, contact details, recordings and free-text case notes in an approved repository; the pack stores minimised references only.

Include successful, unsuccessful, assisted, interrupted, exception and returning routes. An observed repetition, error or delay can be VERIFIED as an event without proving its cause or prevalence. Use OBSERVED for what happened, INFERRED for a supported explanation, UNKNOWN for missing evidence and REQUIRES VALIDATION for a claim that must be tested before investment or public copy.

Step 3: Set the population, routes and observation window

Set the boundary in Journey charter using conditions rather than channel names. For example, start when the user needs to transfer a task and end when the receiving decision is accepted or the user has a safe recovery route. Include the primary digital route, assisted route, interrupted route, exception route and non-completion route when evidence shows they matter. State material exclusions and why they are outside the decision; never let a neat map imply universal coverage.

In Journey map, represent a stage as an observable change in user task, value, risk or decision. Keep internal systems and organisational statuses in their own columns. For each transition capture entry condition, user task, context, channel, system, handoff, receiving owner, exit condition and evidence ID. A channel switch or system boundary is an interface to test, not a reason to replace the user's task with an internal process.

Step 4: Map tasks, handoffs and possible causes

Describe symptoms before explaining them. In Friction and failure log record the affected route, severity, recurrence, consequence, evidence ID and at least one competing explanation. A repeated field may be necessary to confirm a changed need; an error may reflect eligibility, inaccessible interaction, ownership or upstream promise. Ask what evidence would disconfirm the preferred cause. Record contrary cases and unknown prevalence instead of averaging them away.

Use the hypotheses in this guide as prompts, not findings. Compare what users report with what the operation records and what analytics can actually observe. If an issue is mainly a full system, identity, CRM, policy or search problem, follow the adjacent route and stop this decision at its handoff boundary. That protects the validity of both the local diagnosis and the larger programme.

Step 5: Check the business consequences and competing causes

Connect the handoff to a business decision without inventing a forecast. Quantify revenue, cost, delay, risk, retention or service demand only when a defensible source supports the definition and period. Otherwise record the consequence as UNKNOWN or REQUIRES VALIDATION. Ask whether the proposed change improves value for the user while protecting accessibility, privacy, service capacity, quality and excluded routes. The economic buyer owns the consequence, but specialists own evidence within their authority.

Use Intervention and acceptance to assign one accountable owner, contributors, dependencies, receiving acceptance and decision authority. A functional contributor is not automatically the journey owner. Record who may pause, reject, rollback or escalate. If the owner lacks access or authority, record that governance constraint and stop before implementation. The paid-assessment route is appropriate when the issue crosses budgets, systems or evidence sources and cannot be resolved safely in this bounded guide.

Step 6: Name owners, escalation and recovery routes

Write the acceptance test before making a change. For this guide the minimum condition is: A returning user can identify and resume the permitted task, understand changed conditions, correct or discard saved state and obtain assisted recovery when identity or context is uncertain. Add guardrails for privacy, accessibility, support demand, quality, security, duplicate action, state expiry or excluded routes where relevant. Define the observation window, sample, evidence sources, receiving team's acceptance, exception route, rollback and human approver. A proposed design is PROPOSED until observed evidence shows whether it worked.

Test the negative case deliberately: A convenience feature restores stale or wrong state, causing a consequential action, privacy exposure or loss of trust that fresh start would avoid. Include assisted and interrupted users, people who use keyboard or screen readers, users who change their mind, users who cannot provide optional information and users who need support. Do not claim universal access from automated checks. Retain a safe fallback when the primary route fails and make escalation usable before harm or repeated effort occurs.

Step 7: Agree acceptance, guardrails and rollback tests

Run the evidence chain after the intervention: recheck the charter boundary; sample Journey map IDs back to Evidence register; confirm high-severity issues have owners; execute acceptance, guardrail, negative-case and rollback tests; observe task completion, first value, assistance, recovery, exceptions and harm. Reconcile event data with qualitative evidence and operational capacity. A local metric rising is not proof of improved journey value if the receiving decision, support burden or excluded route worsened.

Record the human decision as proceed, adapt, pause, stop or investigate. Keep outcome evidence separate from approval. If a test cannot be run, record the limitation and do not promote PROPOSED to VERIFIED. If a provider, policy, channel or form changes during observation, mark the result non-comparable and reopen the charter or review window.

For this handoff decision, make the trade-off explicit between returning task and saved state: state who gains, who bears additional effort or risk, which guardrail protects affected routes, and what evidence would make the owner pause, adapt or reverse. Record it in Intervention and acceptance and verify it in Outcome and recovery; a local improvement is not a success if it shifts burden to an assisted, interrupted or excluded route.

Step 8: Record the decision and review triggers

Record the decision and review trigger in Review and change log. State the evidence change, version, approver, effective date, next review, replacement or retirement condition and the event that would reopen the decision. Review after a material offer, channel, system, provider, policy, staffing, population or privacy change; after recurring exceptions; when evidence becomes stale; or when acceptance or guardrails change.

Maintain the three profile-specific prevention controls as standing checks. Keep the workbook private and controlled until a separate publication decision exists. The guide body and pack are operational aids, not legal advice, a consent record, a public case study or proof of Abrasim client results. Human owners remain responsible for research, accessibility, privacy, commercial and operational decisions.

Worked example

A hypothetical booking service returns a customer to an expired itinerary on another device. Research shows the user needs to change dates, not repeat booking. The team defines permitted state, shows its age, allows correction and offers support when it cannot be safely restored.

This is a hypothetical teaching example, not an Abrasim client result and not evidence of a guaranteed outcome. Its purpose is to show the decision structure: identify the user's task, separate observation from interpretation, preserve assisted and interrupted routes, assign authority, test the change across the handoff and record what would reverse the decision. Replace the example with authorised local evidence before making an organisational decision.

How to verify the journey change

Verification asks whether the decision changed the user outcome under the stated conditions, not whether the map or system was completed. Review the workbook as one connected evidence chain:

1. Recheck the population, routes, start, end and exclusions in Journey charter.
2. Sample evidence IDs from Journey map back to the Evidence register and controlled sources.
3. Confirm that high-severity items in Friction and failure log have an owner, receiving acceptance and disposition.
4. Execute acceptance, accessibility, privacy, negative-case, exception and rollback tests in Intervention and acceptance.
5. Observe task outcome, first value, assistance, interruption, recovery, exceptions and harm in Outcome and recovery for the agreed window.
6. Reconcile user evidence, operational records, analytics and support demand; record limitations and contrary evidence.
7. Ask the authorised owner to decide proceed, adapt, pause, stop or investigate.
8. Record the decision, evidence change and reopen trigger in Review and change log.

Verification is incomplete when only the easiest route was tested, personal data was used outside permitted purpose, accessibility was checked only by automation, a downstream team was not involved, the response promise exceeds capacity, or the observation window ends before value or recovery can be seen. A conversion or completion event is only one input; it does not prove continuity, quality, lawful use or user value.

Use this evidence with AI safely

AI can help organise authorised evidence, identify contradictions, compare route descriptions and draft questions. It must not invent missing evidence, infer sensitive attributes, make the final decision, issue legal conclusions, approve accessibility, or receive personal or confidential data outside an approved environment. Remove or replace identifiers and use controlled references.

Copy and adapt this prompt:

Role: Journey handoff evidence reviewer. Decision: Distinguish memory, identity, state, changed need and support conditions. Scope: The returning-user task and continuity requirement; identity reconciliation and analytics implementation transfer to their specialist guides. Evidence questions: E01: What evidence establishes the returning task | E02: What evidence establishes memory and expectation | E03: What evidence establishes saved state | E04: What evidence establishes changed need | E05: What evidence establishes recovery condition. Competing explanations: Returning users are routed through first-use steps that contradict expectation | Saved state is absent, stale or unavailable under device or support conditions | A changed need is mistaken for an identity or interface problem. Acceptance, privacy and accessibility guardrails: A returning user can identify and resume the permitted task, understand changed conditions, correct or discard saved state and obtain assisted recovery when identity or context is uncertain. Use only authorised, minimised summaries with evidence IDs and labels. Separate VERIFIED, OBSERVED, INFERRED, PROPOSED, UNKNOWN and REQUIRES VALIDATION; cite the supplied ID for every material statement. Identify contradictions, missing routes, unsupported causal claims, handoff risks and the smallest recovery test. Do not invent users, prevalence, outcomes or legal conclusions. Return an evidence table, risks, questions, decision options, recovery tests and human approvals required.

Review output against source records. If it cannot cite the supplied evidence ID for a statement, treat that statement as REQUIRES VALIDATION. Human owners retain responsibility for research, privacy, accessibility, commercial and operational decisions.

How to keep the problem from returning

Use these three standing controls:

• Review returns after offer, policy, device, identity or state-retention changes.
• Test fresh, returning, interrupted, assisted and changed-need routes separately.
• Make state expiry, correction, deletion and support recovery visible and owned.

Review the journey after a material offer, channel, system, provider, policy, operating-model, staffing or population change; after recurring exceptions; when evidence becomes stale; or when acceptance or guardrails change. Do not update the handoff diagram silently. Update evidence, decision, privacy controls and change log together. Assign a review owner who can convene contributors, access evidence, preserve dissent and obtain an authorised decision.

Continue with the preceding guide when earlier boundary work is unresolved, then use the next guide when that is the next question you need to answer. Use customer identity fragmented devices systems when the adjacent problem owns the wider diagnosis: The analytics guide owns identity reconciliation for measurement; this guide owns the returning user's task, state and recovery.

If the issue crosses teams, budgets, systems or evidence sources and cannot be resolved safely within the guide, Diagnose the returning-user journey break. An assessment should first agree the decision, evidence access and authority. Technology choices follow the findings.

Primary sources used

Source cutoff: 2 September 2026. Review by 2 March 2027, or sooner after a material change. These dates apply to the external references below; local organisational evidence still needs its own date and limitation.

• GOV.UK Service Manual: Researching user experiences
• GOV.UK Service Standard: Provide a joined-up experience across channels
• GOV.UK Service Standard: Make sure everyone can use the service
• W3C Web Content Accessibility Guidelines (WCAG) 2.2
• South African Government: Protection of Personal Information Act