E-commerce 3-spolkowy - RAG support 1200 ticketow/m-c od 1 osoby (PL/DE/HK)

Klient prowadzi 3 e-commerce'y w trzech krajach (Polska, Niemcy, Hongkong) - rozne marki, rozne katalogi, jeden zespol CS. Przed wdrozeniem mieli 4 osoby na suport, kazda po 8h dziennie obslugiwala ~80 ticketow. Po wakacjach wszystkim konczyly sie sily, response time rosl z 2h do 24h, NPS lecial w dol.

Diagnoza

Tydzien siedzenia w ich Zendesku + Allegro panel + DHL/InPost backendach. Rozklad ticketow byl brutalnie powtarzalny:

• 32% - 'gdzie jest moja paczka' (status zamowienia)
• 21% - 'jaki rozmiar wybrac' (size guide / spec)
• 14% - 'jak zwrocic' (return policy)
• 11% - 'kiedy wysylka' (lead time)
• 9% - 'czy jest dostepny w X kolorze' (stock check)
• 13% - reszta (reklamacje, problemy z platnoscia, niestandardowe)

Pierwsze 5 kategorii = 87% wolumenu, kazda ma DETERMINISTYCZNA odpowiedz dostepna w ich systemach (BaseLinker stock, DHL track API, statyczna baza FAQ). To nie wymaga 'rozumowania AI' - wymaga inteligentnego routera ktory laczy intencje z odpowiednim zrodlem danych.

Stack

• Embedding + retrieval: pgvector w Supabase, embedding model Cohere multilingual-v3 (3 jezyki!), chunking 512 tokens overlap 64
• Knowledge base: 4 zrodla scrapowane co 15 min - BaseLinker (produkty + stock), Allegro (oferty), DHL/InPost (tracking), GitBook (FAQ + return policy)
• Brain: Claude Haiku do klasyfikacji intencji + Sonnet 4.6 do generowania odpowiedzi (Haiku tanszy = 80% wolumenu, Sonnet tylko gdy intent confidence <0.7)
• HITL gate: n8n workflow -> jesli intent unknown lub kategoria 'reklamacje' -> forward do osoby na Discord, NIE auto-reply
• Output: Zendesk reply + tagging + Pipedrive deal update jesli VIP klient

Co poszlo nie tak

Pierwszy fail: embedding multilingual nie ogarnial chinskiego (Hongkong klienci pisali tradycyjnym chinskim). Cohere v3 jest dobry dla glownych jezykow europejskich + uproszczonego chinskiego, ale traditional Chinese pokazywal 40% accuracy retrieval. Fix: osobny embedding model BGE-M3 dla HK pipeline, routing po locale.

Drugi fail: Claude Sonnet generowal zbyt dlugie odpowiedzi ('Drodzy Panstwo, w odpowiedzi na Panskie zapytanie...' 4 paragrafy). Klient chcial tonu zwiezlego - 'Czesc, paczka bedzie jutro. tracking_link'. Fix: system prompt z 5 przykladami real responses + max 60 slow rule + literal 'no greetings, get to the point'.

Trzeci fail (najbolesniejszy): RAG zwracal stare dane stockowe bo cache w Supabase byl 1h. Klient kupil cos, dostal potwierdzenie, dostal auto-message 'produkt niedostepny'. Fix: dla pytan o stock - bypass embedding, idz direct do BaseLinker API. RAG NIE jest dobry do volatile data.

Wyniki po 4 miesiacach

• Volume: 1 200 ticketow / m-c (przedtem 950, wzrost po sezonie)
• Auto-resolution: 95% (cel byl 80%, nadrobilismy)
• Average response time: 4 sekundy (przedtem 2-24h)
• CSAT: 4.4/5 (przedtem 3.8/5) - klienci wola szybka odpowiedz AI niz wolna odpowiedz czlowieka
• Zaloga CS: 4 osoby -> 1 osoba (3 przeszly do innych rol: 1 do CX strategy, 1 do retencji, 1 do tworzenia FAQ contentu ktory teraz karmi RAG)
• Koszt infry: ~2 800 PLN/m-c (Supabase + Anthropic + Cohere + n8n self-hosted)
• ROI breakeven: 1.2 miesiaca (savings na pensjach pokryly setup w 5 tygodni)

Co bym zrobil inaczej

Od razu zrobilbym shadow mode przez 2 tygodnie - RAG generuje odpowiedzi, ale do ticketu trafia tylko ludzka odpowiedz. Po 2 tygodniach porownuje sie accuracy AI vs human i dopiero wlacza autoreply. My zrobilismy to dopiero po incydencie ze stock cache i stracilismy zaufanie klienta na tydzien.

Drugi insight: nie uzywaj jednego modelu do wszystkiego. Klasyfikator (Haiku) i generator (Sonnet) to dwie rozne robociochy. Proba 'jeden Claude robi wszystko' kosztowala nas 3x wiecej API w pierwszym miesiacu.

Trzeci insight: RAG to nie jest replacement czlowieka 1:1. To jest mechanizm ktory ZWALNIA czlowieka z 95% rzeczy nudnych, zeby mogl robic te 5% gdzie naprawde dodaje wartosc (rozmowa z naprawde wkurzonym klientem, rozwiazywanie nietypowych reklamacji, budowanie relacji). 1 osoba w CS jest teraz w stanie zrobic wiecej dla klienta niz 4 osoby przedtem.