A return-reason chart is a useful place to begin a conversation. It is a poor place to end one. The largest bar tells you which answer was recorded most often. It does not tell you which change would prevent the next customer from having the same problem.
That distinction matters commercially. Rewriting a product page will not fix a picking error. Adding a warehouse check will not help someone who ordered the correct item but misunderstood its usable dimensions. Both problems can sit under the same reason code, share a dashboard trend and arrive in the same weekly meeting.
The useful question is: what happened between the customer's expectation, the order and the item received—and which part can we change?
Start with one cohort, not the company's return rate
Illustrative example. All products, customers, policies, figures and costs below are fictional teaching assumptions. They are not Aright project results or industry benchmarks.
An online home-storage retailer sells two sizes of an organizer: a 30 cm version and a 40 cm version. Both cost $50 in this example. The team examines 1,000 paid, delivered orders from one channel in one market. Each order contains exactly one organizer; there are no discounts, partial refunds or exchanges in this simplified cohort.
Each order has completed the same 30-day observation period after delivery, matching the example store's standard request window. That is an analytical boundary, not a statement about anyone's legal rights or permission to reject later claims. Orders delivered yesterday do not enter the denominator alongside orders whose full window has elapsed.
Forty customers have submitted a return request. Twenty-four chose “not as described.” The immediate temptation is to tell the content team that descriptions account for 60% of returns: 24 divided by 40.
But 60% describes the share of requests using that code. It is not the share caused by content, nor the incidence among all delivered orders. The coded group is 24 out of 1,000 delivered orders, or 2.4%. Even that is an observation, not a diagnosis.
Follow the disagreement until the possible fixes diverge
For the 24 cases, the team compares the ordered variant, the recorded pick, the customer's account, available item or label photographs, and the product-page version seen at purchase. It preserves conflicting accounts instead of replacing the customer's words with a convenient internal category.
The investigation produces this small working picture:
| Group | Competing explanations | Evidence in the fictional case | Appropriate next action |
|---|---|---|---|
| 12 “not as described” requests | Wrong item sent, or customer misunderstood the ordered size | Orders specify the 30 cm variant; item/label evidence shows the 40 cm variant was delivered | Complete customer remedy; trace the pick/label mismatch and add a targeted verification step |
| 8 “not as described” requests | Wrong item sent, or usable space was misunderstood | Ordered and received variants match; the page shows a 30 cm external length, while usable internal length is 27 cm; customer accounts describe expecting a 28 cm object to fit | Improve the distinction between external and usable dimensions; test whether shoppers can choose correctly |
| 4 “not as described” requests | Either explanation, or another cause | The available records do not establish which item was received or what expectation mattered | Keep the explanation unresolved and follow up without delaying customer support |
| 16 requests with other codes | Other product, delivery or preference issues | These cases have separate evidence and have been resolved at the cutoff | Retain their own diagnoses; do not force them into the page-versus-picking story |
The first 12 provide direct evidence of a variant mismatch. The eight dimension cases support a plausible content problem; they do not establish that every return would have been avoided by a drawing. A shopper could still decide the correctly explained product was unsuitable.
The lesson is not to investigate every return indefinitely. It is to collect enough evidence to distinguish actions that otherwise look interchangeable. If the team cannot say what finding would change its proposed fix, it may be gathering records without testing an explanation.
For this retailer, “improve product descriptions” is too broad. The operational question is why two variants can be confused during picking. The content question is whether a customer can identify the usable space before ordering. Each needs a different owner and a different check.
Reconcile requests, returned goods and refunds before reporting a rate
At the same cutoff, the 40 cases stand as follows:
| Measure | Count | Share of the 1,000 delivered orders |
|---|---|---|
| Orders with a return request | 40 | 4.0% |
| Orders whose unit has physically returned | 32 | 3.2% |
| Orders with a completed full payment refund | 36 | 3.6% |
| Open cases, with neither physical receipt nor completed refund yet | 4 | 0.4% |
The 36 refunded cases comprise the 32 received units and four refunds without a physical return. The four open cases are the four unresolved cases above. Thus 32 + 4 + 4 reconciles to the original 40 requests. The first two groups of “not as described” cases are among the 32 physical returns.
These are not three competing answers to the same question. They measure requests, physical movement and customer payments. Calling all three a “return rate” makes disagreement inevitable. The report should name the event, cohort and cutoff.
Google Analytics' ecommerce documentation describes sending a refund event against a transaction identifier, with item information for item-level reporting. That event is an analytics record. Its presence does not establish warehouse receipt or payment settlement. Reconcile operational counts to the order, return and payment records rather than asking an analytics event to stand in for all three.
Also keep the policy seen by the customer with the order. Google Merchant Center's return-policy guidance allows policies to have different country or product scopes and requires consistency with the website. A policy setting is therefore relevant context, not proof of how a particular case was handled. Do not compare markets or periods as if their policies and case definitions were identical when they were not.
Calculate what a prevented error would actually change
The retailer now considers an extra pick-and-variant check. Before deciding how much to spend, it needs a cost model that does not count the same loss twice.
For one of the wrong-variant orders, assume the following amounts in US dollars. These are economic planning assumptions, before acquisition costs, tax effects and fixed overhead—not an accounting profit statement. The $14 recovery credit is the returned item's assumed net recoverable value after future reconditioning and selling costs; it is not another sale at full retail. The separate $2 inspection charge is not included again in that credit.
| Item | Otherwise successful, retained sale | Fully refunded wrong-variant return |
|---|---|---|
| Sales revenue retained after refund | $50 | $0 |
| Goods cost | −$20 | −$20 |
| Original outbound delivery | −$5 | −$5 |
| Non-recoverable payment processing | −$1 | −$1 |
| Return freight | $0 | −$6 |
| Inspection | $0 | −$2 |
| Net recovery credit | $0 | +$14 |
| Contribution in this model | $24 | −$20 |
The successful sale contributes $50 − $20 − $5 − $1 = $24. The return contributes $0 − $20 − $5 − $1 − $6 − $2 + $14 = −$20.
A genuinely prevented wrong-variant return therefore improves contribution by $24 − (−$20) = $44, if that order becomes an otherwise equivalent retained sale. The $50 refund has already reversed the original revenue. Adding it again as an expense would exaggerate the loss.
That “if” matters. If the corrected process causes an order to be cancelled before shipping, its economics are different. If the customer receives the correct variant but returns it for another reason, the full $44 improvement does not occur. If recovery value is lower, return losses are larger. Use the actual route's costs and outcomes, not a universal cost-per-return number.
Suppose the additional check costs $120 for the next comparable cohort. Under the stated assumptions, the break-even calculation is $120 ÷ $44 = 2.73: at least three genuinely prevented errors are needed. Three would produce $132 of improvement less $120 of checking cost, or $12. With no prevention, the change costs $120.
This is a decision threshold, not a forecast that the check will work. Nor does a before-and-after decline of three cases prove that three errors were prevented.
Make one targeted change, then look for the mechanism
The evidence supports addressing the verified pick/variant mismatch first, rather than commissioning a general rewrite of every product page. The warehouse lead would examine where the order variant, pick label and packed item can diverge, then trial a check at that point. Scanning the same incorrect label twice is not independent verification; the check must compare the intended variant with the item being packed.
The next comparison needs the same delivered-order denominator, a completed observation period and a reasonably comparable size mix, channel and fulfilment route. Record which process version each order used. Where operationally appropriate, an evaluation could allocate a new check across comparable pick lanes or time blocks. If only a sequential before-and-after comparison is feasible, changes in staff, volume and mix remain alternative explanations. NIST's experimental-design guidance is a useful starting point for choosing objectives, variables and a suitable design; it does not supply an appropriate sample size for this store.
Look for a reduction in verified wrong-item deliveries, not merely fewer “not as described” codes. A new form or an agent recoding cases could shrink that category without improving a single shipment. Review checking time, dispatch delays, customer contacts and unresolved cases as well as the estimated contribution effect. Stop or modify the trial if the check creates a new systematic error or materially worsens service.
The dimension problem deserves its own response. Show external and usable measurements together, explain which one determines fit, and ask representative shoppers to choose a size for a stated object. That tests understanding more directly than a fall in page exits. Keep essential information accurate for everyone: do not leave a known misleading statement live simply to maintain a control. A presentation test cannot establish sales causation from a handful of answers, and changing the page and warehouse process at once would make an aggregate improvement difficult to explain.
A lower rate can still be a worse customer outcome
The easiest way to reduce recorded requests is to make the request harder. That would invalidate the purpose of this work.
Keep refund access, response time, complaints and cases that disappear before resolution in view. A request that becomes a complaint, a refused delivery or an abandoned conversation is not automatically a saved sale. Do not wait for a diagnosis before providing a remedy that is due, and do not assign customer blame merely because the internal records are incomplete.
Safety concerns leave the normal improvement queue. For a US consumer-product example, CPSC explains that certain reportable product information requires immediate reporting. A return-rate experiment must not postpone the appropriate safety response. The applicable product, market and duties need qualified review; this example does not decide them for another business or jurisdiction.
Customer messages and photographs should be available only to people who need them for the task, with unnecessary identifying details removed from analysis copies. The team needs the evidence of a size mismatch, not an unrestricted copy of the customer's life.
Finish the meeting with a decision someone can act on
For this fictional retailer, the decision is specific: correct the variant-picking failure, test a targeted verification step against its cost and service effects, and evaluate the dimension explanation separately. Keep four cases unresolved until their evidence supports a better account. Do not redesign the product or tighten the return policy merely because a reason code is common.
The recommendation would change if the variant mismatch proved to be an order-entry problem, the check cost exceeded its plausible benefit, a product measurement was inaccurate, or a safety issue emerged. Those findings point to different owners and actions.
For your next review, take one leading return reason and bring three cases that look similar on the chart. Ask what evidence would separate their causes, what each remedy would change, and how you would know the customer actually had a better outcome. If the answer is still “collect more data,” name the missing observation that could change the decision. That is where returns reporting begins to become returns intelligence.