Kako preprečiti prodajo več kosov, kot jih je na zalogi, po kampanji ponovne zaloge

Do prodaje več kosov, kot jih je na zalogi, pride, ko obvestilo o ponovni zalogi sproži naval in tvoja trgovina še naprej sprejema naročila mimo kosov, ki jih dejansko imaš — tako prodaš 45 stvari, ki jih imaš 30, nato prekličeš 15 naročil in poješ udarec zaupanja. Preprečiš jo s štirimi nadzori, ki delujejo skupaj: sinhronizacija zaloge v realnem času, tako da izložba sekundo za sekundo ve pravo število, razmaknjena ali paketna pošiljanja, tako da 500 ljudi ne udari na blagajno v istih 90 sekundah, izhodno pravilo, ki potegne tok v trenutku, ko zaloga pade na nič, in natančnost na ravni različice, tako da »velikost 42 spet na zalogi« ne proda pomotoma velikosti 44. Preklici so drag del. Kupec ob ponovni zalogi je nekdo, ki je čakal, se navdušil in kupil — preklic pri njem tvojo stranko z najboljšim namenom spremeni v najbolj jezno. To je operativna težava, ne težava s sporočili, in vredno jo je urediti pravilno, preden sploh začneš širiti obvestila o ponovni zalogi.

Takole se prekomerna prodaja zgodi in kako zapreš vsak njen vzrok.

Zakaj je kampanja ponovne zaloge posebej dovzetna za prekomerno prodajo

Običajen dan naročila razporedi. Obvestilo o ponovni zalogi jih stisne. 500 čakajočim ljudem poveš »spet na zalogi« ob 10.00, in velik del jih poskuša kupiti v istih nekaj minutah. Ta konica je nevarnost.

Tukaj je mehanizem. Števci zaloge se ne posodobijo vedno v trenutku, ko je naročilo oddano — pogosto je zamik med »naročilo oddano« in »zaloga zmanjšana«, bodisi zaradi zamud pri sinhronizaciji platforme, predpomnjenja ali integracije, ki se posodablja vsakih nekaj minut namesto takoj. Ob običajnem curku naročil ta zamik nikoli ne šteje; naslednji kupec pride deset minut pozneje, dolgo po tem, ko je števec dohitel. Med konico ponovne zaloge se trideset ljudi odjavi na blagajni znotraj okna zamika, vsi vidijo »na zalogi«, vsi dobijo potrditev naročila — za kose, ki so že obljubljeni. Zdaj imaš prodanih preveč in edini popravek, ki je ostal, je tisti, ki boli: preklici.

Torej težava ni, da so ljudje kupili. Težava je, da so vsi kupili naenkrat, hitreje, kot je tvoj števec zaloge lahko dohajal.

Kaj prekomerna prodaja dejansko stane

Povračilo je poceni del. Povračila na kartico so enostavna. Škoda je stranka.

Pomisli, kdo je kupec ob ponovni zalogi. Izdelek je hotel dovolj, da se je pridružil čakalni listi, čakal je dneve ali tedne, videl obvestilo in skočil. To je tvoja najbolj motivirana stranka z najmočnejšim namenom za ta izdelek. Ko prekličeš njeno naročilo, ne izgubiš le tiste prodaje — vzameš nekoga, ki je bil pred 20 minutami navdušen, in mu daš občutek, da je ogoljufan, javno, če je tip, ki piše ocene. (Ilustrativni račun: prekliči 15 od 45 naročil ob ponovni zalogi na izdelku za 90 €, in povrnil si 1.350 € ter izdelal 15 ljudi, ki zdaj drugim govorijo, da je tvoja »spet na zalogi« nezanesljiva.) Izgubljena življenjska vrednost teh 15 pritlikavi povrnjenih 1.350 €.

Zato je to vredno pošteno inženirsko urediti, ne le se za to opravičiti naknadno.

Štirje nadzori, ki jo preprečijo

1. Sinhronizacija zaloge v realnem času. Prikazana razpoložljivost tvoje izložbe mora odražati pravo zalogo tako blizu hipnemu, kot ti dopušča platforma. Če se tvoja zaloga posodablja z zamikom — nekatere aplikacije za zalogo in večkanalne postavitve se sinhronizirajo vsakih nekaj minut — je ta zamik tvoje okno prekomerne prodaje med konico. Zategni ga in idealno naj blagajna ponovno preveri zalogo ob koraku plačila, ne le ob dodajanju v košarico. Oseba lahko sedi z nečim v košarici deset minut; pravo preverjanje se mora zgoditi, ko plača.

2. Razmaknjena / paketna pošiljanja. Najpreprostejši popravek prekomerne prodaje je, da konice sploh ne ustvariš. Namesto da obvestiš vseh 500 naenkrat, pošiljaj v paketih, pogojenih s preostalo zalogo, tako da povpraševanje prihaja v valovih, s katerimi tvoj števec zaloge lahko drži korak. To je isto razmikanje, ki bi ga uporabil za skopo zalogo — celotna metoda prednosti in paketov je v Prednostno razvrščanje obvestil o ponovni zalogi, ko je zaloga omejena. Paketiranje opravlja dvojno delo: ščiti zaupanje in ščiti tvojo sinhronizacijo zaloge.

3. Izstop iz toka, ko zaloga pade na nič. Avtomatizacija se mora nehati pošiljati v trenutku, ko je različica spet razprodana. Obvestilo o ponovni zalogi, ki še naprej gre ven na tretji paket, medtem ko je polica prazna, hkrati proizvaja poskuse prekomerne prodaje in razočaranje. Nadaljevanje toka veži na živo zalogo in ga prekini pri ničli.

4. Natančnost na ravni različice. »Spet na zalogi« mora pomeniti točno tisto različico, na katero je oseba čakala. Če tvoja čakalna lista ali tvoj sprožilec deluje na ravni izdelka, medtem ko se zaloga vodi po velikosti ali barvi, boš ljudem, ki čakajo velikost 44, povedal, da je izdelek spet na zalogi, ko se je vrnila le velikost 42 — in bodisi prodal preveč 42 bodisi kupce 44 poslal v zid. Sproži se na zalogi točno določene različice in obvesti le ljudi, ki čakajo na to različico.

Logika rezervacije in zadržanja — vredna nad določenim pragom

Za omejene ponovne zaloge z velikim povpraševanjem nekatere platforme omogočajo, da kos zadržiš za kratko okno, ko je enkrat v nečji košarici ali ko pride do blagajne — rezervacija, ki poteče, če ne dokonča. To v celoti odstrani tekmo: kos je njihov, recimo za 10 minut, in nihče drug ga v tem oknu ne more zgrabiti.

Ni pa zastonj. Agresivna zadržanja lahko zaklenejo zalogo za ljudi, ki opustijo, in za kratek čas kažejo »razprodano« pravim kupcem, medtem ko kosi ležijo rezervirani za radovedneže. Torej je logika rezervacije smiselna pri resnično skopih, visokovrednih izdih in je pretiravanje pri rutinski ponovni zalogi. Uporabi jo tam, kjer bi te preklic resnično stal, ne povsod.

Točno kaj avtomatizirati

  • Sprožilec: zaloga točno določene različice se vrne na razpoložljivo (na ravni različice, nikoli na ravni izdelka).
  • Občinstvo: le stiki, ki čakajo na točno to različico.
  • Struktura pošiljanja: paketno, pri čemer je vsak paket pogojen s preostalo zalogo, ne s fiksnim časovnikom.
  • Nadzor blagajne: zaloga ponovno preverjena ob koraku plačila; sinhronizacija zaloge v realnem času (ali blizu realnega časa) med naročili in izložbo.
  • Meja pošiljanja: ne obvesti več ljudi na paket, kot jih zaloga verjetno lahko vpije (glej logiko velikosti paketa v vodniku za prednostno razvrščanje).
  • Izhodni / ustavljalni pogoj: različica pade na nič → tok se takoj ustavi; kdorkoli kupi, izstopi iz preostalih korakov.
  • Neobvezna rezervacija: kratko zadržanje v košarici/na blagajni pri skopih visokovrednih izdih.
  • Cilj: vsak obveščen kupec, ki dokonča blagajno, dejansko prejme izdelek — nič preklicev.

Rdeča nit: vse veži na živo zalogo. Pošiljanja, nadaljevanje in blagajna vsi popuščajo pravemu števcu.

Predelan primer

Trgovina dopolnjuje zalogo prehranskega dopolnila za 75 €, ki hitro prodaja, 60 kosov nazaj, 640 na čakalni listi. (Ilustrativno.)

Namesto enega razpošiljanja paketijo: najprej 200 ljudi, pogojenih z zalogo. Blagajna ob plačilu ponovno preveri zalogo, tako da se, ko se 60 kosov troši, izložba prevesi na »razprodano«, preden gre lahko števec v minus. V trenutku, ko zaloga pade na nič, se tok ustavi — drugi paket se nikoli ne sproži. Zamudnik, ki je imel izdelek v košarici, ob plačilu zadene »razprodano«, namesto da dobi potrditev, ki jo pozneje prekličejo. Nikomur naročila ne potegnejo.

Nobene izmišljene stopnje uspeha. Bistvo je ožičenje: paketno povpraševanje, žive preverbe zaloge ob plačilu in trd ustavek pri ničli pomenijo, da trgovina nikoli ne obljubi več kosov, kot jih ima.

Kaj meriti

  • Stopnja preklicev / prekomerne prodaje pri naročilih ob ponovni zalogi — glavna številka. Preklici, poganjani z ponovno zalogo, naj bodo blizu nič. Karkoli nad curkom pomeni, da eden od štirih nadzorov odpoveduje.
  • Oddana naročila proti razpoložljivim kosom na ponovno zalogo — če oddana naročila presegajo kose tudi le občasno, ima tvoja sinhronizacija zaloge ali preverjanje na blagajni vrzel.
  • Čas med razprodajo in zadnjim pošiljanjem — bi moral biti praktično nič. Vrzel pomeni, da je tok pošiljal še potem, ko je zaloge zmanjkalo.
  • Zahtevki za podporo, označeni s ponovno zalogo — skok zahtevkov »kje je moje naročilo / zakaj je bilo preklicano« je prekomerna prodaja, ki se pokaže kot obremenitev podpore in izjedeno zaupanje.

Kako pomaga Omnisend

Preprečevanje je tu večinoma disciplina zaloge, a pošiljalna stran — paketiranje, sprožilci na ravni različice in ustavljanje pri ničli — živi v tvojem orodju za avtomatizacijo. Preizkusil sem Klaviyo in Omnisend in v svojih trgovinah uporabljam Omnisend, delno zato, ker avtomatizacija ponovne zaloge bere prave podatke o izdelku in zalogi, tako da se tok lahko sproži na pravi različici in izstopi, ko je izginila.

Pomembni deli: sprožilci ponovne zaloge na ravni različice, pogojni koraki, tako da se paketi sprostijo le, dokler zaloga ostaja, in samodejni izhod, ko nekdo kupi ali izdelek poide. (Omnisend je orodje, ki ga uporabljam in priporočam; morebitna partnerska povezava tu je razkrita — pošiljalni nadzori delujejo v vsaki platformi z avtomatizacijo na ravni različice, ki upošteva zalogo.)

Iskrena omejitev: tvoje email orodje ne more popraviti počasne sinhronizacije zaloge znotraj platforme tvoje trgovine ali blagajne, ki zaloge ne preverja znova. Avtomatizacija nadzoruje pošiljalno polovico težave prekomerne prodaje; zalogovna polovica živi v postavitvi tvoje trgovine in obe moraš zapreti. Odločanje, koga obvestiti prvega, je ločeno vprašanje — to je Prednostno razvrščanje obvestil o ponovni zalogi, ko je zaloga omejena, delitev seznama po vrednosti stranke pa je Kako segmentirati naročnike na ponovno zalogo po vrednosti stranke.

Tvoj naslednji korak

Pred svojo naslednjo ponovno zalogo preizkusi eno stvar: postavi izdelek na 1 kos zaloge, nato ga poskusi kupiti v dveh oknih brskalnika hkrati. Če obe blagajni uspeta, imaš vrzel prekomerne prodaje — tvoja zaloga se ob plačilu ne preverja znova. Popravi to, preklopi svoja pošiljanja ob ponovni zalogi na paketno-in-pogojeno-z-zalogo in nastavi tok, da izstopi pri ničli. Te tri spremembe odstranijo večino preklicev ob ponovni zalogi.

Če so ti obvestila o ponovni zalogi nova, začni s samo postavitvijo: Kako nastaviti obvestila o ponovni zalogi za spletno trgovino.

How to Prevent Overselling After a Back-in-Stock Campaign

Overselling after a back-in-stock campaign is prevented with four controls: size the notified audience to the units you actually have (2-3 notified subscribers per unit, released in waves), keep a stock buffer so alerts stop sending before inventory truly hits zero, make sure your alert platform reads live inventory rather than a delayed sync, and remove buyers from any remaining sends the moment they order. Most oversells trace back to one cause — the campaign created demand faster than the store’s stock numbers could keep up — so every fix is about slowing the demand release or speeding up the inventory truth.

How a successful campaign turns into refund emails

The scenario is painfully specific. You restock 30 units, send the alert to a 250-person waitlist, and the response is better than you hoped. But your inventory sync runs every 15 minutes, three people had the last unit in their carts at once, and a marketplace channel sold four units of the same stock pool in parallel. By evening you’ve taken 34 orders for 30 units.

Now you’re writing the worst email in ecommerce: “We’re sorry, your order can’t be fulfilled.” To your most enthusiastic customers — the ones who signed up to be told the instant this product returned, then acted on it within minutes. A refund plus an apology discount eats the margin on several good orders, the chargeback risk goes up, and a customer who raced to buy learns that winning the race means nothing at your store. The next restock alert you send them will be ignored.

Why “sell it all, sort it out later” isn’t a strategy

Some merchants accept occasional oversells as the cost of aggressive campaigns, reasoning that a refund is cheap. It isn’t. The direct cost is small — the trust cost is not, and it lands precisely on high-intent repeat buyers. Others overcorrect: they under-notify so heavily that stock sits unsold for weeks, which defeats the point of holding a waitlist. And throwing ads at a restock while this problem is unsolved makes it strictly worse, because ads add unpredictable demand on top of the demand spike you engineered. The answer is control of the release, not more or less enthusiasm.

The math of an oversell

Illustrative numbers. A store oversells 6 units of an €85 product. Direct damage: 6 refunds, roughly €30 of payment fees and support time, and say a 10% apology voucher to each affected customer that a few redeem later — perhaps €150 all-in. Small. But suppose 2 of those 6 were repeat customers averaging 3 orders a year at €85. If the experience costs you even one of those relationships, that’s about €255 a year in quiet lost revenue, every year — from a single restock morning. The invisible cost outweighs the visible one, which is why this problem is worth an afternoon of setup.

Fix it in this order

  1. Set a stock buffer today. Configure your restock alert to treat “in stock” as inventory above 3-5 units, not above zero. This is the highest-value five-minute change: the last few units absorb sync delays, simultaneous checkouts, and returns re-entering stock.
  2. Ratio the audience to the units. Before any restock send, divide waitlist size by unit count. Above roughly 3:1, don’t blast — release in waves with a stock check between them, exactly as in prioritizing back-in-stock alerts when inventory is limited.
  3. Verify the sync speed. Find out how often your alert tool reads inventory from your store, and how fast your store deducts stock across channels (site, marketplaces, POS). If any leg lags more than a few minutes, widen the buffer to cover it.
  4. Add purchase-based exits. Anyone who buys must leave the remaining sequence immediately — a reminder email to someone who already ordered is harmless, but a reminder to 80 people after stock ran out is 80 oversell attempts.
  5. Later, if oversells persist: per-customer purchase limits on scarce products, and reserving cart contents for a fixed window at checkout if your platform supports it. Don’t start here; the buffer and the ratio solve most cases.

What the automation itself should look like

Trigger: inventory crosses the buffer threshold upward (e.g. rises above 5), not “above 0.” Segment per wave: waitlist subscribers, capped at about 2-3 per available unit, best customers first. Delay: first wave immediate; each later wave 3-4 hours after the previous one. Condition before every send: current stock above the buffer — if not, the send is cancelled, silently. Channel: email as the base; if you add SMS for the first wave, keep its audience smallest, because SMS reacts fastest and can empty the stock before email recipients even open. Content: state the truth — “back in a small batch” — and never promise availability (“reserved for you”) that you can’t enforce. Goal: sell out to notified subscribers with zero orders beyond stock.

One content detail prevents a subtle oversell path: link to the product page, not a pre-filled checkout, when stock is very tight. A product page shows live availability; a cached checkout link can accept an order the page would have refused. If your alerts get strong clicks but the orders aren’t materializing, that’s usually a different failure — why back-in-stock emails get clicks but no orders walks through it.

A quick illustration of the buffer doing its job

Invented but typical. A store restocks 25 candles at €29 with a buffer of 4. Wave one goes to 60 subscribers at 9:00. By 12:30, orders have pushed stock to 4 — the 13:00 second wave checks inventory, finds it at the buffer, and cancels itself. The remaining 4 units sell through normal site traffic over two days, absorbing one simultaneous-checkout collision without a single oversold order. The 90 subscribers in wave two got nothing — and that’s correct; a courtesy “sold out before your turn, you’re first in line next time” email costs nothing and keeps them warm.

Metrics that catch trouble early

  • Oversold orders per restock — the headline number; target is zero.
  • Notified-to-available ratio — audience size divided by units at send time, checked before every campaign.
  • Sold-out clicks — subscribers clicking an alert onto an empty page; rising means your waves or buffer are mis-sized.
  • Refund rate on restock-attributed orders — compare it with your store baseline; a gap points at fulfilment promises the campaign made.

Where Omnisend fits

When I compared tools for my own stores, one reason I settled on Omnisend over Klaviyo was that I could self-manage exactly this kind of conditional logic without an agency: the back-in-stock trigger from Shopify or WooCommerce, delay blocks between waves, and stock-level conditions sit in one visual builder. Be honest with yourself about the dependencies, though — Omnisend can only be as current as the inventory your store platform reports, so multi-channel stock (marketplaces, POS) needs a proper sync at the platform level first. No email tool fixes a stock ledger that’s wrong at the source. If sends are firing at odd times or skipping conditions, work through how to troubleshoot back-in-stock automation before blaming the buffer.

Your next step

Open your restock alert settings and check one thing: does the alert fire at “stock > 0”? If yes, change it to “stock > 4” right now. It’s the single cheapest insurance policy in this whole article.

Leave a Reply

Your email address will not be published. Required fields are marked *