Voicebot w biurze obsługi klienta: czego uczy audyt kilkuset rozmów

Pierwszy tydzień po uruchomieniu asystenta wygląda zwykle bardzo dobrze. Rozmowy są krótkie, klienci nie protestują, statystyki rosną. Prawdziwa ocena zaczyna się później, gdy ktoś usiądzie do transkrypcji i przeczyta kilkaset rozmów pod kątem jednego pytania: czy klient uzyskał to, po co dzwonił. Odpowiedź prawie nigdy nie jest w pełni pozytywna, a wnioski powtarzają się między wdrożeniami i branżami.

Dlaczego audyt jest ważniejszy od uruchomienia

Uruchomienie asystenta to zadanie skończone. Jakość rozmów to proces, ponieważ zmienia się oferta, zmieniają się dane w systemach i zmieniają się pytania klientów. Bez regularnego przeglądu transkrypcji drobne odchylenia narastają w ciszy: asystent zaczyna niepoprawnie kwalifikować sprawy, częściej przekazuje rozmowy albo, co gorsza, przestaje je przekazywać wtedy, gdy powinien.

Praktyczny rytm, który się sprawdza, to przegląd próbki rozmów raz w tygodniu w pierwszym miesiącu, a potem raz na miesiąc, plus przegląd doraźny po każdej zmianie w ofercie lub integracji. Próbka nie musi być duża: kilkadziesiąt rozmów wystarcza, by wzorce błędów stały się widoczne.

Cztery wzorce błędów, które wracają najczęściej

1. Asystent improwizuje, gdy narzędzie nic nie zwróciło

Najgroźniejszy z całej listy. Zapytanie do systemu zwraca pustą odpowiedź albo błąd, a model, zamiast to przyznać, formułuje wypowiedź prawdopodobną: podaje przybliżony status, zgaduje termin, wymyśla warunek oferty. Z punktu widzenia klienta brzmi to jak wiarygodna informacja, więc podejmuje na jej podstawie decyzję.

Rozwiązaniem nie jest zaostrzenie instrukcji. Instrukcja jest sugestią i przy nietypowej rozmowie przestaje działać. Poprawka polega na tym, że przy braku danych ścieżka rozmowy zmienia się w kodzie, a nie w intencji modelu: asystent otrzymuje wyłącznie komunikat o niedostępności informacji i jedyne dopuszczalne działanie, czyli przekazanie sprawy dalej.

2. Dane poprawne technicznie, ale nieaktualne

Asystent odczytuje wartość z systemu, więc wszystko wygląda dobrze, tylko system aktualizuje się raz na dobę albo wymaga ręcznego importu. Klient słyszy stan z wczoraj i traktuje go jako bieżący. Ten błąd jest szczególnie kosztowny przy statusach zamówień, saldach i dostępności towaru.

Wnioski są dwa. Po pierwsze, przy każdym źródle danych trzeba znać jego rzeczywistą świeżość, a nie założoną. Po drugie, gdy dane są opóźnione, asystent powinien to komunikować wprost, na przykład wskazując, na kiedy aktualny jest odczyt. To mniej efektowne, ale utrzymuje zaufanie do całego kanału.

3. Przekazanie rozmowy poza godzinami pracy zespołu

Błąd banalny i bardzo częsty. Asystent, zgodnie z instrukcją, proponuje połączenie z konsultantem o dwudziestej drugiej w sobotę. Klient słyszy sygnał, nikt nie odbiera, rozmowa kończy się gorzej niż gdyby asystent od razu przyjął zgłoszenie. Powód jest zawsze ten sam: godziny pracy istnieją w promptcie jako informacja, a nie jako warunek w logice.

Poprawne rozwiązanie polega na tym, że możliwość przełączenia jest sprawdzana programowo na podstawie aktualnego czasu, kalendarza dni wolnych i dostępności kolejki. Poza tym okresem opcja przekazania po prostu nie istnieje, a asystent przyjmuje zgłoszenie i zapowiada kontakt w konkretnym terminie.

4. Potwierdzenie rezerwacji przy niejednoznacznej odpowiedzi systemu

Zapytanie zapisujące kończy się odpowiedzią, której nie da się jednoznacznie zinterpretować: przekroczony limit czasu, kod pośredni, częściowy zapis. Model, dążąc do zamknięcia rozmowy, mówi klientowi „zapisane”. Wizyta nie istnieje w kalendarzu, klient przyjeżdża, zespół nie wie o niczym. Jedna taka rozmowa kosztuje więcej zaufania niż pięćdziesiąt rozmów bezbłędnych je buduje.

Zasada jest prosta: słowo „potwierdzam” może pojawić się tylko po jednoznacznym potwierdzeniu z systemu. Każdy inny wynik prowadzi do zdania o weryfikacji i kontakcie zwrotnym. Ta reguła musi być egzekwowana w kodzie obsługującym wynik zapytania.

Wniosek: twarde ograniczenia należą do kodu

Wszystkie cztery wzorce mają wspólny mianownik. Prompt jest dobrym narzędziem do kształtowania tonu, kolejności pytań i sposobu tłumaczenia rzeczy klientowi. Nie jest narzędziem do egzekwowania reguł, których naruszenie kosztuje pieniądze albo zaufanie. Takie reguły muszą być warunkami w logice aplikacji.

• Dostępność terminów i stany zawsze z zapytania, nigdy z pamięci modelu.
• Potwierdzenie zapisu wyłącznie po jednoznacznej odpowiedzi systemu.
• Możliwość przełączenia rozmowy wyliczana z kalendarza pracy i stanu kolejki.
• Brak danych oznacza jedną dozwoloną ścieżkę: przyznanie tego i przekazanie sprawy.
• Zakres tematów, w których asystent w ogóle nie odpowiada, wymuszony poza promptem.

Jak uczciwie definiować rozwiązaną sprawę

Wskaźnik automatyzacji łatwo podnieść, obniżając standard. Wystarczy uznać za sukces każdą rozmowę, w której klient się nie rozłączył. Taka statystyka ładnie wygląda w raporcie i nie mówi nic o obsłudze.

Definicja, którą warto przyjąć, jest inna: sprawa jest rozwiązana, gdy klient otrzymał to, po co dzwonił, albo trafił do właściwej osoby z kompletnym kontekstem. Poprawne przekazanie do człowieka jest sukcesem, nie porażką asystenta. Porażką jest przekazanie niepotrzebne, przekazanie w próżnię i udzielenie odpowiedzi błędnej.

Ta zmiana definicji zmienia też sposób projektowania. Zespół przestaje optymalizować odsetek rozmów bez człowieka, a zaczyna optymalizować odsetek rozmów zakończonych poprawnie. To dwie różne rzeczy i tylko druga przekłada się na opinie klientów.

Co warto mierzyć

• Odsetek rozmów zakończonych poprawnie, według definicji powyżej, oceniany na próbce transkrypcji.
• Odsetek i przyczyny przekazań do człowieka, z rozbiciem na przekazania uzasadnione i zbędne.
• Liczba rozmów, w których zapytanie do systemu zwróciło błąd lub pustą odpowiedź, oraz zachowanie asystenta w tych rozmowach.
• Odsetek przekazań poza godzinami pracy, docelowo zerowy.
• Rozbieżności między potwierdzeniami w rozmowie a stanem w systemie, weryfikowane wyrywkowo.
• Średni czas rozmowy w rozbiciu na typy spraw, jako sygnał wczesny problemów ze zrozumieniem.
• Powtarzające się pytania, na które asystent nie ma odpowiedzi, jako lista do bazy wiedzy.

Ostatnia pozycja z tej listy jest najbardziej niedoceniana. Zbiór pytań, na które asystent nie potrafi odpowiedzieć, jest najlepszą listą zadań na kolejny miesiąc pracy nad jakością, ponieważ pochodzi bezpośrednio od klientów, a nie z wyobrażeń zespołu o tym, o co klienci pytają.

Sposób, w jaki prowadzimy przeglądy jakości i pracę po uruchomieniu, opisujemy na stronie usług, a wyniki konkretnych wdrożeń w case studies. Jeśli mają Państwo działający asystent i chcą zewnętrznego przeglądu rozmów, można to ustalić przez kontakt.