Chatbot AI dla B2B, hurtowni i dystrybutorów

Chatbot w hurtowni nie powinien udawać handlowca ani podejmować decyzji, których firma nie zapisała w procesie. Jego rola jest węższa: odczytać właściwe dane, pokazać je właściwej osobie i przerwać automatyzację, gdy sprawa wymaga oceny człowieka.

W B2B ta granica jest szczególnie ważna. Ten sam indeks może mieć inną cenę, walutę, minimum logistyczne, magazyn, termin realizacji i opiekuna w zależności od klienta, oddziału albo kontraktu. Do tego dochodzą rezerwacje, limity kupieckie, blokady jakościowe, backordery, zamienniki, wyjątki projektowe i ustalenia prowadzone poza standardowym cennikiem.

Dlatego chatbot dla dystrybucji nie jest tylko warstwą rozmowy nad katalogiem produktów. To element obsługi klienta, który musi znać źródło odpowiedzi, zakres uprawnień użytkownika i moment, w którym odpowiedź tekstowa mogłaby zostać błędnie potraktowana jako wiążąca deklaracja ceny, terminu albo dostępności.

TL;DR: rozsądny zakres

• Chatbot ma sens przy statusach zamówień, dokumentach, prostych pytaniach o konto, zbieraniu danych do sprawy i kierowaniu zgłoszeń do właściwego zespołu.
• Ceny, dostępność, limity i dokumenty powinny być widoczne tylko po rozpoznaniu użytkownika i tylko w zakresie przewidzianym dla jego roli.
• Model językowy nie powinien sam wyliczać cen, obiecywać terminu dostawy, rezerwować towaru, zwalniać blokad ani zatwierdzać zwrotów bez reguł procesu.
• Integracja z ERP, WMS, CRM lub portalem B2B wymaga decyzji o źródle prawdy, odświeżaniu danych, logach, trybie awaryjnym i odpowiedzialności za błędy.
• Zgodność z RODO i obowiązki przejrzystości wobec użytkownika zależą od konkretnej architektury, retencji danych, umów i sposobu informowania o użyciu AI.

Gdzie chatbot ma sens w B2B

W hurtowniach i firmach dystrybucyjnych duża część kontaktów z klientem dotyczy spraw powtarzalnych. Klient chce sprawdzić, czy zamówienie zostało przyjęte, czy faktura jest dostępna, gdzie pobrać WZ, czy wysyłka została nadana albo kto prowadzi jego sprawę.

To dobry zakres dla automatyzacji, pod warunkiem że odpowiedź pochodzi z zatwierdzonego systemu. Chatbot nie powinien zgadywać na podstawie podobnych przypadków ani dopowiadać brakujących danych dlatego, że rozmowa ma brzmieć płynnie.

Typowe obszary:

• status zamówienia i etap realizacji,
• informacja o wysyłce, awizacji lub odbiorze własnym,
• dostępność produktu w zakresie widocznym dla danego klienta,
• cena konta, jeżeli proces dopuszcza jej pokazanie w czacie,
• minimalna ilość zamówienia, jednostka sprzedaży i opakowanie zbiorcze,
• dokumenty sprzedażowe i magazynowe,
• podstawowe informacje o warunkach płatności lub blokadzie,
• zebranie danych do kontaktu z opiekunem, serwisem albo finansami.

To nie jest przejęcie sprzedaży. Do człowieka powinny trafiać sprawy niestandardowe: wyceny projektowe, spory o dokumenty, reklamacje, pilne rezerwacje, odroczone płatności, zamienniki wymagające decyzji technicznej, klienci strategiczni oraz każda sytuacja, w której odpowiedź bota mogłaby mieć skutek handlowy lub finansowy.

Status zamówienia: prosty tylko z zewnątrz

Status zamówienia wygląda prosto, dopóki firma nie musi pokazać częściowej realizacji. W realnym B2B jedno zamówienie może mieć kilka magazynów, kilka dostaw, pozycje anulowane, pozycje oczekujące na producenta, osobne dokumenty i różne reguły kompletacji.

Chatbot powinien pokazywać to, co system wie, bez zamiany statusu operacyjnego w obietnicę. Jeżeli data jest planowana, powinna być opisana jako planowana. Jeżeli wysyłka nie ma numeru listu przewozowego, bot nie powinien sugerować, że przesyłka już wyszła.

Bezpieczna odpowiedź może zawierać:

• numer zamówienia i datę przyjęcia,
• bieżący status z ERP lub portalu B2B,
• pozycje zrealizowane, oczekujące, anulowane i częściowo wysłane,
• informację, czy towar jest zarezerwowany,
• numer przesyłki lub awizacji, jeżeli jest dostępny,
• zastrzeżenie przy terminie orientacyjnym,
• ścieżkę kontaktu, gdy zamówienie wymaga decyzji handlowca.

Przykład odpowiedzi z właściwym poziomem ostrożności:

Klient: Jaki jest status zamówienia 45678?
Chatbot: Zamówienie 45678 jest częściowo przygotowane do wysyłki.
Linie 1 i 2 są zarezerwowane. Linia 3 oczekuje na dostawę od producenta.
W systemie widzę planowany termin uzupełnienia, ale nie jest to potwierdzona data wysyłki.
Jeżeli zamówienie jest pilne, mogę przekazać sprawę do opiekuna konta.

Taka odpowiedź jest mniej efektowna niż krótka deklaracja „wyślemy jutro”, ale lepiej odpowiada temu, jak działa dystrybucja. Problemem często nie jest sam brak towaru, tylko zbyt pewna informacja przekazana klientowi przed potwierdzeniem.

Dostępność to nie sam stan magazynowy

Pytanie „czy jest na stanie?” rzadko oznacza tylko fizyczną liczbę sztuk w magazynie. Klienta interesuje, czy może kupić konkretną ilość, na swoich warunkach, z dostawą w terminie, który ma znaczenie dla jego produkcji, budowy albo dalszej odsprzedaży.

Odpowiedź zależy od magazynu, rezerwacji, kanału sprzedaży, minimum logistycznego, partii, blokady jakościowej, limitu sprzedaży, jednostki zamówienia i polityki widoczności stanów. Jeżeli handlowiec albo portal B2B nie pokazuje surowych stanów, chatbot też nie powinien ich ujawniać.

W projekcie warto rozróżnić co najmniej cztery pojęcia:

• „widoczne w magazynie”,
• „dostępne do zamówienia”,
• „zarezerwowane dla klienta”,
• „wymaga potwierdzenia”.

Przed pokazaniem dostępności trzeba ustalić:

• czy użytkownik jest zalogowany i powiązany z właściwym kontem,
• które oddziały i magazyny są dla niego właściwe,
• czy wynik uwzględnia rezerwacje, zamówienia w toku i blokady,
• czy produkt ma ograniczenia sprzedaży albo wymaga konfiguracji,
• czy ilość jest dostępna do zamówienia, a nie tylko fizycznie obecna,
• jak często odświeżają się dane w ERP, WMS i portalu B2B,
• co chatbot ma powiedzieć, gdy stan zmieni się przed złożeniem zamówienia.

Dobra odpowiedź brzmi jak odczyt operacyjny, nie jak deklaracja sprzedaży: „system pokazuje 40 sztuk dostępnych do zamówienia w magazynie X; dla 120 sztuk potrzebne jest potwierdzenie terminu”. Taki komunikat zostawia miejsce na proces, zamiast tworzyć obietnicę, której firma może nie być w stanie dotrzymać.

Ceny klienta i warunki handlowe

Cennik B2B bywa zbiorem reguł, nie tabelą. Na cenę mogą wpływać rabaty kontraktowe, progi ilościowe, waluta, dopłaty logistyczne, warunki dostawy, promocje, ceny projektowe, segment klienta i wyjątki zapisane poza standardową matrycą.

Chatbot nie powinien odtwarzać tej logiki samodzielnie. Jeżeli cena ma być pokazana, powinna pochodzić z tego samego źródła, z którego korzysta portal B2B albo proces sprzedaży. Użytkownik musi być rozpoznany, a zakres informacji powinien odpowiadać jego roli.

Minimalne zasady:

• nie pokazuj ceny przed autoryzacją klienta,
• nie mieszaj ceny katalogowej z ceną konta,
• pokaż walutę, jednostkę, minimum zamówienia i ewentualne warunki,
• odróżnij cenę informacyjną od ceny możliwej do użycia w zamówieniu,
• nie wyceniaj zapytań projektowych ani przetargowych bez udziału opiekuna,
• eskaluj sytuacje, w których cena zależy od decyzji handlowej.

Jeżeli system nie może potwierdzić ceny, chatbot powinien powiedzieć to wprost. Odpowiedź „ta pozycja wymaga potwierdzenia przez handlowca” jest lepsza niż wygenerowanie kwoty, której firma później nie uzna.

Limity, płatności i blokady

W dystrybucji zamówienie może zatrzymać nie tylko brak towaru. Powodem może być przekroczony limit kupiecki, zaległa płatność, brak dokumentów, nietypowy adres dostawy, blokada konta, ręczna kontrola finansów albo rozbieżność w danych klienta.

Chatbot może informować o stanie sprawy, ale nie powinien ujawniać więcej niż dana rola ma prawo zobaczyć. Kupujący może potrzebować informacji, że zamówienie wymaga weryfikacji finansowej. Nie musi widzieć notatek windykacyjnych, wewnętrznego scoringu ani pełnej historii należności.

Warto osobno opisać zakres widoczności dla:

• użytkownika kupującego,
• administratora konta klienta,
• przedstawiciela handlowego,
• działu obsługi klienta,
• finansów i windykacji.

Każda z tych ról może widzieć inne dane, nawet jeżeli pyta o to samo zamówienie. To powinno wynikać z systemu uprawnień, a nie z improwizowanej logiki w promptach.

Integracja z ERP i portalem B2B

Chatbot B2B jest wiarygodny tylko tak długo, jak wiarygodne są dane, które pokazuje. Jeżeli ERP nie rozróżnia rezerwacji, blokad, dostępności i cen konta albo API zwraca dane z opóźnieniem, bot musi działać ostrożniej.

Integracja nie powinna zaczynać się od pytania „czy mamy API?”. Ważniejsze jest pytanie, który system jest źródłem prawdy dla konkretnej odpowiedzi i co zrobić, gdy źródła pokazują różne informacje.

Najczęstsze źródła danych:

• ERP: zamówienia, pozycje, faktury, rezerwacje, limity, statusy,
• WMS lub system magazynowy: dostępność, lokalizacje, kompletacja,
• TMS lub integracja kurierska: przesyłki, awizacje, odbiory,
• CRM: opiekun konta, segment klienta, historia kontaktu,
• portal B2B: autoryzacja, koszyk, role użytkowników,
• PIM: nazwy produktów, parametry, opisy i dokumentacja.

Nie każda integracja musi od razu zapisywać dane. W pierwszym etapie często bezpieczniejszy jest zakres odczytowy: status zamówienia, lista dokumentów, podstawowa dostępność i przekazanie sprawy do opiekuna. Zapis do ERP, utworzenie zamówienia, rezerwacja towaru, zmiana adresu dostawy albo zatwierdzenie zwrotu wymagają mocniejszych uprawnień, walidacji, logów i procedury korekty błędu.

Architektura bez nadmiaru obietnic

Produkcyjny chatbot dla hurtowni zwykle nie jest jednym modelem podpiętym do okna rozmowy. Składa się z warstw, które ograniczają zakres odpowiedzi i pozwalają odtworzyć, skąd wzięła się dana informacja.

Typowe elementy:

• interfejs rozmowy w portalu B2B, helpdesku, na stronie albo w komunikatorze,
• autoryzacja i role użytkownika,
• baza wiedzy dla regulaminów, instrukcji, FAQ i opisów produktów,
• kontrolowane wywołania do ERP, CRM, WMS, PIM lub ticketingu,
• reguły walidacji i przekazania sprawy do człowieka,
• logi, monitoring błędów i ocena jakości odpowiedzi.

Wybór frameworka jest mniej ważny niż granice procesu. RAG może pomóc przy wyszukiwaniu dokumentów i instrukcji, ale nie zastąpi systemu transakcyjnego przy numerach zamówień, SKU, statusach, cenach i limitach. Dla takich danych bezpieczniejsze są kontrolowane zapytania do źródła prawdy niż swobodne wyszukiwanie semantyczne.

Równie ważne jest ograniczenie uprawnień. Chatbot, który może tylko odczytać status i utworzyć zgłoszenie, ma inny profil ryzyka niż bot, który może składać zamówienia, zmieniać dane adresowe albo inicjować zwroty.

Uprawnienia i prywatność

Chatbot w B2B pracuje na danych, które zwykle nie są publiczne: cenach, rabatach, historii zamówień, limitach, adresach dostawy, danych kontaktowych, reklamacjach i notatkach handlowych. Projekt powinien zacząć się od mapy uprawnień, a dopiero potem od scenariuszy rozmów.

Pytania kontrolne:

• kto może zobaczyć historię zamówień firmy,
• czy użytkownik widzi wszystkie oddziały klienta, czy tylko własny,
• kto może zobaczyć ceny i warunki handlowe,
• czy dokumenty mogą być pobierane z poziomu czatu,
• czy rozmowy trafiają do CRM lub helpdesku,
• jak długo przechowywane są rozmowy,
• które dane są maskowane w logach,
• jak obsłużyć żądania dostępu, usunięcia lub korekty danych.

RODO wymaga konkretnej analizy: celu, podstawy przetwarzania, minimalizacji danych, retencji, bezpieczeństwa, umów powierzenia i możliwości wykazania zgodności. W praktyce oznacza to ustalenie, jakie dane trafiają do rozmowy, gdzie są przechowywane logi, kto może je przeglądać i czy dane klienta są przekazywane do zewnętrznych dostawców.

Nie warto pisać, że chatbot sam w sobie rozwiązuje RODO tylko dlatego, że działa w określonej lokalizacji albo używa popularnego dostawcy. Można zaprojektować rozwiązanie pod wymagania RODO, ograniczyć dane w promptach i logach oraz zawrzeć właściwe umowy, ale ocena zależy od procesu i architektury.

Od 2 sierpnia 2026 r. zaczynają być stosowane przepisy AI Act dotyczące przejrzystości z art. 50. Dla zwykłego chatbota obsługowego istotne jest jasne poinformowanie osoby fizycznej, że rozmawia z systemem AI, najpóźniej przy pierwszej interakcji, chyba że wynika to oczywiście z kontekstu. Jeżeli system miałby wpływać na ocenę kredytową, zatrudnienie, edukację, zdrowie albo dostęp do istotnych usług, potrzebna jest osobna analiza ryzyka.

Przekazanie sprawy do człowieka

Eskalacja nie jest porażką chatbota. W B2B jest częścią normalnego procesu, bo wiele spraw zależy od relacji handlowej, ryzyka finansowego, dostępności u producenta albo decyzji technicznej.

Przekazanie sprawy powinno zawierać:

• powód eskalacji,
• krótkie podsumowanie rozmowy,
• identyfikator klienta, zamówienia lub produktu,
• typ i priorytet sprawy,
• preferowany kanał odpowiedzi,
• załączniki lub dokumenty przekazane przez klienta,
• decyzje i odczyty wykonane przez chatbota.

Najczęstsze powody eskalacji to niestandardowa cena, spór o dokument, pilna dostawa, przekroczony limit, brak danych w ERP, rozbieżność między ERP i WMS, zapytanie techniczne, reklamacja oraz zwrot wymagający oceny. Dobra zasada brzmi: jeżeli odpowiedź może mieć skutek finansowy, terminowy albo prawny, chatbot pokazuje potwierdzony odczyt z systemu albo przekazuje sprawę człowiekowi.

Wyjątki są częścią projektu

Wdrożenie często psuje się nie na typowych pytaniach, tylko na wyjątkach. Dlatego scenariusze odmowy, doprecyzowania i eskalacji trzeba opisać przed uruchomieniem, a nie dopiero po pierwszej reklamacji.

Przykłady wyjątków:

• klient pyta o produkt wycofany,
• zamówienie jest wstrzymane przez finanse,
• stan magazynowy jest niespójny między ERP i WMS,
• produkt wymaga konfiguracji technicznej,
• klient ma ceny projektowe poza standardową matrycą,
• zapytanie dotyczy oddziału, do którego użytkownik nie ma dostępu,
• rozmowa zawiera dane osobowe lub informacje poufne,
• klient żąda decyzji, której chatbot nie może podjąć.

Dla takich sytuacji potrzebne są reguły, nie swobodna improwizacja modelu. Dobra odmowa jest konkretna: „nie mogę potwierdzić tej ceny w czacie, ponieważ dotyczy warunków projektowych; przekazuję dane do opiekuna”. To lepsze niż uprzejma odpowiedź, która nie daje klientowi żadnej informacji o dalszym toku sprawy.

Logi, audyt i obserwowalność

Logi są potrzebne, żeby utrzymać jakość odpowiedzi i odtworzyć przebieg sprawy po błędzie. Nie oznacza to gromadzenia wszystkiego bez ograniczeń. W B2B nadmiar danych w logach może stać się osobnym ryzykiem.

Warto logować:

• identyfikator rozmowy i użytkownika w bezpiecznym zakresie,
• źródło odpowiedzi: dokument, system, endpoint, status,
• wywołane narzędzia i wynik techniczny,
• decyzję o eskalacji, odmowie lub doprecyzowaniu,
• wersję konfiguracji, promptu, bazy wiedzy i modelu,
• błędy integracji oraz czas odpowiedzi.

Jednocześnie trzeba ograniczyć widoczność danych osobowych, cen, rabatów, notatek handlowych i treści poufnych. Narzędzia obserwowalności mogą pomóc w diagnostyce, ale nie zastępują polityki retencji, dostępu i anonimizacji.

Utrzymanie po wdrożeniu

Chatbot dla hurtowni nie jest jednorazową publikacją. Zmieniają się cenniki, produkty, opiekunowie, struktury klientów, integracje i procesy magazynowe. Bez utrzymania system będzie stopniowo tracił wiarygodność.

Plan utrzymania powinien obejmować:

• przegląd rozmów i powodów eskalacji,
• aktualizację reguł odpowiedzi,
• testy po zmianach w ERP, WMS lub portalu B2B,
• kontrolę jakości danych produktowych,
• obsługę błędów integracji,
• przegląd uprawnień i logów,
• uzgodnienie odpowiedzialności między IT, sprzedażą, finansami i obsługą klienta.

Warto mierzyć nie tylko liczbę rozmów obsłużonych przez chatbota. Ważniejsze są typy spraw, które trafiają do eskalacji, liczba odpowiedzi wymagających korekty, jakość danych źródłowych i to, czy zespół dostaje lepiej opisane zgłoszenia. Deklarowanie z góry konkretnego zwrotu albo procentu oszczędności zwykle nie ma sensu bez analizy realnych spraw i procesu.

Od czego zacząć

Najbezpieczniej zacząć od przeglądu realnych zapytań z maili, telefonu, formularzy, helpdesku i portalu B2B. Celem nie jest długa lista funkcji, tylko wybranie kilku kategorii, które są częste, dobrze opisane i mają stabilne źródło danych.

Praktyczna kolejność:

• zbierz powtarzalne pytania klientów,
• oznacz sprawy wymagające decyzji handlowca, finansów albo technika,
• wskaż system źródłowy dla każdej odpowiedzi,
• sprawdź aktualność danych i dostęp przez API lub inne kontrolowane źródło,
• opisz role użytkowników i zakres widoczności,
• przygotuj reguły dla wyjątków,
• uruchom ograniczony zakres i obserwuj eskalacje.

Chatbot w B2B ma sens wtedy, gdy porządkuje obsługę bez zdejmowania odpowiedzialności z firmy. Powinien odpowiadać mniej, ale dokładniej: tylko tam, gdzie dane są wystarczająco pewne, i szybko przekazywać sprawę człowiekowi, gdy proces wymaga decyzji.

---

Powiązane artykuły:

• Chatbot AI dla sklepu internetowego

Dla sprzedaży internetowej i portali zamówień sprawdź sprzeda.ai: asystenta sklepu.