Jak powinien wyglądać agent-ready produkt B2B dla Direct RFQ? Praktyczny przewodnik krok po kroku

Agent-ready produkt B2B nie jest po prostu dobrze opisaną podstroną internetową.

Jest cyfrową reprezentacją produktu, którą człowiek, system zakupowy albo agent AI może:

jednoznacznie zidentyfikować,
przypisać do właściwej kategorii,
zrozumieć technicznie,
porównać z innymi produktami,
sprawdzić pod kątem kompatybilności,
zweryfikować na podstawie dokumentów,
wycenić dla określonej ilości i warunków,
wykorzystać w zapytaniu Direct RFQ,
przekształcić w zamówienie,
obsługiwać po sprzedaży.

Produkt agent-ready powinien być czytelny jednocześnie dla trzech odbiorców:

człowieka odwiedzającego stronę,
systemu takiego jak ERP, PIM, marketplace lub platforma zakupowa,
agenta AI działającego w imieniu kupującego albo sprzedającego.

Najważniejsza zasada brzmi:

Strona produktowa nie może być jedynym miejscem, w którym istnieje wiedza o produkcie.

Dane powinny pochodzić z jednego źródła prawdy, a następnie być udostępniane przez stronę WWW, feed, API, formularz RFQ, MCP i — w bardziej zaawansowanym modelu — agenta A2A.

1. Zacznij od jednego źródła prawdy

Zanim firma zacznie budować API, agenta AI albo serwer MCP, powinna uporządkować miejsce, w którym przechowywane są dane podstawowe.

Może to być:

PIM,
ERP,
baza produktowa,
system e-commerce,
master data management,
dedykowana baza katalogowa.

Nie powinny nim być jednocześnie:

kilka arkuszy Excel,
opisy na stronie,
folder z dokumentami,
cennik handlowca,
wiadomości e-mail,
pamięć pracownika.

Każdy produkt powinien mieć jeden rekord główny — Product Master Record.

Rekord ten powinien określać:

czym produkt jest,
kto go wytwarza,
jak jest identyfikowany,
jakie ma parametry,
jakie ma warianty,
z czym współpracuje,
jak może być kupiony,
jakie dokumenty go potwierdzają,
jakie działania można na nim wykonać.

Oddziel produkt od oferty

To jeden z najważniejszych elementów całego modelu.

Produkt opisuje obiekt techniczny lub handlowy.

Oferta opisuje warunki, na jakich dany produkt może zostać sprzedany konkretnemu klientowi, w określonej ilości, terminie i miejscu.

Ten sam produkt może mieć wiele ofert:

cenę publiczną,
cenę kontraktową,
cenę dla jednej sztuki,
cenę paletową,
cenę eksportową,
cenę z transportem,
cenę dla dostawy ekspresowej,
cenę obowiązującą przez określony czas.

Agent-ready architektura powinna więc rozdzielać:

PRODUCT
Co to jest?

OFFER
Na jakich warunkach można to kupić?

RFQ
Jakich warunków oczekuje kupujący?

QUOTE
Jakie warunki oferuje sprzedający?

2. Warstwa tożsamości produktu

Tożsamość odpowiada na pytanie:

O jakim dokładnie produkcie mówimy?

Bez jednoznacznej tożsamości agent może pomylić:

dwa podobne warianty,
produkt z akcesorium,
model aktualny z wycofanym,
produkt producenta z numerem nadanym przez dystrybutora,
zwykły produkt z wersją spożywczą, antystatyczną lub wzmocnioną.

2.1. Jednoznaczna nazwa

Nazwa powinna być precyzyjna, stabilna i możliwa do zrozumienia bez kontekstu całej strony.

Słaba nazwa:

Taśma PET

Lepsza nazwa:

Taśma spinająca PET 15,5 × 0,90 mm, zielona, gładka

Nazwa powinna zawierać najważniejsze cechy odróżniające produkt, ale nie może być przeładowana marketingiem.

Warto przechowywać oddzielnie:

nazwę główną,
nazwę skróconą,
nazwę handlową,
nazwę techniczną,
nazwę polską,
nazwę angielską,
synonimy i popularne określenia.

Agent powinien korzystać z trwałego identyfikatora, a nie wyłącznie z nazwy tekstowej.

2.2. Producent

Pole producenta powinno wskazywać podmiot rzeczywiście odpowiedzialny za wytworzenie produktu.

Należy odróżniać:

producenta,
właściciela marki,
importera,
dystrybutora,
sprzedawcę.

W przypadku produktów white-label producent może być ukryty przed publicznym użytkownikiem, ale powinien pozostać dostępny w kontrolowanej bazie wewnętrznej.

2.3. Marka

Marka nie zawsze jest producentem.

Przykładowy model:

manufacturer: Producent przemysłowy GmbH
brand: IndustrialPack
seller: Dystrybutor Polska sp. z o.o.

Agent powinien rozumieć te role, ponieważ wpływają one na:

gwarancję,
odpowiedzialność,
pochodzenie dokumentów,
autoryzację serwisu,
dostępność części.

2.4. Model

Model identyfikuje konkretną rodzinę albo wykonanie produktu.

W przypadku maszyny może to być oznaczenie urządzenia.

W przypadku materiału model może odpowiadać klasie, formulacji, gramaturze, konstrukcji albo typowi nawoju.

Nie należy używać tego samego oznaczenia modelu dla technicznie różnych produktów.

2.5. SKU

SKU jest zazwyczaj wewnętrznym identyfikatorem nadawanym przez sprzedawcę, dystrybutora albo właściciela systemu magazynowego.

Jeden produkt może mieć różne SKU w różnych firmach.

Przykład:

SKU dystrybutora: PET-155-090-GR
SKU klienta: MAT-000481
SKU magazynu: 76843

Dlatego agent-ready rekord powinien umożliwiać mapowanie identyfikatorów partnerów:

partner_identifiers:
- partner_id
- identifier_type
- identifier_value

2.6. MPN

MPN, czyli Manufacturer Part Number, jest numerem produktu nadanym przez producenta.

W technicznym B2B często jest ważniejszy niż nazwa handlowa.

MPN powinien być przechowywany dokładnie w formie producenta, bez samodzielnego:

usuwania znaków,
zmieniania kolejności,
skracania,
dodawania własnych oznaczeń.

2.7. GTIN

GTIN jest globalnym identyfikatorem jednostki handlowej, która może być wyceniana, zamawiana lub fakturowana. Nie każdy produkt przemysłowy musi mieć GTIN, ale jeżeli został nadany, powinien być przechowywany i publikowany w sposób jednoznaczny.

Należy rozróżniać GTIN dla:

pojedynczej sztuki,
opakowania zbiorczego,
kartonu,
palety,
innej jednostki handlowej.

Nie wolno używać GTIN opakowania zbiorczego jako identyfikatora pojedynczej sztuki.

2.8. Wersja i rewizja

Wersja produktu jest niezbędna, gdy zmieniają się:

konstrukcja,
materiał,
oprogramowanie,
właściwości,
dokumentacja,
zgodność,
kompatybilność.

Przydatne pola:

product_version
revision
revision_date
valid_from
valid_to
change_description

Wersja katalogu lub opisu nie powinna być mylona z wersją samego produktu.

2.9. Status produktu

Status powinien być wartością słownikową, a nie swobodnym opisem.

Przykładowe statusy:

active,
new,
made_to_order,
limited_availability,
temporarily_unavailable,
end_of_life,
discontinued,
superseded,
prototype,
service_only.

Przy statusie superseded należy wskazać następcę.

Przy statusie discontinued należy podać:

datę wycofania,
dostępność zapasów,
dostępność części,
możliwy zamiennik,
okres wsparcia.

Rezultat etapu tożsamości

Po zakończeniu tej części agent powinien potrafić odpowiedzieć:

Czy produkt jest jednoznacznie rozpoznany?
Czy jest to właściwy wariant?
Czy produkt nadal jest aktywny?
Czy istnieje nowsza wersja?
Kto jest producentem, a kto sprzedawcą?
Jak produkt jest oznaczony u kupującego i dostawcy?

3. Klasyfikacja produktu

Tożsamość mówi, który to produkt.

Klasyfikacja mówi:

Do jakiego rodzaju produktów należy i w jakich procesach może zostać odnaleziony?

Nie należy polegać wyłącznie na strukturze kategorii własnego sklepu.

3.1. Kategoria własna

Kategoria własna jest potrzebna do:

nawigacji strony,
organizacji katalogu,
raportowania sprzedaży,
budowania landing pages,
zarządzania ofertą.

Powinna mieć:

trwały identyfikator,
nazwę polską,
nazwę angielską,
kategorię nadrzędną,
opis zakresu,
listę produktów,
reguły przypisania.

Przykład:

Systemy pakowania
→ Materiały do spinania
→ Taśmy PET
→ Taśmy PET do automatów

3.2. ETIM

ETIM jest szczególnie przydatny dla produktów technicznych. Model wykorzystuje grupy i klasy produktowe oraz przypisane do nich cechy, wartości i jednostki. Identyfikatory klas i cech są niezależne językowo, dzięki czemu mogą wspierać międzynarodową wymianę danych.

W rekordzie produktu należy zapisać co najmniej:

etim_version
etim_group_id
etim_class_id
etim_feature_mapping

Nie wystarczy wpisać samej nazwy klasy. Konieczny jest identyfikator i wersja klasyfikacji.

3.3. eCl@ss

ECLASS jest międzybranżowym standardem opisu danych produktowych i usługowych, wykorzystywanym w procurement, e-commerce i środowiskach inżynierskich. Klasy produktowe mogą być opisywane za pomocą przypisanych właściwości, wartości i jednostek.

Warto przechowywać:

eclass_release
eclass_class_id
eclass_properties

ECLASS może być szczególnie wartościowy, gdy produkty trafiają do:

zakładów produkcyjnych,
korporacyjnych katalogów zakupowych,
systemów PIM i ERP,
baz części,
rozwiązań przemysłowych.

3.4. UNSPSC

UNSPSC jest wielobranżową klasyfikacją produktów i usług używaną w zakupach, rejestracji dostawców i analizie wydatków. Ma czteropoziomową strukturę: segment, family, class i commodity.

Przykładowy zapis:

unspsc_version
unspsc_segment
unspsc_family
unspsc_class
unspsc_commodity

UNSPSC pomaga agentowi zakupowemu:

przypisać produkt do budżetu,
uruchomić właściwą ścieżkę zakupową,
znaleźć zatwierdzonych dostawców,
porównać wydatki w kategorii.

3.5. Kody branżowe i regulacyjne

Zależnie od produktu można dodać:

kod CPV dla zamówień publicznych,
kod CN lub HS dla handlu i odprawy celnej,
PKWiU,
kod CAS dla substancji,
klasy ADR,
kody materiałowe,
kody recyklingowe,
klasy norm technicznych,
kody klienta lub branżowego marketplace’u.

Każdy kod powinien zawierać:

scheme
version
code
label
valid_from
valid_to

3.6. Zastosowanie

Kategoria mówi, czym produkt jest.

Zastosowanie mówi, do czego może zostać użyty.

Przykładowe pola:

application_id
application_name
industry
process
problem_solved
recommended_use
prohibited_use
operating_conditions

Dla taśmy spinającej zastosowania mogą obejmować:

zabezpieczanie kartonów,
spinanie profili,
zabezpieczanie materiałów budowlanych,
pakowanie palet,
pracę w automacie.

Nie należy wpisywać zastosowania wyłącznie jako ogólnego tekstu marketingowego. Powinno ono mieć strukturę i warunki.

4. Parametry techniczne

Parametry są podstawą porównania, filtrowania, konfiguracji i automatycznej kwalifikacji produktu.

Nie wystarczy zapisać:

szerokość: 15,5

Agent musi wiedzieć:

czego dotyczy wartość,
w jakiej jednostce została podana,
czy jest nominalna,
jaka jest tolerancja,
w jakich warunkach ją zmierzono.

4.1. Identyfikator parametru

Każdy parametr powinien mieć trwały identyfikator.

Przykład:

parameter_id: strap_width
name_pl: szerokość taśmy
name_en: strap width

System powinien operować na parameter_id, a nie na nazwie tekstowej.

Dzięki temu:

zmiana tłumaczenia nie niszczy integracji,
polskie i angielskie nazwy odnoszą się do tej samej cechy,
można mapować parametry na ETIM lub eCl@ss.

4.2. Wartość

Wartość powinna być przechowywana w odpowiednim typie danych:

liczba,
tekst,
wartość logiczna,
data,
kod słownikowy,
zakres,
lista.

Nie należy przechowywać liczb jako tekstu:

Nieprawidłowo:
"width": "15,5 mm"

Prawidłowo:
"value": 15.5
"unit": "mm"

4.3. Jednostka

Jednostka musi być oddzielona od wartości.

Warto przechowywać:

unit_code
unit_symbol
display_unit
canonical_value
canonical_unit

Przykład:

value: 15.5
unit_code: MMT
unit_symbol: mm

Jeżeli dane pochodzą z różnych rynków, system powinien móc przeliczać jednostki bez utraty wartości źródłowej.

4.4. Tolerancja

Tolerancja powinna wskazywać dopuszczalne odchylenie.

Może być zapisana jako:

tolerancja symetryczna,
tolerancja asymetryczna,
minimum i maksimum,
procent,
klasa tolerancji.

Przykład:

nominal_value: 15.5
unit: mm
lower_tolerance: -0.3
upper_tolerance: 0.3

albo:

minimum_value: 15.2
maximum_value: 15.8
unit: mm

4.5. Warunki pomiaru

Niektóre wartości są zależne od:

temperatury,
wilgotności,
prędkości,
metody testowej,
kierunku pomiaru,
kondycjonowania próbki.

Warto zapisywać:

measurement_method
measurement_standard
temperature
humidity
sample_condition
test_direction

Przykładowo wytrzymałość może być nieporównywalna, jeżeli dwóch dostawców użyło innych metod testowych.

4.6. Wartość minimalna i maksymalna

Zakres jest szczególnie ważny w maszynach, częściach i produktach konfigurowalnych.

Przykład:

minimum_box_width: 120 mm
maximum_box_width: 600 mm

Należy odróżnić:

zakres konstrukcyjny,
zakres zalecany,
zakres przetestowany,
zakres gwarantowany.

4.7. Brak wartości

System powinien odróżniać:

null — wartość nieznana,
not_applicable — parametr nie dotyczy,
not_disclosed — wartość nie jest ujawniana,
pending_test — oczekiwanie na badanie,
0 — rzeczywista wartość zero.

Wpisanie zera zamiast braku danych może prowadzić do błędnego dopasowania produktu.

Rezultat etapu parametrów

Agent powinien potrafić:

porównać dwa produkty cecha po cesze,
sprawdzić wymagane minimum,
odrzucić produkt poza zakresem,
rozpoznać różnicę między wartością nominalną i gwarantowaną,
ocenić, czy dane są rzeczywiście porównywalne.

5. Relacje między produktami

W tradycyjnym katalogu produkty często istnieją jako niezależne karty.

W rzeczywistym B2B tworzą sieć zależności.

Agent musi wiedzieć nie tylko, czym jest produkt, ale także:

z czym współpracuje,
czego wymaga,
czym może zostać zastąpiony,
czego nie wolno z nim łączyć.

5.1. Warianty

Warianty należą do tej samej rodziny produktu, ale różnią się określoną cechą.

Przykłady:

szerokość,
kolor,
napięcie,
długość,
wydajność,
materiał,
rodzaj rdzenia.

Każdy wariant powinien mieć własne SKU, a w razie potrzeby również własny MPN i GTIN.

Rekord rodziny nie może zastępować konkretnego wariantu w RFQ.

5.2. Akcesoria

Akcesoria rozszerzają funkcjonalność produktu, ale nie są konieczne do jego podstawowego działania.

Dla akcesorium należy określić:

zgodne modele,
wymagane wersje,
zakres kompatybilności,
ograniczenia,
sposób montażu.

5.3. Części wymagane

Są to elementy, bez których produkt:

nie działa,
nie może zostać zainstalowany,
nie spełnia wymagań,
nie może być bezpiecznie używany.

W ofercie agent powinien poinformować:

Produkt wymaga dodatkowo pozycji X i Y.

5.4. Części opcjonalne

Elementy opcjonalne mogą zwiększać:

wydajność,
bezpieczeństwo,
automatyzację,
ergonomię,
trwałość.

Agent może je zaproponować, ale nie powinien przedstawiać ich jako obowiązkowych.

5.5. Zamienniki

Relacja „zamiennik” jest jedną z najbardziej ryzykownych.

Nie wystarczy stwierdzić:

Produkt B jest podobny do produktu A.

Należy określić poziom równoważności:

pełny zamiennik,
zamiennik warunkowy,
zamiennik funkcjonalny,
alternatywa o innych parametrach,
zamiennik wymagający modyfikacji,
zamiennik wyłącznie do określonego zastosowania.

Przykładowy rekord:

relation_type: conditional_substitute
source_product: SKU-A
target_product: SKU-B
conditions:
- maksymalna temperatura 40°C
- tylko do pracy ręcznej
- nie stosować w automacie model X
evidence_reference: TEST-2026-014

5.6. Następcy

Następca powinien być wskazany przy produkcie wycofanym.

Należy określić:

czy jest kompatybilny wstecznie,
czy wymaga nowego akcesorium,
czy ma inne wymiary,
czy wymaga aktualizacji oprogramowania,
od kiedy zastępuje stary model.

5.7. Produkty kompatybilne

Kompatybilność powinna być relacją warunkową.

Przykład:

product_A compatible_with product_B
when:
- software_version >= 3.2
- adapter SKU-ADP-22 installed

5.8. Produkty wykluczające się

Należy także zapisywać relacje negatywne.

Przykłady:

niewłaściwe napięcie,
niezgodna chemia,
niekompatybilny materiał,
inny rodzaj mocowania,
brak dopuszczenia do kontaktu z żywnością.

To pozwala agentowi nie tylko rekomendować, ale również bezpiecznie odrzucać niewłaściwe kombinacje.

6. Warstwa handlowa

Warstwa handlowa odpowiada na pytanie:

Czy, gdzie, kiedy, w jakiej ilości i na jakich warunkach można kupić produkt?

Dane handlowe zmieniają się znacznie częściej niż dane techniczne. Muszą mieć znacznik czasu i okres obowiązywania.

6.1. Cena publiczna lub tryb RFQ

Produkt może mieć jeden z modeli:

cena stała,
cena „od”,
cena zależna od ilości,
cena kontraktowa,
cena indeksowana,
cena konfigurowana,
wyłącznie RFQ,
chwilowo bez ceny.

Przykładowe pole:

price_mode:
- fixed
- tiered
- contract
- index_linked
- configure_to_order
- request_for_quote

W trybie RFQ agent powinien wiedzieć, jakie dane są potrzebne do wyceny.

6.2. Waluta

Cena musi mieć:

walutę,
status netto lub brutto,
informację o podatku,
datę obowiązywania,
termin ważności,
rynek.

Nie wolno przesyłać samej liczby bez waluty i kontekstu podatkowego.

6.3. Przedziały ilościowe

Cena może być zależna od ilości.

Przykład:

1–9 szt.: 120 PLN/szt.
10–49 szt.: 112 PLN/szt.
50–99 szt.: 105 PLN/szt.
100+ szt.: Direct RFQ

Każdy przedział powinien określać:

minimum,
maksimum,
jednostkę,
cenę,
warunki,
ważność.

6.4. MOQ

MOQ, czyli minimalna ilość zamówienia, powinna być oddzielona od:

wielokrotności zamówienia,
liczby w opakowaniu,
minimalnej wartości zamówienia,
minimalnej partii produkcyjnej.

Przykład:

MOQ: 48 rolek
order_multiple: 12 rolek
case_pack: 12 rolek
pallet_quantity: 480 rolek

6.5. Opakowanie zbiorcze

Agent powinien rozumieć hierarchię logistyczną:

sztuka,
rolka,
karton,
paczka,
paleta,
kontener.

Dla każdego poziomu warto podać:

ilość niższego poziomu,
wymiary,
masę netto,
masę brutto,
GTIN opakowania, jeżeli występuje,
sposób paletyzacji.

6.6. Stan magazynowy

Należy odróżniać:

stan fizyczny,
stan dostępny,
stan zarezerwowany,
dostępność do sprzedaży,
dostępność prognozowaną,
dostępność w konkretnym magazynie.

Agentowi nie zawsze należy ujawniać dokładną liczbę.

Możliwe statusy publiczne:

dostępny,
niski stan,
na zamówienie,
czasowo niedostępny,
dostępny po określonej dacie.

Dane powinny zawierać:

availability_status
available_quantity
warehouse
checked_at
estimated_replenishment_date

6.7. Termin realizacji

Termin realizacji powinien być oddzielony od deklarowanej daty dostawy.

Przydatne pola:

standard_lead_time
expedited_lead_time
production_time
dispatch_time
estimated_delivery_date
confidence_level

Agent powinien rozumieć, czy termin jest:

gwarantowany,
prognozowany,
orientacyjny,
wymagający potwierdzenia.

6.8. Obszar dostawy

Należy określić:

kraje,
regiony,
kody pocztowe,
wyłączenia,
wymagane minimalne zamówienie,
dostępność instalacji i serwisu.

Produkt może być dostępny globalnie, ale usługa uruchomienia tylko w wybranych krajach.

6.9. Incoterms

Incoterms powinny być zapisane jako osobne, kontrolowane pole wraz z miejscem.

Przykład:

incoterm: DAP
named_place: Warszawa, Polska

Samo DAP bez wskazania miejsca nie daje agentowi pełnej informacji.

6.10. Transport

Dane transportowe mogą obejmować:

dostępne formy dostawy,
koszt,
czas,
ograniczenia,
wymagany pojazd,
sposób rozładunku,
ADR,
temperaturę kontrolowaną,
ubezpieczenie.

W Direct RFQ koszt transportu powinien być oddzielną linią albo jasno określonym elementem ceny.

7. Dowody i dokumentacja

Agent-ready produkt powinien być nie tylko dobrze opisany.

Powinien być udowodniony.

Najważniejsza zasada brzmi:

Twierdzenie o produkcie powinno prowadzić do dokumentu, badania albo źródła, które je potwierdza.

7.1. TDS

Technical Data Sheet powinien być powiązany z:

konkretnym produktem,
wersją,
datą,
językiem,
producentem.

Kluczowe parametry nie powinny istnieć wyłącznie w PDF-ie. Należy przenieść je również do struktury danych produktu.

7.2. SDS

Safety Data Sheet dotyczy produktów, dla których karta charakterystyki jest właściwym dokumentem.

Rekord powinien zawierać:

język,
kraj lub rynek,
numer wersji,
datę aktualizacji,
substancję lub produkt,
wystawcę,
status ważności.

7.3. Instrukcja

Instrukcje warto rozdzielić na:

instalację,
obsługę,
bezpieczeństwo,
konserwację,
diagnostykę,
czyszczenie,
wymianę części.

Agent powinien móc pobrać właściwą instrukcję dla konkretnego modelu i wersji.

7.4. Deklaracje

Mogą to być między innymi:

deklaracje zgodności,
deklaracje właściwości,
deklaracje materiałowe,
oświadczenia dostawcy,
deklaracje środowiskowe,
dokumenty dotyczące recyklatu.

Każdy dokument powinien wskazywać:

czego dotyczy,
kto go wystawił,
jaki jest zakres,
od kiedy obowiązuje,
czy został zastąpiony.

7.5. Certyfikaty

Certyfikat powinien być powiązany z:

firmą,
zakładem,
procesem,
rodziną produktów,
konkretnym produktem.

Agent nie powinien zakładać, że certyfikat firmy automatycznie potwierdza właściwość każdego produktu.

7.6. Rysunki

Rysunki techniczne powinny mieć:

numer,
rewizję,
jednostki,
skalę,
datę,
status zatwierdzenia,
wskazanie produktu.

Warto udostępniać format czytelny dla człowieka oraz format możliwy do wykorzystania przez systemy CAD.

7.7. Zdjęcia

Każde zdjęcie powinno mieć:

identyfikator produktu,
typ ujęcia,
wersję,
opis,
prawa do wykorzystania,
datę.

Należy rozróżniać:

zdjęcie konkretnego produktu,
zdjęcie wariantu,
wizualizację,
zdjęcie poglądowe,
przykład zastosowania.

7.8. Wideo

Wideo może potwierdzać:

sposób działania,
wydajność,
instalację,
zastosowanie,
przebieg testu,
serwis.

Agent-ready rekord powinien zawierać transkrypcję i opis scen, ponieważ sam obraz wideo nie jest wystarczającym źródłem danych.

7.9. Case studies

Case study powinno wskazywać:

problem,
zastosowany produkt,
warunki,
zakres wdrożenia,
rezultat,
ograniczenia.

Nie należy przedstawiać case study jako uniwersalnego dowodu, że produkt osiągnie ten sam rezultat w każdej firmie.

7.10. Protokoły testowe

Protokół powinien zawierać:

produkt i wersję,
metodę,
warunki,
datę,
laboratorium lub osobę wykonującą test,
wynik,
kryterium zaliczenia,
załączniki.

Evidence Graph

Najlepszy model nie polega na folderze PDF.

Polega na grafie dowodów:

PRODUKT
→ WERSJA
→ PARAMETR LUB TWIERDZENIE
→ DOKUMENT
→ WYSTAWCA
→ METODA
→ DATA
→ ZAKRES OBOWIĄZYWANIA

Przykład:

Produkt: Taśma PET SKU-123
Twierdzenie: wytrzymałość 5500 N
Dokument: raport testowy TEST-2026-014
Metoda: EN-XYZ
Data: 2026-05-14
Status: ważny

8. Polityki handlowe i posprzedażowe

Produkt agent-ready musi zawierać nie tylko cechy i cenę.

Agent zakupowy ocenia również ryzyko po zakupie.

8.1. Gwarancja

Należy określić:

czas trwania,
moment rozpoczęcia,
zakres,
wyłączenia,
wymagane warunki użytkowania,
sposób zgłoszenia,
region obowiązywania.

8.2. Serwis

Dane serwisowe mogą obejmować:

obszar działania,
godziny przyjmowania zgłoszeń,
czas reakcji,
dostępność zdalnego wsparcia,
dostępność serwisu na miejscu,
stawki,
pakiety SLA,
wymagane kwalifikacje.

8.3. Zwroty

Należy jednoznacznie wskazać:

czy zwroty B2B są dopuszczalne,
dla jakich produktów,
w jakim terminie,
w jakim stanie,
kto ponosi koszt transportu,
czy dotyczy to produktów wykonywanych na zamówienie.

8.4. Reklamacje

Procedura powinna określać:

kanał zgłoszenia,
wymagane dane,
zdjęcia lub próbki,
numer partii,
termin zgłoszenia,
sposób rozpatrzenia,
możliwe rozwiązania.

8.5. Dostawa

Polityka dostawy powinna obejmować:

terminy,
odpowiedzialność,
awizację,
rozładunek,
uszkodzenia transportowe,
częściowe dostawy,
dokumenty dostawy.

8.6. Uruchomienie

Dla maszyn i systemów należy opisać:

czy uruchomienie jest obowiązkowe,
kto je wykonuje,
co musi przygotować klient,
ile trwa,
czy jest w cenie,
jakie dokumenty powstają po uruchomieniu.

8.7. Szkolenie

Należy określić:

formę,
liczbę osób,
język,
zakres,
czas,
miejsce,
możliwość certyfikacji,
koszt.

8.8. Części zamienne

Agent powinien móc sprawdzić:

okres dostępności części,
listę części eksploatacyjnych,
części krytyczne,
zestawy serwisowe,
kompatybilność,
terminy dostaw,
modele wycofane.

9. Interfejs agentowy

Uporządkowane dane nie wystarczą, jeżeli można je odczytać tylko ręcznie ze strony.

Produkt agent-ready potrzebuje warstwy dostępu maszynowego.

9.1. Feed produktowy

Feed jest najprostszym sposobem przekazywania większej liczby produktów.

Może występować jako:

JSON,
XML,
CSV,
plik branżowy,
pełny eksport,
aktualizacja przyrostowa.

Powinien zawierać:

schema_version
generated_at
product_id
changed_at
change_type

Należy zapewnić:

dokumentację schematu,
wersjonowanie,
identyfikację usuniętych produktów,
częstotliwość aktualizacji,
kontrolę błędów.

9.2. API

Minimalne API produktowe może udostępniać:

GET /products/{id}
GET /products/{id}/availability
GET /products/{id}/documents
GET /products/{id}/compatibility
GET /products/{id}/substitutes
POST /quotes
GET /quotes/{id}
GET /orders/{id}/status

API powinno zwracać jednoznaczne błędy, na przykład:

produkt nie istnieje,
produkt wycofany,
wymagane dodatkowe dane,
brak uprawnień,
wycena wymaga człowieka.

9.3. MCP server

MCP umożliwia serwerom udostępnianie agentom narzędzi i zasobów. Narzędzia mogą wykonywać działania, na przykład wywoływać API, sprawdzać bazę albo przeprowadzać kalkulację, natomiast resources mogą udostępniać pliki, dane i inne źródła kontekstu.

Przykładowe narzędzia MCP:

search_products
get_product_details
check_compatibility
find_substitute
check_availability
calculate_freight
create_rfq
create_quote
get_documents
get_order_status

Każde narzędzie powinno mieć:

jednoznaczną nazwę,
opis,
schemat wejścia,
schemat wyniku,
walidację,
wymagane uprawnienia,
klasę ryzyka.

Przykład:

{
  "name": "create_rfq",
  "description": "Tworzy zapytanie ofertowe dla wskazanego produktu",
  "inputSchema": {
    "type": "object",
    "required": [
      "product_id",
      "quantity",
      "delivery_location",
      "required_delivery_date"
    ],
    "properties": {
      "product_id": {
        "type": "string"
      },
      "quantity": {
        "type": "number",
        "minimum": 1
      },
      "delivery_location": {
        "type": "string"
      },
      "required_delivery_date": {
        "type": "string",
        "format": "date"
      }
    }
  }
}

Dostęp do wrażliwych zasobów i działań MCP powinien być objęty autoryzacją. Oficjalna dokumentacja MCP opisuje mechanizmy oparte na OAuth i rekomenduje autoryzację między innymi tam, gdzie potrzebny jest audyt, kontrola dostępu lub obsługa danych przedsiębiorstwa.

9.4. A2A Agent Card

A2A służy do komunikacji pomiędzy niezależnymi agentami. Protokół umożliwia odkrywanie kompetencji, wymianę ustrukturyzowanych danych, zarządzanie zadaniami i współpracę bez ujawniania wewnętrznej pamięci, narzędzi ani logiki agenta.

Agent Card dostawcy powinna określać:

nazwę agenta,
organizację,
adres usługi,
obsługiwane protokoły,
metody uwierzytelnienia,
dostępne umiejętności,
obsługiwane formaty,
wersję,
politykę bezpieczeństwa.

Przykładowe skills:

product.search
product.explain
compatibility.check
substitute.find
availability.check
rfq.accept
quote.prepare
quote.negotiate
documents.provide
order.status
service.request

Branżowy profil Direct RFQ może zostać zbudowany jako rozszerzenie A2A. Mechanizm rozszerzeń pozwala dodawać własne dane, wymagania i modele interakcji, przy czym agent deklaruje obsługiwane rozszerzenia w Agent Card.

9.5. Formularz RFQ

Formularz nadal jest potrzebny dla człowieka oraz firm bez integracji.

Powinien korzystać z tego samego schematu danych co API.

Nie należy budować osobno:

formularza,
API,
workflow dla e-maili,
procesu agenta.

Wszystkie kanały powinny prowadzić do jednego wewnętrznego obiektu RFQ.

9.6. Webhook

Webhook pozwala poinformować system kupującego o zmianie stanu.

Przykładowe zdarzenia:

rfq.received
rfq.validation_failed
rfq.needs_clarification
quote.created
quote.updated
quote.expiring
quote.accepted
order.created
order.shipped
delivery.delayed
document.updated

Każde zdarzenie powinno zawierać:

identyfikator,
czas,
typ,
numer RFQ lub zamówienia,
wersję danych,
podpis albo mechanizm weryfikacji.

9.7. Status zamówienia

Agent powinien móc sprawdzić nie tylko status ogólny, lecz również etapy:

zamówienie przyjęte,
weryfikacja,
rezerwacja materiału,
produkcja,
kontrola jakości,
przygotowanie wysyłki,
wysłane,
częściowo dostarczone,
dostarczone,
wstrzymane,
anulowane.

Status powinien zawierać:

status_code
status_description
changed_at
estimated_next_event
estimated_delivery
exception
required_action

10. Warstwa Direct RFQ

Agent-ready produkt musi jasno określać, jakie dane są potrzebne do uzyskania oferty.

Minimalny Direct RFQ

{
  "rfq_id": "RFQ-2026-00452",
  "schema_version": "1.0",
  "buyer": {
    "buyer_id": "BUYER-001",
    "country": "PL"
  },
  "supplier": {
    "supplier_id": "SUPPLIER-014"
  },
  "items": [
    {
      "product_id": "PROD-000142",
      "manufacturer_part_number": "MPN-12345",
      "quantity": 500,
      "unit": "piece",
      "acceptable_substitutes": false
    }
  ],
  "delivery": {
    "required_date": "2026-09-15",
    "country": "PL",
    "postal_code": "00-001",
    "city": "Warszawa",
    "incoterm": "DAP"
  },
  "commercial": {
    "currency": "PLN",
    "payment_terms": "30 days"
  },
  "response_due_at": "2026-08-20T12:00:00+02:00"
}

W bardziej złożonym zapytaniu należy dodać:

parametry techniczne,
załączniki,
wymagane dowody,
target price,
zakres zamienników,
prognozę wolumenu,
warunki negocjacji,
wymagania serwisowe,
kryteria wyboru.

UBL definiuje formalne dokumenty Request for Quotation i Quotation, w tym możliwość powiązania oferty z konkretnym RFQ i jego liniami. Catena-X rozwija natomiast semantyczny model oraz API przeznaczone do wymiany RFQ między systemami przemysłowymi.

Odpowiedź na Direct RFQ

Oferta powinna zwracać:

quote_id
rfq_id
product_id
offered_quantity
unit_price
currency
total_price
availability
lead_time
estimated_delivery
incoterm
payment_terms
valid_until
deviations
substitute_status
documents
binding_status
approval_required

Szczególnie ważne jest pole binding_status.

Możliwe wartości:

estimate,
indicative_quote,
firm_quote,
subject_to_approval,
binding_offer.

Agent nie może traktować kalkulacji orientacyjnej jako wiążącej oferty.

11. Bezpieczeństwo i poziomy dostępu

Agent-ready nie oznacza, że wszystkie informacje powinny być publiczne.

Warto wprowadzić cztery warstwy.

Warstwa publiczna

Może zawierać:

nazwę,
podstawowe parametry,
zastosowania,
publiczne dokumenty,
cenę publiczną,
ogólną dostępność.

Warstwa partnera

Może zawierać:

dokładniejsze dane techniczne,
pliki CAD,
szczegółowe dokumenty,
standardowe ceny B2B,
dostępność regionalną.

Warstwa klienta

Może zawierać:

ceny kontraktowe,
rabaty,
indywidualne SLA,
historię zakupów,
przydzielony zapas,
warunki płatności.

Warstwa poufna

Może zawierać:

koszty,
minimalną marżę,
reguły rabatowe,
moce produkcyjne,
scoring ryzyka,
dane wewnętrzne.

Agent powinien otrzymywać wyłącznie dane niezbędne do wykonania zadania.

Należy wdrożyć:

uwierzytelnianie,
autoryzację,
ograniczenia zakresu,
rejestrowanie działań,
limity częstotliwości,
daty wygaśnięcia uprawnień,
ochronę przed powtórzeniem komunikatu,
idempotency keys,
progi akceptacji człowieka.

12. Walidacja agent-ready produktu

Produkt nie jest gotowy tylko dlatego, że ma dużo pól.

Musi przejść testy.

Test tożsamości

Czy system odróżnia:

produkt,
wariant,
opakowanie zbiorcze,
akcesorium,
model wycofany?

Test klasyfikacji

Czy produkt może zostać znaleziony przez:

kategorię własną,
kod ETIM,
eCl@ss,
UNSPSC,
zastosowanie?

Test parametrów

Czy agent potrafi odpowiedzieć:

jaka jest wartość,
jaka jest jednostka,
jaka jest tolerancja,
czy produkt spełnia wymagane minimum?

Test kompatybilności

Czy system prawidłowo rozpoznaje:

produkt zgodny,
produkt warunkowo zgodny,
produkt niedopuszczalny?

Test handlowy

Czy agent potrafi ustalić:

minimalną ilość,
wielokrotność,
cenę lub tryb RFQ,
dostępność,
termin,
dostawę?

Test dowodów

Czy każde ważne twierdzenie prowadzi do:

dokumentu,
wersji,
daty,
wystawcy,
zakresu?

Test RFQ

Czy system odrzuci zapytanie, gdy:

brakuje ilości,
termin jest niemożliwy,
nie podano miejsca dostawy,
wymagany produkt jest wycofany,
agent nie ma uprawnienia do ceny?

Test bezpieczeństwa

Czy agent może:

uzyskać cudzą cenę kontraktową,
ominąć MOQ,
wymusić ujemną marżę,
zarezerwować zbyt duży zapas,
pobrać poufny dokument?

Jeżeli odpowiedź brzmi „tak”, produkt i proces nie są jeszcze agent-ready.

13. Poziomy dojrzałości produktu agent-ready

Poziom 0. Produkt dokumentowy

Dane znajdują się w PDF-ach, opisach i arkuszach.

Poziom 1. Produkt uporządkowany

Produkt ma:

identyfikatory,
podstawowe parametry,
dokumenty,
status.

Poziom 2. Produkt porównywalny

Ma:

klasyfikacje,
jednostki,
tolerancje,
warianty,
relacje,
zastosowania.

Poziom 3. Produkt agent-readable

Dane są dostępne przez:

feed,
dane strukturalne,
API,
formularz RFQ.

Poziom 4. Produkt agent-ready

Agent może:

sprawdzić produkt,
zweryfikować dokumenty,
sprawdzić kompatybilność,
ocenić dostępność,
utworzyć RFQ.

Poziom 5. Produkt agent-executable

Agent może w ramach uprawnień:

uzyskać ofertę,
negocjować określone warunki,
zaakceptować ofertę,
utworzyć zamówienie,
monitorować realizację.

14. Minimalny zakres wdrożenia

Firma nie musi od razu budować pełnego ekosystemu A2A.

Minimalny produkt agent-ready powinien mieć:

Tożsamość

stabilny product_id,
jednoznaczną nazwę,
producenta,
markę,
SKU,
MPN,
GTIN, jeżeli występuje,
wersję,
status.

Klasyfikację

kategorię własną,
co najmniej jedną klasyfikację zewnętrzną,
zastosowania.

Parametry

ustrukturyzowane wartości,
jednostki,
minimum i maksimum,
tolerancje tam, gdzie są potrzebne.

Relacje

warianty,
akcesoria,
kompatybilność,
zamienniki,
następców.

Handel

tryb ceny,
MOQ,
jednostkę zamówienia,
dostępność,
termin realizacji,
obszar dostawy.

Dowody

aktualny TDS lub specyfikację,
instrukcję,
wymagane deklaracje,
zdjęcia,
dokumenty przypisane do produktu.

Polityki

gwarancję,
dostawę,
reklamację,
serwis,
części zamienne.

Interfejs

stronę produktową,
feed lub API,
ustrukturyzowany formularz RFQ,
możliwość sprawdzenia statusu zapytania.

15. Checklista końcowa

Produkt B2B jest agent-ready, jeżeli agent może bez zgadywania odpowiedzieć na następujące pytania:

Tożsamość

Co to dokładnie za produkt?
Kto jest producentem?
Jaki jest model, SKU i MPN?
Czy jest to właściwa wersja?
Czy produkt jest aktywny?

Klasyfikacja

Do jakiej kategorii należy?
Jak jest klasyfikowany w ETIM, eCl@ss lub UNSPSC?
Do jakich zastosowań jest przeznaczony?

Parametry

Jakie ma właściwości?
W jakich jednostkach?
Jakie są tolerancje?
Czy spełnia wymagania kupującego?

Relacje

Jakie ma warianty?
Czego wymaga?
Z czym współpracuje?
Co jest zamiennikiem?
Czego nie wolno z nim łączyć?

Handel

Czy ma cenę publiczną, czy wymaga RFQ?
Jakie jest MOQ?
Czy jest dostępny?
Jaki jest termin?
Gdzie może zostać dostarczony?
Jak liczony jest transport?

Dowody

Jakie dokumenty potwierdzają parametry?
Czy dokumenty są aktualne?
Czy dotyczą konkretnej wersji?
Kto je wystawił?

Polityki

Jaka jest gwarancja?
Jak działa serwis?
Czy produkt można zwrócić?
Jak wygląda reklamacja?
Czy dostępne są części?

Interfejs

Czy dane są dostępne w feedzie lub API?
Czy agent może pobrać dokumenty?
Czy może utworzyć RFQ?
Czy może otrzymać ofertę?
Czy może sprawdzić status zamówienia?

Podsumowanie

Agent-ready produkt B2B nie jest treścią przygotowaną wyłącznie pod wyszukiwarkę ani chatbotem dodanym do strony.

Jest kompletnym, ustrukturyzowanym i kontrolowanym cyfrowym modelem produktu.

Powinien łączyć:

Tożsamość → Klasyfikację → Parametry → Relacje → Handel → Dowody → Polityki → Działania

Dopiero wtedy Direct RFQ może działać bez ciągłego ręcznego wyjaśniania:

którego produktu dotyczy zapytanie,
jaki wariant jest potrzebny,
czy produkt jest kompatybilny,
jaka jest minimalna ilość,
jakie dokumenty obowiązują,
czy cena jest wiążąca,
czy agent ma prawo zaakceptować ofertę.

Najważniejsza zmiana polega na przejściu od karty produktu do cyfrowego kontraktu danych i możliwości.

Tradycyjna strona mówi:

Oto nasz produkt.

Produkt agent-ready mówi:

Oto jednoznaczna tożsamość produktu, jego parametry, zastosowania, ograniczenia, relacje, dowody, warunki handlowe oraz bezpieczne działania, które możesz wykonać.

To właśnie taki produkt może zostać znaleziony, zrozumiany, zweryfikowany, wyceniony i zamówiony przez człowieka, system zakupowy albo agenta AI.

kontakt@salesbot.pl