Platforma B2B dla agentów zakupowych: czy AI kupi produkt z MOQ i ceną kontraktową?

Sprawdziliśmy, co da się wyrazić o produkcie B2B w dwóch protokołach handlu agentowego. Wynik: żaden protokół handlu agentowego nie ma pola na minimalną ilość zamówienia. Ani UCP, ani ACP nie mają MOQ, wielokrotności opakowania ani cen progowych. Ma je za to schema.org – warstwa, o której w kontekście agentów nikt nie mówi.

Praktyczny wniosek jest odwrotny do tego, czego można się spodziewać: sklep B2B nie przygotujesz się na agentów przez wdrożenie protokołu. Przygotuje się przez uporządkowanie danych katalogowych i wystawienie ich w warstwie, którą agent odczyta, zanim ktokolwiek się zaloguje.

Wszystkie specyfikacje odczytaliśmy 26 lipca 2026: UCP w wersji 2026-04-08, ACP w wersji 2026-04-17, schema.org V30.0. To dokumenty, które zmieniają się co kilka tygodni, więc datę warto traktować jako część wyniku.

Dlaczego SEO w B2B kończy się na ruchu, a nie na zamówieniu

W sklepie konsumenckim ścieżka jest krótka: klient znajduje produkt, widzi cenę, kupuje. W B2B prawie nic z tego nie działa tak samo. Decyduje kilka osób, cykl trwa tygodnie, cena bywa indywidualna i schowana za logowaniem, a zamiast koszyka bywa oferta.

Konsekwencja dla treści jest taka, że klasyczne SEO doprowadza w B2B do formularza kontaktowego i tam się kończy. Przy asystencie zakupowym problem wygląda inaczej: agent nie wypełni formularza w imieniu klienta, ale może odrzucić Twój produkt na etapie kwalifikacji, jeszcze zanim ktokolwiek pomyśli o kontakcie.

To jest ta sama mechanika, którą opisaliśmy przy badaniu nad odrzucaniem trafnych ofert: model odrzuca ofertę, gdy nie potrafi potwierdzić, że spełnia warunki. W B2B warunków jest więcej i są twardsze.

Co agent widzi przed zalogowaniem

To jest pytanie, od którego trzeba zacząć każdy audyt katalogu B2B. Jeśli przed zalogowaniem widać wyłącznie nazwę, zdjęcie i przycisk „zapytaj o cenę”, agent nie ma na czym oprzeć decyzji o wejściu w proces.

Rozdzielenie jest prostsze, niż się wydaje, i nie wymaga ujawniania niczego wrażliwego. Agent nie potrzebuje Twojej ceny kontraktowej. Potrzebuje pewności, że produkt spełnia wymagania techniczne, ilościowe i dokumentowe – a tego da się dowieść bez podawania warunków handlowych.

Jak wygląda mechanika samego uwierzytelnienia i co się dzieje po zalogowaniu, opisuje specyfikacji identity linking, w której znajduje się zresztą wprost przykład hurtowni: „B2B wholesaler – No guest checkout – every transaction requires an authenticated user”.

Trzy warstwy, trzy różne odpowiedzi

dokumentacji Universal Commerce Protocol deklaruje zakres podmiotowy bardzo szeroko. Platformą może być „an app, an AI agent, a procurement system, or another business”, biznesem „a retailer, a supplier, a service provider”, co czyni protokół „equally applicable to B2C, B2B, and agent-to-agent commerce”. Wśród przykładów platform wymieniono wprost systemy procurementowe, a wśród biznesów dostawców i dystrybutorów.

To deklaracja, nie implementacja. Rozstrzyga ją jedno zdanie ze specyfikacji: „Whether the user is B2B-eligible, what pricing they see, what payment terms apply – those are user attributes the merchant resolves at runtime, not additional scopes”. Innymi słowy UCP mówi: to jest Twój problem, rozwiąż go po swojej stronie. Warto też wiedzieć, że mapie drogowej UCP nie zawiera B2B ani procurementu – są na niej programy lojalnościowe, cross-sell, gastronomia i noclegi.

ACP ma pola, których UCP nie ma

To najważniejsza korekta wobec obiegowej opinii, że protokoły są równoważne. repozytorium Agentic Commerce Protocol, utrzymywany przez OpenAI i Stripe, zawiera pola wprost opisane jako B2B:

Pole	Wartości	Do czego służy
payment_terms	immediate, net_15, net_30, net_60, net_90	opisane w specyfikacji jako „Payment terms for B2B transactions”
purchase_order_number	ciąg znaków	numer zamówienia zakupowego
due_date	data w formacie RFC 3339	termin płatności
CompanyInfo	name, tax_id, department, cost_center	dane firmy kupującego, w tym dział i miejsce powstawania kosztów

Najciekawszy jest jednak nie sam zestaw pól, tylko konstrukcja walidacji: ACP dopuszcza checkout bez instrumentu płatniczego, jeśli podano numer zamówienia zakupowego. To zakup na fakturę wpisany wprost w protokół – i rzecz, której w UCP nie ma wcale.

Korekta, którą trzeba zrobić uczciwie: w obiegu funkcjonuje twierdzenie, że ACP ma pole logiczne approval_required na ścieżkę akceptacji zamówienia. Sprawdziliśmy to w schemacie: approval_required występuje, ale jako jedna z wartości w wyliczeniu kodów błędów, obok unsupported, conflict czy rate_limited. To komunikat „ta operacja wymaga zatwierdzenia”, a nie pole opisujące proces akceptacji po stronie kupującego.

Czego nie ma nigdzie

Pole	UCP	ACP	schema.org
minimalna ilość zamówienia (MOQ)	nie ma	nie ma	jest
minimalna wartość zamówienia	nie ma	nie ma	jest
wielokrotność opakowania	nie ma	nie ma	częściowo
ceny progowe	nie ma	nie ma	jest
segment B2B kontra B2C	runtime sprzedawcy	nie ma	jest
warunki płatności	nie ma	jest	nie ma
numer zamówienia zakupowego	nie ma	jest	nie ma
dane firmy i identyfikator podatkowy	nie ma	jest	nie ma
lead time jako liczba dni	nie ma	jest	częściowo
zapytanie ofertowe jako proces	nie ma	nie ma	częściowo

Sprawdziliśmy to bezpośrednio w schemacie ACP: max_quantity_per_order istnieje, czyli protokół potrafi wyrazić maksimum, ale nie minimum. W kategoriach, gdzie MOQ jest normą, to różnica między zamówieniem możliwym do realizacji a odrzuconym.

Najlepsze pokrycie danych B2B daje schema.org

I to jest wniosek, który odwraca zwykłą kolejność myślenia o gotowości na agentów. Warstwa GoodRelations w schema.org, obecna tam od lat i traktowana jako relikt, ma dokładnie te pola, których brakuje w nowych protokołach:

• eligibleQuantity – „The interval and unit of measurement of ordering quantities for which the offer or price specification is valid”. Minimalną ilość zamówienia wyraża się przez minValue, a jednostkę przez unitCode.
• eligibleTransactionVolume – opisane w dokumentacji jako sposób „for indicating a minimal purchasing volume”, czyli minimalna wartość zamówienia.
• wiele obiektów UnitPriceSpecification w jednej ofercie, każdy z własnym eligibleQuantity – to klasyczny wzorzec na ceny progowe.
• eligibleCustomerType z wartościami Business, Enduser, PublicInstitution i Reseller – segmentacja odbiorcy.
• businessFunction – czy oferta dotyczy sprzedaży, najmu, naprawy czy utylizacji.

Czego schema.org nie ma: warunków płatności jako ustrukturyzowanego pola (jest tylko metoda płatności z typem faktury) ani zapytania ofertowego jako procesu. Czyli dokładnie tego, co ma ACP. Te dwie warstwy się uzupełniają i żadna z nich nie wystarcza sama. Podstawy poprawnego opisania oferty w danych strukturalnych zebraliśmy przy danych strukturalnych ceny i dostępności.

MOQ, wielokrotność i jednostka sprzedaży

To najczęstsze źródło zamówień, których nie da się zrealizować – i najczęściej pomijana informacja w danych produktowych. Trzy różne rzeczy, które bywają mylone:

Pojęcie	Co znaczy	Przykład
minimalna ilość zamówienia	poniżej tej liczby zamówienie nie zostanie przyjęte	minimum 50 sztuk
wielokrotność opakowania	sprzedaż tylko w krotnościach	karton po 24 sztuki, nie da się kupić 30
jednostka sprzedaży	w czym wyrażona jest cena i ilość	cena za metr bieżący przy sprzedaży w zwojach po 50 m

Zdanie „opakowanie zbiorcze 24 szt.” w opisie produktu nie wystarcza. Model potrafi je przeczytać, ale nie ma pewności, czy to ograniczenie zakupu, czy informacja logistyczna. Różnica jest istotna: w pierwszym przypadku zamówienie na 30 sztuk jest niemożliwe, w drugim jest po prostu dostarczone w dwóch kartonach.

Jak wynika z wyszukiwaniu na wymagania, model najpierw rozkłada zapytanie na warunki, a dopiero potem filtruje katalog. Jeśli warunek ilościowy nie jest wyrażony jako dana, nie zostanie uwzględniony w filtrowaniu – trafi najwyżej do treści odpowiedzi jako uwaga.

Cena katalogowa, progowa i kontraktowa

Trzy poziomy, z których publiczny może być pierwszy, częściowo drugi, a trzeci nigdy.

1. Cena katalogowa – punkt odniesienia. Publiczna, choć w wielu hurtowniach ukrywana bez powodu.
2. Ceny progowe – im więcej sztuk, tym niższa cena jednostkowa. To można wyrazić w danych strukturalnych i warto, bo pozwala agentowi policzyć koszt zamówienia, a nie tylko cenę pojedynczej sztuki.
3. Cena kontraktowa – indywidualna, wynikająca z umowy. Nie powinna być publiczna i nie musi. Wystarczy publiczna informacja, że taki poziom istnieje.

Ten trzeci punkt bywa źle rozumiany. Ukrycie ceny kontraktowej nie oznacza, że katalog ma być pusty – oznacza, że publicznie pokazujesz strukturę cennika, a konkretne warunki rozstrzygasz po uwierzytelnieniu. UCP zakłada dokładnie ten model, przenosząc rozstrzygnięcie na runtime sprzedawcy.

Lead time, stan magazynowy i backorder

W handlu konsumenckim wystarczy „dostępny” albo „niedostępny”. W B2B to za mało, bo zamówienie na 500 sztuk z terminem realizacji za trzy tygodnie jest czymś zupełnie innym niż to samo zamówienie na jutro.

ACP ma tu przewagę: pozwala wyrazić czas przygotowania i czas transportu jako liczby dni, osobno wartość minimalną i maksymalną. UCP wyraża to inaczej – przez informację, czy zamówienie jest realizowalne teraz, czy w konkretnej dacie w przyszłości, co obejmuje również zamówienia oczekujące i przedsprzedaż.

Czego nie ma w żadnym z protokołów: stanu magazynowego jako liczby. Oba operują wyliczeniami albo wskazówkami dostępności. Dla kupującego, który potrzebuje wiedzieć, czy hurtownia ma na stanie 500 sztuk czy 12, to zasadnicza różnica – i tę informację trzeba podać w treści karty produktu, bo w danych protokołu nie ma na nią miejsca.

Certyfikaty i dokumentacja: konflikt, którego nie da się obejść

W wielu branżach B2B dokument jest warunkiem zakupu, nie dodatkiem. Karta charakterystyki, deklaracja zgodności, atest higieniczny, certyfikat materiałowy – bez nich zamówienie nie przejdzie przez dział zakupów.

Tu pojawia się realny konflikt. Atrybut na dokumenty produktowe w feedzie wymaga, żeby plik był dostępny publicznie, bez logowania. Tymczasem znaczna część dokumentacji B2B jest za uwierzytelnieniem – czasem z powodów umownych, czasem dlatego, że tak zawsze było.

Rozwiązanie nie polega na otwarciu wszystkiego. Polega na rozdzieleniu: publiczna karta produktu z listą dostępnych dokumentów i publicznie dostępnymi tymi, które i tak muszą być jawne, a reszta za logowaniem. Zasada brzmi: agent musi wiedzieć, że dokument istnieje, nawet jeśli nie może go pobrać.

To jest zresztą szerszy wzorzec – dowód nie musi być pobierany, żeby liczył się jako dowód. Rozwijamy to przy dowodach twierdzeń produktowych.

Kiedy zamówienie, a kiedy zapytanie ofertowe

Żaden z protokołów nie modeluje zapytania ofertowego jako procesu. To luka, o której warto wiedzieć, bo w B2B jest to często ścieżka domyślna, a nie wyjątek.

Praktyczny podział, który sprawdza się w katalogu:

Sytuacja	Ścieżka	Co musi być w danych
produkt katalogowy, ilość powyżej MOQ, cena progowa znana	zamówienie	MOQ, wielokrotność, próg cenowy, dostępność, lead time
ilość poniżej MOQ albo nietypowa	zapytanie ofertowe	jasna informacja o MOQ i ścieżka kontaktu
produkt konfigurowalny albo na zamówienie	zapytanie ofertowe	zakres konfiguracji i orientacyjny czas realizacji
klient z umową i cenami kontraktowymi	zamówienie po zalogowaniu	informacja, że ceny indywidualne istnieją

Kluczowe jest to, żeby agent potrafił rozpoznać, w którym wierszu się znajduje. Jeśli karta produktu nie ujawnia MOQ, agent nie wie, czy ma złożyć zamówienie, czy poprosić o ofertę – i najczęściej nie zrobi ani jednego, ani drugiego.

B2B Agent Readiness Score

Prosty sposób na ocenę własnego katalogu. Osiem obszarów, sto punktów, wagi dobrane wedle tego, jak często dany brak blokuje transakcję.

Obszar	Co się liczy	Punkty
warunki ilościowe	MOQ, wielokrotność, jednostka sprzedaży	15
cena	progi, waluta, netto lub brutto, istnienie cen kontraktowych	15
dostępność	ilość, lead time, backorder, lokalizacja magazynu	15
dokumenty	certyfikaty, deklaracje, karty charakterystyki, instrukcje	15
identyfikacja produktu	MPN, GTIN, kod producenta, stabilny SKU	10
logistyka	waga, paleta, ADR, Incoterms, sposób dostawy	10
kompatybilność	odpowiedniki, następcy, części wymagane	10
transakcja	ścieżka zamówienia lub oferty, płatność odroczona, akceptacja	10

Interpretacja: 0-39 katalog nieczytelny dla agenta · 40-69 agent znajdzie produkt, ale nie dokończy zakupu · 70-100 gotowość procurement-ready.

Cztery obszary o najwyższej wadze to nie przypadek. Każdy z nich potrafi samodzielnie zablokować zamówienie, niezależnie od tego, jak dobrze wypada reszta katalogu.

Od czego zacząć

1. Sprawdź, co widać bez logowania. Otwórz swój katalog w trybie prywatnym i zapytaj asystenta o produkt z konkretnym wymaganiem ilościowym. Jeśli nie potrafi odpowiedzieć, agent kupującego też nie będzie potrafił.
2. Wystaw MOQ i wielokrotność jako dane, nie jako zdanie w opisie. To jedno pole i najczęstsza przyczyna odrzuconych zamówień.
3. Pokaż strukturę cennika, nie ceny. Publiczna informacja, że progi istnieją i od jakiej ilości się zaczynają, wystarczy, żeby agent zakwalifikował ofertę.
4. Opublikuj listę dokumentów, nawet jeśli same pliki zostają za logowaniem.
5. Rozdziel ścieżkę zamówienia od ścieżki oferty i opisz, kiedy obowiązuje która.

Zakres i wycenę uporządkowania katalogu B2B pod agentów zakupowych zebraliśmy w cenniku SEO dla e-commerce. Czy Twoje dane są dziś czytelne dla modeli, sprawdzamy w audycie widoczności w AI, a całość prowadzimy jako element pozycjonowania sklepu internetowego. Techniczną gotowość na transakcje agentowe opisaliśmy przy checkliście gotowości na zakupy przez AI, pomiar tej sprzedaży przy atrybucji sprzedaży agentowej, a ocenę wiarygodności sprzedawcy przy weryfikacji sprzedawcy przed transakcją. Jak budować treści B2B, które generują leady, opisaliśmy osobno przy treściach B2B generujących leady. Ten temat jest jedną z dziesięciu warstw SEO w e-commerce – całość, wraz z patentami stojącymi za każdą warstwą, zebraliśmy w mapie 10 warstw SEO w e-commerce.

Najczęściej zadawane pytania