Kiedy bot powinien powiedzieć „nie wiem”

Klient przesyła ci zrzut ekranu. Widnieje na nim twój chatbot, który obiecuje termin dostawy nieuzgodniony z magazynem, podaje rabat, którego nikt nie zatwierdził, albo tłumaczy zasadę zwrotów nieistniejącą w żadnym regulaminie. Przekopujesz bazę wiedzy, FAQ, stare PDF-y. Nic. Odpowiedź wzięła się znikąd, a ty musisz teraz zdecydować, czy ją honorować, czy powiedzieć klientowi, że twój własny system wprowadził go w błąd.

Ten moment jest całą tezą tego artykułu. Przyznana luka kosztuje cię jedną dodatkową wiadomość. Pewna siebie błędna odpowiedź kosztuje zwrot pieniędzy, eskalację i kawałek zaufania, którego nie odkupisz tanio. A różnica między jednym a drugim nie leży w jakości modelu. Leży w projekcie fallbacku: w tym, że z góry ustalasz, co bot robi, gdy nie ma nic konkretnego do powiedzenia.

Pewna siebie błędna odpowiedź kosztuje więcej niż przyznana luka

Błędne odpowiedzi nigdy nie zostają tam, gdzie powstały. Generują drugie zgłoszenie, a to zgłoszenie trafia do konsultanta, którego pierwszym zadaniem jest zaprzeczyć botowi własnej firmy. Nikt nie lubi pisać „przepraszamy, nasz asystent się pomylił”. A klienci rzadko czytają to jako pojedynczą usterkę. Czytają to jako sygnał, jak starannie działa reszta twojej firmy.

Niektóre kategorie są kosztowne z natury. Terminy dostaw. Ceny i rabaty. Warunki gwarancji, zwroty, wszystko powiązane z konkretnym kontem, wszystko o ciężarze prawnym. W tych obszarach wymyślona odpowiedź nie tylko wprowadza w błąd - może stworzyć oczekiwanie, którego trudno ci odmówić z powodów handlowych albo prawnych. Cała reszta (godziny otwarcia, opisy produktów, sposób działania usługi) niesie znacznie mniejsze ryzyko, jeśli bot będzie lekko nieprecyzyjny.

Klienci wybaczają botowi, że czegoś nie obsługuje. Nie wybaczają, gdy pewnym tonem powie im coś nieprawdziwego. Widziałem małe zespoły tracące całe popołudnia na sprzątanie, którego nikt nie wliczył w budżet. Większe firmy odczuwają to inaczej: ta sama błędna odpowiedź rozchodzi się po czacie, telefonie i mailu przez tygodnie, zanim ktokolwiek połączy zgłoszenia. Tak czy inaczej, decyzja, która ma znaczenie, zapada przed startem, a nie w trakcie rozmowy. To, ile w ogóle bierzesz na siebie tego ryzyka, zależy od architektury, od której zaczynasz, bo porównanie botów regułowych i AI pokazuje, że zawodzą one w zupełnie różny sposób.

Tam, gdzie kończy się baza wiedzy, bot powinien się zatrzymać

Bot oparty na twoich wgranych dokumentach, poradnikach i FAQ może być tylko tak kompletny jak te pliki. To uczciwe ograniczenie integracji z bazą wiedzy i nazwałbym to raczej zaletą niż wadą: luka w źródle powinna ujawnić się jako luka w odpowiedzi, a nie zostać zamaskowana wiarygodnie brzmiącym wypełniaczem.

Przed startem spisz listę tematów zakazanych - takich, których bot nigdy nie ma podejmować, nawet jeśli wygląda, że znalazł coś pasującego. Potem świadomie ustaw zakres i ton w panelu administracyjnym, zamiast zostawiać asystentowi decyzję, że każde przychodzące pytanie to jego sprawa. Dostosowanie zakresu bota w konfiguracji idzie dużo szybciej niż naprawianie tego później, transkrypcja po transkrypcji.

Martwe pola powtarzają się w różnych firmach. Nieaktualne PDF-y, w których nadal figuruje zeszłoroczny przewoźnik. Dokumenty wewnętrzne pisane dla pracowników, pełne skrótów, które klient źle zrozumie. I zasady istniejące wyłącznie w głowie osoby, która od początku zajmuje się zwrotami i nigdy nic z tego nie spisała.

Coś do zrobienia w tym tygodniu: wypisz dwadzieścia najczęstszych tematów pytań, zaznacz, które mają za sobą realny plik źródłowy, i traktuj wszystko niezaznaczone jako obszar do odmowy, dopóki ktoś nie napisze dokumentu.

Jak sformułować odmowę, która nie irytuje ludzi

Jedno zdanie o ograniczeniu, jedno zdanie o następnym kroku. To cały przepis. Długie przeprosiny czyta się jako wykręt, a każde dodatkowe zdanie sprawia, że bot brzmi, jakby grał na zwłokę. Dwa zdania wystarczą, żeby było jasno, i są na tyle krótkie, żeby w nie uwierzyć.

Nazwij granicę konkretnie. „Nie mam informacji o konkretnych zamówieniach” mówi klientowi coś prawdziwego o systemie. „Nie mogę w tym pomóc” nie mówi nic i brzmi jak zbycie. Konkretna wersja przy okazji uczy ludzi, do czego bot rzeczywiście się nadaje, co zmniejsza liczbę kolejnych niemożliwych pytań.

Wytnij zwroty, które drażnią: powtarzane przeprosiny, „jako model językowy AI”, sztuczną empatię i wszelkie sugestie, że klient źle sformułował pytanie. Kanał głosowy potrzebuje własnych sformułowań. Voicebot czytający na głos adres URL albo czternastoznakowy numer referencyjny to mała katastrofa - przenieś ten szczegół do kanału, w którym da się to przeczytać, a mówioną odmowę utrzymaj w tonie rozmowy.

Co bot powinien zrobić dalej

Odmowa bez następnego kroku to ślepy zaułek, a ślepy zaułek jest dla klienta gorszy niż błędna odpowiedź w danej chwili. Fallback jest skończony dopiero wtedy, gdy człowiek wie, skąd naprawdę dostanie odpowiedź.

Działający fallback zawiera pięć rzeczy:

• Granicę powiedzianą wprost - czego bot nie ma, słowami zrozumiałymi dla klienta.
• Zachowane oryginalne pytanie - żeby nikt nie musiał przepisywać go dla człowieka.
• Konkretny następny krok - osoba, formularz, strona, oddzwonienie.
• Realny czas oczekiwania - mgliste zapewnienia rodzą dokładnie to dodatkowe zgłoszenie, którego chciałeś uniknąć.
• Sposób na kontynuację - klient podejmuje rozmowę tam, gdzie ją przerwał, zamiast zaczynać od zera.

Przekazanie do człowieka, utworzenie zgłoszenia i reguły kierowania to standardowa praktyka, którą warto zaprojektować wokół swojego bota, niezależnie od użytych narzędzi. Element, który ludzie lekceważą, to przekazanie rozmowy konsultantowi bez utraty historii, bo klient, który musi tłumaczyć wszystko drugi raz, już przestał liczyć to jako pomoc. Wskazanie właściwej strony albo dokumentu też jest prawdziwą odpowiedzią i bije szybkością każdą kolejkę. W małym zespole jeden jasny kanał wygrywa z pomysłowym kierowaniem za każdym razem. W większej firmie: zdecyduj, które odmowy trafiają do której kolejki, zanim zdecyduje za ciebie wolumen.

Nie każda luka zasługuje na tę samą odpowiedź

Większość zespołów projektuje dwie reakcje, odpowiedź albo odmowę, podczas gdy są trzy. Bot może odpowiedzieć w pełni, odpowiedzieć częściowo z zaznaczeniem granicy, albo odmówić i przekierować. Ta środkowa opcja jest wykorzystywana zdecydowanie za rzadko.

Częściowa odpowiedź podaje ogólną zasadę i wstrzymuje się z częścią dotyczącą konkretnego konta, jasno mówiąc, co jest czym: „Zwroty przyjmujemy w standardowym terminie od doręczenia. Czy twoje konkretne zamówienie nadal się kwalifikuje, tego nie mogę sprawdzić”. Klient wychodzi z użyteczną wiedzą i trafnym obrazem tego, co będzie dalej.

Zanim bot odmówi wprost, pozwól mu zadać jedno pytanie doprecyzowujące. Duża część pozornych luk w wiedzy to po prostu niejednoznaczne pytania, a jedna wymiana zdań to porządkuje. Czego bot nigdy nie może robić, to wypełniać luki domysłem. Żadnej zgadniętej liczby, żadnej szacowanej daty, żadnej prawdopodobnej nazwy. Brak danych oznacza brak danych w odpowiedzi, kropka.

Przetestuj odmowy, zanim zrobią to klienci

Zespoły ćwiczą ścieżkę sukcesu, a ścieżkę porażki wypuszczają nieprzetestowaną. Odwróć to. Napisz listę pytań, których bot powinien odmówić, i przejdź je celowo, tak jak testowałbyś proces zakupowy.

Jedno przejście zrób złośliwie. Zapytaj o ceny, których nie publikujesz. Zapytaj o konkurencję. Zapytaj o coś politycznego. Zapytaj w drugim obsługiwanym języku. Zadaj pytanie, na które twoje FAQ odpowiada tylko w połowie, bo dokładnie tam pojawiają się pewne siebie bzdury.

W pierwszych tygodniach czytaj prawdziwe transkrypcje ręcznie i oznaczaj każdą odmowę jako trafną, niepotrzebną albo pominiętą. Te pominięte to ciekawa kolumna. Wprowadź je z powrotem do bazy wiedzy, bo prawdziwa luka to zadanie contentowe, nie zadanie dla bota - naprawą prawie zawsze jest nowy dokument, a nie sprytniejszy prompt.

Skoro po rejestracji dostajesz pierwszego voicebota bez opłat, ta próba generalna jest tania: przejdź całą listę odmów, zanim zobaczy ją choćby jeden klient. Co do rytmu, mały zespół może robić przegląd co tydzień. W większej firmie przegląd powinien mieć wyznaczoną osobę, inaczej po drugim miesiącu po cichu przestanie się odbywać.

Bot, który przyznaje się do ograniczeń, to ten, z którego ludzie dalej korzystają

Wymiana jest prosta. Wąski zestaw wiarygodnych odpowiedzi bije szeroki zestaw niepewnych, za każdym razem, w każdym kanale. Szeroki zakres lepiej wygląda w demo. Wiarygodność jest tym, co przetrwa kontakt z prawdziwymi klientami.

Projekt fallbacku to decyzja biznesowa o tym, co jesteś gotów obiecać, przebrana za ustawienie techniczne. Potraktuj ją jak to pierwsze, a wybory konfiguracyjne szybko staną się oczywiste.

Potem obserwuj wskaźnik, który naprawdę ma znaczenie, a nie jest nim odsetek rozwiązanych spraw. Klienci wracają do bota, który nigdy ich nie okłamał, nawet jeśli ciągle odsyła ich gdzie indziej. Jeśli porządkujesz resztę ścieżki porażki, inne poradniki o automatyzacji obejmują elementy, które ją otaczają.