Decyzja w procesie obsługi
Sam wydźwięk wypowiedzi klienta nie wyjaśnia, czy zgłoszenie może prowadzić do eskalacji. Emocjonalna wiadomość może dotyczyć rutynowej sprawy, a neutralna — kolejnego etapu długo nierozwiązanego problemu. Ocena ryzyka wymaga więc spojrzenia na sekwencję i kontekst interakcji, a nie tylko na treść ostatniego zgłoszenia.
Zbudowaliśmy model wspierający decyzję o tym, które sprawy mogą wymagać wcześniejszej analizy. Projekt rozpoczął się od proof of concept, przeszedł przez MVP i dotarł do implementacji w środowisku dużej firmy technologicznej. System wspierał ocenę pracownika, zamiast przedstawiać pojedynczy wynik jako dowód, że eskalacja nastąpi.
Cel predykcji wymaga również dokładnego horyzontu czasowego. Eskalacja przed następną odpowiedzią, podczas bieżącej sprawy lub przy późniejszym przeglądzie konta odpowiada innym decyzjom. Bez takiej definicji dane historyczne mogą łączyć kilka rodzajów zdarzeń i pozornie zawyżać przydatność modelu dla rzeczywistego procesu obsługi.
Użyteczny sygnał powinien pomagać zespołowi ustalać kolejność przeglądu i pokazywać kontekst wyniku. Nie powinien automatycznie zmieniać poziomu obsługi, ograniczać klienta ani wywoływać decyzji handlowej bez ustalonej zasady i odpowiedzialnej osoby.
Sygnały rozważane w projekcie
Model łączył kilka rodzajów informacji.
- historię i powtarzalność problemów klienta;
- kontekst operacyjny i informacje o koncie istotne dla procesu obsługi;
- cechy językowe wydobywane z wiadomości i odpowiedzi.
Połączenie tych sygnałów dawało więcej kontekstu niż wyszukiwanie słów kluczowych lub prosty podział wypowiedzi na pozytywne i negatywne. Publiczny opis nie ujawnia pól klienta, progów ani wewnętrznych zasad dotyczących danych konta.
Wybór cech wpływa zarówno na przydatność, jak i na nadzór nad systemem. Historia interakcji może ujawniać powtarzające się problemy, opóźnienia odpowiedzi, przekazania spraw i zmiany tonu. Kontekst konta może wyjaśniać priorytet lub zobowiązania serwisowe, ale może też prowadzić do nieuzasadnionych różnic w traktowaniu klientów. Każde pole potrzebuje więc uzasadnienia operacyjnego, właściciela i reguł dostępu.
Projekt powstał przed dostępnością współczesnych modeli transformatorowych i dużych modeli językowych dla tego rodzaju implementacji. Użyliśmy więc klasycznego przetwarzania języka naturalnego do wyznaczania cech językowych i dostosowaliśmy to podejście do istniejących standardów technologicznych firmy.
Od proof of concept do implementacji
Proof of concept sprawdzał, czy historię obsługi, kontekst konta i cechy językowe z NLP można połączyć w użyteczny model ryzyka eskalacji. MVP rozszerzyło model o szerszy proces pracy. Finalna implementacja musiała następnie pasować do wytycznych, systemów i ograniczeń operacyjnych przedsiębiorstwa.
W takim systemie wynik musi odpowiadać jasno określonemu sposobowi pracy: kto widzi sygnał, jakie informacje otrzymuje i jaką decyzję może podjąć. Od tych ustaleń zależy także sposób oceny fałszywych alarmów i pominiętych eskalacji.
Pracownik potrzebował kontekstu pozwalającego ocenić, czy alert wynikał z rzeczywistego wzorca, czy z niepełnych danych. Implementacja musiała więc pasować do otaczającego procesu obsługi, zamiast działać jako odizolowany endpoint predykcyjny.
Informacja zwrotna od osób oceniających byłaby potrzebna do odróżnienia poprawnej predykcji od użytecznej interwencji. Alert wyświetlony po faktycznej eskalacji ma niewielką wartość operacyjną. Ewaluacja powinna więc obejmować czas i możliwość podjęcia działania, a nie tylko jakość klasyfikacji.
Granice ewaluacji
Prace przeszły od proof of concept przez MVP do implementacji. Publiczne materiały nie zawierają wyniku trafności, definicji zbioru testowego, punktu odniesienia ani progu alertów, dlatego realizacja ich nie podaje.
Progi alertów powinny być oceniane w odniesieniu do rzeczywistej przepustowości zespołu obsługi, a nie wybierane wyłącznie na podstawie wyniku modelu. Użycie danych o koncie lub relacji handlowej wymagałoby też uzasadnienia biznesowego, reguł dostępu i sprawdzenia ryzyka niepożądanej stronniczości.
Wyniki ewaluacji powinny odnosić się do wybranego momentu decyzji i punktu porównania. Trzeba też podać, ile spraw przy danym progu trafia do przeglądu. Sama precyzja i czułość nie pokażą, czy zespół może obsłużyć alerty ani czy system nadal pomija ważne przypadki.
Testy operacyjne powinny uwzględniać aktualność danych, brakujące historie, ponownie otwarte sprawy, zmiany kolejek i opóźnione etykiety. Monitoring powinien wykrywać zmiany w strukturze zgłoszeń lub praktykach eskalacji, które podważają wcześniejszą ocenę.
Potwierdzony rezultat
Projekt zakończył się implementacją funkcji predykcji eskalacji dla dużej firmy technologicznej po wcześniejszych etapach proof of concept i MVP. Pokazuje, jak dostosować system NLP do wytycznych i istniejących systemów przedsiębiorstwa, gdy nowsze transformatory i narzędzia LLM nie są dostępne.
Potwierdzonym rezultatem jest przejście do implementacji. Realizacja nie podaje konkretnej trafności, spadku liczby eskalacji, poprawy satysfakcji klienta ani ilościowej korzyści operacyjnej, ponieważ te miary nie są dostępne do publikacji.
W podobnym projekcie pierwszym krokiem jest zdefiniowanie zdarzenia eskalacyjnego oraz decyzji pracownika, którą ma zmienić sygnał. Następnie niewielka, sprawdzona próba może pokazać, czy potrzebna historia i kontekst są dostępne przed budową systemu predykcyjnego.