returns_reverse_logistics v1.0.0

name: "returns_reverse_logistics" description: "Design and run e-commerce returns: RMA intake and authorization, receiving inspection and grading, restock/refurbish/liquidate disposition routing, return-policy templates, and return analytics. Use when someone needs a returns workflow, RMA process, inspection grading rules, disposition decisions, or a written return policy."

Returns Reverse Logistics

Purpose

Run product returns as a controlled operation instead of a loss center: authorize every return through an RMA record, inspect and grade what comes back, route each unit to the disposition that recovers the most value, and keep the written policy aligned with what the warehouse actually enforces.

Workflow

1. RMA intake

Every return starts as an RMA record, never as an informal refund. Capture at minimum: order ID, SKU, quantity, reason code, claimed condition, requested resolution (refund, exchange, store credit), and customer contact. See assets/rma-record-schema.json for the full field list. Issue a unique RMA number and return instructions; mark the package with the RMA number so receiving can match it.

2. Eligibility check

Before approving, verify against the policy: return window (clock starts at delivery unless the policy says otherwise), product category restrictions, exclusion list (final sale, personalized, opened cosmetics), and proof of purchase. Auto-deny what the policy excludes, with the specific policy clause quoted in the denial message. Flag serial-returner patterns and high-value fraud indicators for manual review.

3. Receiving and inspection

Track each RMA through stages: requested, approved, in_transit, received, inspected, resolved. On arrival, match the package to the RMA number, then inspect against a category checklist and assign a grade:

• Grade A: like new, complete packaging, passes functional testing where applicable. Restockable as new.
• Grade B: light cosmetic wear or damaged packaging; item itself fully functional. Candidate for open-box resale.
• Grade C: functional problems or significant wear. Candidate for refurbish or liquidation.
• Grade D: broken, incomplete beyond recovery, or unsafe. Recycle or destroy.

Category checklists live in references/disposition-playbook.md. Inspectors record the grade plus any defect photos on the RMA record before it moves to disposition.

4. Disposition routing

Route each graded unit with the decision tree in references/disposition-playbook.md. The short version:

• Grade A with intact packaging -> restock as new (reselling used goods labeled "new" is an FTC enforcement risk; only resell as new when the item genuinely is).
• Grade A with damaged packaging or Grade B -> repackage and sell as open box, when repackaging cost is covered by the margin over the next-lower channel.
• Grade C -> refurbish when refurbishment cost stays under 40% of the refurbished selling price and a refurbished sales channel exists; otherwise liquidate.
• Grade C/D -> liquidate through pallet auctions or wholesale liquidators (keep pallets category-pure; mixed pallets price at the lowest-category rate), or donate for a tax deduction at fair market value when that beats liquidation.
• Low-value items: use returnless refunds when round-trip processing costs more than the item is worth.

Run candidate decisions through bin/disposition_calculator.py to compare net recovery across channels.

5. Resolution and customer communication

Issue the resolution the policy promises for the recorded grade: full refund, partial refund, exchange, or store credit. Notify the customer at each stage (approved, received, resolved); denials name the policy clause. Record refund amounts and timelines on the RMA record for audit.

6. Policy design

Write the policy before you need it, and keep it where customers can find it (product pages, checkout, order confirmation). The required fields and three ready-to-adapt templates are in references/policy-design-guide.md: a standard DTC apparel policy, an electronics policy with restocking fees, and a bulky-goods policy with shipping rules.

7. Analytics

Monthly, review: return rate by SKU and category, top reason codes, RMA turnaround time, inspection grade distribution, value recovered per disposition channel, and restocking-fee revenue vs. conversion impact. Feed the top defect patterns back to product descriptions, sizing guidance, and QA so returns stop at the source.

Output Contract

When asked to design returns operations, deliver:

1. The RMA record schema in use (or assets/rma-record-schema.json as the starting point).
2. The stage list with owners (intake, eligibility, receiving, inspection, disposition, resolution).
3. The grading rubric for the merchant's product categories.
4. The disposition decision tree with cost thresholds filled in from the merchant's real costs.
5. A written return policy built from references/policy-design-guide.md templates.
6. The analytics checklist with the review cadence.

Operating Rules

1. Every return needs an RMA record. No RMA, no refund.
2. The policy is an operating document, not marketing copy. Warehouse staff must be able to apply it line by line, and denials must quote the clause.
3. Grades are recorded by inspectors on facts (photos, test results), not opinions about what a customer intended.
4. Disposition follows economics: cost each channel from your own measured labor, packaging, and shipping before trusting any default threshold.
5. Never invent statistics, rates, or legal claims. If a fact cannot be sourced, cut it or mark it as an estimate to verify.
6. Write plainly. No em dashes, no hype language.