Automatyczna klasyfikacja zgłoszeń: jak zaprojektować kategorie i sprawdzić trafność, zanim ją włączycie

Automatyzacja obsługi zgłoszeń zaczyna się zwykle od klasyfikacji: system czyta wiadomość, ustala, czego dotyczy, i kieruje ją do właściwej osoby lub kolejki. Na stronie o automatyzacji obsługi klienta piszemy, że to najczęstszy pierwszy krok, bo pomyłka oznacza, że zgłoszenie trafi do innej osoby z obsługi, która i tak ma do niego dostęp — o ile wszyscy w zespole obsługi widzą te same zgłoszenia. Żeby ten krok był naprawdę bezpieczny, przed uruchomieniem trzeba zaprojektować trzy rzeczy: listę kategorii, kolejkę na zgłoszenia, których system nie jest pewien, i test trafności. Ten tekst opisuje je po kolei. Gdzie ten krok mieści się wśród innych automatyzacji, pokazujemy w przykładach automatyzacji AI (przykład 4).

Jeżeli dostawca podaje procent trafności, zapytajcie, na jakich zgłoszeniach go zmierzono i jak go liczono. Tutaj takiego procentu nie znajdziecie. Liczba, która ma znaczenie, powstaje na Waszych zgłoszeniach, w arkuszu, który opisujemy niżej — i jest inna dla każdej kategorii.

Jak to działa, w jednym akapicie

Zgłoszenie przychodzi mailem, z formularza albo z czatu. System — w praktyce model językowy, czyli program, który rozumie tekst i potrafi przypisać mu kategorię z listy, albo prostszy model wytrenowany na Waszych przykładach — wybiera jedną kategorię i podaje liczbę opisującą, jak bardzo jest pewien. Jeżeli pewność jest co najmniej równa progowi, zgłoszenie trafia do kolejki tej kategorii. Jeżeli poniżej, trafia do kolejki „do ręcznej oceny”, w której kategorię przypisuje człowiek. Jeżeli system, który rozważacie, takiej liczby nie podaje, zapytajcie dostawcę, jak oznacza zgłoszenia, których nie jest pewien — bez tego do kolejki ręcznej trafią najwyżej całe kategorie, a nie pojedyncze wątpliwe zgłoszenia. Priorytet i termin obsługi to osobne decyzje, do których wracamy na końcu. Jak takie przepływy buduje się w narzędziu do automatyzacji, opisaliśmy w przewodniku po n8n; tutaj zajmujemy się tym, co trzeba ustalić, zanim cokolwiek zostanie zbudowane.

Kiedy nie warto klasyfikować automatycznie

Zacznijmy od przypadków, w których odpowiedź brzmi „nie teraz”:

• Zgłoszeń jest tak mało, że jedna osoba i tak czyta wszystkie. Automat oszczędzi jej kilka kliknięć dziennie, a trafność trudno będzie wiarygodnie ocenić, zanim zbierze się wystarczająco dużo zgłoszeń.
• Wystarczy prosta reguła. Jeżeli kategorię wyznacza adres, na który przyszła wiadomość, pole wyboru w formularzu albo nadawca, reguła w skrzynce lub systemie zgłoszeń może wystarczyć — bez modelu. Sprawdźcie tylko wyjątki, na przykład klientów, którzy piszą na niewłaściwy adres. Zaczynajcie od takich reguł, a model zostawcie na resztę.
• Kategorie zmieniają się co miesiąc. Każda zmiana listy unieważnia test i trzeba go powtórzyć.
• Nikt nie jest właścicielem kolejki ręcznej. Bez tej osoby niepewne zgłoszenia czekają dłużej niż przed automatyzacją.
• Zgłoszenia przychodzą głównie telefonicznie, bez tekstu. Najpierw trzeba rozwiązać zamianę mowy na tekst, a to osobny problem z osobnymi błędami.
• Pomyłka kosztuje więcej niż przekazanie i opóźnienie. Formalne reklamacje z terminami wynikającymi z przepisów lub umów, zgłoszenia awarii zagrażających bezpieczeństwu, sprawy prawne — takie kategorie zostają w rękach człowieka albo trafiają do niego stałą regułą, niezależnie od modelu.

Lista kategorii: z prawdziwych zgłoszeń, nie ze schematu organizacyjnego

Lista kategorii powstaje z próbki prawdziwych zgłoszeń. Proponujemy wylosować około dwustu spraw z ostatnich trzech miesięcy ze wszystkich kanałów pisemnych. Jednostką jest sprawa, a nie wiadomość: jeżeli eksport ma osobny wiersz dla każdej wiadomości, najpierw zostawcie jeden wiersz na sprawę, bo inaczej długie wątki trafiałyby do próbki częściej. Potem w Excelu dodajcie kolumnę z funkcją LOS, skopiujcie ją i wklejcie jako wartości (bo LOS losuje na nowo przy każdym przeliczeniu arkusza), posortujcie i weźcie pierwsze dwieście wierszy. Jeżeli spraw było mniej, weźcie wszystkie. Systemowi pokażcie potem tylko to, co było znane w chwili pierwszego kierowania zgłoszenia: pierwszą wiadomość i pola formularza, bez późniejszych odpowiedzi, bo te często zdradzają właściwą kategorię.

Zanim przypiszecie kategorie zgłoszeniom z próbki, przejrzyjcie kilkadziesiąt zgłoszeń spoza niej i spiszcie kategorie według tego, kto i jak obsługuje sprawę, a nie według katalogu produktów czy działów firmy. Pytanie kontrolne brzmi: czy dwa zgłoszenia z tej samej kategorii trafiają do tej samej osoby i obsługuje się je podobnie? Do listy dodajcie kategorię „inne”. Ustalcie też od razu, co dzieje się ze zgłoszeniem, które system oznaczy jako „inne”: proponujemy kierować je do kolejki ręcznej, bo „inne” nie ma swojej osoby.

Dlaczego od ośmiu do piętnastu, a nie czterdzieści

Na początek proponujemy od ośmiu do piętnastu kategorii. To punkt wyjścia, a nie reguła ani wynik obliczeń, ale stoi za nim prosty rachunek:

• w kategorii, do której należy pięć zgłoszeń, jedna pomyłka zmienia jej wynik o 20 punktów procentowych;
• w kategorii z dwudziestoma zgłoszeniami jedna pomyłka to 5 punktów procentowych.

Przy dwustu zgłoszeniach i czterdziestu kategoriach na kategorię przypada średnio pięć zgłoszeń, przy dziesięciu kategoriach — średnio dwadzieścia. Nawet dwadzieścia to niewiele. Jeżeli system trafnie rozpoznał 18 z 20 zgłoszeń, wynik wynosi 90%, ale przy tak małej liczbie zgłoszeń prawdziwa trafność może leżeć mniej więcej między 70% a 97% (to przedział ufności 95% liczony metodą Wilsona, opisaną w podręczniku statystyki NIST — źródło podajemy na końcu). Taki test pokazuje więc wyraźne problemy, a nie różnice o kilka punktów. Im więcej zgłoszeń miesięcznie, tym dłuższą listę da się sprawdzić; przy małej liczbie zgłoszeń wyniki rzadkich kategorii trzeba zbierać dłużej.

Średnia to nie wszystko: rzadkie kategorie dostaną w próbce po kilka zgłoszeń. Jeżeli chcecie, żeby system kierował je automatycznie, dobierzcie dla nich dodatkowe przykłady ze starszych miesięcy — o ile obsługuje się je tak samo jak dziś. Na tych przykładach sprawdzajcie tylko, ile prawdziwych zgłoszeń z danej kategorii system rozpoznaje i z czym je myli. Oceniajcie je w osobnej kopii arkusza, a precyzję i udziały kategorii liczcie wyłącznie na losowej próbce, bo dobrane przykłady zmieniają proporcje między kategoriami.

Gdzie ludzie przypisują różne kategorie

Poproście drugą osobę z obsługi, żeby niezależnie przypisała kategorie kilkudziesięciu zgłoszeniom z próbki. Tam, gdzie dwie osoby wybierają różne kategorie, przyjrzyjcie się przyczynie. Czasem zgłoszenie dotyczy dwóch spraw naraz — wtedy przypiszcie kategorię osoby, która powinna zająć się nim jako pierwsza. Przyczyną może być też niejasna definicja: dopiszcie do niej jedno zdanie i przykład albo połączcie obie kategorie w jedną. Podobnie radzi Microsoft w dokumentacji swojej usługi do klasyfikacji tekstu: jeżeli model stale myli dwie kategorie, warto rozważyć ich połączenie.

Stałe reguły dla kategorii, w których nie wolno się pomylić

Kategorie, o których pisaliśmy przy przypadkach „nie teraz” — formalne reklamacje z terminem, awarie, sprawy prawne — rozpoznawajcie na początek stałymi regułami: po polu formularza, adresie albo konkretnych słowach. Zgłoszenie, które spełnia regułę, trafia do człowieka niezależnie od tego, co wskaże model. W sprawach, w których pomyłka jest niedopuszczalna, reguła musi opierać się na sygnale, którego nie da się ominąć: obowiązkowym polu formularza albo osobnym adresie, z którego klienci rzeczywiście muszą korzystać. Reguła oparta na słowach może pomóc, ale nie wystarczy — to, że w teście niczego nie przepuściła, nie gwarantuje, że wychwyci kolejne takie sprawy. Jeżeli takiego sygnału nie ma, zgłoszenia, wśród których mogą się znaleźć takie sprawy, zostają w rękach człowieka. Każdą regułę sprawdźcie też na tej samej próbce: ile takich spraw rozpoznała, a ile przepuściła, bo klient opisał je innymi słowami. To osobny test: osoba przypisująca wzorzec zaznacza, czy zgłoszenie powinno zostać wychwycone przez regułę, a potem porównujecie to z tym, czy reguła zadziałała — najprościej w osobnej kopii arkusza, w kolumnie „Uwagi”.

Etykieta człowieka jako wzorzec

Teraz osoba, która na co dzień obsługuje zgłoszenia, przypisuje właściwą kategorię każdemu zgłoszeniu z próbki. To jest wzorzec, z którym porówna się system, więc obowiązują trzy zasady: kategorie przypisuje się, zanim zobaczy się odpowiedź systemu, używa się dokładnie tej listy kategorii, którą dostanie system, i patrzy się tylko na to, co system też dostanie — pierwszą wiadomość i pola formularza, bez późniejszych odpowiedzi klienta. Przy minucie na zgłoszenie dwieście zgłoszeń to 3 godziny i 20 minut; policzcie to dla siebie, bo długie pierwsze wiadomości zajmują więcej czasu.

Pobierzcie szablon arkusza (Excel). Użyjcie osobnej kopii pliku dla próbki do poprawek i osobnej dla testu na nowych zgłoszeniach, o którym niżej. Arkusz „Próbka” mieści do tysiąca zgłoszeń i ma takie kolumny:

W arkuszu „Kategorie” wpisujecie swoją listę kategorii i, po ustaleniu, próg pewności dla każdej z nich. Arkusz sam liczy dla każdej kategorii precyzję i czułość, o których piszemy niżej, a także liczbę zgłoszeń skierowanych automatycznie i oddanych do ręcznej oceny. Jeżeli system nie podaje pewności, wpiszcie 1 przy każdym zgłoszeniu (to umowna wartość, a nie zmierzona pewność): kategorie kierowane automatycznie dostają próg 1, a pozostałe zostają bez progu i w całości trafiają do ręcznej oceny. Zestawienie numerów wierszy z numerami zgłoszeń w Waszym systemie trzymajcie osobno, poza arkuszem. Do arkusza nie przepisujcie imion, adresów, numerów zamówień ani treści wiadomości, bo kolumny ich nie potrzebują. Treść zgłoszeń, które system ma sklasyfikować, zwykle zawiera dane osobowe klientów. Zasady przekazywania ich do modelu językowego, w tym to, co wynika z RODO (ogólnego rozporządzenia o ochronie danych), opisaliśmy na stronie o bezpieczeństwie i RODO.

Dwa etapy testu: próbka, potem nowe zgłoszenia

Ogólną zasadę uruchamiania nowego systemu obok dotychczasowej pracy, zanim ją zastąpi, opisaliśmy w szóstym kroku tekstu o tym, jak wdrożyć AI w firmie. Przy klasyfikacji zgłoszeń ważne jest jedno rozróżnienie: próbka, na której poprawiacie listę kategorii i ustawiacie progi, nie może być tą samą, na której potem sprawdzacie wynik. Kto raz za razem poprawia ustawienia pod jedną próbkę, dostaje wynik dopasowany do tej próbki — dlatego Google w swoim kursie uczenia maszynowego zaleca ostateczne sprawdzenie na danych, których wcześniej nie używano. W praktyce:

1. Próbka służy do poprawek. System klasyfikuje te same dwieście zgłoszeń, którym kategorie przypisał człowiek. Na wynikach poprawiacie definicje kategorii, łączycie mylone kategorie i ustalacie progi. Po każdej zmianie nazwy, połączeniu kategorii albo zmianie definicji, która przesuwa zgłoszenia między kategoriami, przypiszcie kategorię na nowo tym zgłoszeniom z próbki, których dotyczy zmiana — arkusz pokazuje, ile etykiet nie ma już na liście. Po każdej zmianie definicji kategorii albo ustawień systemu puśćcie system jeszcze raz na całą próbkę, bo jego wcześniejsze odpowiedzi dotyczyły starej wersji. Progi ustalajcie dopiero na nowych wynikach. Żadne zgłoszenie nie trafia jeszcze nigdzie automatycznie.
2. Ustawienia się zamraża. Lista kategorii, reguły, ustawienia systemu i progi zostają zapisane i nie zmieniają się do końca testu.
3. Nowe zgłoszenia służą do decyzji. System klasyfikuje bieżące zgłoszenia, ale kieruje je nadal człowiek, tak jak dziś, i nie widzi przy tym podpowiedzi systemu. Zapisuje się kategorię wybraną przez system, jego pewność i kierunek, który wynikałby z zamrożonych progów, a obok pierwszą kategorię nadaną przez osobę kierującą, sprzed ewentualnej poprawki. Człowiek też się myli, więc wyniki liczy się na losowej próbce nowych zgłoszeń, którym właściciel kolejki ręcznej przypisuje kategorię niezależnie — na podstawie pierwszej wiadomości, pól formularza i definicji kategorii, bez zaglądania do odpowiedzi systemu i osoby kierującej. Zgłoszenia, przy których system i osoba kierująca wskazali różne kategorie, warto przejrzeć osobno — dopiero po przypisaniu kategorii w próbce — żeby zrozumieć pomyłki, ale do wyników trafiają tylko te, które znalazły się w losowej próbce. Wzorcem jest kategoria właściciela kolejki (a jeżeli to on kierował dane zgłoszenie — innej osoby, która go nie kierowała) dla każdego zgłoszenia z próbki — rozbieżność z osobą kierującą niczego w nim nie zmienia, bo to jej trafność jest mierzona. Jeżeli chcecie pewniejszego wzorca, niech drugą kategorię niezależnie przypisze jeszcze jedna osoba, też bez patrzenia na system i na osobę kierującą, a rozbieżności między tymi dwiema osobami rozstrzyga trzecia. Test trwa, aż każda kategoria, którą chcecie włączyć, zbierze w tej losowej próbce liczby zgłoszeń zapisane przed startem testu albo aż minie zapisany z góry najdłuższy czas testu — zależnie od tego, co nastąpi wcześniej (o tym niżej). Decyzję o włączeniu podejmuje się na podstawie wyników z tego etapu. W arkuszu ostateczny, uzgodniony wzorzec trafia do kolumny „Kategoria — wzorzec”, a pierwotna kategoria osoby kierującej — do osobnej kolumny, dzięki czemu widać i wynik systemu, i dzisiejszą trafność ludzi.
4. Dzisiejsze pomyłki ludzi. W tym samym czasie policzcie, jak często już dziś zgłoszenie trafia do niewłaściwej osoby i ile czasu mija, zanim dotrze do właściwej. Ludzie też się mylą, a bez tych liczb nie będzie z czym porównać wyniku po uruchomieniu.

Dwie liczby na każdą kategorię

Jedna łączna liczba — „system trafia w 80% przypadków” — mówi niewiele, bo ukrywa kategorie, w których system myli się najczęściej. Dlatego dla każdej kategorii liczy się dwie liczby. Najpierw po ludzku, na przykładzie reklamacji:

• Z tego, co system skierował do reklamacji, ile naprawdę było reklamacjami? Ta liczba nazywa się precyzją. Niska precyzja oznacza, że osoba od reklamacji dostaje cudze zgłoszenia.
• Ze wszystkich prawdziwych reklamacji, ile system skierował automatycznie do właściwej kolejki? Ta liczba nazywa się czułością. Niska czułość oznacza, że część reklamacji trafiła gdzie indziej albo do kolejki ręcznej.

Wzory, w tej samej postaci, w jakiej podają je dokumentacja Microsoftu i kurs uczenia maszynowego Google:

• precyzja = zgłoszenia trafnie skierowane do danej kategorii ÷ wszystkie zgłoszenia skierowane przez system do tej kategorii;
• czułość = zgłoszenia trafnie skierowane do danej kategorii ÷ wszystkie zgłoszenia, które według wzorca należą do tej kategorii.

Obie liczby odczytuje się z tabeli pomyłek: wiersze to kategoria wzorcowa, kolumny to kierunek wybrany przez system po zastosowaniu progów. Trafne skierowania leżą na przekątnej, pomyłki widać od razu poza nią — także to, z którą kategorią system myli daną kategorię najczęściej. Kolumna „do ręcznej oceny” to zgłoszenia oddane człowiekowi: nie są pomyłką w kierowaniu, ale obniżają czułość, bo system nie skierował ich automatycznie. W Excelu przygotujecie ją za pomocą tabeli przestawnej: w wierszach kolumna „Kategoria — wzorzec”, w kolumnach „Kierunek”, w wartościach liczba z kolumny „Kategoria — wzorzec”; puste wiersze („(puste)”) odfiltrujcie, bo arkusz ma miejsce na tysiąc zgłoszeń. Pojedynczą liczbę policzy też funkcja LICZ.WARUNKI, na przykład liczba wierszy, w których kategoria wzorcowa to „reklamacja”, a kierunek to „reklamacja”, podzielona przez liczbę wierszy z kierunkiem „reklamacja”.

Przykład: dwieście zgłoszeń, cztery kategorie

Poniższe liczby są wymyślone, żeby pokazać arytmetykę. Nie są wynikiem żadnej firmy ani punktem odniesienia. Próbka liczy dwieście zgłoszeń, progi są już ustalone, a zgłoszenia oznaczone przez system jako „inne” trafiają, tak jak proponowaliśmy, do kolejki ręcznej.

Z tej tabeli:

Kategoria „inne” nie ma tu własnej precyzji, bo nie ma swojej kolejki. Liczy się co innego: szesnaście zgłoszeń, które naprawdę są „inne”, system skierował do konkretnych osób. Warto je obejrzeć jako pierwsze.

Łącznie system skierowałby automatycznie 132 zgłoszenia z 200, z tego 111 trafnie, czyli około 84%, a 21 do niewłaściwej osoby. Kolejne 68 zgłoszeń trafiłoby do kolejki ręcznej, w tym 54, które naprawdę są „inne”. Ta jedna liczba — 84% — nie mówi, że faktury mają precyzję 60%, a dwie reklamacje wylądowały u osoby od statusów zamówień. Pamiętajcie też o rachunku z początku: przy kategoriach z dwudziestoma czy trzydziestoma zgłoszeniami pojedyncze pomyłki mocno przesuwają wynik.

Próg pewności i kolejka „do ręcznej oceny”

Liczba opisująca pewność systemu niekoniecznie coś znaczy — trzeba to sprawdzić na próbce. Weźcie wiersze, w których system wybrał daną kategorię, posortujcie je według pewności i zobaczcie, gdzie skupiają się pomyłki. W arkuszu przefiltrujcie kolumnę „Kategoria — system”, skopiujcie widoczne wiersze, wklejcie je jako wartości do nowego arkusza i tam je posortujcie — arkusz z próbką jest chroniony, żeby nie nadpisać formuł. Jeżeli przy wysokiej pewności pomyłek prawie nie ma, a przy niskiej jest ich dużo, próg ma sens. Ustawiacie go tam, gdzie pomyłki powyżej progu są do przyjęcia przy koszcie pomyłki w tej kategorii. Jeżeli pomyłki rozkładają się równo przy każdej pewności, próg nic nie da, a kategoria zostaje w rękach człowieka.

Próg ustala się dla każdej kategorii osobno. Działa to w jedną stronę: im wyższy próg, tym więcej zgłoszeń trafia do kolejki ręcznej i tym mniej pomyłek przechodzi dalej. Dla kategorii, w której pomyłka oznacza tylko przekazanie w zespole, próg może być niższy niż dla kategorii, w której pomyłka opóźnia coś ważnego.

Kolejka „do ręcznej oceny” to część projektu, a nie śmietnik. Potrzebuje właściciela z imienia i nazwiska, zastępcy i terminu obsługi — jak każda kolejka spraw czekających na decyzję człowieka, o czym piszemy w tekście o zatwierdzaniu przez człowieka. Liczcie też jej wielkość: jeżeli trafia do niej większość zgłoszeń, automat niewiele zmienia, a jeżeli jej właściciel nie nadąża, niepewne zgłoszenia czekają dłużej niż dziś.

Decyzja: które kategorie kierować automatycznie

Zanim zobaczycie wyniki z nowych zgłoszeń, zapiszcie dla każdej kategorii trzy rzeczy: minimalną precyzję, którą przyjmiecie, minimalną liczbę zgłoszeń skierowanych przez system do tej kategorii, po której ocenicie precyzję, i minimalną liczbę zgłoszeń, które według wzorca do niej należą, po której ocenicie czułość. Test trwa, aż osiągnięte zostaną obie minimalne liczby zgłoszeń — do oceny precyzji i do oceny czułości. Zapiszcie też najdłuższy czas testu — test kończy się na tym, co nastąpi wcześniej. Kategoria, która do tego czasu nie zbierze wymaganych zgłoszeń (na przykład dlatego, że system prawie nigdy jej nie wskazuje albo wszystko oddaje do ręcznej oceny), zostaje w rękach człowieka. Jeżeli kategoria ma się opłacać, a nie tylko nie szkodzić, zapiszcie też minimalną czułość. Niska czułość ma dwie przyczyny. Zgłoszenia oddane do kolejki ręcznej nie szkodzą, o ile ta kolejka nadąża w ustalonym terminie — ale wtedy automat przejmuje niewiele pracy. Zgłoszenia skierowane automatycznie do innej kategorii to już pomyłki i szkodzą: obniżają precyzję tamtej kategorii i widać je w tabeli pomyłek. Zapisanie tych warunków wcześniej chroni przed dopasowaniem wymagań do wyniku, który akurat wyszedł. Pamiętajcie przy tym, że precyzja i czułość mają różne podstawy: precyzję liczy się ze zgłoszeń skierowanych do kategorii, czułość — ze zgłoszeń, które do niej naprawdę należą. Kategoria może mieć wiele prawdziwych zgłoszeń, a mało skierowanych; jeżeli system nie skierował do niej żadnego, precyzji po prostu nie da się policzyć — to nie jest 0%. Przy małej liczbie zgłoszeń wynik jest obarczony dużą niepewnością, jak w przykładzie z 18 na 20. Minimalna precyzja zależy od kosztu pomyłki, więc nie podajemy jej za Was. Kategorię włącza się tylko wtedy, gdy spełnione są też warunki wspólne: osoby, do których trafi, mają dostęp do tych zgłoszeń, a kolejka ręczna ma obsadę na zgłoszenia, które do niej spłyną. Potem decyzja wygląda tak:

W pierwszej wersji pomyłki poprawia człowiek. Osoba, która dostała nie swoje zgłoszenie, odsyła je do kolejki ręcznej, a jej właściciel przypisuje je właściwej osobie. Warto zadbać, żeby odesłanie było proste — jeden przycisk albo ustalona etykieta — bo inaczej źle skierowane zgłoszenia będą przekazywane z ręki do ręki bez śladu. Kiedy kategorię można zostawić bez stałej kontroli i po jakim zdarzeniu kontrola wraca, opisaliśmy w tekście o zatwierdzaniu przez człowieka — te zasady stosuje się do każdej kategorii osobno.

Ile kosztuje pomyłka i jak ją zmierzyć

Strona usługi mówi, że źle skierowane zgłoszenie trafia do innej osoby z obsługi, która i tak ma do niego dostęp. To prawda, jeżeli wszyscy w zespole obsługi widzą te same zgłoszenia — sprawdźcie to w uprawnieniach, zanim założycie. Kosztem jest wtedy dodatkowe przekazywanie — do kolejki ręcznej i dalej do właściwej osoby — i opóźnienie. Ten koszt mierzy się w trzech miejscach:

• w teście na nowych zgłoszeniach — ile zgłoszeń, które system skierowałby automatycznie, miało inną kategorię niż wzorzec. To są pomyłki możliwe, a nie faktyczne, bo zgłoszenia kierowała jeszcze osoba kierująca;
• w dzisiejszej pracy — jak często człowiek kieruje zgłoszenie do niewłaściwej osoby i ile czasu mija do chwili, w której dotrze do właściwej;
• po uruchomieniu pierwszych kategorii — jaka część zgłoszeń skierowanych automatycznie wróciła do kolejki ręcznej albo dostała od człowieka inną kategorię (to odsetek powrotów i zmian kategorii, z którego wyodrębnia się pomyłki — o tym niżej) i ile czasu minęło od wpływu do chwili, w której zgłoszenie dotarło do osoby, która je ostatecznie obsłużyła.

Przy każdym powrocie albo zmianie kategorii zapiszcie przyczynę. Za pomyłkę klasyfikacji uznajcie błędne skierowanie na podstawie informacji dostępnych w chwili kierowania; osobno oznaczcie zmiany wynikające z nowych informacji od klienta albo z organizacji pracy. Nie wliczajcie do pomyłek zgłoszeń skierowanych od razu do kolejki ręcznej: tam kategorię nadaje człowiek, zgodnie z projektem. Wliczajcie natomiast zgłoszenia skierowane automatycznie do niewłaściwej osoby, nawet jeśli potem wróciły do tej kolejki — każde tylko raz, niezależnie od liczby powrotów. Porównujcie też liczby o tej samej podstawie. Osobno liczcie odsetek pomyłek wśród zgłoszeń skierowanych automatycznie, a osobno — przed i po uruchomieniu — odsetek pomyłek wśród wszystkich zgłoszeń należących do włączonych kategorii, łącznie z tymi obsłużonymi ręcznie. Obok podajcie udział kolejki ręcznej i czas dotarcia do właściwej osoby dla wszystkich zgłoszeń — inaczej wynik poprawi się na papierze tylko dlatego, że trudne zgłoszenia przeszły do kolejki ręcznej.

Jest jeden wyjątek, o którym trzeba pamiętać przy projektowaniu kolejek. Przekazanie między osobami z obsługi klienta zostaje w kręgu osób, które mają dostęp do zgłoszeń. Jeżeli jednak kategoria kieruje zgłoszenia do innego działu — finansów, kadr, prawników — pomyłka może pokazać dane klienta osobie, która nie powinna ich widzieć. Takie kierowanie zostawcie na początek człowiekowi albo skierujcie do kolejki ręcznej. Szczególnie uważajcie na zgłoszenia, w których klienci sami opisują na przykład swoje zdrowie; więcej o tym piszemy na stronie o bezpieczeństwie i RODO.

Co zapisywać przy każdym zgłoszeniu

Bez zapisu nie policzycie żadnej z powyższych liczb po uruchomieniu. Przy każdym zgłoszeniu wystarczy kilka pól:

• kanał i czas wpływu;
• kategoria wybrana przez system i jego pewność;
• wersja listy kategorii, reguł, progów i ustawień systemu, według których zgłoszenie sklasyfikowano;
• kolejka, do której zgłoszenie trafiło, i czas skierowania;
• czy i kiedy automatycznie skierowane zgłoszenie wróciło do kolejki ręcznej;
• kategoria nadana ostatecznie przez człowieka, kto ją zmienił, kiedy i z jakiej przyczyny (pomyłka, nowe informacje od klienta czy organizacja pracy);
• kiedy zgłoszenie dotarło do osoby, która je ostatecznie obsłużyła.

Treść zgłoszenia jest już w systemie zgłoszeń — w zapisie o klasyfikacji nie trzeba jej powielać.

Priorytet ustalany przez model: nie w pierwszej wersji

Na stronie usługi nadanie priorytetu wymieniamy razem z rozpoznawaniem i kierowaniem, bo to jeden krok procesu. W pierwszej wersji priorytet ustalają jednak stałe reguły, a nie model. Nadawanie priorytetu przez model, czyli rozpoznawanie pilności, wygląda na drobny dodatek, ale to druga klasyfikacja, z własną listą, własnym testem i dwoma różnymi rodzajami pomyłek: pilne zgłoszenie uznane za zwykłe czeka za długo, a zwykłe uznane za pilne zabiera czas potrzebny na naprawdę pilne sprawy. Dlatego najpierw uruchamia się kategorie. Sprawy, które nie mogą czekać, rozpoznaje się na początek stałymi regułami — po nadawcy, polu formularza albo konkretnych słowach — i kieruje prosto do człowieka. Te reguły też sprawdzajcie na próbce, bo mogą przepuścić pilną sprawę opisaną innymi słowami. Jeżeli nie ma sygnału, którego nie da się ominąć, na przykład obowiązkowego pola, pilne sprawy zostają w rękach człowieka. Terminy obsługi, które obowiązują dziś, zostają bez zmian, także dla kolejki ręcznej — w pierwszej wersji model ich nie ustala ani nie zmienia. Priorytet oparty na modelu przychodzi dopiero wtedy, gdy kategorie działają i jest dla niego osobna próbka.

Co dalej

Wylosujcie próbkę, spiszcie kategorie i poproście osobę z obsługi o przypisanie ich dwustu zgłoszeniom. To jeszcze żaden system, a już na tym etapie zobaczycie, które kategorie ludzie mylą ze sobą i ile zgłoszeń trafia do „innych”. Dopiero potem warto rozmawiać z dostawcą i poprosić, żeby sklasyfikował tę samą próbkę. Zanim jakiekolwiek zgłoszenie trafi do jego modelu — także uruchomionego „w Waszym środowisku”, bo model wciąż może działać u dostawcy — ustalcie, które pola opuszczają firmę, kto je dostaje, w jakim regionie są przetwarzane, na jakiej podstawie prawnej i czy mogą posłużyć do trenowania modelu. Dopóki tego nie ustalicie, nie przekazujcie prawdziwych zgłoszeń nawet po usunięciu imion i adresów: treść wiadomości wciąż może wskazywać konkretną osobę albo zawierać poufne informacje firmy. Na tym etapie wystarczą zgłoszenia przykładowe, napisane przez Was na wzór prawdziwych. Pytania do dostawcy zebraliśmy na stronie o bezpieczeństwie i RODO. Jak w ploch.ai podchodzimy do automatyzacji jednego procesu, od pomiaru przez pilotaż po utrzymanie, opisujemy na stronie o automatyzacji AI w firmie.

Źródła i stan na 12 października 2026 roku

• Microsoft Learn — „Custom text classification model concepts” — wzory na precyzję i czułość liczone dla każdej kategorii osobno, tabela pomyłek i zalecenie, by rozważyć połączenie kategorii, które model stale myli; przykład zgłoszeń do pomocy technicznej, przy których pomyłka kieruje zgłoszenie do złego zespołu; odczyt 12 października 2026 r.
• Google for Developers — „Classification: Accuracy, recall, precision, and related metrics” — definicje precyzji i czułości oraz to, dlaczego sama trafność łączna wprowadza w błąd, gdy jedna klasa jest rzadka; odczyt 12 października 2026 r.
• Google for Developers — „Thresholds and the confusion matrix” — próg zamieniający wynik modelu na decyzję i tabela pomyłek; odczyt 12 października 2026 r.
• Google for Developers — „Datasets: Dividing the original dataset” — ostateczne sprawdzenie modelu na osobnym zbiorze danych i to, że zbiór, na którym stale poprawia się ustawienia, „zużywa się”; odczyt 12 października 2026 r.
• NIST/SEMATECH e-Handbook of Statistical Methods, 7.2.4.1 „Confidence intervals” — przedział ufności dla udziału w próbce, w tym metoda Wilsona zalecana przy małych próbkach. Dla 18 trafień na 20 zgłoszeń przedział 95% wynosi w przybliżeniu od 70% do 97%; odczyt 12 października 2026 r.
• Microsoft — funkcja LOS, funkcja LICZ.WARUNKI i tworzenie tabeli przestawnej w polskiej wersji Excela; odczyt 12 października 2026 r.