Migracja z BaseLinkera do Sellasist bez zatrzymywania sprzedaży

Pytanie o zmianę systemu do obsługi sprzedaży wraca u naszych klientów regularnie, a od rebrandingu BaseLinkera na Base i przejścia na model „stała opłata plus stawka za zamówienie" wraca częściej. Wybór platformy to najprostsza część. Trudno robi się wtedy, gdy trzeba przełożyć na nowe tory działający organizm, przez który codziennie przechodzą zamówienia z Allegro, sklepu i kilku marketplace'ów.

Taka migracja różni się od wymiany dowolnego innego narzędzia w firmie jednym szczegółem: nie da się jej zrobić w weekend. Zamówienia spływają non stop, kurierzy odbierają codziennie, a stany muszą się zgadzać na wszystkich kanałach naraz. Każda godzina, w której dwa systemy uważają, że mają prawo aktualizować stany na tym samym koncie Allegro, kosztuje realne pieniądze i realne oceny.

Poniżej procedura, którą stosujemy przy takich przeprowadzkach. Jeśli dopiero decydujesz, czy się przenosić, zacznij od porównania Sellasist i BaseLinkera albo przeglądu alternatyw po podwyżkach. Ten tekst zakłada, że decyzja już zapadła.

TL;DR: Nie migruj przełącznikiem. Spisz wszystko, co BaseLinker robi u Ciebie dzisiaj, sprawdź punkt po punkcie pokrycie w Sellasist, skonfiguruj nowe konto obok starego i przepnij najpierw jeden najmniejszy kanał. Okres podwójnej obsługi jest kosztem, który kupuje Ci możliwość wycofania się. Nie ruszaj tego w szczycie sezonu i pilnuj, żeby stany na danym kanale aktualizował zawsze dokładnie jeden system.

Migracja to okres podwójnej obsługi, nie przełącznik

Najczęstszy plan, jaki dostajemy do zaopiniowania, brzmi tak: w piątek wyłączamy stary system, przez weekend przenosimy dane, w poniedziałek pracujemy na nowym. Zawodzi zawsze w tym samym miejscu. W poniedziałek okazuje się, że kurier nie generuje etykiet, bo klucz API był podpięty pod konto osoby, która odeszła pół roku temu, a zamówienia z soboty wiszą w systemie, do którego nikt nie ma już dostępu.

Alternatywa jest mniej efektowna. Nowe konto stoi obok starego, skonfigurowane i przetestowane, ale przez pewien czas nie obsługuje niczego realnego. Potem przejmuje jeden kanał, ten, na którym stracisz najmniej, gdy coś pójdzie nie tak. Podwójna obsługa kosztuje czas ludzi, ale kupuje możliwość wycofania się w dowolnym momencie.

Krok 1: inwentaryzacja tego, co BaseLinker robi dzisiaj

To najważniejszy i najczęściej pomijany etap. BaseLinker w firmie, która używa go od kilku lat, robi znacznie więcej, niż ktokolwiek pamięta. Kolejne osoby dokładały akcje automatyczne, statusy i wydruki, część z nich odeszła, konfiguracja została. Bez zamkniętej listy nie zweryfikujesz pokrycia w nowym systemie. Spis robimy w tabeli, każdy punkt dostaje właściciela po stronie firmy.

Lista wykłada się najczęściej na akcjach automatycznych, których nikt nie potrafi wytłumaczyć. Zapisz je mimo to, z adnotacją „nie wiemy, po co". Druga wpadka to integracje własne, czyli skrypty odpytujące API, o których wie jedna osoba. Jeśli spinaliście BaseLinkera z czymkolwiek po swojemu, ten kawałek opisaliśmy przy okazji łączenia go z n8n.

Gdy konfigurację budował wykonawca, którego już nie ma, inwentaryzacja zaczyna się od odzyskania dostępów. Procedurę zebraliśmy w tekście o przejęciu automatyzacji po freelancerze.

Krok 2: weryfikacja pokrycia w Sellasist

Przechodzisz przez listę punkt po punkcie i każdemu wpisowi nadajesz jeden ze statusów: jest (Sellasist robi to natywnie), obejście (da się osiągnąć, ale proces wygląda inaczej niż dziś), do zbudowania (trzeba dołożyć coś z zewnątrz).

Sellasist pokrywa większość typowego zakresu: dwustronną obsługę Allegro, eBay, Amazona i Arena.pl z wieloma kontami jednocześnie, moduł WMS (przyjęcie dostawy, rozlokowanie, zbieranie, pakowanie, zwroty, inwentaryzacja), akcje automatyczne „gdy warunek, to akcja", moduł faktur z obsługą JPK, eksport do EDI++ dla Subiekta i integracje kurierskie. Sellasist podaje ponad 400 integracji, Base kilkukrotnie więcej. Ta liczba sama w sobie nic nie znaczy: liczy się tylko to, czy są tam te konkretne integracje z Twojej listy z kroku 1.

Punkty „do zbudowania" to zwykle rzeczy poza zakresem obu platform: dosyłanie danych do systemu księgowego innego niż wspierany natywnie, raporty składane z kilku źródeł, powiadomienia operacyjne dla zespołu, integracja z systemem klienta B2B. U nas tę warstwę robi n8n i to jest moment, żeby ją zaplanować, a nie odkrywać po przepięciu. Zanim założysz, że coś się da spiąć, sprawdź, czy narzędzie po drugiej stronie ma API.

Zapisz też świadomie punkty, z których rezygnujesz. Części akcji nie ma sensu odtwarzać, bo powstały do procesu, którego już nie ma. To musi być decyzja, a nie przeoczenie.

„Najdroższy element takiej migracji to nigdy nie przeniesienie produktów. To odtworzenie kilkudziesięciu automatycznych akcji, które przez pięć lat dokładały cztery różne osoby i z których żadna nie została nigdzie opisana. Firmy wyceniają przeprowadzkę na podstawie katalogu produktów, a płacą za archeologię." — Mikołaj Brunka, założyciel NoCodeWork

Krok 3: konto skonfigurowane obok

Nowe konto konfigurujesz w całości, zanim cokolwiek przepniesz. Sellasist daje 30 dni testów wyższych pakietów i darmowy próg do 20 zamówień miesięcznie, co zwykle wystarcza na konfigurację i pilota. Kolejność, która się u nas sprawdza:

1. Katalog produktów: eksport, import, weryfikacja na próbce. Sprawdzasz nie liczbę pozycji, tylko warianty, jednostki miary, stawki VAT, kody EAN i zdjęcia. Największe straty powstają na wariantach.
2. Mapowania na kanały: szablony ofert, kategorie, pola specyficzne dla Allegro, ceny per kanał. Praca ręczna, bez skrótów.
3. Magazyn: lokalizacje, stany startowe, zasady rezerwacji. Stanów nie przenosisz raz na zawsze, tylko ustawiasz procedurę ich synchronizacji na moment przepięcia.
4. Statusy zamówień. Jeśli masz dwadzieścia statusów, z których dziesięć znaczy to samo, przenieś proces, nie bałagan. Wcześniej zmapuj go na kartce.
5. Akcje automatyczne z listy z kroku 1, po jednej, każda testowana osobno.
6. Dokumenty: wzory faktur, etykiet, list zbiórki.

Kanałów nie podłączasz na tym etapie w trybie aktywnej synchronizacji. Konta marketplace podpinasz w ostatniej możliwej chwili, w trybie odczytu albo na koncie testowym. Dwa systemy aktualizujące oferty na tym samym koncie to najprostsza droga do sprzedaży towaru, którego nie ma.

Krok 4: kurierzy, etykiety i numeracja dokumentów

Umowy kurierskie masz z przewoźnikiem, a nie z platformą, więc przy zmianie systemu ich nie tracisz. Przenosisz konfigurację: numery kont nadawczych, klucze API, dane nadawcy, punkty odbioru, domyślne gabaryty i wagi, obsługę pobrania. To jeden z dłuższych fragmentów pracy, bo każdy przewoźnik ma własne zestawy pól.

U każdego przewoźnika sprawdź osobno trzy rzeczy. Pule numerów listów przewozowych, bo część przewoźników przydziela je per integracja, a nadanie z dwóch systemów naraz kończy się duplikatem numeru i przesyłką, której nie da się rozliczyć. Protokoły nadania, bo kurier przyjeżdża po paczki z jednego protokołu, a w okresie podwójnej obsługi nadajesz z dwóch systemów. Statusy zwrotne i powiadomienia dla kupującego, bo to osobna integracja niż samo nadanie i łatwo o niej zapomnieć, po czym przez tydzień ręcznie odpowiadać na pytania „gdzie moja paczka".

Numerację dokumentów sprzedażowych uzgadniasz z księgowością, nie rozstrzygasz w panelu. Dwa systemy wystawiające faktury w tym samym miesiącu mogą wygenerować dwa dokumenty o tym samym numerze. Bezpieczne wyjście to nowa seria numeracji dla dokumentów z Sellasist, wprowadzona od pierwszego dnia pilota. Jeśli księgowość pracuje na Subiekcie albo Optimie, sprawdź też formaty przekazywania danych, bo bywają inne po obu stronach. Zebraliśmy to w tekście o spinaniu Optimy i Subiekta z automatyzacjami.

Krok 5: co zrobić z historią zamówień

Tego etapu nie załatwisz importem. Historia z pełnym kontekstem, czyli korespondencją z kupującym, dokumentami, śladem zmian statusów i danymi przesyłek, w komplecie się nie przenosi. Zamiast walczyć o przeniesienie wszystkiego, ustal, co musisz mieć dostępne i w jakiej formie.

Wracać do tych danych będziesz głównie z powodów formalnych. Roszczenia konsumenckie potrafią wrócić po dwóch latach od zakupu i potrzebujesz wtedy zamówienia, dowodu wysyłki i dokumentu sprzedaży. Dokumentację księgową przechowuje się pięć lat, licząc od początku roku następującego po roku obrotowym, którego dotyczy.

Praktycznie robimy to tak: pełny eksport zamówień z pozycjami i danymi kupujących do plików, osobno zrzut dokumentów PDF, a dane liczbowe do arkusza albo bazy, na której da się liczyć raporty. Eksport wykonujesz przed zmianą planu w starym systemie, bo okres przechowywania danych bywa różny w różnych pakietach i obniżenie planu potrafi skrócić dostęp do historii. Konto zostawiamy aktywne, w najniższym pakiecie, do zamknięcia okresu reklamacyjnego na ostatnich zamówieniach, które przez nie przeszły.

Na koniec sprawdź odtwarzalność archiwum. Weź losowe zamówienie sprzed roku i spróbuj z eksportu odtworzyć komplet: co, komu, kiedy, jaką przesyłką, na jaki dokument. Jeśli się nie da, archiwum jest niepełne i lepiej dowiedzieć się tego teraz.

Krok 6: przepięcie kanału pilotażowego

Pilota wybieramy według jednego kryterium: najmniejsza strata, gdy pójdzie źle. Zwykle jest to najmniejsze konto Allegro, poboczny marketplace albo sklep o niewielkim ruchu. Kanał, który robi połowę obrotu, przepinasz ostatni. Sama operacja jest krótka, ale ma kolejność:

1. Wstrzymanie synchronizacji stanów dla tego jednego kanału w BaseLinkerze. Nie globalnie, bo pozostałe muszą dalej działać.
2. Odczekanie na domknięcie zamówień w locie. Te, które już spłynęły, obsługujesz do końca w starym systemie.
3. Zgranie stanów i ich fizyczna weryfikacja na produktach o największej rotacji.
4. Podpięcie kanału w Sellasist i włączenie synchronizacji w jedną stronę.
5. Ręczne sprawdzanie pierwszych realnych zamówień, dopóki kilkanaście nie przejdzie bez zastrzeżeń.

Punkt pierwszy jest najważniejszy i to na nim firmy przewracają się najczęściej. Zasada brzmi: na jednym kanale stany aktualizuje w danym momencie dokładnie jeden system. Ani zero, ani dwa. Zero oznacza sprzedaż z nieaktualnych stanów, dwa oznaczają wyścig, który wygrywa ten, kto zapisał się później. Kończy się tak samo, czyli sprzedanym towarem, którego nie ma na półce.

W okresie podwójnej obsługi pilnuj też rzeczy pozornie drobnych: kto odbiera zamówienia z którego systemu, gdzie się drukuje, kto odpowiada na wiadomości. Jedna kartka na ścianie w magazynie robi tu więcej niż godzina szkolenia.

Testy end-to-end przed każdym przepięciem

Zamówienie testowe przepuszczamy przez pełny tor na każdym kanale osobno, przed jego przepięciem. Nie „na jednym, bo reszta działa tak samo", bo reszta nigdy nie działa tak samo. Test kończy się, gdy przejdzie cała ścieżka:

• zamówienie spływa z kompletem danych kupującego, adresem i danymi do faktury,
• akcje automatyczne odpalają się w oczekiwanej kolejności i na właściwych statusach,
• stan magazynowy schodzi i wraca na pozostałych kanałach,
• dokument sprzedaży ma prawidłową numerację i stawki VAT,
• etykieta drukuje się z poprawnymi gabarytami i kwotą pobrania,
• klient dostaje maile o statusach, dokładnie raz i z właściwego adresu,
• dane trafiają do księgowości w oczekiwanym formacie,
• zwrot i anulowanie zachowują się poprawnie (najczęściej pomijana ścieżka),
• zamówienie zagraniczne i z fakturą na firmę przechodzą tak samo.

Osobno przetestuj scenariusz brzegowy, na którym wykłada się najwięcej wdrożeń: dwa zamówienia na ten sam ostatni egzemplarz, złożone na dwóch kanałach w tej samej minucie.

Harmonogram etapów i plan rollback

Nie podam liczby tygodni, bo bez inwentaryzacji z kroku 1 byłaby zmyślona. Sklep z dwoma kanałami i pięciuset produktami to inna skala niż siedem kanałów, WMS i integracja z ERP. Struktura etapów jest za to stała, a każdy ma warunek wyjścia.

Plan rollback ustal, zanim przepniesz pierwszy kanał, i zapisz go jako progi, a nie odczucia. Przykładowy zestaw do dopasowania pod swoją skalę: więcej niż ustalony procent zamówień na pilocie wymaga ręcznej korekty, rozjazd stanów przekracza ustalony próg dziennie, czas obsługi zamówienia rośnie dwukrotnie albo pojawia się choć jedna sprzedaż towaru, którego fizycznie nie ma. Przekroczenie progu oznacza powrót kanału do starego systemu i analizę przyczyny, a nie „damy radę, przecież już prawie działa".

Powrót jest wykonalny tylko wtedy, gdy stary system pozostaje aktywny i skonfigurowany, integracji w nim nie kasujesz (najwyżej wyłączasz), a umowy nie wypowiadasz przed przepięciem ostatniego kanału. Wygląda to na oczywiste, dopóki nie zobaczysz faktury za dwa systemy naraz.

Pułapki, które kosztują najwięcej

Sezon. Nie migruj w czwartym kwartale. Okres od Black Friday do Trzech Króli to najgorszy możliwy moment: największe wolumeny, najmniej rąk do pracy i wsparcie obu platform obciążone bardziej niż zwykle. Dobre okna to zwykle luty i marzec albo późna wiosna. Jeśli podwyżka cennika wypada w listopadzie, taniej wyjdzie zapłacić za dwa miesiące więcej, niż migrować w szczycie.

Okno przepięcia i oversell. Synchronizacja stanów działa w cyklach, a nie natychmiast. Nawet kilkuminutowa przerwa między wyłączeniem jednego systemu a włączeniem drugiego to okno, w którym kanał sprzedaje z zamrożonych stanów. Przepinaj poza godzinami szczytu i zwiększ na ten czas bufor na najszybciej rotujących produktach.

Poczta transakcyjna. Powiadomienia do klientów to osobny system od zamówień. Typowe wpadki: klient dostaje dwa maile o tym samym statusie z dwóch systemów, wiadomości z nowego systemu lądują w spamie, bo nikt nie ustawił uwierzytelnienia domeny nadawcy, albo szablon wraca do wersji domyślnej i mail jest podpisany nazwą platformy zamiast nazwą sklepu. Wyślij testy na kilka różnych skrzynek.

Klucze podpięte pod prywatne konta. Integracje kurierskie i marketplace bywają założone na koncie pracownika. Migracja to moment, żeby to uporządkować, bo przy przepinaniu i tak wszystko wychodzi na wierzch.

Odtwarzanie bałaganu jeden do jednego. Przeniesienie dwudziestu statusów i czterdziestu akcji bez pytania, po co one są, daje ten sam bałagan w nowym systemie, tylko po dwóch miesiącach pracy. Przy okazji sprawdź, czego nie warto automatyzować w ogóle.

FAQ

Czy da się zmigrować z BaseLinkera do Sellasist bez przestoju w sprzedaży?

Tak, pod warunkiem że nie robisz tego przełącznikiem. Nowe konto konfigurujesz obok starego, przepinasz najpierw jeden mały kanał i przez pewien czas obsługujesz sprzedaż w dwóch systemach naraz. Przestój nie bierze się ze zmiany narzędzia, tylko z sytuacji, w której nowy system nie jest gotowy, a stary został już wyłączony. Realne ryzyko to zresztą nie przestój, lecz oversell w oknie przepinania stanów.

Czy historia zamówień przenosi się z BaseLinkera do Sellasist?

W komplecie nie. Przenieść da się dane podstawowe, czyli zamówienia, pozycje i dane kupujących, ale pełny kontekst (korespondencja z klientem, ślad zmian statusów, dokumenty) zostaje w starym systemie. Standardowe rozwiązanie to eksport historii do plików i utrzymanie starego konta w najniższym pakiecie do zamknięcia okresu reklamacyjnego. Eksport zrób przed obniżeniem planu, bo okres przechowywania danych bywa różny w różnych pakietach.

Co się dzieje z umowami kurierskimi przy zmianie systemu?

Nic, bo umowę masz z przewoźnikiem, a nie z platformą do obsługi zamówień. Przenosisz konfigurację: numery kont nadawczych, klucze API, dane nadawcy, gabaryty i obsługę pobrania. Uwagi wymagają pule numerów listów przewozowych przydzielane per integracja oraz protokoły nadania w okresie, gdy nadajesz z dwóch systemów naraz.

Kiedy najlepiej zaplanować migrację systemu do obsługi zamówień?

Poza szczytem sezonu, czyli w e-commerce zwykle w pierwszym kwartale albo późną wiosną. Czwarty kwartał odpada: przy największych wolumenach każdy błąd konfiguracji mnoży się przez liczbę zamówień, a zespół nie ma czasu na pracę w dwóch panelach. Jeśli powodem migracji jest podwyżka cennika, taniej wychodzi zapłacić wyższą stawkę przez dwa miesiące, niż migrować w listopadzie.

Jak uniknąć oversellu podczas przepinania kanałów?

Trzymaj zasadę, że stany na danym kanale aktualizuje w danym momencie dokładnie jeden system. Przed przepięciem wyłącz synchronizację tego jednego kanału w starym systemie, a nie wszystkich naraz. Przepinaj poza godzinami szczytu, zweryfikuj stany fizycznie na produktach o największej rotacji i zwiększ na ten czas bufor na najszybciej schodzących pozycjach.

Podsumowanie

Migracja z BaseLinkera do Sellasist jest wykonalna bez zatrzymywania sprzedaży, ale nie jest operacją weekendową. Najwięcej pracy leży poza samym przenoszeniem danych: w spisaniu tego, co stary system robi dzisiaj naprawdę, i w odtworzeniu automatyzacji, o których nikt nie pamiętał. Katalog produktów przenosi się w jeden dzień, proces potrafi zająć wielokrotnie więcej.

Za większość ryzyka odpowiadają trzy decyzje: termin (nie w szczycie sezonu), kolejność (najmniejszy kanał pierwszy, największy ostatni) i dyscyplina wokół stanów magazynowych. Ta ostatnia jest najtańsza do utrzymania i najdroższa do zignorowania, bo jeden kanał aktualizowany przez dwa systemy naraz kosztuje więcej niż cała reszta przeprowadzki.

Chcesz przejść przez inwentaryzację i sprawdzić, ile z Twojej obecnej konfiguracji Sellasist obsłuży natywnie, a co trzeba będzie dobudować? Umów bezpłatną konsultację — powiemy wprost, jeśli po spisaniu listy wyjdzie, że migracja Ci się nie opłaca i lepiej zostać tam, gdzie jesteś.

Przeczytaj również

• Sellasist czy BaseLinker: porównanie dla sprzedawców Allegro
• BaseLinker drożeje: alternatywy dla polskiego e-commerce
• Baselinker czy n8n? Automatyzacja polskiego e-commerce
• Przejęcie automatyzacji po freelancerze albo innej firmie: instrukcja
• Automatyzacja w e-commerce: 10 procesów do zautomatyzowania