A return reason should describe the evidence available, not force every case into one convenient explanation. Separate product condition, suitability, fulfilment and customer-reported reasons, preserve unknowns and allow contributing factors. Analyse units and timing consistently before recommending a product or process change.
Separate the event from the explanation
Define a return at the relevant milestone: requested, authorised, received or inspected. These counts differ when items remain in transit or requests are withdrawn. Record the unit, such as an item or order, and distinguish partial returns. A customer-reported reason is valuable evidence but may not match a later inspection finding. Retain both rather than overwriting one with the other.
Create categories tied to distinct actions. Confirmed damage, wrong item, poor fit and no stated reason suggest different investigations. Avoid labels that imply fault without evidence. An item arriving damaged could involve packaging, transit or pre-existing condition. Keep the observed condition separate from an assigned cause until review supports the attribution. A taxonomy should clarify uncertainty instead of hiding it behind a definitive code.
Design categories that remain useful in real cases
Allow a primary operational reason and additional contributing factors when necessary, with a rule explaining how the primary reason is chosen. If categories are meant to sum to total returns, each case needs one primary category and unknown must remain available. Multiple-tag counts can exceed the number of returns and must be labelled accordingly. Do not alternate between these views without explaining the denominator.
Review ambiguous cases with examples and record category changes. A return may begin as unsuitable and later reveal a specification error. Preserve the revision path and date, especially when reports are compared over time. Train reviewers on evidence requirements and inspect a sample for inconsistent coding. Agreement on labels improves comparability but does not establish that the underlying explanation is correct.
Use a relevant sales cohort and follow-up period
Returns often arrive after the original sale, so a monthly return count divided by the same month's sales can mix unrelated cohorts. Link returns to eligible shipped or delivered units where possible and allow a stated observation window. Keep immature cohorts separate. If linking is incomplete, report that limit and avoid presenting the resulting ratio as a fully observed product return probability.
Investigate patterns by product version, batch, route or customer need only when the source supports those distinctions. A high return count may reflect high sales volume, while a high rate may be based on very few units. Combine counts, denominators and severity before choosing a response. Assign a corrective action to the confirmed mechanism and monitor whether both return incidence and customer experience change afterward.
A fictional footwear-return review
A fictional scenario to explain the method, not a customer result or a market benchmark.
A fictional retailer receives 40 returned items from a matured cohort of 400 delivered pairs, giving a 10% observed item-return rate. Primary reasons are 18 fit issues, 8 confirmed defects, 6 wrong items and 8 unknown, which sum to 40. Reviewers also tag damaged packaging on five returns, including two defects and three fit returns.
The five packaging tags are not added as a fifth mutually exclusive primary category, because that would double-count cases. The team reviews sizing guidance for the 18 fit cases, fulfilment records for the six wrong items and inspection evidence for the eight defects. It does not assume all unknown returns are harmless or defective. A newer cohort with only one week of follow-up is shown separately rather than compared directly with this mature cohort. The case is fictional and illustrates denominator and classification choices, not an actual product defect rate. The unknown category receives a targeted review of available notes rather than an arbitrary redistribution across known reasons. If that review changes the classification, the next report identifies the revision and retains the original cohort denominator of four hundred delivered pairs.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Define the return milestone and counting unit.
- Preserve reported reasons and inspection findings.
- Distinguish primary categories from multiple tags.
- Compare cohorts with adequate follow-up.
Common questions.
Should every return have a known root cause?
No. Unknown is preferable to an unsupported attribution, with follow-up assigned where the decision requires it.
Can multiple reason tags be summed as total returns?
No. Tagged categories may overlap; use a unique-case count or a mutually exclusive primary classification for reconciliation.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse Accuralytix.
Found an error or a missing qualification? Send an editorial correction.
Check my data readiness.
Use a practical tool to turn this idea into a clearer starting point.
Check my data readiness