Testowanie bota, zanim trafi do klientów

Większość nieudanych wdrożeń chatbotów nigdy nie została naprawdę przetestowana. Ktoś wpisał w panelu administracyjnym kilkanaście przyjaznych pytań, dostał sensowne odpowiedzi i włączył bota. Dwa tygodnie później kolejka pęka od zdenerwowanych klientów, którzy zapytali o coś nieco z boku i dostali pewną siebie, błędną odpowiedź. Testy przed startem to nie formalność do odhaczenia. To praca, która decyduje o tym, czy wdrożenie się utrzyma.

Zacznij od prawdziwych zgłoszeń, nie od wymyślonych

Otwórz skrzynkę wsparcia. Wyciągnij maile, transkrypcje czatów i notatki z rozmów telefonicznych z ostatnich kilku miesięcy. Zestaw pytań powstaje z tego, co klienci faktycznie napisali, a nie z tego, co zespół myśli, że piszą. W tej różnicy większość botów po cichu się wykłada.

Grupuj wszystko według intencji, nie według sformułowania. Dwadzieścia wariantów tego samego pytania o wysyłkę to jeden przypadek testowy z dwudziestoma wariantami, a traktowanie ich jako dwudziestu osobnych przypadków tylko rozdmuchuje arkusz, nie dodając pokrycia. Zachowaj oryginalną pisownię, slang, urwane zdania i literówki dokładnie w takiej formie, w jakiej przyszły. Jeśli je wygładzisz, dostaniesz elegancki zestaw testowy, który bot zalicza, a życie potem weryfikuje.

Mały zespół zrobi to ręcznie w arkuszu w jedno popołudnie. Większe działy powinny świadomie dobierać próbki według kategorii zgłoszeń, żeby żadna kolejka - zwroty, płatności, sprawy techniczne, pytania przedsprzedażowe - nie została nieprzetestowana tylko dlatego, że akurat w tym miesiącu było w niej cicho. Jest tu praktyczny bonus: zbuduj bazę wiedzy z tego samego archiwum zgłoszeń, a każdy wgrany dokument od razu odpowiada pytaniu, które ktoś naprawdę zadał.

Zestaw pytań: trzy warstwy

Użyteczny zestaw testowy ma trzy warstwy. Pomijanie drugiej i trzeciej to powód, dla którego tyle botów wygląda na gotowe, a wcale nie jest. Warstwa pierwsza to podstawowe intencje, na które bot musi odpowiadać poprawnie za każdym razem, wzięte z najczęstszych zgłoszeń. To pytania, które w ogóle uzasadniają wdrożenie.

Warstwa druga to nietypowe sformułowania: ta sama intencja zadana opryskliwie, ściśnięta do jednego słowa, wpisana w drugim języku albo zakopana trzy akapity w głąb długiej reklamacji. Nikt nie pisze czystych zapytań, kiedy jest zirytowany. Warstwa trzecia zbiera pytania spoza zakresu, których bot powinien grzecznie odmówić, zamiast improwizować dookoła nich.

Zamroź zestaw, zanim zaczniesz testy. Jeśli będziesz zmieniać pytania w trakcie pomiarów, wyniki przestaną być porównywalne między wersjami, a to kosztuje cię jedyny sygnał, który mówi, czy zmiana pomogła. Nowe przypadki trafiają do osobnej partii i dołączasz je później. Przy wdrożeniach wielojęzycznych zleć tłumaczenie zestawu komuś, kto naprawdę obsługuje klientów w tym języku. Pytania testowe przepuszczone przez tłumacza maszynowego testują tłumacza, nie bota.

Boty wykładają się na pytaniach błędnych, ale wiarygodnych

Bełkot jest nieszkodliwy. Każdy bot znośnie radzi sobie z nonsensem, bo nonsens od razu uruchamia wyraźny sygnał niepewności. Groźne jest zupełnie rozsądne pytanie o coś pokrewnego, czego twoja baza wiedzy po prostu nie obejmuje - na tyle bliskie twoim dokumentom, że model sięga po odpowiedź, i na tyle odległe, że ją wymyśla.

Zbuduj pytania oparte na fałszywym założeniu i zobacz, co się stanie. Zapytaj o rabat lojalnościowy, którego nigdy nie było. Zapytaj o warunki gwarancji produktu wycofanego rok temu. Dobry bot prostuje założenie, słaby przytakuje i wręcza klientowi obietnicę, której teraz musisz dotrzymać. Przetestuj też pytania złożone, w których dwie intencje przychodzą w jednym zdaniu, a odpowiedzieć da się tylko na jedną.

Potem przetestuj przypadki, w których poprawną odpowiedzią jest odmowa: porady prawne, twierdzenia medyczne, gwarancje zwrotu pieniędzy, na które nikt nie dał zgody. Bot, który mówi, że nie wie, i kieruje do właściwego kontaktu, zachowuje się dokładnie tak, jak powinien, a twój arkusz oceny musi zapisać to jako zaliczone. Kiedy coś nie przechodzi, zawęź zakres i popraw ton w konfiguracji panelu administracyjnego i uruchom ten sam zestaw jeszcze raz. Przepisywanie pytań, aż zaczną przechodzić, to nie testowanie. To dekoracja.

Kto powinien testować, a kto nie

Konsultanci wsparcia są zdecydowanie najlepszymi testerami. Znają prawdziwe sformułowania, pamiętają niewygodne przypadki i od razu wyłapują, kiedy odpowiedź jest technicznie poprawna, ale i tak skończy się reklamacją. Daj im największą część zestawu.

Osoba, która napisała bazę wiedzy, jest najgorszym testerem. Nie z niedbalstwa - nieświadomie formułuje pytania słownictwem dokumentów, które sama napisała, więc wyszukiwanie działa znakomicie i niczego nie dowodzi. Niech poprawia treści, a nie je ocenia. Dorzuć jedną osobę bez żadnej wiedzy o produkcie jako przeciwwagę; wyłapie żargon, który bot powtarza, nigdy go nie tłumacząc.

Założyciele i menedżerowie idą prosto ścieżką idealną, dostają dobre odpowiedzi i ogłaszają projekt skończonym. Daj im zamiast tego warstwę pytań błędnych, ale wiarygodnych, gdzie ich nos do ryzyka biznesowego naprawdę coś wnosi. Daj wszystkim tę samą czterostopniową skalę - poprawnie, niepełnie, błędnie, powinien był odmówić - żeby wyniki dało się porównywać, zamiast się o nie spierać. I jedna zasada liczy się bardziej niż reszta: testerzy zapisują dokładne pytanie, znak po znaku. Odtworzenie błędu wymaga oryginalnego brzmienia, a streszczenie je niszczy.

Naprawianie tego, co wykryją testy

Większość błędów wraca do bazy wiedzy, a nie do modelu. Brakujący dokument, PDF wciąż z zeszłorocznym cennikiem, dwa pliki, które po cichu sobie przeczą - każde z tego pokona dowolny system. Kiedy dwa źródła się nie zgadzają, odpowiedź staje się rzutem monetą, który zmienia się między sesjami.

Kasuj nieaktualne dokumenty. Nie wgrywaj nowszej wersji obok nich. Trzymanie obu wydaje się bezpieczne i jest najczęstszą przyczyną niespójnych odpowiedzi, jaką spotykam. Druga klasa błędów nie ma nic wspólnego z faktami: odpowiedź jest poprawna, ale ton nie ten. Za sucho, za gadatliwie, za technicznie. To należy do ustawień zakresu i tonu w panelu administracyjnym, a nie do plików źródłowych.

Wdrożenia głosowe wymagają osobnego przebiegu. Rozpoznawanie mowy przekręca nazwy produktów, kody pocztowe i nazwiska, które w tekście czytają się bez problemu, więc zestaw pytań sprawdzony na czacie jest dla voicebota sprawdzony tylko w połowie. Pytania o taką konfigurację pojawiają się na tyle często, że odpowiedzi na częste pytania pokrywają większość z nich. Po każdej zmianie uruchamiaj cały zamrożony zestaw, a nie tylko przypadek, który nie przeszedł. Naprawa jednej intencji regularnie przestawia odpowiedzi na sąsiedniej, a chcesz to zobaczyć od razu.

Miękki start: wpuszczamy część ruchu

Testy wewnętrzne przestają dawać nowe informacje szybciej, niż ludzie się spodziewają. Zespołowi kończy się wyobraźnia. Prawdziwi klienci pytają o rzeczy, których nikt na etacie nigdy by nie wpisał. W tym momencie sensownym ruchem jest ekspozycja, ostrożnie ograniczona.

Skieruj do bota najpierw wycinek ruchu: jeden kanał, jeden język, jedną linię produktów albo jedno okno czasowe. Ruch poza godzinami pracy to najbezpieczniejszy pierwszy wycinek, bo alternatywą dla klienta o 23:00 jest brak odpowiedzi, a nie wolniejsza odpowiedź człowieka. To całkowicie zmienia rachunek ryzyka - porównujesz bota z ciszą, a nie ze swoim najlepszym konsultantem.

Trzymaj drogę do człowieka widoczną i obsadzoną przez cały czas. To organizujesz po swojej stronie, przez istniejące kanały kontaktu, a nie jest to funkcja, którą bot wykonuje sam. Przez pierwsze tygodnie czytaj transkrypcje codziennie, potem co tydzień, i dokładaj każde nowe sformułowanie do zamrożonego zestawu jako nową partię. Poszerzaj wycinek, kiedy minie pełny tydzień bez nowej kategorii błędu. Nie wtedy, kiedy kalendarz mówi, że pora.

Jak naprawdę wygląda gotowy bot

Gotowość mierzy się zachowaniem przy pytaniach, na które bot nie umie odpowiedzieć, a nie wynikiem na tych, na które umie. Każda sensowna konfiguracja obsłuży podstawowe intencje. Po starcie containment rate jako sygnał testowy mówi ci to samo na dużą skalę. O tym, czy wdrożenie przetrwa, czy zostanie wyłączone, decyduje to, jak czysto radzi sobie z granicą swojej wiedzy.

Krótka lista kontrolna przed startem, warta przejścia, zanim wpuścisz cały ruch:

• Podstawowe intencje obsłużone poprawnie na podstawie aktualnych, niesprzecznych dokumentów
• Pytania spoza zakresu odrzucone czysto, ze wskazaniem właściwego kontaktu
• Ton zgodny z tym, jak twoja marka faktycznie mówi do klientów
• Każdy obsługiwany język przetestowany przez osobę, dla której jest ojczysty
• Droga eskalacji do człowieka obsadzona w godzinach, w których bot działa
• Transkrypcje przeglądane przez konkretną osobę, a nie przez zespół w ogóle

Testowanie nie kończy się na starcie. Baza wiedzy starzeje się przy każdej zmianie ceny, zasad i produktu, a zaniedbany bot powoli staje się pewny siebie i nieaktualny. Botino daje pierwszego voicebota za darmo po rejestracji, więc cały ten cykl - kopanie w zgłoszeniach, trzy warstwy pytań, miękki start - możesz przejść, zanim się na cokolwiek zdecydujesz, a o czasie, który to uwalnia, warto poczytać więcej o efektywności biznesowej. O tym, czy wdrożenie działa, czy zostaje porzucone po miesiącu, prawie zawsze decyduje jakość tego przedstartowego zestawu pytań.