Jak działa automatyczna synchronizacja produktów z Base.com?

Przy kilkunastu produktach można jeszcze próbować robić to ręcznie. Przy kilku tysiącach SKU i kilku kanałach sprzedaży taki model właściwie przestaje działać.

Base.com może pełnić rolę warstwy łączącej magazyn z ofertami sprzedażowymi. Zamówienie pobrane z jednego kanału wpływa na dostępny stan, a zmiana może zostać przekazana do pozostałych marketplace’ów. Podobnie można synchronizować ceny.

Trzeba jednak dobrze zrozumieć jedną rzecz: produkt, stan magazynowy, cena i oferta na marketplace to nie to samo. Automatyzacja każdego z tych elementów działa trochę inaczej.

Najpierw trzeba ustalić, gdzie znajduje się główna baza produktów

To najważniejsza decyzja podczas konfiguracji.

Firma może prowadzić produkty:

w Katalogu Base.com,
w sklepie internetowym,
w zewnętrznym ERP lub programie magazynowym,
w hurtowni,
w kilku źródłach jednocześnie.

Nie ma jednego wariantu właściwego dla każdej firmy.

Załóżmy, że przedsiębiorca korzysta z WooCommerce i od kilku lat właśnie tam prowadzi 20 000 produktów. Ceny i stany aktualizuje również w WooCommerce.

Nie musi przenosić całej pracy do Base tylko po to, żeby rozpocząć sprzedaż na marketplace.

Base może korzystać z magazynu podłączonego sklepu jako źródła produktów do wystawiania ofert.

Inna firma może natomiast zdecydować:

Katalog Base.com jest naszym głównym magazynem, a sklepy i marketplace’y mają otrzymywać z niego informacje.

To również prawidłowy model.

Najgorsza jest sytuacja, w której pracownicy nie wiedzą, który system jest nadrzędny.

Jedna osoba zmienia stan w sklepie, druga w Base, a trzecia bezpośrednio na Allegro. Po kilku dniach trzy systemy pokazują trzy różne wartości.

Powiązanie produktu jest podstawą synchronizacji

Base musi wiedzieć, że:

„Koszulka ABC czarna L”

w magazynie jest tym samym produktem co:

„Koszulka ABC czarna rozmiar L”

w ofercie na marketplace.

Nie wystarczy podobna nazwa.

Oferta powinna zostać powiązana z konkretnym produktem znajdującym się w wybranym magazynie.

Przy istniejących ofertach Base może pomagać w automatycznym dopasowaniu produktów między innymi na podstawie:

EAN, SKU albo nazwy.

Właśnie dlatego dobre SKU i poprawne numery EAN są tak ważne przy sprzedaży wielokanałowej.

Jeżeli sklep posiada dwa różne produkty o nazwie „Etui czarne” i oba mają pusty EAN oraz przypadkowe SKU, automatyczne dopasowanie robi się ryzykowne.

W praktyce dobry katalog powinien mieć możliwie trwały identyfikator produktu niezależny od tego, jak handlowiec później zmieni nazwę marketingową.

Co dzieje się po sprzedaży produktu?

Załóżmy, że firma ma 10 sztuk produktu i sprzedaje go jednocześnie na kilku marketplace’ach.

Klient kupuje jedną sztukę na platformie A.

Base pobiera zamówienie.

Jeżeli oferta jest prawidłowo powiązana z produktem, system może zmniejszyć odpowiedni stan magazynowy.

Z 10 sztuk robi się 9.

Następnie moduły synchronizacji pozostałych kanałów dostają informację, że aktualny stan wynosi 9 i mogą zmienić liczbę dostępnych sztuk w pozostałych ofertach.

Schemat wygląda więc mniej więcej tak:

sprzedaż na marketplace → zamówienie w Base → zmniejszenie stanu produktu → aktualizacja ofert w pozostałych kanałach.

To właśnie mechanizm, który ogranicza ryzyko sprzedaży tego samego ostatniego egzemplarza jednocześnie w kilku miejscach.

Stan nie zawsze zmniejsza się dokładnie w momencie kliknięcia „Kup”

To ważny szczegół.

Base musi najpierw otrzymać i odpowiednio przetworzyć zamówienie z zewnętrznego kanału.

Moment zmniejszenia stanu zależy między innymi od integracji i konfiguracji procesu zamówienia.

Można również określić moment realizacji zamówienia z punktu widzenia magazynu.

Dodatkowo w Katalogu Base.com dostępny jest mechanizm rezerwacji stanów.

Dzięki niemu produkt może zostać zarezerwowany już po pojawieniu się zamówienia, zanim nastąpi jego ostateczne zdjęcie z magazynu.

Załóżmy, że fizycznie znajduje się 5 sztuk produktu, ale klienci złożyli zamówienia na 3 sztuki.

System może pokazywać:

**stan fizyczny: 5,
zarezerwowane: 3,
realnie dostępne: 2.**

To znacznie bezpieczniejsze niż informowanie każdego kolejnego kanału, że nadal można sprzedać wszystkie pięć sztuk.

Synchronizacja może działać w kilku odstępach czasu

Nie każda synchronizacja oznacza natychmiastową zmianę w ułamku sekundy.

Dla stanów w ofertach marketplace Base udostępnia różne częstotliwości synchronizacji, w tym – zależnie od konfiguracji – synchronizację na żywo, co godzinę lub w dłuższych odstępach.

Dla cen również można ustawić różne interwały.

Ma to znaczenie praktyczne.

Jeżeli firma sprzedaje 2 sztuki produktu miesięcznie i ma ich 500 na stanie, aktualizacja co kilka godzin prawdopodobnie nie będzie problemem.

Jeżeli sprzedaje popularny produkt w Black Friday w tempie 30 sztuk na minutę, nawet niewielkie opóźnienia zaczynają mieć znaczenie.

Dlatego częstotliwość synchronizacji powinna odpowiadać rotacji produktów i liczbie kanałów.

Co się stanie, gdy stan spadnie do zera?

Automatyzacja nie musi ograniczać się do wpisania „0”.

Base może odpowiednio skonfigurować zachowanie ofert, gdy produkt się skończy.

W zależności od platformy i ustawień możliwe jest automatyczne zakończenie oferty po osiągnięciu zerowego stanu, a później jej wznowienie, gdy produkt znowu pojawi się w magazynie.

Przykład:

rano magazyn ma 1 sztukę,

klient ją kupuje,

stan spada do 0,

oferta przestaje być dostępna,

po południu magazyn przyjmuje dostawę 20 sztuk,

stan ponownie rośnie,

oferta może zostać wznowiona zgodnie z konfiguracją.

Pracownik nie musi sprawdzać ręcznie każdego marketplace’u.

Przy tysiącach ofert jest to jedna z najważniejszych korzyści automatycznej synchronizacji.

Z cenami działa to podobnie, ale można stosować różne reguły

Firma nie musi sprzedawać produktu w tej samej cenie wszędzie.

Załóżmy:

cena w sklepie – 100 zł,
marketplace A – 105 zł,
marketplace B – 109 zł.

Różnice mogą wynikać z prowizji, kosztów obsługi, waluty albo strategii sprzedaży.

Base pozwala pracować z grupami cenowymi oraz mnożnikami cen.

Można więc przechowywać kilka cen albo na podstawie ceny źródłowej obliczać wartość dla danego kanału.

Jeżeli cena bazowa zmieni się ze 100 na 110 zł, odpowiednio skonfigurowana synchronizacja może zaktualizować ceny ofert.

Nie trzeba otwierać tysiąca ofert i zmieniać każdej osobno.

Trzeba natomiast bardzo uważać na mnożniki.

Jeżeli cena jest modyfikowana najpierw przez regułę hurtowni, a później jeszcze przez regułę konkretnego marketplace’u, końcowa wartość może znacznie odbiegać od tej, której spodziewa się sprzedawca.

Dlatego przed uruchomieniem synchronizacji cen najlepiej sprawdzić kilka produktów z różnych przedziałów cenowych.

Hurtownia może być źródłem stanów i cen

Synchronizacja robi się szczególnie przydatna w dropshippingu.

Firma może nie mieć produktu fizycznie u siebie. Sprzedaje asortyment dostawcy, który posiada np. 50 000 indeksów.

Ręczne sprawdzanie dostępności byłoby praktycznie niemożliwe.

Base może korzystać z podłączonego magazynu hurtowni i pobierać z niego aktualne informacje o dostępności oraz cenach.

Załóżmy, że dostawca zmienia stan produktu:

83 → 12 → 0.

Base pobiera te informacje, a następnie może odpowiednio reagować na oferty sprzedażowe.

Gdy produkt znika z hurtowni, można ograniczyć jego dostępność albo zakończyć ofertę.

Kiedy pojawia się ponownie, oferta może zostać przywrócona.

W dropshippingu jest to szczególnie ważne, ponieważ sprzedawca nie widzi magazynu dostawcy fizycznie. Bez automatycznej wymiany danych dowiaduje się o braku często dopiero po złożeniu zamówienia przez klienta.

Można zostawić zapas bezpieczeństwa

Nie zawsze warto wystawiać dokładnie tyle sztuk, ile pokazuje hurtownia.

Dostawca informuje, że ma 5 produktów.

W tym samym czasie sprzedaje je jednak również stu innym odbiorcom. Stan może zniknąć, zanim kolejne odświeżenie dotrze do naszego systemu.

Dlatego można stosować korekty stanów.

Przykładowa reguła może być taka:

jeżeli hurtownia ma od 0 do 5 sztuk → pokazuj 0.

Dzięki temu sklep tworzy bufor bezpieczeństwa.

Inny wariant może ukrywać rzeczywistą liczbę dostępnych sztuk przed klientami i marketplace’em.

Nie powinno się jednak ustawiać takich reguł przypadkowo.

Zbyt duży bufor powoduje, że sklep przestaje oferować produkt mimo jego dostępności. Zbyt mały zwiększa ryzyko sprzedaży towaru, którego dostawca już nie posiada.

Można również pobierać dane z ERP lub systemu księgowo-magazynowego

Dla większej firmy głównym magazynem często nie jest ani sklep, ani Base.

Jest nim ERP.

Firma przyjmuje dostawy, wykonuje dokumenty magazynowe i prowadzi stany właśnie tam. Base odpowiada natomiast za e-commerce.

W takim układzie nie ma sensu wymagać od magazyniera zmiany ilości w dwóch programach.

Przy obsługiwanych integracjach produkty można powiązać z systemem zewnętrznym i pobierać z niego stany oraz ceny do Base.

Proces może wyglądać tak:

PZ w ERP → wzrost stanu → aktualizacja Base → aktualizacja marketplace’ów.

Po sprzedaży przepływ informacji może działać dalej zgodnie z możliwościami konkretnej integracji.

Zakres integracji z systemami ERP i księgowymi nie jest jednak zawsze taki sam. Jedna może obsługiwać stany i ceny, druga dodatkowo dokumenty, a kolejna wymagać osobnego rozwiązania.

Dlatego przed wdrożeniem trzeba sprawdzić konkretną integrację, a nie sam fakt, że logo programu znajduje się na liście połączeń.

Synchronizacja stanu i synchronizacja całej karty produktu to dwie różne rzeczy

To chyba najważniejsza pułapka językowa.

Sprzedawca słyszy:

„Base synchronizuje produkty”

i zakłada, że gdy zmieni w katalogu:

nazwę,
opis,
zdjęcia,
EAN,
wagę,
parametry,
SKU,
cenę i stan,

wszystko automatycznie pojawi się na każdej platformie.

Tak to nie działa w każdym przypadku.

Automatyczna synchronizacja stanów i cen jest osobnym mechanizmem.

Dane oferty takie jak opis, zdjęcia czy inne informacje produktowe mogą być aktualizowane z magazynu, ale wymagają odpowiednich operacji i zależą od możliwości konkretnego marketplace’u.

Niektóre zmiany mogą również wymagać odświeżenia powiązania oferty z produktem.

Dlatego przed masową zmianą danych warto odpowiedzieć sobie na pytanie:

czy zmieniam dane magazynowe, które są synchronizowane automatycznie, czy treść istniejącej oferty?

To nie zawsze ten sam proces.

Szczególnie uważać trzeba na EAN i SKU

EAN i SKU są często wykorzystywane do identyfikowania i automatycznego dopasowywania produktów.

Jeżeli firma bez planu zmieni SKU w jednym systemie, może zerwać istniejące powiązanie albo utrudnić późniejsze dopasowanie danych.

Jeszcze gorsze są duplikaty.

Dwa produkty mają ten sam SKU.

Albo kilka wariantów ma ten sam EAN.

Dla pracownika różnica może być oczywista na podstawie zdjęcia. Dla automatu już nie.

Przed dużym wdrożeniem Base warto więc wykonać porządek w katalogu:

usunąć przypadkowe duplikaty,
ustalić jednolity sposób tworzenia SKU,
sprawdzić EAN,
zweryfikować warianty,
usunąć stare produkty, które nie powinny już uczestniczyć w sprzedaży.

Im czystsza baza wejściowa, tym mniej ręcznego poprawiania powiązań.

Warianty są bardziej wymagające niż zwykły produkt

Koszulka dostępna w pięciu rozmiarach i czterech kolorach może oznaczać 20 różnych wariantów.

Każdy ma własny stan.

Czarna M może mieć 12 sztuk, a czarna XL – 0.

Nie wystarczy więc powiązać oferty z nadrzędnym produktem „Koszulka ABC”.

Trzeba prawidłowo odwzorować warianty.

To samo dotyczy produktów takich jak:

buty w różnych rozmiarach,
telefony w różnych pojemnościach,
kosmetyki w kilku wariantach,
części w różnych wersjach,
odzież w wielu kolorach.

Błędne powiązanie może spowodować, że sprzedaż rozmiaru M zmniejszy zapas XL albo oferta pokaże dostępny wariant, którego fizycznie już nie ma.

Dlatego po migracji katalogu wariantowego nie wystarczy sprawdzić kilku głównych produktów. Trzeba przetestować również sprzedaż konkretnych wariantów.

A co z kilkoma magazynami?

Firma może mieć magazyn główny, sklep stacjonarny, drugi oddział albo kilka źródeł dostaw.

Wtedy „stan produktu” przestaje być jedną liczbą.

Może wyglądać tak:

Warszawa – 8 sztuk,
Kraków – 5 sztuk,
magazyn centralny – 20 sztuk.

Do tego mogą dojść zarezerwowane egzemplarze.

Trzeba zdecydować, jaki stan powinien być wykorzystywany przez konkretny kanał.

Sklep internetowy może korzystać z magazynu centralnego. Punkt stacjonarny z własnego. Marketplace może korzystać z określonego magazynu lub z procesu zbudowanego według przyjętych reguł.

Najważniejsza zasada pozostaje ta sama: firma musi wiedzieć, które miejsce jest źródłem konkretnej wartości.

Najgroźniejszy błąd to dwie bazy nadrzędne

Wyobraźmy sobie taki proces.

Base wysyła stan 20 do sklepu.

Pracownik w sklepie ręcznie poprawia go na 17.

Base nadal uważa, że właściwa wartość to 20.

Przy kolejnej synchronizacji mogą pojawić się niezgodności, ponieważ systemy nie mają jednej odpowiedzi na pytanie, gdzie stan powinien być zmieniany.

Jeżeli Base jest nadrzędny, zmiany trzeba wykonywać zgodnie z tym modelem.

Jeżeli nadrzędny jest ERP, to właśnie tam powinny powstawać operacje magazynowe, a Base ma je pobierać.

Nie wolno budować integracji według zasady:

„czasem poprawiamy tu, a czasem tam”.

To praktycznie gwarantuje problemy.

Jak wdrożyć synchronizację bez ryzyka?

Nie zaczynałbym od podłączenia wszystkich 30 000 produktów.

Najpierw warto wybrać niewielką grupę.

Na przykład:

produkt zwykły,
produkt z wariantami,
produkt o niskim stanie,
produkt z kilkoma cenami,
produkt sprzedawany na kilku marketplace’ach.

Następnie można wykonać rzeczywisty test.

Zmieniamy stan z 10 na 8.

Sprawdzamy, gdzie pojawiła się zmiana.

Składamy zamówienie na jedną sztukę.

Kontrolujemy nowy stan.

Anulujemy zamówienie.

Sprawdzamy zachowanie rezerwacji.

Zmieniamy cenę.

Kontrolujemy wszystkie marketplace’y.

Ustawiamy stan 0.

Sprawdzamy, czy oferta zachowała się tak, jak przewiduje konfiguracja.

Dopiero po przejściu całego cyklu warto rozszerzać synchronizację na pozostały asortyment.

Dobrze ustawionej synchronizacji prawie nie powinno być widać

To najlepszy test całego rozwiązania.

Magazyn przyjmuje towar.

Stany aktualizują się w systemie nadrzędnym.

Base przekazuje właściwą dostępność do kanałów.

Klient kupuje produkt na jednym marketplace.

Pozostałe kanały dostają nowy stan.

Cena zostaje zmieniona w miejscu, które firma uznała za nadrzędne.

Nowa wartość pojawia się tam, gdzie powinna.

Towar się kończy.

Oferty przestają pozwalać na dalszą sprzedaż.

Przyjeżdża kolejna dostawa.

Produkty ponownie stają się dostępne.

Pracownik magazynu nie loguje się przy tym do pięciu marketplace’ów, a osoba odpowiedzialna za sklep nie poprawia codziennie setek stanów ręcznie.

Na tym polega rzeczywista wartość synchronizacji produktów w Base.com.

Nie chodzi o samo „połączenie Allegro ze sklepem”. Chodzi o stworzenie jednego uporządkowanego przepływu danych, w którym wiadomo, skąd pochodzi stan, skąd cena, z jakim produktem związana jest oferta i który system ma prawo zmienić daną informację.

Jeżeli te zasady są ustalone dobrze, Base może automatyzować dużą część codziennej pracy. Jeżeli nie są, synchronizacja tylko szybciej rozprowadzi błędne dane po wszystkich kanałach sprzedaży.