Overview
Returns and reshipments are usually treated as an operational cost to absorb. In this project I treated them as evidence: a record of the moments where the customer experience breaks down. By analysing returns over most of a year, I traced recurring problems back to points in the ordering journey that a product team can change.
This is a public, anonymised version of the case. It contains no internal figures, customer names or screenshots of internal systems.
The Problem
Every return creates freight costs and manual work. The reasons behind returns, however, were spread across free-text notes and different steps of the process. Without a shared picture of why parcels came back, it was hard to tell one-off incidents from structural problems — and therefore hard to decide where to act.
Which returns are preventable, and what would it take to prevent them?
My Role
Working in operations and process improvement, I led this analysis end to end: I structured the data, defined the classification, mapped the workflows, built the simulation and turned the findings into recommendations. My day-to-day work in fulfilment and back-office coordination gave me first-hand insight into where delivery problems actually surface.
Approach
- Data analysis. Consolidated returns and freight-cost records from January to November 2026.
- Classification. Built a root-cause taxonomy and a local, AI-assisted process to classify free-text return reasons consistently.
- Workflow mapping. Mapped the end-to-end returns and reshipment workflows to see where each problem originates and who has to fix it.
- Scenario simulation. Built a simulator to estimate the effect of address validation and checkout improvements before anyone changes the product.
- Returns data January to November 2026
- Classify Root causes, AI-assisted
- Map workflows Returns and reshipment
- Size the opportunity Preventable costs
- Simulate Checkout scenarios
Evidence & Insights
- A significant share of freight costs traced back to address corrections — orders that could not be delivered as entered and had to be fixed and reshipped.
- These were not random operational failures. They pointed upstream, to the moment in checkout where the address is entered.
- Order The customer places an order
- Checkout The address is entered Where it starts
- Fulfilment The order is produced and shipped
- Delivery The parcel cannot be delivered
- Return Corrected and reshipped
- Because address errors can be prevented at the source, they are a cost opportunity rather than a fixed cost of doing business.
- Free-text return reasons were not comparable as they were. A shared classification was a precondition for any decision.
Decisions & Experiments
- Sized the preventable-cost opportunity linked to address corrections. Done
- Modelled address validation and checkout improvements in a scenario simulator. Simulated
- Recommended address validation and checkout changes as product opportunities. Proposed
No product change has been implemented as part of this work. The figures behind the sizing and the simulation remain internal.
Outcomes & Learnings
The work produced a shared classification of returns, a map of the returns and reshipment workflows, and a sized, prioritised opportunity that connects an operational cost to a product decision.
- Operational data is user research. Every return is the trace of a customer who got stuck somewhere.
- Classification is a product decision too. How you categorise problems determines what you are able to see.
- Simulation makes trade-offs discussable before anyone commits engineering time.
Next Steps
- Validate the simulated effect with a small, measurable experiment in checkout.
- Define success metrics together with the teams that own checkout and fulfilment.
- Extend the classification so new returns are tagged consistently from the start.