Direct RFQ

Direct RFQ dziś i jutro: praktyczny przewodnik krok po kroku dla polskiego rynku B2B

Przez wiele lat proces zapytania ofertowego w polskich firmach wyglądał podobnie.

Kupujący przygotowuje specyfikację, przesyła wiadomość e-mail lub plik PDF, a następnie czeka, aż dostawca sprawdzi dostępność, policzy cenę, zweryfikuje termin dostawy i przygotuje ofertę. Po drodze dane są wielokrotnie przepisywane między pocztą elektroniczną, arkuszami Excel, systemem ERP, CRM i dokumentem ofertowym.

Direct RFQ zmienia tę architekturę.

Przekształca zapytanie ofertowe z dokumentu przeznaczonego głównie dla człowieka w ustrukturyzowaną, maszynowo czytelną transakcję, która może być przekazywana bezpośrednio między systemami kupującego i dostawcy albo między reprezentującymi ich agentami AI.

Direct RFQ nie jest jeszcze jednym, powszechnie obowiązującym standardem technicznym. To rozwijający się model operacyjny wykorzystujący istniejące systemy zakupowe, ERP, API, EDI, platformy sourcingowe, Model Context Protocol, komunikację A2A i narzędzia Agentic Commerce.

Dla polskich firm najważniejsze jest jednak to, że wdrażanie Direct RFQ nie musi zaczynać się od budowania autonomicznych agentów AI.

Powinno zaczynać się od uporządkowania danych, zasad wyceny i procesu obsługi zapytań.


Czym jest Direct RFQ?

Direct RFQ to prywatne, ustrukturyzowane zapytanie ofertowe kierowane bezpośrednio do wybranego dostawcy.

Różni się od Broadcast RFQ, czyli otwartego zapytania publikowanego na giełdzie, marketplace B2B albo platformie zakupowej i udostępnianego wielu potencjalnym dostawcom.

W modelu Direct RFQ:

  • kupujący wskazuje konkretnego dostawcę,
  • obie strony mogą zostać zweryfikowane,
  • zapytanie ma określoną strukturę danych,
  • warunki handlowe pozostają poufne,
  • system dostawcy może automatycznie przetworzyć zapytanie,
  • odpowiedź może zostać zwrócona w formacie czytelnym zarówno dla człowieka, jak i maszyny.

Direct RFQ może być przesyłane przez:

  • API,
  • EDI,
  • XML,
  • JSON,
  • system zakupowy,
  • integrację ERP,
  • platformę B2B,
  • bezpieczny konektor danych,
  • narzędzie MCP,
  • endpoint agenta A2A.

Direct RFQ nie oznacza zatem wyłącznie formularza internetowego.

To model, w którym zapytanie staje się uporządkowanym obiektem biznesowym, mogącym uruchomić po stronie dostawcy proces identyfikacji produktu, kalkulacji ceny, sprawdzania magazynu, planowania produkcji, logistyki i przygotowania dokumentacji.


Krok 1. Wykrycie potrzeby zakupowej

Tradycyjne RFQ zaczyna się zazwyczaj wtedy, gdy człowiek zauważy brak materiału, części lub usługi.

Direct RFQ może rozpocząć się automatycznie, gdy potrzebę wykryje system.

Triggerem może być:

  • spadek zapasu poniżej poziomu minimalnego,
  • nowe zlecenie produkcyjne,
  • planowany przegląd maszyny,
  • awaria,
  • opóźnienie obecnego dostawcy,
  • wzrost prognozowanego zapotrzebowania,
  • uruchomienie nowego projektu,
  • wygaśnięcie umowy,
  • zmiana ceny surowca,
  • brak potwierdzenia dostawy.

Źródłem informacji może być:

  • ERP,
  • MRP,
  • WMS,
  • system utrzymania ruchu,
  • CRM,
  • platforma zakupowa,
  • system planowania produkcji,
  • arkusz kontrolny,
  • aplikacja magazynowa.

Jak wygląda to dziś?

System najczęściej tworzy:

  • zapotrzebowanie zakupowe,
  • zadanie dla działu zakupów,
  • alert,
  • projekt zamówienia,
  • wiadomość e-mail.

Jak może wyglądać jutro?

Agent zakupowy otrzyma cel:

Zabezpiecz dostawę 500 sztuk zatwierdzonego komponentu do 15 sierpnia, w ramach budżetu, polityki zakupowej i listy autoryzowanych dostawców.

Agent nie musi od razu podejmować decyzji zakupowej. Najpierw powinien zebrać kontekst i przygotować kompletne zapytanie.


Krok 2. Przekształcenie potrzeby w ustrukturyzowane RFQ

Sama informacja „potrzebujemy taśmy”, „proszę o cenę części” albo „potrzebna owijarka” nie stanowi jeszcze wartościowego zapytania ofertowego.

Direct RFQ wymaga określonego zestawu danych.

Podstawowe zapytanie powinno zawierać:

  • numer RFQ,
  • dane kupującego,
  • dane wybranego dostawcy,
  • nazwę produktu lub usługi,
  • SKU, numer katalogowy, MPN albo opis techniczny,
  • ilość,
  • jednostkę miary,
  • wymagany termin dostawy,
  • miejsce dostawy,
  • walutę,
  • warunki dostawy,
  • termin odpowiedzi.

W bardziej złożonych zakupach potrzebne mogą być także:

  • rysunki techniczne,
  • pliki CAD,
  • specyfikacje materiałowe,
  • tolerancje,
  • wymagania jakościowe,
  • wymagane normy,
  • certyfikaty,
  • badania,
  • dokumenty regulacyjne,
  • warunki płatności,
  • dopuszczalne zamienniki,
  • prognozowany wolumen roczny,
  • wymagania dotyczące opakowania,
  • sposób rozładunku,
  • wymagania serwisowe.

Przykład dla materiałów opakowaniowych

Agent lub system powinien zebrać między innymi:

  • rodzaj materiału,
  • szerokość,
  • grubość,
  • długość nawoju,
  • średnicę tulei,
  • kolor,
  • wytrzymałość,
  • wymagany procent recyklatu,
  • sposób pakowania,
  • liczbę rolek na palecie,
  • dokumenty PPWR,
  • miejsce i termin dostawy.

Przykład dla maszyny pakującej

Potrzebne mogą być:

  • rodzaj produktu,
  • wymiary,
  • ciężar,
  • oczekiwana wydajność,
  • sposób podawania,
  • warunki środowiskowe,
  • rodzaj materiału eksploatacyjnego,
  • sposób integracji z linią,
  • wymagania bezpieczeństwa,
  • dostępna przestrzeń,
  • oczekiwany termin uruchomienia.

Dziś

W wielu firmach dane są częściowo uporządkowane w systemie zakupowym, ale do dostawcy nadal trafia wiadomość e-mail lub PDF.

Jutro

Podstawowym nośnikiem będzie sam rekord danych. PDF stanie się jedynie czytelną dla człowieka reprezentacją zapytania.


Krok 3. Walidacja zapytania przed wysłaniem

Niekompletne RFQ jest jedną z głównych przyczyn wydłużania procesu ofertowego.

Przed wysłaniem system powinien sprawdzić:

  • czy wszystkie wymagane pola zostały uzupełnione,
  • czy jednostki są poprawne,
  • czy ilość jest logiczna,
  • czy termin dostawy jest możliwy,
  • czy numer produktu istnieje,
  • czy załączono wymaganą dokumentację,
  • czy wymagania techniczne nie są sprzeczne,
  • czy zapytanie mieści się w polityce zakupowej firmy.

Agent AI może pomóc w odczytywaniu treści, dokumentów i wiadomości e-mail. Nie powinien jednak samodzielnie decydować, że dane są poprawne.

Końcowa walidacja powinna być oparta na twardych zasadach.

Przykładowe reguły:

  • ilość musi być większa od zera,
  • termin dostawy nie może przypadać przed terminem składania ofert,
  • waluta musi pochodzić z zatwierdzonego słownika,
  • zamiennik musi spełniać wymagane parametry,
  • wartość zakupu musi mieścić się w limicie osoby lub agenta,
  • produkt wymagający certyfikatu nie może być kupiony bez właściwego dokumentu.

Najważniejsze pytanie nie brzmi:

Czy wszystkie pola zostały wypełnione?

Powinno brzmieć:

Czy na podstawie tych informacji dostawca może bezpiecznie i odpowiedzialnie przygotować wykonalną ofertę?


Krok 4. Wybór i uwierzytelnienie dostawcy

Direct RFQ jest komunikacją adresowaną.

Kupujący powinien wiedzieć:

  • który dostawca otrzyma zapytanie,
  • czy znajduje się na liście zatwierdzonych partnerów,
  • czy obsługuje daną kategorię,
  • czy dostarcza do wskazanego regionu,
  • przez jaki kanał przyjmuje RFQ,
  • jak należy potwierdzić tożsamość obu stron.

W modelu A2A agent dostawcy może publikować własną Agent Card, czyli maszynowo czytelną kartę kompetencji.

Może ona wskazywać, że agent:

  • przyjmuje RFQ dla określonych grup produktów,
  • sprawdza dostępność,
  • przygotowuje ceny kontraktowe,
  • proponuje zamienniki,
  • udostępnia dokumentację,
  • odpowiada na pytania techniczne,
  • umożliwia złożenie zamówienia.

Dziś

Dostawcy wybierani są najczęściej z listy zatwierdzonych kontrahentów w ERP albo na podstawie doświadczenia kupca.

Jutro

Wybór może uwzględniać:

  • status zatwierdzonego dostawcy,
  • tożsamość organizacji,
  • kompetencje agenta,
  • dostępny zakres dostaw,
  • historię realizacji,
  • jakość danych,
  • kompletność dokumentów,
  • wiarygodność deklarowanych terminów,
  • uprawnienia do zawarcia konkretnej transakcji.

Krok 5. Wysłanie Direct RFQ

Po walidacji zapytanie jest przesyłane bezpośrednio do dostawcy.

Uproszczony komunikat może zawierać:

{
  "rfq_id": "RFQ-2026-00841",
  "buyer_id": "BUYER-PL-001",
  "supplier_id": "SUPPLIER-EU-014",
  "currency": "PLN",
  "delivery_terms": "DDP",
  "response_due": "2026-07-14T14:00:00+02:00",
  "items": [
    {
      "manufacturer_part_number": "SKU-123",
      "quantity": 500,
      "unit": "piece",
      "required_delivery_date": "2026-08-15",
      "delivery_location": "Warszawa, Polska"
    }
  ]
}

Zapytanie może być przesłane przez:

  • REST API,
  • integrację ERP,
  • EDI,
  • platformę zakupową,
  • broker komunikatów,
  • narzędzie MCP,
  • komunikat zadaniowy A2A.

Sam format transportu nie jest najważniejszy.

Kluczowe są:

  • identyfikacja stron,
  • autoryzacja,
  • poufność,
  • integralność danych,
  • potwierdzenie odbioru,
  • możliwość audytu,
  • wersjonowanie komunikatu.

Krok 6. Agent dostawcy uruchamia wewnętrzne systemy

Agent dostawcy nie powinien wymyślać odpowiedzi na podstawie ogólnej wiedzy modelu językowego.

Jego zadaniem jest koordynowanie systemów, które przechowują wiarygodne dane biznesowe.

Może korzystać z:

  • PIM — dane produktowe,
  • ERP — koszty, kontrakty, warunki klienta,
  • WMS — stan magazynowy,
  • MRP lub APS — dostępne moce produkcyjne,
  • CPQ — konfiguracja i kalkulacja,
  • CRM — historia relacji i ustalenia,
  • TMS — koszty transportu,
  • DMS — dokumentacja,
  • systemu ryzyka — limit kredytowy i weryfikacja,
  • systemu compliance — certyfikaty i zgodność.

W tej warstwie istotną rolę może pełnić Model Context Protocol.

Różnica między A2A a MCP

  • A2A łączy agenta kupującego z agentem dostawcy.
  • MCP łączy agenta z narzędziami, danymi i systemami przedsiębiorstwa.

Przykładowo agent kupującego wysyła przez A2A zadanie:

Przygotuj ofertę na 500 sztuk komponentu z dostawą do Warszawy.

Agent dostawcy używa MCP lub API, aby:

  • sprawdzić magazyn,
  • pobrać kartę produktu,
  • odczytać warunki klienta,
  • policzyć transport,
  • zweryfikować dokumenty,
  • utworzyć ofertę.

Krok 7. Kalkulacja oferty według twardych reguł

Model językowy nie powinien być źródłem ceny, marży ani wiążącego terminu.

Oferta powinna być liczona przez zatwierdzony mechanizm biznesowy.

Kalkulacja może uwzględniać:

  • aktualny koszt produktu,
  • cenę surowca,
  • minimalną marżę,
  • rabat klienta,
  • ilość,
  • dostępny zapas,
  • obciążenie produkcji,
  • koszt przezbrojenia,
  • transport,
  • termin płatności,
  • ryzyko kredytowe,
  • pilność,
  • wartość kontraktu.

Uproszczony model:

Cena oferty = koszt + marża + logistyka + ryzyko + finansowanie + konfiguracja – zatwierdzony rabat

Agent może:

  • zebrać dane,
  • wybrać właściwe narzędzia,
  • uruchomić kalkulację,
  • wyjaśnić wynik,
  • zaproponować alternatywę.

Nie powinien mieć możliwości ominięcia polityki cenowej.

Twarde zabezpieczenia

System powinien uwzględniać:

  • minimalną marżę,
  • maksymalny rabat,
  • maksymalną wartość zamówienia,
  • limit kredytowy,
  • limit rezerwacji magazynu,
  • dopuszczalne rynki,
  • warunki transportu,
  • próg akceptacji człowieka.

Dziś

Automatyczna wycena jest stosowana głównie dla:

  • produktów standardowych,
  • prostych usług,
  • transportu,
  • konfiguracji oprogramowania,
  • wybranych procesów produkcyjnych.

Jutro

Cena będzie coraz częściej zależna od kontekstu.

Dostawca może zaproponować lepsze warunki, gdy:

  • ma wolne moce produkcyjne,
  • zamówienie pasuje do istniejącej partii,
  • transport można połączyć z inną dostawą,
  • klient zaakceptuje inny termin,
  • dostępny jest zamiennik,
  • warunki płatności są korzystniejsze.

Krok 8. Zwrot maszynowo czytelnej oferty

Odpowiedź dostawcy powinna zawierać więcej niż cenę.

Kompletna oferta powinna obejmować:

  • numer oferty,
  • odniesienie do RFQ,
  • oferowany produkt,
  • ilość,
  • cenę jednostkową,
  • wartość całkowitą,
  • walutę,
  • termin dostawy,
  • czas realizacji,
  • koszt transportu,
  • podatki,
  • Incoterms,
  • warunki płatności,
  • termin ważności oferty,
  • odstępstwa od specyfikacji,
  • informacje o zamienniku,
  • dokumenty,
  • założenia i wyłączenia.

Warto rozróżniać:

  • dane potwierdzone,
  • dane obliczone,
  • dane szacunkowe,
  • warunki wymagające zatwierdzenia.

Dzięki temu orientacyjna kalkulacja nie zostanie pomylona z wiążącą ofertą handlową.


Krok 9. Porównanie ofert według wielu kryteriów

Direct RFQ jest szczególnie wartościowe, gdy prywatne zapytanie trafia do kilku zatwierdzonych dostawców.

Agent kupującego może ujednolicić odpowiedzi i porównać:

  • cenę jednostkową,
  • koszt całkowity,
  • transport,
  • termin dostawy,
  • warunki płatności,
  • jakość,
  • ryzyko,
  • dokumentację,
  • serwis,
  • gwarancję,
  • zgodność regulacyjną,
  • wpływ środowiskowy.

Najtańsza oferta nie zawsze jest najlepsza.

W przypadku awarii kluczowy może być termin.

Przy produkcie regulowanym ważniejsza może być dokumentacja.

W przypadku maszyny znaczenie może mieć serwis, czas reakcji i dostępność części.

Przykładowy model oceny:

Wynik dostawcy = cena + termin + jakość + ryzyko + zgodność + serwis

Wagi powinny zależeć od konkretnego zakupu.


Krok 10. Negocjacja w ramach guardrails

Nie każde Direct RFQ wymaga negocjacji.

W standardowym zakupie agent może zaakceptować albo odrzucić ofertę.

W bardziej złożonym procesie agenci mogą negocjować:

  • cenę,
  • ilość,
  • termin,
  • długość kontraktu,
  • płatność,
  • transport,
  • minimalne zamówienie,
  • rabat,
  • opakowanie,
  • poziom serwisu.

Negocjacja musi być ograniczona zasadami.

Agent kupującego może otrzymać:

  • maksymalną cenę,
  • preferowany termin,
  • dopuszczalne zamienniki,
  • maksymalną liczbę rund,
  • zakres możliwych ustępstw.

Agent sprzedającego może otrzymać:

  • minimalną marżę,
  • maksymalny rabat,
  • dopuszczalne terminy,
  • dozwolone warunki płatności,
  • minimalny wolumen,
  • maksymalną rezerwację zapasu.

W standardowych, powtarzalnych zakupach negocjacja może przebiegać automatycznie.

Przy zakupach strategicznych, technicznych lub wysokiego ryzyka człowiek powinien zachować decydującą rolę.


Krok 11. Akceptacja człowieka tam, gdzie jest potrzebna

Direct RFQ nie powinno oznaczać niekontrolowanego kupowania przez AI.

Najlepszy model to:

zero-touch dla standardowych transakcji, człowiek przy wyjątkach.

Automatyczna akceptacja może być dopuszczalna, gdy:

  • produkt jest zatwierdzony,
  • dostawca jest zatwierdzony,
  • ilość mieści się w normie,
  • wartość jest poniżej limitu,
  • marża jest zabezpieczona,
  • nie występują odstępstwa techniczne,
  • dokumentacja jest kompletna,
  • termin jest możliwy.

Człowiek powinien zostać zaangażowany, gdy:

  • wartość jest nietypowo wysoka,
  • pojawia się nowy dostawca,
  • zaproponowano zamiennik,
  • brakuje dokumentu,
  • wymagania są niejasne,
  • cena odbiega od zakresu,
  • przekroczono limit kredytowy,
  • produkt jest krytyczny dla bezpieczeństwa,
  • potrzebna jest nowa umowa,
  • transakcja dotyczy maszyny lub projektu indywidualnego.

Krok 12. Przekształcenie zaakceptowanej oferty w zamówienie

Po akceptacji oferty dane nie powinny być ponownie przepisywane.

Oferta może zostać automatycznie przekształcona w:

  • zamówienie zakupu w ERP kupującego,
  • zamówienie sprzedaży w ERP dostawcy,
  • rezerwację magazynową,
  • zlecenie produkcyjne,
  • zlecenie transportowe,
  • harmonogram dostaw,
  • dokument kontraktowy.

System powinien zachować pełne powiązanie między:

  • intencją zakupową,
  • RFQ,
  • ofertą,
  • negocjacją,
  • akceptacją,
  • zamówieniem,
  • dostawą,
  • fakturą.

Pozwala to odtworzyć nie tylko, co kupiono, ale również:

  • dlaczego wybrano daną ofertę,
  • jakie dane wykorzystano,
  • jaka polityka obowiązywała,
  • kto lub co podjęło decyzję,
  • gdzie wystąpiła akceptacja człowieka.

Jak wdrożyć Direct RFQ w polskiej firmie już dziś

Firma nie musi od razu wdrażać autonomicznych agentów.

Najlepsza ścieżka jest etapowa.

Etap 1. Ustandaryzuj zapytania ofertowe

Określ:

  • pola obowiązkowe,
  • pola opcjonalne,
  • dane zależne od kategorii,
  • wymagane dokumenty,
  • jednostki miary,
  • identyfikatory,
  • reguły walidacji.

Najlepiej zacząć od jednej kategorii.

Dobre przykłady:

  • materiały opakowaniowe,
  • części zamienne,
  • produkty MRO,
  • transport,
  • materiały eksploatacyjne,
  • standardowe komponenty,
  • powtarzalne zamówienia produkcyjne.

Nie warto zaczynać od złożonej linii technologicznej albo nietypowego projektu Engineering-to-Order.

Etap 2. Zbuduj jeden punkt przyjmowania RFQ

Firma powinna móc przyjmować zapytania z:

  • formularza,
  • poczty elektronicznej,
  • arkusza,
  • pliku PDF,
  • platformy zakupowej,
  • API,
  • agenta AI.

Niezależnie od źródła dane powinny zostać przekształcone do jednego modelu wewnętrznego.

To ważny etap przejściowy:

na zewnątrz firma może nadal przyjmować e-maile, ale wewnątrz powinna pracować na uporządkowanych danych.

Etap 3. Połącz dane produktowe i handlowe

RFQ powinno mieć dostęp do:

  • identyfikatorów,
  • parametrów,
  • cenników,
  • rabatów,
  • stanów magazynowych,
  • terminów,
  • dokumentacji,
  • warunków klienta,
  • danych logistycznych.

To podstawa Agent-Ready Offer Optimization.

Czym jest Agent-Ready Offer Optimization?

To proces przygotowania produktu i oferty tak, aby agent mógł je:

  • znaleźć,
  • zrozumieć,
  • porównać,
  • zweryfikować,
  • wycenić,
  • wykorzystać w transakcji.

Agent-ready oferta powinna obejmować:

  • spójne identyfikatory,
  • uporządkowane atrybuty,
  • jasne jednostki,
  • zasady wyceny,
  • progi ilościowe,
  • terminy,
  • dostępność,
  • kompatybilność,
  • zamienniki,
  • dokumentację,
  • gwarancję,
  • serwis,
  • wymagania do RFQ,
  • maszynowo dostępne działania.

Etap 4. Zautomatyzuj walidację

Wprowadź kontrolę:

  • kompletności,
  • poprawności produktu,
  • zgodności handlowej,
  • wykonalności technicznej,
  • uprawnień klienta,
  • dostępności dokumentów.

Etap 5. Automatyzuj przygotowanie oferty

Na początku system może tworzyć projekt oferty do akceptacji handlowca.

Później standardowe transakcje mogą być wysyłane automatycznie.

Etap 6. Udostępnij bezpieczne funkcje

Przez API lub MCP można udostępnić wybrane działania:

  • sprawdzenie dostępności,
  • pobranie danych produktu,
  • obliczenie transportu,
  • utworzenie oferty,
  • pobranie dokumentów,
  • sprawdzenie statusu zamówienia.

Nie oznacza to wystawiania całego ERP do internetu.

Należy udostępnić wyłącznie kontrolowane funkcje biznesowe.

Etap 7. Dodaj komunikację A2A

Po uporządkowaniu danych i reguł firma może wdrożyć agenta, który jasno publikuje:

  • swoją tożsamość,
  • obsługiwane kategorie,
  • formaty RFQ,
  • dostępne działania,
  • wymagania bezpieczeństwa,
  • sposób eskalacji.

Etap 8. Wprowadzaj ograniczoną autonomię

Agent powinien samodzielnie obsługiwać tylko te przypadki, które mieszczą się w zatwierdzonych limitach.

Autonomię należy zwiększać na podstawie rzeczywistych wyników, a nie samej możliwości technologicznej.


Direct RFQ jutro

1. RFQ stanie się zdarzeniowe

Zapytanie coraz częściej będzie powstawało w wyniku zdarzenia:

  • spadku zapasu,
  • prognozowanej awarii,
  • opóźnienia,
  • zmiany ceny,
  • wzrostu popytu,
  • uruchomienia projektu.

Człowiek nie będzie musiał ręcznie zaczynać procesu.

2. RFQ stanie się ciągłe

Oferta nie zawsze będzie jednorazowym dokumentem.

Agent może stale sprawdzać:

  • aktualną cenę,
  • termin,
  • transport,
  • dostępność,
  • ryzyko,
  • kurs waluty,
  • możliwość użycia zamiennika.

Może to prowadzić do ciągłej renegocjacji.

3. Przedmiotem RFQ stanie się zdolność wykonawcza

Firmy będą pytać nie tylko o produkt, lecz również o:

  • godziny pracy maszyny,
  • wolne moce produkcyjne,
  • slot transportowy,
  • przestrzeń magazynową,
  • dostępność serwisu,
  • proces technologiczny.

Dostawca może także proaktywnie oferować niewykorzystaną moc.

4. Compliance stanie się częścią oferty

Przyszłe zapytanie nie będzie pytało tylko:

Czy możecie dostarczyć produkt?

Będzie pytało:

Czy możecie dostarczyć produkt wraz z kompletem wymaganych dowodów dla tego zastosowania, rynku i terminu?

Oferta może zawierać:

  • deklaracje,
  • certyfikaty,
  • wyniki badań,
  • dane środowiskowe,
  • dokumentację PPWR,
  • informacje o recyklacie,
  • SDS,
  • REACH,
  • CE,
  • EPD,
  • dane Digital Product Passport.

5. Tożsamość agenta stanie się warunkiem handlowym

Firma będzie musiała potwierdzić:

  • jaką organizację reprezentuje agent,
  • jakie ma uprawnienia,
  • do jakich danych może uzyskać dostęp,
  • jaki limit może wykorzystać,
  • czy może złożyć wiążące zamówienie.

Agent pytający o cenę katalogową potrzebuje innych uprawnień niż agent negocjujący warunki kontraktu.

6. Powstaną branżowe schematy RFQ

Uniwersalne pola handlowe będą wspólne, ale poszczególne branże będą wymagały własnych rozszerzeń.

Przykłady:

  • chemia: CAS, grade, SDS, REACH,
  • opakowania: materiał, grubość, recyklat, dokumentacja PPWR,
  • produkcja: CAD, tolerancje, proces,
  • transport: trasa, waga, objętość, termin,
  • maszyny: wydajność, integracja, bezpieczeństwo,
  • MRO: numer części, kompatybilność, numer seryjny urządzenia.

7. Strona internetowa nie będzie jedynym interfejsem sprzedaży

Ludzie nadal będą korzystać ze stron WWW.

Agenci będą korzystać z:

  • feedów,
  • API,
  • MCP,
  • endpointów A2A,
  • rejestrów kompetencji,
  • baz dokumentów.

Firma będzie potrzebowała dwóch interfejsów:

  • zrozumiałego i przekonującego dla człowieka,
  • uporządkowanego i wykonywalnego dla maszyny.

8. Najważniejszym KPI stanie się Time-to-Valid-Quote

Nie chodzi wyłącznie o szybkość odpowiedzi.

Kluczowy będzie czas potrzebny do przygotowania oferty, która jest:

  • kompletna,
  • technicznie wykonalna,
  • handlowo zatwierdzona,
  • udokumentowana,
  • możliwa do dostarczenia,
  • audytowalna,
  • gotowa do akceptacji.

Szybka, ale błędna oferta nie tworzy wartości.


Model dojrzałości Direct RFQ

Poziom 0. RFQ przez e-mail

Zapytanie jest przesyłane w wiadomości lub PDF-ie i obsługiwane ręcznie.

Poziom 1. Ustrukturyzowane RFQ cyfrowe

Formularz albo portal zbiera standaryzowane dane.

Poziom 2. RFQ połączone przez API

System kupującego i system dostawcy wymieniają zapytania i oferty.

Poziom 3. RFQ wspierane przez agenta

Agent analizuje treść, uzupełnia dane, waliduje zapytanie i przygotowuje ofertę.

Poziom 4. Ograniczone autonomiczne RFQ

Agenci wysyłają, analizują i negocjują oferty w granicach zatwierdzonych polityk.

Poziom 5. Zamknięta pętla Agentic Commerce

Proces od wykrycia potrzeby do zamówienia, dostawy i rozliczenia jest koordynowany maszynowo, a ludzie zarządzają wyjątkami i strategią.

Polska firma nie powinna próbować przechodzić bezpośrednio z poziomu 0 na poziom 5.

Właściwa kolejność brzmi:

najpierw struktura, później integracja, następnie automatyzacja, a dopiero później agenci.


Checklista gotowości do Direct RFQ

Firma jest gotowa rozpocząć wdrożenie, jeżeli potrafi odpowiedzieć twierdząco na większość poniższych pytań:

  • Czy produkty i usługi są jednoznacznie identyfikowane?
  • Czy wiadomo, jakie dane są niezbędne do przygotowania oferty?
  • Czy parametry techniczne są uporządkowane?
  • Czy jednostki i terminologia są spójne?
  • Czy zasady kalkulacji są opisane?
  • Czy można wiarygodnie sprawdzić stan i termin?
  • Czy dostępne są warunki indywidualne dla klienta?
  • Czy dokumenty są przypisane do właściwych produktów?
  • Czy określono limity akceptacji?
  • Czy nietypowa transakcja może zostać automatycznie zatrzymana?
  • Czy można odtworzyć źródło każdej ceny?
  • Czy człowiek może przejąć proces?

Jeżeli odpowiedź brzmi „nie”, firma nie ma przede wszystkim problemu z AI.

Ma problem z danymi, procesem i zarządzaniem.


Podsumowanie

Direct RFQ dziś jest ustrukturyzowaną metodą bezpośredniej wymiany prywatnych zapytań ofertowych między zaufanymi partnerami biznesowymi.

Direct RFQ jutro stanie się jednym z podstawowych mechanizmów Agentic Commerce.

Docelowy proces może wyglądać tak:

Intencja → Specyfikacja → Walidacja → Zaufanie → Direct RFQ → Oferta → Negocjacja → Akceptacja → Zamówienie → Realizacja

Agent zakupowy wykrywa potrzebę.

System tworzy kompletną specyfikację.

A2A łączy agenta kupującego z agentem dostawcy.

MCP daje agentom kontrolowany dostęp do narzędzi i danych.

Deterministyczny silnik wylicza cenę.

Guardrails chronią marżę, uprawnienia, zgodność i bezpieczeństwo.

Człowiek pojawia się tam, gdzie transakcja wykracza poza standard.

Direct RFQ nie eliminuje relacji w B2B.

Eliminuje zbędne opóźnienia, wielokrotne przepisywanie danych i braki informacyjne, które dziś otaczają te relacje.

Przewagę osiągnie nie firma mająca najbardziej efektownego chatbota.

Wygra firma, której produkty, kompetencje, ceny, dokumenty i zasady handlowe są gotowe do zrozumienia i bezpiecznego wykorzystania zarówno przez ludzi, jak i maszyny.


kontakt@salesbot.pl


Synthosa