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 zakupowy 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 specyfikacja identity linking. Znajduje się w niej zresztą wprost przykład zatytułowany „B2B wholesaler”, a warunek brzegowy postawiono w nim jednym zdaniem: „No guest checkout – every transaction requires an authenticated user”.

Jakie trzy warstwy danych widzi agent zakupowy?

Dokumentacja 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 że 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 mapa drogowa UCP nie zawiera B2B ani procurementu – są na niej programy lojalnościowe, cross-sell, gastronomia, noclegi i wejście na rynki Indii, Indonezji oraz Ameryki Łacińskiej.

ACP ma pola, których UCP nie ma

To najważniejsza korekta wobec obiegowej opinii, że protokoły są równoważne. Schemat opublikowany w repozytorium Agentic Commerce Protocol – utrzymywanym przez OpenAI, Stripe i Meta – zawiera pola wprost opisane jako B2B: Więcej na ten temat w naszym tekście o agentic commerce readiness. Więcej na ten temat w naszym tekście o atrybucji w agentic commerce.

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
approval_required	wartość logiczna	czy płatność wymaga zatwierdzenia – ścieżka akceptacji zakupu

Wszystkie pięć pól leży w jednym obiekcie PaymentData, co jest samo w sobie informacją: autorzy ACP potraktowali zakup firmowy jako wariant płatności, a nie jako osobny tryb protokołu. Warto przy tym wiedzieć, że approval_required występuje w schemacie dwa razy i w dwóch różnych rolach – raz jako to pole logiczne, a drugi raz jako jedna z wartości w wyliczeniu kodów błędów, obok unsupported, conflict czy rate_limited. Protokół potrafi więc zarówno zadeklarować, że akceptacja będzie potrzebna, jak i odmówić realizacji, dopóki jej nie ma.

Najciekawsza jest jednak nie sama lista 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.

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	nie ma – zakres dat	jest
stan magazynowy jako liczba	nie ma	jest	jest
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.

Jest przy tym szczegół, który tę tezę wzmacnia, a nie osłabia. Lista kodów błędów w ACP zawiera minimum_not_met, maximum_exceeded i quantity_exceeded. Protokół potrafi więc odmówić, powołując się na niespełnione minimum – tylko nie ma gdzie tego minimum zadeklarować w katalogu. Agent dowiaduje się o progu dopiero wtedy, gdy próbuje kupić, czyli w najgorszym możliwym momencie.

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.

Jak opisać MOQ, wielokrotność i jednostkę sprzedaży dla AI?

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.

Z tej trójki jedna pozycja wypada lepiej, niż można się spodziewać: jednostkę sprzedaży wyrażają oba protokoły, i to niemal identycznie. UCP ma w wariancie produktu obiekt measure („Product quantity in packaging”) razem z reference („Denominator for unit price display”). ACP ma w schemacie feedu obiekt UnitPrice z tą samą parą measure i reference. Luką pozostają MOQ i wielokrotność zamówienia – to pojęcia o zamawianiu, a nie o opakowaniu, i tej różnicy żaden z protokołów nie obsługuje. Więcej na ten temat w naszym tekście o Product schema.

Jak wynika z wyszukiwania 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.

Czym różnią się 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.

Jak podać lead time, stan magazynowy i backorder w danych strukturalnych?

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.

Żaden z protokołów nie wyraża lead time’u tak, jak robi to dział zakupów, czyli w dniach roboczych i z rozbiciem na czas przygotowania oraz czas transportu. ACP podaje zakres dwóch dat – earliest i latest w formacie RFC 3339 – czyli jedno łączne okno dostawy. UCP wyraża to jeszcze 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ż. Liczbę dni ma dopiero schema.org, w polu deliveryLeadTime.

Że stanem magazynowym jest odwrotnie, niż mówi obiegowa opinia o „ubogich” protokołach. ACP ma available_quantity – liczbę całkowitą opisaną jako „Quantity currently available for purchase”. UCP nie ma odpowiednika: operuje wartością logiczną available i statusem (in_stock, backorder, preorder, out_of_stock, discontinued). Dla kupującego, który musi wiedzieć, czy hurtownia ma 500 sztuk czy 12, to różnica rozstrzygająca – i jeśli sprzedajesz przez warstwę UCP, tę liczbę trzeba podać w treści karty produktu.

Dlaczego certyfikaty i dokumentacja tworzą nierozwiązywalny konflikt?

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. Dokumentację można podłączyć do feedu produktowego atrybutem document_link – do pięciu plików PDF, każdy do 50 MB – ale Google wymaga, żeby adres był publicznie dostępny i możliwy do zaindeksowania: „Googlebot must be able to access documents publicly without requiring logins or special permissions and with no restrictions in robots.txt”. Tymczasem znaczna część dokumentacji B2B jest za uwierzytelnieniem – czasem z powodów umownych, czasem dlatego, że tak zawsze było.

Warto przy tym wiedzieć, czego ten atrybut nie obejmuje, bo to akurat luka dotkliwa właśnie w B2B. Google podaje jako przykłady instrukcje obsługi, poradniki i instrukcje montażu. Nie ma pola na typ dokumentu, więc nie oznaczysz pliku jako karty charakterystyki ani deklaracji zgodności – a to są dokumenty, od których zależy dopuszczenie zamówienia. Osobny atrybut certification przyjmuje wyłącznie wartości z zamkniętej listy, głównie unijne etykiety energetyczne, i nie przyjmuje pliku. Sam atrybut dokumentowy jest zresztą opisany jako przeznaczony przede wszystkim do zastosowań konwersacyjnych, takich jak AI Mode w wyszukiwarce.

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 stosować 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.

Jak obliczyć 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ąć przygotowanie platformy B2B dla agentów AI?

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.

Cena kontraktowa ma jeszcze jeden wymiar, którego ten tekst nie obejmuje: mechanikę rozstrzygania, komu jaka cena przysługuje, i reguły Google dla cen członkowskich. Rozwijamy to osobno w tekście o cenach zależnych od tożsamości kupującego.

Najczęściej zadawane pytania

Jeśli opisy produktów i kategorii wymagają systematycznej oceny, audyt treści pozwala wskazać luki w pokryciu tematycznym i jakości copy. Przed wdrożeniem zmian w sklepie warto przeprowadzić audyt SEO, który zidentyfikuje krytyczne problemy techniczne i contentowe. Skuteczny content marketing w e-commerce buduje widoczność na zapytania informacyjne, które poprzedzają decyzję zakupową.

Więcej na ten temat w artykule AI poleca produkt, którego nie ma. Więcej na ten temat w artykule Prompt injection w e. Więcej na ten temat w artykule Laptopy poleasingowe i produkty refurbished w AI Search.

Ramka metodologiczna. Wnioski oparte na danych z Google Search Console, Google Analytics 4 oraz autorskiej metodyce diagnostycznej Semgence (zgłoszenie patentowe P.448274). Próbki obejmują projekty e-commerce w polskim rynku. Wyniki stanowią obserwacje z ograniczonej próby i nie powinny być traktowane jako uniwersalne prawidłowości. Dane z narzędzi zewnętrznych (Ahrefs, Screaming Frog, PageSpeed Insights) służą jako uzupełnienie diagnostyki, nie jako jedyne źródło rekomendacji.