Why this one is not a sync-speed problem
Most oversell problems are timing problems: a sale happens on one channel and another channel finds out sixty seconds later. Faster updates genuinely help. A deal site plus a trade counter is a different shape. The deal starts at a fixed time, demand arrives in a burst, and a counter customer can be loading a pallet of the same SKU at that exact moment. The two sales are simultaneous, so there is no interval short enough to referee them.
The fix is allocation. Decide, before the deal is live, how much stock the deal may sell — and reserve it, so that every other channel and the till are looking at what is genuinely left.
A worked example
You hold 800 units of a case-packed SKU. A Groupon deal is capped at 500 redemptions and runs for seven days. A purchase order for 600 more is confirmed for day four. Trade counter demand runs at roughly 40 units a day.
| Approach | Counter sees | Likely outcome |
|---|---|---|
| No ring-fence, publish 800 | 800 available | Deal takes 500 in two days while the counter sells 80. Day three is short and someone is cancelling orders. |
| Ring-fence the full cap of 500 | 300 available, 800 on hand | Deal is safe. Counter has 300 for seven days at 40 a day, plus 600 arriving on day four. Nothing is cancelled. |
| Ring-fence 300, rely on the PO for the tail | 500 available | Works if the PO lands on day four. If it slips two days, the deal is the thing that breaks. |
The middle row is usually right. The third row is the one people choose because it looks like more upside, and it is the one that converts a supplier delay into cancelled marketplace orders.
What the till needs to show
Two numbers, not one. On hand is what is physically in the building. Available to sell is on hand minus what is already promised — deal reservations, picked-not-dispatched orders, and allocations to other channels. The classic counter mistake is selling against on hand because on hand looks healthy, with no visibility that 400 units belong to a deal that has already been paid for.
In MaxInvent a till sale is an order source against the same stock pool rather than a separate stock ledger, so a counter sale reduces the same available number the marketplaces read. That is the property that makes ring-fencing meaningful; without it, you have reserved stock in one system and sold it in another.
Decide the priority rule in advance
Sooner or later you will be short. Write the rule down before that happens:
- Deal orders usually win. A cancelled deal order costs you marketplace account health as well as a refund, and the customer has already paid.
- The counter is easier to serve differently. A substitute, a short wait or a part-load is a conversation; a cancelled marketplace order is a metric.
- Name who may override. If a large account can jump the queue, say who signs that off, and make the override visible in the record rather than invisible in the stock number.
Before every deal: a five-minute checklist
- Confirm the redemption cap and the deal window in writing.
- Check on-hand and on-order quantities, and the confirmed arrival date for anything you are counting on.
- Reserve the deal quantity, sized from on hand plus only the on-order stock that lands inside the window.
- Confirm the counter and other channels are now reading the reduced available number.
- Tell the counter team the deal is live and what the priority rule is.
The same problem, faster
A TikTok livestream compresses this into minutes rather than days, and the approach is identical: ring-fence before you go live, reserve rather than publish free stock, and keep the stream and the counter on one pool. See the livestream oversell playbook for the timed version.
For the general method across ordinary marketplace listings, see the oversell prevention playbook, and use the oversell risk calculator to size buffers on the channels that do not need a hard ring-fence.