Jak przenieść historię zamówień do nowego systemu

Najczęstszy powód, dla którego sprzedawcy zostają w systemie, którego nie lubią, nie brzmi „jest dobry". Brzmi „mam tam trzy lata historii". To realna obawa i warto ją rozłożyć na części, bo w praktyce dotyczy mniejszej ilości danych, niż się wydaje.

Najpierw: po co Ci ta historia

Zanim zaplanujesz migrację, odpowiedz na jedno pytanie — do czego faktycznie używasz starych zamówień? W praktyce są trzy powody i każdy ma inne wymagania:

• Obsługa klienta i zwroty. Interesują Cię zamówienia z ostatnich kilku–kilkunastu miesięcy, bo tyle trwa rękojmia i tyle realnie wraca. Potrzebujesz treści zamówienia i danych kontaktowych.
• Księgowość i kontrola. Tu liczą się faktury, a te i tak masz w programie księgowym i w KSeF — nie w systemie do obsługi zamówień. To najczęściej nieporozumienie: historia, o którą się martwisz, w dużej części nie mieszka tam, gdzie myślisz.
• Analiza sprzedaży. Potrzebujesz sum i trendów, a nie każdego wiersza. Wyeksportowany plik z ostatnich lat wystarcza, żeby porównać sezony.

Rozdzielenie tych trzech rzeczy zwykle zmniejsza „muszę przenieść wszystko" do „muszę mieć pod ręką ostatnie kilkanaście miesięcy i jeden plik z resztą".

Co przenosi się dobrze

Katalog produktów

SKU, nazwy, opisy, ceny, parametry, zdjęcia. To przenosi się najlepiej ze wszystkiego, bo jest ustrukturyzowane i aktualne.

Powiązania istniejących ofert

Oferty już wystawione na marketplace nie muszą być wystawiane od nowa: nowy system może się do nich podpiąć po identyfikatorze oferty albo po SKU.

To ważne, bo ponowne wystawianie kasuje historię oferty i jej pozycję.

Klienci i adresy

Z zastrzeżeniem, że to dane osobowe i przenosisz je na tej samej podstawie prawnej, na jakiej je zbierałeś.

Zmiana narzędzia nie jest nowym celem przetwarzania, ale porządek w tym trzeba mieć.

Zamówienia jako dane

W formie eksportu. Praktycznie każdy system pozwala wyjąć zamówienia do CSV albo XLS.

Co dokładnie mieści się w imporcie zamówień

„Eksport do CSV" brzmi ogólnie, więc warto wiedzieć, jakie pola faktycznie przenoszą się razem z zamówieniem. Import zamówień z pliku w easySales mapuje 47 kolumn w sześciu grupach — komplet danych, których potrzebujesz do obsługi posprzedażowej:

• Identyfikator zamówienia — jedna kolumna, która trafia jednocześnie do numeru marketplace i do numeru prezentowanego w Twoim panelu. Dzięki temu zamówienie sprzed migracji nadal da się odnaleźć po numerze, który zna kupujący.
• Data i status — data złożenia zamówienia i status, w jakim ma wylądować. To ważniejsze, niż wygląda: zaimportowane zamówienie sprzed pół roku nie powinno trafić do kolejki do spakowania.
• Dane kupującego — imię i nazwisko lub nazwa firmy, e-mail, telefon, NIP, numer rejestrowy oraz informacja, czy to firma czy osoba prywatna i czy kupujący jest płatnikiem VAT.
• Adres — ulica, miasto, kod pocztowy, kraj i województwo.
• Pozycje zamówienia — SKU, ilość, cena netto, cena brutto, stawka VAT i wartość pozycji.
• Płatność i waluta — sposób płatności i waluta, a w razie potrzeby także seria faktury oraz dane rachunku bankowego.

Dwie rzeczy warto z tej listy wyciągnąć. Po pierwsze: pozycje zamówienia dopasowują się po SKU, więc katalog musi być w systemie wcześniej niż zamówienia.

Wiersz, dla którego nie ma pasującego SKU, i tak się zaimportuje — z nazwą, ilością i ceną — ale nie zostanie powiązany z produktem z katalogu. Zamówienie wygląda wtedy poprawnie i nie da się po nim niczego policzyć.

Po drugie: nie ma tu pól na historię zmian statusu ani na wątki wiadomości z kupującym.

Przenosisz stan końcowy zamówienia, a nie jego przebieg — i w praktyce to wystarcza do wszystkiego, po co naprawdę sięgasz do starego zamówienia.

Podpięcie ofert zamiast wystawiania od nowa

To fragment migracji, w którym najłatwiej zrobić sobie krzywdę, więc zasługuje na osobne miejsce. Oferta, która wisi na Allegro od dwóch lat, ma historię sprzedaży, opinie i pozycję w wynikach.

Wystawienie jej od nowa kasuje to wszystko — dostajesz nowy identyfikator oferty i zaczynasz od zera, mimo że produkt jest dokładnie ten sam.

Dlatego poprawna kolejność wygląda tak: najpierw wgrywasz katalog, potem podpinasz istniejące oferty do produktów, i dopiero wtedy pozwalasz systemowi cokolwiek wysyłać na kanał.

Podpięcie działa po identyfikatorze oferty albo po SKU i sprowadza się do tego, że system uczy się, który produkt w Twoim katalogu odpowiada której ofercie na marketplace.

Trzy sytuacje, w których podpięcie się potyka

Dopasowanie działa automatycznie tylko wtedy, gdy katalog i oferty mówią tym samym językiem. Trzy przypadki, w których tak nie jest:

• SKU różni się między kanałami. Ten sam produkt bywa wystawiony jako „ABC-123" na jednym kanale i „abc123" na drugim, bo tak wyszło przy pierwszym wystawianiu. Dopasowanie po SKU wtedy nie zadziała i trzeba je poprawić — najlepiej przed migracją, bo to i tak porządek, który przyda się później.
• Warianty. Oferta wielowariantowa musi znaleźć w katalogu wszystkie swoje warianty. Jeśli w starym systemie warianty były sklejone w jeden produkt, ich rozdzielenie to osobne zadanie i lepiej zaplanować na nie czas.
• Oferty archiwalne. Zakończone i wycofane oferty nie muszą się podpinać. Warto je odfiltrować, żeby nie zaniżały wyniku dopasowania i nie robiły niepotrzebnego szumu w raporcie.

Praktyczna zasada: zanim przełączysz wysyłanie stanów i cen, przejrzyj raport dopasowania i policz, ile ofert zostało bez pary. Każda niedopasowana oferta to albo produkt, którego nie ma w katalogu, albo SKU do poprawienia.

Jedno i drugie lepiej znaleźć teraz niż w dniu, w którym system zacznie wysyłać stany.

Czego nie da się przenieść i lepiej to wiedzieć wcześniej

Automatyzacje

Reguły, przepływy, szablony wiadomości i warunki — to jest logika zapisana w modelu konkretnego narzędzia i nie ma formatu wymiany.

Trzeba je odtworzyć. Dobra wiadomość: to zwykle kilka godzin, a nie kilka dni, i jest to najlepszy moment, żeby wyrzucić reguły, które powstały jako obejście czegoś, czego już nie ma.

Historia komunikacji z marketplace

Wątki wiadomości z kupującymi zostają na platformie — i tam nadal będą dostępne, niezależnie od tego, jakiego systemu używasz.

Numeracja wewnętrzna

Nowy system nada własne identyfikatory. Numeracja faktur to osobna sprawa i ta akurat musi zachować ciągłość — pilnuj jej w programie księgowym, nie w systemie do zamówień.

Największe ryzyko przy przełączaniu: dwa systemy i jeden stan magazynowy

Jeśli z całego tekstu masz zapamiętać jedną rzecz, to tę. W okresie przejściowym masz dwa systemy podpięte do tych samych kanałów, a stan magazynowy jest jeden — fizyczny, na półce.

Jeżeli oba systemy mają włączone wysyłanie stanów, zaczynają się nadpisywać nawzajem.

Wygląda to tak: stary system wysyła „mam 10 sztuk", nowy chwilę później wysyła „mam 8", potem stary znowu „10".

Oferta miga między dwiema wartościami, a Ty dowiadujesz się o tym dopiero wtedy, gdy sprzedasz coś, czego nie masz.

W drugą stronę bywa gorzej — system, który nie zna jeszcze Twojego magazynu, wysyła zera i wygasza oferty w środku dnia.

Bezpieczna kolejność przełączenia

Zasada jest prosta i nie ma od niej wyjątku: w danym momencie dokładnie jeden system wysyła stany na dany kanał. W praktyce oznacza to taką kolejność:

1. Nowy system podpinasz w trybie, w którym tylko pobiera zamówienia i nie wysyła ani stanów, ani cen.
2. Sprawdzasz, że stany w nowym systemie zgadzają się z rzeczywistością — z magazynem, a nie z tym, co pokazuje stary system.
3. Wyłączasz wysyłanie stanów w starym systemie.
4. Dopiero teraz włączasz je w nowym.

Między krokiem trzecim a czwartym przez kilka minut nikt nie aktualizuje stanów i to jest zupełnie w porządku. Znacznie gorsze są dwie godziny, w których robią to obaj naraz.

To samo dotyczy cen, jeśli korzystasz z automatycznej zmiany cen, oraz odsyłania statusów wysyłki. Jeden nadawca na kanał, zawsze.

Jak przenieść historię zamówień — plan, który działa

1. Wyeksportuj zamówienia do pliku, zanim cokolwiek zmienisz. Nawet jeśli nigdy go nie zaimportujesz, to jest Twoja kopia bezpieczeństwa i koszt jest zerowy. Zrób to dziś, niezależnie od decyzji.
2. Przenieś katalog i podepnij oferty w nowym systemie, ale nie przełączaj jeszcze obsługi.
3. Odtwórz automatyzacje — zacznij od tych, które dotykają wysyłki i faktur, bo to one oszczędzają najwięcej czasu.
4. Przez jeden tydzień prowadź oba równolegle. Nowe zamówienia obsługujesz w nowym systemie, stare dokańczasz w starym. To najprostszy sposób, żeby nie mieć jednego dnia przełomu, w którym wszystko musi zadziałać naraz.
5. Wyłącz stary system dopiero, gdy ostatnie zamówienie z niego jest zamknięte. Zwroty z ostatniego tygodnia to jedyny powód, dla którego naprawdę potrzebujesz obu.

Jedno pytanie wraca przy każdej migracji: co zrobić z zamówieniami, które są w połowie realizacji w dniu przełączenia.

Odpowiedź jest prostsza, niż się wydaje — zostaw je tam, gdzie powstały.

Zamówienie przenoszone między systemami w trakcie kompletacji to najprostszy sposób na pomyłkę w wysyłce. Nikt na tym nie oszczędza czasu, a ryzyko jest realne.

Dlatego przełączenie robi się na nowych zamówieniach, a nie na wszystkich naraz. Stare dokańczasz w starym systemie i dopiero potem go wyłączasz.

Tydzień równoległej pracy, dzień po dniu

„Prowadź oba systemy równolegle" to dobra rada, która nie mówi nic o tym, co konkretnie robić w środę.

Poniżej rozkład, który sprawdza się u sprzedawcy z dwoma–trzema kanałami. Jeśli masz ich więcej, rozciągnij go w czasie, ale nie zmieniaj kolejności.

Poniedziałek — katalog i podpięcie. Wgrywasz produkty, podpinasz oferty, przeglądasz raport dopasowania. Nowy system nie wysyła jeszcze niczego. Stary pracuje normalnie.

Wtorek — pobieranie zamówień. Włączasz pobieranie zamówień w nowym systemie.

Przez jeden dzień te same zamówienia są w obu systemach i to jest celowe: porównujesz, czy wszystko się zgadza — liczba zamówień, kwoty, dane kupujących, koszty wysyłki.

Środa — stany. Sprawdzasz stany w nowym systemie względem magazynu, wyłączasz wysyłanie stanów w starym, włączasz w nowym. Od tego momentu to nowy system odpowiada za dostępność ofert.

Czwartek — wysyłka i dokumenty. Pierwsze zamówienia obsługujesz do końca w nowym systemie: etykieta, status, faktura. Rób to na prawdziwych zamówieniach, nie na testowych — testowe zawsze wyglądają lepiej niż rzeczywistość.

Piątek — automatyzacje. Włączasz odtworzone reguły, po jednej, i patrzysz na pierwsze uruchomienie każdej z nich.

Reguła, która ma się odpalać raz dziennie, potrzebuje doby, żeby pokazać, że działa — dlatego włącza się je pod koniec tygodnia, a nie na początku.

Kolejny tydzień — dokańczanie. Do starego systemu trafiają już tylko zwroty i reklamacje do zamówień, które w nim powstały. Nic nowego tam nie wpada.

Wyłączenie. Kiedy ostatnie zamówienie ze starego systemu jest zamknięte i minął Twój zwykły okres zwrotów, możesz go wyłączyć. Wcześniej zrób ostatni eksport — ten sam, który zrobiłeś na początku, tylko kompletny.

Warto też ustalić z góry, kto w tym tygodniu odpowiada za co.

Przy dwóch działających systemach najczęstszym problemem nie jest technika, tylko dwie osoby obsługujące to samo zamówienie w dwóch miejscach — albo żadna, bo każda założyła, że robi to druga.

Co sprawdzić po przełączeniu

Poniższa lista zajmuje pół godziny i wyłapuje rzeczy, które łatwo przeoczyć, bo nic nie krzyczy, kiedy są ustawione źle.

Ten przegląd jest jedyną rzeczą, która oddziela „przenieśliśmy się" od „przenieśliśmy się i wszystko działa".

Ile to trwa naprawdę

Dla sprzedawcy z jednym–dwoma kanałami i uporządkowanym katalogiem: kilka dni, z czego większość to czekanie na synchronizację, a nie praca.

Dla sprzedawcy z wieloma kontami, własnym sklepem i rozbudowanymi regułami: tydzień do dwóch, i tu warto poprosić o pomoc przy odtwarzaniu automatyzacji.

Najdłużej trwa zwykle nie migracja, tylko decyzja. A koszt czekania jest realny — płacisz go co miesiąc.

Jeśli chcesz zobaczyć, jak wygląda podpięcie kanałów, zacznij tutaj: integracje easySales. Migrację przeprowadzamy razem z Tobą i nie pobieramy za nią opłaty.