B2B Commerce w 2026: jeden silnik sprzedaży zamiast trzech osobnych światów

W wielu firmach produkcyjnych proces zamówień B2B często jest rozbity na trzy osobne światy: sklep obsługiwany przez marketing, wyceny budowane ręcznie przez handlowców i subskrypcje kontrolowane przez finanse. Efekt to kosztowne przeklejanie danych, niska konwersja i permanentne ryzyko błędów. Nowe funkcje Agentforce Commerce (Salesforce) celują dokładnie w to miejsce, łącząc konfigurację produktów, RFQ i zarządzanie subskrypcjami w jeden spójny przepływ. 

Nowe podstawy techniczne: B2B Commerce i Revenue Cloud jako jeden silnik

Najważniejsza zmiana zachodzi pod spodem: Salesforce przestaje traktować B2B Commerce i Revenue Cloud jako dwa osobne moduły. Integracja na poziomie Process APIs i wspólnego modelu danych sprawia, że konfiguracja, pricing i subskrypcje działają jako jeden strumień. Kluczową rolę odgrywa tutaj przeniesienie logiki konfiguracji do storefrontu, co eliminuje słynne call for details, które blokowały konwersję na polskich portalach B2B. Dzięki temu walidacja konfiguracji odbywa się już na etapie koszyka, a nie w rękach handlowca 24 godziny później. To fundamentalnie zmienia obciążenie zespołów: mniej korekt, mniej back-and-forth, więcej przewidywalnych procesów.

Technicznie oznacza to szersze wykorzystanie reguł konfiguracji znanych z CPQ, ale obsługiwanych przez nową warstwę storefront logic. Firmy, które mają custom CPQ, będą musiały zastanowić się nad migracją lub harmonizacją, bo podwójne utrzymywanie rules engines skończy się błędami cenowymi. To kolejny sygnał, że klasyczne CPQ staje się trudne do skalowania przy nowych modelach cenowych, co szerzej omawialiśmy w analizie złożonych modeli CPQ. Dla architektów to jasna rekomendacja: roadmapa na 2026 powinna zakładać redukcję duplikatów pricing logic i migrację do jednego engine.

W praktyce oznacza to bardziej zwinne wdrożenia w polskich firmach produkcyjnych, które dotychczas rozbijały projekt na osobne zespoły Commerce, CPQ i Billing. Salesforce spaja to w platformę, a nie integrację. Rynek integratorów w Polsce będzie musiał odejść od podejścia multi-stack na rzecz jednego ownera procesu quote-to-cash, co pozwoli skrócić cykl wdrożenia o 20–40 proc.

Agentic AI w Commerce: od chatbotów do realnych Guided Shopping Agents

Do tej pory B2B Commerce korzystało z prostych botów, które potrafiły odpowiedzieć na pytanie lub podać link do produktu. Guided Shopping Agents działają inaczej. To agenty z pełnym dostępem do katalogu, zasad uprawnień, cenników kontraktowych i historii zamówień. Ich zadaniem nie jest rozmowa, ale wykonanie pracy: znalezienie właściwego SKU, stworzenie konfiguracji lub odtworzenie zamówienia na podstawie specyfikacji technicznej. To przykład agentic AI, które wcześniej analizowaliśmy w kontekście architektury w artykule o Agentforce 360.

Nowością jest Agentforce Localization, czyli obsługa wielojęzyczna i multi-locale wbudowana bez potrzeby posiadania globalnego zespołu wsparcia. W przypadku polskich producentów z rynkami DACH i CEE to usuwa jeden z największych kosztów operacyjnych: obsługę pre-sales w kilku językach. Technicznie rozwiązanie korzysta z kontekstu produktowego dostępnego bezpośrednio w Data Cloud, dzięki czemu agent nie musi generować odpowiedzi wyłącznie z promptu, ale faktycznie korzysta z danych katalogowych.

Implikacje dla praktyków są znaczące: onboarding klientów do samoobsługi staje się możliwy także przy produktach, które dotychczas wymagały długiego wsparcia handlowca. Jednocześnie pojawia się wyzwanie governance: każda firma musi określić, które akcje agent może wykonywać w pełnej autonomii, a które wymagają manualnego checkpointu. To kontynuacja trendu, który obserwujemy w całym ekosystemie AI Salesforce, gdzie rośnie znaczenie deterministycznych ograniczeń agentów, opisane wcześniej w analizie kosztów autonomii Agentforce.

Nowy storefront: open-source LWC i rezygnacja z customów, które kosztują najwięcej

Salesforce otwiera kluczowe komponenty storefrontu jako open-source LWC: Homepage, PLP i PDP. Dla polskich developerów to największa zmiana od lat, bo w praktyce eliminuje potrzebę budowania custom storefrontów tylko po to, aby obsłużyć nietypowy layout lub logikę. Do tej pory customizacja oznaczała vendor lock-in i wzrost TCO. Teraz standardowe komponenty można forkować, modyfikować i utrzymywać w repo razem z resztą projektu.

Open-source LWC ma też konsekwencje architektoniczne: wchodzimy w model, w którym front-end przestaje być częścią monolitycznego Commerce Cloud, a staje się modułem rozwijanym jak każda współczesna aplikacja webowa. Deweloperzy otrzymują realne extension points, w tym możliwość zmiany logiki wyszukiwania, która w czerwcu dostanie kolejne usprawnienia. Weighted search attributes i synonym management to funkcje, które powinny rozwiązać problem niskiej trafności wyszukiwania w wielu polskich wdrożeniach przemysłowych.

Dla firm to oznacza krótszy czas wdrożeń i mniejsze koszty, ale także większe wymagania dotyczące jakości kodu i CI/CD. Firmy, które dotychczas traktowały Commerce Cloud jako gotowy produkt, będą musiały zbudować minimalny proces developerski z branchowaniem, code review i release management. Ten kierunek jest spójny z trendem platformizacji, w którym Commerce, Revenue i Data Cloud mają działać jako jeden ekosystem, a nie oddzielne silosy.

RFQ, subskrypcje i seamless handoff: koniec pęknięć w procesie zamówieniowym

Request for Quote wbudowany w PDP zmienia fundament pracy zespołów sprzedaży. Klient może przejść od koszyka do wyceny jednym kliknięciem, a handlowiec widzi pełny kontekst w Salesforce. W czerwcu pojawi się funkcja odwrotna: handlowiec wyśle spersonalizowaną ofertę z powrotem do klienta do samodzielnej akceptacji i finalizacji transakcji. To eliminuje kanał e-mail jako miejsce, gdzie znika większość konwersji.

Równie istotne są subskrypcje: klienci mogą samodzielnie modyfikować, odnawiać lub anulować swoje kontrakty. W polskich firmach model as-a-service rośnie szczególnie w urządzeniach przemysłowych, serwisie oraz w sprzedaży części eksploatacyjnych. Do tej pory zarządzanie subskrypcjami było oddzielnym systemem lub makrami w ERP. Wspólna platforma order, billing i subscription to realne obniżenie kosztów integracji.

W praktyce oznacza to, że polskie firmy produkcyjne mogą zbliżyć się do poziomu samoobsługi znanego z software B2B, bez konieczności przepisywania architektury. Jednocześnie integratorzy będą musieli zmienić sposób prowadzenia projektów: zamiast trzech streamów (Commerce, CPQ, Billing) powstanie jeden zintegrowany strumień quote-to-cash z agentami AI. Ten trend już widać w podejściu globalnych firm implementacyjnych i jest zgodny z kierunkiem platformy Salesforce na 2026.

Podsumowanie

Agentforce Commerce nie jest kolejną paczką funkcji, ale sygnałem zmiany architektury: B2B ma działać jako jeden proces od discovery do checkout, z AI jako realnym wykonawcą części zadań. Dla polskich producentów to szansa na obniżenie TCO, skrócenie cykli sprzedaży i przeniesienie klientów z e-maila do samoobsługi. Kluczowe wyzwanie to governance: ile autonomii dać agentom i jak unifikować logikę konfiguracji i pricingu. Pytanie, które warto sobie zadać już dziś: gdzie w waszym procesie sprzedaży są największe pęknięcia i które z nich można wyeliminować dzięki temu, że platforma staje się jednym silnikiem, a nie trzema oddzielnymi światami?