Co to jest BaseLinker i jak pomaga zarządzać sprzedażą internetową?

Firma sprzedaje produkty we własnym sklepie internetowym, na kilku platformach marketplace i przez zamówienia obsługiwane ręcznie. Każdy kanał posiada osobny panel, własne statusy, wiadomości, numery zamówień i sposób aktualizowania stanów magazynowych.

Pracownik otwiera kolejne zakładki, sprawdza nowe zamówienia, kopiuje dane klientów, tworzy przesyłki, drukuje dokumenty i ręcznie zmienia statusy.

Jeżeli produkt sprzeda się jednocześnie w dwóch miejscach, istnieje ryzyko, że oba kanały pokażą stan, którego magazyn nie jest już w stanie zrealizować.

BaseLinker pomaga połączyć takie procesy w jednym środowisku.

System może pobierać zamówienia z różnych źródeł, porządkować je według wspólnego procesu, aktualizować produkty, przekazywać dane do kurierów i uruchamiać automatyczne działania.

Nie oznacza to jednak, że po podłączeniu integracji cały handel automatycznie zacznie działać poprawnie.

Każdy sklep może inaczej rozpoznawać produkty. Jedna platforma wykorzystuje SKU, druga własny identyfikator oferty, a system magazynowy kod towaru. Status „wysłane” w jednym kanale może oznaczać coś innego niż status „zrealizowane” w drugim.

Jeżeli przed uruchomieniem synchronizacji nie zostanie ustalone źródło cen, stanów i danych produktowych, systemy mogą zacząć nadpisywać się wzajemnie.

W swojej pracy spotykam integracje, w których BaseLinker został podłączony do kilku kanałów bez wcześniejszego uporządkowania katalogu. Ten sam produkt posiada różne SKU, warianty nie są ze sobą połączone, a aktualizacja stanu jednego towaru wpływa na kilka przypadkowych ofert.

Spotykam też rozbudowane automatyzacje, które wykonują działania zgodnie z konfiguracją, ale niezgodnie z rzeczywistym procesem firmy. Zamówienie otrzymuje status wysłanego przed utworzeniem przesyłki albo klient dostaje wiadomość o realizacji mimo nieudanej płatności.

BaseLinker może być centrum obsługi sprzedaży wielokanałowej, ale wymaga prawidłowego projektu danych, statusów, magazynów i automatyzacji.

Co to jest BaseLinker?

BaseLinker jest systemem służącym do integracji i zarządzania sprzedażą internetową prowadzoną w wielu kanałach.

Może łączyć między innymi:

• sklepy internetowe,
• platformy marketplace,
• systemy magazynowe,
• firmy kurierskie,
• operatorów płatności,
• programy księgowe,
• hurtownie,
• systemy ERP,
• narzędzia do obsługi klienta,
• własne aplikacje firmy.

BaseLinker może pełnić rolę warstwy pośredniej pomiędzy tymi systemami.

Zamiast tworzyć osobne połączenie pomiędzy każdym sklepem, marketplace’em, kurierem i systemem ERP, firma może przesyłać dane przez jedno centralne środowisko.

Do czego służy BaseLinker?

System może wspierać między innymi:

• pobieranie zamówień z różnych kanałów,
• zarządzanie wspólnym procesem realizacji,
• synchronizowanie stanów magazynowych,
• aktualizowanie cen,
• tworzenie i aktualizowanie ofert,
• drukowanie dokumentów,
• tworzenie przesyłek,
• przekazywanie numerów nadania,
• wysyłanie wiadomości do klientów,
• automatyczne zmienianie statusów,
• przesyłanie danych do systemów zewnętrznych,
• raportowanie i kontrolowanie procesu sprzedaży.

Zakres możliwości zależy od używanych integracji, kanałów sprzedaży i sposobu konfiguracji konta.

Czy BaseLinker jest sklepem internetowym?

BaseLinker nie zastępuje strony sklepu, na której klient ogląda produkty, dodaje je do koszyka i składa zamówienie.

Sklep internetowy nadal odpowiada za:

• prezentację oferty,
• koszyk,
• checkout,
• płatności,
• konto klienta,
• treści,
• SEO,
• doświadczenie użytkownika.

BaseLinker może pobierać dane ze sklepu i wspierać dalszą obsługę zamówienia.

Nie naprawi jednak źle działającego checkoutu, błędnej ceny na stronie ani nieczytelnej karty produktu.

Czy BaseLinker jest systemem ERP?

BaseLinker może obsługiwać katalogi, magazyny, zamówienia i część procesów operacyjnych, ale nie zawsze zastępuje pełny system ERP.

ERP może odpowiadać za:

• księgowość,
• zakupy,
• produkcję,
• rezerwacje magazynowe,
• dokumenty handlowe,
• rozrachunki,
• wiele oddziałów,
• zaawansowaną gospodarkę magazynową.

W zależności od firmy BaseLinker może być:

• głównym centrum obsługi zamówień,
• warstwą integracyjną pomiędzy ERP i kanałami sprzedaży,
• narzędziem do wystawiania ofert,
• systemem automatyzującym wysyłki,
• dodatkiem do istniejącej infrastruktury.

Przed wdrożeniem trzeba ustalić, które zadania pozostają w ERP, a które przejmuje BaseLinker.

BaseLinker a sprzedaż wielokanałowa

Sprzedaż wielokanałowa oznacza oferowanie produktów w więcej niż jednym miejscu.

Firma może sprzedawać:

• we własnym WooCommerce,
• na platformach marketplace,
• w sklepie stacjonarnym,
• przez telefon,
• w sprzedaży B2B,
• na kilku rynkach zagranicznych.

Każdy kanał może posiadać inne:

• ceny,
• prowizje,
• opisy,
• kategorie,
• zasady dostawy,
• statusy,
• terminy wysyłki,
• wymagania dotyczące produktów.

BaseLinker może pomóc zarządzać wspólną warstwą operacyjną, ale nie usuwa różnic pomiędzy kanałami.

Czym jest centralizacja zamówień?

Centralizacja polega na pobieraniu zamówień z różnych źródeł do jednego panelu.

Pracownik może przetwarzać w podobny sposób zamówienia pochodzące z:

• WooCommerce,
• marketplace’u,
• formularza B2B,
• sprzedaży telefonicznej,
• innego sklepu.

Wspólny proces może obejmować:

1. pobranie zamówienia,
2. sprawdzenie płatności,
3. rezerwację produktów,
4. przygotowanie przesyłki,
5. wydruk dokumentów,
6. przekazanie numeru śledzenia,
7. zmianę statusu w kanale źródłowym,
8. wysłanie wiadomości do klienta.

Centralizacja nie oznacza, że wszystkie zamówienia muszą być identyczne. Proces może być różny zależnie od kanału, kraju, metody dostawy albo rodzaju produktu.

Czym są statusy zamówień w BaseLinkerze?

Status opisuje aktualny etap obsługi zamówienia.

Firma może posiadać statusy takie jak:

• nowe,
• oczekujące na płatność,
• opłacone,
• do przygotowania,
• pakowane,
• gotowe do wysyłki,
• wysłane,
• anulowane,
• zwrócone,
• wymaga kontaktu.

Statusy mogą uruchamiać dalsze działania, dlatego nie powinny być traktowane wyłącznie jako kolorowe etykiety.

Zmiana statusu może spowodować:

• utworzenie przesyłki,
• wysłanie wiadomości,
• wydruk dokumentu,
• zmianę statusu w sklepie,
• przekazanie danych do ERP,
• oznaczenie zamówienia jako zrealizowanego.

Mapowanie statusów

Każdy kanał może posiadać własne statusy.

WooCommerce może używać statusów:

• oczekujące na płatność,
• w trakcie realizacji,
• wstrzymane,
• zrealizowane,
• anulowane,
• zwrócone.

Marketplace może używać innych nazw i etapów.

BaseLinker może posiadać jeszcze bardziej szczegółowy proces wewnętrzny.

Mapowanie powinno określać:

• jaki status otrzymuje nowe zamówienie,
• kiedy jest uznawane za opłacone,
• kiedy kanał źródłowy otrzymuje informację o wysyłce,
• który status oznacza zakończenie procesu,
• jak obsługiwane są anulowania i zwroty.

Błędne mapowanie może wysłać klientowi nieprawidłową informację albo zablokować dalszą zmianę zamówienia.

Czy status „zrealizowane” oznacza wysłanie?

Nie zawsze.

W jednej firmie status zrealizowane może oznaczać, że przesyłka została utworzona. W innej, że paczka została przekazana kurierowi. Jeszcze w innej, że zamówienie zostało zakończone księgowo.

Każdy status powinien mieć jasno opisaną definicję.

Pracownik i automatyzacja muszą rozumieć go w ten sam sposób.

Czym jest magazyn produktów?

Magazyn w BaseLinkerze jest katalogiem zawierającym produkty i ich dane.

Może przechowywać między innymi:

• nazwy,
• SKU,
• EAN,
• ceny,
• stany,
• opisy,
• zdjęcia,
• warianty,
• parametry,
• powiązania z ofertami.

Firma może posiadać jeden albo kilka magazynów zależnie od struktury sprzedaży.

Magazyn BaseLinkera nie musi oznaczać fizycznego budynku. Może być logicznym źródłem danych używanym do synchronizacji kanałów.

Który system powinien być źródłem produktów?

Przed uruchomieniem synchronizacji trzeba ustalić system nadrzędny dla danych produktowych.

Źródłem może być:

• ERP,
• WooCommerce,
• magazyn BaseLinkera,
• PIM,
• system hurtowni,
• dedykowana baza produktów.

Nie każdy rodzaj danych musi pochodzić z tego samego miejsca.

Przykładowo:

• ERP może dostarczać ceny i stany,
• WooCommerce opisy marketingowe,
• PIM zdjęcia i parametry,
• BaseLinker powiązania ofert.

Taki podział musi być jednak dokładnie opisany.

Źródło prawdy dla stanów magazynowych

Stan produktu powinien mieć jedno nadrzędne źródło.

Może nim być:

• ERP,
• program magazynowy,
• BaseLinker,
• WooCommerce.

Jeżeli kilka systemów równocześnie aktualizuje stan, mogą powstać konflikty.

Przykładowo:

1. ERP przekazuje stan 10.
2. Sklep sprzedaje jedną sztukę i zmienia stan na 9.
3. BaseLinker ponownie pobiera starą wartość 10 z innego źródła.
4. Produkt zostaje sprzedany ponownie mimo braku towaru.

Trzeba ustalić, czy sprzedaż w kanałach zmniejsza wspólny stan natychmiast, czy dopiero po potwierdzeniu zamówienia w systemie magazynowym.

Rezerwacja a rzeczywisty stan

Stan fizyczny i stan dostępny do sprzedaży nie zawsze są identyczne.

Produkt może posiadać:

• stan fizyczny,
• rezerwacje dla zamówień,
• towar uszkodzony,
• towar przeznaczony dla innego kanału,
• zapas bezpieczeństwa.

Do sprzedaży może być dostępna tylko część całkowitego stanu.

Integracja powinna wiedzieć, którą wartość przekazywać do kanałów.

Zapas bezpieczeństwa

Zapas bezpieczeństwa pozwala ograniczyć ryzyko sprzedaży ostatnich sztuk w kilku kanałach równocześnie.

Jeżeli magazyn posiada 10 sztuk, system może udostępniać do sprzedaży tylko 8.

Dwie sztuki pozostają buforem na:

• opóźnienie synchronizacji,
• uszkodzenie,
• błąd magazynu,
• sprzedaż stacjonarną,
• równoległe zamówienia.

Bufor powinien wynikać z rzeczywistego ryzyka, a nie być przypadkową liczbą ustawioną dla całego katalogu.

Synchronizacja stanów

Synchronizacja może działać:

• cyklicznie,
• po wystąpieniu zdarzenia,
• na podstawie webhooka,
• przez API,
• za pomocą pliku,
• ręcznie.

Im szybciej zmienia się sprzedaż, tym większe znaczenie ma częstotliwość aktualizacji.

Sklep sprzedający pojedyncze unikalne przedmioty potrzebuje innej kontroli niż firma posiadająca tysiące sztuk każdego produktu.

Synchronizacja cen

Ceny mogą być przekazywane pomiędzy magazynem, sklepami i marketplace’ami.

Trzeba ustalić:

• gdzie tworzona jest cena bazowa,
• czy ceny są brutto czy netto,
• jaka waluta obowiązuje,
• czy kanały posiadają własne marże,
• jak przeliczane są prowizje,
• jak obsługiwane są promocje,
• jak działa zaokrąglanie.

Ta sama cena nie zawsze powinna obowiązywać w każdym kanale.

Marketplace może pobierać wyższą prowizję, posiadać inne koszty dostawy albo wymagać określonej polityki cenowej.

Reguły cenowe

Reguła może obliczać cenę na podstawie wartości źródłowej.

Może uwzględniać:

• procentową marżę,
• stałą kwotę,
• kurs waluty,
• minimalną cenę,
• zaokrąglenie,
• kategorię,
• markę,
• konkretny kanał.

Przykładowa cena marketplace’u może być wyższa od ceny sklepu o koszt prowizji.

Reguła musi jednak uwzględniać podatki, promocje i minimalną rentowność.

Cena źródłowa a cena oferty

Produkt może posiadać cenę w magazynie i osobną cenę aktywnej oferty.

Zmiana ceny magazynowej nie zawsze automatycznie oznacza zmianę wszystkich ofert.

Trzeba sprawdzić:

• czy synchronizacja cen jest włączona,
• które grupy cenowe są używane,
• czy oferta posiada własną regułę,
• czy cena nie została zablokowana ręcznie,
• czy kanał przyjął aktualizację.

Czym jest oferta?

Oferta jest konkretną prezentacją produktu w kanale sprzedaży.

Ten sam produkt magazynowy może posiadać kilka ofert:

• w sklepie internetowym,
• na jednym marketplace,
• na drugim marketplace,
• w innym kraju,
• w wersji promocyjnej.

Oferta może posiadać własne:

• ID,
• tytuł,
• opis,
• cenę,
• kategorię,
• parametry,
• warunki dostawy,
• status publikacji.

Nie należy utożsamiać ID oferty z ID produktu magazynowego.

Powiązanie oferty z produktem

Oferta powinna być połączona z właściwym produktem lub wariantem w magazynie.

Powiązanie umożliwia:

• aktualizowanie stanu,
• synchronizowanie ceny,
• rozpoznawanie produktu w zamówieniu,
• tworzenie wspólnych raportów,
• kontrolę sprzedaży.

Błędne powiązanie może sprawić, że sprzedaż jednego produktu zmniejszy stan innego.

SKU jako identyfikator

SKU jest jednym z najważniejszych identyfikatorów w integracji sprzedaży.

Powinno być:

• unikalne,
• stabilne,
• przypisane do właściwego produktu,
• zgodne pomiędzy systemami.

Produkt główny i jego warianty mogą wymagać oddzielnych SKU.

Nie należy używać tego samego kodu dla kilku różnych towarów tylko dlatego, że mają podobną nazwę.

Co się dzieje, gdy SKU są nieprawidłowe?

Problemy mogą obejmować:

• łączenie kilku produktów w jeden,
• brak aktualizacji stanów,
• dodawanie nieznanych pozycji do zamówień,
• duplikowanie produktów,
• błędne raporty,
• nieprawidłową synchronizację z ERP.

Przed połączeniem katalogów wykonuję kontrolę:

• brakujących SKU,
• duplikatów,
• różnic w zapisie,
• spacji i znaków specjalnych,
• kodów wariantów.

Identyfikatory produktów

Jeden produkt może posiadać wiele identyfikatorów:

• ID WooCommerce,
• SKU,
• EAN,
• ID magazynu BaseLinkera,
• ID oferty marketplace,
• ID produktu ERP,
• ID wariantu.

Każdy identyfikator pełni inną funkcję.

Integracja powinna przechowywać powiązania zamiast zakładać, że wszystkie systemy używają tej samej wartości.

Produkty wariantowe

Produkt wariantowy może występować w kilku rozmiarach, kolorach albo konfiguracjach.

Każdy wariant może posiadać własne:

• SKU,
• EAN,
• cenę,
• stan,
• zdjęcie,
• ID oferty.

Wariant powinien być połączony z odpowiadającą mu pozycją w każdym systemie.

Nie wystarczy powiązać tylko produktu głównego, jeżeli stany są prowadzone oddzielnie dla rozmiarów lub kolorów.

Najczęstsze błędy wariantów

Problemy występują, gdy:

• wszystkie warianty mają to samo SKU,
• oferta nie rozróżnia wariantów,
• kolejność atrybutów jest inna w systemach,
• jeden kolor ma kilka różnych nazw,
• produkt główny otrzymuje stan będący sumą wariantów,
• EAN jednego wariantu jest kopiowany do pozostałych.

Przed synchronizacją warto przygotować słowniki cech, na przykład:

• czarny odpowiada black,
• XL odpowiada x-large,
• 100 ml odpowiada 0,1 l.

Zestawy i komplety

Zestaw może składać się z kilku produktów magazynowych.

Przykładowo zestaw prezentowy zawiera:

• produkt główny,
• akcesorium,
• opakowanie.

Dostępność zestawu zależy od stanu wszystkich składników.

Sprzedaż jednego zestawu powinna odpowiednio zmniejszyć stany jego elementów.

Integracja musi rozumieć:

• skład zestawu,
• ilość każdego elementu,
• sposób wyceny,
• zachowanie podczas zwrotu,
• powiązanie z ERP.

Produkty bez powiązania

Zamówienie może zawierać produkt, którego BaseLinker nie potrafi połączyć z magazynem.

Przyczyną może być:

• brak SKU,
• zmienione ID oferty,
• ręcznie utworzona oferta,
• usunięty produkt,
• błędny wariant,
• nieaktualne powiązanie.

Takie zamówienie nie powinno zostać niezauważone.

Może trafić do statusu wymagającego kontroli, aby pracownik ręcznie wskazał odpowiedni towar.

Import produktów

Produkty mogą być pobierane z istniejącego sklepu, magazynu albo innego kanału.

Przed importem trzeba zdecydować:

• które dane zostaną pobrane,
• czy warianty zostaną zachowane,
• jak będą tworzone SKU,
• czy zdjęcia zostaną skopiowane,
• jak zostaną odwzorowane kategorie,
• co zrobić z produktami już istniejącymi.

Import bez reguł może stworzyć duplikaty całego katalogu.

Eksport produktów

BaseLinker może przekazywać produkty do kanałów sprzedaży albo systemów zewnętrznych.

Eksport może obejmować:

• nowe oferty,
• ceny,
• stany,
• opisy,
• zdjęcia,
• parametry,
• kategorie.

Każdy kanał może wymagać innego mapowania.

Jedna kategoria sklepu nie zawsze odpowiada jednej kategorii marketplace’u.

Mapowanie kategorii

Produkty muszą zostać przypisane do odpowiednich kategorii kanału docelowego.

Mapowanie może działać na podstawie:

• kategorii sklepu,
• typu produktu,
• marki,
• atrybutów,
• ręcznie utworzonych reguł.

Kategorie o tej samej nazwie mogą mieć inne znaczenie w różnych systemach.

Przykładowa kategoria „Akcesoria” jest zbyt ogólna, aby automatycznie przypisać ją do właściwego działu marketplace’u.

Parametry ofert

Marketplace może wymagać dodatkowych informacji, takich jak:

• marka,
• model,
• kolor,
• materiał,
• rozmiar,
• GTIN,
• dane producenta,
• informacje bezpieczeństwa.

Parametry mogą być pobierane z:

• atrybutów WooCommerce,
• pól niestandardowych,
• magazynu BaseLinkera,
• ERP,
• szablonu oferty.

Brak parametru może uniemożliwić wystawienie oferty albo ograniczyć jej widoczność.

Szablony ofert

Szablon może określać sposób budowania oferty.

Może zawierać reguły dotyczące:

• tytułu,
• opisu,
• kategorii,
• zdjęć,
• ceny,
• dostawy,
• warunków sprzedaży,
• parametrów.

Szablon pozwala wystawiać wiele ofert według wspólnej struktury.

Nie powinien jednak tworzyć identycznych, niedopasowanych tytułów dla całego katalogu.

Obsługa zamówień

Po pobraniu zamówienia system może automatycznie:

• przypisać status,
• sprawdzić metodę płatności,
• wybrać magazyn,
• wydrukować dokument,
• utworzyć przesyłkę,
• wysłać dane do ERP,
• poinformować klienta,
• przekazać numer nadania.

Proces powinien być dopasowany do źródła zamówienia.

Zamówienie za pobraniem może wymagać innego działania niż zamówienie oczekujące na płatność online.

Płatność i status zamówienia

Zamówienie nie powinno zostać uznane za opłacone wyłącznie dlatego, że zostało pobrane do BaseLinkera.

Trzeba rozróżnić:

• zamówienie utworzone,
• płatność rozpoczętą,
• płatność oczekującą,
• płatność potwierdzoną,
• płatność nieudaną,
• płatność zwróconą.

Informacja może pochodzić ze sklepu, operatora płatności albo systemu księgowego.

Źródło powinno być wiarygodne i jednoznaczne.

Numery zamówień

Jedno zamówienie może posiadać kilka numerów:

• ID w WooCommerce,
• numer widoczny dla klienta,
• ID w BaseLinkerze,
• numer marketplace’u,
• numer dokumentu ERP,
• numer transakcji płatniczej.

Integracja powinna przechowywać te powiązania.

Nie należy zakładać, że jeden numer będzie identyczny we wszystkich systemach.

Niestandardowe numery zamówień w WooCommerce

WooCommerce może wyświetlać klientowi numer zmieniony przez dodatkową wtyczkę albo własny kod.

Techniczne ID zamówienia może być inne niż numer prezentowany w dokumentach i wiadomościach.

Jeżeli BaseLinker albo inny system potrzebuje numeru widocznego dla klienta, trzeba przekazać go w odpowiednim polu lub metadanych.

W przeciwnym razie pracownik może szukać zamówienia po numerze, którego system zewnętrzny nie zna.

Automatyzacje w BaseLinkerze

Automatyczna akcja wykonuje określone działanie po spełnieniu warunków.

Może reagować na:

• utworzenie zamówienia,
• zmianę statusu,
• potwierdzenie płatności,
• wybraną metodę dostawy,
• konkretny kanał,
• wartość zamówienia,
• kraj klienta,
• zawartość koszyka,
• upływ czasu.

Automatyzacja może:

• zmienić status,
• utworzyć przesyłkę,
• wysłać wiadomość,
• wydrukować dokument,
• wywołać zewnętrzny adres,
• ustawić pole dodatkowe,
• przekazać dane do innego systemu.

Dlaczego kolejność automatyzacji ma znaczenie?

Kilka reguł może zareagować na to samo zamówienie.

Przykładowo:

1. Zamówienie zostaje oznaczone jako opłacone.
2. Reguła tworzy przesyłkę.
3. Druga reguła zmienia status na wysłane.
4. Trzecia wysyła wiadomość klientowi.

Jeżeli przesyłka nie zostanie utworzona, kolejne działania nie powinny udawać pełnego sukcesu.

Automatyzacja powinna uwzględniać wynik poprzedniego kroku.

Warunki automatycznych akcji

Warunek określa, kiedy reguła może zadziałać.

Może sprawdzać:

• status,
• źródło zamówienia,
• metodę płatności,
• metodę dostawy,
• kraj,
• wartość,
• produkt,
• kategorię,
• pole dodatkowe,
• czas od utworzenia.

Warunki powinny być wystarczająco precyzyjne.

Reguła tworząca przesyłkę kurierską nie powinna uruchamiać się dla odbioru osobistego.

Automatyzacja a błędy

Każda automatyzacja powinna posiadać scenariusz błędu.

Trzeba ustalić:

• co zrobić, gdy kurier odrzuci dane,
• co zrobić, gdy ERP jest niedostępny,
• jak oznaczyć zamówienie bez powiązanego produktu,
• kto otrzyma powiadomienie,
• czy operacja zostanie ponowiona,
• jak uniknąć duplikatu.

Brak scenariusza błędu powoduje, że nieudane zamówienie wygląda jak prawidłowo przetworzone albo pozostaje w przypadkowym statusie.

Zapobieganie wielokrotnemu wykonaniu

Automatyzacja może zostać uruchomiona ponownie przez:

• ponowną zmianę statusu,
• powtórzony webhook,
• ręczne cofnięcie zamówienia,
• ponowienie nieudanego zadania,
• błąd integracji.

Tworzenie przesyłek, faktur i płatności powinno być zabezpieczone przed duplikacją.

System może sprawdzać, czy zamówienie posiada już:

• numer przesyłki,
• numer dokumentu,
• identyfikator operacji,
• znacznik wykonania akcji.

Wiadomości do klientów

BaseLinker może wspierać automatyczne wysyłanie wiadomości związanych z zamówieniem.

Wiadomości mogą dotyczyć:

• potwierdzenia przyjęcia,
• oczekiwania na płatność,
• przygotowania przesyłki,
• numeru śledzenia,
• opóźnienia,
• anulowania,
• prośby o dodatkowe informacje.

Treść powinna odpowiadać rzeczywistemu statusowi.

Nie należy wysyłać informacji „paczka została wysłana”, jeżeli system dopiero utworzył etykietę.

Szablony wiadomości

Szablon może wykorzystywać dane zamówienia, takie jak:

• imię klienta,
• numer zamówienia,
• lista produktów,
• kwota,
• numer przesyłki,
• link śledzenia.

Trzeba sprawdzić zachowanie, gdy dana wartość jest pusta.

Wiadomość z pustym numerem przesyłki albo nieprawidłowym linkiem obniża zaufanie klienta.

Tworzenie przesyłek

Integracje kurierskie mogą umożliwiać:

• tworzenie przesyłki,
• pobranie etykiety,
• zamówienie odbioru,
• przekazanie numeru nadania,
• wybór punktu odbioru,
• śledzenie statusu.

Dane przesyłki mogą zależeć od:

• metody dostawy,
• wagi,
• wymiarów,
• kraju,
• pobrania,
• ubezpieczenia,
• rodzaju produktu.

Nie każda przesyłka powinna być tworzona z tym samym szablonem.

Waga i wymiary produktów

Automatyczne tworzenie przesyłki wymaga wiarygodnych danych.

Jeżeli produkty nie posiadają wagi, system może:

• użyć wartości domyślnej,
• utworzyć nieprawidłową przesyłkę,
• zostać odrzucony przez kuriera,
• naliczyć dopłatę.

Zestawy, produkty wielkogabarytowe i kilka sztuk jednego produktu mogą wymagać osobnych reguł pakowania.

Punkty odbioru

Zamówienie do punktu powinno zawierać identyfikator wybranej lokalizacji.

Nie wystarczy sama nazwa metody dostawy.

Integracja musi prawidłowo przenieść:

• kod punktu,
• adres,
• operatora,
• dane odbiorcy,
• telefon i e-mail.

Brak kodu punktu może uniemożliwić utworzenie przesyłki.

Dokumenty i wydruki

Proces może obejmować generowanie:

• faktur,
• paragonów,
• listów przewozowych,
• kart zamówień,
• dokumentów magazynowych,
• etykiet produktowych.

Dokumenty mogą być drukowane automatycznie po zmianie statusu.

Trzeba jednak ustalić:

• kiedy dokument jest ostateczny,
• który system nadaje numer,
• czy możliwa jest korekta,
• jak obsługiwać anulowanie,
• czy wydruk nie powstaje kilka razy.

Integracja z WooCommerce

BaseLinker może pobierać z WooCommerce między innymi:

• produkty,
• warianty,
• ceny,
• stany,
• zamówienia,
• dane klientów,
• statusy.

Może również przesyłać do sklepu:

• aktualne stany,
• ceny,
• statusy zamówień,
• numery przesyłek,
• wybrane dane produktów.

Zakres zależy od konfiguracji integracji.

WooCommerce jako źródło produktów

Jeżeli WooCommerce jest głównym katalogiem, produkty mogą być pobierane do BaseLinkera.

Trzeba sprawdzić:

• czy wszystkie produkty mają SKU,
• jak obsługiwane są warianty,
• gdzie przechowywana jest marka,
• gdzie znajduje się EAN,
• czy opisy zawierają kod kreatora,
• jak przekazywane są zdjęcia,
• czy stany są aktualne.

Niestandardowe pola mogą wymagać dodatkowego mapowania albo własnej integracji.

BaseLinker jako źródło produktów dla WooCommerce

W innym modelu katalog może być zarządzany centralnie poza sklepem.

WooCommerce otrzymuje wtedy:

• nowe produkty,
• zmiany cen,
• aktualizacje stanów,
• opisy,
• zdjęcia.

Trzeba uważać, aby synchronizacja nie nadpisywała ręcznie przygotowanych treści SEO i elementów wizualnych sklepu.

Można rozdzielić odpowiedzialność:

• BaseLinker aktualizuje stan i cenę,
• WooCommerce zachowuje opis i treści marketingowe.

Niestandardowe pola WooCommerce

Sklep może przechowywać dane w:

• polach ACF,
• metadanych produktu,
• własnych taksonomiach,
• polach wtyczki marek,
• dedykowanej tabeli,
• zewnętrznym systemie.

Standardowa integracja nie zawsze rozpoznaje wszystkie takie informacje.

Przed wdrożeniem sprawdzam, czy wymagane dane są dostępne i możliwe do pobrania.

Niestandardowe statusy WooCommerce

Sklep może posiadać dodatkowe statusy, na przykład:

• oczekuje na projekt,
• w produkcji,
• gotowe do odbioru,
• weryfikacja B2B.

Integracja musi wiedzieć, jak mapować je na proces BaseLinkera.

Nie każdy niestandardowy status powinien być wysyłany do marketplace’u.

Zamówienia tworzone poza WooCommerce

Zamówienie może zostać dodane:

• ręcznie w BaseLinkerze,
• przez marketplace,
• przez API,
• z systemu B2B,
• przez pracownika.

Trzeba ustalić, czy takie zamówienie ma zostać również utworzone w WooCommerce.

Tworzenie wszystkich zamówień zewnętrznych w sklepie może być potrzebne do:

• wspólnego raportowania,
• historii klienta,
• programu lojalnościowego,
• obsługi zwrotów.

Może jednak prowadzić do duplikacji, jeśli integracja działa w obu kierunkach bez odpowiedniego oznaczenia źródła.

Integracja z ERP

Połączenie może obejmować:

• produkty,
• ceny,
• stany,
• zamówienia,
• klientów,
• dokumenty,
• statusy,
• numery przesyłek.

Przed wdrożeniem trzeba ustalić:

• który system tworzy produkt,
• kto nadaje SKU,
• gdzie zmienia się cena,
• kiedy zamówienie trafia do ERP,
• kiedy rezerwowany jest stan,
• jak obsługiwane są anulowania,
• jak wraca numer dokumentu.

Integracja jednokierunkowa

W prostym modelu dane płyną tylko w jednym kierunku.

Przykładowo:

• ERP przesyła ceny i stany do BaseLinkera,
• BaseLinker przesyła zamówienia do ERP.

Każdy rodzaj danych posiada jasno określony kierunek.

Taki model jest łatwiejszy do kontrolowania niż pełna synchronizacja dwukierunkowa.

Integracja dwukierunkowa

W synchronizacji dwukierunkowej oba systemy mogą wysyłać zmiany tego samego rodzaju danych.

Wymaga to obsługi:

• konfliktów,
• kolejności zmian,
• pętli synchronizacji,
• czasu aktualizacji,
• priorytetów.

Jeżeli BaseLinker zmieni status w ERP, a ERP odeśle tę samą zmianę jako nowe zdarzenie, proces może uruchomić się ponownie.

Integracja powinna rozpoznawać własne aktualizacje.

BaseLinker API

API umożliwia programistyczne pobieranie danych i wykonywanie operacji.

Może być wykorzystane do:

• pobierania zamówień,
• zmiany statusów,
• aktualizowania produktów,
• odczytywania stanów,
• tworzenia przesyłek,
• pobierania dokumentów,
• łączenia własnego systemu.

Dokładne możliwości zależą od udostępnionych metod i uprawnień.

Klucz API

Klucz API umożliwia identyfikację integracji.

Powinien być:

• przechowywany po stronie serwera,
• chroniony przed publicznym dostępem,
• udostępniany wyłącznie potrzebnym systemom,
• możliwy do zmiany lub unieważnienia.

Nie należy umieszczać klucza w kodzie JavaScript widocznym w przeglądarce.

Limity API

API może ograniczać liczbę wykonywanych operacji.

Integracja powinna:

• unikać niepotrzebnych zapytań,
• pobierać dane partiami,
• obsługiwać błędy limitu,
• stosować kolejkę,
• ponawiać operacje z opóźnieniem.

Przetwarzanie każdego produktu osobnym żądaniem może być niewydajne przy dużym katalogu.

Webhooki i zdarzenia

Webhook może poinformować zewnętrzny system, że zamówienie lub produkt uległy zmianie.

Odbiorca może następnie pobrać szczegóły przez API.

Proces powinien obsługiwać:

• duplikaty,
• opóźnienia,
• nieprawidłową kolejność,
• błędy systemu docelowego,
• ponowienia.

Jedno zdarzenie nie powinno utworzyć kilku identycznych dokumentów.

Kolejki zadań

Duże operacje nie powinny blokować panelu ani procesu zamówienia.

Kolejka może przetwarzać w tle:

• eksport produktów,
• aktualizację stanów,
• przesyłanie zamówień,
• tworzenie przesyłek,
• ponawianie błędnych operacji.

Administrator powinien widzieć:

• zadania oczekujące,
• zadania zakończone,
• błędy,
• liczbę prób,
• czas ostatniej synchronizacji.

Co się dzieje podczas awarii?

System zewnętrzny może być chwilowo niedostępny.

Integracja nie powinna wtedy tracić zamówienia.

Powinna:

• zapisać operację,
• oznaczyć ją jako nieudaną,
• ponowić próbę,
• powiadomić administratora po przekroczeniu limitu,
• umożliwić ręczne wznowienie.

Nie każdy błąd powinien być ponawiany automatycznie.

Brak produktu w ERP wymaga innej reakcji niż chwilowy brak połączenia.

Błąd techniczny a błąd danych

Błąd techniczny może oznaczać:

• brak połączenia,
• timeout,
• niedostępność API,
• przekroczenie limitu.

Błąd danych może oznaczać:

• brak SKU,
• nieprawidłową cenę,
• brak wymaganej kategorii,
• nieznany status,
• nieistniejącego klienta.

Ponowienie żądania nie naprawi nieprawidłowego SKU.

Monitoring integracji

System powinien być regularnie kontrolowany.

Warto monitorować:

• czas ostatniego pobrania zamówień,
• liczbę błędów,
• niepowiązane produkty,
• kolejkę zadań,
• różnice stanów,
• różnice cen,
• zamówienia zatrzymane w statusie,
• nieutworzone przesyłki.

Brak komunikatu o błędzie nie zawsze oznacza, że synchronizacja działa.

Nagły brak nowych zamówień może być objawem przerwanego połączenia.

Logi integracji

Log powinien pomóc ustalić:

• kiedy operacja została wykonana,
• jakiego obiektu dotyczyła,
• który system ją uruchomił,
• jaki był wynik,
• dlaczego wystąpił błąd.

Logi nie powinny bez potrzeby zawierać:

• kluczy API,
• haseł,
• pełnych danych płatniczych,
• nadmiarowych danych osobowych.

Bezpieczeństwo konta

BaseLinker może posiadać dostęp do zamówień, klientów, produktów i integracji.

Należy stosować:

• indywidualne konta użytkowników,
• ograniczone uprawnienia,
• uwierzytelnianie dwuskładnikowe,
• regularną kontrolę dostępów,
• usuwanie kont po zakończeniu współpracy,
• bezpieczne przechowywanie kluczy.

Nie każdy pracownik potrzebuje możliwości zmiany integracji i automatyzacji.

Uprawnienia pracowników

Zakres dostępu może zależeć od roli.

Pracownik magazynu może potrzebować:

• listy zamówień,
• wydruków,
• przesyłek,
• zmiany wybranych statusów.

Nie musi posiadać dostępu do:

• kluczy API,
• konfiguracji cen,
• pełnych raportów finansowych,
• integracji kont.

Minimalny zakres ogranicza ryzyko przypadkowej zmiany.

BaseLinker a dane osobowe

System może przetwarzać:

• imiona i nazwiska,
• adresy,
• telefony,
• adresy e-mail,
• dane firmowe,
• historię zamówień.

Firma powinna kontrolować:

• kto posiada dostęp,
• jak długo dane są przechowywane,
• do jakich systemów są przesyłane,
• które integracje są aktywne,
• jak chronione są eksporty i logi.

Nie należy przekazywać pełnych danych zamówienia do narzędzia, które potrzebuje wyłącznie numeru i statusu.

Środowisko testowe

Zmiany w automatyzacjach i integracjach powinny być testowane przed zastosowaniem do całej sprzedaży.

Test może obejmować:

• zamówienie online,
• pobranie,
• odbiór osobisty,
• nieudaną płatność,
• produkt bez stanu,
• wariant,
• zestaw,
• zamówienie zagraniczne,
• zwrot,
• anulowanie.

Nie wystarczy przetestować jednego prostego zamówienia.

Testowanie automatyzacji

Przed aktywacją reguły sprawdzam:

1. Czy uruchamia się dla właściwego zamówienia?
2. Czy nie uruchamia się dla niewłaściwego?
3. Czy działa tylko raz?
4. Czy poprawnie reaguje na błąd?
5. Czy można cofnąć jej efekt?
6. Czy klient otrzymuje właściwą wiadomość?
7. Czy statusy w kanałach są zgodne?

Automatyzację warto najpierw ograniczyć do wybranych zamówień albo kontrolowanego okresu.

Kopia konfiguracji i dokumentacja

Konfiguracja powinna być udokumentowana.

Dokumentacja może zawierać:

• listę integracji,
• źródła danych,
• mapowanie statusów,
• reguły stanów i cen,
• opis automatyzacji,
• procedurę błędu,
• osoby odpowiedzialne,
• instrukcję wyłączenia procesu.

Bez dokumentacji usunięcie jednej reguły może przerwać cały proces realizacji.

Najczęstsze błędy w BaseLinkerze

Brak określonego źródła prawdy

Kilka systemów aktualizuje te same ceny i stany.

Duplikaty SKU

Różne produkty są rozpoznawane jako jedna pozycja.

Brak SKU wariantów

System nie potrafi połączyć konkretnych rozmiarów i kolorów.

Powiązanie oferty z niewłaściwym produktem

Sprzedaż jednego towaru zmniejsza stan innego.

Import bez kontroli duplikatów

Ten sam katalog zostaje utworzony kilka razy.

Nieprawidłowe mapowanie statusów

Zamówienie zostaje oznaczone jako zakończone zbyt wcześnie.

Automatyzacja bez scenariusza błędu

Nieudana przesyłka pozostawia zamówienie w przypadkowym statusie.

Tworzenie przesyłki kilka razy

Ponowione zdarzenie generuje kolejne etykiety.

Wiadomość wysyłana przed faktycznym zdarzeniem

Klient otrzymuje informację o wysyłce przed przekazaniem paczki kurierowi.

Brak kontroli płatności

Zamówienie jest realizowane mimo niepotwierdzonej transakcji.

Brak mapowania pól niestandardowych

EAN, marka albo ważna informacja pozostają niewidoczne dla integracji.

Nadpisywanie opisów sklepu

Synchronizacja usuwa ręcznie przygotowane treści marketingowe.

Jedna cena dla wszystkich kanałów

Kampanie i marketplace’y sprzedają produkty poniżej opłacalności.

Brak zapasu bezpieczeństwa

Ostatnia sztuka zostaje sprzedana w kilku kanałach.

Brak monitoringu kolejki

Zamówienia od kilku dni nie trafiają do ERP.

Brak dokumentacji

Nikt nie wie, dlaczego konkretna reguła zmienia status.

Zbyt szerokie uprawnienia

Każdy pracownik może zmieniać automatyzacje i integracje.

Brak testów po zmianach

Aktualizacja sklepu lub systemu magazynowego przerywa synchronizację.

Jak samodzielnie sprawdzić konfigurację BaseLinkera?

Podstawową kontrolę można rozpocząć od odpowiedzi na kilka pytań:

1. Jakie kanały sprzedaży są podłączone?
2. Skąd pochodzą produkty?
3. Który system jest źródłem stanów?
4. Który system jest źródłem cen?
5. Czy wszystkie produkty posiadają unikalne SKU?
6. Czy warianty mają własne identyfikatory?
7. Czy oferty są połączone z właściwymi produktami?
8. Jak często aktualizowane są stany?
9. Czy działa zapas bezpieczeństwa?
10. Jak mapowane są statusy zamówień?
11. Kiedy zamówienie jest uznawane za opłacone?
12. Kiedy tworzy się przesyłka?
13. Kiedy klient otrzymuje wiadomość?
14. Czy automatyzacje mogą wykonać się kilka razy?
15. Jak obsługiwany jest błąd kuriera lub ERP?
16. Gdzie widoczne są nieudane operacje?
17. Czy administrator otrzymuje alert?
18. Kto posiada dostęp do konfiguracji?
19. Czy połączenia API są udokumentowane?
20. Czy proces był testowany po ostatnich zmianach?

Jak wygląda prawidłowe wdrożenie BaseLinkera?

1. Opisuję proces sprzedaży – ustalam drogę zamówienia od złożenia do zakończenia.
2. Inwentaryzuję systemy – sprawdzam sklepy, marketplace’y, ERP, kurierów i płatności.
3. Określam źródła prawdy – przypisuję odpowiedzialność za produkty, ceny, stany i statusy.
4. Porządkuję identyfikatory – kontroluję SKU, EAN, warianty i powiązania ofert.
5. Projektuję magazyny – ustalam, jakie katalogi i stany są potrzebne.
6. Mapuję produkty – łączę oferty z właściwymi towarami i wariantami.
7. Mapuję statusy – opisuję przejścia pomiędzy sklepem, BaseLinkerem i ERP.
8. Konfiguruję ceny – uwzględniam kanały, prowizje, podatki i marże.
9. Konfiguruję stany – ustalam rezerwacje, bufory i częstotliwość synchronizacji.
10. Podłączam zamówienia – pobieram je do kontrolowanego procesu.
11. Podłączam kurierów – testuję metody dostawy, punkty i przesyłki niestandardowe.
12. Projektuję automatyzacje – tworzę warunki, akcje i scenariusze błędów.
13. Zabezpieczam duplikację – kontroluję przesyłki, dokumenty i operacje API.
14. Testuję scenariusze – sprawdzam płatności, pobrania, zwroty, warianty i błędy.
15. Uruchamiam etapami – zaczynam od ograniczonej grupy produktów lub zamówień.
16. Wdrażam monitoring – kontroluję kolejki, błędy, stany i zatrzymane zamówienia.
17. Dokumentuję konfigurację – zapisuję odpowiedzialność, mapowanie i procedurę awaryjną.

Czy każda firma potrzebuje BaseLinkera?

Nie.

Mały sklep prowadzący sprzedaż wyłącznie w jednym kanale może poradzić sobie z narzędziami WooCommerce, kuriera i systemu księgowego.

BaseLinker staje się szczególnie użyteczny, gdy firma:

• sprzedaje w wielu kanałach,
• posiada dużą liczbę zamówień,
• musi synchronizować stany,
• wystawia wiele ofert,
• korzysta z kilku kurierów,
• potrzebuje automatyzacji statusów,
• łączy sklep z ERP,
• chce ograniczyć pracę ręczną.

Nie wdrażam systemu wyłącznie dlatego, że posiada wiele funkcji. Najpierw sprawdzam, które procesy rzeczywiście wymagają centralizacji i automatyzacji.

Czy BaseLinker eliminuje pracę ręczną?

Może znacząco ją ograniczyć, ale nie każdą decyzję warto automatyzować.

Pracownik nadal może być potrzebny do:

• obsługi wyjątków,
• kontaktowania się z klientem,
• rozwiązywania błędów danych,
• weryfikacji zamówień wysokiego ryzyka,
• kontroli produktów niepowiązanych,
• obsługi zwrotów i reklamacji.

Najlepsza automatyzacja usuwa powtarzalne działania, ale pozostawia człowiekowi kontrolę nad wyjątkami.

Najważniejsze wnioski

• BaseLinker pomaga zarządzać sprzedażą prowadzoną w wielu kanałach.
• Może łączyć sklepy, marketplace’y, magazyny, ERP, kurierów i inne systemy.
• Nie zastępuje sklepu internetowego ani nie naprawia błędów jego procesu zakupowego.
• Przed wdrożeniem trzeba określić źródło produktów, cen, stanów i statusów.
• Każdy rodzaj danych powinien posiadać jasno wskazany system nadrzędny.
• SKU powinny być unikalne i stabilne we wszystkich połączonych systemach.
• Warianty wymagają osobnych identyfikatorów, cen i stanów.
• Oferta marketplace’u nie jest tym samym co produkt magazynowy.
• Każda oferta powinna być połączona z właściwym produktem lub wariantem.
• Synchronizacja stanów wymaga uwzględnienia rezerwacji i zapasu bezpieczeństwa.
• Ceny mogą różnić się pomiędzy kanałami ze względu na prowizje i koszty sprzedaży.
• Statusy powinny posiadać jednoznaczne definicje i prawidłowe mapowanie.
• Zmiana statusu może uruchamiać przesyłki, dokumenty i wiadomości.
• Automatyzacja powinna posiadać scenariusz sukcesu, błędu i ponowienia.
• Przesyłki, dokumenty i płatności trzeba zabezpieczyć przed wielokrotnym utworzeniem.
• Wiadomość o wysyłce nie powinna być wysyłana przed rzeczywistym przekazaniem paczki.
• Niestandardowe pola WooCommerce mogą wymagać dodatkowego mapowania.
• Synchronizacja nie powinna bez potrzeby nadpisywać opisów i treści SEO sklepu.
• API umożliwia tworzenie własnych integracji, ale wymaga ochrony kluczy i obsługi limitów.
• Webhooki i kolejki pomagają szybko reagować na zdarzenia bez utraty danych podczas awarii.
• Monitoring powinien obejmować brakujące zamówienia, kolejki, stany, ceny i błędy integracji.
• Dostępy pracowników powinny być ograniczone do ich rzeczywistych obowiązków.
• Każda ważna automatyzacja i integracja powinna być udokumentowana.
• Wdrożenie należy testować na wielu scenariuszach, a nie tylko na jednym poprawnym zamówieniu.
• BaseLinker daje największą wartość wtedy, gdy porządkuje wcześniej zdefiniowany proces sprzedaży.

Nie wiesz, czy BaseLinker jest prawidłowo połączony z Twoim sklepem?

Podczas analizy sprawdzam nie tylko to, czy zamówienia pojawiają się w panelu. Kontroluję źródła produktów, SKU, warianty, powiązania ofert, stany, ceny, statusy, przesyłki, automatyzacje i komunikację z systemami zewnętrznymi.

Mogę wskazać sytuacje, w których kilka ofert zmniejsza stan niewłaściwego produktu, zamówienia powstają podwójnie, a synchronizacja nadpisuje dane przygotowane ręcznie w WooCommerce.

Nie zakładam automatycznie, że trzeba przebudować całą konfigurację. Najpierw ustalam, gdzie powstaje błąd: w danych sklepu, magazynie, powiązaniu oferty, mapowaniu statusu, automatycznej akcji czy integracji API. Dopiero później porządkuję proces i zabezpieczam go przed utratą, duplikacją oraz niekontrolowanym nadpisywaniem danych.