Dział obsługi klienta sklepu internetowego dostaje 200 reklamacji tygodniowo. Trzydzieści procent to powtarzalne sprawy: uszkodzony towar przy dostawie, błąd w fakturze, brakująca pozycja w paczce. Konsultant odpowiada na nie niemal identycznie, co tydzień, od miesięcy. Kolejne 40% wymaga sprawdzenia jednego faktu w systemie magazynowym lub ERP, a dopiero wtedy standardowej odpowiedzi. Reszta to sprawy skomplikowane: spory prawne, klienci po kilku nieudanych próbach, zgłoszenia z danymi wrażliwymi.
AI radzi sobie dobrze z pierwszymi dwiema grupami. Z trzecią nie powinna próbować działać samodzielnie.
Cztery warstwy triage: co AI robi przed pierwszą odpowiedzią#
Zanim jakakolwiek reklamacja trafi do kolejki konsultanta lub do generatora odpowiedzi, dobrze zaprojektowany system przepuszcza ją przez cztery etapy.
Etap 1: klasyfikacja typu reklamacji. Klasyfikator wieloetykietowy ustala jednocześnie kategorię (uszkodzenie towaru, błąd rozliczenia, opóźnienie dostawy, niezgodność z opisem, reklamacja gwarancyjna), kanał (e-mail, formularz, czat, telefon STT) i język. Przy 500 lub więcej przykładach treningowych na kategorię trafność 85-92% jest osiągalna. Poniżej 200 przykładów lepiej działają modele bazowe z few-shot promptingiem niż fine-tuning.
Etap 2: detekcja pilności i sentymentu. Pilność to osobny wymiar, niesymetryczny kosztowo. Pominięcie pilnej sprawy (klient stracił dostęp do usługi, sprawa trafiła do mediacji) kosztuje wielokrotnie więcej niż fałszywy alert eskalacji. Dlatego klasyfikator pilności działa z wyraźną asymetrią: woli fałszywy alarm niż pominięcie. Sentyment bardzo negatywny (wielokrotne słowa jak „skandal”, „bezprawie”, „pozew”) uruchamia eskalację do konsultanta niezależnie od kategorii.
Etap 3: wyciąganie faktów z treści. Structured output z walidacją schematu wyodrębnia numer zamówienia, datę zakupu, kwotę, opis problemu i załączone dowody (zdjęcia, PDF paragonu). Wyciągnięte fakty są od razu dostępne dla generatora odpowiedzi i dla konsultanta, bez ręcznego przepisywania z treści e-maila.
Etap 4: weryfikacja w systemach zewnętrznych. Agent odpytuje ERP lub system magazynowy: czy zamówienie istnieje, jaki był status dostawy, czy gwarancja jest aktywna. Odpowiedź wraca jako fakty, nie jako gotowa decyzja. Model wie, że zamówienie było dostarczone w terminie. Czy to znaczy, że reklamacja jest bezzasadna? To ocena dla człowieka.
Tabela: typ reklamacji, rola AI, obowiązkowy human-gate, poziom ryzyka#
| Typ reklamacji | Rola AI | Obowiązkowy human-gate | Poziom ryzyka |
|---|---|---|---|
| Uszkodzony towar (standardowy) | Klasyfikacja, projekt odpowiedzi z szablonu RAG | Konsultant zatwierdza projekt przed wysyłką | Niski |
| Błąd w fakturze | Klasyfikacja, wyciągnięcie kwoty i numeru, projekt korekty | Dział księgowości zatwierdza korektę | Średni |
| Opóźnienie dostawy | Sprawdzenie statusu w systemie, projekt odpowiedzi z faktami | Konsultant weryfikuje fakty przed wysyłką | Niski |
| Odmowa reklamacji | Projekt uzasadnienia z cytowaniem regulaminu (RAG) | Człowiek podejmuje decyzję odmowy, nie AI | Wysoki |
| Odszkodowanie lub bon | Projekt propozycji na podstawie polityki firmy | Człowiek akceptuje wartość i formę, podpisuje się pod decyzją | Wysoki |
| Sentyment bardzo negatywny lub prawny | Wykrycie, priorytet eskalacji, zebranie kontekstu | Wyłącznie człowiek, AI nie generuje odpowiedzi | Bardzo wysoki |
| Zgłoszenie zawierające dane wrażliwe (RODO) | Wykrycie PII, maskowanie przed modelem chmurowym, eskalacja | Człowiek decyduje o każdym kroku | Bardzo wysoki |
Jak RAG buduje projekt odpowiedzi#
Gdy klasyfikator ustali, że sprawa nadaje się do automatycznego projektu, system odpytuje bazę wiedzy przez RAG. Baza zawiera zatwierdzone szablony odpowiedzi, regulaminy, politykę gwarancyjną i procedury zwrotów. Model nie wymyśla treści: łączy fakty wyciągnięte z reklamacji z fragmentami znalezionymi w bazie.
Warunek poprawnego działania: baza wiedzy musi być aktualna i pokrywać wszystkie kategorie reklamacji. Jeśli firma zmieniła politykę zwrotów, a baza nie została zaktualizowana, model wygeneruje projekt oparty na nieaktualnej procedurze. Dlatego aktualizacja bazy wiedzy to nie jednorazowy projekt, lecz stały obowiązek operacyjny. Artykuł o aktualizacji wiedzy RAG omawia wzorce przyrostowej reindeksacji.
Projekt odpowiedzi trafia do konsultanta jako gotowy tekst do zatwierdzenia lub edycji, nie jako wysłana wiadomość. Konsultant widzi: kategorię reklamacji, wyciągnięte fakty, fragment regulaminu, który posłużył jako źródło, i propozycję treści. Może zaakceptować jednym kliknięciem lub edytować i wysłać. Czas obsługi spada, jakość rośnie, odpowiedzialność pozostaje po stronie człowieka.
SLA tracking i observability: skąd wiedzieć, że system działa#
Observability systemu reklamacyjnego zaczyna się od czterech metryk mierzonych od pierwszego dnia pilotażu.
Czas do pierwszej odpowiedzi. Czas od wpłynięcia reklamacji do wysłania pierwszej odpowiedzi (przez AI lub przez konsultanta zatwierdzającego projekt AI). Cel dla standardowych spraw: poniżej 2 godzin w godzinach pracy. Artykuł o monitoringu jakości agenta AI opisuje szczegółowe wzorce zbierania tych metryk.
Wskaźnik zatwierdzania projektów bez edycji. Odsetek projektów odpowiedzi, które konsultant zaakceptował bez zmian. Przy dobrze skalibrowanej bazie wiedzy i wąskim zakresie kategorii ten wskaźnik osiąga 60-75% dla spraw standardowych. Jeśli spada poniżej 40%, baza wymaga uzupełnienia lub zakres kategorii obsługiwanych przez AI jest zbyt szeroki.
Escalation rate i re-classification rate. Odsetek spraw przekierowanych do wyższej kolejki po pierwszym routingu. Wysoki escalation rate (powyżej 15%) sygnalizuje błędną klasyfikację pilności. Re-classification rate powyżej 20% dla jednej kategorii to sygnał do przeglądu etykiet treningowych lub rozdzielenia kategorii, podobnie jak omawia to artykuł o klasyfikacji i routingu zgłoszeń.
SLA compliance per kategoria. Czy sprawy z danej kategorii są zamykane w zadeklarowanym czasie? System powinien flagować sprawy zbliżające się do granicy SLA i automatycznie podnosić ich priorytet, zanim termin minie.
Granice automatyzacji: gdzie AI nie wchodzi#
Kilka kategorii jest poza zakresem automatycznej obsługi niezależnie od trafności klasyfikatora.
Odmowy reklamacji. Klient, który dostaje odmowę z systemu automatycznego, ma gorsze wrażenie niż klient, który dostaje odmowę od człowieka z uzasadnieniem. Projekt odmowy może przygotować AI (z cytatem z regulaminu), ale decyzję podejmuje i podpisuje konsultant. Jest to też wymóg AI Act dla systemów wpływających na prawa konsumentów.
Odszkodowania i bony o wartości powyżej ustalonego progu. Firma powinna zdefiniować próg kwotowy, powyżej którego każda decyzja finansowa wymaga zatwierdzenia przez człowieka. Poniżej progu system może automatycznie generować bon rabatowy według tabel polityki, zawsze z logiem i możliwością audytu.
Reklamacje zawierające dane wrażliwe. Zgłoszenie, w którym klient opisuje problem zdrowotny wynikły z użycia produktu, lub zgłoszenie zawierające dane finansowe, wymaga maskowania PII przed jakimkolwiek przetwarzaniem przez model chmurowy. Jeśli system nie jest self-hosted, dane wrażliwe nie powinny opuszczać lokalnej infrastruktury.
Sprawy po wielokrotnych kontaktach. Klient, który pisze po raz trzeci w tej samej sprawie, jest już sfrustrowany. System powinien automatycznie eskalować takie zgłoszenie do seniora, nie wysyłać kolejnego projektu odpowiedzi z szablonu.
Wzorzec pilotażu: shadow mode przez 4 tygodnie#
Bezpieczne wdrożenie zaczyna się od trybu shadow. Przez pierwsze 4-6 tygodni klasyfikator i generator projektów działają równolegle do istniejącego procesu: klasyfikują, wyciągają fakty i przygotowują projekty, ale konsultanci obsługują sprawy samodzielnie i widzą wyniki AI obok swoich decyzji.
Porównanie decyzji AI z decyzjami konsultantów buduje ground truth: gdzie model myli kategorie, gdzie projekty są akceptowalne bez edycji, gdzie sentyment jest wykrywany prawidłowo. Po 4 tygodniach masz dane, żeby bezpiecznie włączyć automatyzację dla wybranych kategorii niskiego ryzyka.
Artykuł o firmach usługowych i AI oraz o obowiązkach firm wynikających z AI Act i RODO omawia wymagania dokumentacyjne, które warto przygotować przed uruchomieniem systemu na danych klientów.
My w Cashcrown budujemy takie systemy jako ośrodek badawczy: każdy komponent (klasyfikator, generator projektów, human-gate, observability) jest mierzony osobno przed integracją. Nie ma jednego słusznego progu pilności ani jednej gotowej taksonomii reklamacji. Kalibracja pod konkretną branżę i historyczne dane klienta jest tym, co decyduje o wyniku.
FAQ#
Czy AI może samodzielnie podejmować decyzje o przyjęciu lub odrzuceniu reklamacji?#
Nie powinna. Decyzja merytoryczna o reklamacji ma skutki prawne i relacyjne: błędna odmowa może narazić firmę na postępowanie UOKiK lub utratę klienta. AI może przygotować projekt uzasadnienia z cytatem z regulaminu, ale ostateczną decyzję podejmuje i podpisuje człowiek. Obowiązujący od 2026 AI Act nakłada ten wymóg wprost dla systemów wpływających na prawa konsumentów, a obsługa reklamacji dokładnie do tej kategorii należy.
Jak chronić dane osobowe klientów w systemie reklamacyjnym?#
Reklamacje często zawierają dane osobowe: imię, adres, numer zamówienia, czasem dane zdrowotne lub finansowe. Przed wysłaniem treści do modelu chmurowego dane te powinny być maskowane lokalnie przez system PII maskowania. Jeśli sprawa zawiera szczególnie wrażliwe dane, cały pipeline powinien działać na infrastrukturze self-hosted lub sprawa powinna być obsługiwana wyłącznie przez człowieka. Przed wdrożeniem warto przeprowadzić DPIA, zwłaszcza jeśli obsługujesz branże wrażliwe (zdrowie, finanse, dzieci).
Jak długo trwa wdrożenie takiego systemu?#
Pilotaż shadow mode z klasyfikatorem opartym na few-shot promptingu można uruchomić w 3-5 tygodni, jeśli masz historyczne dane reklamacji z etykietami. Pełne wdrożenie z integracją do ERP lub systemu helpdesk, metrykami SLA i procedurami eskalacji zajmuje 8-14 tygodni. Największa część czasu to zebranie i przejrzenie danych treningowych, kalibracja progów eskalacji i szkolenie konsultantów w nowym przepływie pracy, nie samo programowanie.
Jakie metryki mierzyć, żeby ocenić skuteczność systemu?#
Cztery liczby mówią prawdę: czas do pierwszej odpowiedzi (cel: poniżej 2 godzin dla spraw standardowych), wskaźnik zatwierdzania projektów bez edycji (cel: 60-75% dla wąskich kategorii), escalation rate (sygnał błędnej klasyfikacji pilności gdy powyżej 15%) i SLA compliance per kategoria (odsetek spraw zamkniętych w terminie). Containment rate, czyli odsetek spraw zamkniętych bez człowieka, ma sens jako metryka dopiero po co najmniej 8 tygodniach stabilnej pracy systemu.
Co zrobić, gdy klient pisze po raz trzeci w tej samej sprawie?#
Klient z wielokrotnymi kontaktami w tej samej sprawie powinien być automatycznie eskalowany do seniora lub do wyznaczonej kolejki retencyjnej, nie trafiać ponownie do automatycznego generatora projektów. System powinien wykrywać historię kontaktów (liczba zgłoszeń w ostatnich 14 dniach dotyczących tego samego zamówienia lub tematu) i traktować to jako sygnał eskalacji priorytetowej, niezależnie od kategorii i sentymentu bieżącego zgłoszenia.