The 9.9 Post-Mortem: 5 Numbers to Pull Within 48 Hours

If you ran a 9.9 campaign yesterday, pull five numbers before Friday: order accuracy rate, fulfilment lag, support first-response time, payment failure rate, and stock variance. These five tell you whether your business was busy or whether it was breaking — and they are the only honest input into what you fix before 10.10 and 11.11. Wait until October and the evidence will have decayed: WhatsApp threads scroll away, staff memories soften, and the marketplace dashboard resets to a rolling window. The post-mortem is a 48-hour job, not a month-end one.

Why does a 9.9 post-mortem have to happen this week?

Because most of the useful data is perishable. Marketplace seller centres typically show order-level detail readily for the recent period and then push older records behind exports and slower reporting tools. Your own team's recollection degrades faster than that. Ask a packer on 11 September which SKUs kept running out and you will get a specific answer; ask on 11 October and you will get "the usual ones".

There is also a hard calendar constraint. 10.10 is 30 days out. 11.11 is 62. Any fix that involves changing a process, training staff, or reconfiguring a system needs to be specified this week, built next week, and tested on a normal trading day before the next spike — otherwise you are deploying untested changes into peak traffic, which is worse than the original problem.

Which five numbers actually tell you what broke?

1. Order accuracy rate. Orders shipped correctly, first time, divided by total orders. Count wrong item, wrong quantity, wrong address, and missing freebie or bundle component as failures. Below 97% on a peak day means your picking process depends on a person remembering something. That is a systems gap, not a staffing one.

2. Fulfilment lag. Median hours from order confirmation to courier handover, measured separately for the sale day and the two days after. The median matters less than the shape: if your lag was two hours at 10am and eleven hours by 8pm, you have a throughput ceiling that overtime papered over. Find the hour it broke.

3. Support first-response time. Median minutes to first human or automated reply across WhatsApp, marketplace chat, and email — again, hour by hour. Most Singapore SMEs discover their queue collapsed between 9pm and midnight, when the same two people were packing and answering. Note also the top three question types; if "where is my order" was more than half, that is an automation target, not a headcount problem.

4. Payment failure rate. Checkouts initiated versus payments completed on your own storefront, split by method. A jump in abandonment on PayNow or card during peak hours usually points at a gateway timeout or a checkout page buckling under load — quiet revenue loss that never appears in any sales report because the order never existed.

5. Stock variance. System quantity versus physical count on your top 20 SKUs, done now while the discrepancy is still traceable. Oversells, phantom stock, and unrecorded bundle deductions all surface here. Every unit of variance is either a refund you will issue or a sale you refused for no reason.

How do you separate a demand problem from a systems problem?

Divide each failure by volume. If order accuracy was 96% at 100 orders a day in August and 96% at 900 orders on 9.9, your process scaled — the absolute error count rose but the rate held, and you have a capacity conversation. If accuracy fell from 99% to 91%, the process did not scale, and adding staff in October will simply produce more errors faster.

Apply the same test to support and fulfilment. A system that degrades linearly with volume can be planned around. A system that degrades non-linearly — fine at 3x, collapsing at 5x — has a specific bottleneck: one person who approves something, one manual export, one spreadsheet that everyone waits on. Peak days are useful precisely because they expose which one it is.

What does a prioritised Q4 fix list look like?

Score each finding on two axes: cost per occurrence and frequency at 11.11 volume. A wrong-item shipment costs the replacement, the return leg, the support handling, and often the review. At 9.9 volumes that might be 12 incidents; at 11.11 volumes, projected on your own growth, perhaps 30. That is a quantified case for a scan-to-verify step at packing — not an opinion about it.

Rank ruthlessly and stop at five items. A 30-day window with an operating business inside it realistically absorbs three to five process changes, and the discipline of cutting the list is what stops the whole plan from stalling. Anything below the line goes into a January backlog with the evidence attached, so you are not re-deriving it next year.

What should you fix in the 30 days before 10.10?

Sequence by dependency, not by enthusiasm. Data flow first: if your marketplace orders reach your inventory system by manual export, fix that before anything else, because stock variance and oversells both trace back to it. Then customer communication: automated order-status and dispatch updates on WhatsApp typically remove the largest single support category. Then reorder logic: use 9.9 sell-through, not last year's averages, to set restock quantities — with China lead times, the 11.11 purchase order is a September decision.

Leave the cosmetic work alone. Nobody abandoned a cart because of your banner. They abandoned it because checkout timed out, or because the item they wanted showed available and was not.

Frequently asked questions

How long should a 9.9 post-mortem take?

Roughly three hours of data pulling and a 90-minute session with the people who actually worked the sale — warehouse, support, and whoever watched the storefront. Anything longer becomes a report rather than a decision, and reports do not get implemented before 10.10.

What if we did not instrument anything before the sale?

You can still reconstruct four of the five numbers from marketplace order exports, courier handover timestamps, WhatsApp message history, and a physical stock count done this week. Payment failure rate is the one you will struggle to recover — set up that tracking now so it is available for 10.10.

Should we run the same post-mortem after 10.10 and 11.11?

Yes, and the value compounds. Three data points across the Q4 peaks show whether your fixes actually held under increasing load, which is far more useful than a single snapshot. Keep the same five metrics and the same definitions so the comparison stays valid.

A busy sale day that produces no evidence is just a tiring day. The businesses that absorb 11.11 with systems rather than overtime are the ones that spent this week reading what 9.9 told them.