Designing a Return Reason Taxonomy That Scales

Ask a customer why they are returning a hoodie and you get a sentence, not a data point: "too tight around the shoulders, also I changed my mind about the color." Ask ten thousand customers the same question through a free-text box and you get ten thousand sentences that no query can group and no product team can act on with confidence. This is the taxonomy problem, and it sits one layer beneath the analytics most teams actually want. Turning that data into a flywheel — feeding reason codes back into sizing, merchandising, and supplier scorecards — only works if the codes underneath are structured well enough to aggregate. This post is about that upstream design problem, not the downstream question of what to do with the data once you have it.

The free-text trap

Free-text reason fields feel customer-friendly because they impose no structure on the shopper, but that same lack of structure is what makes them worthless as data. A team trying to answer whether a small-medium block runs loose in the shoulder or loose in the waist cannot run that question against a column of open sentences without paying someone to read and manually tag thousands of them first — and by the time that project finishes, the season it was meant to inform is over. Free text also hides double meaning: "didn't fit" could mean the garment ran small, ran large, ran short in the sleeve, or simply looked different from the product photo. Every one of those is a different fix, and a single unstructured phrase collapses them all into one bucket.

A two-axis structure: direction times attribute

The fix is not more categories, it is a small number of orthogonal axes that compose into a coordinate instead of a sentence. The first axis is direction: the underlying reason the item is coming back, independent of which part of the product is at fault — too small, too large, defective or quality issue, changed mind, wrong item shipped, or style and fit mismatch. The second axis is attribute: the specific product dimension the direction applies to — chest, length, sleeve, waist, color, material, or overall style. Cross the two axes and a reason stops being free prose and becomes a coordinate: too-small paired with chest, defective paired with zipper, changed-mind paired with color — exactly what a sizing team, a quality team, and a merchandising team can each query on their own.

Not every direction needs a full attribute pairing, and forcing one is how taxonomies bloat. A wrong-item return is a fulfillment error regardless of which attribute the customer might otherwise blame, so it gets a single terminal code instead of six redundant variants. The discipline is knowing which directions genuinely vary by attribute and which are already fully explained by direction alone.

Governance: who owns the taxonomy, and how it changes without breaking history

A taxonomy that anyone can extend will not survive its second year. The common failure mode is not too little structure, it is too much of the wrong kind: a support agent adds "customer said it felt cheap" as a one-off code during a busy week, a merchandiser adds another for a single problematic SKU, and eighteen months later there are four hundred codes, most of which appear on fewer than ten orders and none of which anyone remembers approving. The fix is ownership, not tooling. One person or one small committee — typically the data or analytics lead — reviews and approves every new code and every deprecation before it ships, the same way a schema change to a production database goes through review rather than getting added ad hoc.

Versioning is the other half of governance: a taxonomy that changes shape breaks every trend line built on top of it. The rule that keeps history intact is simple — add, don't rename, and deprecate, don't delete. A code that turns out too broad gets split into two new codes going forward, while historical volume under the old code stays as recorded, tagged with the version that was live when captured. A code that turns out redundant gets deprecated and mapped to its closest active match, so a five-year chart of "defective returns" keeps working even though the code list looked different in year one than year five. This is why reason codes matter beyond one quarter's report — they feed the metrics that actually matter over time, and a metric built on a taxonomy that reshuffles every few months is not one anyone should trust.

A taxonomy that changes shape every quarter is not a taxonomy. It is a moving target, and no trend line survives being measured against one.

• Assign a single taxonomy owner — usually the data or analytics lead — who approves every new code and deprecation before it ships.
• Version by addition: split or deprecate codes going forward, and never rename or reuse an existing code string retroactively.
• Review usage every quarter and retire codes under a meaningful volume threshold for two consecutive quarters, mapping their history into the nearest active code rather than deleting it.
• Cap the live taxonomy's size on purpose — a code list with hundreds of active entries is the free-text problem again, wearing a structured costume.

Forcing structure without adding customer friction

None of this works if capturing a structured code costs the customer more effort than typing a sentence. The strongest pattern we've seen is a short guided flow at the point of return request: ask direction first, then attribute, never a free-text box as the primary input. Direction should be four to six icon-labeled options scoped to the product category — apparel, footwear, and electronics need different sets — since more than six options turns a two-tap flow back into a search problem. Attribute should be scoped to the direction and category chosen a moment earlier, so a "too small" apparel return offers chest, waist, and length, while a "too small" footwear return offers width and length instead. Research groups such as Gartner have long argued that structured data capture only succeeds at scale when entering it costs less effort than the alternative — a lesson that applies to a return reason picker as much as to any enterprise data form.

1. 1Ask direction first, with four to six icon-labeled options tailored to the product category — never more, or the list becomes its own free-text problem.
2. 2Ask attribute second, scoped to the direction and category chosen in step one, so the options always make physical sense.
3. 3Offer a short optional free-text field only after the structured pick, so it enriches the coordinate instead of replacing it.
4. 4Log the taxonomy version with every submitted code, so a future split or rename can be reconciled against which code set was live at capture time.

Done well, this whole exercise is invisible to the customer and load-bearing for everyone downstream of them. The customer taps through two short screens instead of composing a paragraph, and the business ends up with a coordinate instead of a sentence — one a sizing team, a QA team, and a merchandising team can each query independently, months or years later, without a manual tagging project standing between them and an answer. That reliability is what makes treating returns as a genuine data flywheel possible in the first place, rather than an annual slide deck built on a spreadsheet someone tagged by hand.