Kontekst: dlaczego ISP potrzebował voicebota

Klient to regionalny dostawca internetu, jakieś 80 pracowników, obsługują klientów biznesowych i indywidualnych w trzech województwach. Ich dział wsparcia miał trzy osoby na słuchawkach i odbierał dziennie gdzieś między 120 a 180 połączeń. Średni czas oczekiwania na połączenie: 8 minut w szczycie, 3 minuty poza szczytem. Klienci byli wściekli. Zespół był wypalony. Dwóch koordynatorów odeszło w ciągu pół roku.

Prezes zadzwonił do mnie we wtorek, pod koniec lutego. Powiedział że potrzebują "czegoś co odbierze telefony jak nie mają nikogo wolnego". Zapytałem czy szukają voicebota czy systemu kolejkowania. Odpowiedział że nie wie jaka jest różnica. To była dobra rozmowa.

Po audycie pierwszego tygodnia okazało się że gdzieś połowa wszystkich połączeń to cztery typy spraw: awaria internetu, pytanie o fakturę, zmiana danych i pytanie o termin wizyty technika. Żadna z tych spraw nie wymagała decyzji. Wszystkie miały ścieżkę obsługi którą dało się opisać w kilku krokach.

Co voicebot robi, a czego nie

Voicebot który zbudowaliśmy odpowiada na cztery typy zgłoszeń. Przy awarii internetu sprawdza status usługi w systemie monitoringu, jeśli awaria jest znana, informuje klienta o przewidywanym czasie naprawy i tworzy ticket w Freshdesku. Jeśli awaria nie jest znana, przeprowadza krótką diagnostykę (czy router odpowiada, czy inne urządzenia w sieci działają) i na podstawie odpowiedzi albo podaje rozwiązanie, albo tworzy ticket z notatką dla technika.

Przy pytaniu o fakturę pobiera dane z systemu bilingowego i podaje kwotę, termin i status płatności. Przy zmianie danych zbiera nowe informacje i tworzy zadanie weryfikacyjne. Przy umawianiu wizyty technika sprawdza dostępne terminy i rezerwuje.

Czego voicebot nie robi: nie obsługuje reklamacji, nie negocjuje opłat, nie rozmawia z klientami którzy są wyraźnie zdenerwowani i chcą eskalacji. Te połączenia są przekierowywane do zespołu z transkrypcją dotychczasowej rozmowy.

I tu jest pierwsza rzecz którą musicie wiedzieć o voicebotach: voicebot to nie jest tańszy pracownik. To jest filtr. Filtruje proste sprawy i przepuszcza trudne. Jeśli wasz zespół składa się z samych trudnych spraw, voicebot nic nie da, bo nie będzie miał co filtrować.

Jak przebiegało wdrożenie

Wdrożenie trwało 7 tygodni. Pierwsze dwa tygodnie spędziliśmy słuchając nagrań. Odsłuchaliśmy około trzystu połączeń, żeby zrozumieć jak klienci mówią o swoich problemach. Nie jak myślimy że mówią, tylko jak mówią naprawdę.

Odkrycie: klienci nie mówią "mam awarię internetu". Mówią: "nie działa mi net", "internet padł", "nie mogę się połączyć", "wifi nie działa", "nie ładuje mi stron", "jestem bez internetu", "chłopie wyłączone jest". Ponad dwadzieścia różnych sformułowań na to samo. Voicebot musi rozumieć wszystkie.

Potem zbudowaliśmy drzewa konwersacji. Nie flow, drzewa. Bo rozmowa z człowiekiem nie jest flowem, rozwidla się. Przy awarii klient może od razu powiedzieć co nie działa, albo najpierw opowiedzieć że dzwoni trzeci raz, albo zacząć od pytania czy to potrwa długo. Voicebot musi za tym nadążyć.

Integracja techniczna: voicebot przez SIP trunking do centralki, API do systemu monitoringu sieci, API do systemu bilingowego, API Freshdeska do ticketów. Każda integracja to osobny tydzień pracy z testami.

Szczerze, przez pierwsze trzy tygodnie po wdrożeniu bot działał z grubsza poprawnie w jakichś dwóch trzecich przypadków. To brzmi źle, ale to jest normalne. Voicebot uczy się na realnych rozmowach. Pierwszy miesiąc to nadzorowany okres nauki, gdzie ktoś z zespołu przegląda transkrypcje i poprawia błędy.

Czwartek który poszedł nie tak

Trzy tygodnie po wdrożeniu, w czwartek rano, zadzwonił do mnie kierownik wsparcia. "Bot tworzy duplikaty ticketów. Klienci dzwonią drugi raz i dostają nowy ticket zamiast aktualizacji starego."

Problem był prozaiczny. Voicebot przyjmował zgłoszenie i tworzył ticket w Freshdesku. Jeśli klient zadzwonił ponownie z tą samą sprawą, bot nie sprawdzał czy istnieje już otwarty ticket dla tego numeru telefonu. Po prostu tworzył nowy. Efekt: jeden klient z awarią miał cztery otwarte tickety na to samo, a technik nie wiedział który jest aktualny.

Poprawka: dodaliśmy sprawdzenie otwartych ticketów dla numeru dzwoniącego przed utworzeniem nowego zgłoszenia. Jeśli istnieje aktywny ticket na ten sam temat, voicebot informuje klienta o statusie istniejącego zgłoszenia zamiast tworzyć nowe. Zajęło to jeden dzień. Ale przez ten czwartek support ręcznie scalał tickety i dzwonił do klientów z przeprosinami.

To jest dokładnie ten rodzaj błędu którego nie wyłapiesz na etapie testów, bo testujesz na pojedynczych scenariuszach. Wychodzi dopiero przy realnym ruchu, gdy ta sama osoba dzwoni kilka razy. Nigdy nie testowałem voicebota pod kątem "co się stanie gdy ten sam numer zadzwoni cztery razy w ciągu godziny". Teraz to pierwsza rzecz którą sprawdzam.

Co się zmieniło po 3 miesiącach

Po trzech miesiącach od wdrożenia voicebot obsługuje gdzieś 55 do 60 procent wszystkich połączeń przychodzących. Reszta trafia do zespołu, ale z transkrypcją i wstępną klasyfikacją, więc człowiek od razu wie z czym dzwoni klient.

Średni czas oczekiwania spadł z 8 minut w szczycie do poniżej 2 minut. Zespół nie musi już zatrudniać czwartej osoby, chociaż ruch wzrósł o prawie 20 procent przez ostatnie pół roku. Właściciel powiedział mi na podsumowaniu że "wreszcie nie budzi się w poniedziałek z myślą ile osób dziś nie przyjdzie do pracy".

Koszt: wdrożenie zamknęło się w okolicach 62 tysięcy złotych. Miesięczna infrastruktura to niecałe 1 500 zł (serwer, API do syntezy i rozpoznawania mowy, utrzymanie). Jeden etat w supporcie to ponad 85 tysięcy rocznie z ZUSem. Voicebot robi mniej więcej tyle co jedna osoba na pierwszej linii, tylko nie choruje i nie odchodzi.

Nie napiszę że voicebot "zwrócił się w 9 miesięcy", bo to byłoby zbyt czyste. Prawda jest taka, że voicebot zmienił strukturę pracy zespołu i to jest trudniejsze do policzenia niż prosty ROI. Ale właściciel nie szuka czwartej osoby do zespołu. To chyba jest najlepsza miara.