W moich projektach ciągle widzę, jak bardzo wzrosły oczekiwania wobec voicebotów. Wiele firm zaczyna z nadzieją, że w kilka tygodni stworzy pełnoprawną usługę opartą na sztucznej inteligencji. Rzeczywistość wygląda inaczej. Voiceboty mogą dziś zrobić naprawdę dużo, ale potrzebują solidnych podstaw, jasnych celów i firm, które na początku są gotowe zainwestować trochę więcej energii.
W moim webinarium (tylko w języku niemieckim) w ramach 16. Tygodnia Obsługi Klienta przedstawiłem dwa projekty, które bardzo dobrze pokazują, co jest możliwe, a na jakie pułapki należy uważać. Oba przypadki użycia pochodzą z sektora publicznego i oba miały ten sam cel: odciążenie centrum obsługi i automatyzację standardowych zapytań. Niemniej jednak projekty okazały się bardzo różne.
Voicebot jako pierwszy punkt kontaktu: co działa dobrze, a co nie
W pierwszym projekcie wyzwaniem była bardzo duża liczba połączeń. Pracownicy byli nieustannie przerywani, jednocześnie obsługując obywateli na miejscu. Celem było zmniejszenie nakładu pracy o co najmniej 50%.
W związku z tym organ zdecydował się przekierowywać wszystkie połączenia publiczne do bota głosowego. Tylko w przypadku, gdy bot nie był w stanie odpowiedzieć na zapytanie, dzwoniący mógł zostawić prośbę o oddzwonienie. Prośby te były wysyłane w formie wiadomości e-mail zawierającej podsumowanie i szczegółową transkrypcję do skrzynki pocztowej pracowników organu, aby mogli się nimi zająć w dogodnym dla nich czasie.
Na początku podejście wydawało się proste. Pomysł polegał na wykorzystaniu istniejących tekstów FAQ ze strony internetowej do stworzenia bota. Zaczęliśmy więc od klasycznego bota NLU (Natural Language Understanding). Klient nie chciał ryzykować żadnych halucynacji i nalegał na ściśle określoną ścieżkę klienta.
Jednak właśnie w tym momencie zdaliśmy sobie sprawę, jak trudny jest to temat. Treści na stronach internetowych nie są tworzone z myślą o botach głosowych. Często rozrastają się one z biegiem czasu, zawierając nieprecyzyjne informacje lub powtarzające się treści. Bot potrzebuje jednak jasnych, jednoznacznych i dobrze zorganizowanych informacji. Dialogi wydawały się sztywne i nie zadowoliłyby dzwoniących.
Przejście na bota LLM (Large Language Model, LLM) było prawdziwym punktem zwrotnym. Entuzjazm był ogromny: ludzkie dialogi, empatia, różne sformułowania. Bot mówił „Och, brzmi wspaniale” lub „Przykro mi to słyszeć”. Bot był w stanie odpowiedzieć na to samo pytanie na różne sposoby i reagował bardziej ludzko, nie wykraczając poza określone wytyczne.
Wymierne wyniki
Wynik był wyraźnie mierzalny. Tylko około 20% pierwotnych połączeń zakończyło się prośbą o oddzwonienie przez pracownika. Większość spraw została sprawnie rozwiązana przez bota. Bardzo miły efekt uboczny: zniknęli powtarzający się rozmówcy, ponieważ bot nie ma sygnału „zajętości”. Pracownicy mają teraz znacznie więcej czasu dla obywateli na miejscu. Była to dokładnie taka ulga, na jaką liczył klient.
Bot rozłącza się z 15% dzwoniących, głównie po udanych rozmowach. Od 30 do 40% dzwoniących rozłącza się samodzielnie. W tym przypadku musieliśmy przejrzeć transkrypcje, aby ocenić, czy jest to dobre, czy złe.
Czego nauczyliśmy się dzięki temu projektowi
Zasoby ludzkie
Można osiągnąć szybkie sukcesy, ale żaden projekt voicebot nie działa bez aktywnego zaangażowania klienta. Obejmuje to utrzymywanie bazy wiedzy, tworzenie słownika, testowanie, kompilowanie słownika czystej wymowy dla funkcji zamiany tekstu na mowę oraz poprawianie treści. Oprócz eksperta merytorycznego powinno być zapewnione wsparcie techniczne, które zajmuje się interfejsami API i posiada wiedzę na temat skryptów w JavaScript lub XML. Wymagane są również zasoby testowe. W przypadku projektu tej wielkości potrzebne są co najmniej dwie dedykowane osoby kontaktowe po stronie klienta, a najlepiej trzy.
Wiedza LLM
Kolejną ważną kwestią jest wbudowana wiedza ogólna modelu LLM. Model zawsze posiada własną wiedzę ogólną. Należy ją aktywnie ograniczać, aby pozostawała w zakresie dostarczonych treści. Działa to dobrze, ale nie w stu procentach. W razie potrzeby należy przeprowadzać testy, poprawki i dostosowania.
Naturalność
Kiedy obywatel zadaje pytanie, bot „myśli” – zamienia mowę na tekst, tekst na LLM, tekst na mowę. Te przerwy muszą być wypełnione. Odgłosy pisania, małe znaki wahania, zmiany głośności. Zmiany hałasu w tle pomagają nadać dialogowi naturalny charakter.
Wpadka
Większość dostawców botów oferuje obecnie również funkcję tzw. „barge-in”, czyli przerywania dialogu. Bot musi akceptować fakt, że może zostać przerwany. Na przykład, jeśli rozmówca otrzymał już potrzebne informacje, nie powinien być zmuszony do wysłuchiwania pozostałej części skryptu bota. Wadą tej funkcji jest to, że hałas w tle, np. na peronie kolejowym, może również zostać zinterpretowany jako przerwanie rozmowy. Problem ten można rozwiązać za pomocą ustawień czułości.
Drugi przykład: Gdy przekierowanie połączeń jest częścią procesu
Drugi projekt również dotyczył często zadawanych pytań, ale wymagania były inne. Bot miał odpowiadać na zapytania i odciążać centrum obsługi – cel również wynosił 50%. Jednak w godzinach pracy połączenia musiały być w razie potrzeby przekazywane do pracowników zaplecza lub centrum kontaktowego. Nie było opcji oddzwaniania. Ponadto istniejący system Avaya musiał zostać zintegrowany w zakresie przekazywania połączeń z bota do pracownika.
Integracja techniczna
Kluczowym aspektem była integracja techniczna. Połączenie przychodzące do centrum obsługi klienta jest przekierowywane do bota głosowego i w razie potrzeby powinno zostać zwrócone do pracownika. Należy podać identyfikator routingu i odzwierciedlić go – poprzez informacje między użytkownikami lub manipulację nagłówkiem SIP. Dzięki temu połączenie pojawi się poprawnie w historii raportów.
Zintegrowaliśmy również usługę Call Data Service firmy Parloa. Podsumowanie połączenia pojawia się w interfejsie użytkownika Avaya, zanim pracownik przyjmie połączenie. Dzięki temu agenci mogą z wyprzedzeniem sprawdzić, czego dotyczy rozmowa.
Efekty
Po raz kolejny mieliśmy do czynienia z tą samą sytuacją na początku: klient chciał zaimportować sekcję FAQ ze strony internetowej. I po raz kolejny nie udało się to. Treść musiała zostać poprawiona ręcznie.
Osiągnięto 50% wskaźnik przekazywania – częściowy sukces. W idealnym przypadku przekazywanie nie byłoby potrzebne, ale pozostałe 50% zostało pomyślnie zautomatyzowane.
Wskaźnik rozłączeń przez bota wyniósł 10% – po przejrzeniu transkrypcji można uznać to za sukces. Wskaźnik rozłączeń przez klientów wyniósł 40% – należy to dokładniej zbadać. Czy to sukces, czy nie? Należy ponownie sprawdzić transkrypcje i przejrzeć rozmowy. Jedną z opcji jest przeprowadzenie ankiety satysfakcji na końcu rozmowy z botem.
Wnioski wyciągnięte z drugiego projektu
Wymagany czas
Projekt trwał 3 miesiące. Wszystko poszło zgodnie z planem. Projektowanie, konfiguracja i testy techniczne po naszej stronie zajęły około 20 dni roboczych.
Zasoby ludzkie
Mieliśmy tu zbyt mało zasobów dotyczących klientów. Spowodowało to dodatkową pracę, która nie była zaplanowana.
Wyrażenie zgody
Ważna kwestia dotycząca obu botów. Obywatel musi wyrazić zgodę na nagrywanie. Bot zawsze nagrywa wszystko – pełne transkrypcje są zawsze dostępne, niezależnie od tego, czy zostaną usunięte po 7 czy 30 dniach.
Należy poprosić o wyrażenie zgody. Obywatele powinni również mieć możliwość powiedzenia: „Nie, nie chcę kontynuować”. Mogą też kontynuować – i, jak widzieliśmy w pierwszym przypadku – poprosić o oddzwonienie i podać tylko minimalne informacje o sobie.
W tym przypadku sensowne może być rozpoczęcie od NLU, tj. podejścia strukturalnego, a następnie kontynuowanie podejścia LLM-Agentic, aby zapewnić prawidłową obsługę opcji opt-in. W przypadku pełnego startu LLM ten krok może zostać nieumyślnie pominięty.
Czego nauczyliśmy się z obu projektów
Voiceboty są obecnie bardzo wydajne. Nie są to jednak produkty typu „plug-and-play”. Aby odnieść sukces, należy poważnie potraktować trzy kwestie.
Po pierwsze: treść. Bot jest tak dobry, jak baza wiedzy, którą mu przekazujesz. Teksty ze stron internetowych prawie nigdy nie mogą być wykorzystane w obecnej postaci. Należy je poprawić i uporządkować.
Po drugie: zasoby. Bez ekspertów po stronie klienta, którzy testują, poprawiają i utrzymują treści, projekt stanie się powolny i trudny.
Po trzecie: zarządzanie oczekiwaniami. Niemal zawsze występuje faza, w której jakość nie jest jeszcze wystarczająca. Jeśli jednak kontynuuje się proces doskonalenia, jakość szybko wzrasta. W obu projektach osiągnęliśmy wysokie wskaźniki sukcesu i zadowolenie dzwoniących.
Wnioski
Voiceboty są prawdziwym ułatwieniem, jeśli są prawidłowo skonfigurowane. Technologia ta jest dojrzała, ale wymaga starannego wdrożenia. Jeśli treści, testy i współpraca są dobrze zarządzane, można osiągnąć punkt, w którym większość zapytań jest zautomatyzowana, a zespoły mają więcej czasu na sprawy, które naprawdę wymagają ludzkiej uwagi.
