PrestaShop a Endora Commerce - co wybrać do sprzedaży B2B

Kiedy polska firma handlowa szuka platformy do sprzedaży, PrestaShop trafia na krótką listę prawie zawsze. Ma ku temu mocne powody. To dojrzały system open source w PHP, który w Polsce ma jedną z najsilniejszych pozycji ze wszystkich platform: ponad 15 tysięcy aktywnych sklepów i rynek wykonawców, w którym agencję znajdziesz w każdym większym mieście. Kod dostajesz na własność, hosting wybierasz sam, a katalog modułów (oficjalne Addons to ponad 3 tysiące pozycji, a poza nim działa jeszcze cały rynek polskich dostawców) pokrywa praktycznie każdą potrzebę sklepu. W lutym 2026 PrestaShop przejęła grupa cyber_Folks razem z Sylius i BitBagiem. Właściciel platformy siedzi więc dziś w Poznaniu, a nie w Paryżu, i wnosi do grupy około 230 tysięcy aktywnych sklepów na całym świecie.

Różnica między PrestaShop a Endora Commerce zaczyna się w punkcie wyjścia. PrestaShop powstał jako silnik sklepu detalicznego i tak jest zbudowany do dziś. Sprzedaż firma-firma realizuje się w nim na dwa sposoby. Pierwszy to tryb B2B: przełącznik w ustawieniach klientów, który dokłada do karty klienta pola firmowe, autoryzowany limit zadłużenia, maksymalną liczbę dni płatności i ocenę ryzyka. Drugi to grupy klientów z własnymi cenami, rabatami i widocznością katalogu. To działa i obsługuje sensowny zakres hurtu z cennika. Wszystko, co wykracza poza ten zestaw, dokłada się modułami: zapytania ofertowe, negocjacje ceny, katalog zależny od roli, ukrywanie produktów per grupa, hierarchia oddziałów.

Endora Commerce poszła odwrotnie: kupującym jest organizacja, cena wynika z kontraktu, zamówienie może być efektem negocjacji, a sprzedaż detaliczna działa jako dodatkowy kanał na tym samym modelu danych. Ten tekst jest przede wszystkim o tym, co dostajesz za porównywalny budżet, bo wniosek, który zaskakuje najczęściej, brzmi tak: przy zakresie B2B obie platformy mieszczą się w tej samej półce cenowej. Przy każdym kryterium znajdziesz więc zarówno przewagi PrestaShop, jak i Endory, a na końcu konkretne scenariusze i listę kontrolną.

Skrót dla niecierpliwych

Jeśli masz przeczytać tylko trzy zdania: PrestaShop wybierasz, kiedy chcesz ruszyć szybko i tanio, Twój B2B da się opisać jako „hurt z cennika”, a lista integracji pokrywa się z tym, co polski rynek modułów już umie. Endorę wybierasz, kiedy sprzedaż firma-firma jest Twoim głównym biznesem: ceny są negocjowane, struktura klientów jest drzewem, a proces zamówienia ma własne kroki. Wtedy budżet, który w PrestaShopie idzie na zbudowanie B2B z modułów, w Endorze idzie na dopasowanie gotowego B2B do Twojego procesu. Jeśli masz działający sklep na PrestaShopie i wykonawcę, który go zna, migracja bez policzonego powodu to zła inwestycja.

Czym właściwie jest każda z tych platform

PrestaShop

PrestaShop to aplikacja PHP na bazie MySQL lub MariaDB, rozwijana od 2007 roku, dostępna na otwartej licencji. PrestaShop 9, wydany w czerwcu 2025, to obecnie najnowsze duże wydanie. Całe zaplecze administracyjne zostało przeniesione na Symfony 6.4 LTS. Doszło Admin API z uwierzytelnianiem OAuth, architektura CQRS w warstwie backendu i nowy domyślny motyw Hummingbird oparty na Bootstrapie 5, z natywną obsługą WebP i AVIF. Wymagania to PHP od 8.1 do 8.4 oraz MySQL od 5.7 (rekomendowane 8.0+) albo MariaDB od 10.4. Wydanie 9.1 z kwietnia 2026 dołożyło zgodność z PHP 8.5, uproszczenie zarządzania rabatami i poprawki bezpieczeństwa. Benchmarki dostawców pokazują dla dziewiątki około 28-29% szybsze ładowanie stron i o 21% niższe szczytowe zużycie pamięci względem PrestaShop 8, w dużej mierze dzięki nowszemu PHP.

W warstwie B2B PrestaShop daje natywnie mniej, niż sugeruje wielkość ekosystemu. Tryb B2B włącza się przełącznikiem w ustawieniach klientów. Do karty klienta dokłada pola: firma, francuskie odpowiedniki NIP-u i kodu PKD (SIRET i APE), strona WWW, autoryzowany limit zadłużenia, maksymalna liczba dni płatności i ocena ryzyka, plus osobną listę zaległości. Do tego dochodzą grupy klientów (każda z własnym mnożnikiem cenowym, widocznością cen i dostępem do kategorii) oraz tabela cen specjalnych, w której da się zdefiniować cenę dla pojedynczego klienta, produktu, waluty czy kraju. To realny zestaw i dla wielu hurtowni w zupełności wystarczający.

Czego w tym zestawie nie ma: zapytań ofertowych i negocjacji ceny, katalogu zależnego od roli w firmie kupującej, hierarchii oddziałów z dziedziczeniem warunków, akceptacji zamówienia po stronie kupującego, jednostek opakowaniowych z przeliczaniem. To wszystko realizuje się modułami z Addons albo pisze na zamówienie.

Endora Commerce

Endora Commerce to platforma B2B napisana w TypeScripcie: backend na Fastify z MikroORM i kontraktami Zod, storefront w Next.js renderowany po stronie serwera, panel administracyjny w React. Dane w PostgreSQL, cache i kolejki w Redisie z BullMQ, wyszukiwarka Meilisearch. Ponad 60 modułów w standardzie: od katalogu i cenników po KSeF, feedy produktowe i asystenta AI w panelu.

Nie jest to platforma wyłącznie B2B. Sprzedaż B2C działa na tej samej instalacji i tym samym modelu danych: rejestracja klienta indywidualnego zakłada w tle jednoosobową organizację, więc zamówienia, zapytania ofertowe, faktury i adresy idą dokładnie tą samą ścieżką co w B2B. Nie ma równoległego, uproszczonego trybu, który po pół roku zaczyna się rozjeżdżać z resztą. B2C włącza się osobno dla każdego kanału sprzedaży.

Model dostarczania jest podobny do PrestaShopa w jednej ważnej rzeczy: kod jest Twój. We wszystkim pozostałym jest inny. Nie pobierasz paczki i nie instalujesz jej sam: dostajesz platformę wdrożoną pod Twoje procesy, z kodem w Twoim repozytorium Git i danymi w Twojej bazie. Pierwszy działający prototyp powstaje w cztery tygodnie, a średnie wdrożenie mieści się orientacyjnie w widełkach 60-80 tys. zł, bez integracji z systemami zewnętrznymi, które wycenia się osobno.

Wydajność

Tę rozmowę trzeba rozbić na dwa pytania, bo odpowiedzi są różne.

Katalog anonimowy

Tu PrestaShop po dostrojeniu jest szybki i nie ma sensu udawać inaczej. Dziewiątka przyspieszyła względem ósemki, motyw Hummingbird serwuje obrazy w WebP i AVIF, a jQuery ładuje się z opóźnieniem. Warstwę cache’u da się dołożyć na kilku poziomach: cache Smarty, cache obiektowy w Redisie i pełnostronicowy Varnish przed aplikacją. Publiczny katalog z cenami widocznymi dla wszystkich to scenariusz, w którym PrestaShop pracuje od kilkunastu lat i ma dla niego dopracowane playbooki optymalizacji.

Endora renderuje storefront serwerowo w Next.js, z celami Core Web Vitals wpisanymi wprost w wymagania platformy (LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1) i wyszukiwaniem poniżej 200 ms w percentylu 95. Demo chodzi na katalogu powyżej 120 tys. SKU, a generowanie feedu produktowego dla 100 000 produktów daje plik 38 MB przy szczytowym zużyciu pamięci poniżej 20 MB, bo serializacja jest strumieniowa.

Katalog z cenami zależnymi od klienta

I tu obraz się komplikuje, a to jest właśnie codzienność B2B.

W PrestaShopie ceny indywidualne żyją w tabeli cen specjalnych, w której jeden wiersz opisuje kombinację produktu, wariantu, sklepu, waluty, kraju, grupy i klienta. Przy kilkuset firmach z własnymi warunkami i katalogu liczonym w dziesiątkach tysięcy pozycji ta tabela potrafi urosnąć do rozmiarów, w których zaczyna być wąskim gardłem. To problem opisywany na forach PrestaShopa od lat, wracający przy każdej większej hurtowni.

Dochodzi do tego druga rzecz: pełnostronicowy cache trzeba różnicować po grupie klienta, więc im więcej grup z własnymi cenami, tym więcej wariantów tej samej strony i tym częściej trafiasz w wariant zimny. Osobny wątek to zaplecze. Siatka produktów w panelu przy katalogu rzędu stu tysięcy pozycji potrafi być bolesna, bo zapytania listujące korzystają z konstrukcji SQL_CALC_FOUND_ROWS, uznanej w MySQL 8.0.17 za przestarzałą i skrajnie nieefektywnej na dużych zbiorach.

Da się to obejść i firmy to robią: mocniejszy sprzęt, strojony MySQL, Redis, Varnish, wyszukiwarka w Elasticsearch. Praktyczna granica dla dobrze utrzymanego PrestaShopa to katalogi rzędu 50-200 tys. produktów przy 4-8 vCPU i 16-32 GB RAM. To jest osiągalne, ale jest efektem pracy optymalizacyjnej, a nie stanem po instalacji.

Endora nie ma tego problemu strukturalnie, bo nie opiera swojej wydajności na cache’u pełnostronicowym. Cena jest rozstrzygana przez silnik cen przy każdym żądaniu: z cennika grupy, kontraktu indywidualnego, progu ilościowego i okna czasowego, z deterministycznym rozstrzyganiem nakładających się reguł. Reguły opisuje się budowniczym warunków po kanale, grupie, organizacji, kategorii i walucie, z operatorami AND i OR do głębokości pięciu poziomów. Wycena pobrana przez API przechodzi przez ten sam silnik co koszyk, więc zgodność jest co do grosza. Personalizacja nie jest tu wyjątkiem od optymalizacji, tylko przypadkiem podstawowym.

Sprzęt potrzebny, żeby to utrzymać

Zastrzeżenie: PrestaShop ma za sobą kilkanaście lat wdrożeń i bardzo dobrze rozpoznane wąskie gardła. Na każdy problem wydajnościowy znajdziesz opis, patch i konsultanta, który już to naprawiał. Liczby Endory to cele architektoniczne potwierdzone testami i skalą demo, a nie dekada produkcyjnych sezonów szczytowych.

Koszt wdrożenia i utrzymania

Policzmy to na konkretnym przypadku

Hurtownia z 300 klientami firmowymi, katalogiem rzędu 40 tys. pozycji, indywidualnymi cennikami, zapytaniami ofertowymi i integracją z Comarch ERP Optima. Horyzont: trzy lata. Kwoty netto, kurs przyjęty do przeliczeń: 1 EUR = 4,30 zł.

Różnica wychodzi na około 38 tys. zł w trzyletnim horyzoncie. I teraz najważniejsze zdanie tej sekcji: to nie jest różnica, na podstawie której warto podjąć decyzję. Opublikowane widełki dla polskich wdrożeń B2B na PrestaShopie to 50-130 tys. zł, co znaczy, że ten sam projekt u innego wykonawcy może wyjść 60 tys. albo 120 tys. Trzydzieści osiem tysięcy mieści się w niepewności każdej z tych wycen. Wniosek nie brzmi „Endora jest tańsza”. Brzmi tak: przy tym samym zakresie B2B obie platformy są w tej samej półce budżetowej, więc pytanie przestaje dotyczyć ceny, a zaczyna dotyczyć tego, co za te pieniądze dostajesz.

A dostajesz co innego. W PrestaShopie znacząca część budżetu idzie na zbudowanie B2B na silniku detalicznym: reguły cenowe zależne od roli, moduł zapytań ofertowych, obejście na hierarchię oddziałów, moduł na limit kupiecki liczony inaczej niż zaległość z trybu B2B. W Endorze te rzeczy są w rdzeniu, więc budżet idzie na dopasowanie gotowego B2B do Twojego procesu i na integracje. Druga różnica to rozkład kosztu w czasie: pozycje „odnowienia licencji”, „utrzymanie zgodności modułów” i „duża aktualizacja” w PrestaShopie wracają cyklicznie i rosną z liczbą modułów, których używasz.

Zastrzeżenie po drugiej stronie: dla prostego sklepu ta kalkulacja wygląda zupełnie inaczej i wypada zdecydowanie na korzyść PrestaShopa. Sklep detaliczny z gotowym motywem i kilkoma modułami uruchomisz za kilka do kilkunastu tysięcy złotych, na współdzielonym hostingu, w kilka tygodni. Endora nie ma takiego wariantu. Dolna granica to projekt wdrożeniowy.

Łatwość rozwijania platformy

To kryterium najlepiej sprawdzić na konkretnych zadaniach, a nie na deklaracjach.

Osobnego akapitu wymagają aktualizacje między dużymi wersjami, bo to najbardziej niedoszacowana pozycja w budżecie utrzymania PrestaShopa. Przejście z ósemki na dziewiątkę nie jest podbiciem numerka. Zaplecze przeszło na Symfony 6.4, część kontrolerów administracyjnych została przepisana, a szablony zaplecza przeniesiono ze Smarty na Twiga. Część hooków związanych z cyklem życia kontrolerów przestała być wywoływana, a z rdzenia wypadły biblioteki, na których stały moduły: Guzzle, SwiftMailer, Tactician i pear/archive_tar. Każdy moduł nadpisujący stary kontroler administracyjny po prostu przestaje działać.

Oficjalne szacunki i praktyka wykonawców zgadzają się co do rzędu wielkości: prosty sklep to 3-5 dni, rozbudowany 1-3 miesiące, a migracja pojedynczego własnego modułu z PS8 na PS9 to zwykle 2-5 dni pracy. Ze starych wersji nie migruje się wprost. Ścieżka prowadzi przez 1.7, potem 8, dopiero potem 9.

To nie jest argument przeciw PrestaShopowi, tylko pozycja, którą trzeba wpisać do budżetu. Ryzyko jest wprost proporcjonalne do liczby modułów od zewnętrznych dostawców. Przy trzech wtyczkach to formalność. Przy piętnastu to już projekt, w którym trzeba się dowiedzieć, czy każdy z piętnastu dostawców wydał wersję zgodną z nową dziewiątką i co zrobić z tymi, którzy nie wydali.

Warto też powiedzieć wprost o jakości modułów. Rynek jest ogromny i to jest jego największa zaleta, ale rozrzut jakościowy jest równie duży. Obok modułów utrzymywanych latami, z dokumentacją i wsparciem, są takie, które ostatnią aktualizację dostały przy PrestaShop 1.7. Nic w tym nadzwyczajnego, bo tak wygląda każdy duży marketplace. W praktyce oznacza to jednak, że wybór modułu jest decyzją architektoniczną, a nie zakupem. Warto sprawdzać datę ostatniej aktualizacji, deklarowaną zgodność z 9.x i to, czy dostawca ma historię wydawania wersji przy poprzednich dużych aktualizacjach.

Po stronie PrestaShopa jest za to przewaga, której nie da się podważyć: rynek wykonawców. Programistów PHP i Symfony zatrudnisz albo wynajmiesz w każdym większym mieście, agencji PrestaShopowych w Polsce są dziesiątki, a zmiana partnera to przetarg, a nie przepisywanie platformy. Endora daje Ci kod na własność, ale zespołu, który zna tę platformę od środka, nie znajdziesz w pierwszym ogłoszeniu. Łagodzi to fakt, że kod jest zwykłym TypeScriptem z kontraktami Zod i wygenerowaną dokumentacją, a nie autorskim frameworkiem, ale nie znosi tego całkowicie.

Jedna rzecz działa tylko w jedną stronę: w panelu Endory jest asystent AI. Otwierasz paletę poleceń, opisujesz po polsku, co ma się stać, asystent pokazuje plan i wykonuje go po Twoim potwierdzeniu, w granicach Twoich uprawnień i z wpisem w dzienniku audytu.

Za tym stoi konkret, bo „szybko” samo w sobie nic nie znaczy: mniej złożony moduł powstaje w Endorze w 1-3 dni, większy do tygodnia. Nie dotyczy to integracji z ERP, WMS, CRM, PIM czy OMS: te są zawsze mocno indywidualne, a napisanie takiej integracji zajmuje do dwóch tygodni. Te są zawsze mocno indywidualne i potrafią zająć znacznie dłużej. To nie jest przewaga nad otwartym kodem jako takim, bo tam też możesz dopisać, co zechcesz. To przewaga punktu startu: dokładasz moduł do działającej platformy B2B, zamiast najpierw zbudować to, co ma być rozszerzane.

Integracje z systemami zewnętrznymi

W B2B to zwykle kryterium rozstrzygające, bo platforma prawie nigdy nie jest źródłem prawdy. Jest nim ERP, a obok niego CRM, WMS i coraz częściej OMS.

Gdzie wygrywa PrestaShop

Polski ekosystem integracji. To jest najmocniejsza karta PrestaShopa i trzeba ją postawić na stole pierwszą. Allegro, Ceneo, BaseLinker, InPost, DPD, DHL, GLS, Paczkomaty, Przelewy24, PayU, tpay, integracje z Subiektem GT i Nexo, Comarch ERP Optima, WAPRO Mag, Symfonia. Dla każdego z tych systemów istnieje więcej niż jeden gotowy konektor, często od kilku konkurujących dostawców, z polskim wsparciem i fakturą VAT. Do tego dochodzą platformy pośredniczące pokrywające dziesiątki systemów naraz. Jeśli Twoja lista systemów mieści się w tym zestawie, w PrestaShopie realnie kupujesz integrację zamiast ją zamawiać, a wdrożenie liczysz w dniach.

Druga przewaga to liczba osób, które już to robiły. Integracja PrestaShopa z Optimą została zrobiona setki razy i ktoś, kto ją dla Ciebie skonfiguruje, prawdopodobnie zna wszystkie pułapki, zanim je napotkacie.

Gdzie wygrywa Endora

Krótsza lista gotowców, ale mocniejszy kontrakt i ważne rzeczy natywnie.

Najważniejsze jest to, że lista nie jest zamknięta i nie musi być. Warstwa integracyjna Endory jest ogólna: nie ma listy „obsługiwanych ERP-ów”, jest opisany kontrakt: API partnerskie, podpisane webhooki i szyfrowane konfiguracje dostawców. Dzięki temu dowolny ERP, CRM, WMS czy OMS podłącza się jako moduł-adapter, niezależnie od tego, czy to Comarch, SAP, IFS, autorski system napisany w firmie dwadzieścia lat temu, czy platforma, o której nikt jeszcze nie słyszał. Adapter rejestruje się w platformie, dostaje własne ustawienia i uprawnienia, a rdzeń zostaje bez zmian.

Konkrety, na których stoi ta warstwa:

• Comarch ERP Optima i Subiekt GT. Adaptery w standardzie: kartoteki, stany, ceny i dokumenty sprzedaży.
• KSeF w rdzeniu platformy. Faktury i korekty w formacie FA(3), obowiązującym od 1 lutego 2026, wysyłane trwałą kolejką, numer KSeF na dokumencie, UPO do pobrania i kod QR weryfikacyjny na PDF. PrestaShop nie ma KSeF w rdzeniu: wbudowany moduł faktur nie obsługuje polskiego e-fakturowania, więc idzie się przez moduł integrujący z zewnętrznym systemem fakturowym albo przez dedykowaną usługę. W obu wariantach dochodzi kolejny abonament i kolejny punkt awarii.
• API partnerskie z żywym OpenAPI. Dokument generowany z kontraktów w kodzie, więc integrator nie pracuje na nieaktualnym PDF-ie.
• Klucz API przypięty do organizacji i kanału. Integracja widzi ceny i limity dokładnie tej firmy i nie może więcej niż jej własny kupujący. Nie ma parametru omijającego reguły.
• Zamówienia idempotentne. Powtórzone żądanie zwraca to samo zamówienie, nigdy drugie. Dotyczy też równoległych powtórzeń.
• Webhooki podpisane HMAC-SHA-256, do ośmiu prób z rosnącym odstępem, osobny widok nieudanych doręczeń z ręcznym ponowieniem.
• Wycena hurtowa. Jedno żądanie wycenia do 200 pozycji dla konkretnej organizacji, z gwarancją zgodności z koszykiem co do grosza.
• Poświadczenia szyfrowane AES-256-GCM, testowane przy zapisie, maskowane przy odczycie i redagowane w dzienniku audytu.

Różnica w filozofii jest taka: w PrestaShopie częściej kupujesz integrację, w Endorze częściej ją piszesz. Piszesz ją jednak jako moduł-adapter, we własnym repozytorium i bez ryzyka, że kolejna duża wersja platformy rozjedzie się z cudzą wtyczką. Jeśli Twój ERP jest popularny, przewaga jest po stronie PrestaShopa i jest wyraźna. Jeśli jest autorski, leciwy albo mocno zmodyfikowany (a tak bywa w polskich firmach produkcyjnych), przewaga przesuwa się na stronę Endory, bo i tak piszesz kod, tylko w czystszym miejscu.

Jest jeszcze różnica, którą widać dopiero w B2B: kontrakt integracyjny Endory zna pojęcie organizacji. Klucz API przypięty do firmy widzi jej cennik, jej limit kupiecki i jej asortyment. Portal zamówieniowy dystrybutora albo integracja z systemem klienta działa więc dokładnie na tych samych warunkach co jego kupujący, bez budowania osobnej logiki uprawnień po stronie integratora.

B2B: gdzie Endora Commerce faktycznie się wyróżnia

Zacznę od tego, co PrestaShop w B2B naprawdę potrafi, bo lista jest dłuższa, niż sądzi większość osób oceniających go z zewnątrz. Natywnie dostajesz tryb B2B z polami firmowymi na karcie klienta, autoryzowanym limitem zadłużenia, maksymalną liczbą dni płatności, oceną ryzyka i listą zaległości. Do tego grupy klientów z własnym mnożnikiem cenowym, przełącznikiem widoczności cen i kontrolą dostępu do kategorii. Dalej ceny specjalne definiowane aż do poziomu pojedynczego klienta i produktu, z rabatami progowymi, ukrywanie cen przed niezalogowanymi oraz osobne metody płatności i dostawy per grupa. Modułami z Addons dokłada się resztę: zapytania ofertowe z kontrofertą, rejestrację firmy z akceptacją przez handlowca, katalog zależny od roli, listy zakupowe, szybkie zamawianie. Dla hurtowni, która sprzedaje z cennika stałym klientom, to jest komplet.

Różnica pojawia się tam, gdzie sprzedaż przestaje być odmianą detalu. I nie polega na długości listy funkcji, tylko na tym, czy dana rzecz jest modelem, czy nadbudową.

1. Zapytania ofertowe jako pełna pętla negocjacji w rdzeniu. W PrestaShopie RFQ to moduł. Działa, ale żyje obok modelu zamówienia i zwykle kończy się na „klient pyta, handlowiec odpowiada, ktoś przepisuje pozycje do zamówienia”. W Endorze to rdzeń: klient składa zapytanie, handlowiec wycenia z terminem realizacji i ważnością oferty, obie strony mogą modyfikować warunki, a zaakceptowana oferta zamienia się w zamówienie bez przepisywania pozycji. Do tego dochodzi tryb wyświetlania cen none, który ukrywa wszystkie elementy cenowe i kieruje intencję zakupową do zapytania ofertowego. To rozwiązanie dla asortymentu, którego z zasady nie sprzedaje się z cennika.

2. Hierarchia organizacji z dziedziczeniem warunków handlowych. PrestaShop modeluje klienta firmowego jako konto z polami firmowymi i przypisaną grupą. To struktura płaska: nie ma drzewa, po którym spływałyby warunki. W Endorze centrala i oddziały tworzą drzewo: widoczność zamówień spływa w dół, a cennik i limit kupiecki dziedziczą się z najbliższego przodka. Firma z dwudziestoma oddziałami nie wymaga dwudziestu równoległych konfiguracji ani dwudziestu grup klientów.

3. Limit kupiecki, a nie zaległość liczona po fakcie. Autoryzowany limit zadłużenia w PrestaShopie to wartość na karcie klienta i raport zaległości. To informacja, nie mechanizm. Endora rezerwuje limit atomowo w chwili składania zamówienia i zwalnia go po opłaceniu faktury albo anulowaniu, a po wyczerpaniu limitu filtruje dostępne metody płatności. To różnica między wiedzą o ryzyku a kontrolą ryzyka.

4. Własny cykl życia zamówienia i pola wynikające z umów. Statusy w PrestaShopie dodasz w panelu, ale logika przejść i zdarzeń biznesowych to moduł. W Endorze statusy, przejścia i podpięte do nich zdarzenia konfigurujesz w panelu, a pola dodatkowe dokładasz do zamówień, organizacji, klientów, kategorii, produktów i zapytań ofertowych jako dane, bez migracji bazy i bez wdrożenia kodu.

5. Kanał sprzedaży jako pełnoprawny wymiar. Storefront, marketplace, portal dystrybutora, aplikacja mobilna i POS to osobne kanały tej samej instalacji, z osobnymi produktami, cenami, promocjami, treściami, ustawieniami, analityką i indeksem wyszukiwarki. Odpowiednikiem w PrestaShopie jest multistore. Działa, ale jest funkcją sklepową, a nie wymiarem modelu danych, i przy rozjeżdżających się asortymentach szybko zaczyna wymagać osobnego utrzymania.

6. Realia zamówień hurtowych obsłużone wprost. Jednostki opakowaniowe z przeliczaniem sztuk przenoszonym do zamówienia i oferty. Akceptacja koszyka włączana per organizacja, z decyzją i uzasadnieniem. Import koszyka z CSV albo Excela, wyszukiwanie po SKU i atrybutach, zakup jednym kliknięciem dla klientów z kompletem domyślnych preferencji. Listy zakupowe, porównywarka z eksportem PDF, zwroty i reklamacje z numeracją RMA i fakturami korygującymi, wielomagazynowość z rezerwacjami i backorderem.

Do tego dochodzi rzecz, której nie widać na liście funkcji: każda wrażliwa operacja trafia do dziennika audytu ze stanem przed zmianą i po zmianie. Uprawnienia sprawdzane są po stronie serwera, a handlowiec może wejść w kontekst klienta i zobaczyć jego ceny tak, jak widzi je klient, z widocznym banerem i wpisem w dzienniku.

Gdzie PrestaShop ma przewagę w samym B2B: w tym, jak szybko można zacząć. Tryb B2B włącza się jednym przełącznikiem, grupy klientów z własnymi cenami skonfigurujesz w godzinę, a moduł zapytań ofertowych z Addons kupisz za kilkaset euro i uruchomisz tego samego dnia. Jeśli Twój B2B naprawdę mieści się w zdaniu „stali klienci kupują po swoich cenach i płacą przelewem z odroczeniem”, PrestaShop obsłuży to szybciej i taniej niż jakiekolwiek wdrożenie szyte na miarę. Do tego dochodzi możliwość stopniowego dokładania funkcji: kupujesz moduł, sprawdzasz, odinstalowujesz, jeśli nie pasuje. W modelu wdrożeniowym takiej ścieżki nie ma.

Kiedy PrestaShop będzie lepszym wyborem

1. Masz już działający sklep na PrestaShopie i wykonawcę, który go zna. Replatforming bez policzonego powodu biznesowego to jeden z najdroższych sposobów na nic. Jeśli problemy da się rozwiązać optymalizacją, aktualizacją do dziewiątki albo jednym modułem, zostań.

2. Twój B2B to hurt z cennika. Stali klienci, przypisane grupy i ceny, odroczone płatności, powtarzalne zamówienia, bez negocjacji. Tryb B2B i grupy klientów pokrywają to natywnie.

3. Detal jest równie ważny albo ważniejszy niż hurt. Publiczny katalog, ceny widoczne dla wszystkich, kampanie, sezonowe piki. To środowisko, dla którego PrestaShop był projektowany, z gotową obsługą Allegro, Ceneo i porównywarek.

4. Twoja lista integracji pokrywa się z polskim standardem. Optima albo Subiekt, InPost i kurierzy, Allegro, BaseLinker, popularna bramka. Kupienie pięciu gotowych konektorów jest szybsze i tańsze niż zamówienie pięciu adapterów, a wykonawcę znajdziesz od ręki.

5. Budżet startowy jest mały i musi zostać mały. Sklep na gotowym motywie z kilkoma modułami uruchomisz za kilka do kilkunastu tysięcy złotych. Endora nie ma odpowiednika tego wariantu.

6. Chcesz mieć łatwo wymienialnego dostawcę. Rynek agencji PrestaShopowych w Polsce jest głęboki. Zmiana partnera to przetarg, a nie przepisywanie platformy. To samo dotyczy zatrudnienia programisty do zespołu.

7. Chcesz dokładać funkcje po jednej i sprawdzać, czy się przydają. Model modułowy pozwala kupić, przetestować i zrezygnować. Wdrożenie szyte na miarę wymaga podjęcia decyzji wcześniej.

Kiedy Endora Commerce będzie lepszym wyborem

1. Sprzedaż idzie przez negocjację, nie przez koszyk. Zapytania ofertowe są główną ścieżką, część asortymentu w ogóle nie ma pokazywanej ceny, a oferta bywa modyfikowana przez obie strony przed akceptacją.

2. Struktura klientów jest drzewem. Grupy kapitałowe, centrale z oddziałami, dziedziczenie cennika i limitu z najbliższego przodka, widoczność zamówień w dół struktury. Odwzorowanie tego grupami klientów kończy się mnożeniem konfiguracji.

3. Limit kupiecki musi realnie blokować, a nie tylko informować. Rezerwacja limitu w chwili składania zamówienia, zwolnienie po opłaceniu faktury, filtrowanie metod płatności po wyczerpaniu limitu.

4. Proces zamówienia ma własne kroki. Weryfikacja techniczna, akceptacja u kupującego, produkcja, kompletacja, częściowe wydania. Do tego zdarzenia biznesowe wpięte w przejścia, konfigurowane w panelu zamiast zamawiane u dostawcy.

5. Twoje reguły cenowe są nietypowe. Cenniki grup, kontrakty indywidualne, progi ilościowe, okna czasowe i warunki po kanale, organizacji, kategorii i walucie z operatorami AND i OR. Do tego deterministyczne rozstrzyganie, gdy reguły się nakładają.

6. Uruchamiasz portal dystrybutora albo kilka kanałów naraz. Osobny asortyment, ceny, treści i indeks wyszukiwarki dla każdego kanału z jednego panelu, plus klucz API przypięty do organizacji i kanału dla ruchu integracji.

7. Masz system, którego nikt nie wspiera „z półki”. Autorski ERP, leciwy WMS, OMS złożony z kilku narzędzi. Warstwa integracyjna Endory nie zakłada, że po drugiej stronie stoi konkretny produkt. Adapter piszesz raz, we własnym repozytorium.

8. KSeF ma być częścią platformy, a nie kolejnym abonamentem. Faktury i korekty w formacie FA(3) wysyłane z platformy, numer KSeF na dokumencie, UPO i kod QR na PDF, bez pośredniczącego systemu fakturowego.

9. Chcesz zweryfikować pomysł, zanim podpiszesz duży budżet. Warsztat i klikalny prototyp na Twoich danych po czterech tygodniach, potem wspólna decyzja o pełnym wdrożeniu.

Czego Endora Commerce nie ma

Ta sekcja jest w tekście po to, żeby dało się na jego podstawie podjąć decyzję, a nie tylko poczuć się przekonanym.

• Marketplace’u rozszerzeń. Nie kupisz gotowej wtyczki za 300 euro, nie przetestujesz jej przez weekend i nie odinstalujesz, jeśli nie pasuje. Każda nietypowa funkcja to praca programistyczna.
• Głębokiego rynku specjalistów. PrestaShop ma w Polsce dziesiątki agencji i szeroki rynek programistów PHP. Endorę rozwija się z partnerem albo własnym zespołem TypeScript, który musi wejść w platformę.
• Kilkunastu lat referencji. PrestaShop przeszedł przez tysiące wdrożeń i wszystkie ich patologie. Liczby Endory to cele architektoniczne potwierdzone testami i skalą demo.
• Wariantu „mały sklep za kilka tysięcy”. Dolna granica to projekt wdrożeniowy. Jeśli szukasz sklepu na gotowym motywie za kilkanaście tysięcy złotych, to nie jest ta oferta.
• Pełnych integracji API z marketplace’ami. Allegro, Amazon i eBay są dziś obsługiwane szablonami feedów, a nie dwukierunkową integracją z API marketplace’u. PrestaShop ma tu gotowe moduły i jest to realna przewaga.
• Utrzymania wliczonego w jedną cenę. Ktoś musi utrzymać serwer, kopie zapasowe i aktualizacje. To zresztą dotyczy obu platform, ale w PrestaShopie łatwiej kupić to jako usługę hostingową. Możesz je prowadzić samodzielnie albo zlecić nam lub firmie partnerskiej w ramach umowy SLA.

Krótka lista kontrolna

Odpowiedz sobie na te pytania. Odpowiedzi zwykle układają się w jedną stronę.

1. Czy Twoi klienci pytają o cenę przed zamówieniem, czy kupują po cenach, które już mają przypisane?
2. Czy struktura Twoich klientów jest płaska, czy ma centrale i oddziały dziedziczące warunki?
3. Czy limit kupiecki ma blokować zamówienie, czy wystarczy, że będzie widoczny w raporcie?
4. Ile z Twoich systemów ma gotowy moduł do PrestaShopa, a ile trzeba by napisać w każdym scenariuszu?
5. Ile modułów od zewnętrznych dostawców jesteś gotów utrzymywać przy każdej dużej aktualizacji?
6. Czy proces zamówienia ma kroki, których nie da się nazwać „opłacone” i „wysłane”?
7. Jaki masz budżet startowy: kilkanaście tysięcy złotych czy kilkadziesiąt?
8. Czy KSeF ma być w platformie, czy może być w zewnętrznym systemie fakturowym?

Przewaga odpowiedzi „sprzedaż z cennika”, „płaska struktura klientów”, „popularne integracje”, „mały budżet startowy”, „chcemy wykonawcę z rynku” wskazuje na PrestaShopa. Przewaga odpowiedzi „negocjujemy ceny”, „oddziały i dziedziczenie warunków”, „limit musi blokować”, „nietypowy proces zamówienia”, „autorski ERP” wskazuje na Endorę. Jeśli odpowiedzi rozkładają się po równo, decydująca będzie prawdopodobnie liczba modułów, które musiałbyś kupić i utrzymywać, żeby PrestaShop robił to, czego potrzebujesz.

Podsumowanie

PrestaShop i Endora Commerce mają wspólny fundament: otwarty kod, który zostaje u Ciebie, i brak opłat od obrotu. Rozchodzą się w tym, od czego zaczynają. PrestaShop daje Ci dojrzały silnik sklepu z ogromnym ekosystemem, najsilniejszym w Polsce zestawem gotowych integracji i wykonawcą dostępnym od ręki. Sprzedaż firma-firma budujesz na nim z trybu B2B, grup klientów i modułów, płacąc za to złożonością utrzymania i kosztem każdej dużej aktualizacji. Endora daje Ci platformę zaprojektowaną wokół sprzedaży firma-firma, z zapytaniami ofertowymi, hierarchią organizacji, limitami kupieckimi i konfigurowalnym cyklem życia zamówienia w rdzeniu. Płacisz za to młodością platformy, węższym rynkiem specjalistów i brakiem wariantu „mały sklep za kilka tysięcy”.

Najprostszy test: jeśli Twój B2B da się opisać jako „hurt z cennika”, PrestaShop obsłuży to szybciej i taniej. Jeśli w opisie pojawia się „negocjujemy”, „oddziały mają własne warunki” albo „u nas zamówienie przechodzi przez”, warto policzyć drugą opcję, bo przy tym zakresie budżety są porównywalne, a różnica sprowadza się do tego, ile z Twojego procesu jest w platformie, a ile trzeba dokupić.

Panel i storefront Endory działają online, więc najszybszą drogą jest przeklikać demo samodzielnie albo umówić bezpłatny warsztat, na którym przejdziemy przez Twoje procesy i systemy, a potem wycenimy zakres pierwszego wdrożenia razem z integracjami.

A jeśli z rozmowy wyjdzie, że lepszym wyborem jest PrestaShop, powiemy to wprost. Nieudane wdrożenie nie jest dobrą referencją dla nikogo.