Kdaj poslati obvestilo o ponovni zalogi?

Obvestilo o ponovni zalogi pošljite tisti trenutek, ko je izdelek zares na voljo in ga je mogoče kupiti – ne takrat, ko pošiljka prispe v vaše skladišče, ne takrat, ko se potrdi naročilnica, temveč takrat, ko je varianta v vaši trgovini resnična, prodajljiva številka in bi nekdo dejansko lahko opravil nakup. V praksi to pomeni, da obvestilo sproži takoj ob dogodku žive zaloge, z dvema varovalkama: ne obveščajte o zalogi, ki še ni zares prodajljiva, in pri veliki seznamu prijav na omejeno zalogo razporedite pošiljanje, da tisoč ljudi ne pošljete na stran, na kateri je le štirideset kosov. Hitrost je tukaj pomembna, ker povpraševanje po ponovni zalogi hitro upade in izdelek se lahko v nekaj urah spet razproda. A hitrost ob napačnem trenutku – obveščanje, preden je zaloga kupljiva – je slabša od čakanja, saj vaše najbolj vroče stranke pošljete v zid.

Takole določite pravi trenutek, da obvestilo prispe, ko lahko dejansko pripelje do nakupa.

»Na zalogi« in »kupljivo« nista isti trenutek

To je past, v katero se ujame večina trgovin. Zaloga se v sistemu pojavi, preden je dejansko prodajljiva, in če se vaše obvestilo sproži ob napačnem signalu, ste ljudi z e-pošto poslali na stran, na kateri še vedno ne morejo kupovati.

Nekaj načinov, kako »na zalogi« zavaja:

  • Pošiljka je prispela, a še ni prevzeta v prodajljivo zalogo. Kosi so fizično tam; trgovina še vedno prikazuje nič ali jih prikazuje, a blokira nakup. Obvestite zdaj in gumb ne bo deloval.
  • Zaloga je rezervirana, ne razpoložljiva. Del tega števila je že obljubljen naročilom na čakanju ali rezervacijam. Številka je videti zdrava; prodajljiva številka je precej manjša.
  • Varianta je spet tu, a je izdelek še vedno nastavljen kot osnutek ali skrit. Število se je posodobilo; stran ni objavljena.

Sprožilec torej ne bi smel spremljati »ali se je zaloga spremenila«. Spremljati bi moral »ali je ta varianta zdaj pozitivna, razpoložljiva za prodajo na živi, kupljivi strani«. To sta različna dogodka in ravno v razmiku med njima nastanejo slabo tempirana obvestila. Če niste prepričani, da vaša nastavitev to razlikuje, so mehanizmi sprožilca opisani v Kako nastaviti obvestila o ponovni zalogi za spletno trgovino.

Zakaj je takojšnje pošiljanje boljše od »zbatchamo za jutri zjutraj«

Ko je izdelek zares kupljiv, pošljite takoj. Povpraševanje po ponovni zalogi ima kratek rok trajanja in dve stvari delujeta proti vam, čim dlje čakate.

Prvič, izdelek se lahko spet razproda. Če ste ponovno napolnili majhno serijo priljubljenega izdelka in sedite na obvestilu do »boljšega časa pošiljanja«, lahko organski promet in vračajoče se stranke izpraznijo police, preden vaš čakalni seznam sploh sliši, da je izdelek spet tu. Ljudje, ki so izrecno prosili, da jih obvestite – vaše najbolj vroče stranke – zamudijo priložnost naključnim obiskovalcem. To je narobe.

Drugič, namera pojenja. Oseba, ki se je prijavila pred tremi tedni, je še vedno zainteresirana, a z vsakim dnem, ki mine, jih nekaj kupi drugje, pozabi ali izgubi zagon. Če jih dosežete na dan, ko se izdelek vrne, ujamete več te namere, kot če jih dosežete šele takrat, ko odide vaš naslednji načrtovani batch.

Privzeto torej velja: sproži ob dogodku kupljivosti, takoj. Spodnje izjeme se nanašajo na to, kako pošiljate, ne na to, ali čakati.

Kdaj počakati – na kratko – namesto da sprožite takoj

Obstaja nekaj poštenih razlogov, da dodate kratek, nameren zamik. Ne zamik »pošlji jutri« – majhen pribitek, s katerim zagotovite, da se obvestilo ne sproži ob majavi zalogi.

Kratek pribitek za preverjanje. Če je znano, da vaš vir zaloge migeta – varianta, ki na kratko prikaže 5, nato pa spet pade na 0, ko sinhronizacija popravi podatek – zelo kratek zamik (recimo potrditev, da je zaloga čez nekaj minut še vedno pozitivna) prepreči, da bi obvestilo poslali o številki, ki izgine. To je popravek kakovosti podatkov, ne marketinška odločitev. Prava rešitev so čistejši podatki o zalogi; pribitek zgolj ustavi najhujše zgrešitve, medtem ko to urejate.

Ponovna zaloga, premajhna za seznam. Če čaka 900 ljudi in ste dopolnili 50 kosov, pošiljanje vseh 900 naenkrat pomeni, da jih 850 klikne in ugotovi, da je spet razprodano – zid, v velikem obsegu. Tu ne zadržite celotne pošiljke; razporedite jo. O tem več v nadaljevanju.

Razporejanje pošiljanja, ko je zaloge malo

Ko je čakalni seznam precej večji od ponovne zaloge, takojšnje pošiljanje vsem povzroči navalno stampedo. Prvi kupci v nekaj minutah izpraznijo zalogo in vsi za njimi zadenejo ob »razprodano« – ravno tisto razočaranje, ki ste ga z obvestilom želeli preprečiti, zdaj dostavljeno stotinam ljudi naenkrat.

Zato razporedite. Pošiljajte v valovih – prvi batch takoj, naslednji nekoliko kasneje in tako naprej – grobo prilagojeno zalogi, ki jo imate. Vrstni red valov je prava odločitev: vaše najboljše stranke, ali ljudje, ki so čakali najdlje, ali tisti, ki so imeli izdelek v košarici, si zaslužijo, da slišijo prvi. Ta razvrstitev po prednosti je tema zase – Kako določiti prednost obvestilom o ponovni zalogi, ko je zaloga omejena – a načelo tempiranja je preprosto: ne usmerjajte na police več povpraševanja, kot ga police zmorejo naenkrat.

In ne glede na to, kako razporejate, mora biti pravilo izhoda živo: v trenutku, ko se varianta spet razproda, ustavite preostale pošiljke. Nima smisla obveščati tretjega vala o zalogi, ki je že pošla. Kar je pravzaprav tudi problem preprodaje – glejte Kako preprečiti preprodajo po kampanji ponovne zaloge.

Ali je čas dneva pomemben?

Manj, kot bi mislili, in naj vas ne zadrži. Privlačnost »vaš točno določen izdelek je spet tu in se prodaja« premaga običajne ritme odpiranja – ljudje odprejo obvestilo o ponovni zalogi zaradi tega, kar piše, ne zaradi tega, kdaj prispe. Zadrževanje zares kupljivega obvestila za šest ur, da bi zadeli »optimalni pošiljanju ob 10h«, tvega, da se izdelek v teh šestih urah razproda. Ni vredno.

Če tako ali tako razporejate valove, potem seveda – potisnite batche proti budnim uram na vašem glavnem trgu, namesto da četrti val sprožite ob 3h zjutraj. A pošiljanje v trenutku, ko je izdelek kupljiv, vsakič premaga pošiljanje ob popolni uri.

Praktičen primer

Trgovina ponovno napolni zalogo jakne za 90 € , ki je bila mesec dni razprodana, s 400 ljudmi na seznamu obvestil, ponovno naročilo pa znaša 120 kosov. (Ilustrativno.)

Zaloga prispe in je ob 14h prevzeta v prodajljivo zalogo – strani variant so objavljene in kupljive. Namesto da vseh 400 zasuje naenkrat (kar bi prodalo 120 kosov in preostalih 280 poslalo v zid), trgovina prvi val pošlje takoj segmentu z najvišjo prednostjo, drugi val dvajset minut kasneje, ostalo pa zadrži. Ko je 120 kosov razprodanih, se preostale pošiljke samodejno ustavijo – nihče ne dobi obvestila o jakni, ki je spet ni več.

Brez izmišljene številke povrnitve. Bistvo je logika tempiranja: sproži, ko je izdelek zares kupljiv, prilagodi obseg pošiljanja zalogi in ubij rep v trenutku, ko se razproda.

Kaj meriti

Da veste, ali je vaše tempiranje pravo:

  • Čas od ponovne zaloge do prve pošiljke – naj bo kratek. Dolg razmik pomeni, da namera pojenja ali da se izdelek najprej prodaja nenaročnikom.
  • Kliki na že razprodano ob prihodu – ljudje, ki so kliknili obvestilo in zadeli razprodano stran. Visoke številke pomenijo, da za razpoložljivo zalogo pošiljate preveč naenkrat ali sprožate, preden je izdelek zares kupljiv.
  • Pretvorba po valu pošiljanja – če kasnejši valovi pretvarjajo precej slabše, zaloga poide, preden jih dosežete; zaostrite velikosti valov ali razvrstitev po prednosti.

Kako pomaga Omnisend

Da to dobro stempirate, se mora obvestilo sprožiti ob dogodku žive zaloge, pošiljanje pa se mora ustaviti v trenutku, ko zaloga poide. Testiral sem Klaviyo in Omnisend ter v svojih trgovinah uporabljam Omnisend, deloma zato, ker se avtomatizacije poganjajo iz resničnih podatkov trgovine o izdelkih in zalogi, tako da sprožilec spremlja dejansko prodajljivo številko, ne zastarele.

Pomembni deli: avtomatizacija, ki jo sproži vrnitev variante v kupljivo zalogo, možnost razporeditve ali segmentacije pošiljanja in izhod, ki zaustavi preostala sporočila, ko se izdelek spet razproda. (Omnisend je orodje, ki ga uporabljam in priporočam; morebitna partnerska povezava je razkrita – pristop deluje na vsaki platformi, ki sproža ob živi zalogi in se lahko ustavi sredi pošiljanja.)

Ne bo pa popravil vira zaloge, ki javi kose, preden so prodajljivi. Če sta »na zalogi« in »kupljivo« v vaši trgovini neusklajena, bo tempiranje obvestil zgrešeno ne glede na orodje – to najprej uskladite.

Vaš naslednji korak

Preizkusite dejansko tempiranje: prijavite se za razprodano varianto, ponovno napolnite zalogo in zabeležite dve stvari – kako hitro se obvestilo sproži in ali je stran, na katero vodi, zares kupljiva v trenutku, ko e-pošta prispe. Če obstaja razmik med obvestilom in delujočim nakupom, vaš sprožilec spremlja napačen signal; popravite ga po Kako nastaviti obvestila o ponovni zalogi za spletno trgovino. Ko se posamezno obvestilo sproži ob pravem trenutku, se odločite, ali je ena pošiljka dovolj ali si vroč izdelek zasluži kratko zaporedje opomnikov – Koliko sporočil o ponovni zalogi naj pošljete to pokriva. In poskrbite, da se besede ujemajo s trenutkom: Kaj naj piše v e-pošti o ponovni zalogi.

When Should You Send a Back-in-Stock Notification

Send the back-in-stock notification within an hour of inventory going live, with one exception: if the restock lands between roughly 10 p.m. and 7 a.m. in your customers’ timezone, hold it until morning. Speed wins because interest decays and because other stores stock the same or similar products — but a 3 a.m. email just sinks to the bottom of the morning inbox pile. The other timing decision is sequencing: when the restock is smaller than the waitlist, don’t send to everyone at once; notify in waves sized to the units you actually have. This article covers both decisions — clock time and send order — plus the follow-up window.

Why this question exists at all

If you’ve run a store past the EUR 20,000-a-month mark, you know restocks don’t arrive on a schedule you control. The container clears customs on a Friday evening. Your 3PL books inventory into the system at 11 p.m. Shopify flips the variant to available, and if your automation fires on that event — which it should — the emails go out while your customers sleep.

So the real situation is this: you’ve built the flow, the trigger works, and now you’re deciding whether “instant” is actually optimal or just the default. Meanwhile there’s a second pressure underneath: some of your waitlisted customers have been waiting six weeks, some six hours, and some will buy within minutes of the email while others take three days. One send time can’t be right for all of them unless you think it through once and encode it.

“Just send it immediately” is almost right — and that’s the trap

The usual advice is send instantly, always, because first-mover advantage on a scarce product is everything. For genuinely scarce restocks, that’s correct. But applied blindly it produces three predictable problems.

Night sends bury your alert under the morning’s newsletter stack, blunting your open rate on the one email type that should top your stats. Instant all-at-once sends to a large waitlist can oversell a small restock — 300 alerts chasing 50 units means 250 disappointed people and possibly refunds, which is a worse outcome than a slower send. And “immediately” for email gets copied to SMS, where a midnight text doesn’t get buried — it wakes someone up and earns you an unsubscribe. Speed is the right instinct; unconditional speed is the mistake.

What bad timing costs, roughly

Illustrative numbers to make the trade-off concrete. Suppose a restock alert goes to 200 people. Sent at a reasonable hour, say it converts 15% — 30 orders at EUR 70, EUR 2,100. Sent at 2 a.m., the same email competes with everything that arrived overnight; if buried placement costs you a third of those conversions, that’s 10 orders — EUR 700 — lost to nothing but the clock. One held send per month at that scale is a four-figure annual difference. The overselling scenario is worse: refunding 20 oversold orders costs the revenue plus support time plus the trust of exactly the customers who wanted you most.

The timing rules, in order of importance

  1. Fire from the inventory event, never a manual send. The trigger is “variant back above threshold”. A human remembering to send the campaign is how alerts go out two days late.
  2. Add a quiet-hours window. Emails triggered between 10 p.m. and 7 a.m. local time queue until morning. For SMS, make the window stricter — nothing before 9 a.m. or after 8 p.m.
  3. Compare waitlist size to restock size before the send. If units comfortably exceed requesters, release to everyone at once. If not, send in waves — details below — and see how to prevent overselling after a back-in-stock campaign for the inventory side of the same problem.
  4. Decide the reminder window now, not later. One follow-up to non-openers, 24–48 hours after the first send, only while stock remains. Whether you send more than that is a real question with a short answer — how many back-in-stock messages should you send covers it.
  5. Not needed yet: per-recipient send-time optimization, timezone splitting for a single-country store, or predictive anything. Get the four rules above running first.

The automation, setting by setting

  • Trigger: variant inventory crosses your threshold (e.g. 5+ units, so a single return doesn’t fire the flow).
  • Segment: requesters of that variant, excluding purchasers since their request. For wave sends, order the queue oldest request first — they’ve waited longest and their interest is most at risk of expiring. Split waves at roughly 1.5 alerts per available unit: 50 units means the first wave is about 75 people, since not everyone buys.
  • Delay: immediate, gated by quiet hours. Wave 2 goes 24 hours after wave 1, only if a stock check still passes.
  • Channel: email for all recipients; SMS layered on for subscribers who opted in, useful when stock is tight and hours matter — the mechanics of running both without doubling noise are in a two-channel back-in-stock sequence for high-demand products.
  • Message: product name in the subject, image, price, one deep-linked button. Short.
  • Goal: purchase of the restocked item within 72 hours; sell-through of the restock without an oversell.

A concrete scenario

Illustrative: a sneaker store restocks 60 pairs of a popular model at 11:40 p.m. on a Thursday, with 210 people waitlisted. The flow queues overnight. At 7 a.m. Friday, wave one — the 90 oldest requesters — gets the email; SMS opt-ins among them get a text at 9 a.m. Saturday 7 a.m., a stock check shows 22 pairs left, so wave two (the next 60 requesters) fires. Sunday, non-openers from wave one get a single reminder. By Monday the model is sold out, the remaining 60 waitlisted people were never emailed about stock that no longer existed, and nobody got a text at midnight.

What to measure

  • Time from restock event to first send — should be minutes plus quiet hours, never days.
  • Conversion within 72 hours of the alert, per wave, so you can see how much interest decays down the queue.
  • Oversell incidents per restock campaign — target zero.
  • SMS opt-out rate after restock texts — a spike means your quiet hours or frequency are off.

Encoding the rules in Omnisend

The reason I ended up on Omnisend for my own stores, after trying Klaviyo too, is that rules like these were something I could set up and adjust myself without treating it as a second job — the flow builder is the kind you can reason about at a glance. For this flow specifically: the back-in-stock trigger fires on the inventory event, delay steps and conditional splits handle quiet hours and reminder logic, and email and SMS sit in the same flow so the channel rules stay in one place. What it won’t do for you: it can’t know your restock quantities are entered wrong, and wave sizing still starts from your judgment about demand.

Your next step

Pull up your last restock and find two timestamps: when inventory went live and when the alert actually went out. If the gap was hours of dead daytime — or the send landed at 3 a.m. — add the event trigger and the quiet-hours window this week, before the next container arrives.

Leave a Reply

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