Something that came up recently in our operation that I haven’t seen talked about much here.
We had a stretch of about three weeks where returns on one SKU jumped noticeably. First instinct was product-market fit issue. Maybe the listing was misleading, maybe the product itself had changed. Took a while before someone connected the dots back to a specific inbound shipment from six weeks earlier. One supplier batch, quietly distributed across dozens of orders before anyone caught it.
By the time we figured it out the refund exposure was already significant.
The frustrating part is that the data to catch it earlier was all there — receiving records, fulfillment timestamps, return reasons. It just lived in three different places and nobody was looking across all of them at once.
Curious whether others have run into this and how you handled it. A few specific questions:
Do you track returns at the batch or shipment level, or just at the SKU level?
How long does it usually take your operation to connect a return spike to its source?
Is this something you’ve built a process around, or does it still happen reactively?
The receiving dock feels like the part of the operation that gets the least attention relative to how much downstream damage a bad inbound can cause.
This is a really underappreciated problem. Most stores track returns at the SKU level and stop there, but the batch/shipment layer is where the actual root cause lives. The challenge is exactly what you described, the data exists but it’s spread across receiving, fulfillment, and returns in three different systems. The pattern I’ve seen work is tagging return reasons at the line item level and then looking at time-clustering. If returns on one SKU spike in a 2-3 week window and then normalize, it’s almost always a bad inbound batch, not a product page issue. If they’re steady over time, it’s usually a listing problem. The receiving dock point is spot on. QC at inbound is way cheaper than processing returns downstream but almost nobody builds a process around it until they’ve already eaten the cost.
We ran into something very similar with a merchant handling multi supplier inventory. The tricky part was that the return spike didn’t show up at SKU level until weeks later because the affected units were spread across multiple fulfillment windows.
What ended up helping was tagging inbound shipments separately and tying return reasons back to receiving dates instead of just product IDs. It exposed patterns much faster.
I agree with your point about the receiving dock though. Most operations optimize fulfillment heavily but inbound QA usually stays reactive until losses become visible.
Out of curiosity, were the return reasons consistent or scattered across different complaints?