QA ścieżki klienta (customer journey QA) ocenia wszystko, przez co klient przeszedł, żeby rozwiązać jedną sprawę: każdy kontakt z botem, agentem AI, czatem, telefonem i konsultantem w tej sprawie w ustalonym oknie czasowym. Zamiast pytać, czy każda rozmowa była dobra, pyta, czy ścieżka zakończyła się rozwiązaniem problemu, bez pętli, utraconego kontekstu i zignorowanych próśb o rozmowę z człowiekiem.
W skrócie
- QA rozmów ocenia jeden kontakt. QA ścieżki klienta ocenia całą drogę, jaką klient przeszedł, żeby rozwiązać jedną sprawę, przez boty, agentów AI, kanały i ludzi.
- Większość błędów w obsłudze z AI leży pomiędzy rozmowami: zignorowane „chcę rozmawiać z człowiekiem”, pętla między czatem a telefonem, utracony kontekst, ponowny kontakt, klient, który po cichu rezygnuje.
- Ścieżkę definiuje się jako tego samego klienta z tą samą sprawą w stałym oknie czasowym, domyślnie 7 dni.
- Warto mierzyć ścieżki poprawnie rozwiązane, liczbę kontaktów na ścieżkę, błędy przekazania, utracony kontekst, spełnione prośby o człowieka, ciche porzucenia i czas do rozwiązania.
- Całe ścieżki ocenia się na karcie oceny ścieżki, próbkuje według sygnałów ryzyka, a każda nieudana ścieżka dostaje jednego właściciela, który usuwa przyczynę.
Czym jest QA ścieżki klienta?
QA ścieżki klienta to kontrola jakości, w której jednostką oceny jest sprawa klienta, a nie pojedyncza rozmowa. Oceniający albo automatyczna kontrola śledzi jednego klienta i jedną sprawę przez każdy punkt styku (bot, agent AI, czat, e-mail, telefon, konsultant) w ustalonym oknie i ocenia, czy ścieżka rozwiązała problem poprawnie i bez zbędnego wysiłku.
Tradycyjna kontrola jakości czyta jedno zgłoszenie i ocenia konsultanta, który je obsłużył. Gdy na pierwszej linii stoją agenci AI, jedna sprawa często zamienia się w trzy albo cztery kontakty: rozmowę z botem, eskalację na czat, telefon i e-mail z dopytaniem. Każdy z tych kontaktów może przejść własną kartę oceny, a klient i tak przez trzy dni nie posuwa się ani o krok.
Hasło „customer journey AI agents” często oznacza narzędzia marketingowe, takie jak Journey Creation Agent Microsoftu, który buduje ścieżki e-mail, SMS i push na podstawie celu opisanego zwykłym językiem. Ten poradnik dotyczy obsługi klienta: sprawdzania ścieżek, którymi klienci faktycznie przechodzą, kiedy potrzebują pomocy.
Dlaczego ocena pojedynczych rozmów pomija miejsca, w których zawodzi obsługa z AI?
Ocena pojedynczych rozmów pomija błędy obsługi z AI, bo te błędy powstają pomiędzy rozmowami. Bot, który ignoruje „chcę rozmawiać z człowiekiem”, czat, który odsyła klienta na infolinię, przekazanie, które gubi numer zamówienia, albo klient, który po cichu rezygnuje: w każdym z tych przypadków pojedyncza rozmowa wygląda poprawnie. Szkodę pokazuje dopiero cała ścieżka.
Klienci tego oczekują. W badaniu Gartnera przeprowadzonym na 5728 klientach (grudzień 2023) 64% odpowiedziało, że wolałoby, żeby firmy nie używały AI w obsłudze klienta, a ich największą obawą było to, że trudniej będzie dotrzeć do człowieka. Gartner radzi, żeby chatbot, który nie potrafi rozwiązać problemu, przekazywał rozmowę na czat z konsultantem, który „picks up where the chatbot left off” (podejmuje sprawę tam, gdzie skończył chatbot). To wymóg dotyczący ścieżki.
Amerykańskie Consumer Financial Protection Bureau w raporcie o chatbotach w finansach konsumenckich nazywa ten sam wzorzec „doom loops” (pętlami bez wyjścia), które często powstają, gdy sprawa wykracza poza ograniczone możliwości chatbota.
Większość szkód powoduje pięć wzorców błędów:
| Wzorzec błędu | Czego doświadcza klient | Dlaczego ocena rozmowy go nie widzi | Sygnał na poziomie ścieżki |
|---|---|---|---|
| Zignorowane „chcę rozmawiać z człowiekiem” | Prosi o człowieka, dostaje kolejne odpowiedzi bota albo ślepą uliczkę | Bot był uprzejmy i trzymał się tematu, więc rozmowa przechodzi ocenę | Wyraźna prośba o człowieka bez żadnego kontaktu z człowiekiem na ścieżce |
| Pętla między kanałami | Czat każe zadzwonić, telefon każe napisać na czacie, nikt nie rozwiązuje sprawy | Każdy kontakt „poprawnie” gdzieś klienta przekierował | Ta sama sprawa, 2 lub więcej zmian kanału, brak rozwiązania |
| Utracony kontekst przy przekazaniu | Powtarza numer zamówienia, problem i kroki, które już wypróbował | Konsultant był miły i zadawał właściwe pytania | Klient podaje tę samą informację dwa razy na jednej ścieżce |
| Ponowny kontakt | Sprawa była „rozwiązana”, a po kilku dniach wraca | Pierwsza rozmowa skończyła się pewną siebie odpowiedzią | Nowy kontakt w tej samej sprawie w oknie czasowym |
| Ciche porzucenie | Rezygnuje w połowie ścieżki, może anuluje albo odchodzi | Brak skargi, brak ankiety, zgłoszenie zamyka się jako rozwiązane | Ścieżka kończy się bez rozwiązania i bez kolejnego kontaktu |
Klienci na publicznych forach wsparcia opisują pętlę między kanałami jednym zdaniem: czat odsyła ich na infolinię, a infolinia odsyła z powrotem albo się rozłącza. Ani transkrypcja czatu, ani rozmowa telefoniczna oceniona osobno nie zostałyby ocenione negatywnie. Błędy w pojedynczej rozmowie AI, które dashboardy liczą jako sukcesy, opisuje nasz poradnik o cichych błędach agentów AI.
Jak zdefiniować ścieżkę klienta na potrzeby QA?
Ścieżkę klienta definiuje się jako każdy kontakt tego samego klienta w tej samej sprawie w stałym oknie czasowym, na przykład 7 dni od pierwszego kontaktu. Zanim zaczną Państwo cokolwiek oceniać, potrzebne są trzy spisane zasady: jak rozpoznać tego samego klienta, jak rozpoznać tę samą sprawę i kiedy ścieżka uznawana jest za zakończoną.
Ten sam klient. Warto użyć najsilniejszego identyfikatora, jaki Państwo mają: ID klienta lub numeru konta, potem zweryfikowanego e-maila, potem numeru telefonu. Anonimowe czaty lepiej liczyć osobno, niż zgadywać.
Ta sama sprawa. Dopasowanie opiera się na tagu intencji, numerze zamówienia lub sprawy albo powiązanym zgłoszeniu. Gdy tagi są niewiarygodne, oceniający powinien najpierw potwierdzić dopasowania na próbce.
Okno czasowe. Dobiera się je według typu sprawy, a potem utrzymuje bez zmian:
| Typ sprawy | Proponowane okno | Dlaczego |
|---|---|---|
| Proste pytania o obsługę lub konto | 3 dni | Jeśli sprawa wraca później, to zwykle jest to nowe pytanie |
| Zamówienia, dostawy, zwroty | 7 dni | Obejmuje czas oczekiwania na dostawę albo na pojawienie się zwrotu środków |
| Rozliczenia, zwroty środków, reklamacje płatności | 14 dni | Błędna odpowiedź wychodzi na jaw przy kolejnym wyciągu lub płatności |
| Roszczenia, rezygnacje, sprawy regulowane | 30 dni | Długie procesy z kilkoma wymaganymi krokami |
Te okna to nasze zasady wyjściowe, a nie standard branżowy. Warto rozpisać na wykresie liczbę dni między pierwszym a drugim kontaktem w tej samej sprawie i ustawić okno tam, gdzie dotarła już większość rzeczywistych ponownych kontaktów.
Jak kończy się ścieżka. Rozwiązana (faktyczny problem został rozwiązany i w oknie nic już nie nastąpiło), porzucona (klient przestał się kontaktować bez rozwiązania) albo otwarta (do oceny później). First contact resolution korzysta z tego samego okna ponownego kontaktu, ale pyta tylko o pierwszy kontakt; QA ścieżki klienta ocenia całą drogę.
Które wskaźniki na poziomie ścieżki warto mierzyć?
Warto mierzyć siedem wskaźników ścieżki: odsetek ścieżek rozwiązanych poprawnie, liczbę kontaktów na ścieżkę, odsetek błędów przekazania, odsetek utraconego kontekstu, spełnione prośby o człowieka, odsetek cichych porzuceń i czas rozwiązania ścieżki. Razem pokazują, czy sprawy klientów są rozwiązywane, ile wysiłku ich to kosztuje i który styk psuje się najczęściej. Raportuje się je według typu sprawy i kanału wejścia.
| Wskaźnik | Jak go obliczyć | Zasada wyjściowa (nasza, do dopasowania do Państwa punktu odniesienia) |
|---|---|---|
| Ścieżki rozwiązane poprawnie | Ścieżki, w których faktyczny problem rozwiązano poprawnie / zamknięte ścieżki | Zbadać każdy typ sprawy poniżej 85% |
| Kontakty na ścieżkę | Wszystkie kontakty we wszystkich kanałach / ścieżki | Zbadać każdy typ sprawy powyżej 1,5 |
| Odsetek błędów przekazania | Przekazania, które zgubiły kontekst, nastąpiły za późno lub odesłały klienta z powrotem / ocenione przekazania | Cel: poniżej 5% |
| Odsetek utraconego kontekstu | Ścieżki z wieloma kontaktami, w których klient powtórzył informację / ścieżki z wieloma kontaktami | Zbadać powyżej 5% |
| Spełnione prośby o człowieka | Wyraźne prośby o człowieka, po których nastąpił kontakt z człowiekiem / wszystkie takie prośby | Cel: 95% lub więcej |
| Odsetek cichych porzuceń | Ścieżki zakończone bez rozwiązania i bez skargi / zamknięte ścieżki | Co tydzień przejrzeć próbkę, niezależnie od poziomu |
| Czas rozwiązania ścieżki | Od pierwszego kontaktu do rozwiązania, mediana i 90. percentyl | Obserwować 90. percentyl |
Wysoki containment rate może ukrywać złą ścieżkę: klient, który opuszcza bota i dzwoni na infolinię, nadal liczy się jako „zatrzymany” przez bota. Liczba kontaktów na ścieżkę to wychwytuje. Warto też odróżniać „rozwiązane” od „rozwiązane poprawnie”: pewna siebie, ale błędna odpowiedź wygląda na rozwiązanie, dopóki nie przyjdzie ponowny kontakt. Jak to sprawdzić, pokazuje nasz audyt wskaźnika rozwiązań agentów AI.
Karta oceny ścieżki klienta (do skopiowania)
Karta oceny ścieżki klienta to krótki zestaw kryteriów, które mają sens tylko w odniesieniu do całej ścieżki. Każde kryterium ma jasny warunek niezaliczenia i wskazuje dane, których potrzebuje oceniający. Każdą rozmowę ocenia się jak zwykle na standardowej karcie oceny, a ścieżkę dodatkowo według tych kryteriów, tak żeby jedno nigdy nie zastępowało drugiego.
| # | Kryterium ścieżki | Co oznacza niezaliczenie | Potrzebne dane |
|---|---|---|---|
| 1 | Faktyczny problem został na końcu rozwiązany poprawnie | Problem nierozwiązany, rozwiązany błędnie albo „rozwiązany” i z powrotem w oknie czasowym | Wszystkie kontakty w oknie, wynik końcowy, obowiązująca zasada lub artykuł bazy wiedzy |
| 2 | Prośby o człowieka zostały spełnione (krytyczne) | Klient poprosił o człowieka i go nie dostał albo dostał dopiero po 2 lub więcej prośbach | Transkrypcje bota i agenta AI, log eskalacji |
| 3 | Brak pętli między botami, kanałami lub zespołami (krytyczne) | Klient został odesłany do kanału lub osoby, z którymi w tej sprawie już się kontaktował | Kanał i obsługujący przy każdym kontakcie, log routingu |
| 4 | Kontekst przeszedł przez każde przekazanie | Klient powtórzył identyfikator, problem albo kroki, które już wypróbował | Transkrypcje po obu stronach każdego przekazania, podsumowanie przekazania, jeśli istnieje |
| 5 | Eskalacja nastąpiła przy właściwym wyzwalaczu | Eskalacja za późno (po kilku nieudanych odpowiedziach) albo odbicie do człowieka bez podania powodu | Zasady eskalacji, transkrypcja w momencie przekazania |
| 6 | Spójne odpowiedzi we wszystkich kanałach i u wszystkich obsługujących | Dwa kontakty dały klientowi różne odpowiedzi w sprawie tej samej zasady | Wszystkie udzielone odpowiedzi, obowiązująca zasada |
| 7 | Obietnice zostały dotrzymane | Oddzwonienie, zwrot środków lub dopytanie obiecane w jednym kontakcie nie nastąpiło | Obietnice w transkrypcjach, system zamówień lub spraw |
| 8 | Wysiłek był proporcjonalny | Więcej kontaktów lub dni, niż wymaga dany typ sprawy (powyżej Państwa zasady dla kontaktów na ścieżkę lub czasu) | Liczba kontaktów, znaczniki czasu |
| 9 | Zakończenie było jednoznaczne | Ścieżka zakończyła się ciszą przy nierozwiązanej sprawie (ciche porzucenie) | Ostatni kontakt, wynik, ewentualna rezygnacja lub odejście klienta |
Zasada oceny. Ścieżka nie przechodzi, jeśli nie zalicza kryterium 1, 2 lub 3 (krytycznych). W pozostałych przypadkach liczy się resztę niezaliczonych kryteriów: 0 oznacza zaliczenie, 1 zaliczenie z ustaleniem, 2 lub więcej niezaliczenie. Przy każdym niezaliczeniu zapisuje się jeden segment przyczyny źródłowej: bot, konkretny agent AI, zasada routingu lub przekazania, kanał, konsultant albo treść zasad lub bazy wiedzy. To przypisanie zamienia ocenę ścieżki w konkretną poprawkę.
Kryterium 4 to ta sama kontrola ciągłości, którą szczegółowo, styk po styku, opisuje nasz poradnik o ocenie przekazania rozmowy z bota do konsultanta. Dla ścieżek, w których kilku agentów AI przekazuje sobie sprawę, wzorce routingu stojące za kryteriami 3 i 5 opisuje artykuł o orkiestracji agentów AI.
Jak próbkować i oceniać całe ścieżki?
Ścieżki próbkuje się w dwóch warstwach: ocenia się każdą ścieżkę, która uruchamia sygnał ryzyka (zignorowana prośba o człowieka, 3 lub więcej kontaktów, 2 lub więcej kanałów, pętla albo porzucenie), a potem dodaje losową próbkę zwykłych ścieżek, żeby zmierzyć rzeczywisty odsetek błędów. Każdą ścieżkę przegląda się chronologicznie, na jednej osi czasu, z wszystkimi kontaktami obok siebie.
Warstwa 1: ścieżki wskazane przez sygnały ryzyka. Tu skupiają się błędy, więc warto przeczytać wszystkie albo stałą liczbę na wyzwalacz tygodniowo:
- Wyraźna prośba o człowieka („konsultant”, „człowiek”, „chcę rozmawiać z kimś”) w transkrypcji bota lub agenta AI.
- 3 lub więcej kontaktów albo 2 lub więcej zmian kanału w tej samej sprawie.
- Ponowny kontakt po kontakcie oznaczonym jako rozwiązany.
- Ścieżka, która kończy się bez rozwiązania i bez kolejnego kontaktu.
Warstwa 2: losowa próbka. Wyzwalacze pokazują, gdzie szukać, ale nie to, jak często coś idzie źle. Żeby raportować odsetek błędów, którego da się bronić, dodaje się losową próbkę zamkniętych ścieżek; 150 do 400 miesięcznie daje użyteczny margines błędu dla jednego typu sprawy. Dlaczego mniejsze próbki wprowadzają w błąd, wyjaśnia nasz artykuł o statystyce próbkowania w QA (po angielsku).
Jak ocenić jedną ścieżkę. Najpierw odtwarza się oś czasu: każdy kontakt w kolejności dat, z kanałem i obsługującym (bot, agent AI, człowiek, menu IVR). Pierwszy i ostatni kontakt czyta się przed środkowymi; różnica między tym, o co klient prosił, a tym, z czym skończył, to werdykt. Potem przechodzi się przez każdy styk. Rozmowy telefoniczne potrzebują transkrypcji lub podsumowania, żeby znaleźć się na tej samej osi czasu; wiele contact center już ocenia próbkę rozmów telefonicznych, a ocena ścieżki umieszcza je obok kontaktów na czacie i z botem.
Szablon oceny ścieżki
Można go skopiować do arkusza lub formularza oceny. Jeden blok na ścieżkę.
| Pole | Co wpisać |
|---|---|
| ID ścieżki | Własne ID albo numer pierwszego zgłoszenia |
| Klient i sprawa | Identyfikator klienta, typ sprawy, numer zamówienia lub sprawy |
| Okno czasowe | Data pierwszego kontaktu, długość okna, stan końcowy (rozwiązana, porzucona, otwarta) |
| Oś czasu | Jeden wiersz na kontakt: data i godzina, kanał, obsługujący (bot, konkretny agent AI, człowiek, menu IVR), co się stało w jednym zdaniu, czy kontekst został przekazany (tak lub nie), wynik |
| Sygnały ryzyka | Które wyzwalacze z warstwy 1 się uruchomiły, jeśli jakieś |
| Karta oceny ścieżki | Zaliczone lub niezaliczone kryteria 1 do 9, z numerem kontaktu jako dowodem |
| Werdykt | Zaliczona, zaliczona z ustaleniem, niezaliczona |
| Segment przyczyny źródłowej | Bot, agent AI (nazwa), zasada routingu lub przekazania, kanał, konsultant, zasady lub baza wiedzy |
| Właściciel i poprawka | Kto odpowiada za ten segment, uzgodniona poprawka, data wdrożenia |
| Ponowna kontrola | Data, kiedy ponownie oceni się ten sam typ ścieżki |
Przykład z obliczeniami (ilustracja, liczby wymyślone, żeby pokazać rachunek)
Zespół obsługi klienta obsługuje 50 000 kontaktów miesięcznie przez chatbota, agenta AI na czacie i w e-mailu, infolinię i konsultantów. Po połączeniu w ścieżki z 7-dniowym oknem te kontakty tworzą 38 000 ścieżek:
- 31 800 ścieżek (84%) wymaga jednego kontaktu.
- 6200 ścieżek wymaga dwóch lub więcej, łącznie 18 200 kontaktów (po 2,94).
- Kontakty na ścieżkę ogółem: 50 000 / 38 000 = 1,32.
QA rozmów wygląda dobrze: 91% próbkowanych rozmów przechodzi ocenę. Potem lider QA przegląda losową próbkę 150 ścieżek z wieloma kontaktami. 48 nie przechodzi (32%):
| Przyczyna źródłowa | Nieudane ścieżki | Udział w niezaliczeniach |
|---|---|---|
| Utracony kontekst przy przekazaniu z bota do konsultanta | 17 | 35% |
| Prośba o człowieka zignorowana lub opóźniona | 12 | 25% |
| Pętla między czatem a telefonem | 9 | 19% |
| Błędne rozwiązanie, klient wrócił | 6 | 13% |
| Różne odpowiedzi w sprawie zasady na czacie i przez telefon | 4 | 8% |
| Razem | 48 | 100% |
W tych 48 nieudanych ścieżkach mieści się 141 rozmów, a 118 z nich (84%) przeszło kartę oceny rozmowy. Ścieżki zawiodły, choć większość rozmów w nich przeszła ocenę.
W skali całości 32% z 6200 to około 1980 nieudanych ścieżek miesięcznie. Margines błędu przy 95% ufności wynosi około plus minus 7,5 punktu procentowego (1,96 × √(0,32 × 0,68 / 150) = 0,075), więc rzeczywista liczba leży mniej więcej między 1520 a 2450. Każdy z tych krańców jest wart naprawy. A 29 z 48 niezaliczeń (60%) pochodzi z dwóch styków, danych przekazywanych przy przekazaniu i zasady dotyczącej próśb o człowieka, więc tam trafiają pierwsze poprawki.
Proszę zobaczyć to na własnych rozmowach. Kaizo ocenia 100% Państwa rozmów z klientami, prowadzonych przez konsultantów i agentów AI, według Państwa własnej karty oceny, a każdy wynik łączy z dowodem w rozmowie. Umów demo.
Kto powinien odpowiadać za jakość ścieżki klienta?
Za jakość ścieżki od początku do końca powinna odpowiadać jedna osoba, zwykle Head of Support albo kierownik Support Operations, bo żaden właściciel kanału czy agenta nie widzi całej drogi. Ten właściciel odpowiada za wskaźniki ścieżki i cotygodniowy przegląd. Każda nieudana ścieżka trafia potem do właściciela segmentu, który ją spowodował.
| Rola | Odpowiada za | Działa w sprawie |
|---|---|---|
| Właściciel ścieżki (Head of Support lub Support Ops) | Wskaźniki ścieżki, kartę oceny ścieżki, cotygodniowy przegląd | Priorytety między zespołami; eskaluje, gdy poprawka utknie |
| Właściciel agenta AI (dla każdego bota lub agenta AI) | Instrukcje agenta, wiedzę i wyzwalacze eskalacji | Niezaliczenia przypisane temu agentowi: błędne odpowiedzi, zignorowane prośby o człowieka |
| Właściciel routingu i przekazań | Zasady routingu, dane przekazywane przy przekazaniu, transfer między kanałami | Pętle, utracony kontekst, spóźniona eskalacja |
| Liderzy kanałów (czat, e-mail, telefon) | Proces i obsadę każdego kanału | Pętle między kanałami, nieudane oddzwonienia, niespójne odpowiedzi |
| Lider QA | Próbkowanie, kalibrację oceniających, szablon oceny | Wiarygodne oceny ścieżek; nowe wzorce błędów |
| Właściciel wiedzy i zasad | Treści, na podstawie których odpowiadają ludzie i agenci AI | Niespójne odpowiedzi w różnych kanałach |
Dwie zasady chronią przed tym, żeby spotkanie nie zamieniło się w szukanie winnych. Każda nieudana ścieżka dostaje dokładnie jeden segment przyczyny źródłowej; resztę zapisuje się jako ustalenia drugorzędne. A poprawka zależy od tego, kto zawiódł: człowiek dostaje coaching, agent AI zmianę instrukcji, wiedzy lub wyzwalaczy. Więcej w artykule coaching ludzi a poprawianie agentów AI.
Jak naprawić błędy, które znajduje QA ścieżki klienta?
Błędy ścieżki naprawia się na styku, który je spowodował, a nie w rozmowie, w której wyszły na jaw. Większość poprawek to zmiany zasad: wyzwalacz eskalacji, dane przekazywane przy przekazaniu, zasada mówiąca, kiedy prośba o człowieka jest zawsze spełniana, albo jedna wspólna odpowiedź na daną zasadę we wszystkich kanałach. Potem ponownie ocenia się ten sam typ ścieżki, żeby potwierdzić, że poprawka zadziałała.
| Znaleziony błąd | Typowa poprawka | Gdzie przeczytać więcej |
|---|---|---|
| Zignorowane „chcę rozmawiać z człowiekiem” | Twarda zasada: wyraźna prośba albo druga nieudana odpowiedź oznacza przekazanie z podsumowaniem | Zabezpieczenia agentów AI |
| Pętla między kanałami | Usunąć odpowiedzi „proszę zadzwonić” lub „proszę napisać na czacie” przy sprawach, których drugi kanał też nie rozwiąże; zamiast tego zaproponować oddzwonienie lub zgłoszenie | Dlaczego rozmowy z AI zawodzą |
| Utracony kontekst przy przekazaniu | Stały zestaw danych przy przekazaniu: ID klienta, sprawa, wypróbowane kroki, czego klient chce | Ocena przekazania rozmowy z bota do konsultanta |
| Niespójne odpowiedzi | Jedno wersjonowane źródło zasad, z którego odpowiadają zarówno ludzie, jak i agenci AI | Polityki dla agentów AI |
| Błędne rozwiązanie, ponowny kontakt | Zawęzić to, co agent AI może rozwiązać sam; audytować jego rozwiązania | Poziomy autonomii agentów AI |
| Ciche porzucenie | Co tydzień przeglądać porzucone ścieżki; dodać kontakt zwrotny przy nierozwiązanych sprawach wysokiego ryzyka | Monitorowanie agentów AI |
Każdą zmianę warto przetestować, zanim dotrze do klientów, a potem zmierzyć na produkcji. Nasz poradnik o ewaluacji agentów AI opisuje oba etapy: zestawy testowe przed wdrożeniem i ocenę prawdziwych rozmów po nim.
Kiedy QA ścieżki klienta nie jest dla Państwa?
QA ścieżki klienta nie jest warte wysiłku wdrożenia, gdy większość spraw rozwiązuje się w jednym kontakcie, a na pierwszej linii nie ma bota ani agenta AI. Jeśli liczba kontaktów na ścieżkę wynosi około 1,1, klienci rzadko zmieniają kanał, a kontaktów jest kilkaset tygodniowo, QA rozmów plus prosty wskaźnik rozwiązania przy pierwszym kontakcie pokazują już to, czego Państwo potrzebują.
Jest też za wcześnie, gdy nie da się powiązać kontaktów z klientem: jeśli większość czatów jest anonimowa, a rozmowy telefoniczne nie mają identyfikatora klienta, najpierw trzeba to naprawić. W międzyczasie warto czytać każdą transkrypcję z wyraźną prośbą o człowieka, co nie wymaga łączenia kontaktów. A QA ścieżki klienta nigdy nie zastępuje QA rozmów: jedno pokazuje, gdzie droga się przerwała, drugie, co poszło nie tak w kontakcie.
Jak zacząć w tym tygodniu
QA ścieżki klienta można zacząć w tym tygodniu z arkuszem i jednym typem sprawy. Celem pierwszego tygodnia nie jest dashboard. Chodzi o znalezienie jednego styku, który psuje najwięcej ścieżek, tak żeby pierwsza poprawka zwróciła włożony wysiłek.
- Wybrać jeden typ sprawy o dużym wolumenie, w którym pierwszy kontakt przejmuje bot lub agent AI, na przykład status zamówienia albo zwroty.
- Spisać trzy zasady: który identyfikator, który tag sprawy lub numer sprawy, jakie okno czasowe.
- Wybrać 30 ścieżek: 20, które uruchamiają sygnał ryzyka, i 10 losowych.
- Ocenić je na karcie oceny ścieżki i w szablonie, z jednym segmentem przyczyny źródłowej na każde niezaliczenie.
- Wskazać właściciela najgorszego styku i uzgodnić jedną poprawkę z datą.
- Powtórzyć w kolejnym tygodniu na tym samym typie sprawy, żeby sprawdzić, czy poprawka zadziałała.
Gdy ręczna ocena potwierdzi wzorzec, warto zautomatyzować to, co się skaluje. Kontrola jakości agentów AI w Kaizo ocenia rozmowy agentów AI i konsultantów na tej samej karcie oceny, łącznie z tym, czy agent eskalował przy właściwym wyzwalaczu i przekazał kontekst, a AutoPilot ocenia każdą rozmowę w chwili jej rozwiązania w Zendesk lub Salesforce. Łączenie tych rozmów w ścieżki opiera się na danych z Państwa helpdesku: powiązanych zgłoszeniach, ID klientów i tagach spraw. Szerszy obraz daje nasz poradnik o agentowej obsłudze klienta.
Najczęściej zadawane pytania
Jaka liczba kontaktów na ścieżkę jest dobra?
Nie ma uniwersalnego punktu odniesienia, bo zależy to od typu sprawy. Warto używać własnego punktu odniesienia dla każdego typu sprawy i badać wszystko, co rośnie. Jako zasada wyjściowa: proste pytania powinny być blisko 1,0, a wszystko powyżej 1,5 zasługuje na przyjrzenie się stojącym za tym ścieżkom.
Czy QA ścieżki klienta to to samo co mapowanie ścieżki klienta?
Nie. Mapowanie ścieżki klienta (customer journey mapping) projektuje drogę, którą klienci mają przechodzić, często na potrzeby marketingu lub projektowania usług. QA ścieżki klienta sprawdza drogi, którymi klienci faktycznie przeszli, kontakt po kontakcie, i ocenia, czy każda z nich rozwiązała problem bez pętli, utraconego kontekstu i zignorowanych próśb o człowieka.
Czy można oceniać razem ścieżki telefoniczne i czatowe?
Tak, jeśli każda rozmowa telefoniczna ma transkrypcję lub pisemne podsumowanie w tym samym miejscu co kontakty na czacie i w e-mailu. Ocena ścieżki umieszcza wtedy rozmowę telefoniczną na tej samej osi czasu co kontakty z botem i na czacie i stosuje te same kryteria ścieżki. Bez transkrypcji lub podsumowania oceniający może ocenić rozmowę tylko po jej wyniku.
Czy QA ścieżki klienta to to samo co monitorowanie agentów AI?
Nie. Monitorowanie śledzi bieżące sygnały jednego agenta AI, takie jak odsetek eskalacji, błędy i dryf, i alarmuje, gdy się zmieniają. QA ścieżki klienta ocenia zakończone ścieżki przez wszystkie boty, agentów, kanały i ludzi i sprawdza, czy problem klienta został rozwiązany. Monitorowanie mówi, że coś się zmieniło; QA ścieżki mówi, ile to kosztowało klienta.
Jak wykryć ciche porzucenie?
Warto szukać ścieżek, które zakończyły się bez rozwiązania i bez kolejnego kontaktu: rozmowy z botem przerwanej w połowie, eskalacji, na którą klient nigdy nie odpowiedział, oddzwonienia, które nigdy nie doszło do skutku. Część tych klientów rozwiązała sprawę gdzie indziej, część zrezygnowała. Warto co tydzień przeglądać próbkę i, jeśli to możliwe, sprawdzać rezygnacje lub odejścia klientów w kolejnych tygodniach.
