The 30-minute post-mortem for SKUs that ran out (template included)

Nine days. That's how long the bestseller in the worked example below sat at zero — and the reason it had happened twice before that year is that the first two incidents were fixed with restocks instead of reviews. Running out is an event; the post-mortem is the 30-minute review that stops it becoming a pattern. The format is borrowed from incident response, where engineering teams have run blameless post-mortems for years (the practice is documented in Google's SRE book, accessed October 2026) — the version below is sized for one person, four steps, half an hour. Retail trade press tends to reserve "post-mortem" for year-end reviews; this is the monthly one, run per SKU, while the trail is still fresh.

Why post-mortems: the record shows where, the retro finds why

The same SKUs run out for the same reason. That's the finding worth internalizing before any template: repeat events almost never trace to bad luck. They trace to one unfixed link in the chain between noticing demand and putting sellable stock on the shelf.

Two neighboring pieces of work bracket this one. The money question — what the dark days cost, per SKU — is loss math, covered in the cost of going out of stock. The data cleanup — correcting velocity so the gap doesn't corrupt the next reorder — is its own procedure, in how to correct sales velocity after a gap. What sits between them, and what no report can produce, is the why. Reports rank the SKUs that went dark and for how long. They cannot tell you whether the PO was late, the forecast was wrong, or the supplier went quiet. Your records can — and that's what the 30 minutes below are for.

The 30-minute template

Four steps, one page per SKU. Build everything from records, not memories — Shopify's inventory history shows adjustments and zero days per variant (Shopify Help Center, accessed October 2026).

1. Build the timeline (10 minutes). Five dates from your records:

2. Pick one primary cause (5 minutes). One, not a ranked list:

The discipline is choosing the one link that, broken, would have prevented this specific event. Secondary causes get a note, not a project — five causes means no fix.

3. Find the ignored signal (5 minutes). What did the data say before it happened? A velocity line rising for three weeks. An alert dismissed on a busy Friday. A supplier whose ship confirmation never arrived. Every event has at least one, and naming it turns the retro from archaeology into early-warning design.

4. Make one process change (10 minutes). The smallest change that breaks the chain — not five. If the fix list is long, the cause wasn't isolated properly. And a change nobody has to remember by Friday is the only kind that survives; wire it into an existing habit or a calendar slot.

Worked example: enamel pins, nine days dark

A one-person shop selling stationery-adjacent goods. Ghost-design enamel pins, selling roughly 14/day through October, with the reorder point calibrated to a 21-day supplier lead time.

Running the template: forecast miss? No — the PO fired on time and the quantity held until the slip. Late PO? No — placed Sep 17, per schedule. Receiving lag? One day, minor. Hidden demand? Real, and absorbed by safety stock until the supplier slipped. Data error? None; the system told the truth the whole time.

Primary cause: no supplier check-in habit. The PO sat silent for 31 days and nobody asked where it was, so an 11-day slip arrived as a dark week instead of a Tuesday email. Ignored signal: the missing ship confirmation — an absence nobody was watching for. One process change: a mid-lead-time check-in — at day 14 of every PO cycle, one message to the supplier: "still on for Oct 8?" The unannounced slip becomes a flagged slip with a week left to react.

Two follow-ons before closing the retro:

• Correct the velocity. Those nine dark days recorded zero sales, which the reorder math will happily read as zero demand. Exclude Oct 10–19 from the pins' velocity or the next cycle under-orders — right into the second October spike. Use the velocity correction procedure linked above; it takes about ten minutes.
• If slips are the pattern, not the event, the retro's scope widens: supplier scorecards, backup sources, buffer policy. That variant is its own article — when the supplier is the cause.

And if the timeline shows the system lied — stock that never existed — the retro changes shape entirely. That's a count-incident review, owned by the phantom inventory guide, and the fix lives in receiving and sync process rather than supplier comms.

The cadence: two retros a month, not twenty

Not every event earns a retro. Run the 30 minutes on the top two leaks each month — the SKUs with the most out-of-stock days in the period — and for the rest, log SKU, date, and a one-line cause in a running sheet. Twenty-four deep retros a year on the SKUs that actually bleed, plus a paper trail for the tail, beats a quarterly review nobody attends and a resolution list nobody rereads. The tail sorts itself: when the same one-line cause shows up four times, it has promoted itself to next month's retro.

This is where a ranked list earns its name — InventoryX's Leak Report orders SKUs by out-of-stock days so "top two" is a lookup rather than an archaeology project. Then it's back to the template.

The inventory post-mortem, in one pass

The whole practice fits on one page: a timeline you can rebuild from records, one primary cause you commit to, one process change you actually make, and a date to check whether it held. Everything below fills in the four steps.

Common questions

What is a post-mortem for a SKU that ran out? A 30-minute root-cause review: build the timeline from records, pick one primary cause (forecast miss, late PO, receiving lag, hidden demand, or a data error), name the ignored signal, and make one process change. Its purpose is stopping the repeat — the same SKU going dark again for the same reason.

Should I run a post-mortem on every item that went out of stock? No. Retro the top two by out-of-stock days each month and log a one-line cause for the rest. When the same cause repeats in the log, that SKU gets next month's slot. Depth on the SKUs that bleed most beats shallow coverage of everything.

What counts as the primary cause? The one link that, broken, would have prevented the event. If the PO fired on time and the quantity was right, the forecast isn't the cause no matter how noisy the month was — a supplier slip nobody chased is. One cause gets the fix; secondary causes get a note.

What's the most common ignored signal? The missing confirmation: ship confirmations that never arrive, alerts dismissed on busy days, velocity climbing for weeks before the zero. Design the fix around the signal — a mid-lead-time check-in message converts a silent supplier slip into a flagged one while there's still time to react.

What do I do after finding the cause? One process change — the smallest that breaks the chain, wired into an existing habit: a scheduled check-in message, a receive-before-shelve rule, an alert with a named owner. Then correct the velocity for the days the SKU was dark, or the next reorder will under-order the very SKU you just fixed.

Next step

This week: pull the two SKUs with the most dark days this quarter, run the 30-minute template on each, and make the one change. Then check the reorder math that governed the event — most retros end in the same place, with the reorder point calculated correctly and something around it failed. Ten minutes with the reorder point formula walkthrough confirms which side of that line your event fell on. If the same cause keeps surfacing, zoom out: the Shopify inventory audit checks the data, structure, settings, and process layers that single retros miss.