A fair next step after a failed return pickup.

A failed pickup should not erase the story.

Return Recovery is an in-app recovery concept for customers whose timely return requests become stuck after a pickup is marked unsuccessful or disputed. The proposed experience keeps the original request, pickup history, customer explanation and support decision together. Its purpose is to make the next action visible without forcing the customer to start the story again.

The project combines secondary research, a competitor check, journey mapping, a service blueprint, MVP prioritisation, a PRD and a Figma prototype. It is a focused addition to a marketplace returns system. It does not automatically approve refunds, extend return windows or accept every dispute as valid.

The uncertainty begins after the status changes.

The target moment is specific: a customer opens Return Details and sees an unsuccessful pickup reason they believe is wrong, such as being marked unavailable despite waiting for collection. They may then move through generic support channels without a shared view of the original request, previous attempts or the decision that comes next.

The customer wants to preserve the context of a return requested on time and understand what happens next. Support needs the same history alongside the customer explanation and applicable terms. The design problem therefore includes both the visible customer journey and the operational information required to review a dispute fairly.

Public cases reveal a plausible failure point.

The supplied study reviews two National Consumer Helpline cases, marketplace support flows and published returns guidance. One case described a return placed on hold after collection; another described repeated return requests without collection. These examples informed the recovery scenario, but do not establish how frequently pickup disputes occur.

The competitor review contrasts existing return tracking and support escalation with a dedicated case that carries the disputed status and its history. This is the opportunity proposed by the study, not a claim that every marketplace lacks dispute handling. Primary customer research and internal operational data would still be needed to validate the scope.

Make the smallest complete recovery loop.

The must-have scope includes return and attempt history, a way to report the issue, a case reference, an under-review status, support context and a visible decision. Optional evidence attachments and status notifications support that flow. Live pickup tracking and automatic prioritisation of repeat failures can wait because they do not establish the core review-and-resolution loop.

Automatic dispute decisions and fraud detection are outside the MVP. They would require reliable historical data and policy validation that this concept does not have. A dispute triggers review, and the interface must avoid presenting submission as a promise of a refund or an extension.

Keep every attempt in the same case.

The prototype demonstrates an unsuccessful pickup, issue submission, an under-review state and a newly scheduled pickup. The broader design also allows support to request more information or decline with a policy-based reason. The customer should see the submitted explanation and a clear next update while the review is pending.

Behind those screens, the service blueprint connects order and return IDs, logistics events, customer submissions, policy context and notifications. If a rescheduled pickup fails again, the new attempt belongs to the existing case. That continuity is central to the concept: adding another help button would not by itself prevent repeated explanations.

Measure resolution without losing fairness.

The primary proposed metric is median case resolution time, from issue submission to a final recorded decision. Supporting measures include recovery-case completion, repeat support contact and successful rescheduled pickups. The study explicitly avoids baseline or improvement claims because internal marketplace data is unavailable.

A pilot would first establish that baseline and pair speed with guardrails: incorrect approvals, support handling time, repeated pickup failures and dispute abandonment. Customer and support sessions should also check whether the recorded reason, pending state and final decision are understood as intended.

Recovery is a service, not just a screen.

The key learning is that a missed pickup becomes harder when context and confidence disappear together. Next, I would validate whether one visible history reduces repeat contact and helps support make consistent decisions. I would also test whether rescheduling resolves the underlying issue, rather than merely beginning another failure loop.