Połączenie sklepu stacjonarnego ze sklepem online: jak zsynchronizować stany magazynowe i sprzedaż

Klient sprawdza w sklepie internetowym ostatni dostępny rozmiar, opłaca zamówienie, a kilka minut później pracownik sklepu stacjonarnego sprzedaje ten sam produkt przy kasie. W systemie online nadal widnieje jedna sztuka, choć fizycznie nie ma jej już na półce. Następnego dnia obsługa musi szukać towaru w innym punkcie, proponować zamiennik albo anulować zamówienie. Dla klienta nie ma większego znaczenia, który system zawiódł. Otrzymał informację o dostępności, więc oczekuje realizacji.

Połączenie sklepu stacjonarnego ze sklepem online ma temu zapobiegać, ale sama instalacja integracji nie rozwiązuje problemu. Trzeba ustalić, który system jest źródłem prawdy, jakie zdarzenia zmieniają dostępność produktu, jak obsługiwane są rezerwacje i zwroty oraz kiedy informacja o zmianie ma pojawić się w pozostałych kanałach. Dopiero wtedy synchronizacja stanów magazynowych staje się elementem spójnego procesu sprzedaży, a nie pojedynczym technicznym dodatkiem. ^[1]

Gdy sklep internetowy sprzedaje towar, którego nie ma już na półce

Jak wygląda problem z perspektywy klienta i obsługi

Najbardziej widoczny scenariusz jest prosty: produkt ma w sklepie internetowym status „dostępny”, chociaż jego ostatnia sztuka została sprzedana w punkcie stacjonarnym. Może też być odwrotnie. Towar jest widoczny jako dostępny w salonie, ale w rzeczywistości został odłożony dla klienta, czeka na kontrolę jakości albo znajduje się w zamkniętym zapleczu bez możliwości wydania.

Klient online nie widzi tych okoliczności. Składa zamówienie, płaci lub wybiera płatność przy odbiorze, a sklep rozpoczyna realizację. Dopiero podczas kompletacji okazuje się, że produkt nie istnieje w miejscu wskazanym przez system. W tym momencie powstaje łańcuch dodatkowych czynności: kontakt z innym sklepem, sprawdzanie dostaw, korekta dokumentów, zwrot płatności, zmiana zamówienia i wyjaśnienie sytuacji klientowi.

Jednorazowa pomyłka nie musi oznaczać kryzysu, ale powtarzalne rozbieżności szybko obciążają zespół. Pracownicy zamiast sprzedawać, przeszukują magazyny i ręcznie porównują stany. Klienci otrzymują sprzeczne informacje, zamówienia są anulowane, a opinie zaczynają dotyczyć nie jakości produktu, lecz braku wiarygodności sklepu. Problem jest szczególnie dotkliwy przy produktach sezonowych, promocyjnych i sprzedawanych w pojedynczych egzemplarzach.

Nie chodzi wyłącznie o samą liczbę sztuk

W prostym modelu można powiedzieć: sklep ma 10 sztuk produktu albo nie ma żadnej. W praktyce przydatne są co najmniej różne kategorie zapasu:

• stan fizyczny – liczba sztuk znajdujących się faktycznie w konkretnej lokalizacji,
• stan dostępny do sprzedaży – zapas, który można rzeczywiście zaoferować klientowi,
• stan zarezerwowany – produkty przypisane do zamówień, rezerwacji lub odbiorów osobistych,
• stan zablokowany – towary uszkodzone, wymagające kontroli, reklamacyjne albo przeznaczone do ekspozycji,
• stan w drodze – produkty zamówione u dostawcy lub przesuwane między lokalizacjami, których nie powinno się jeszcze obiecywać klientowi. ^[4]

Jeżeli system pokazuje wyłącznie sumę wszystkich sztuk, sklep może komunikować dostępność produktu, którego nie wolno sprzedać. Przykład: magazyn posiada pięć sztuk, ale dwie są zarezerwowane, jedna uszkodzona, a dwie znajdują się w dostawie między sklepami. Fizyczny stan wynosi pięć, lecz dostępność handlowa może wynosić zero.

Trzeba również rozstrzygnąć, co oznacza „dostępny”. Czy produkt jest dostępny, gdy znajduje się w koszyku? Czy dopiero po opłaceniu? Czy rezerwacja w sklepie stacjonarnym blokuje go dla e-commerce? Czy towar zwrócony przy kasie wraca do sprzedaży natychmiast, czy dopiero po sprawdzeniu? Bez odpowiedzi na te pytania żadna integracja nie będzie działać zgodnie z oczekiwaniami. ^[2]

Produkt musi mieć tę samą tożsamość w każdym kanale

Synchronizacja jest możliwa tylko wtedy, gdy wszystkie systemy rozpoznają ten sam produkt jako ten sam produkt. Najczęściej służy do tego kod SKU, kod EAN albo inny jednoznaczny identyfikator. Nazwa handlowa nie wystarcza. „Koszulka Basic czarna M” w kasie i „T-shirt Basic Black, rozmiar medium” w e-sklepie mogą oznaczać ten sam wariant, ale system nie zawsze potrafi to ustalić.

Odrębnego identyfikatora wymagają warianty. Produkt główny „buty sportowe” nie powinien mieć jednego stanu, jeśli klient kupuje konkretne rozmiary i kolory. Każdy wariant powinien być rozliczany osobno. Podobnie działa sprzedaż produktów z numerami seryjnymi, partiami, datami ważności, różnymi jednostkami miary czy zestawami składającymi się z kilku elementów.

Pytania kontrolne są tu bardziej użyteczne niż ogólne zapewnienie, że system jest zintegrowany: co dokładnie wiemy o stanie magazynowym, a czego system nie rejestruje? Czy można wskazać, gdzie znajduje się konkretna sztuka? Czy wiadomo, że została odłożona? Czy sprzedaż zestawu zmniejsza stan każdego komponentu? Jeśli odpowiedź brzmi „nie”, najpierw trzeba uporządkować model danych i proces, a dopiero później zwiększać zakres automatyzacji.

Dlaczego stany i sprzedaż rozjeżdżają się między kanałami

Kilka systemów oznacza kilka wersji tego samego zdarzenia

Typowy sklep wielokanałowy korzysta z kilku narzędzi jednocześnie: platformy e-commerce, systemu POS, ERP, programu magazynowego lub WMS, systemu płatności, integracji z kurierami i czasem marketplace’ów. Każdy z tych systemów może przechowywać fragment informacji o produkcie i zamówieniu.

Sklep internetowy rejestruje zamówienie, POS sprzedaż przy kasie, ERP dokument handlowy, a WMS kompletację i wydanie. Jeżeli systemy nie przekazują sobie zmian w określonej kolejności, mogą powstać sprzeczne dane. E-sklep uzna zamówienie za opłacone i zarezerwuje produkt, podczas gdy kasa sprzedała go wcześniej. ERP może jeszcze przez jakiś czas pokazywać stan sprzed obu operacji.

Nie każda integracja jest taka sama. Czym innym jest import katalogu produktów, a czym innym synchronizacja operacji. Import nazw, zdjęć i cen nie oznacza jeszcze, że do e-sklepu trafiają sprzedaże z kasy, korekty, rezerwacje, przyjęcia dostaw i zwroty. Przy wyborze rozwiązania trzeba sprawdzić, jakie zdarzenia są przekazywane w obie strony, a nie tylko czy dostawca używa słowa „integracja”.

Wspólny SKU i jednolite jednostki rozwiązują część problemów

Rozbieżności zaczynają się często od katalogu. Produkt ma inny kod w sklepie internetowym, inny w POS, a jeszcze inny w magazynie. Czasem kod główny dotyczy produktu, a sprzedaż odbywa się na poziomie wariantu. W innym przypadku dostawca dostarcza towar w kartonach, sklep przyjmuje go jako opakowania, a sprzedaje pojedyncze sztuki.

Przed połączeniem systemów warto przygotować tabelę porządkującą dane:

Zmiana kodów w trakcie działania sklepu jest ryzykowna, bo historyczne zamówienia i dokumenty mogą przestać łączyć się z aktualnym katalogiem. Lepszym rozwiązaniem jest ustalenie reguł przed migracją oraz przygotowanie mapowania starych i nowych oznaczeń. Jeżeli zmiana jest konieczna, trzeba zachować relację między identyfikatorem archiwalnym a aktualnym.

Opóźnienia i błędna kolejność zdarzeń mają znaczenie

Synchronizacja wykonywana raz na godzinę może wystarczyć dla produktów sprzedawanych sporadycznie, ale nie dla ostatnich sztuk, krótkich promocji i intensywnego ruchu w sklepie. Jeżeli o 12:00 dostępne są dwie sztuki, a aktualizacja następuje co 30 minut, w tym czasie oba kanały mogą przyjąć więcej zamówień, niż sklep jest w stanie zrealizować.

Problem nie zawsze wynika z częstotliwości. Komunikat o sprzedaży może zostać opóźniony przez błąd połączenia, przeciążenie kolejki albo niedostępność jednego z systemów. Gdy integracja ponawia operację bez kontroli, zdarzenie może zostać wykonane dwa razy. Gdy system „naprawia” dane przez automatyczne nadpisanie, można stracić informację o tym, która sprzedaż była pierwsza.

Dlatego potrzebne są logi i statusy. Dla każdej istotnej operacji powinno dać się sprawdzić, kiedy została utworzona, do którego systemu wysłana, czy została przyjęta i czy wystąpił błąd. Ciche pomijanie nieudanych aktualizacji jest szczególnie niebezpieczne. Pracownik dowiaduje się o problemie dopiero wtedy, gdy klient pyta o niedostarczone zamówienie.

Rezerwacja nie jest tym samym co sprzedaż

Produkt może zmieniać dostępność na kilku etapach. Zamówienie internetowe może być złożone, nieopłacone, opłacone, przekazane do kompletacji, gotowe do odbioru albo anulowane. Rezerwacja w salonie może mieć termin ważności. Towar dodany do koszyka zwykle nie powinien blokować stanu przez nieograniczony czas, ale opłacone zamówienie już tak.

Odbiór osobisty wymaga dodatkowej precyzji. Jeżeli klient wybiera punkt, produkt trzeba zarezerwować w konkretnym miejscu albo wskazać lokalizację, która go skompletuje. Samo zmniejszenie globalnego stanu nie wystarczy, ponieważ pracownik innego sklepu może nadal widzieć tę sztukę jako dostępną na półce.

Zwrot również ma kilka etapów. Towar przyjęty przez pracownika może wymagać oceny, czyszczenia, przepakowania lub sprawdzenia kompletności. Nie powinien od razu zwiększać stanu dostępnego online, jeżeli nie jest gotowy do wysyłki. Przydatne są osobne statusy: „zwrot oczekuje na weryfikację”, „zwrot zaakceptowany” oraz „ponownie dostępny”.

Jaki model połączenia wybrać: wspólny magazyn, wiele lokalizacji czy zapas bezpieczeństwa

Jeden wspólny stan dla sklepu stacjonarnego i online

Najprostszy model zakłada, że oba kanały korzystają z tej samej puli. Sprzedaż przy kasie zmniejsza stan widoczny w e-sklepie, a zamówienie internetowe blokuje produkt w magazynie obsługującym również sklep stacjonarny. Takie rozwiązanie pozwala lepiej wykorzystać zapas i ogranicza sytuację, w której towar zalega w jednym kanale, choć klienci szukają go w drugim.

Wspólny stan sprawdza się przy ograniczonej liczbie lokalizacji i sprawnym obiegu informacji. Wymaga jednak szybkiej aktualizacji oraz dyscypliny przy każdym ruchu produktu. Przyjęcie dostawy, sprzedaż, anulowanie, uszkodzenie, rezerwacja i zwrot muszą być odnotowane w tym samym modelu.

Wiele lokalizacji, gdy towar jest rozproszony

Model wielu lokalizacji nie traktuje magazynu centralnego, salonu i punktu odbioru jako jednego miejsca. Każda lokalizacja ma własny stan, a system może określać, czy produkt jest dostępny w konkretnym sklepie, w magazynie centralnym, czy dopiero po przesunięciu między punktami.

To rozwiązanie jest przydatne, gdy klient chce kupić produkt z odbiorem w wybranym salonie. Sklep internetowy powinien wtedy pokazywać nie tylko informację „dostępny”, ale także wskazywać miejsce i sposób realizacji:

• produkt jest gotowy do odbioru w wybranym salonie,
• towar znajduje się w magazynie centralnym i wymaga przesunięcia,
• produkt jest dostępny w innym punkcie, ale jego sprowadzenie potrwa dłużej,
• brak towaru w konkretnej lokalizacji uniemożliwia natychmiastowy odbiór.

System musi więc obsługiwać nie tylko zmianę liczby sztuk, lecz także decyzję, z którego miejsca zostanie zrealizowane zamówienie. Przydatne są reguły priorytetu, na przykład: najpierw magazyn wskazany jako główny, potem lokalizacja najbliższa klientowi, a na końcu sklep posiadający nadwyżkę. Bez takich reguł pracownicy mogą ręcznie ustalać źródło realizacji, co wydłuża obsługę i zwiększa ryzyko pomyłek.

Warto również rozdzielić stan przeznaczony dla odbioru osobistego od stanu dostępnego dla sprzedaży wysyłkowej. Jeżeli cały zapas salonu jest wystawiony online, zamówienie z dostawą kurierską może uszczuplić pulę potrzebną do obsługi klientów odwiedzających sklep. Z kolei pełne blokowanie zapasu w każdej lokalizacji może ograniczyć sprzedaż bardziej, niż wymaga tego rzeczywisty popyt.

Jak zaplanować przesunięcia między lokalizacjami

Sama informacja, że produkt znajduje się w innym sklepie, nie oznacza jeszcze, że można obiecać go klientowi. Trzeba uwzględnić czas przygotowania przesunięcia, transport, przyjęcie w lokalizacji docelowej i potwierdzenie, że towar rzeczywiście dotarł.

Przesunięcie powinno mieć własny status, na przykład „zaplanowane”, „wydane z lokalizacji źródłowej”, „w transporcie”, „przyjęte w lokalizacji docelowej” albo „anulowane”. Dzięki temu system nie pokaże produktu jako dostępnego na półce w dwóch miejscach jednocześnie. Towar wydany z jednego sklepu nie powinien już zwiększać dostępności w drugim, dopóki nie zostanie tam przyjęty.

Reguły przesunięć można oprzeć na kilku kryteriach:

• minimalnym stanie, który musi pozostać w salonie,
• odległości od klienta i przewidywanym czasie dostawy,
• koszcie transportu między lokalizacjami,
• rotacji produktu w poszczególnych sklepach,
• terminie ważności lub numerze partii.

Nie każdy produkt powinien być dostępny z każdej lokalizacji. Ciężkie towary, produkty wymagające specjalnego transportu albo artykuły sprzedawane wyłącznie lokalnie mogą mieć ograniczony zasięg. Taką regułę lepiej skonfigurować w systemie niż pozostawiać ją w formie instrukcji dla pracowników.

Zapas bezpieczeństwa chroni przed zbyt odważną obietnicą

Trzeci model polega na tym, że system nie udostępnia online całego rzeczywistego zapasu. Część produktów pozostaje jako bufor bezpieczeństwa. Jeżeli magazyn ma dziesięć sztuk, sklep internetowy może prezentować na przykład osiem, a dwie pozostawić na obsługę sprzedaży stacjonarnej, błędy inwentaryzacji, uszkodzenia lub opóźnienia w aktualizacji.

Zapas bezpieczeństwa jest szczególnie przydatny wtedy, gdy integracja nie działa w czasie rzeczywistym albo sprzedaż w salonie jest intensywna. Nie zastępuje jednak prawidłowej synchronizacji. Jeżeli system regularnie gubi zdarzenia lub pracownicy nie rejestrują wydań, zwiększanie bufora jedynie ukryje problem i ograniczy sprzedaż.

Bufor nie musi mieć jednej wartości dla całego katalogu. Można ustalić go według:

• popularności produktu,
• częstotliwości sprzedaży w sklepie stacjonarnym,
• wartości towaru,
• czasu potrzebnego na uzupełnienie zapasu,
• ryzyka pomyłki przy kompletacji lub inwentaryzacji.

Przykładowo, dla szybko rotującego produktu dostępność online może zostać ograniczona do dwóch sztuk, nawet jeśli fizycznie jest ich więcej. Dla artykułu sprzedawanego sporadycznie bufor może wynosić zero. W praktyce warto obserwować, ile razy bufor zapobiegł brakom, a ile razy niepotrzebnie zablokował sprzedaż.

Porównanie modeli przed podjęciem decyzji

Modele można również łączyć. Sklep może prowadzić osobne stany dla każdej lokalizacji, a jednocześnie utrzymywać bufor dla produktów szybko rotujących. Wspólny stan może obejmować magazyn centralny i e-commerce, natomiast salony mogą zachować własne minima. Takie podejście jest zwykle bardziej realistyczne niż próba dopasowania całej firmy do jednego schematu.

Jak dobrać model do sposobu sprzedaży

Jeżeli większość zamówień wysyłkowych jest realizowana z jednego magazynu, a sklepy stacjonarne mają niewielki udział w sprzedaży, dobrym punktem wyjścia będzie wspólny stan z niewielkim zapasem bezpieczeństwa. Pozwala to uniknąć nadmiernej komplikacji i jednocześnie chroni przed krótkimi opóźnieniami.

Gdy klienci często wybierają odbiór osobisty, potrzebny jest model wielu lokalizacji. W takim przypadku należy od początku określić, która lokalizacja rezerwuje towar, kto odpowiada za przygotowanie zamówienia i kiedy produkt staje się ponownie dostępny po anulowaniu odbioru.

Przy dużej liczbie salonów nie warto udostępniać klientom całego rozproszonego zapasu bez reguł. Lepsze może być pokazywanie dostępności tylko wtedy, gdy lokalizacja ma więcej niż ustalone minimum. Zmniejsza to liczbę sytuacji, w których ostatnia sztuka z ekspozycji zostaje sprzedana chwilę przed przyjęciem zamówienia online.

Przed wdrożeniem warto przeprowadzić próbę na ograniczonej grupie produktów. Powinna obejmować sprzedaż przy kasie, zamówienie internetowe, rezerwację, anulowanie, przesunięcie między sklepami, zwrot oraz ręczną korektę stanu. Dopiero po sprawdzeniu tych scenariuszy można ocenić, czy wybrany model odpowiada rzeczywistemu obiegowi towaru.

Czego unikać przy łączeniu sprzedaży stacjonarnej i online

• Nie należy traktować importu stanów jako pełnej integracji. Samo okresowe przesyłanie liczby sztuk nie obsługuje rezerwacji, anulowań i przesunięć.
• Nie warto udostępniać online każdej fizycznej sztuki. Towar na ekspozycji, w kontroli jakości albo oczekujący na przyjęcie nie powinien automatycznie trafiać do oferty.
• Nie należy pozwalać na ręczne nadpisywanie stanów bez śladu. Korekta powinna mieć autora, powód i datę, aby można było wyjaśnić późniejszą rozbieżność.
• Nie powinno się testować integracji wyłącznie na dużych zapasach. Najwięcej problemów ujawnia sprzedaż ostatniej sztuki, równoczesna rezerwacja i szybkie anulowanie.
• Nie należy uzależniać procesu od jednego pracownika. Instrukcja musi określać, co zrobić przy braku połączenia, błędnym skanowaniu, zwrocie lub niezgodności inwentaryzacyjnej.

Najbezpieczniejszy wybór zależy więc nie od liczby funkcji na liście dostawcy, lecz od sposobu, w jaki firma naprawdę przyjmuje, rezerwuje, przesuwa i wydaje produkty. Wspólny stan będzie efektywny przy szybkiej wymianie danych, wiele lokalizacji sprawdzi się przy rozproszonej sieci i odbiorach osobistych, a zapas bezpieczeństwa ograniczy ryzyko tam, gdzie pełna synchronizacja nie jest jeszcze możliwa. Dobrym rozwiązaniem jest zacząć od jednego kontrolowanego scenariusza, zmierzyć liczbę rozbieżności i dopiero potem rozszerzać integrację na kolejne produkty oraz lokalizacje. ^[3]

Źródła

• [1] Shopify Help Center – Migrating from Stocky to Shopify inventory management ↑
• [2] Square App Marketplace – Connect online and in-person sales and inventory ↑
• [3] WooCommerce – WooCommerce Square Documentation ↑
• [4] Shopify Help Center – Inventory transfers and shipments ↑