Using AI to Classify Return Reasons

A structured return-reason taxonomy tells you which codes are allowed to exist. It does not tell you how a given return actually earns one of those codes without making the customer do the sorting for you. That second problem is a classification problem, and it is the one most teams underestimate. Even with a well-designed dropdown, a large share of your reason data still arrives unstructured: a marketplace order syncs back a one-line note, a shopper types a sentence into an optional comment box, a support agent pastes a photo of a torn seam into a ticket. Left alone, every one of those inputs is a data point your analytics will never see. Classification, increasingly with machine learning and large language models, is how you turn that messy human input into the same structured coordinate that a well-designed return-reason taxonomy is built to hold.

The three kinds of input a classifier has to handle

A return-reason classifier is not one model doing one job. It is a system that has to ingest at least three very different signal types and land them all in the same taxonomy. The first is the structured dropdown pick, which looks clean but is quietly noisy: a meaningful fraction of customers select the first option, the most generic option, or whichever one clears the screen fastest, so the label you captured and the reason that actually drove the return often disagree. The second is free text, either from an optional comment field or imported from channels you do not control, where the customer describes the problem in their own words, such as 'too tight across the shoulders, and honestly the color was darker than the photo.' The third is images, a photo of a stain, a cracked screen, or a wrong item, which carry the most unambiguous defect signal of all and the least structure.

Each input type argues for a different model. Free text is a natural-language classification job, which is where large language models have changed the economics: a model that a few years ago needed thousands of hand-labeled examples per category can now map a sentence onto a fixed code list with a short instruction and a handful of examples. Photos are a computer-vision job, closely related to the models that already power automated return grading on the warehouse side. And the dropdown, ironically, is the input that benefits most from being treated with suspicion rather than trust.

Capture, classify, validate: a pipeline, not a model

The mistake teams make is shopping for a model when what they need is a pipeline. Classification is the middle stage of three, and skipping either of the stages around it is what turns a promising accuracy number into an unreliable one in production.

1. 1Capture the rawest signal you can. Keep the free text, the image, the dropdown pick, and the order context, such as SKU, size, channel, and days since delivery, together as one record. The classifier is only ever as good as the signal it sees, and a stripped-down 'reason: other' throws away the exact words that would have resolved the ambiguity.
2. 2Classify into the taxonomy, never outside it. The model's job is to select from your fixed code list, not to invent a new label. This is the single most important design constraint, and the one an LLM will violate by default if you let it generate free-form output instead of choosing from an enumerated set.
3. 3Validate with a human in the loop, routed by confidence. High-confidence predictions apply automatically; low-confidence or high-stakes ones, such as a defect that could trigger a supplier chargeback, route to a short human review queue. The humans are not re-doing the model's work; they are handling the tail it was honest enough to flag.

The tempting shortcut is to skip the messy inputs entirely and force every customer through a rigid dropdown, and for some operations that is genuinely the right call. A rigid dropdown is free to run, produces structured data by construction, and never hallucinates. What it cannot do is capture nuance the option list did not anticipate, and it silently mis-labels every customer who picked the wrong box. An LLM classifier sitting behind a free-text field captures the nuance and recovers the mis-picks, but it costs a fraction of a cent to a few cents per return to run, it can drift as your product mix changes, and it will confidently assign a plausible-but-wrong code often enough that you cannot remove the human review layer entirely. Neither is strictly better. The strongest architecture usually uses both: a fast structured pick for the customers happy to give you one, and an LLM to rescue signal from the free text and photos a dropdown alone would have discarded.

How accurate is good enough, and how to know

Accuracy is the question every stakeholder asks and the one most easily answered badly. A single headline accuracy number is nearly meaningless for a classifier with twenty-plus codes, because the model can be excellent at the three high-volume codes that make up most of your traffic and poor at the long tail that individual teams actually care about. A sizing team does not benefit from 92% overall accuracy if the model confuses 'too small in the chest' with 'too small in the waist' half the time, since those two codes point at different pattern fixes. Measure accuracy per code, weight it by how much each code matters to a downstream decision, and watch the confusion pairs, the specific codes the model swaps, not just the aggregate.

The human-in-the-loop layer is what makes an imperfect classifier safe to deploy, and confidence calibration is what makes that layer affordable. A well-calibrated model that says it is 95% sure is right about 95% of the time, which means you can auto-apply above a threshold and review below it, and know roughly what error rate you are accepting in the auto-applied band. Sample-audit the auto-applied predictions continuously, pulling a small random slice each week and hand-checking them, so drift shows up as a slow rise in your audit error rate before it corrupts a quarter of analytics. Consultancies that study AI adoption, McKinsey among them, have made the same point across domains: the operational value of a model comes less from its peak accuracy than from the review process wrapped around its mistakes.

A classifier's job is not to be right every time. It is to be right most of the time and honest about the rest, so a human only ever touches the returns it flags.

Closing the loop into grading and analytics

Classification only pays off if the structured code it produces actually flows somewhere. A reason code that lands in a table nobody queries is expensive theater. The version that earns its keep feeds two destinations at once: the analytics layer, where reason volume by SKU drives sizing, merchandising, and supplier decisions, and the operational layer, where a 'defective, zipper' classification routes the physical unit toward inspection and refurbishment instead of straight back to stock. This is the seam we designed ResReturn around, structured reason capture at the point of return, enriched rather than replaced by classification of any free text or photos the customer adds, feeding both the returns data flywheel and the grading decision downstream. The model is a means; the structured, queryable coordinate is the end.

• Keep every raw signal, the dropdown pick, free text, photo, and order context, in one record, so the classifier and any human reviewer see everything the customer gave you.
• Constrain the model to select from your fixed taxonomy; never let an LLM generate free-form labels it can invent.
• Route by confidence: auto-apply high-confidence predictions, send the rest to a short human review queue, and sample-audit the auto-applied band weekly.
• Measure accuracy per code and watch confusion pairs, not one blended number that hides the long-tail codes your teams rely on.
• Treat the dropdown as noisy input to be checked, not ground truth, since a large share of picks are the fastest option, not the true reason.