Monthly returns analysis that flags product quality issues

On the first Monday of every month at 9am, analyze last month's returns and tell me what they are actually saying about product quality, not just how many items came back.

The reporting period is the previous full calendar month. Also gather the month before that, so every number can be compared against a prior period.

Use ShipBob Get Return Orders to list every return order created in the reporting period, paging through all results. Then use ShipBob Get Return Order to pull full detail, including line items and per item return reasons, on the cases that carry the most signal: the products with the highest return counts, and anything flagged as damaged or defective. Do not enrich every single return. ShipBob allows 150 requests per minute, so keep the detail pass bounded to the returns that actually drive the findings.

Use ShipBob Get Orders to pull fulfilled order volume across the same period and count units shipped per SKU. This is the denominator. Express every return as a return rate, meaning returns divided by units fulfilled for that SKU in that period, rather than a raw count that just tracks how much I sold. A SKU with 40 returns may be healthier than one with 6 if it shipped twenty times the units, and the report is close to useless without this normalization.

Cluster the returns two ways: by product or SKU, and by reason. Sort the reasons into customer driven (ordered the wrong size, wrong color, changed their mind, no longer needed) and product driven (damaged, defective, broken, not as described, poor quality). If a reason is really a fulfillment error, such as the wrong item being shipped, keep it in a separate third bucket, because blaming the product for a pick and pack mistake buries the signal. Only the product driven bucket is something I can fix at the source, so lead with it.

Compare each SKU's return rate against the prior period and call out any SKU whose rate rose materially. As a starting definition, treat a rise as material when the rate went up by at least 2 percentage points and by at least 50 percent relative to the prior period. Ignore SKUs with very low volume, fewer than roughly 20 units fulfilled in the period, since a single return can swing a small denominator into an alarming looking percentage. Tune these thresholds to my catalog over time.

Write the full analysis to Notion using Create a Page, as a child of the parent page I specify, titled 'Returns Quality Review' plus the month and year. Structure it as: a short headline summary, a table of return rate by SKU showing returns, units fulfilled, and rate for both the current and prior period, the reason breakdown split across the buckets above, the SKUs whose return rate rose materially with a short read on why, and a closing list of recommended actions tied to specific products.

Then post the three headline findings to Slack Bot using Send a Message in my operations channel. Name the worst offending SKUs with their return rates and the direction they moved, and make the point explicit when a SKU's raw return count rose but its rate actually fell. Keep it short enough to read on a phone, and include a link to the Notion page for the full detail.

If there were no returns at all in the period, post a single line to Slack saying the period was clean and skip the Notion page rather than creating an empty report.