VTEX vs commercetools vs Spryker: porównanie platform B2B commerce

TL;DR, która platforma pasuje do którego scenariusza B2B

Wybór nieodpowiedniej platformy B2B commerce rzadko ujawnia się w dniu go-live. Wychodzi na jaw pół roku później, gdy hierarchia organizacyjna nie przystaje do tego, jak naprawdę działa dział zakupów, proces wyceny wymaga trzech obejść, albo Twój zespół deweloperów wciąż buduje portal kupującego, który w prezentacji sprzedawcy wyglądał jak funkcja gotowa do użycia.

Nasz zespół prowadził wdrożenia VTEX B2B Suite, projektował hierarchie Business Unit w commercetools dla klientów wielooddziałowych oraz integrował protokół punchout w Sprykerze, poniższe różnice wynikają z decyzji projektowych, nie z folderów sprzedażowych.

Jeśli Twoje wymagania B2B wpisują się w typowy schemat, hierarchie kont, cenniki kontraktowe, łańcuchy zatwierdzeń, adresy dostaw przypisane do cost centers, VTEX B2B Suite dostarcza to natywnie i szybciej doprowadzi Cię do działającego środowiska. Jeśli Twój model organizacyjny jest naprawdę niestandardowy, commercetools daje swobodę modelu danych niezbędną do jego odwzorowania, kosztem większej ilości pracy po Twojej stronie. Spryker wygrywa głębokością procesu quote-to-cash; odpowiednio zaplanuj harmonogram wdrożenia.

Dalsza część artykułu omawia, gdzie model każdej platformy przestaje działać pod wpływem rzeczywistych struktur organizacji zakupowych, ile kosztuje utrzymanie każdej z nich w skali oraz które scenariusze pozostają naprawdę niejednoznaczne.

Porównanie trzech platform, szybki przegląd

Wszystkie trzy to platformy e-commerce klasy enterprise stworzone z myślą o B2B, ale ich filozofie architektury, modele cenowe i głębokość natywnych funkcji B2B różnią się na tyle, że wybranie złego dopasowania może kosztować kilka miesięcy dodatkowej pracy deweloperskiej.

Pełne zrozumienie struktury kosztów, nie tylko opłat licencyjnych lub SaaS, odróżnia dobrze skalkulowany model TCO od budżetu, który eksploduje w drugim roku.

Zestawienie kosztów wdrożenia dla porównania TCO

Wdrożenia B2B w segmencie enterprise na wszystkich trzech platformach kosztują rocznie wyraźnie powyżej sześciu cyfr, jeszcze bez kosztów wdrożenia. Opłaty platformowe to tylko część całości: integracja systemów, bieżące zasoby inżynieryjne i budowa omnichannel frontendu znacząco powiększają tę kwotę, a proporcje różnią się wyraźnie w zależności od wyboru architektury.

Model cenowy oparty na GMV, stosowany w kontraktach VTEX enterprise, premiuje wzorzec zamówień B2B o niskim wolumenie i wysokiej wartości. Zamówienie o wartości 2 mln USD realizowane raz w tygodniu generuje taki sam GMV, a co za tym idzie, zbliżoną opłatę platformową, jak setki małych transakcji konsumenckich sumujących się do tej wartości, lecz przy wielokrotnie niższym narzucie transakcyjnym na każdego dolara przychodu. Dla firm, których podstawowy profil B2B to rzadkie, wysokowartościowe zakupy, to istotna strukturalna przewaga. commercetools odwraca tę logikę: intensywne przeglądanie katalogu, szkice wycen i wywołania API katalogu generują koszty niezależnie od konwersji, organizacje z dużymi portalami kupującego i wieloma aktywnymi pracownikami przeglądającymi ofertę przed podpisaniem zamówienia powinny dokładnie zamodelować wolumen wywołań API przed podjęciem decyzji. Model licencyjny Spryker eliminuje ryzyko wolumenowe, ale z góry obciąża kosztami bez względu na przepustowość, co sprzyja organizacjom z przewidywalnym, wysokim GMV, a nie tym, które dopiero skalują kanał B2B.

Porównując Spryker i VTEX pod kątem całkowitego kosztu, wdrożenie Spryker zazwyczaj wymaga większych zasobów wewnętrznych lub partnerskich niż porównywalny rollout enterprise VTEX, choć gotowe moduły Spryker częściowo niwelują tę różnicę w stosunku do w pełni niestandardowej budowy na commercetools.

Ogólną architekturę VTEX poza specyfiką B2B omówiliśmy w naszym przewodniku po platformie VTEX. Szersze spojrzenie na rynek headless commerce znajdziesz w naszym porównaniu platform headless commerce.

Jak każda platforma modeluje organizację zakupową B2B

Model danych leżący u podstaw struktury organizacyjnej decyduje o tym, czy wdrożenie obejmujące wiele spółek zależnych zajmie tygodnie konfiguracji czy miesiące budowania rozwiązań na zamówienie.

Płaskie struktury organizacyjne, jedno konto, jedna lista cenowa, jeden adres wysyłki, załamują się w momencie, gdy kupujący ma regionalne zespoły zakupowe, odrębne centra kosztów dla zakupów capex i opex albo spółki zależne, które konsolidują zamówienia na wyższym poziomie, ale potrzebują niezależnych ścieżek zatwierdzania. Wszystkie trzy platformy rozwiązują ten problem, lecz robią to w zasadniczo różny sposób.

VTEX: Organizations, cost centers i trade policies od razu po wdrożeniu

Aplikacja B2B Organizations (część pakietu VTEX B2B Suite) dostarcza hierarchię natywnie: Organization grupuje użytkowników B2B i powiązuje ich z tabelami cenowymi, metodami płatności oraz kolekcjami produktów na poziomie organizacji. Poniżej znajdują się Cost Centers, z których każde posiada własne adresy dostawy, automatycznie dostępne przy kasie bez potrzeby tworzenia niestandardowego middleware.

To właśnie na poziomie Cost Centers zapadają konkretne decyzje wdrożeniowe. Adres dostawy każdego Cost Center pojawia się przy kasie automatycznie, jednak gdy kupujący należy do kilku Cost Centers, VTEX rozwiązuje domyślny adres dostawy według kolejności przypisania do Cost Center, a nie według ostatnio używanego adresu. Jeśli zespół zakupowy klienta oczekuje zapamiętywania adresu między sesjami, konieczne jest stworzenie niestandardowej aplikacji VTEX IO, która nadpisuje logikę rozwiązywania adresów, natywne zachowanie jest deterministyczne, ale nie uwzględnia preferencji użytkownika.

Trade Policies nakładają się na tę strukturę i kontrolują, które tabele cenowe, warunki płatności oraz kolekcje produktów widzi każda Organization. Granular Roles pozwalają określić, kto może przeglądać ceny, składać zamówienia lub uczestniczyć w ścieżce zatwierdzania, wszystko bez ingerencji w dane organizacji w Master Data API v2, chyba że potrzebne są pola niestandardowe. Jedna decyzja konfiguracyjna często zaskakuje zespoły: Trade Policies działają na poziomie Organization, nie na poziomie Cost Center. Gdy jedna Organization ma dwa Cost Centers, jedno dla capex, drugie dla opex, i każde z nich wymaga innych warunków płatności, konieczne jest albo stworzenie dwóch oddzielnych Trade Policies przypisanych do dwóch Organizations, albo niestandardowa logika kasy dzieląca dostępność metod płatności według kontekstu Cost Center. Żadne z tych podejść nie jest nieuzasadnione, ale żadne nie jest też rozwiązaniem zerowej konfiguracji.

Dla CTO oceniającego koszt wdrożenia uczciwe podsumowanie brzmi: rusztowanie jest dostarczone gotowe, konfigurujesz je, a nie budujesz od zera. Ogólny kontekst architektury VTEX znajdziesz w naszym przewodniku po platformie VTEX.

Commercetools: Maksymalna elastyczność, więcej pracy własnej

Business Units w commercetools to podstawowy element struktury: każda z nich modeluje spółkę zależną, dział lub oddział regionalny z własnymi zamówieniami, koszykami i listami zakupów. Pojedyncza konfiguracja BU obsługuje kupującego z sektora MŚP; warstwowa hierarchia korporacyjna z Associates, Granular Roles i Approval Flows obsługuje przedsiębiorstwo wielooddziałowe. Merchant Center umożliwia sprzedawcom konfigurację tej struktury, lub kupującym samodzielną konfigurację przez API.

Kompromis jest realny: commercetools nie dostarcza żadnego interfejsu portalu kupującego. Logika przepływów zatwierdzania jest dostarczana jako prymitywy API, a nie jako gotowy interfejs procesu, Twój zespół samodzielnie pisze ewaluację reguł, hooki powiadomień i maszynę stanów zatwierdzania. To jest charakterystyczna dla commercetools decyzja projektowa: maksymalna kontrola nad modelem danych organizacji, ale cały obszar UX i stojące za nim godziny inżynierskie należą do Ciebie. Zespoły wyceniające ten projekt często go niedoszacowują, bo sam model danych jest przejrzysty i szybki w konfiguracji, podczas gdy warstwa UX jest w całości budowana przez deweloperów, inaczej niż w VTEX, gdzie ścieżki zatwierdzania konfiguruje się, a nie koduje.

Spryker: Natywny B2B, najbardziej rozbudowane narzędzia quote-to-cash, wyższy próg wejścia

Spryker jest najbardziej opiniotwórczy spośród tych trzech platform pod względem struktury organizacyjnej B2B: jego model danych zaprojektowano z myślą o organizacjach zakupowych, a nie dopasowano do rdzenia handlu detalicznego. Katalogi dedykowane klientom, wielopoziomowe ceny kontraktowe, ścieżki zatwierdzania oraz integracja protokołów punchout (OCI i cXML), umożliwiająca bezpośrednie połączenie z systemami zakupowymi klientów, takimi jak Ariba czy Coupa, to możliwości pierwszej klasy, nie dodatki. Moduł Quotation Offer / Offer Management obejmuje natywnie pełny cykl quote-to-cash: przedstawiciele handlowi mogą inicjować ofertę, kierować ją przez konfigurowalne ścieżki zatwierdzania, stosować ceny specyficzne dla klienta i konwertować ją do zamówienia bez opuszczania platformy ani polegania na zewnętrznym narzędziu CPQ.

Udokumentowany punkt tarcia: kilka recenzji platformy Spryker na G2 wskazuje, że interfejs CPQ/quotation może po wstępnej konfiguracji wydłużać czas obsługi pojedynczej oferty w porównaniu z analogicznymi narzędziami (G2 - Spryker Cloud Commerce OS Reviews). Dla zespołów zakupowych przetwarzających dziesiątki niestandardowych ofert dziennie ten problem UX przekłada się bezpośrednio na koszt szkoleń i wskaźnik błędów.

Głęboka funkcjonalność B2B Sprykera ma swoją cenę w postaci wymagań wdrożeniowych: platforma wymaga zazwyczaj wyspecjalizowanego partnera SI i generuje większe uzależnienie od wewnętrznego zespołu niż VTEX czy commercetools. Platforma dostarcza bogatszą strukturę B2B od razu po wdrożeniu, jednak zespoły powinny odpowiednio zaplanować budżet zarówno na fazę budowy, jak i na bieżące utrzymanie platformy.

Macierz build-vs-buy: 6 kluczowych możliwości B2B na tle wszystkich trzech platform

Dla liderów inżynierii wyceniających projekt wdrożenia e-commerce B2B poniższa tabela mapuje sześć możliwości, punchout, przepływy zatwierdzania, ceny kontraktowe, quote-to-cash, segmentacja katalogu oraz synchronizacja z ERP, względem tego, co każda platforma dostarcza natywnie, co wymaga konfiguracji, a co musisz zbudować samodzielnie.

Wzorzec jest spójny: VTEX B2B Suite dostarcza większość strukturalnych funkcji B2B natywnie i wymaga mniejszego nakładu pracy przy konfiguracji, commercetools oferuje maksymalną elastyczność kosztem dłuższego czasu budowy, a Spryker to najbardziej zaawansowana natywnie platforma commerce B2B spośród tych trzech – szczególnie w obszarze quote-to-cash – choć moduł CPQ ma udokumentowaną złożoność UX.

Punchout to jedna funkcja, przy której wszystkie trzy platformy wymagają znaczącej pracy integracyjnej: ani VTEX, ani commercetools nie obsługują go natywnie, a głębokość konektora Spryker zależy od wersji systemu zakupowego, z którym się integrujesz.

TCO i model cenowy: GMV vs. użycie API vs. licencja

Trzy modele cenowe rozchodzą się wyraźnie przy skali transakcji B2B – i ta różnica ma większe znaczenie niż nominalna opłata licencyjna.

VTEX stosuje model cenowy oparty na GMV, pobierając procent od wartości brutto towarów przetwarzanych przez platformę, uzupełniony stałymi opłatami, zamiast flat rocznej licencji. Umowy enterprise VTEX są negocjowane indywidualnie, więc efektywna stawka zależy od progu kontraktowego, trajektorii GMV oraz miksu wolumenu marketplace i sprzedaży własnej. Przy niższym GMV model wydaje się przewidywalny.

Gdy sprzedawca B2B rośnie lub prowadzi operację o wysokim wolumenie i niskich marżach, gdzie wartości zamówień są duże, ale marże cienkie, pułap GMV staje się strukturalnym problemem kosztowym. Producent przetwarzający 400 mln dolarów rocznie przez VTEX płaci wyraźnie wyższą opłatę platformową niż merchant z obrotami 40 mln dolarów – niezależnie od liczby wywołań Master Data API v2 czy złożoności konfiguracji Trade Policy.

Jeśli Twój footprint omnichannel się rozszerza i GMV ma się podwoić w ciągu trzech lat, zamodeluj tę eskalację, zanim założysz, że VTEX jest tańszą opcją SaaS.

commercetools rozlicza się na podstawie wolumenu wywołań API, nie GMV. W przypadku wdrożenia w architekturze MACH z integracją ERP w czasie rzeczywistym, dostępnością stanów magazynowych i cenami specyficznymi dla klientów pobieranymi z SAP lub Oracle przy każdym ładowaniu koszyka – koszty szybko rosną: każde wyświetlenie strony portalu kupującego, przeglądanie katalogu i szkic oferty to mierzalne wywołanie, niezależnie od tego, czy prowadzi do konwersji. Zespoły, które nie modelują oczekiwanego wolumenu wywołań na etapie projektowania – uwzględniając punkty styku integracji ERP, ruch w portalu kupującego i zachowanie przy tworzeniu ofert – regularnie odkrywają, że koszty platformy przekraczają początkowe prognozy w ciągu pierwszych kilku kwartałów od uruchomienia. Zmapuj każdy punkt styku integracji ERP na liczbę żądań API, zanim podpiszesz umowę z commercetools.

Spryker działa na tradycyjnym modelu licencji enterprise z rocznymi opłatami negocjowanymi per zakres wdrożenia. Branżowe porównania powszechnie wskazują na przedział 200 000-500 000 dolarów rocznie dla średnich i dużych wdrożeń, choć własne umowy enterprise Spryker są wyceniane indywidualnie – traktuj to zatem jako punkt orientacyjny w planowaniu, nie jako ofertę. Koszt początkowy jest wyższy niż w obu pozostałych alternatywach, ale nie ma ryzyka eskalacji GMV ani niespodzianek związanych z wywołaniami API. Prawdziwym czynnikiem kosztowym jest wdrożenie: modularna, natywnie B2B architektura Spryker wymaga głębszego zaangażowania SI, a sama konfiguracja modułu Quotation Offer / Offer Management zazwyczaj wydłuża harmonogram uruchomienia o cztery do ośmiu tygodni. Porównując Spryker i VTEX pod kątem całkowitych wydatków, głębokość wdrożenia jest często decydującą zmienną.

W większości porównań dostawców B2B SaaS różnica w opłatach licencyjnych jest do odrobienia. Różnica w kosztach SI – a szczególnie w godzinach developerskich potrzebnych do zbudowania UI portalu kupującego w commercetools w porównaniu z użyciem natywnych komponentów storefront B2B Organizations VTEX – często już nie. W podstawowych przypadkach użycia B2B, gdzie liczy się szybkość dojścia do przychodów, ta luka kosztów budowy to konkretna pozycja w TCO, a nie abstrakcyjna kwestia architektoniczna.

Złożoność wdrożenia: harmonogramy, zależność od SI i liczba deweloperów

Harmonogramy uruchomienia produkcyjnego na tych trzech platformach różnią się o sześć miesięcy lub więcej na poziomie enterprise, a ta różnica wynika mniej ze złożoności funkcji, a bardziej z tego, ile struktury B2B każda platforma dostarcza natywnie, a ile Twój zespół musi zbudować samodzielnie. Zrozumienie architektonicznego śladu każdej opcji to najczytelniejszy sygnał, jak długo faktycznie potrwa Twój projekt.

VTEX B2B Suite to najszybsza droga do działającego sklepu B2B dla większości producentów i dystrybutorów z segmentu mid-market. Organizations, Cost Centers, Trade Policies oraz łańcuchy zatwierdzania są dostarczane jako aplikacje VTEX IO, konfigurujesz je, nie budujesz od zera. W projektach Netguru opartych na VTEX B2B Suite zespoły uruchamiały działający portal dla kupujących, w tym rozwiązywanie adresów dostawy w zakresie Cost Center podczas realizacji zamówienia, w ciągu 14-18 tygodni przy wdrożeniu na jeden rynek. Główną zmienną wdrożeniową jest zakres Trade Policy: klient z trzema odrębnymi segmentami klientów i oddzielnymi tabelami cenowymi wymaga starannego mapowania przed migracją danych, inaczej zapytania do Master Data API v2 zwracają niespójne ceny w czasie działania systemu.

Zależność od SI jest umiarkowana. Kompetentny partner VTEX obsługuje konfigurację, a niestandardowe tworzenie aplikacji VTEX IO pojawia się tylko przy niestandardowych integracjach zakupowych. W przypadku wdrożeń VTEX enterprise obejmujących wiele regionów lub punktów styku omnichannel, dodaj cztery do sześciu tygodni na walidację Trade Policy rynek po rynku.

commercetools Business Units wymagają więcej pracy montażowej. Modularny model danych jest elastyczny, możesz odwzorować wielooddziałową organizację z zagnieżdżonymi Business Units i szczegółowymi rolami Associate, ale interfejs użytkownika dla kupujących w całości budujesz samodzielnie. Skoncentrowane wdrożenie B2B w commercetools z jednym BU może zamknąć się w 6-9 miesiącach; naprawdę wielooddziałowa hierarchia enterprise z niestandardową konfiguracją przepływu zatwierdzania i w pełni niestandardowym portalem dla kupujących typowo rozciąga się do 12-18 miesięcy i wymaga alokacji inżynierów frontendowych, którą natywne komponenty sklepu VTEX by wyeliminowały. Przy headlessowym projekcie z niestandardową konfiguracją przepływu zatwierdzania w trzech oddziałach, zaplanuj cztery do sześciu frontendowych FTE przez pierwsze kilka miesięcy. To zobowiązanie kadrowe jest głównym sygnałem, który decydenci w procesach oceny B2B konsekwentnie niedoszacowują.

Spryker wiąże się z najstromszą krzywą wdrożenia. Jego natywna dla B2B architektura, obejmująca zarządzanie ofertami Quotation Offer, katalogi klientów, wielopoziomowe ceny i bezpośrednią integrację protokołu punchout, jest najbardziej kompletna spośród tych trzech platform, ale powierzchnia wdrożeniowa jest odpowiednio duża. Dokumentacja platformy Spryker zakłada realistyczne uruchomienie MVP w tygodniach, a pełne wdrożenie enterprise typowo trwa od 6 do 12 miesięcy w zależności od zakresu (Spryker B2B Commerce Platform). Sama integracja punchout, mapowanie OCI lub cXML do warstwy Offer Management Spryker, dodaje od czterech do ośmiu tygodni w zależności od systemu ERP klienta. Koszty wdrożenia pracowników i szkoleń wewnętrznych w zakresie modułu CPQ Spryker, udokumentowane w recenzjach enterprise na G2, są pozycją, którą zespoły z segmentu mid-market konsekwentnie niedoszacowują na etapie kickoffu projektu.

Który profil kupującego pasuje do której platformy, idealny profil kupującego B2B

Dopasowanie platformy sprowadza się do trzech zmiennych: złożoności organizacji, wewnętrznych możliwości inżynieryjnych i tego, jak centralną rolę w Twoim modelu przychodowym odgrywają przepływy quote-to-cash. Poniżej trzy archetypy, które obserwujemy w praktyce.

VTEX B2B Suite, producent lub dystrybutor z segmentu mid-market, który migruje ze sklepu opartego na ERP. Sprzedajesz do 50-500 kont kupujących, potrzebujesz cen kontraktowych i rozwiązywania adresów dostawy w zakresie cost center bez konieczności budowania ich samodzielnie, i chcesz działającego sklepu B2B w mniej niż sześć miesięcy (VTEX Help Center - B2B Suite Overview). VTEX dostarcza Organizations, Cost Centers i Trade Policies natywnie, więc Twój zespół inżynierski konfiguruje, a nie konstruuje. Zły wybór: wielooddziałowe enterprise z głęboko warstwowymi hierarchiami organizacyjnymi lub retailer prowadzący retail media obok B2B, model cenowy VTEX oparty na GMV staje się też kosztowny powyżej określonego wolumenu transakcji, a sufit dostawcy SaaS B2B jest realny na wysokim poziomie skali.

commercetools Business Units, enterprise z silnym zapleczem inżynieryjnym i niestandardową strukturą B2B. Masz wiele oddziałów, oddziałów regionalnych lub model organizacji zakupowej, którego żadna gotowa platforma nie odwzorowuje dokładnie. commercetools pozwala Ci precyzyjnie zamodelować tę strukturę za pomocą Business Units i zbudować UI portalu dla kupujących dokładnie tak, jak wymaga tego Twój przepływ zakupowy. Zły wybór: zespół bez dedykowanych inżynierów frontendowych odpowiedzialnych za złożenie composable commerce, każda godzina tego podejścia „zbuduj sam" będzie odczuwalna.

Spryker Quotation Offer / Offer Management, enterprise stawiające B2B na pierwszym miejscu, z rozbudowanymi wymaganiami CPQ i punchout. Prowadzisz formalne cykle RFQ, potrzebujesz integracji protokołu punchout z systemami zakupowymi klientów (SAP Ariba, Coupa) i wymagasz katalogów dedykowanych dla klientów z wielopoziomowymi cenami jako standardu. Spryker to najbardziej wyspecjalizowana platforma handlowa enterprise spośród tych trzech, jeśli chodzi o głębię quote-to-cash. Zły wybór: zespół oczekujący dopracowanego UX administracyjnego od razu po wdrożeniu, recenzje enterprise na G2 w kategorii commerce konsekwentnie wskazują, że interfejs modułu CPQ jest wolniejszy w obsłudze niż oczekiwano, co kumuluje się w czasie obsługi każdej oferty w zespołach o wysokim wolumenie.

FAQ: Najczęstsze pytania na etapie decyzji

Masz już wstępną listę? Pomożemy Ci podjąć decyzję

Jeśli przeanalizowałeś porównanie VTEX vs. Commercetools vs. Spryker i masz już wstępną listę kandydatów, kolejnym krokiem powinna być analiza architektury powiązana z twoją rzeczywistą strukturą organizacyjną – nie kolejna demonstracja od dostawcy.

Nasz zespół inżynierów commerce ma praktyczne doświadczenie we wdrożeniach wszystkich trzech platform: wdrożeń VTEX B2B Suite z definiowaniem zakresu Trade Policy i konfiguracją Cost Center, projektowania hierarchii Business Unit w Commercetools dla klientów wielooddziałowych oraz integracji protokołu punchout w Sprykerze dla korporacyjnych procesów zakupowych. Pracujemy w całym stosie composable commerce – od projektowania modelu danych przez integrację z ERP aż po budowę portalu dla kupujących.

Jeśli oceniasz korporacyjną platformę e-commerce pod kątem wymagań B2B i chcesz usłyszeć opinię praktyka na temat dopasowania, zakresu i TCO – a nie oferty handlowej – porozmawiaj z naszym zespołem. Jeśli rozważasz też szersze opcje platformowe, nasze zestawienie Shopify Plus vs SAP Commerce Cloud omawia prostotę SaaS w zderzeniu z głębią integracji korporacyjnej.