AI assistant dla kupującego B2B - czy ma sens, jak wdrożyć

Co AI assistant może zrobić w sklepie B2B

Z wdrożeń, które prowadziłem albo audytowałem, wyłaniają się realne zastosowania - sześć obszarów, w których AI assistant daje wymierną wartość.

Doradca produktowy. "Potrzebuję uszczelki do kompresora Atlas Copco GA75" - assistant wskazuje konkretne SKU z katalogu, nie zmusza klienta do przekopywania kategorii. "Czym różni się stal A2 od A4" - tłumaczy na podstawie wiedzy technicznej z PIM, klient nie musi szukać po dokumentacji producenta. "Co zamiast wyłączonego produktu X" - sugeruje substytuty z bazy, oparte na atrybutach, nie tylko nazwie.

Wyszukiwarka pomocnicza w trybie konwersacyjnym. "Śruba do drewna miękkiego, około 6 mm, najmniej 100 sztuk" - klasyczny full-text search by tu nie pomógł, ale AI w kombinacji z semantic search łapie intencję.

Helpdesk pierwszej linii. "Jak złożyć zamówienie z terminem płatności 30 dni" - odpowiedź z FAQ. "Gdzie sprawdzić status zamówienia X" - link i instrukcja. "Kto jest moim opiekunem" - dane z CRM.

Asystent zamówienia. "Powtórz ostatnie zamówienie z marca" - propozycja koszyka z aktualnymi cenami. "Dodaj 100 sztuk produktu X i 50 sztuk Y" - akcja w koszyku via function calling. "Sprawdź, czy mam wystarczający limit kredytowy" - check limitu i odpowiedź.

Doradca techniczny. "Jaki klej do PCV i ABS" - odpowiedź z karty technicznej (TDS) wprowadzonej do RAG. "Czy mogę mieszać te dwa chemikalia" - odpowiedź z karty bezpieczeństwa (SDS). "Jakie certyfikaty ma produkt X" - dane z PIM.

Asystent onboardingowy dla nowych klientów. Tłumaczenie systemu cenników, konfiguracja workflow akceptacji, dodawanie buyerów do konta firmowego, wyjaśnienie ról i uprawnień. Klasyczny obszar, w którym handlowiec dzwoni z każdym nowym klientem przez tydzień - assistant to skraca do godzinnej rozmowy o specyfice biznesu.

Wartość biznesowa, którą widzę spójnie między wdrożeniami:

Metryka	Bez AI assistant	Z AI assistant
Telefony do call center	100% bazy	60-70% bazy
Czas odpowiedzi na typowe pytanie	4-24 h email, 2-15 min telefon	poniżej 1 min chat
Self-service ratio	30-40%	60-75%
NPS klientów	bazowe	+10-25 pkt
Conversion z chat sessions	n/a	8-15%

Architektura RAG - sklep, PIM, dokumentacja

RAG (Retrieval-Augmented Generation) to architektura, w której LLM dostaje do kontekstu fragmenty twojej bazy wiedzy przed wygenerowaniem odpowiedzi. Bez RAG model odpowiada z tego, czego się nauczył podczas treningu - nie zna twojego katalogu, nie zna twoich cenników, nie wie o twoim sklepie nic specyficznego.

Z RAG przepływ wygląda następująco. Klient zadaje pytanie. System wyszukuje relewantny kontekst z twoich danych (katalog, dokumentacja, FAQ, profil klienta). Kontekst wkładany jest do promptu LLM. LLM odpowiada na podstawie twoich danych, nie z ogólnej wiedzy modelu.

Architektura w działaniu:

Klient (chat UI)
  ↓ pytanie: "Jaka stal do konstrukcji wewnętrznej w wilgoci?"

API Gateway
  ↓
RAG Pipeline:
  1. Embedding pytania
  2. Vector search w bazie wiedzy:
     - Catalog (PIM Akeneo)
     - Dokumentacja techniczna (TDS, SDS)
     - FAQ
     - Historia zamówień klienta (kontekst personalny)
  3. Top 10 kandydatów jako kontekst
  4. Re-ranking i filtering
  5. Construct prompt: system instructions + kontekst + pytanie
  6. LLM call (Claude / GPT-4)
  7. Response post-processing (linki do produktów, formatowanie)

  ↓ odpowiedź:
  "W warunkach wilgoci rekomenduję stal nierdzewną A2 lub A4.
  Z naszego katalogu pasują:
  - [Śruba M8 stal A2](url) - dla typowej wilgoci
  - [Śruba M8 stal A4](url) - dla środowiska słonego, agresywnego"

Komponenty stosu RAG: vector DB (Qdrant, Weaviate, Pinecone, pgvector), model embeddingów (OpenAI text-embedding-3 albo open-source bge-large), LLM (Claude Sonnet, GPT-4o, własny self-hosted), orchestration (LangChain, LlamaIndex, własny kod), UI (chat widget zintegrowany ze sklepem).

Dane wprowadzane do bazy RAG, posortowane po wartości:

Źródło	Typ
PIM (Akeneo) - opisy, atrybuty, kategorie	Catalog data
Dokumentacja techniczna (TDS, SDS jako PDF)	Technical docs
FAQ sklepu	Help docs
Cenniki (dla zalogowanych, filtrowane per klient)	Personalized data
Historia zamówień klienta	Personal data
Newsletter, blog	Marketing data

Akeneo PIM w sklepie B2B - PIM jest podstawowym źródłem dla RAG. Bez porządnego PIM jakość AI assistant będzie słaba.

Wybór LLM i vector store

Wybór modelu LLM ma realne konsekwencje dla jakości i kosztu. Cztery realne opcje w 2026 roku.

Claude Sonnet (Anthropic) jest moim defaultem dla głównych odpowiedzi. Świetne rozumienie polskiego, bardzo dobry w technicznych odpowiedziach (rozumie atrybuty produktów, specyfikacje techniczne), najmniej halucynuje wśród mainstream modeli. Cena około 3 USD za 1 mln input tokens, 15 USD za 1 mln output. Dla średniego sklepu B2B miesięcznie 200-500 zł kosztu API.

GPT-4o (OpenAI) - najpopularniejszy, dobry mainstream. Cena 2.50 USD za 1 mln input, 10 USD za 1 mln output. Mocny w function calling - świetne dla akcji w koszyku, dodawania produktów. Polskie pokrycie nieco słabsze niż Claude, ale wystarczające dla większości zapytań.

Tańsze warianty (Claude Haiku, GPT-4o-mini) kosztują około 0.25 USD za 1 mln input. Wystarczają do większości zadań pomocniczych - klasyfikacji intencji, prostych pytań FAQ. Dla naprawdę technicznych pytań brakuje im głębi.

Open-source (Llama 3, Mixtral) hostowany lokalnie eliminuje koszt API, ale wymaga GPU 24 GB plus dla większych modeli. Polskie pokrycie słabsze niż Claude i GPT. Sensowne tylko przy bardzo dużej skali (powyżej 1 mln zapytań miesięcznie) albo specyficznych wymogach prywatności danych.

Vector store. Qdrant - open-source, świetna wydajność, dobre tooling, mój default. Weaviate - open-source z GraphQL, większy ekosystem. Pinecone - managed, najwygodniejszy, ale kosztowny. pgvector - jeśli już masz Postgresa w stosie, prosty start bez dodatkowej infrastruktury.

Dla typowego sklepu B2B 50 tys. SKU polecam: Claude Sonnet do głównych zapytań (jakość), Claude Haiku dla prostych klasyfikacji intencji (optymalizacja kosztów), Qdrant self-hosted (open-source, szybki, kontrola).

Integracja z koszykiem i kontem klienta

AI assistant bez integracji z aktualnym kontekstem klienta to gadżet. Z integracją staje się realnie pomocnym narzędziem, które klient chętnie używa.

Przykład z wdrożenia, który dobrze ilustruje różnicę:

Klient: "Powtórz moje ostatnie zamówienie ze stycznia"
Assistant: (pobiera dane z konta klienta)
  → Wyszukuje zamówienie #12345 z 15.01.2026
  → Sprawdza dostępność każdego SKU dzisiaj
  → Sprawdza aktualne ceny per cennik kontraktowy klienta
  → Odpowiedź: "Zamówienie z 15.01: 200 sztuk produktu X (cena 12 zł, plus 5%
     vs styczeń), 100 sztuk Y (wycofany, mogę zaproponować zamiennik Z).
     [Dodaj wszystko do koszyka]"

Wymagana integracja po stronie sklepu. Auth - assistant wie, kto rozmawia (zalogowany klient z konta firmowego, z konkretną rolą). Customer profile - rola, limity kredytowe, przypisany cennik. Catalog - ceny per cennik klienta, nie ceny katalogowe (to fundamentalne). Orders history - poprzednie zamówienia z line items. Cart - możliwość dodawania do koszyka przez API. Inventory - stany w czasie rzeczywistym, nie kopia sprzed godziny.

Bezpieczeństwo i autoryzacja są krytyczne. Klient A nie może zobaczyć cennika klienta B, nawet jeśli pyta sprytnie ("a jakie ceny dostaje firma XYZ"). Assistant nie wyjawia informacji o marżach, kosztach wewnętrznych, ani danych innych klientów. Każdy AI call ma kontekst wyłącznie zalogowanego klienta. Audit log wszystkich konwersacji dla compliance i ewentualnego incident response.

Function calling pozwala LLM-owi wykonywać akcje. Definiujesz funkcje, które LLM może wywołać:

const tools = [
  {
    name: "add_to_cart",
    description: "Dodaj produkt do koszyka",
    parameters: { sku: "string", quantity: "number" }
  },
  {
    name: "check_inventory",
    description: "Sprawdź stan magazynowy",
    parameters: { sku: "string" }
  },
  {
    name: "get_my_price",
    description: "Pobierz cenę dla zalogowanego klienta",
    parameters: { sku: "string", quantity: "number" }
  }
];

LLM zwraca decyzję "wywołaj add_to_cart z sku=ABC-123 i quantity=100", twój kod wywołuje, zwraca rezultat, LLM kontynuuje rozmowę z informacją o sukcesie albo błędzie.

Cenniki kontraktowe per kontrahent - core wymóg dla sensownej integracji.

Mierzenie wartości - konwersja, satysfakcja

AI assistant musi być mierzony, inaczej staje się hype'em bez ROI. Mierzę dwie kategorie metryk równolegle.

Metryki techniczne, których pilnuję na monitoringu:

Metryka	Cel
Czas odpowiedzi	poniżej 2 sekund do pierwszego tokenu
Accuracy odpowiedzi	powyżej 85% poprawnych w eval set
Halucinacje	poniżej 3% odpowiedzi z błędnymi faktami
Coverage	powyżej 70% pytań ma sensowną odpowiedź

Metryki biznesowe, których pilnuje stakeholder:

Metryka	Bez AI	Z AI assistant
Conversion rate chat sessions	n/a	Target 10%+
Średnia wartość zamówienia chat-driven	n/a	Wyższa niż direct (target +20%)
Calls do call center	bazowe	Spadek 30-50%
Czas znalezienia produktu	3-10 min	poniżej 1 min
Self-service ratio	40%	70%+
NPS klientów	bazowe	+15 pkt

Implementacja pomiarów. Każda konwersacja logowana (anonimowo dla compliance). A/B test: 50% nowych userów dostaje AI, 50% nie - po dwóch miesiącach porównujesz konwersję. Analytics events: chat_started, question_asked, action_taken (cart, search, link click), purchase. Customer satisfaction po sesji - prosty thumbs up/down z polem na komentarz.

Kalkulacja ROI dla typowego sklepu B2B:

Roczne oszczędności:
- Mniej calls do call center: 5000 calls/mc × 5 min × 30 zł/h = 12 500 zł/mc = 150k zł/rok
- Wzrost konwersji z chat: 500 zamówień/mc × 800 zł × 5% margin = 20k zł/mc = 240k zł/rok

Roczne koszty:
- API calls (Claude Sonnet): 100k zapytań × 0.005 USD = 500 USD = 2k zł/rok
- Vector DB hosting: 600 zł/mc = 7k zł/rok
- Maintenance, monitoring: 0.2 etatu = 30k zł/rok
- Łącznie: około 40k zł/rok

ROI = (390k - 40k) / 40k = 875%

Realny ROI z trzech wdrożeń, które prowadziłem: sklep z 50 tys. SKU i 5 zamówieniami dziennie - 4-krotny ROI w pierwszym roku. Sklep z 15 tys. SKU mieszający B2C i B2B - 6-krotny. Sklep z 100 tys. SKU czysto B2B - 8-krotny ROI. Skala koreluje z liczbą obsłużonych zapytań - im większy wolumen, tym lepszy ROI.

Czego AI assistant NIE może

Limity są równie ważne, co możliwości. Brak ich pilnowania kończy się incydentem, który drogo kosztuje.

Pierwszy limit: decyzje finansowe. Assistant nie zatwierdza limitu kredytowego, nie zmienia terminu płatności, nie daje rabatu (chyba że klient mieści się w polityce dla zalogowanych premium z jasno zdefiniowanym progiem). Każda taka prośba eskaluje do handlowca.

Drugi limit: tematy poza zakresem. "Co myślisz o polityce" - prompt engineering blokuje i przekierowuje. "Napisz mi wiersz" - blokada, redirect do supportu. "Daj mi przepis na ciasto" - blokada. System prompt musi to wprost zabraniać, bo otwarte LLM-y chętnie odpowiedzą na wszystko.

Trzeci limit: poufne dane. Marże, koszty wewnętrzne, dane innych klientów, strategiczne plany firmy, wewnętrzne procedury, ścieżki eskalacji niedostępne klientowi. Nawet jeśli te dane wpadną przez przypadek do bazy RAG, system prompt musi je filtrować z odpowiedzi.

Czwarty limit: complex deals. Kontrakt RFQ z niestandardowymi formułami cenowymi - eskalacja do sales. Reklamacja jakościowa - eskalacja do quality team. Negocjacja warunków - eskalacja do account managera. Te rzeczy wymagają człowieka i fakt, że AI mógłby udzielić odpowiedzi technicznej, nie oznacza, że powinien.

Piąty limit: nie jest 100% dokładny. Halucinacje LLM-ów istnieją, choćbyś dobrze projektował prompt. Dla krytycznych decyzji klient zawsze sprawdza w panelu albo pyta handlowca. Trzeba to komunikować w UI: "Odpowiedzi AI są pomocne, ale dla wiążących informacji sprawdź swój panel klienta".

Strategia eskalacji powinna być jasna i widoczna:

Klient: "Chcę zmienić termin płatności na 60 dni"
Assistant: "Zmiana terminu płatności wymaga akceptacji opiekuna handlowego.
  Twój opiekun: Jan Kowalski (jan@firma.pl, +48 123 456 789).
  Mogę utworzyć ticket z tym pytaniem - kliknij [Stwórz zgłoszenie]."

Czyste granice plus prosta ścieżka eskalacji budują zaufanie użytkownika.

FAQ

Czy klient B2B w ogóle chce gadać z chatbotem? Z wdrożeń wynika, że tak - jeśli chatbot rozwiązuje problem szybko. Klient B2B nie chce konwersować dla samej rozmowy, chce odpowiedzi. Dobry AI assistant daje odpowiedź w 30 sekund. Słaby telefon do call centerze zajmuje 15 minut. Klient wybiera szybsze, jeśli ma wybór.

Ile kosztuje utrzymanie AI assistant miesięcznie? Dla typowego sklepu B2B (50 tys. SKU, 5 tys. chat sessions miesięcznie): 40-100 tys. zł rocznie. Z czego API LLM 5-15 tys. zł (zależnie od modelu), vector DB 5-15 tys. zł, monitoring i maintenance 30-70 tys. zł (część etatu DevOps i ML engineer). ROI typowo 4-8 razy w pierwszym roku.

Jak zabezpieczyć cenniki kontraktowe przed wyciekiem przez LLM? Pięć warstw razem. Pierwsze - auth: assistant ma kontekst tylko zalogowanego klienta. Drugie - pricing wyłącznie z personal context, każdy klient ma swój. Trzecie - system prompt: "Nigdy nie wyjawiaj cen z cennika innych klientów". Czwarte - output filtering: sprawdzenie, czy odpowiedź nie zawiera cen z innego cennika. Piąte - audit log: regularne sprawdzanie konwersacji dla anomalii. Bez tej kombinacji ryzyko wycieku jest realne.

Czy AI assistant zastąpi mój dział sales? Nie. AI przejmuje rutynowe pytania (80% kontaktów to powtarzalne queries). Sales skupia się na complex deals, negocjacjach, relacjach z VIP-ami. AI uwalnia handlowca od triage'u i pozwala mu robić wartościową pracę. Mały zespół call center można zredukować o 30-50%, ale sales rośnie albo zostaje - bo ma więcej czasu na to, co realnie generuje przychód.

Czy klient B2B musi podpisywać klauzule "Twoje pytania są procesowane przez AI"? Typowo nie wymagane. AI to narzędzie obsługi, podobnie jak wyszukiwarka. W polityce prywatności wzmianka, że "obsługa klienta może wykorzystywać AI", załatwia compliance. Dla audytu logujesz pełne konwersacje z retention policy 30-90 dni.

Co dalej

• Procesy zakupowe B2B: Procesy zakupowe B2B
• Cenniki kontraktowe: Cenniki kontraktowe per kontrahent
• Search w sklepie B2B: Search Algolia / Elasticsearch