This worked case is part of the refund abuse review guide, which covers what to inventory before a returns platform migration. Here one hard case is walked through step by step, so a partner can recognize the same shape at a client.
The case in one paragraph (Illustrative)
A fictional 180-person outdoor apparel retailer runs its store on a commerce platform, its support on a helpdesk and its returns through a separate returns app. Its return-rate rule holds any refund when an account has more than four returns in 120 days. Between January 8 and April 22, one customer returns five orders. The fifth trips the rule and the refund is held. A reviewer looks before denying it and finds the customer was ordering up a size each time on one insulated jacket line because the published size chart was wrong. The refund is released and the rule is changed. None of this is a real company or customer.
Step by step: flag, review, decision, fix
Step 1. The pattern builds. Five orders and five returns over fifteen weeks. Four carry the return reason "Too small", all on the same jacket line in successive sizes. The returns app counts returns; it does not read reasons.
Step 2. An unrelated signal appears. On March 28, a merchandising lead opens a ticket about a spike in returns on that jacket line. Nobody connects it to any single customer.
Step 3. The product is fixed. On April 10 a corrected size chart goes live on the product page. The commerce platform's content history records the change.
Step 4. The rule fires. On April 22 the fifth return trips the threshold. The returns app logs a hold, the rule name and the count.
Step 5. The customer writes in. On April 23 the customer asks why the refund has not arrived. A support agent adds a note and escalates the ticket to the returns review queue.
Step 6. The reviewer decides. On April 24 the returns review lead reads the reasons, finds the merchandising ticket and the size chart change, and clears the hold. The case note records "size chart defect, not abuse" and the approver.
Step 7. The money moves. On April 25 the refund posts on the order.
Step 8. The rule changes. On May 30 the customer operations director excludes returns on product lines with an open size chart defect from the count. A 30-day check shows no repeat hold for the same reason.
The record behind each decision
The evidence asset for this page: each step, the record it left, the system and the role that owns it.
| Step | Record | System | Decision it captures | Owner |
|---|---|---|---|---|
| 1 | Five orders and returns, four tagged "Too small" | Commerce platform and returns app | None yet; the raw pattern | Ecommerce manager |
| 2 | Merchandising ticket on the jacket line | Helpdesk or project tracker | That the product was suspect | Merchandising lead |
| 3 | Size chart revision | Commerce platform content history | The fix and its date | Ecommerce manager |
| 4 | Hold with rule name and threshold | Returns app rule log | The automated flag | Customer operations director |
| 5 | Ticket with customer note and escalation | Helpdesk | Agent's choice to escalate, not deny | Support team lead |
| 6 | Case note: cleared, reason, approver | Returns app case notes | The authorized human decision | Returns review lead |
| 7 | Refund transaction | Commerce platform | The action taken | Finance |
| 8 | Rule configuration change and 30-day check | Returns app configuration | The accepted outcome and the fix to the rule | Customer operations director |
Reason codes only exist if staff record them. Shopify's help center tells merchants to create a return and pick a return reason before refunding returned items, and its refunding guidance notes that a refund issued without a return records no return reason; the "reason for refund" field is an internal note, and reports that group returns by reason use only return reasons. A store that often refunds without creating a return will have thin reason data for step 1.
Why this sequence is useful evidence
Each record on its own says little. The order history says "five returns". The rule log says "held". Only with the reasons, the merchandising ticket and the reviewer's note does the case become a decision record: a problem (a held refund), an authorized action (release, approved by a named role) and a checked result (no repeat hold after the rule change).
That shape is what makes exception history interesting to AI developers: a rule that was wrong, a person who noticed, and a documented correction. It is the same reason AI-to-human handoff data and chargeback representment records are valued: they capture where automated judgment stopped and a human decided. Shopify's Timeline is often where a reviewer writes reasoning on the order itself; staff comments there are not visible to customers, and deleted comments cannot be recovered, so a pre-migration cleanup can erase step 6 for good.
Spotting similar cases at a client
Ask the customer operations director these questions, and listen for yes:
- Does the returns app hold refunds automatically on a count or score?
- Are cleared holds recorded with a written reason and an approver?
- Do return requests carry reason codes most of the time?
- Do merchandising or quality issues get logged anywhere with dates?
- Has a rule ever been changed after a wave of false flags?
- Roughly how many holds a year, and what share were cleared?
Three or more yeses suggest the company holds explained cases, not just transactions. To see how the records join across tools, read the system map; for who can approve a discussion, see who can license refund abuse review records. The workflow map template helps a client sketch its own version, and assessing procurement approvals and exception workflows applies the same test elsewhere.
Rights sit above the director. Return and ticket records carry customer names and addresses, so counsel decides what could ever be licensed and what would need de-identifying. The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records, and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. Buyer interest, the rights review result and any offer stay unknown until SourceX reviews it.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a retailer's cleared refund holds carry a reason and an approver, register as a partner, check the company against who qualifies and read the program terms before you ask the customer operations director to sponsor the introduction.