Amazon FBA vs FBM, which fulfilment model to pick
A comparison of the Amazon FBA and FBM logistics models: costs, control, requirements, and how to manage orders and invoices whichever fulfilment method you choose.
A backorder lets you accept an order for a product you do not currently hold, and fulfil it once stock returns. Here is when it is worth switching on, how to set the dates and the customer messages, and how to stop it turning into overselling.
A backorder is accepting an order for a product you do not hold at that moment, on the understanding that you will fulfil it once stock returns. The customer orders and pays, or reserves the goods now, and despatch starts when the delivery from your supplier reaches you. You will also see it called a pending order or selling to order.
The point is simple. Demand for the product exists right now, and you do not want to lose it just because the warehouse happens to be empty. Instead of pulling the listing and sending the customer to a competitor, you collect the order and fulfil it later. A well-run backorder rescues the sale and tells you how many units to reorder. A badly run one turns into a string of cancellations and disappointed customers.
Backorders and preorders work alike technically, but they describe two different situations. They are worth separating, because customers approach each differently.
The difference shapes the message. With a backorder you reassure: the goods are coming back and we know the date. With a preorder you build anticipation for something new. In both cases the panel mechanics are similar, because you accept an order beyond current stock and fulfil it later.
This distinction matters most for the safety of your store. From the outside they look alike, because in both you sell more than sits on the shelf. Everything else about them differs.
A backorder is planned. You decide that a given product can be ordered ahead, you state a date, and you tell the customer before they click buy. Overselling is an accident: two channels showed the product as available although the last unit had gone, and a second customer ordered something that physically is not there. Nobody planned it and nobody was warned.
The consequences differ too. A backorder ends with delivery on the promised date. Overselling usually ends with a cancellation, a refund and a bad review, and on marketplaces with a penalty for the unfulfilled order on top. The key takeaway: you may only switch backorders on once you control your stock. Without that, backorders and overselling blur into the same thing.
Backorders do not suit every range. They work when several conditions hold at once.
| A backorder makes sense when... | Better to take the listing down when... |
|---|---|
| Your supply chain is steady and predictable | The supplier's delivery date is uncertain |
| The product returns to stock regularly | It is a one-off batch or a discontinued model |
| The customer accepts a reasonable wait | The buyer expects despatch right now |
| You sell in your own store, in full control | You sell on a marketplace that penalises delays |
| The goods have a long shelf life | The product is seasonal with a hard date, or perishable |
There is one boundary rule: accept backorders only for what you can genuinely deliver. If you are unsure when stock will be replenished, it is more honest to pull the product from sale for a while than to collect orders you cannot close. A backorder builds trust only when you keep the delivery promise.
A well-organised backorder rests on a few elements that have to work together.
Not every product suits pending orders. Choose items with predictable supply, and decide how many backordered units you will accept before the risk passes a sensible level. A limit protects you from collecting hundreds of orders for goods your supplier cannot deliver in time.
The despatch date is the heart of a backorder. Give it on the product page and in the basket, not only after the purchase. Better to state a cautious, dependable date and beat it, than to promise too much and keep moving the date.
A waiting customer needs confirmation that everything is on track. Automatic e-mail notifications about order status are the minimum: confirmation that the backorder was accepted, a note if the date changes, and a message the moment the parcel is despatched. Silence at this stage is the most common cause of cancellations and support tickets.
Backorders may only be switched on atop a foundation: a central stock level read by every channel. If you sell on several platforms at once, on Allegro and in your own WooCommerce store, each channel has to see the same current unit count and the same backorder pool. Otherwise pending orders from different places start overlapping, and you lose track of how much you really need to reorder.
Running backorders by hand stops being sustainable as order numbers grow. You have to remember which orders wait on which goods, in what order to fulfil them, and when to send a notification. Across several channels you also have to police the shared pool.
This is where a central warehouse comes in. In the NavyFlame warehouse module you keep one stock level for every connected platform. After each sale the shared pool drops and the new figure goes out to the channels, so the window for overselling shrinks to seconds. On that foundation a backorder stops being a risk and becomes a deliberate decision: you know exactly how many units are ordered beyond stock and how many you must replenish.
Then comes automation. Instead of policing every pending order by hand, you rely on rules and notifications that carry the customer through the wait. When the delivery lands and stock rises, you fulfil the waiting orders first and the system tells the buyers their parcel is on the way.
A backorder is how you avoid losing a sale when the demand is there and the warehouse is briefly empty. You accept an order for something you do not hold, and fulfil it once stock returns. The condition is honesty: a clear date, straight communication and real control over supply.
Do not confuse a backorder with a preorder, which covers products before launch, and certainly not with overselling, the accidental sale of goods with nothing behind them. A backorder is safe only on the foundation of one shared stock level, updated automatically after every sale, and sensible notification automation. Start by putting stock and communication in order, and only then open pending orders on selected, predictable products.
A backorder is an order for a product you do not currently hold, accepted on the understanding that you will fulfil it once stock returns. The customer pays or reserves the goods now, and despatch follows when your delivery arrives. It applies to products you normally sell and that will come back into stock, not to a one-off clearance of leftovers.
A backorder covers goods that were already on sale, ran out for a while and will return once you reorder from your supplier. A preorder covers a product that has not launched yet. Accepting the order works much the same way, but the reason for the gap differs: a backorder is a temporary shortage, a preorder is a product that does not exist yet.
No. A backorder is a deliberate, planned sale beyond current stock, with clear information for the customer and a realistic delivery date. Overselling is an accidental sale of goods you do not have, caused by stock drifting apart between channels. A backorder is controlled and communicated; overselling is a mistake that usually ends in a cancellation and a disappointed customer.
Give the expected despatch date on the product page and in the basket, and confirm it by e-mail once the order is placed. When the delivery arrives, send a despatch notification. Honesty about the date is what counts: better to give a cautious, realistic date and beat it, than to promise too much and keep pushing despatch back.
When you are unsure of your supplier's delivery date, for products with a short shelf life, for seasonal goods with a hard deadline, or on strict marketplaces that penalise delays and cancellations. In those cases it is safer to take the listing down until stock returns than to accept orders you may not deliver on time.
A comparison of the Amazon FBA and FBM logistics models: costs, control, requirements, and how to manage orders and invoices whichever fulfilment method you choose.
A seasonal checklist for getting a store ready for Black Friday and Cyber Monday: stock levels, invoices, carriers, monitoring and surviving the peak.
An API in e-commerce is the interface stores and marketplaces use to exchange data with other systems. A plain explanation of REST APIs, webhooks and API keys, and what a seller gets out of them.
See how NavyFlame keeps one shared stock level and pushes availability out to your connected platforms. Click through the demo with no sign-up.
See the demoWe use cookies to keep the site working, to measure traffic and to personalise content. Read more in our privacy policy.
Manage preferences