Czym naprawdę jest zintegrowana platforma – definicja bez marketingu

Zintegrowana platforma to jedna baza produktów, klientów i zamówień, do której wszystkie systemy zapisują dane i z której je czytają — plus automatyczny obieg informacji między sklepem, ERP, magazynem, płatnościami i kurierami. Nie liczy się liczba wtyczek. Pięć narzędzi połączonych ręcznym eksportem CSV to nadal pięć oddzielnych światów, w których każdy plik trzeba sprawdzić i poprawić.

Platforma składa się z pięciu warstw i każda odpowiada za coś innego:

• Sprzedaż — katalog, ceny, stany, koszyk, zamówienie. Tu powstaje źródło prawdy o SKU i cenie. Jeśli cena żyje w trzech miejscach, prędzej czy później klient kupi po tej najstarszej.
• Finanse — faktura, dokument magazynowy, VAT, rozrachunki. Zamówienie trafia do księgowości bez przepisywania i bez uzgadniania na koniec miesiąca.
• Logistyka — rezerwacja stanu, lista kompletacji, etykieta kurierska, numer śledzenia wracający do zamówienia.
• Płatności — autoryzacja, potwierdzenie, zwrot i chargeback przypięty do konkretnego zamówienia, a nie do osobnego raportu u operatora.
• Dane klienta — historia zamówień, zgody marketingowe, reklamacje, statusy.

Różnica praktyczna: w „stacku narzędzi” informacja płynie eksportem raz na dobę i wymaga człowieka w środku. W platformie zdarzenie w jednym systemie wywołuje reakcję w pozostałych w kilka sekund. To widać dopiero na konkretnym zamówieniu.

Przykład: zamówienie złożone o 22:40. 22:40 — sklep zapisuje zamówienie i rezerwuje stan. 22:40:30 — webhook operatora potwierdza płatność, status zmienia się automatycznie. 22:41 — ERP tworzy dokument sprzedaży z poprawnym NIP-em i stawką VAT. 07:00 — magazyn dostaje listę kompletacji z lokalizacjami regałów. 08:15 — generuje się etykieta, numer śledzenia wraca do zamówienia i do klienta. 09:00 — faktura jest w systemie księgowym, stan zdjęty z magazynu.

Integracja nie naprawi złego cennika, wadliwego procesu zwrotów ani decyzji o asortymencie. Automatyzuje przepływ, nie podejmuje decyzji za właściciela. Jeśli dziś ręcznie łamiesz ceny na wyprzedaży, po integracji będziesz to robić szybciej i z większą szkodą.

Integracja czy zwykła wtyczka? 6 sygnałów, po których poznasz różnicę

Zanim podpiszesz umowę, zadaj dostawcy sześć pytań. Nie o technologię, o zachowanie w sytuacjach granicznych — tam wszystko wychodzi.

1. Mapowanie pól. Poproś o tabelę: pole w sklepie → pole w ERP. Sprawdź dwie rzeczy: czy stawki VAT są mapowane po stawce, czy po nazwie, i czy NIP klienta trafia do pola fakturowego, a nie do uwag.
2. Błędy 4xx i 5xx. Co system robi, gdy ERP odpowiada 500? Czy zamówienie zostaje w kolejce, czy przepada?
3. Mechanizm retry. Ile prób, w jakich odstępach (typowo: 3 próby, 5 s / 30 s / 5 min), co po ich wyczerpaniu?
4. Dostęp do logów. Gdzie je widzisz, jak długo są przechowywane (minimum 30 dni), czy możesz je filtrować po numerze zamówienia.
5. Idempotencja. Jeśli ten sam webhook przyjdzie dwa razy, powstanie jedna faktura czy dwie?
6. Kto utrzymuje po wdrożeniu. Imię, nazwisko, kanał zgłoszeń, czas reakcji. To zwykle decyduje o koszcie po roku — zobacz, jak wygląda utrzymanie i opieka techniczna sklepów w praktyce.

Test 10-minutowy. Zmień status zamówienia w ERP i sprawdź, czy sklep zaktualizuje go w mniej niż 60 sekund. Zrób to na zamówieniu testowym, nie na produkcyjnym. Potem zmień dwa razy pod rząd i sprawdź, czy nie powstały duplikaty.

Test zwrotu i anulowania. To miejsce, w którym integracje wypadają najczęściej. Anuluj zamówienie po opłaceniu, potem zwróć jeden produkt z zamówienia trzypozycyjnego. Sprawdź trzy punkty: czy stan wrócił na magazyn, czy powstał dokument korygujący i czy klient dostał maila. Ręczne poprawki po zwrotach to typowo 10–15 minut na zdarzenie.

Logi i kody. 401 to problem z kluczem API — alert natychmiast, bo stoi cały przepływ. 429 to przekroczony limit zapytań — potrzebny throttling, nie kolejna próba co sekundę. 500 po stronie ERP to błąd poza twoją kontrolą — alert po dwóch nieudanych retry. Alert powinien dotyczyć stanu przepływu (brak synchronizacji > 15 min, kolejka > 50 zdarzeń), a nie każdego pojedynczego błędu.

Kiedy wtyczka wystarczy? Gdy masz jeden kanał sprzedaży, do 20 zamówień dziennie i nie prowadzisz magazynu poza sklepem. Wtyczka z marketplace staje się długiem technicznym, gdy: nadpisuje pliki przy aktualizacji systemu, nie ma logów, sprzedawca nie odpowiada na zgłoszenia, a każdy zwrot robisz ręcznie. Wtedy płacisz nie za wtyczkę, a za godziny pracy ludzi.

7 mierzalnych efektów zintegrowanej platformy

Zanim wdrożysz cokolwiek, zmierz stan wyjściowy. Bez tego nie udowodnisz efektu ani sobie, ani księgowej.

1. Czas obsługi zamówienia. Ręcznie: 6–8 minut (sprawdzenie płatności, przepisanie do ERP, etykieta, mail). Automatycznie: 30–60 sekund, głównie praca magazynu. Pomiar: weź 10 kolejnych zamówień i stoperem zmierz czas od potwierdzenia płatności do wysłania etykiety.
2. Koszt błędu ręcznego. Literówka w adresie to nieudana dostawa: ponowny przejazd kuriera, kontakt z klientem, często rabat na przeprosiny. Jeden taki przypadek to kilkadziesiąt złotych plus 15–20 minut pracy.
3. Stany w czasie realnym. Koniec sprzedaży produktu, którego nie ma. Przy jednym SKU zamówionym dwa razy w tym samym dniu problem jest widoczny od razu — i widzi go klient.
4. Faktura bez przepisywania. Wystawienie faktury spada z 3–5 minut do kilku sekund. Największa oszczędność jest jednak na koniec miesiąca: domknięcie schodzi z 2–4 dni uzgodnień do kilku godzin.
5. Skala. Przy 50 zamówieniach dziennie i 6 minutach na zamówienie to 300 minut, czyli 5 godzin pracy każdego dnia roboczego. W miesiącu około 150 godzin. Przy 8 minutach — 200 godzin. To etat albo dwa.
6. Mniej ręcznych korekt. Zlicz korekty dokumentów i poprawki stanów z ostatniego miesiąca. To twoja lista strat, którą integracja powinna skrócić o 70–90%.
7. Efekt techniczny. Gdy sklep nie odpytuje zewnętrznych API przy każdym wejściu na kartę produktu, a stany pobiera z własnej bazy, strona ładuje się szybciej i stabilniej. To bezpośrednio przekłada się na Core Web Vitals i widoczność w Google — poczytaj o tym w artykule o SEO technicznym i optymalizacji szybkości, a definicje metryk znajdziesz w dokumentacji Web Vitals.

Uwaga na pułapkę: integracja skraca czas obsługi, ale nie zwiększa liczby zamówień sama z siebie. Jeśli proces zwrotów jest chaotyczny, po wdrożeniu będzie chaotyczny szybciej. Efekty licz na tych siedmiu wskaźnikach, nie na wrażeniu „działa płynniej”.

Kiedy to ma sens, a kiedy przepłacisz – progi decyzyjne

Zacznij od czterech progów. Przekroczenie któregokolwiek z nich oznacza, że ręczna obsługa kosztuje więcej, niż widać na fakturach — bo ten koszt siedzi w godzinach pracy, a nie w osobnej pozycji księgowej.

• Powyżej 20 zamówień dziennie — przepisywanie danych między sklepem, kurierem i księgowością zajmuje realnie 1,5–2 godziny dziennie.
• Powyżej 300 SKU — stany rozjeżdżają się między kanałami szybciej, niż ktokolwiek je koryguje.
• Więcej niż 2 kanały sprzedaży (własny sklep + marketplace + hurtownia) — każdy kanał to osobne wystawianie i osobna wersja stanów.
• Więcej niż 1 osoba obsługująca zamówienia — bez wspólnego źródła prawdy dwie osoby pracują na dwóch wersjach rzeczywistości.

Kalkulacja jest prosta: 2 godziny dziennie × 22 dni robocze = 44 godziny miesięcznie. Przy stawce 55–70 zł/h to 2400–3100 zł miesięcznie, czyli 29–37 tys. zł rocznie. Typowe wdrożenie (konektor, testy, cutover, dokumentacja) zamyka się w 42–116 godzinach. Porównuj więc godziny z godzinami, a nie „oszczędności” z cennikiem. Do kosztu ręcznej obsługi dolicz błędy: podwójnie wysłane zamówienie, zły stan magazynowy, faktura na niewłaściwy NIP.

Kiedy wystarczy eksport CSV raz na dobę. Przy 5–10 zamówieniach dziennie, jednym kanale i jednej osobie obsługującej — spokojnie. Wystarczy cron o 6:00, który pobiera raport z marketplace i eksport z WooCommerce lub PrestaShop do ERP. To nie wstyd, to świadoma decyzja: mniejszy zakres, mniej rzeczy do zepsucia.

Kiedy integracja staje się przymusem. KSeF i faktury ustrukturyzowane — wysyłka i odbiór muszą działać po stronie systemu sprzedaży. Wymogi marketplace — potwierdzanie zamówień i aktualizacja stanów w narzuconym czasie. Wiele magazynów albo dropshipping — bez wspólnego stanu i potwierdzenia dostępności u dostawcy sprzedajesz towar, którego fizycznie nie masz.

Jak wyłapać przepłacenie na etapie briefu. Weź listę integracji i przy każdej policz zdarzenia w miesiącu. Jeśli funkcja ma mniej niż 20 zdarzeń miesięcznie (np. eksport do CRM, który otwiera jedna osoba raz w tygodniu), nie wrzucaj jej do pierwszego etapu.

PrestaShop, WooCommerce czy SaaS – co lepiej się integruje

Wybór platformy to pytanie o trzy rzeczy: ile pracy włożysz na starcie, ile kontroli zostawisz sobie i co zabierzesz ze sobą przy zmianie.

PrestaShop. Webservice API włączysz w Zaawansowane → Webservice: generujesz klucz i nadajesz uprawnienia per zasób (GET/POST/PUT/DELETE na products, orders, stock_availables). Dane siedzą w tabelach ps_product, ps_product_lang, ps_stock_available, więc przy katalogu powyżej 1000 SKU działasz przewidywalnie. Jedna pułapka: stronicowanie. Przy 5000 SKU pobieranie listy bez parametrów limit i offset kończy się timeoutem. Wymagane nagłówki i kolejność wywołań opisuje dokumentacja dla deweloperów PrestaShop — warto ją przejrzeć jeszcze przed wyceną, bo oszczędza godziny analizy.

WooCommerce. REST API (/wp-json/wc/v3/products, /orders) jest wygodne i szybkie do wdrożenia, ale produkt to post z meta danymi, więc wydajność zależy od hostingu i cache. Przy 3000 SKU na słabym hostingu sam eksport przez API potrafi trwać 20 minut. Drugie ryzyko to zależność od wtyczek firm trzecich — ich aktualizacja potrafi zmienić format danych, na których opiera się integracja. Wdrożenia i optymalizacja WooCommerce to temat, który planuje się razem z integracją, a nie po niej.

SaaS. Mniej pracy na starcie (dni, nie tygodnie), mniejsza kontrola nad danymi i koszt rosnący z wolumenem: przy 50 zamówieniach miesięcznie plan kosztuje grosze, przy 500 — kilka razy więcej.

Lock-in. Zanim podpiszesz umowę, poproś o eksport próbki: 100 zamówień i 100 produktów w CSV lub JSON. Sprawdź, czy wyjdzie historia stanów, historia cen i dane klientów. Odpowiedź „eksport jest możliwy na życzenie” traktuj jak brak eksportu.

Ile to kosztuje i ile trwa – rozbicie na godziny

Wycena z sufitu („od 3000 zł”) nic nie mówi, bo nie wiesz, za co płacisz. Rozbij wdrożenie na etapy i przypisz im godziny.

Do tego dochodzą zależności zewnętrzne. Integracja płatności lub kuriera: 8–20 h, bo API są gotowe i udokumentowane. Integracja z ERP: 40–120 h — dochodzi mapowanie kontrahentów, statusów i dokumentów. Niestandardowy moduł: 30–90 h, gdy logika jest specyficzna (np. wyliczanie kosztu dostawy zależne od strefy i wagi).

Co realnie podnosi koszt: brak API po stronie dostawcy (zostaje scraping albo wymiana plików — plus 20–40 h i ryzyko przy każdej zmianie wyglądu strony), stare wersje PHP (7.4 i starsze nie mają wsparcia bezpieczeństwa, więc aktualizacja to osobny projekt), dane bez EAN i spójnych ID (300 SKU × 2 minuty to 10 godzin samego mapowania), wiele kanałów sprzedaży i decyzje podejmowane w trakcie („to jeszcze dorzućcie”).

Godziny czy stały pakiet. Po godzinach wyceniamy analizę, moduł i testy — bo realny zakres znasz dopiero po analizie. Jako stały pakiet można wycenić standardowy konektor do popularnej bramki płatności czy kuriera, bo to robota powtarzalna. Widełki są uczciwsze niż sztywne „od X zł”: „od” zawsze opisuje najprostszy przypadek, który rzadko występuje.

Opieka po wdrożeniu. Zaplanuj pakiet 5–10 godzin miesięcznie i zapisz SLA: np. reakcja do 4 godzin w dni robocze 9–17 na błędy blokujące i do 24 godzin na pozostałe. W umowie rozdziel, co wchodzi w pakiet (aktualizacje bezpieczeństwa, monitoring, kopie zapasowe), a co jest osobną wyceną — nowa integracja to nie „drobna zmiana”. Utrzymanie i opieka techniczna sklepów to osobny budżet, którego nie warto udawać, że nie istnieje.

Wdrożenie krok po kroku – 8 etapów i punkty kontrolne

Wdrożenie da się zamknąć w ośmiu etapach. Każdy ma punkt kontrolny – jeśli wykonawca go pomija, to sygnał, że projekt będzie się ciągnął miesiącami.

Etap 1 – audyt danych. Eksport z 12 miesięcy: zamówienia, klienci, produkty. Szukasz trzech rzeczy: duplikatów klientów (ten sam e-mail zapisany z inną pisownią nazwiska), brakujących EAN i pustych pól ID. Punkt kontrolny: liczba SKU w sklepie i w ERP różni się o 0. Jeśli różni się o 40 – nie zaczynasz integracji, najpierw porządkujesz kartotekę.

Etap 2 – jedno źródło prawdy. Zapisujesz to w briefie jednym zdaniem: stany magazynowe i ceny zakupowe w ERP, treści, zdjęcia i opisy w sklepie. Bez tego zapisu dwa systemy zaczną się nadpisywać i po dwóch tygodniach nikt nie będzie wiedział, która liczba jest prawdziwa.

Etapy 3–4 – mapowanie pól i statusów w tabeli. Kolumny: pole w sklepie, pole w ERP, pole u kuriera, czy wymagane, sposób konwersji. Status musi mieć odpowiednik w obie strony, nie tylko ze sklepu do ERP. Punkt startu dla listy pól to dokumentacja API PrestaShop dla deweloperów.

Etap 5 – środowisko testowe na zamaskowanych danych produkcyjnych. Kopia bazy z produkcji, ale z podmienionymi e-mailami, telefonami i adresami. Testowanie na żywych danych osobowych to najprostsza droga do problemu zgodnościowego. Maskowanie robisz raz, skryptem, nie ręcznie w arkuszu.

Etapy 6–7 – test obciążeniowy i cutover. Minimum: 200 zamówień w 10 minut, czyli 20 na minutę. Mierzysz czas odpowiedzi webhooka i długość kolejki. Cutover w oknie poza szczytem, z gotowym rollbackiem: wyłączenie webhooków, powrót do ręcznego wystawiania dokumentów, powrót poniżej 15 minut. Takie rzeczy planuje się razem z wdrożeniem i optymalizacją WooCommerce, bo obciążenie zależy od tego, jak sklep jest zbudowany.

Etap 8 – monitoring, alerty i właściciel procesu. Alerty: brak webhooka przez 30 minut, błędy 5xx powyżej 1% żądań, kolejka powyżej 200 zdarzeń. Właściciel po stronie klienta z imienia i nazwiska, nie „dział IT”. To element utrzymania i opieki technicznej sklepu.

Kolejność ma znaczenie. Najpierw płatności i kurierzy – tam są pieniądze i klient, a zakres pól jest mały. ERP na końcu: najwięcej pól, najdłużej uzgadniane mapowania i największe ryzyko opóźnienia.

8 pułapek, które zabijają wdrożenie i jak je wykryć przed startem

Te osiem problemów wraca w każdym drugim projekcie. Każdy da się wykryć przed startem, jeśli wiesz, czego szukać.

1. Rozjazd stanów magazynowych. Test: 100 zamówień na jeden SKU, po każdym porównujesz stan w sklepie i w ERP. Jeśli po 20. zamówieniu liczby się różnią, problem jest w kolejności zdarzeń, nie w „błędzie synchronizacji”.

2. Brak idempotencji webhooków. Ten sam event wysłany trzy razy nie może utworzyć trzech zamówień ani trzech faktur. Test: wyślij identyczne zdarzenie trzy razy i sprawdź, czy masz jeden dokument. Rozwiązanie: klucz idempotencji (ID zamówienia + typ zdarzenia) z unikalnym indeksem w bazie.

3. Limity API i odpowiedzi HTTP 429. Retry z backoffem wykładniczym i losowym opóźnieniem, np. 5 prób: 1 s, 2 s, 4 s, 8 s, 16 s. Testuj przed sezonem szczytowym, nie w jego trakcie.

4. Strefy czasowe i daty dokumentów. Zamówienie o 23:50 czasu lokalnego a data wystawienia faktury to klasyczny błąd. Bazę trzymaj w UTC, dokumenty licz w Europe/Warsaw, a granicę dnia przetestuj zamówieniem złożonym o 23:50 i 00:10.

5. Status w ERP bez odpowiednika w sklepie. Mapowanie musi działać w obie strony. Test: zmień status w ERP i sprawdź, czy sklep go pokazuje i czy klient dostaje właściwego maila.

6. Dane osobowe w logach i eksportach. Logi nie mogą zawierać e-maila, telefonu ani adresu. Maskowanie po stronie aplikacji, retencja 30 dni. To obszar, który warto przejrzeć razem z administracją serwerami i VPS, bo najczęściej dane wyciekają właśnie na poziomie serwera.

7. Brak właściciela po wdrożeniu. Kto reaguje, gdy integracja padnie o 7 rano w poniedziałek? Konkretna osoba, numer telefonu i zakres decyzji. Bez tego alerty trafiają w pustkę.

8. Brak wersjonowania konfiguracji i mapowań. Zmiana ustawienia w panelu bez zapisu to najczęstsza przyczyna „cudów” po dwóch miesiącach. Test: czy potrafisz odtworzyć konfigurację z pliku po awarii serwera?

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Policz średnią i szczytową liczbę zamówień dziennie — Weź ostatnie trzy miesiące z panelu sklepu, oddziel dzień zwykły od promocji. Sprawdź przed każdą rozmową z dostawcą.
• Policz aktywne SKU — Tylko produkty faktycznie dostępne i wystawione. Sprawdź, czy liczba w sklepie zgadza się z liczbą w magazynie i ERP.
• Wypisz wszystkie kanały sprzedaży — Sklep, marketplace, sprzedaż stacjonarna, B2B. Sprawdź, czy każdy kanał ma osobny proces obsługi zamówienia.
• Policz osoby dotykające jednego zamówienia — Od kliknięcia klienta do wysyłki. Jeśli jest ich więcej niż jedna, każda ręczna operacja to miejsce na błąd i opóźnienie.
• Zmierz czas obsługi jednego zamówienia stoperem — Weź 20 losowych zamówień z ostatniego tygodnia i zmierz pełną ścieżkę. Wynik 6–8 minut na zamówienie to typowy punkt startowy.
• Policz ręczne poprawki zwrotów i anulowań w miesiącu — Przejrzyj skrzynkę i korespondencję z klientami. Każda poprawka to sygnał, że proces nie domyka się automatycznie.
• Zmierz czas wystawienia faktury i zamknięcia miesiąca — Policz dni od ostatniego dnia miesiąca do gotowego raportu. Sprawdź, ile danych było przepisywanych ręcznie.
• Zrób test 10-minutowy na statusie zamówienia — Zmień status w ERP i sprawdź, czy sklep zaktualizuje go w mniej niż 60 sekund. Test wykonaj na wersji testowej lub na jednym zamówieniu.
• Sprawdź mapowanie pól i słowniki statusów — Poproś o tabelę: pole w systemie A, pole w systemie B, typ danych, wartość domyślna. Sprawdź, co dzieje się przy pustym polu.
• Sprawdź obsługę błędów 401, 429 i 5xx oraz retry — Zapytaj, co system robi przy każdym z tych kodów i po jakim czasie ponawia próbę. Sprawdź, czy przy 401 leci alert do człowieka.
• Zweryfikuj dostęp do logów integracji — Poproś o zrzut z ostatnich 30 dni i o dostęp dla Twojej firmy po wdrożeniu. Logi bez dostępu to logi bezużyteczne.
• Przetestuj pełny scenariusz zwrotu i anulowania — Zamówienie, anulowanie, ponowne zamówienie, zwrot części pozycji. Sprawdź stan magazynowy, płatność i dokumenty po każdej operacji.
• Ustal, kto utrzymuje integrację po wdrożeniu — Zapisz w umowie czas reakcji na błąd krytyczny i zakres opieki. Sprawdź to przed podpisaniem, nie po pierwszej awarii.
• Sprawdź zgodność stanów magazynowych online z rzeczywistością — Wybierz 10 produktów i porównaj stan w sklepie, ERP i na półce. Różnice oznaczają, że dane nie płyną w czasie realnym.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• PrestaShop – dokumentacja dla deweloperów
• web.dev – Core Web Vitals