Return Reason Structured Classification

Return portals, agent tickets, and post-delivery emails already capture why buyers send products back. Most of that signal arrives as free text: a short note in a Zendesk ticket, a Salesforce case comment, a line pasted into SAP returns processing, or a transcript from a support call. Quality and design teams need those reasons in a stable vocabulary so they can spot defect patterns, packaging failures, and fit issues by SKU, plant, and cohort. Unstructured text does not roll up that way.

Manual coding does not scale. Analysts sample a slice of returns, map phrases to a spreadsheet taxonomy, and publish a monthly chart. By then the window to stop a bad lot or revise a fixture has closed. Agent-selected reason codes help a little, but they are often chosen under time pressure, limited to a coarse list, and biased toward whatever option was easiest to click. The richer story stays in the narrative field that nobody aggregates.

Structured classification closes that gap. An LLM reads the free text attached to a return, extracts the stated reason (and secondary reasons when present), and maps each statement onto a controlled taxonomy that product quality and CX insights already agree on. Downstream systems then treat those labels like any other structured attribute: filters, trends, alerts, and joins to inspection and production data.

The useful output is not a paragraph summary. It is a small, typed record per return line or return header:

• Primary reason class (required when text exists)
• Optional secondary classes when the customer states more than one cause
• Confidence or review flag for borderline language
• Source channel and document reference (ticket ID, email message ID, transcript segment)
• Empty-class marker when no usable text is present

Empty class is intentional, not a failure mode. Many manufacturing returns arrive with a barcode, RMA number, and condition code but no customer narrative. Forcing a guess invents quality signal that never existed. When text is missing, blank, or only contains shipping logistics (“please pick up,” “label attached”), the classifier emits an empty class so volume totals stay honest and analysts can separate “reason unknown” from “reason mapped.”

Keep the taxonomy shallow enough for weekly ops review and deep enough for design root cause. A practical pattern is a two-level hierarchy: a closed set of parent categories (for example defect, damage in transit, wrong item, fit or sizing, expectation mismatch, packaging, documentation) and child codes that name the mechanism (seal leak, cracked housing, missing fastener, incorrect revision, dimensional out of tolerance). Parent codes power executive views. Child codes power CAPA, supplier quality, and design change requests.

Pair each classification with the original snippet the model relied on. That citation makes spot audits cheap and keeps legal and quality stakeholders comfortable that labels are grounded in customer language, not invented.

Manufacturing return programs rarely live in one system. Intake and CX often sit in Zendesk or Salesforce Service Cloud. The RMA, credit, and warehouse steps usually live in SAP (or a connected WMS). Classification has to meet text where it appears and write labels back where decisions are made.

A workable flow looks like this:

1. Trigger on return creation or on first meaningful text event (new ticket comment, email body, call transcript attach).
2. Collect candidate text fields: customer note, agent summary, email thread excerpts, transcript turns that mention “return,” “broken,” “wrong,” “doesn’t fit,” and similar cues.
3. Normalize language lightly (strip signatures, track numbers, boilerplate) without rewriting the customer’s claim.
4. Classify against the published taxonomy; allow multi-label only when the text clearly supports it.
5. Write primary (and optional secondary) classes plus empty-class status onto the return record, and mirror a compact reason code into SAP for analytics and supplier chargebacks where policy allows.
6. Queue low-confidence or novel phrases for human review so the taxonomy can grow without silent drift.

Zendesk and Salesforce are typically the richest text sources. SAP often holds the authoritative return quantity, plant, material, and batch. Join on RMA or order line so a quality dashboard can chart “seal leak” by plant and material without asking engineers to open tickets one by one. When the same return has conflicting agent codes and model labels, prefer the model output when the narrative is detailed, and prefer the agent code when text is empty, with both retained for audit.

Do not re-classify every comment forever. Prefer the first substantive customer statement, then allow an explicit “reason update” path when the customer corrects themselves after inspection. That keeps time series stable while still reflecting new facts.

CX insights teams optimize for customer experience themes. Product quality teams optimize for failure modes that manufacturing and design can fix. A shared taxonomy has to serve both without becoming a dumping ground.

Start from historical high-volume phrases, not from a perfect ontology. Cluster a few thousand recent return notes, draft parent and child codes, then pressure-test them in a joint review with quality engineering, packaging, and CX. Reject codes that cannot drive an action. If a label never leads to a containment, design review, supplier claim, or CX playbook change, drop it or fold it into a parent.

Define disambiguation rules in plain language the model (and reviewers) can follow. Examples:

• Cosmetic scratch described after open-box delivery maps to damage or handling, not to a manufacturing defect, unless the customer also cites a functional failure.
• “Wrong item” means SKU or revision mismatch; “missing part” is incomplete shipment or BOM, not a defect of the main unit.
• Fit issues for apparel-adjacent or adjustable products stay separate from dimensional defects on precision parts.
• Expectation mismatch covers “not as advertised” when no physical fault is claimed.

Publish a short codebook with positive and negative examples for each child code. Retrain or refresh prompts when reviewers keep overriding the same pair of siblings. Track override rates by code; a chronically corrected code is usually a taxonomy problem, not a model problem.

Connect reason classes to related quality workflows. When classified reasons concentrate on a child code that also shows up in inspection escapes, escalate jointly rather than debating ownership. Structured return reasons become one more evidence stream beside scrap, warranty, and in-process checks.

Treat classification as a controlled process, not a one-time automation project.

Coverage. Report the share of returns with non-empty text, the share classified, the empty-class rate, and the human-review rate. A rising empty-class rate after a portal change may mean customers stopped writing notes, which is an intake design issue as much as a model issue.

Precision where it matters. Full accuracy across every child code is expensive. Prioritize precision on codes that trigger containment, supplier recovery, or design holds. Allow lower confidence on rare long-tail codes that only feed research backlogs.

Freshness. New products introduce new failure language. Schedule taxonomy reviews when a platform launches, when a packaging change ships, or when a plant comes online. Add temporary “watch” codes for novel phrases, then promote them once volume justifies a permanent child.

Privacy and retention. Return emails and transcripts can contain personal data. Limit fields sent to the model to what classification needs, retain snippets under the same retention policy as the source ticket, and avoid shipping unnecessary PII into analytics extracts.

Downstream consumers. Product quality uses class trends by material, plant, and production week. CX insights uses the same classes to brief support and update help content. Design uses child codes and cited snippets in change requests. Finance may use a coarser parent map for reserve analysis. One taxonomy, multiple grain levels of reporting, keeps the organization aligned.

When you start, pick one high-volume product family, wire Zendesk or Salesforce text into classification, write labels back beside the SAP return, and run a two-week dual control against analyst coding. Expand channels only after empty-class handling, review queues, and taxonomy ownership are clear. Related work on Returned Item Condition Grading, Inspection Escape Root Cause Correlation, and Return Volume Forecasting then becomes additive: condition grades describe what came back, reason classes explain why the customer initiated the return, escape correlation ties both to process failure, and forecasting uses the structured mix instead of opaque free text.