Allegro i własny sklep: jak nie sprzedać dwa razy tego samego towaru

Ryzykowna minuta: gdy ten sam towar kupują w dwóch kanałach naraz

Wyobraź sobie taką sytuację: klient na Allegro kupuje ostatnią sztukę produktu, a w tym samym momencie inny klient składa zamówienie na Twojej stronie internetowej. System nie widzi, że towar właśnie został sprzedany gdzie indziej. Obie transakcje przechodzą, a Ty musisz jedną anulować. Klient, który dostał informację o braku towaru po opłaceniu, zostawia negatywną ocenę. To nie jest teoria — to ryzyko pojawia się zawsze, gdy prowadzisz sprzedaż w więcej niż jednym kanale bez automatycznej synchronizacji stanów.

Dlaczego to się dzieje? Ponieważ ręczna aktualizacja stanów magazynowych nie nadąża za tempem sprzedaży. W ciągu minuty może dojść do kilku transakcji na różnych platformach. Bez systemu, który widzi każdą sprzedaż jako zdarzenie i natychmiast reaguje, podwójna sprzedaż jest kwestią czasu, nie pecha.

Koszty braku synchronizacji

Każda odwołana transakcja to nie tylko stracona sprzedaż. To również czas poświęcony na obsługę reklamacji, negatywna ocena w Allegro, potencjalna utrata pozycji w wynikach wyszukiwania i zaufania przyszłych klientów. W skali miesiąca, przy dziesiątkach takich sytuacji, koszty rosną wielokrotnie.

Jedna prawda o magazynie — centralne źródło stanów

Rozwiązanie problemu zaczyna się od architektury danych. Zamiast utrzymywać osobne stany magazynowe w Allegro, w sklepie internetowym i w arkuszu kalkulacyjnym, potrzebujesz jednego źródła prawdy (single source of truth). Wszystkie kanały sprzedaży powinny czytać stan z jednego miejsca i tylko zgłaszać tam zdarzenia — sprzedaż, zwrot, korektę.

Gdzie to miejsce może się znajdować? To zależy od Twojej infrastruktury:

• System CRM lub ERP — jeśli już go używasz, magazyn powinien być tam, a Allegro i sklep tylko odczytują i zgłaszają zmiany.
• Baza danych — prostsze rozwiązanie, gdzie jedna tabela przechowuje aktualne stany, a API lub automatyzacja aktualizuje platformy.
• Arkusz kalkulacyjny — dla małej skali, ale wymaga ręcznej obsługi i nie nadaje się do tysięcy produktów.

Kluczowa zasada brzmi: magazyn jest źródłem, kanały sprzedaży są tylko konsumentami i producentami zdarzeń. Nikt nie wpisuje ręcznie stanu „10 sztuk" — każda zmiana powstaje jako zdarzenie: sprzedaż, przyjęcie towaru, korekta inwentaryzacji.

Co oferuje Allegro: dziennik zdarzeń i masowa zmiana stanów

Allegro udostępnia bogate API, które pozwala nie tylko odczytywać i zmieniać oferty, ale również śledzić wszystkie zmiany w nich. Poprzez endpoint GET /sale/offer-events możesz pobrać historię zdarzeń dotyczących Twoich ofert. System zwraca między innymi:

• OFFER_STOCK_CHANGED — zmiana liczby sztuk w ofercie, zwracana również po zakupie. To kluczowe zdarzenie pozwala wykryć, że ktoś kupił towar.
• OFFER_PRICE_CHANGED — zmiana ceny, przydatna do śledzenia rabatów i promocji.
• OFFER_ENDED — zakończenie oferty, na przykład gdy produkt został wyprzedany ręcznie.

Zdarzenia możesz filtrować po typie i dacie. Dzięki temu Twój system może reagować na każdą zmianę w czasie zbliżonym do rzeczywistego, a nie czekać na cykliczne sprawdzanie.

Allegro oferuje również możliwość masowej zmiany ceny i liczby sztuk w wielu ofertach jednocześnie. Jeśli masz setki produktów i chcesz zaktualizować ich stany po inwentaryzacji lub imporcie z hurtowni, nie musisz robić tego pojedynczo.

Jak to działa w praktyce

Konfigurujesz automatyzację, która w regularnych odstępach czasu (lub w czasie rzeczywistym przez webhooki, jeśli Allegro je udostępnia) pobiera zdarzenia typu OFFER_STOCK_CHANGED. Gdy system wykryje, że stan zmniejszył się, wysyła tę informację do Twojego centralnego źródła magazynowego. To z kolei aktualizuje stany w sklepie internetowym i innych kanałach.

Zamówienia Allegro: kiedy naprawdę brakuje towaru

Sama zmiana stanu w ofercie to nie koniec historii. Równie ważne jest śledzenie zamówień i ich statusów. Endpoint GET /order/events zwraca wszystkie zdarzenia związane z zamówieniami: zakup, wypełnienie formularza dostawy, anulowanie płatności i wiele innych.

Najważniejszy status to READY_FOR_PROCESSING. Oznacza on, że klient wypełnił formularz opcji dostawy i sfinalizował płatność (lub wybrał płatność przy odbiorze albo odbiór osobisty). Dopiero w tym momencie zamówienie trafia do realizacji i możesz fizycznie zarezerwować towar. Wcześniejsze statusy, takie jak FILLED_IN (klient wypełnił dane, ale jeszcze nie zapłacił), nie powinny powodować rezerwacji magazynowej.

Dlaczego READY_FOR_PROCESSING jest tak ważny

Wielu sprzedawców błędnie reaguje na pierwszy sygnał zakupu, czyli zdarzenie BUY. Tymczasem klient może wypełnić formularz, a potem anulować płatność lub po prostu nie dokończyć transakcji. Dopiero status READY_FOR_PROCESSING oznacza, że transakcja jest naprawdę potwierdzona i towar powinien zostać odjęty ze stanu magazynowego.

Pamiętaj też, że dla jednego zamówienia może pojawić się wiele zdarzeń. Możesz otrzymać kilka komunikatów READY_FOR_PROCESSING, jeśli klient dokonał kilku zakupów. Dlatego zawsze opieraj swoją logikę na identyfikatorze zamówienia w obiekcie checkoutForm.

Strona sklepu: status Processing jako sygnał do redukcji stanu

W WooCommerce i większości popularnych platform sklepowych status zamówienia „Processing" oznacza, że płatność została otrzymana, a stan magazynowy został już zmniejszony — zgodnie z dokumentacją WooCommerce. Jest to sygnał dla właściciela lub magazynu, aby przygotować i wysłać zamówienie.

Statusy WooCommerce działają następująco:

• Pending payment — zamówienie złożone, ale jeszcze nie opłacone.
• Processing — płatność otrzymana, stock zmniejszony, zamówienie czeka na realizację.
• Completed — zamówienie zrealizowane i wysłane.
• Refunded — w pełni zwrócone przez administratora.

Gdy zamówienie przechodzi w status Processing, Twój system powinien wygenerować zdarzenie zredukowania stanu w centralnym magazynie. To zdarzenie automatycznie aktualizuje stany w Allegro i innych kanałach. Dzięki temu każdy kolejny klient, niezależnie od tego, czy kupuje przez Allegro, czy przez Twój sklep, widzi aktualny stan.

Łączenie kanałów: zdarzenie to wspólny język

Zasada jest prosta: niezależnie od tego, gdzie dokonano sprzedaży, powstaje jedno zdarzenie redukcji stanu magazynowego. Gdy klient kupuje na Allegro, system odnotowuje zakup przez OFFER_STOCK_CHANGED i zmniejsza stan w centralnym magazynie. Gdy klient płaci w sklepie internetowym, status Processing w WooCommerce generuje to samo zdarzenie redukcji. Obie ścieżki prowadzą do tego samego centrum zarządzania stanami i aktualizują drugi kanał w ciągu sekund.

Częstotliwość aktualizacji — dlaczego raz na dobę to za mało

Wielu właścicieli sklepów myśli: „będę aktualizować stany raz dziennie, rano, przed pracą". To podejście działa, dopóki masz dużo zapasów i rzadkie transakcje. Problem pojawia się przy ostatnich sztukach produktu, które są kupowane często i szybko.

Wyobraź sobie produkt, którego zostało tylko pięć sztuk. W ciągu godziny może dojść do sześciu transakcji na Allegro i w sklepie. Jeśli aktualizujesz stany raz na dobę, ostatnia z tych transakcji zakończy się odwołaniem. Klient dostanie informację „przepraszamy, produkt niedostępny" po tym, jak już zapłacił.

Rozwiązania tego problemu są dwa:

• Aktualizacja w czasie zbliżonym do rzeczywistego — za każdym razem, gdy pojawia się nowe zdarzenie, natychmiast aktualizujesz stany we wszystkich kanałach.
• Bufor bezpieczeństwa — dla popularnych produktów utrzymujesz dodatkowy zapas (na przykład 2-3 sztuki), który nie jest widoczny w sprzedaży. Gdy widoczny stan osiągnie zero, produkt automatycznie znika ze sprzedaży we wszystkich kanałach.

Bufor to decyzja biznesowa, którą podejmujesz sam: ile jesteś w stanie stracić potencjalnych klientów z powodu niedostępności, versus ile możesz stracić przez odwołane zamówienia.

Tabela zdarzeń: od źródła do miejsca docelowego

Poniższa tabela pokazuje typowe zdarzenia i przepływ informacji między systemami:

Tabela pomaga zobaczyć, że niezależnie od źródła zdarzenia, przepływ jest zawsze taki sam: źródło generuje zdarzenie, centralny magazyn je przetwarza, wszystkie kanały otrzymują zaktualizowany stan.

Zrób to sam: kontrola ręczna i proste zabezpieczenia

Jeśli nie masz jeszcze zintegrowanego systemu, możesz wprowadzić proste zabezpieczenia, które zmniejszą ryzyko podwójnej sprzedaży:

1. Identyfikuj produkty z niskim stanem — raz lub dwa razy dziennie sprawdzaj produkty, których zostało 1-3 sztuki. Jeśli widzisz, że taki produkt był ostatnio kupowany, tymczasowo wyłącz go z sprzedaży w jednym z kanałów.
2. Wyłącz duplikaty ofert — na Allegro wystawiaj tylko jedną ofertę na produkt. Nie twórz wielu wariantów z tym samym towarem, bo utrudnia to śledzenie stanów.
3. Prowadź dziennik odwołań — zapisuj każdą sytuację, w której musiałeś anulować zamówienie z powodu braku towaru. Po miesiącu będziesz widzieć skalę problemu i łatwiej ocenisz, czy inwestycja w automatyzację się opłaca.
4. Ustaw alerty — sprawdź, czy Twoja platforma sklepowa pozwala włączyć powiadomienia o niskim stanie magazynowym, i ustaw próg na 1–3 sztuki.

Te działania nie rozwiążą problemu w stu procentach, ale dadzą Ci czas i informację potrzebną do podjęcia decyzji o pełnej automatyzacji.

Jak to wygląda z systemem — automatyczna synchronizacja

Gdy połączysz kanały sprzedaży z centralnym systemem zarządzania magazynem, cały proces wygląda tak:

To oznacza, że gdy klient kupi produkt na Allegro, Twój sklep internetowy w ciągu sekund zobaczy zmniejszony stan i pokaże „ostatnia sztuka" lub „niedostępny". I odwrotnie: zakup w sklepie natychmiast zaktualizuje stan w Allegro.

System nie daje gwarancji zero odwołań — nadal mogą zdarzyć się sytuacje graniczne, na przykład gdy klient kupuje w tym samym milisekundzie w dwóch kanałach. Ale znacząco zmniejsza ryzyko i eliminuje ogromną większość takich przypadków.

Zobacz, jak Aura obsługuje integracje Allegro z sklepem internetowym i automatyczną synchronizację stanów magazynowych: Integracje, Sklepy internetowe, API, Panele admina, Dashboardy.

Przeczytaj też, dlaczego warto myśleć o automatyzacji procesów w firmie i kiedy gotowe rozwiązanie SaaS sprawdza się lepiej niż własna integracja: Automatyzacja procesów w firmie, Własna automatyzacja czy gotowy SaaS, n8n czy Make, CRM czy ERP, Zamówienia online dla restauracji.

Najczęściej zadawane pytania

Czy muszę używać API Allegro, żeby zsynchronizować stany?

Nie musisz, ale bez API jesteś ograniczony do ręcznych metod. Możesz eksportować stany do arkusza kalkulacyjnego i ręcznie aktualizować oferty, ale to czasochłonne i podatne na błędy. API pozwala zautomatyzować ten proces i reagować na zmiany w czasie zbliżonym do rzeczywistego.

Co jeśli klient kupi na Allegro, ale nie zapłaci?

W takim przypadku status zamówienia pozostanie na etapie FILLED_IN i nie przejdzie w READY_FOR_PROCESSING. Dopóki płatność nie zostanie sfinalizowana, system nie powinien rezerwować towaru w magazynie. To dlatego tak ważne jest, aby Twoja logika bazowała na statusie READY_FOR_PROCESSING, a nie na samym fakcie zakupu.

Czy mogę używać tego samego rozwiązania dla wielu kont Allegro?

Tak, pod warunkiem, że każde konto ma swoje dane dostępowe do API. Twój system centralny musi obsługiwać wiele połączeń i rozróżniać, z którego konta pochodzi zdarzenie. W praktyce oznacza to, że każde konto Allegro będzie miało własny token OAuth.

Co zrobić, gdy produkt ma warianty (rozmiar, kolor)?

Warianty w Allegro to osobne oferty z własnymi stanami. Musisz je mapować na odpowiednie warianty w Twoim systemie magazynowym. Jeśli prowadzisz sprzedaż wielowariantową, upewnij się, że Twoja integracja obsługuje tę logikę — inaczej możesz sprzedać rozmiar M, gdy w magazynie został tylko L.

Jak często powinienem pobierać zdarzenia z Allegro?

Optymalnie — co kilka minut, a najlepiej w czasie rzeczywistym przez webhooki (jeśli Allegro je udostępnia). Przy dużej liczbie transakcji częstotliwość raz na godzinę może być niewystarczająca dla produktów z niskim stanem. Dla produktów z wysokim stanem wystarczy rzadziej.

Czy mogę synchronizować stany bez programisty?

Częściowo tak. Niektóre platformy sklepowe oferują wtyczki do integracji z Allegro, które działają bez pisania kodu. Jednak zaawansowane scenariusze, jak obsługa wielu kont, niestandardowe reguły bufora czy zaawansowane raportowanie, zwykle wymagają indywidualnego rozwiązania.