Jak uniknąć chaosu podczas sprzedaży na wielu platformach?

Na jednej platformie produkt kosztuje 129 zł, na drugiej nadal 119 zł. Ostatnia sztuka zostaje sprzedana w sklepie, ale Allegro wciąż pokazuje ją jako dostępną. Zamówienie z Amazonu jest już wysłane, choć w wewnętrznym systemie nadal ma status „nowe”. Klient zwrócił produkt przez marketplace, ale magazyn nie wie jeszcze, czy może ponownie wprowadzić go do sprzedaży.

Przy kilku zamówieniach da się to kontrolować ręcznie. Przy kilkuset nie pomoże nawet bardzo dobrze prowadzony Excel.

Sprzedaż wielokanałową trzeba zorganizować tak, aby platform było wiele, ale produkt, stan magazynowy i proces realizacji zamówienia miały jedno źródło prawdy.

Najpierw ustal, gdzie naprawdę znajduje się magazyn

Najczęstszy problem zaczyna się niewinnie.

Firma ma:

WooCommerce – 15 sztuk,
Allegro – 15 sztuk,
Amazon – 15 sztuk.

W rzeczywistości w magazynie znajduje się 15 sztuk, a nie 45.

Jeżeli każde miejsce prowadzi własny stan, sprzedaż jednej sztuki na Allegro powinna uruchomić zmianę w dwóch pozostałych kanałach. Jeżeli któryś pracownik o tym zapomni albo integracja zadziała z opóźnieniem, można sprzedać produkt, którego już nie ma.

Dlatego jeden system powinien być nadrzędnym źródłem stanu.

Może to być ERP, WMS, system sklepu internetowego albo platforma integrująca marketplace’y. Konkretne rozwiązanie ma mniejsze znaczenie niż zasada:

stan zmieniamy w jednym miejscu, a pozostałe kanały otrzymują aktualizację automatycznie.

Jeżeli w magazynie znajduje się 27 sztuk produktu, wszystkie oferty powinny wynikać z właśnie tej wartości.

Po sprzedaży trzech sztuk:

27 → 24.

System aktualizuje dostępność we wszystkich połączonych kanałach.

Pracownik nie powinien nawet zastanawiać się, na których platformach dany produkt jest obecnie wystawiony.

Nie zawsze pokazuj cały fizyczny zapas

Synchronizacja nie oznacza, że na każdym marketplace trzeba udostępniać dokładnie tyle sztuk, ile znajduje się na półce.

Czasem rozsądniejszy jest bufor.

Firma posiada fizycznie:

10 sztuk.

Do sprzedaży internetowej udostępnia:

8 sztuk.

Dwie pozostają jako zabezpieczenie.

Ma to sens szczególnie przy produktach szybko rotujących, sprzedaży stacjonarnej albo integracjach, w których aktualizacja nie następuje natychmiast.

Można również stosować osobne reguły dla kanałów.

Przykładowo przy stanie magazynowym 50 sztuk:

Allegro może pokazywać maksymalnie 20,
Amazon maksymalnie 15,
własny sklep cały dostępny stan.

Nie zmienia to faktu, że wszystkie kanały korzystają z tego samego rzeczywistego magazynu.

Takie ograniczenie może chronić również przed sytuacją, w której niespodziewanie duże zamówienie z jednego marketplace’u wyczyści cały zapas przeznaczony także dla innych klientów.

Każdy produkt potrzebuje jednego identyfikatora

Synchronizacja zaczyna się rozpadać, jeśli system nie wie, że trzy oferty dotyczą tego samego produktu.

W ERP widnieje:

ABC-123-CZ

Na Allegro:

Lampa czarna 123

Na Amazonie:

SKU0004382

A w sklepie:

lamp-czarna-new.

Dla człowieka może być oczywiste, że chodzi o tę samą lampę. Dla automatyzacji już niekoniecznie.

Dlatego warto uporządkować SKU.

Konkretny wariant produktu powinien mieć jeden stabilny kod, np.:

LAMPA-ABC-BLACK-40

i ten sam identyfikator powinien być wykorzystywany wszędzie tam, gdzie jest to możliwe.

EAN pomaga dodatkowo identyfikować produkt, ale nie zawsze zastąpi SKU. Firma może przecież sprzedawać własne zestawy, opakowania zbiorcze albo produkty, dla których używa własnej wewnętrznej kartoteki.

Szczególnie dużo problemów powodują warianty.

Koszulka czarna M i koszulka czarna L nie są jednym towarem magazynowym.

Podobnie:

telefon 128 GB i 256 GB,
lampa 3000 K i 4000 K,
but 43 i 44.

Każdy rzeczywisty wariant powinien być powiązany z odpowiednim indeksem magazynowym.

Jedno błędne powiązanie może później sprawić, że sprzedaż rozmiaru L zmniejsza stan M na wszystkich marketplace’ach.

Nie zarządzaj cenami osobno na każdym marketplace

Drugi obszar, który szybko wymyka się spod kontroli, to ceny.

Produkt został przeceniony w sklepie z 299 na 269 zł.

Na Allegro pracownik również wprowadził 269 zł.

O eBayu zapomniał.

Na Amazonie cena była dodatkowo ustalana w euro i pozostała bez zmian przez kolejne trzy tygodnie.

Przy tysiącach ofert ręczne pilnowanie cen jest praktycznie niemożliwe.

Znacznie lepiej utrzymywać cenę bazową i na niej budować reguły dla kanałów.

Przykład:

cena bazowa: 100 zł

własny sklep: 100 zł,
marketplace A: 105 zł,
marketplace B: 110 zł.

Różnica może wynikać z prowizji, kosztów reklamy, logistyki albo strategii sprzedaży.

Nie trzeba więc utrzymywać identycznych cen wszędzie. Trzeba natomiast wiedzieć, skąd każda z nich się bierze.

Jeżeli cena zakupu wzrośnie, system może automatycznie przeliczyć ceny sprzedaży według ustalonych zasad.

Przy sprzedaży zagranicznej dochodzi waluta. Tu również lepiej zastosować określony sposób przeliczania i aktualizacji niż ręcznie wyceniać tysiące ofert.

Automatyczna zmiana cen ma jednak jedną pułapkę: powinna uwzględniać minimalną dopuszczalną marżę.

Sprzedaż może rosnąć bardzo szybko, jeżeli automat ciągle obniża cenę. Problem pojawia się wtedy, gdy po odjęciu prowizji marketplace’u, reklamy, kosztu dostawy i zwrotów okazuje się, że firma niemal nic na tej sprzedaży nie zarabia.

Wszystkie zamówienia powinny trafiać do jednej kolejki

Pracownik nie powinien rozpoczynać dnia od otwierania:

panelu sklepu,

Allegro,

Amazonu,

eBay,

kolejnego marketplace’u.

Nie powinien też musieć pamiętać, że na Amazonie zamówienie oczekujące wygląda w jeden sposób, a na innej platformie używana jest zupełnie inna nazwa statusu.

Zamówienia najlepiej sprowadzić do jednego procesu wewnętrznego.

Na przykład:

Nowe → Opłacone → Do kompletacji → Pakowanie → Gotowe do wysyłki → Wysłane.

Klient może przyjść z dowolnego kanału.

Dla magazyniera nie ma większego znaczenia, czy paczka powstała z zamówienia Allegro czy własnego sklepu. Ma wiedzieć, co pobrać, gdzie produkt się znajduje i jaką przesyłkę przygotować.

Dopiero po zmianie statusu system powinien przekazać odpowiednią informację do platformy źródłowej.

Zamówienie z eBayu zostało wysłane?

Informacja wraca do eBay.

Zamówienie z Allegro dostało numer przesyłki?

Numer trafia do Allegro.

Jeden proces wewnętrzny może więc obsługiwać różne wymagania zewnętrznych kanałów.

Automatyzuj rzeczy, które występują przy prawie każdym zamówieniu

Najwięcej czasu nie zawsze zabierają duże operacje.

Częściej problemem jest 20 małych czynności wykonywanych po kilkaset razy dziennie.

Pracownik kopiuje adres.

Wybiera kuriera.

Tworzy przesyłkę.

Pobiera etykietę.

Zmienia status.

Kopiuje numer przesyłki.

Wkleja go do marketplace’u.

Wystawia fakturę.

Wysyła wiadomość do klienta.

Jeżeli jedna taka sekwencja zajmuje tylko dwie minuty, przy 300 zamówieniach daje dziesięć godzin pracy.

Dużą część można usunąć.

Po spełnieniu określonych warunków system może sam:

utworzyć przesyłkę,

wygenerować etykietę,

przesłać numer trackingowy,

zmienić status,

przygotować fakturę,

wysłać dokument,

poinformować klienta.

Pracownik zajmuje się głównie produktem i paczką.

Automatyzacja powinna być jednak przewidywalna. Nie ma sensu tworzyć kilkuset skomplikowanych reguł, których po roku nikt w firmie nie rozumie.

Dobra reguła jest prosta:

jeżeli zamówienie jest opłacone, kompletne i ma wybraną metodę dostawy → prześlij je do realizacji.

Wyjątki trafiają do człowieka.

Wyjątki powinny być widoczne, a nie ginąć między poprawnymi zamówieniami

W prawidłowo działającej sprzedaży wielokanałowej pracownik nie powinien sprawdzać ręcznie wszystkich zamówień.

Powinien przede wszystkim widzieć te, z którymi coś jest nie tak.

Na przykład:

brakuje telefonu,

nie można utworzyć przesyłki,

produkt nie jest powiązany z magazynem,

płatność się nie zgadza,

stan spadł poniżej zera,

marketplace odrzucił aktualizację,

nie udało się wystawić faktury,

adres dostawy jest niekompletny.

To znacznie lepszy model niż system, który „automatyzuje” pracę, ale błędy zapisuje wyłącznie w technicznych logach.

Jeżeli przez dwa dni nie działa aktualizacja stanów na jednej platformie, osoba odpowiedzialna za sprzedaż powinna dowiedzieć się o tym szybko, a nie dopiero po otrzymaniu zamówienia na wyprzedany produkt.

Zwroty muszą wrócić do tego samego systemu

Sprzedaż nie kończy się po nadaniu paczki.

Przy wielu marketplace’ach równie łatwo stracić kontrolę nad zwrotami.

Klient kupił produkt na Amazonie, zwrócił go po tygodniu, magazyn odebrał paczkę, a dział sprzedaży nie wie jeszcze, czy została zrobiona korekta i czy produkt wrócił na stan.

Sam fizyczny powrót paczki nie powinien automatycznie zwiększać dostępnego zapasu.

Najpierw trzeba sprawdzić produkt.

Może być:

nieotwarty i pełnowartościowy,

otwarty, ale nadający się do ponownej sprzedaży,

uszkodzony,

niekompletny,

przeznaczony do reklamacji.

Dopiero po weryfikacji otrzymuje odpowiedni status magazynowy.

Dobrze, jeśli zwrot pozostaje powiązany z pierwotnym zamówieniem. Wtedy od razu wiadomo, skąd pochodził, za ile produkt został sprzedany, jaki dokument wystawiono i jaką płatność trzeba zwrócić.

Bez tego po kilku miesiącach powstaje osobny „świat zwrotów” prowadzony w mailach, arkuszach i panelach poszczególnych marketplace’ów.

Dokumenty sprzedażowe też powinny powstawać centralnie

Ten sam klient nie powinien dostać dwóch faktur tylko dlatego, że zamówienie pojawiło się jednocześnie w dwóch systemach, które uznały, że to one odpowiadają za fakturowanie.

Trzeba ustalić jedno miejsce odpowiedzialne za dokument sprzedaży.

Schemat może wyglądać tak:

marketplace → system obsługi zamówień → system fakturowania → KSeF.

Informacja o wystawieniu dokumentu wraca później do zamówienia.

To ważne również z punktu widzenia numeracji, korekt i późniejszego wyszukiwania sprzedaży.

Jeżeli faktura powstaje w jednym programie, korekta na marketplace, a zwrot płatności jeszcze w trzecim, ustalenie historii pojedynczego zamówienia staje się niepotrzebnie trudne.

Najlepiej, gdy otwarcie zamówienia pozwala zobaczyć całość:

źródło sprzedaży,

produkty,

płatność,

przesyłkę,

numer trackingowy,

fakturę,

zwrot,

korektę.

Nie wszystkie platformy działają tak samo

Centralizacja nie oznacza udawania, że Allegro, Amazon, eBay i własny sklep są identyczne.

Nie są.

Mają różne:

kategorie,

parametry produktów,

zasady tworzenia ofert,

statusy,

wymagania logistyczne,

prowizje,

formaty danych,

procesy zwrotów.

Dlatego jedna kartoteka produktu może być źródłem danych, ale oferta powinna być dostosowana do konkretnego kanału.

Na Amazonie produkt może być powiązany z istniejącą kartą katalogową. Allegro ma własne parametry kategorii. eBay również posiada własny model ofert i lokalizacji magazynowych.

Nie warto więc budować procesu polegającego na kopiowaniu jednej aukcji 1:1 na pięć platform.

Centralne powinny być informacje takie jak:

SKU,

EAN,

stan,

koszt zakupu,

dane techniczne,

zdjęcia źródłowe,

podstawowy opis.

Sposób prezentacji oferty może być różny.

Najpierw uporządkuj jeden kanał, później dodawaj kolejne

Firma czasami próbuje rozwiązać problem spadającej sprzedaży w ten sposób:

„Wejdźmy jeszcze na Amazon, eBay i dwa nowe marketplace’y”.

Jeżeli obecny proces jest chaotyczny, dodanie trzech platform nie rozwiązuje problemu. Powiększa go.

Najpierw warto uporządkować:

kartotekę produktów,

SKU,

stany,

ceny,

proces zamówienia,

wysyłkę,

fakturowanie,

zwroty.

Dopiero później można podłączyć następny kanał.

Wtedy wdrożenie wygląda znacznie prościej.

Nowy marketplace nie wymaga projektowania całej obsługi od początku. Trzeba tylko ustalić, jak jego dane zostaną włączone do istniejącego procesu.

Zamówienie nadal trafi do tej samej kolejki.

Produkt nadal korzysta z tego samego magazynu.

Faktura nadal powstanie w tym samym systemie.

Zmieni się jedynie źródło sprzedaży.

Testuj integrację na kilku produktach, nie na całym katalogu

To szczególnie ważne przy firmach posiadających tysiące SKU.

Po podłączeniu nowej platformy nie ma potrzeby od razu uruchamiać synchronizacji 30 000 ofert.

Najpierw wybierz kilkanaście produktów, najlepiej różnych:

prosty produkt,

produkt z wariantami,

zestaw,

towar z małym stanem,

produkt o innej stawce lub sposobie sprzedaży,

towar dostępny w kilku magazynach.

Następnie wykonaj prawdziwy test procesu.

Zmień cenę.

Sprawdź platformę.

Zmień stan.

Złóż zamówienie.

Sprawdź, czy zapas zmniejszył się wszędzie.

Anuluj zamówienie.

Nadaj paczkę.

Przeprowadź zwrot.

Dopiero kiedy cały cykl działa poprawnie, można zwiększać skalę.

Integracja, która błędnie obsługuje jeden produkt, jest irytująca.

Ta sama integracja uruchomiona od razu na 50 000 produktów może w kilka godzin zrobić ogromny bałagan.

Jedna osoba powinna odpowiadać za architekturę sprzedaży

Przy większej firmie pojawia się jeszcze problem organizacyjny.

Marketing zmienia nazwy produktów.

Handlowiec ustawia ceny.

Magazyn poprawia stany.

Księgowość zmienia dane kontrahentów.

E-commerce dodaje integracje.

Jeżeli każdy może niezależnie zmieniać dane podstawowe, w końcu przestaje być jasne, który system jest właściwy.

Nie oznacza to, że jedna osoba ma wykonywać wszystkie operacje.

Ktoś powinien jednak ustalić zasady:

gdzie tworzymy produkt,

gdzie zmieniamy SKU,

który stan jest nadrzędny,

skąd pochodzi cena,

który system wystawia fakturę,

kto może zmienić mapowanie ofert,

co dzieje się przy błędzie synchronizacji.

To bardziej istotne niż wybór konkretnego oprogramowania.

Można kupić bardzo zaawansowaną platformę integracyjną i nadal mieć chaos, jeśli pięć osób zmienia te same dane w pięciu miejscach.

Dobry system wielokanałowy powinien być nudny

Najlepiej działająca sprzedaż wielokanałowa z perspektywy pracownika nie wygląda szczególnie spektakularnie.

Rano widzi jedną listę zamówień.

Magazyn pokazuje właściwe stany.

System wie, skąd pobrać produkt.

Po spakowaniu drukuje się etykieta.

Numer przesyłki wraca do odpowiedniego marketplace’u.

Faktura powstaje zgodnie z ustalonym procesem.

Zwrot pojawia się przy właściwym zamówieniu.

Jeżeli coś się nie uda, system pokazuje wyjątek wymagający reakcji.

Pracownik nie musi wiedzieć, ile zapytań API zostało wykonanych między Allegro, sklepem, magazynem, kurierem i programem fakturowym.

I właśnie taki powinien być cel.

Sprzedaż na pięciu platformach nie powinna oznaczać pięciu osobnych procesów. Powinna być jednym procesem sprzedaży z pięcioma różnymi źródłami zamówień.

Dopóki firma zachowuje jedno źródło stanów, spójną kartotekę produktów i centralną obsługę zamówień, kolejny marketplace jest dodatkowym kanałem sprzedaży.

Kiedy każdy kanał zaczyna żyć własnym życiem, staje się kolejnym systemem, który ktoś musi codziennie pilnować.