A stock number on a product page is not information. It is a commitment: if you pay, you get this.
Most stores treat it as information — a figure copied from somewhere, refreshed on some schedule, roughly right. That works until two people buy the last one, or until the number was wrong to begin with, and then it stops being a data quality issue and becomes the worst experience your business can deliver.
Overselling is more expensive than running out. Running out costs you a sale. Overselling costs you a sale, plus a refund, plus a support conversation, plus the customer, plus whatever they tell people — and it happens after you have taken their money, which is the point at which trust is most expensive to break.
This is an engineering problem with a business decision at the center of it. Both halves are below.
Why the number is usually wrong
Four causes, in rough order of how often we find them.
Nobody owns it. Stock is updated when someone remembers. There is no process, so the number decays quietly between the moments someone looks.
Two systems disagree. The website has a number, the accounting package has a number, the warehouse has a shelf. Any two of them are reconciled occasionally, all three never. Every integration between them is an opportunity for drift, and drift is one-directional: it always ends with the website being the most optimistic.
Held stock is not counted. Items in other people's carts, items in unpaid orders, items reserved for a wholesale customer. The count says five; three are spoken for.
Nothing is atomic. Two customers check out within the same second. Both reads see one unit. Both writes succeed. You have sold one thing twice, and no amount of care in the warehouse will catch it, because the error happened in a few milliseconds inside your database.
That last one is the one people are most surprised by, because it does not look like a mistake anyone made. It is a correctness problem, and it has a correctness fix.
Stock as a state machine
The fix is to stop thinking of stock as a number and start thinking of each unit as being in a state. A single integer cannot express the difference between "available", "in someone's cart", "paid but not shipped" and "gone", and every overselling bug lives in that gap.
The minimum useful model:
| State | Meaning | Counts as sellable |
|---|---|---|
| Available | On the shelf, unclaimed | Yes |
| Reserved | Held for an in-progress checkout, with an expiry | No |
| Committed | Paid, not yet shipped | No |
| Fulfilled | Gone | No |
What a customer sees is Available, not total. The transition that matters is Available → Reserved, and it must be atomic: one operation that both checks and claims, so that two simultaneous requests cannot both succeed. Your database can do this. An application that reads, thinks, and then writes cannot.
The second thing that matters is that a reservation expires. Without expiry, abandoned checkouts accumulate as phantom unavailability and you stop selling things you have. With expiry, the stock returns automatically.
The pattern generalizes beyond goods
We built this exact machinery for something that is not a product: appointment slots on Bronjoy, a booking marketplace that in September 2026 listed 23,727 venues.
A time slot is inventory with a quantity of one and a very unforgiving customer. The AI receptionist that books over voice is built on a rule that is worth stealing verbatim: hold_slot returns a hold token, and book_appointment will not run without it. There is no path to a confirmed booking that skips the reservation. The hold is the reservation; the token is the proof it exists.
On the guest booking flow we had to fix the ordering itself. The original created the appointment first and sent the confirmation code afterwards — which meant any phone number could put a real booking on a partner's calendar. Now the code goes to the customer's own phone or email first, valid five minutes for one appointment, and the booking does not exist until it comes back.
Both of these are inventory lessons wearing different clothes. Reserve before you confirm. Never let an unverified request consume a real unit.
Decide your oversell policy before it happens
No system is perfect. A shelf count can be wrong, a warehouse can lose a box, a supplier can fail. So the question is not whether you will ever oversell, but what happens in the ninety minutes after you notice — and that should be a decision made calmly in advance, not improvised by whoever opens the inbox.
Write down four things.
Who finds out, and how fast. An alert when a paid order cannot be fulfilled, going to a person, not to a dashboard nobody opens.
What the customer is told, and when. Immediately, by a human-sounding message, saying what happened and what you are doing. Not a silent delay followed by a refund notification a week later.
What you offer. Refund immediately, no questions. Plus, where it makes sense: a substitute, a wait with a firm date, or a discount for the inconvenience. Offer the choice rather than deciding for them.
Whether you allow backorders at all, and if so, how they are labeled at the point of sale. A backorder a customer chose is a completely different object from one they discovered.
The rule underneath all four: say it before they ask. A customer told on day one that their item is delayed and offered a refund is usually fine. The same customer who emails on day six to ask where their order is has already decided what kind of business you are.
What "inventory management" should mean in a quote
Our e-commerce builds start at $499 and run one to five weeks, and inventory and orders is named in the store plan. But "inventory management" is a phrase that covers everything from a number field to a full multi-location system, so specify what you are buying.
Ask which of these are included:
- Stock tracked per variant, not only per product — size and color are different units
- Atomic decrement, so simultaneous checkouts cannot both succeed
- Reservations with an expiry, and a stated expiry period
- Low-stock and out-of-stock thresholds, with alerts to a person
- What the product page shows when stock is low, zero, or unknown
- Whether backorders are supported and how they are presented
- An audit trail: who changed a count, when, and why
- If stock comes from another system: which system is authoritative, how often it syncs, and what happens when the sync fails
That last group is where most real projects live, and the two questions that matter are which system wins in a disagreement and what happens during an outage. A sync that silently fails open — leaving stale optimistic numbers on the site — is how a normal week becomes a hundred oversold orders.
The display decision
One small thing with a large effect: what the page says.
An exact number ("3 left") creates urgency and creates an obligation. If it is wrong, it is conspicuously wrong. Only show it if it is genuinely accurate in real time.
A band ("Low stock") is honest and less brittle, and for most stores it is the better default.
Nothing at all is fine for products that are always available, and it is the right answer more often than stores think.
What is not fine is showing a confident number produced by a nightly export. That is a promise backed by yesterday.
And say something about lead time. "In stock, ships within 24 hours" answers the question the stock count was a proxy for anyway — because what the customer actually wants to know is not how many you have, but when they will have it.
The half-day audit
If you run a store, this is worth doing this week.
- Pick ten products. Compare the site count, the accounting count and the physical shelf. Note the gaps.
- Open a product in two browsers and check out simultaneously. See whether both succeed.
- Add a low-stock item to a cart, leave it an hour, and check whether it is still sellable to someone else.
- Look up how many orders in the last six months were refunded for unavailability, and what that cost, including the support time.
- Ask one person: what do we do when we oversell? If there are two answers, there is no policy.
Step 2 is the one that surprises people, and it takes ninety seconds.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
We only sell a handful of items a day. Is this over-engineering?
The reservation machinery, possibly. Atomic decrement, no — it is a small amount of work that removes an entire class of failure permanently, and low volume does not protect you, it just makes the collision rarer and therefore more confusing when it happens. At low volume the bigger risk is the count being wrong to begin with, which is a process problem.
Should I hide products that are out of stock?
Usually not. The page has search visibility, links pointing at it and a customer who might wait or want a substitute. Keep it, mark it clearly, and offer a notify-me or an alternative. Removing it throws away an asset to avoid an awkward sentence.
What if my stock lives in a separate system?
Then decide explicitly which one is authoritative — and it should be the operational system, not the website. Sync in one direction, log every sync, alert on failure, and decide in advance whether a failed sync should make the site conservative or optimistic. Conservative is almost always the right answer.
How long should a cart reservation last?
Long enough to finish checkout, short enough not to strand stock. Ten to fifteen minutes is a common band for goods. For something scarce with a queue behind it, shorter. The number matters less than it existing and being enforced automatically.
Is overselling ever acceptable?
As a deliberate, disclosed business model, yes — preorders and made-to-order both work that way, and customers accept them because they chose them. As a surprise after payment, no. The difference is entirely whether the customer knew before they paid.
