Synchronizacja sprzedaży z kilku marketplace’ów – biznes dla osób wdrażających systemy typu multichannel

Sprzedawca działający jednocześnie na Allegro, Amazonie, Empiku, Kauflandzie, własnym WooCommerce czy Shopify bardzo szybko trafia na problem, którego nie da się rozwiązać dodatkowym Excelem. Ten sam produkt występuje w kilku kanałach, zamówienia wpadają z różnych miejsc, stany magazynowe zmieniają się co kilka minut, a wystarczy jedna niesynchronizowana sztuka, żeby sprzedać towar, którego fizycznie już nie ma.

I właśnie na tym problemie można zbudować konkretną usługę B2B. Wdrożenia systemów multichannel nie polegają bowiem na założeniu konta w integratorze i wpisaniu hasła do Allegro. Prawdziwa praca zaczyna się przy mapowaniu produktów, magazynów, cen, statusów, dokumentów, kurierów i wyjątków występujących w procesie sprzedaży.

Dla osoby technicznej, software house’u, freelancera e-commerce albo firmy wdrażającej ERP jest to interesująca nisza z dwóch powodów. Po pierwsze, klient płaci nie tylko za samo uruchomienie systemu. Po drugie, źle wykonana integracja szybko generuje wymierne straty, więc przedsiębiorcy mają powód, żeby kupić fachową konfigurację zamiast samodzielnie eksperymentować przez kilka tygodni.

Gdzie rzeczywiście zaczyna się biznes na wdrożeniach multichannel

Najłatwiej sprzedać usługę firmie, która ma już co najmniej dwa kanały sprzedaży i zaczyna odczuwać problemy operacyjne. Sklep realizujący 30 zamówień miesięcznie zwykle poradzi sobie ręcznie. Przy 300–500 zamówieniach sytuacja wygląda inaczej, szczególnie kiedy część sprzedaży pochodzi z marketplace’u, część ze sklepu internetowego, a magazynem zarządza Subiekt GT, enova365, Comarch ERP albo osobny WMS.

Typowe sygnały, że klient potrzebuje wdrożenia, są bardzo konkretne:

• pracownik kilka razy dziennie ręcznie zmienia stany na Allegro lub w sklepie,
• ceny na marketplace’ach nie odpowiadają cenom zapisanym w ERP,
• ten sam produkt ma różne symbole SKU w kilku systemach,
• zamówienia trzeba przepisywać do programu magazynowego,
• etykiety kurierskie powstają w osobnych panelach,
• status „wysłane” nie wraca automatycznie do marketplace’u,
• klient otrzymuje anulowania zamówień z powodu braku towaru,
• faktura lub paragon są tworzone ręcznie,
• zwroty nie aktualizują dostępnego zapasu,
• przedsiębiorca nie wie, który system jest nadrzędnym źródłem stanu magazynowego.

To właśnie ostatni punkt jest często najważniejszy.

W poprawnie zaprojektowanym środowisku trzeba ustalić jedno źródło prawdy o zapasie. Jeżeli stan magazynowy jednocześnie „kontroluje” ERP, integrator i sklep internetowy, wcześniej czy później pojawią się konflikty. Jeden system zapisze 12 sztuk, drugi 10, trzeci 11, a administrator będzie szukał błędu dopiero po sprzedaży produktu, którego nie ma na półce.

Dobry wdrożeniowiec nie zaczyna więc od podłączania marketplace’ów. Zaczyna od diagramu:

produkt → magazyn → integrator → kanał sprzedaży → zamówienie → ERP/WMS → wysyłka → status → dokument → zwrot.

Dopiero po ustaleniu kierunku przepływu danych konfiguruje narzędzia.

Na polskim rynku najczęściej spotyka się systemy takie jak BaseLinker, Apilo, integracje tworzone bezpośrednio pod API marketplace’ów oraz rozwiązania pośredniczące między ERP, sklepem i platformami sprzedażowymi. Różnią się możliwościami i modelem rozliczeń, ale dla wdrożeniowca ważniejsze od liczby dostępnych integracji jest pytanie, czy konkretne połączenie obsługuje wszystkie operacje wymagane przez klienta.

Samo „mamy integrację z ERP” nie wystarcza.

Trzeba sprawdzić, czy działa:

• pobieranie i rezerwowanie stanów,
• aktualizacja cen,
• tworzenie dokumentów,
• obsługa zestawów i kompletów,
• synchronizacja wielu magazynów,
• aktualizacja numerów przesyłek,
• obsługa zwrotów,
• korekty dokumentów,
• mapowanie wariantów,
• przenoszenie numerów VAT UE,
• rozróżnianie sprzedaży krajowej i zagranicznej.

To właśnie na takich szczegółach kończą się wdrożenia „za kilka kliknięć”.

Ile można liczyć za wdrożenie i gdzie pojawia się największa marża

Najgorszy model biznesowy to wycenianie wdrożenia jako liczby podłączonych kanałów. Integracja Allegro + Amazon + sklep nie musi być trzy razy trudniejsza od pojedynczego kanału. Czasem jest dziesięć razy trudniejsza, ponieważ klient ma kilka magazynów, zestawy produktowe, własne reguły cenowe i nietypowy obieg dokumentów.

Dlatego sensowniejsza jest wycena według zakresu procesów oraz liczby wyjątków, a nie liczby ikon marketplace’ów.

Przy niewielkim polskim e-commerce orientacyjne ceny usług wdrożeniowych mogą wyglądać następująco:

• 500–1500 zł netto – podstawowa konfiguracja jednego prostego kanału przy gotowej bazie produktów,
• 1500–4000 zł netto – kilka marketplace’ów, automatyzacje statusów, kurierzy i podstawowa synchronizacja magazynu,
• 4000–10 000 zł netto – połączenie z ERP, mapowanie produktów, testy dokumentów, reguły cenowe i migracja istniejącej sprzedaży,
• 10 000–30 000 zł netto i więcej – większy sklep, kilka magazynów, WMS, nietypowe integracje API, sprzedaż zagraniczna oraz rozbudowana automatyzacja.

To nie są stawki z urzędowego cennika. Są praktycznymi widełkami, które trzeba przeliczyć na własną stawkę godzinową, zakres odpowiedzialności i stopień ryzyka projektu.

Przy stawce 150–250 zł netto za godzinę projekt zajmujący 25 godzin powinien kosztować mniej więcej 3750–6250 zł netto. Sprzedawanie go za 1500 zł tylko dlatego, że „to przecież konfiguracja BaseLinkera”, szybko zamienia usługę w nieopłacalną.

Dużo lepiej rozdzielić projekt na etapy:

1. Audyt – 500–1500 zł netto.
Sprawdzenie kanałów, ERP, SKU, magazynów, sposobu tworzenia dokumentów i obecnego obiegu zamówienia.

2. Projekt konfiguracji.
Określenie systemu nadrzędnego, kierunków synchronizacji i wyjątków.

3. Wdrożenie – zwykle kilka tysięcy złotych.
Podłączenie kanałów, mapowanie produktów, automatyzacje, wysyłki, dokumenty.

4. Testy.
Nie pięć testowych zamówień jednego rodzaju. Trzeba przetestować przynajmniej sprzedaż pojedynczego produktu, zestawu, anulowanie, częściowy zwrot, brak stanu, zmianę ceny, przesyłkę i ponowienie komunikacji po błędzie.

5. Stabilizacja.
Kilka lub kilkanaście dni po uruchomieniu, kiedy wychodzą przypadki, których klient nie zgłosił podczas analizy.

6. Utrzymanie – np. 300–2000 zł netto miesięcznie.
Kontrola błędów, zmiany integracji, nowe automatyzacje, dodawanie kanałów i reagowanie po zmianach API.

Właśnie abonament serwisowy jest jednym z ciekawszych elementów tego biznesu. Marketplace’y zmieniają wymagania, sprzedawca dodaje magazyny, pojawiają się nowe sposoby dostawy, zmieniają się procesy księgowe. System, który został poprawnie skonfigurowany w styczniu, w listopadzie może wymagać kolejnych zmian.

Trzeba jednak jasno ustalić zakres utrzymania. „Opieka nad integracją” bez limitu godzin to proszenie się o konflikt. Lepszym rozwiązaniem jest przykładowo 3 godziny miesięcznie w abonamencie, określony czas reakcji i osobna stawka za prace przekraczające pakiet.

Istotny jest także koszt samego oprogramowania. Przykładowo w sierpniu 2026 r. Apilo oferuje pakiety od 39 zł netto miesięcznie za Starter, przez 199 zł za Basic, 399 zł za Professional i 799 zł za Optimum, do 999 zł za Advanced. Wyższy poziom obsługuje większą liczbę zamówień i ofert. Dodatkowo płatna może być szybsza synchronizacja, integracja z hurtownią czy konkretnym ERP.

To ważna lekcja również dla wdrożeniowca: klient powinien poznać nie tylko cenę Twojej pracy, ale pełny miesięczny koszt utrzymania architektury.

Jeżeli po wdrożeniu przedsiębiorca ma płacić 800 zł za integrator, 500 zł za dodatkową wtyczkę ERP i 700 zł za miesięczne utrzymanie, trzeba powiedzieć o 2000 zł miesięcznego kosztu przed podpisaniem umowy. Ukrywanie tego do końca projektu jest prostą drogą do niezadowolonego klienta.

Najwięcej problemów nie powoduje API, tylko źle ustalone reguły danych

Integracje marketplace’owe brzmią jak przedsięwzięcie programistyczne, lecz w praktyce sporą część problemów powoduje nie kod, tylko bałagan w katalogu produktowym i źle zaprojektowany proces.

Przykład z życia wdrożeń: ten sam kubek występuje w ERP jako `KUB-BIA-01`, w sklepie jako `KB001`, a na Allegro został wystawiony ręcznie bez powiązanego SKU. Integrator pobiera zamówienie, ale nie potrafi jednoznacznie wskazać produktu magazynowego. Synchronizacja technicznie działa. Biznesowo nie działa nic.

Dlatego przed migracją trzeba wykonać audyt identyfikatorów.

Minimum to tabela zawierająca:

• SKU w systemie nadrzędnym,
• EAN/GTIN, jeśli produkt go posiada,
• identyfikator wariantu,
• identyfikator oferty na każdym marketplace,
• magazyn,
• stan fizyczny,
• stan możliwy do sprzedaży,
• cenę bazową,
• regułę ceny kanałowej.

Szczególnej uwagi wymagają zestawy.

Jeżeli klient sprzedaje osobno szampon i odżywkę, ale na Allegro ma również zestaw „szampon + odżywka”, stan zestawu nie może być niezależną liczbą. Przy 12 szamponach i 5 odżywkach można sprzedać maksymalnie 5 kompletów. System musi pomniejszać zapas komponentów również wtedy, kiedy klient kupuje zestaw.

Jeszcze bardziej problematyczny jest zapas bezpieczeństwa.

Firma ma 20 sztuk produktu, ale równocześnie sprzedaje na trzech platformach. Wystawienie pełnych 20 sztuk wszędzie jest bezpieczne wyłącznie wtedy, kiedy rezerwacja i aktualizacja stanów przebiegają wystarczająco szybko. Jeżeli aktualizacja odbywa się np. raz na godzinę, produkt o wysokiej rotacji może zostać w tym czasie kupiony w kilku kanałach.

W takim przypadku stosuje się bufor. Fizycznie jest 20 sztuk, ale kanałom udostępnia się np. 17 lub 18.

Nie istnieje jedna prawidłowa wartość bufora. Dla produktu sprzedającego dwie sztuki tygodniowo zapas bezpieczeństwa 5 sztuk bez potrzeby ograniczy sprzedaż. Dla produktu kupowanego kilkanaście razy na godzinę bufor jednej sztuki może być za mały.

Trzeba go wyznaczać na podstawie:

rotacji produktu × opóźnienia synchronizacji × liczby aktywnych kanałów.

Drugi częsty błąd dotyczy cen.

Sprzedawca zakłada: cena w ERP wynosi 100 zł, więc wszędzie ma kosztować 100 zł. Tymczasem każdy marketplace ma inną strukturę prowizji, koszty promocji, logistykę i wymagania dotyczące ofert. Cena kanałowa powinna być liczona oddzielnie.

Przykładowa reguła może wyglądać tak:

cena marketplace = cena bazowa × 1,08 + 3 zł

albo być oparta na kategorii, marży minimalnej czy konkretnym rynku.

Nie wolno natomiast automatycznie przenosić każdej zmiany ceny bez ustalenia zabezpieczeń. Literówka w ERP, np. wpisanie 19,90 zł zamiast 199 zł, może po synchronizacji wylądować równocześnie na kilku marketplace’ach.

Dlatego przy większych wdrożeniach warto stosować regułę odrzucającą zmianę przekraczającą określony próg, np. 20–30% jednorazowo, i kierować ją do ręcznej weryfikacji.

Podobne zabezpieczenia powinny obejmować:

• ujemne stany,
• produkt bez SKU,
• ofertę bez powiązania z kartoteką,
• zamówienie bez metody dostawy,
• brak danych do dokumentu,
• powtórzony numer zamówienia,
• brak odpowiedzi systemu nadrzędnego,
• błędną walutę,
• zmianę statusu w niewłaściwej kolejności.

To właśnie system obsługi wyjątków odróżnia porządne wdrożenie od konfiguracji, która działa jedynie podczas prezentacji.

Dochodzi jeszcze sprzedaż zagraniczna. Przy Amazonie, Kauflandzie czy innych platformach działających na kilku rynkach trzeba uwzględniać m.in. waluty, stawki podatkowe, zasady VAT OSS, lokalne wymagania ofertowe oraz obowiązki dotyczące informacji produktowych. Od grudnia 2024 r. w UE obowiązuje GPSR, więc przy sprzedaży produktów konsumenckich znaczenie mają m.in. dane producenta lub podmiotu odpowiedzialnego i wymagane informacje dotyczące bezpieczeństwa. Integrator nie powinien „zgadywać” brakujących danych – powinien pokazać klientowi, które pola są niekompletne.

Równie ważna jest księgowość. Polska sprzedaż internetowa wchodzi w okres obowiązkowego KSeF, którego kolejne etapy obejmują 2026 r. Jeżeli projekt obejmuje ERP i fakturowanie, trzeba ustalić z księgowym lub dostawcą systemu, gdzie dokładnie powstaje dokument i który system odpowiada za wysłanie go do KSeF. Wysyłanie faktury z dwóch aplikacji jednocześnie nie jest automatyzacją – jest błędem architektury.

Największą niedogodnością całego modelu multichannel pozostaje zależność od zewnętrznych platform. API może mieć limity, marketplace może zmienić strukturę danych, token autoryzacyjny może wygasnąć, a moduł dostaw może zacząć zwracać nowy typ błędu. Żaden wdrożeniowiec nie zagwarantuje, że integracja nigdy się nie zatrzyma.

Można natomiast zaprojektować ją tak, żeby awaria była widoczna i możliwa do odtworzenia.

Dlatego system powinien przechowywać logi, kolejkę operacji zakończonych błędem i informację o ostatniej poprawnej synchronizacji. Automatyczne ponawianie też trzeba ograniczać. Jeśli błędne zamówienie zostanie ponowione 500 razy bez rozwiązania przyczyny, zamiast odpornego systemu powstaje generator kolejnych problemów.

Dla firmy wdrożeniowej właśnie ten etap jest najbardziej wartościowy biznesowo. Klient nie płaci wyłącznie za połączenie API. Płaci za zmniejszenie liczby sytuacji, w których człowiek musi ręcznie ratować sprzedaż.

FAQ – wdrażanie sprzedaży multichannel

Czy trzeba być programistą, żeby zarabiać na wdrożeniach multichannel?
Nie przy każdym projekcie. Dużą część wdrożeń można wykonać w gotowych systemach takich jak BaseLinker czy Apilo. Znajomość API staje się potrzebna przy nietypowych ERP, własnych sklepach, niestandardowych przepływach danych albo funkcjach, których gotowy integrator nie obsługuje.

Od ilu marketplace’ów opłaca się wdrażać centralny system?
Najczęściej już od dwóch kanałów, jeżeli współdzielą ten sam magazyn. Kryterium nie powinna być jednak liczba marketplace’ów, lecz liczba ręcznych operacji i ryzyko rozjazdu stanów. Firma obsługująca jeden marketplace i sklep przy 1000 zamówień miesięcznie może potrzebować automatyzacji bardziej niż sprzedawca mający cztery kanały i 40 zamówień.

Ile trwa typowe wdrożenie?
Prosta konfiguracja gotowych integracji może zamknąć się w 1–3 dniach pracy. Projekt obejmujący kilka marketplace’ów, ERP, automatykę dokumentów i migrację produktów zwykle wymaga od około tygodnia do kilku tygodni. Najwięcej czasu zabiera często nie konfiguracja techniczna, ale poprawienie kartotek produktów i uzgodnienie procesów.

Co powinno znaleźć się w umowie z klientem?
Zakres kanałów, system nadrzędny, zakres synchronizowanych danych, odpowiedzialność za dane produktowe, procedura testów, okres stabilizacji, stawka za prace dodatkowe oraz zasady reakcji na awarie usług zewnętrznych. Trzeba również zaznaczyć, że zmiana API albo regulaminu marketplace’u nie jest błędem wykonawcy.

Czy synchronizacja stanów musi działać w czasie rzeczywistym?
Nie. Dla wolno rotującego asortymentu aktualizacja co kilkanaście minut lub nawet rzadziej może wystarczyć. Przy produktach szybko rotujących, małym zapasie lub wielu aktywnych kanałach opóźnienie zwiększa ryzyko oversellingu. Wtedy trzeba przyspieszyć synchronizację albo zastosować zapas bezpieczeństwa.

Co jest największym błędem początkującego wdrożeniowca?
Podłączanie systemów przed ustaleniem, który system jest właścicielem poszczególnych danych. Najpierw trzeba ustalić, skąd pochodzi stan, cena, produkt, dokument i status zamówienia. Dopiero potem konfigurować integracje.

Czy można zbudować na tym stały biznes, a nie tylko jednorazowe wdrożenia?
Tak. Najbardziej przewidywalny model łączy płatny audyt, wdrożenie oraz późniejsze utrzymanie. Kolejne marketplace’y, zmiany API, nowe magazyny, automatyzacje i błędy operacyjne powodują, że część klientów potrzebuje stałego wsparcia.

Pierwszą rzeczą, którą należy zrobić przed sprzedażą takiej usługi, nie jest wybór integratora ani przygotowanie cennika. Weź jedno rzeczywiste zamówienie klienta i rozpisz jego pełną drogę od marketplace’u do wydania paczki oraz dokumentu sprzedaży. Przy każdym etapie zaznacz system, który zapisuje dane, oraz system, który może je zmienić.

Jeżeli przy stanie magazynowym, cenie albo statusie zamówienia pojawią się dwa systemy nadrzędne, usuń ten konflikt przed wszystkim innym. To właśnie podwójna odpowiedzialność za te same dane jest jednym z pierwszych błędów, które później prowadzą do nadpisanych stanów, błędnych cen i zamówień wymagających ręcznej naprawy.

Więcej informacji na: https://hd-biznes.com/blog