Running a limited release without overselling

You have forty boxes. Two hundred people want them. You post the link, and in the ninety seconds that follow you take fifty-three orders. Now you are writing thirteen apologies and thirteen refunds, and the people who clicked at exactly the right moment are the ones who lost.

That is not a marketing problem. It is a timing problem with a specific technical cause.

Why a plain product page oversells

A normal storefront checks stock when you press pay. If forty people press pay in the same second, all forty read "40 remaining" before any of them has finished paying, and every one of those checks passes. Stock only goes down when the payments land, by which point the damage is done.

The fix is to move the moment of truth earlier: the unit has to be claimed when it goes into the cart, not when the card clears.

Claim first, pay second

In ibakepro, a drop is a set quantity per product for a scheduled window. When a shopper adds a drop item to their cart, the unit is not checked against the count. It is claimed from it, there and then, and held for that shopper until the sale completes or the hold lapses.

Two details matter more than they look:

It is all or nothing. If a cart takes units across several lines and any one line would go past what is left, nothing in that add is claimed and the whole add fails. You never get the half-successful cart that quietly sells one thing it does not have.

If the count cannot be confirmed, no sale happens. For any reason at all, the shopper is told reservations are temporarily unavailable. A sale never goes through on a count nobody checked.

On successful payment the hold is consumed and the stock stays down.

What comes back, and when

Three different things return stock, and they behave differently.

Abandoned carts come back on their own. A hold that lapses returns to the count without anyone doing anything, whether or not there is a shopper on the page at the time. Nothing for you to press.

A cancelled drop releases every live hold at once.

A cancelled or fully refunded order puts its units back.

When any of this goes wrong, it goes wrong toward showing sold out while a unit is technically free. It is not built to be exact, it is built to never sell you into a hole.

Two different caps

A drop item has a quantity, or you can mark it unlimited, in which case it carries no hold at all and behaves like a normal catalog line inside the drop.

Separately, an item can carry a maximum per customer, which is what stops one person taking the whole run. It is applied while someone is shopping and again at checkout, and it counts what that customer already bought on earlier orders for the same drop. Over the cap, the checkout is refused rather than the order being trimmed.

By default a drop is exclusive: while it is live, its products are pulled from the normal catalog listing, and a cart line for one of them is rejected at checkout unless it came through the live drop. That is what stops someone routing around the cap by buying the product the normal way. You can opt a drop out of that if you want the products sold both ways.

For a release where you expect a genuine crush there is an optional waiting room: shoppers wait at the door and are admitted in batches, strictly in the order they arrived.

The waitlist is a list, not a megaphone

A waitlist signup does more than collect an address. It creates or merges a customer record, records where the consent came from and tags the person both as a waitlist joiner generally and for this drop specifically. That per-drop tag is what makes them an audience later.

Now the part to be honest about, because it is the opposite of what "join the waitlist and they will be told" implies. Announcing to a waitlist does not send anything by itself. It builds a campaign against that audience and leaves it as a draft. You open it, read it and send it. Consent is checked again at dispatch.

There is one way to make it hands-off, opt-in per drop. Turn on auto-announce and pick an offset, and scheduling the drop schedules the announcement too: at launch, or one, six or twenty-four hours before. That one does go out on its own. Edit the drop and the schedule moves with it. Turn it off and an unsent announcement is pulled back to a draft rather than fired.

Automatic if you set it up that way, manual otherwise. Neither is "told the moment it opens" unless you chose the offset that means that.

What the results view tells you

Results attribute orders back to the drop line by line: units and revenue per product, sell-through against the cap you set, order count and distinct buyers. Time to sell out appears only when a sold-out event was recorded, so treat a blank as "not captured" rather than "never sold out".

Remarketing gives you two audiences built from the tags: everyone who bought, and everyone who joined the waitlist and did not. Both open as drafts with starting copy, for you to edit and send.

Setting up a drop is four decisions

Naming the drop, giving it a launch time, adding products with quantities and deciding on per-customer caps. That is the work.

What you are not doing is watching a counter, manually closing sales or refunding because two people bought the last one. The oversell case is handled below the level you can see. The parts that involve talking to customers stay in your hands, because those are the parts where an automated mistake is expensive.

If you have never run one, size the first release smaller than you want to. Set a quantity you would be glad to sell out of, cap it at one or two per customer and open the waitlist a good while before you open the drop, so you can see the shape of the demand before you commit to a number. The results view then hands you the only benchmark worth having: units sold, distinct buyers and how much of the run cleared, from your own list rather than someone else's.

How many you can actually make in the window is the other half of that number, and it is a production question rather than a drops one. Planning production and cutting waste covers the part where the oven, not the counter, is the constraint.