Dział supportu IT przetwarza 200 zgłoszeń dziennie przez trzy kanały: e-mail, formularz i czat. Połowa wpada między 16:00 a 9:00 rano, kiedy zespół jest niepełny. Analiza historyczna 3 miesięcy pokazuje, że 12 spraw oznaczonych „standardowe" w ciągu 48 godzin eskalowało do poważnych incydentów. Każda eskalacja kosztowała od 4 do 8 godzin dodatkowej pracy. Klasyfikator AI, wdrożony przez 6-8 tygodni pilotażu, może zredukować takie opóźnienia o 60-75%, jeśli jest dobrze skalibrowany pod asymetrię kosztów błędów.
Co klasyfikuje AI i jakie sygnały czyta
#Dobrze zaprojektowany klasyfikator zgłoszeń czyta jednocześnie kilka wymiarów.
Kategoria tematyczna to najłatwiejszy wymiar. Model uczy się rozróżniać billing od problemów technicznych, zapytania handlowe od reklamacji, onboarding od pytań o regulamin. Dane treningowe to historyczne zgłoszenia z etykietami nadanymi przez zespół. Przy 500+ przykładach na kategorię model osiąga trafność 85-92% na własnym teście. Poniżej 200 przykładów trzeba użyć few-shot promptingu z modelem bazowym zamiast fine-tuningu.
Pilność to trudniejszy wymiar, bo jest asymetryczny. Fałszywy alarm eskalacji kosztuje minuty pracy koordynatora. Pominięta pilna sprawa kosztuje utratę klienta lub incydent SLA. Dlatego klasyfikator pilności powinien być osobnym modelem (lub osobną głowicą klasyfikacyjną) z wyraźnie wyższą czułością na klasę „wysoka" i „krytyczna". Sygnały: słowa kluczowe kryzysowe (awaria, brak dostępu, niemożliwe, natychmiast, strata), liczba poprzednich zgłoszeń od tego klienta w ciągu 7 dni, tier klienta z CRM, godzina wpłynięcia względem okna SLA.
Język i sentyment uzupełniają obraz. Wielojęzyczna firma potrzebuje auto-detekcji języka przed klasyfikacją, żeby nie przekazywać polskiego zgłoszenia do anglojęzycznej kolejki. Sentyment negatywny nie zmienia priorytetu sam w sobie, ale jest sygnałem eskalacji: klient, który w czterech zdaniach użył słowa „skandal" dwa razy i napisał z wykrzyknikami, wymaga innego tonu auto-odpowiedzi i szybszego kontaktu ludzkiego.
Kanał i format też wpływają na routing. Zgłoszenie przez czat ma niższy oczekiwany czas odpowiedzi niż e-mail. PDF z załącznikiem wymagający OCR trafia do innej kolejki niż pytanie tekstowe. Formularz z polem „priorytetu" podanym przez klienta jest silnym sygnałem, który model może przeoczyć w samej treści.
Architektura: od sygnału do kolejki
#Wzorzec, który sprawdza się przy 100-500 zgłoszeń dziennie, to pipeline strukturyzowanego outputu z warstwowym fallbackiem.
Krok 1: normalizacja wejścia. Zgłoszenie z każdego kanału sprowadzane jest do wspólnej struktury: temat + treść + metadane (kanał, godzina, ID klienta). Załączniki są parsowane osobno przez OCR lub ekstraktor PDF przed przekazaniem do klasyfikatora.
Krok 2: klasyfikacja. Model (lub prompt LLM z few-shot examples) zwraca JSON ze strukturą: { "category": "...", "urgency": "high|standard|low", "language": "pl|en|de", "sentiment": "negative|neutral|positive", "keywords": [...] }. Structured output z walidacją schematu eliminuje halucynowane pola. Jeśli model zwraca urgency: null lub niski confidence score, zgłoszenie trafia do kolejki ręcznej klasyfikacji, a nie do auto-routingu.
Krok 3: routing. Na podstawie skrzyżowania kategorii i pilności reguły kierują do kolejki. Krytyczna pilność zawsze trafia do dedykowanej kolejki dyżurnej, niezależnie od kategorii. Wysoka pilność wychodzi poza godziny pracy przez powiadomienie push lub SMS do wyznaczonego dyżuranta. Standardowe zgłoszenia z niskim sentymentem mogą otrzymać auto-odpowiedź z RAG na bazie bazy wiedzy.
Krok 4: human-handoff. Agent nie kończy pracy na routingu. Przekazuje kontekst: dlaczego trafiło do tej kolejki, jakie sygnały zadecydowały, historia klienta z ostatnich 30 dni, podobne rozwiązane sprawy. Konsultant widzi gotowy brief zamiast surowego zgłoszenia.
Tabela: sygnał vs decyzja routingu vs fallback
#| Sygnał wejściowy | Decyzja routingu | Fallback przy niskim confidence |
|---|---|---|
| Słowa kryzysowe (awaria, brak dostępu, strata) | Kolejka krytyczna + powiadomienie dyżuranta | Kolejka pilna z flagą do weryfikacji |
| Tier klienta: enterprise + wysoka pilność | Dedykowany opiekun klienta, max 15 min SLA | Senior support, max 30 min SLA |
| Sentyment bardzo negatywny + kategoria reklamacja | Kolejka retencji, priorytet wysoki | Kolejka ogólna support z notatką sentymentu |
| Język inny niż obsługiwany | Autodetect + routing do native-speaker lub MT z flagą | Kolejka ogólna z oznaczeniem języka |
| Kategoria billing + godzina poza biurem | Auto-odpowiedź RAG + ticket do następnego dnia | Kolejka billing z notatką o czasie |
| Niski confidence klasyfikatora (< 0,6) | Kolejka ręcznej klasyfikacji, nie auto-routing | Zawsze: człowiek klasyfikuje manualnie |
| Powracający klient z 3+ zgłoszeniami w tygodniu | Eskalacja do account managera z historią | Kolejka senior support z historią |
Kiedy auto-odpowiedź, kiedy człowiek
#Auto-odpowiedź przez RAG działa dobrze w wąskim paśmie: pytania o status zamówienia, godziny pracy, procedury zwrotów, standardowe instrukcje konfiguracji z dokumentacji. Warunek: odpowiedź musi być weryfikowalna przez system (np. status z bazy danych) lub dosłownie zaczerpnięta z zatwierdzonego dokumentu. Auto-odpowiedź halucynowana lub niedokładna kosztuje więcej zaufania niż brak odpowiedzi.
Człowiek wchodzi w każdym z tych scenariuszy: pilność krytyczna lub wysoka, eskalacja retencyjna, zgłoszenie prawne lub regulacyjne (RODO, reklamacje finansowe), temat nieznany modelowi (nowy produkt, incydent bez precedensu w danych treningowych), sentiment bardzo negatywny z sygnałami churn. Dobrą regułą jest też: jeśli konsultant musiałby poprawić auto-odpowiedź w ponad 15% przypadków danej kategorii, ta kategoria wypada z auto-routingu i wraca do kolejki ludzkiej.
Wzorzec pilotażu: przez pierwsze 4-6 tygodni klasyfikator działa w trybie shadow. Klasyfikuje, ale ostateczny routing robi człowiek. Porównanie decyzji AI vs decyzji konsultanta buduje ground truth do oceny modelu i ujawnia kategorie, gdzie model myli się systematycznie.
Jak mierzyć trafność routingu
#Observability dla systemu routingowego opiera się na kilku metrykach zbieranych od pierwszego dnia.
Precision i recall per kolejka. Precision: ile zgłoszeń trafiło do kolejki słusznie. Recall: ile zgłoszeń, które powinny trafić do kolejki, faktycznie tam trafiło. Szczególnie ważny recall dla kolejki krytycznej: pominięcie pilnej sprawy to incydent.
Escalation rate. Odsetek zgłoszeń przeniesionych przez konsultanta do wyższej kolejki po routingu. Wysoki escalation rate (powyżej 10-15%) sygnalizuje, że klasyfikator zaniża pilność. To główny wskaźnik błędnej deprioretyzacji.
Re-classification rate. Odsetek zgłoszeń, gdzie konsultant zmienił kategorię nadaną przez model. Powyżej 20% dla danej kategorii to sygnał do dotreniowania lub rewizji etykiet treningowych.
Time-to-first-response per kolejka vs SLA. Czy routing rzeczywiście przyspiesza obsługę? Mierzony czas od wpłynięcia zgłoszenia do pierwszej odpowiedzi konsultanta, porównany z SLA dla danego priorytetu.
Confidence score distribution. Monitoring rozkładu pewności modelu per kategoria. Jeśli kategoria „billing" regularnie wraca z confidence 0,55-0,65, model nie jest pewny i potrzebuje więcej przykładów treningowych lub przeformułowania promptu.
Spróbuj na żywo
#FAQ
#Jak długo trwa wdrożenie klasyfikatora zgłoszeń AI?
#Pilotaż shadow mode z klasyfikatorem opartym na few-shot promptingu można uruchomić w 2-4 tygodnie, jeśli masz historyczne dane zgłoszeń z etykietami. Pełne wdrożenie z integracją do helpdesku, metrykami i procedurami eskalacji zajmuje 6-12 tygodni. Większość czasu to zebranie i przejrzenie danych treningowych oraz kalibracja progów pilności, a nie samo programowanie.
Czy AI może w pełni zastąpić człowieka przy klasyfikacji zgłoszeń?
#Przy kategorii tematycznej i prostych przypadkach pilności AI osiąga trafność 85-92% na dobrze przygotowanych danych. Jednak automatyczny routing bez nadzoru człowieka ma sens tylko dla klas niskiego ryzyka (standardowe pytania, niski sentyment, znana kategoria). Zgłoszenia krytyczne, prawne i retencyjne wymagają ludzkiej weryfikacji. Cel to nie zero konsultantów, tylko uwolnienie 60-70% ich czasu od rutynowej klasyfikacji.
Co zrobić, gdy klasyfikator systematycznie myli jedną kategorię?
#Zbierz zgłoszenia z tej kategorii z ostatnich 30-60 dni, przejrzyj je z konsultantem i sprawdź, czy etykiety były spójne. Najczęstsze przyczyny: zbyt wąska lub zbyt szeroka definicja kategorii, nakładające się kategorie (np. „billing" vs „zwrot"), mała liczba przykładów treningowych (poniżej 200). Rozwiązanie: uszczegółowienie definicji, scalenie lub podział kategorii, doszycie dodatkowych przykładów, ewentualnie dodanie negatywnych przykładów (co NIE jest tą kategorią).
Jak obsługiwać wielojęzyczne zgłoszenia w jednym systemie?
#Auto-detekcja języka działa na poziomie 98%+ dla języków z wystarczającą ilością danych. Klasyfikacja kategorii i pilności działa niezależnie od języka, jeśli model bazowy jest wielojęzyczny (np. BGE-M3 do embeddingów). Routing do kolejki językowej to prosta reguła na wyjście z klasyfikatora. Problem pojawia się przy mieszanym języku w jednym zgłoszeniu lub przy dialektach. Rozwiązanie: flagowanie do ręcznej weryfikacji przy confidence językowej poniżej 0,85.
Jakie dane są potrzebne do wytrenowania klasyfikatora i jak je chronić?
#Do treningu potrzebujesz historycznych zgłoszeń z etykietami: minimum 200-500 przykładów per kategoria, minimum 100-200 per klasa pilności. Dane zgłoszeń często zawierają PII (imię, e-mail, numer konta). Przed treningiem: anonimizacja lub pseudonimizacja danych, usunięcie danych osobowych z przykładów treningowych lub ich zamaskowanie. Jeśli zgłoszenia zawierają wrażliwe dane finansowe lub zdrowotne, rozważ self-hosting modelu i przeprowadź DPIA przed wdrożeniem.
Powiązane artykuły: AI w call center, Automatyzacja obsługi klienta AI, Agent AI wielokrokowy planowanie, AI do moderacji treści. Sprawdź też narzędzie blueprint agenta do zaprojektowania architektury swojego systemu routingowego.