Jak policzyć próg niskiego stanu magazynowego
Stały próg, np. 5 sztuk dla wszystkich produktów, sprawdza się tylko w małym, jednorodnym katalogu. Produkt, który sprzedaje się w 20 sztukach dziennie, przy takim progu zniknie w kilka godzin, a produkt sprzedawany raz w miesiącu będzie generował zbędne alerty. Lepiej liczyć próg z danych sprzedaży.
Najprostszy wskaźnik to liczba dni zapasu, czyli na ile dni wystarczy obecny stan przy średniej sprzedaży z ostatnich tygodni. Przykładowo, przy 120 sztukach na stanie i średniej sprzedaży 8 sztuk dziennie zapasu wystarczy na 15 dni. Alert powinien przyjść, gdy liczba dni zapasu spadnie poniżej czasu dostawy od dostawcy powiększonego o margines bezpieczeństwa.
[#chart:wpr25b]
Ten sam warunek można zapisać jako próg w sztukach: średnia dzienna sprzedaż razy czas dostawy w dniach plus zapas bezpieczeństwa. Przy sprzedaży 8 sztuk dziennie, dostawie w 7 dni i zapasie bezpieczeństwa 20 sztuk próg wynosi 76 sztuk (wartości przykładowe). Średnią warto liczyć z co najmniej kilku tygodni i aktualizować regularnie, bo w sezonie sprzedaż potrafi wzrosnąć kilkukrotnie.
Alerty magazynowe przez skrypt na API
Skrypt to mały program uruchamiany cyklicznie, np. co godzinę lub raz dziennie rano, który pobiera stany i sprzedaż przez API sklepu, integratora albo ERP, liczy progi i wysyła zbiorczy raport. To rozwiązanie daje najwięcej swobody: alert może uwzględniać sprzedaż ze wszystkich kanałów, czas dostawy konkretnego dostawcy, minimalną ilość zamówienia i produkty sezonowe.
Dobrze napisany skrypt alertów ma kilka cech:
Jedno źródło stanów - pobiera stan tam, gdzie jest prowadzony, np. z integratora, a nie z każdego kanału osobno.
Zbiorczy raport - jeden e-mail lub wiadomość z listą produktów, posortowaną według liczby dni zapasu.
Pamięć wysłanych alertów - nie powtarza alertu o tym samym produkcie, dopóki stan nie wzrośnie lub nie minie ustalony czas.
Dane do zamówienia - podaje dostawcę, sugerowaną ilość i datę, do której trzeba złożyć zamówienie.
Powiadomienie o własnej awarii - jeśli skrypt nie zadziała, ktoś powinien się o tym dowiedzieć, zamiast zakładać, że braków po prostu nie ma.
Skrypt wymaga serwera lub usługi w chmurze, na której będzie działał, oraz kogoś, kto go utrzyma, gdy zmieni się API sklepu lub integratora. W zamian koszt utrzymania nie rośnie wraz z liczbą produktów i uruchomień. Skrypt można też łatwo rozbudować, np. o raport produktów, które od dawna się nie sprzedają i zamrażają gotówkę w magazynie, albo o automatyczne wstrzymanie reklam produktów, którym kończy się zapas.
Alerty o niskim stanie w Make
Make to narzędzie do budowania automatyzacji z gotowych modułów, bez pisania dużej ilości kodu. Scenariusz alertów uruchamia się według harmonogramu, pobiera produkty przez moduł danej platformy lub ogólny moduł HTTP, filtruje te poniżej progu i wysyła wiadomość. Typowy scenariusz wygląda tak:
[#chart:wpr25c]
Make dobrze sprawdza się na start i przy średnich katalogach. Trzeba jednak pamiętać, że każde wykonanie modułu dla każdego produktu zużywa limit planu, więc scenariusz przeglądający kilka tysięcy produktów co godzinę szybko go wyczerpie. Lepiej uruchamiać go rzadziej, pobierać produkty stronami i filtrować możliwie wcześnie. Porównanie Make z innymi narzędziami znajdziesz we wpisie Zapier czy Make dla sprzedawcy online.
Raport braków z systemu ERP
Jeśli stany prowadzisz w ERP, np. w Subiekcie, Comarch ERP Optima czy enova365, to ERP jest naturalnym miejscem na alerty. Większość systemów pozwala ustawić stan minimalny na kartotece towaru i wygenerować zestawienie towarów poniżej tego progu, a część pozwala też tworzyć na tej podstawie propozycje zamówień do dostawców. Brakującym elementem bywa automatyczna wysyłka - raport trzeba otworzyć ręcznie. Zaletą ERP jest za to pełny obraz: system zna zamówienia u dostawców w drodze, więc może nie zgłaszać braku, jeśli towar już został zamówiony.
Tę lukę uzupełnia się małą integracją, która cyklicznie pobiera zestawienie z ERP i wysyła je zespołowi. Jak wygląda połączenie popularnego ERP ze sklepem, opisujemy w artykule integracja Subiekta GT ze sklepem internetowym.
Alerty magazynowe dla produktów sezonowych, nowych i zestawów
Średnia sprzedaż z ostatnich tygodni nie działa dobrze w trzech przypadkach, które w e-commerce zdarzają się bardzo często. Każdy z nich wymaga osobnej reguły w skrypcie, scenariuszu lub ERP.
Produkty sezonowe - przed sezonem sprzedaż z ostatnich tygodni jest niska, więc próg wychodzi zbyt mały. Lepiej liczyć średnią z tego samego okresu poprzedniego roku albo ręcznie podnieść próg na czas sezonu.
Nowe produkty - nie mają historii sprzedaży, więc przez pierwsze tygodnie potrzebują progu ustawionego ręcznie, np. na podstawie podobnego produktu z tej samej kategorii.
Zestawy i komplety - zestaw sprzedaje się tylko wtedy, gdy są wszystkie jego składniki. Alert powinien sprawdzać stan każdego składnika, a nie tylko stan zestawu, jeśli sklep wylicza go z komponentów.
Osobną grupą są produkty sprzedawane na zamówienie lub wycofywane z oferty. Dla nich alert jest zbędny, więc warto oznaczyć je atrybutem lub tagiem i wykluczyć z raportu. To jeden z najprostszych sposobów, żeby raport był krótki i czytany, a nie ignorowany.
Gdzie wysyłać alerty o niskim stanie
Kanał powiadomienia warto dobrać do pilności. Raport z listą produktów do zamówienia najlepiej sprawdza się jako jeden e-mail rano albo jako arkusz, z którego zespół zakupów od razu przygotowuje zamówienie u dostawcy. Alerty krytyczne, np. o bestsellerze, któremu zostało zapasu na dwa dni, lepiej wysyłać do komunikatora zespołu, bo tam szybciej zostaną zauważone. Rozdzielenie tych dwóch rodzajów powiadomień sprawia, że pilne sprawy nie giną wśród rutynowych.
Skrypt, Make czy ERP - porównanie
| Rozwiązanie | Zalety | Ograniczenia | Dla kogo |
|---|
| Wbudowane powiadomienia platformy | Brak kosztów, konfiguracja w kilka minut | Stały próg, alert na każdy produkt, tylko stan sklepu | Mały sklep, jeden kanał sprzedaży |
| Scenariusz Make | Szybki start bez programowania, łatwe zmiany | Zużycie limitu planu przy dużych katalogach | Średni katalog, kilka kanałów przez integrator |
| Skrypt na API | Pełna kontrola, próg ze sprzedaży, dane do zamówienia | Wymaga programisty i serwera | Duży katalog, wielu dostawców, sezonowość |
| Raport z ERP | Stany z jednego źródła, propozycje zamówień | Często brak automatycznej wysyłki | Firmy, w których ERP prowadzi magazyn |
[#uwaga] Alert o niskim stanie nie zastąpi poprawnej synchronizacji stanów. Jeśli stany w sklepie i na marketplace'ach się rozjeżdżają, alert będzie liczony z błędnych danych. Najpierw upewnij się, że wszystkie kanały pobierają stan z jednego źródła.
Jak Vinson pomaga wdrożyć alerty magazynowe
Programiści Vinson zaczynają od ustalenia, gdzie naprawdę prowadzone są stany: w sklepie, integratorze czy ERP. Potem dobieramy rozwiązanie - konfigurujemy wbudowane powiadomienia, budujemy scenariusze w Make albo piszemy skrypty na API sklepu, Base lub systemu ERP, które liczą progi ze sprzedaży i wysyłają jeden czytelny raport. Jako certyfikowany partner Base łączymy alerty z integratorem i synchronizacją stanów w wielu kanałach. Szczegóły współpracy znajdziesz na stronie Wsparcie programistyczne dla e-commerce.
Najczęściej zadawane pytania
Jak ustawić powiadomienie o niskim stanie magazynowym w WooCommerce?
W ustawieniach WooCommerce, w zakładce produktów i sekcji magazynu, włącz powiadomienia o niskim stanie i braku w magazynie, podaj adres odbiorcy i ustaw próg niskiego stanu. Próg można też nadpisać dla pojedynczego produktu w jego ustawieniach magazynowych. Powiadomienia działają tylko dla produktów z włączonym zarządzaniem stanem.
Jak obliczyć próg niskiego stanu magazynowego?
Pomnóż średnią dzienną sprzedaż produktu przez czas dostawy od dostawcy w dniach i dodaj zapas bezpieczeństwa. Przy sprzedaży 8 sztuk dziennie, dostawie w 7 dni i zapasie 20 sztuk próg wynosi 76 sztuk. Średnią sprzedaż warto przeliczać regularnie, szczególnie przed sezonem.
Czy Make nadaje się do alertów magazynowych?
Tak, Make dobrze sprawdza się przy małych i średnich katalogach. Scenariusz uruchamiany według harmonogramu pobiera stany, filtruje produkty poniżej progu i wysyła raport e-mailem lub do komunikatora. Przy kilku tysiącach produktów trzeba uważać na zużycie limitu planu i uruchamiać scenariusz rzadziej.
Skąd brać stany do alertów, gdy sprzedaję w kilku kanałach?
Z jednego źródła prawdy, czyli tam, gdzie stan jest faktycznie prowadzony: z integratora, np. Base, albo z ERP. Pobieranie stanów z każdego kanału osobno prowadzi do rozbieżności i fałszywych alertów. Sprzedaż do wyliczenia progu warto sumować ze wszystkich kanałów.
Jak uniknąć zalewu powiadomień o brakach?
Wysyłaj jeden zbiorczy raport zamiast osobnego maila dla każdego produktu, zapamiętuj wysłane alerty i nie powtarzaj ich, dopóki stan nie wzrośnie. Wyłącz alerty dla produktów wycofanych i sprzedawanych na zamówienie. Raport kieruj do osoby, która odpowiada za zamówienia u dostawców.
Czy Shopify wysyła alerty o niskim stanie magazynowym?
Shopify nie ma prostego ustawienia progu z mailem, jak WooCommerce, ale w Shopify Flow są gotowe szablony automatyzacji reagujących na niski stan produktu (stan na kwiecień 2026 - sprawdź aktualną listę szablonów). Flow może wysłać e-mail, wiadomość do zespołu albo oznaczyć produkt tagiem. Przy sprzedaży w kilku kanałach lepiej liczyć alerty w integratorze lub ERP, gdzie widać pełną sprzedaż i wspólny stan.
Automatyczne alerty o brakach magazynowych działają, gdy próg wynika ze sprzedaży i czasu dostawy, stany pochodzą z jednego źródła, a raport trafia do właściwej osoby. Jeśli chcesz zbudować alerty dopasowane do swojego katalogu i kanałów, sprawdź wsparcie programistyczne Vinson. O tym, jak utrzymać zgodne stany w sklepie i na marketplace'ach, przeczytasz we wpisie synchronizacja stanów magazynowych między sklepem a marketplace.
