Integracja BaseLinker z Allegro i innymi marketplace'ami

Kilka platform naraz bez centralnego zarządzania

Sprzedaż prowadzona równolegle w kilku miejscach szybko przestaje być możliwa do ogarnięcia ręcznie: osobne panele, osobne stany, osobne zamówienia. Integracja spina to w jedno miejsce — pod warunkiem że stany i kody produktów są uporządkowane.

Co daje połączenie platform

• Wspólny stan magazynowy dla wszystkich kanałów.
• Zamówienia z każdej platformy w jednej liście.
• Wystawianie i aktualizację ofert bez wchodzenia do paneli platform.
• Jednolitą obsługę wysyłki niezależnie od kanału.
• Wspólne dokumenty sprzedaży.

Największe ryzyko

Sprzedanie ostatniej sztuki w dwóch kanałach naraz. Zdarza się, gdy odświeżanie stanów jest zbyt rzadkie albo gdy rezerwacje liczone są po obu stronach inaczej. Ustawiamy to jednoznacznie i sprawdzamy na produktach o niskim stanie — bo tam problem ujawnia się najpierw.

Wymagania platform

Każda ma własne zasady dotyczące opisów, parametrów i zdjęć. Oferta przygotowana pod jedną platformę bywa odrzucana przez inną. Przygotowujemy szablony dopasowane do wymagań każdej z nich, zamiast poprawiać oferty pojedynczo.

Prowizje

Różnią się między kanałami i wpływają na rzeczywistą rentowność. Konfigurujemy przekazywanie kosztów prowizji do zestawień, żeby dało się porównać kanały nie po obrocie, lecz po zysku.

Kontrola po uruchomieniu

Przez pierwszy okres sprawdzamy zgodność stanów po każdej sprzedaży w kanale rzadziej używanym.

Od czego zależy poprawna synchronizacja ofert

Samo połączenie konta marketplace z BaseLinkerem nie porządkuje automatycznie katalogu. Najpierw trzeba ustalić, który rekord produktu jest źródłem danych dla pozostałych kanałów. Rekord oznacza tutaj zestaw informacji o jednym towarze, takich jak kod, nazwa, stan, cena i wariant. Bez wskazania głównego źródła ta sama cecha może mieć inną wartość w magazynie, sklepie oraz na marketplace.

Podstawą powiązania są zwykle jednoznaczne kody produktów. Jeżeli ten sam kod przypisano kilku różnym towarom albo jeden produkt występuje pod kilkoma kodami, automatyzacja może aktualizować niewłaściwą ofertę. Przed uruchomieniem integracji sprawdzamy duplikaty, puste pola i różnice w oznaczeniach. Dotyczy to również wariantów, czyli wersji tego samego produktu różniących się na przykład rozmiarem lub kolorem.

Osobnej decyzji wymaga sposób przekazywania cen. W jednym kanale może obowiązywać cena podstawowa, w innym cena powiększona o koszty sprzedaży, a w sklepie czasowa promocja. Reguła cenowa, czyli zasada automatycznego wyliczania ceny, powinna wskazywać źródło oraz sposób aktualizacji. Zapobiega to przypadkowemu nadpisaniu cen ustawionych świadomie dla konkretnego kanału.

Różne warianty zarządzania stanem magazynowym

Najprostszy wariant zakłada jeden magazyn i jeden wspólny stan dostępny dla wszystkich platform. Każde zamówienie pomniejsza wtedy tę samą pulę towaru. Takie rozwiązanie jest czytelne, ale wymaga poprawnego rozpoznawania anulowanych zamówień, zwrotów i ręcznych korekt magazynowych.

W bardziej rozbudowanym modelu sprzedaż korzysta z kilku magazynów. Towar może znajdować się w różnych lokalizacjach albo część zapasu może być przeznaczona wyłącznie dla określonego kanału. Trzeba wtedy ustalić, czy platforma ma otrzymywać sumę stanów, stan jednego magazynu czy wartość obliczaną według własnej reguły.

Stosuje się również bufor bezpieczeństwa, czyli liczbę sztuk celowo niewystawianych do sprzedaży. Bufor ogranicza ryzyko przyjęcia zamówienia na towar, który został uszkodzony, odłożony dla klienta albo nie został jeszcze poprawnie rozliczony. Nie rozwiązuje jednak błędnego mapowania produktów. Jeżeli oferta jest połączona z niewłaściwą kartą magazynową, samo zmniejszenie dostępnego stanu nie usunie przyczyny problemu.

Istotna jest też kolejność zdarzeń. Zamówienie może zostać pobrane z platformy, zarezerwować towar, zmienić status, zostać anulowane, a następnie zwolnić rezerwację. Każdy z tych etapów powinien mieć określony wpływ na stan. Niejednoznaczne reguły prowadzą do sytuacji, w której towar wraca do sprzedaży zbyt wcześnie albo pozostaje zablokowany mimo anulowania zamówienia.

Obsługa zamówień wymaga spójnych statusów

Centralna lista zamówień jest użyteczna dopiero wtedy, gdy statusy mają jasne znaczenie. Status to etap obsługi, na przykład zamówienie nowe, opłacone, gotowe do wysyłki albo anulowane. Marketplace, sklep i program magazynowy mogą nazywać podobne etapy inaczej. Potrzebne jest więc mapowanie statusów, czyli przypisanie etapów z jednego systemu do odpowiadających im etapów w drugim.

Nie każdy status powinien od razu uruchamiać dalsze działania. Utworzenie dokumentu, przygotowanie przesyłki lub wysłanie wiadomości do klienta powinno następować dopiero po spełnieniu ustalonych warunków. Przykładowo zamówienie oczekujące na płatność nie zawsze powinno być traktowane tak samo jak zamówienie opłacone. Reguły trzeba dopasować do rzeczywistego procesu firmy, a nie wyłącznie do nazw widocznych w panelach.

Ważne jest również rozdzielenie czynności automatycznych od ręcznych. Automatyzacja może przenosić zamówienia między statusami, generować dokumenty i przekazywać dane do wysyłki. Wyjątki, takie jak brak towaru, zmiana adresu lub częściowy zwrot, powinny trafiać do osobnej kolejki. Dzięki temu nietypowa sprawa nie przechodzi przez standardowy proces bez kontroli.

Warianty ofert i różnice między marketplace'ami

Jedna karta produktu nie zawsze może zostać opublikowana bez zmian we wszystkich kanałach. Platformy stosują własne kategorie, parametry obowiązkowe i zasady prezentowania wariantów. Parametr obowiązkowy to cecha, którą trzeba uzupełnić, aby oferta mogła zostać wystawiona lub zaktualizowana. Brak takiej wartości może zatrzymać publikację mimo kompletnego opisu produktu.

Problemy pojawiają się także wtedy, gdy kategorie są podobne z nazwy, ale wymagają innych danych. Automatyczne przypisanie do pierwszej pasującej kategorii może skutkować brakiem właściwych parametrów albo umieszczeniem oferty w niewłaściwym dziale. Dlatego mapowanie kategorii i cech sprawdza się na reprezentatywnej grupie produktów, obejmującej towary proste, wariantowe i nietypowe.

Szablon oferty powinien oddzielać informacje wspólne od elementów zależnych od kanału. Nazwa produktu, podstawowy opis i dane magazynowe mogą pochodzić z jednego źródła. Tytuł, układ opisu, kategoria oraz wybrane parametry mogą wymagać osobnych ustawień. Takie rozdzielenie ułatwia późniejsze zmiany i ogranicza ryzyko, że korekta dla jednej platformy pogorszy oferty w pozostałych.

Najczęstsze błędy przy samodzielnej konfiguracji

Częstym błędem jest włączenie automatycznej synchronizacji przed sprawdzeniem kodów produktów. W efekcie pierwsza aktualizacja może przypisać stan lub cenę do niewłaściwych ofert. Bezpieczniej najpierw wykonać kontrolę powiązań, a dopiero później pozwolić systemowi na automatyczne zmiany.

Inny problem to jednoczesne ustawienie kilku źródeł jako nadrzędnych. Cena zostaje zmieniona w sklepie, następnie przesłana do BaseLinkera, a później nadpisana wartością z programu magazynowego. Powstaje pętla aktualizacji, czyli cykl, w którym systemy przekazują sobie kolejne, sprzeczne wersje danych. Każdy rodzaj informacji powinien mieć jedno jasno wskazane źródło główne.

Ryzykowne jest też testowanie od razu na całym katalogu. Błąd w regule ceny, szablonie lub kategorii obejmuje wtedy wiele ofert. Test na kilku zróżnicowanych produktach pozwala zobaczyć rezultat bez wprowadzania masowych zmian. Dopiero po sprawdzeniu stanów, cen, opisów i obsługi zamówienia można rozszerzyć konfigurację.

Nie należy usuwać i ponownie tworzyć powiązań bez zapisania dotychczasowych ustawień. Taka próba może utrudnić rozpoznanie, które oferty były połączone prawidłowo. Przed zmianami warto zebrać informacje o źródłach stanów, regułach cenowych, magazynach, statusach i automatycznych akcjach. Ułatwia to odtworzenie poprawnych elementów konfiguracji.

Kiedy problem nie wynika z samej integracji

Brak aktualizacji oferty nie zawsze oznacza awarię połączenia BaseLinkera z marketplace'em. Przyczyną może być niekompletna karta produktu, brak obowiązkowego parametru, zakończona oferta albo zmiana wymagań kategorii. W takim przypadku komunikacja między systemami może działać, ale platforma odrzuca konkretną operację.

Rozbieżny stan nie musi też wynikać z opóźnienia synchronizacji. Niekiedy jedna oferta jest powiązana z innym wariantem niż zakładano albo ręczna rezerwacja została wykonana tylko w systemie magazynowym. Trzeba wtedy prześledzić źródło stanu oraz historię operacji, zamiast wielokrotnie uruchamiać aktualizację.

Jeżeli zamówienie jest widoczne w BaseLinkerze, ale nie przechodzi do księgowości lub magazynu, problem może dotyczyć kolejnego połączenia. Integracja z marketplace'em odpowiada wtedy za pobranie zamówienia, natomiast przekazanie dokumentu lub pozycji do innego programu jest osobnym etapem. Rozdzielenie tych etapów skraca diagnostykę i zapobiega zmianom w działającym fragmencie konfiguracji.

Dodatkowe pytania o integrację BaseLinkera

Czy można podłączyć nowe konto bez zatrzymywania obecnej sprzedaży?

Tak, ale nowe połączenie powinno być uruchamiane etapami. Najpierw sprawdza się dostęp do konta, import ofert i zgodność produktów. Następnie testuje się aktualizację wybranych stanów oraz pobranie zamówienia. Automatyczne akcje dla całego kanału włącza się po potwierdzeniu, że testowy proces przebiega zgodnie z założeniami.

Czy każda oferta musi mieć identyczny tytuł i opis?

Nie. Dane wspólne mogą pochodzić z jednej karty produktu, ale treść prezentowana klientowi można dostosować do wymagań kanału. Ważne, aby różnice były zaplanowane. Ręczne poprawianie pojedynczych ofert bez określenia źródła danych może spowodować ich nadpisanie podczas kolejnej aktualizacji.

Co zrobić, gdy ten sam produkt ma różne kody w kilku systemach?

Trzeba przygotować jednoznaczne powiązanie między kodami i ustalić kod główny. Nie należy łączyć rekordów wyłącznie na podstawie podobnej nazwy, ponieważ nazwy bywają skracane lub zmieniane. Szczególnej kontroli wymagają warianty oraz zestawy składające się z kilku produktów.

Czy możliwe jest pozostawienie części ofert poza synchronizacją?

Tak. Wybrane oferty mogą wymagać ręcznego zarządzania ze względu na indywidualną cenę, nietypowy stan albo odmienny sposób realizacji. Taki wyjątek powinien być jednak oznaczony i udokumentowany. W przeciwnym razie później trudno ustalić, czy brak aktualizacji jest zamierzony, czy wynika z błędu.

Jak sprawdzić integrację po zmianie ustawień?

Należy przejść cały proces na kontrolowanym produkcie: sprawdzić powiązanie, zmianę stanu, przekazanie ceny, pobranie zamówienia, rezerwację towaru i właściwy status. Potem warto zweryfikować anulowanie oraz zwolnienie rezerwacji. Sama poprawna publikacja oferty nie potwierdza jeszcze, że pozostałe etapy działają prawidłowo.

Spójny katalog jest podstawą sprzedaży wielokanałowej

Dobrze skonfigurowana integracja nie polega na podłączeniu możliwie wielu funkcji. Najważniejsze są jednoznaczne źródła danych, poprawne kody produktów, przemyślane reguły stanów i czytelny obieg zamówień. Gdy każdy kanał otrzymuje właściwe informacje, można rozwijać sprzedaż bez ręcznego porównywania kilku paneli po każdej transakcji. Jeżeli pojawiają się rozbieżności, analizujemy drogę konkretnego produktu i zamówienia od źródła aż do marketplace'u, a następnie porządkujemy reguły odpowiedzialne za aktualizację.