Building a Pre-Order System That Handles Delays Gracefully

Pre-orders are the most useful commercial tool a small publisher has. They de-risk the print run, they concentrate sales into a window, and they tell you what demand looks like before you commit money to paper.

They also carry a specific operational risk that most stores are not built for: the date moves. Printers slip, shipping is delayed, a proof comes back wrong. When that happens, the difference between a minor inconvenience and a refund wave is almost entirely down to how the system was built.

Decide when you take the money

Two models, and the choice has consequences.

Charging at order time gives you cash immediately, which is often the point, since the money is funding the print run. It also means you are holding customer money against an undelivered product, which in many jurisdictions comes with obligations about maximum delay and refund rights. Card authorisations also expire, so a long pre-order window can produce failed captures if you defer.

Charging at dispatch is cleaner legally and better for the customer, and it does not help with cash flow at all. Expect a meaningful proportion of payment methods to fail by the time you come to charge them, because cards expire and get replaced.

Most publishers charge at order and accept the obligations. If you do, say so plainly at checkout, including the expected date and the refund position.

Mixed baskets, which is where most systems break

Someone orders a pre-order title and an in-stock title together. Your system needs to decide, and to tell the customer, whether that ships as one parcel when everything is ready or as two parcels with the available item going first.

Both are reasonable. Neither is acceptable as a surprise. Present the choice at checkout, with the shipping implications visible, and default to whichever your fulfilment can actually deliver consistently.

The date field is not one field

This is the design detail that makes delays survivable. Store three things separately: the publication date, the expected dispatch date, and the date communicated to the customer at the time they ordered.

When the printer slips, you update the expected dispatch date, and the system can now identify every customer whose communicated date is no longer accurate and generate a specific message to them. Without that separation, you are exporting a list and writing emails by hand at exactly the moment you have least time.

Communicate before the date passes, not after

This is the entire difference between a delay and a crisis.

A customer told two weeks in advance that their book will now arrive in March rather than February will nearly always accept it. The same customer, having heard nothing, who reaches the promised date with no book and no message, is now in a support queue and thinking about a refund.

Automate a check that runs against the pre-order list, and require a decision when the expected date is within a set window and stock has not arrived. Send the update proactively. Include the reason, briefly and honestly. Include the new date. Include a clear refund option, because offering it up front is what stops most people from wanting it.

Give the pre-order period a real incentive

If a pre-order gets exactly what a later order gets, there is no reason to accept the wait and the risk. Number the first printing, include a signed bookplate, list names in the back matter, offer a print or a digital extract on order.

Whatever it is, it must genuinely end when the pre-order window ends. If people learn that waiting costs nothing, your pre-order window stops working permanently.

The reporting that matters

A pre-order dashboard needs four numbers: units committed by title, revenue committed, days until expected dispatch, and how many customers have been told a date that is no longer correct.

That fourth number is the one that should be visible on the wall. It is the only number that predicts a support problem before it arrives.