Pre-orders Done Right: Separate Inventory Pools, Payment Timing, and Shipping Promises

Pre-orders are good business: collect the money first, stock up later, beautiful cash flow — and you get real orders to negotiate volume with suppliers. But the most common way pre-orders die is being run through the same inventory and the same order flow as in-stock goods. A customer's order mixes in-stock and pre-order items, so the whole order stalls waiting for the slowest one; the warehouse sees an order and picks, shipping someone else's in-stock goods against a pre-order; and from then on, nobody can explain the inventory numbers.

We run our own e-commerce operation and have built pre-order systems for clients, and the conclusion is consistent: a pre-order is not "in-stock goods that ship later" — it's a different product state that needs dual-track management. This piece covers the three core designs: inventory separation, payment timing, and the shipping promise.

Inventory separation: the pre-order pool and the in-stock pool can't share one number

The root of the chaos is usually one inventory field doing all the work. The correct approach splits "sellable quantity" into two layers:

• In-stock pool: quantity physically in the warehouse, shippable now — sell one, deduct one.
• Pre-order pool: a "committed quantity" based on a purchase order or production schedule. If the next batch arriving is 500 units, the pre-order cap is 500 minus a safety margin. It draws down future goods and is fully independent of the in-stock ledger.

On arrival day, the system performs a "pre-order pool roll-over into the in-stock pool": goods are received into inventory, and pre-orders are allocated in sequence and moved to awaiting-shipment. That roll-over must leave an audit trail, or stocktaking will never reconcile. Also, when a product has both in-stock and pre-order availability at once, the product page should make the customer explicitly choose one (the batch shipping now vs. the next pre-order batch) — not have the system quietly guess behind the scenes.

Payment timing: full payment, deposit, or pay on arrival?

The mainstream for Taiwanese e-commerce pre-orders is full payment at order time, for practical reasons: the simplest money flow, the lowest abandonment, the best cash flow. The price is a heavier promise — with the money already collected, every day of delayed delivery burns trust. If you choose a deposit model (common for high-ticket, long-lead-time categories), system complexity goes up a tier: one order carries two payment legs and two invoice legs, balance-due collection must be automated, and the rules for abandoned balances (is the deposit refundable?) must be spelled out on the purchase page — otherwise you have a consumer-protection dispute.

Don't miss invoice timing either: in practice, a government e-invoice should be issued when payment is collected — collect the full amount on a pre-order, issue for the full amount (details per your invoicing setup and your accountant's advice). If the amount changes later, handle it via void-and-reissue or a credit note — we unpack this fully in automated e-invoice issuance.

The shipping promise: be specific, leave slack, communicate first

Ninety percent of pre-order complaints aren't about waiting — they're about "not knowing how much longer." Battle-tested principles:

1. Promise a date range, never "ships promptly upon arrival." "Expected to ship in batches June 15–25" gives customers an anchor they can check against; vague phrasing just makes customer service answer the same question daily.
2. Discount your internal lead time before promising externally. If the supplier says goods arrive June 1, tell the public you ship June 15. The slack isn't laziness — it's customs, QC, and labeling, the surprises that always happen. Shipping early is a delight; shipping late is an incident.
3. Announce delays proactively, with a concrete new date and remedy options. Admitting a delay only after customers come asking is how trust dies. A proactive notice plus a "can't wait? full refund" option actually persuades most people to keep waiting.
4. Decide mixed-order shipping rules in advance. A customer orders in-stock and pre-order items together: hold the whole order until the pre-order arrives (saves shipping, worse experience), or split and ship the in-stock items first (better experience — but who absorbs the extra shipping)? We recommend letting the customer choose at checkout, with the shipping rules written out.

Pre-orders sell a promise; in-stock sells a product. Keep both on the same ledger and sooner or later you lose control of each.

One last reminder: the moment a pre-order opens often brings a high-concurrency rush, and poorly built stock deduction will oversell just the same — we cover that separately in preventing overselling. If your current system can't distinguish a pre-order pool from an in-stock pool, that's usually not a settings problem but a data-structure problem — come talk to us about e-commerce system development.