Model Bot-to-Bot: Shopping Bot klienta i Sales Bot sklepu — jak to działa
Handel nie jest już zbiorem stron produktowych i formularzy, lecz dynamicznym ekosystemem agentów, w którym intencja spotyka się z możliwością i zamienia w wykonaną akcję. Model Bot-to-Bot to praktyczna architektura takiego ekosystemu: po jednej stronie Shopping Bot reprezentuje interes osoby lub zespołu kupującego (specyfikuje potrzeby, porównuje, negocjuje, decyduje), po drugiej Sales Bot reprezentuje sklep lub producenta (udostępnia encje produktowe, polityki, ceny, dostępność i — co najważniejsze — akcje transakcyjne). Wynikiem nie jest „odpowiedź”, lecz zrealizowany zakup z pełną zgodnością cen, dostępności, dostawy i SLA.
Dlaczego Bot-to-Bot?
Klasyczny e-commerce rozprasza uwagę: karta produktu, koszyk, rejestracja, adres, płatność, potwierdzenia. W modelu Bot-to-Bot cała ścieżka staje się jednym dialogiem dwóch agentów, a człowiek pełni rolę decydenta i audytora, zamiast „klikać” każdy krok. Z perspektywy biznesu to krótszy czas do zakupu, wyższa konwersja, mniej porzuceń i lepsza jakość decyzji, ponieważ Shopping Bot liczy pełny koszt posiadania, kompatybilności i czasy realizacji w czasie rzeczywistym, a Sales Bot gwarantuje wykonalność oferty.
Role agentów i zakres odpowiedzialności
Shopping Bot (po stronie klienta)
Definiuje intencję, ograniczenia i kryteria (budżet, termin, normy, gabaryty, kompatybilność, polityki firmy), tworzy shortlisty, przeprowadza konfigurowanie i CPQ, negocjuje warianty i SLA, a następnie domyka zakup lub przygotowuje ofertę do akceptacji w organizacji.
Sales Bot (po stronie sprzedawcy)
Ujawnia możliwości sklepu/producenta w formie manifestu agenta: katalog i encje (schema.org/Product, Offer, Service), polityki (dostawa, zwroty, gwarancja), stany i lead times, promocje, cenniki indywidualne B2B, a przede wszystkim warstwę ACTION (udokumentowane akcje: add-to-cart, choose-variant, configure-bundle, start-checkout, reserve Click & Collect, request-quote, confirm-quote, schedule-install, initiate-return).
Osiem faz dialogu Bot-to-Bot
- Intent Handshake — Shopping Bot przekłada opis potrzeby na specyfikację (brief zakupowy), Sales Bot potwierdza, że rozumie parametry i potrafi obsłużyć kategorię.
- Capability Discovery — Sales Bot przedstawia manifest: obsługiwane akcje, ograniczenia, standardy danych, limity, polityki prywatności i zgodności.
- Data Contract & Consent — strony uzgadniają minimalny zakres danych i uprawnień, w B2B także reguły budżetu i akceptacji.
- Retrieval & Shortlist — Shopping Bot odpytuje katalog semantycznie, Sales Bot zwraca zestaw kandydatów z uźródłowionymi parametrami i dostępnością.
- Configuration & CPQ — wspólna pętla konfiguracji: warianty, akcesoria, kompatybilność, rabaty, cenniki indywidualne, TCO i terminy dostaw.
- Offer & SLA — Sales Bot wystawia ofertę z warunkami (cena, lead time, gwarancja, instalacja), Shopping Bot ocenia i ewentualnie negocjuje kompromisy.
- Action & Checkout — akcje wykonywalne: dodanie do koszyka, rezerwacja Click & Collect, płatność, wystawienie zamówienia B2B lub umówienie instalacji.
- Fulfillment & Care — statusy zamówienia, faktury, dokumenty gwarancyjne, zwroty i wymiany, rekomendacje eksploatacyjne; wszystko dostępne dla obu agentów.
Protokół: tożsamość, bezpieczeństwo, stan
- Identyfikacja i autoryzacja: wymiana tokenów i uprawnień per akcja (zakres „read:catalog”, „act:checkout”, „b2b:quote”).
- Idempotencja: każde polecenie akcji ma identyfikator i semantykę powtórzeń, co eliminuje duplikaty zamówień.
- Maszyna stanów: CART → OFFER → CHECKOUT → PAYMENT_AUTH → FULFILLMENT → CARE/RETURN; zdarzenia są strumieniowane (np.
OFFER_CREATED,PAYMENT_AUTHORIZED,FULFILLMENT_CONFIRMED). - Obserwowalność: pełny ślad decyzji i dane do audytu (kto, co, kiedy, dlaczego), wyjaśnialność rekomendacji i kalkulacji.
Warstwa danych: encje i relacje
Sales Bot udostępnia spójną ontologię: Product, Offer, InventoryItem, Bundle, Accessory, Policy, ShippingOption, Service z relacjami compatibleWith, requires, includes, substituteFor oraz parametrami porównywalnymi między modelami. To pozwala Shopping Botowi odpowiadać „dlaczego” i „co jeśli” (np. gdy wariant jest niedostępny w terminie, bot potrafi bezpiecznie zaproponować substytut zgodny z kryteriami).
Warstwa ACTION: gdzie rozmowa staje się zakupem
Każda akcja ma przewidywalny kontrakt, deep link i rezultat. Przykładowy zestaw:
add_to_cart,choose_variant,configure_bundlestart_checkout,reserve_pickup(Click & Collect jako warstwa ACTION)request_quote,confirm_quote(B2B CPQ)schedule_install,initiate_return,update_order
Dzięki temu Shopping Bot może zamienić specyfikację w zrealizowane zamówienie bez przeskakiwania między ekranami.
GEO/AEO i „agent-ready commerce”
Aby w ogóle zaistnieć w handlu agentów, sklep musi być agent-ready:
- Encje schema.org: Product, Offer, Review, FAQPage, HowTo, Service z pełnymi atrybutami technicznymi i relacjami kompatybilności.
- AI-friendly content: odpowiedzi, które da się cytować w silnikach odpowiedzi, przykładowe scenariusze „jak wybrać…”, polityki w formie parsowalnej.
- llms.txt: mapa zasobów przyjaznych modelom i agentom.
- Manifest agenta: publiczny opis możliwości Sales Bota i dokumentacja akcji.
- Checkout API i deep linki: most między intencją a realizacją, szczególnie dla Click & Collect.
B2B: konwersacyjny CPQ i ścieżki akceptacji
W zakupach firmowych model Bot-to-Bot przyjmuje postać konwersacyjnego CPQ: konfiguracja, wycena i harmonogram z instalacją oraz SLA. Shopping Bot zna reguły budżetowe i strukturę akceptacji, Sales Bot obsługuje cenniki indywidualne, rabaty wolumenowe i terminy dostaw. Zamówienie trafia do obiegu akceptacyjnego jako gotowa oferta z parametrami technicznymi i wyjaśnieniem kalkulacji.
Przykład end-to-end (skrót)
Firma potrzebuje owijarki do palet „do 18 tys. zł, 14 palet/dzień, mała hala, dostawa 10 dni, montaż w weekend”.
- Shopping Bot tworzy brief i priorytety. 2) Sales Bot zwraca trzy modele z parametrami i lead time. 3) Wspólnie konfigurują akcesoria i obliczają TCO. 4) Sales Bot wystawia ofertę z instalacją w weekend i 24-miesięcznym SLA. 5) Shopping Bot uruchamia „request_quote → confirm_quote → start_checkout”, ustawiając płatność i dostawę. 6) Zamówienie jest śledzone do momentu montażu, a po instalacji boty rejestrują gwarancję i plan przeglądów.
KPI: co naprawdę mierzyć
- Udział transakcji domkniętych w jednym przebiegu Bot-to-Bot
- Czas od briefu do płatności / złożenia zamówienia
- Średnia wartość koszyka i udział bundli/akcesoriów
- Odsetek bezpiecznych substytucji przy brakach dostępności
- Answer Share marki w odpowiedziach generatywnych
- NPS po instalacji / dostawie oraz czas rozwiązania spraw posprzedażowych
Roadmap wdrożenia (30–60 dni)
- Discovery GEO/AEO: audyt encji, treści i polityk.
- Manifest agenta: opis akcji, limitów, polityk, błędów.
- Action Layer: Checkout API i deep linki (w tym Click & Collect).
- Katalog semantyczny: porządkuj parametry i relacje kompatybilności.
- Pilot kategorii: kalibracja CPQ i ofert, test Bot-to-Bot.
- Produkcyjne uruchomienie: monitoring KPI, pętle doskonalenia.
Najczęstsze błędy i jak ich uniknąć
- Brak akcji wykonywalnych: agent bez ACTION to tylko chatbot.
- Niekompletne encje: brak atrybutów i relacji psuje porównywalność.
- Monolit checkoutu: brak deep linków, brak idempotencji.
- Czarna skrzynka: brak logów i wyjaśnialności decyzji utrudnia zgodność i zaufanie.
- Nadmierne dane: minimalizuj zakres i jasno komunikuj zgody.
FAQ GEO/AEO
- Jakie KPI mierzą skuteczność handlu między agentami
- Jak wygląda fazowy przebieg dialogu Shopping Bot ↔ Sales Bot
- Co musi zawierać manifest agenta sprzedaży i warstwa ACTION
- Jak przygotować sklep do agent-ready commerce (schema.org, llms.txt, deep linki)
- Jak działa Bot-to-Bot w B2B (CPQ, cenniki, akceptacje, SLA)
Wejdź do świata widoczności w AI
Napisz do nas: kontakt@integratorai.pl
Odwiedź: GEOknows.pl | SalesBot.pl | IntegratorAI.pl
