Chatbot czy dodatkowy człowiek do obsługi

Chatbot opłaca się tam, gdzie pytania się powtarzają. Dodatkowa osoba tam, gdzie każde zgłoszenie kończy się decyzją. Granica biegnie przy zapisie.

·5 min czytania·Antoni Łubisz
Przenośnik z powtarzalnymi elementami rozdziela się na dwie ścieżki: identyczne biegną dalej same, nieregularne trafiają do stanowiska z człowiekiem.
W tym tekście6

Chatbot opłaca się tam, gdzie pytania się powtarzają, a odpowiedź da się sprawdzić, zanim pójdzie do klienta. Dodatkowa osoba opłaca się tam, gdzie każde zgłoszenie kończy się decyzją. Granica nie biegnie przy liczbie zapytań, tylko przy tym, czy odpowiedź ma coś zmienić w twoim systemie. Jeśli ma, sam chatbot to za mało.

Ta granica jest ostrzejsza, niż wygląda z zewnątrz. Firma dostaje sto zapytań tygodniowo i wydaje się, że to argument za automatem. Ale sto zapytań, z których każde dotyczy innej sprawy, to sto decyzji, a nie sto powtórzeń. Odwrotnie też: dwadzieścia zapytań tygodniowo brzmi jak za mało, żeby cokolwiek wdrażać, tylko że jeśli dziewiętnaście z nich brzmi identycznie, to jest to praca do oddania.

Rozstrzyga powtarzalność i to, co dzieje się po odpowiedzi. Dopóki system tylko mówi, pomyłka kosztuje jedną poprawioną wiadomość. Kiedy zaczyna zapisywać, pomyłka zostaje w bazie.

Zacznij od tego, ile z tych pytań już kiedyś padło

Weź skrzynkę z ostatniego miesiąca i przeczytaj pięćdziesiąt ostatnich wiadomości od klientów. Nie licz ich. Pogrupuj.

Zwykle wychodzi z tego kilka kubełków, które zajmują większość skrzynki: dostępność, cena, termin, status zamówienia, godziny otwarcia. Reszta to sprawy jednostkowe, przy których i tak siada człowiek. Ten podział jest odpowiedzią na pytanie z tytułu, tylko trzeba go zobaczyć na własnych wiadomościach, a nie na cudzym poradniku.

Jeśli pięć kubełków zjada czterdzieści z pięćdziesięciu wiadomości, automat ma co robić. Jeśli pięćdziesiąt wiadomości rozpada się na czterdzieści osobnych spraw, to jest etat, nie wdrożenie. Trzeci wynik jest najczęstszy: kubełki zjadają połowę, a druga połowa wymaga człowieka. Wtedy pytanie brzmi już inaczej, bo nie chodzi o wybór, tylko o to, gdzie postawić przekazanie.

Ta godzina z papierem i skrzynką jest tańsza niż każde wdrożenie i każda rekrutacja.

Granica biegnie przy zapisie, nie przy trudności pytania

Najczęstszy błąd w tej decyzji polega na tym, że mierzy się trudność pytania. Trudność nie jest właściwą miarą. Właściwą jest to, czy odpowiedź zmienia stan w jakimś systemie.

W jednym z naszych wdrożeń chatbot miał odpowiadać na pytania, opowiadać o usługach i umawiać spotkania. Robił to dobrze. Potem zakres urósł o rzecz, która wyglądała podobnie: miał domykać transakcje w systemie firmy partnerskiej, z którą klient rozliczał się prowizyjnie. Z zewnątrz to jest kolejna funkcja. W środku to jest inna kategoria pracy, bo przepływ był specyficzny dla tego biznesu i nie składał się z gotowych elementów.

Powiedzieliśmy, że to już nie jest zadanie dla konfiguracji, tylko dla oprogramowania pisanego pod ten proces. Nie dlatego, że tamtego nie dałoby się poskładać. Dałoby się. Skończyłoby się rzeczą, która czasem działa poprawnie, a czasem prawie poprawnie, i nikt by nie wiedział, który to raz.

Odpowiadanie wybacza niedokładność. Zapis do cudzej bazy nie wybacza jej wcale.

Czego automat nie ma prawa powiedzieć, ustalasz ty

Obawa, że automat powie klientowi coś głupiego, jest uzasadniona i nie zbywamy jej zapewnieniem, że „system jest bezpieczny”. Zbywa się ją listą.

Przed uruchomieniem spisujecie razem, o czym system nie wypowiada się w ogóle. Zwykle trafiają tam ceny niestandardowe, terminy, których nikt nie potwierdził, reklamacje, sprawy po terminie i wszystko, co pachnie zobowiązaniem. Na te tematy system mówi jedno zdanie i przekazuje do człowieka. Nie improwizuje, bo nie ma z czego.

Druga rzecz to sprawdzenie na waszej własnej historii. Bierzemy wcześniejsze rozmowy z klientami i pokazujemy, w ilu przypadkach system odpowiedziałby tak samo jak wasi ludzie. To jest jedyny sposób, żeby rozmawiać o jakości przed uruchomieniem, a nie po pierwszej wpadce.

Gotowe rozwiązanie z abonamentem tego nie ma i mieć nie może. Ono nie wie, jakie macie terminy, ceny i zasady, więc na pytanie o termin powie coś sensownie brzmiącego. Sensownie brzmiące jest tutaj gorsze od milczenia.

Przy jednej osobie liczy się kwalifikacja, nie liczba zgłoszeń

Jednoosobowa firma z dobrą widocznością w wyszukiwarce ma inny problem niż firma z działem obsługi. Zgłoszeń nie jest dużo w liczbach bezwzględnych. Jest ich za dużo w stosunku do jednej doby.

Pracowaliśmy z osobą z branży prawno-finansowej, która pełniła w firmie wszystkie role naraz. Marka osobista działała, wejść na stronę było sporo, tylko że każde zapytanie trzeba było przeczytać, ocenić i odpisać. Część tych rozmów nie miała szans skończyć się współpracą i było to widać już po drugim zdaniu, ale żeby zobaczyć drugie zdanie, trzeba było wejść w rozmowę.

Przenieśliśmy do systemu jej własny sposób kwalifikowania klienta i pierwsze kroki wdrażania go do współpracy. Do kalendarza zaczęły trafiać rozmowy już przefiltrowane. Oszczędność nie polegała na tym, że automat odpisał szybciej. Polegała na tym, że część rozmów w ogóle się nie odbyła.

Przy jednej osobie kosztem nie jest obsłużenie zapytania. Kosztem jest godzina spędzona na rozmowie, która i tak nie mogła się udać.

Kiedy mówimy: zatrudnij człowieka

Jedna z firm, z którymi pracowaliśmy, wynajmuje mieszkania i ma wielu najemców w jednym panelu. Prosty chatbot ze strony przenieśliśmy tam do środka, żeby przyjmował pytania i zgłoszenia usterek. I na tym zakończyliśmy. Nie dołożyliśmy nic więcej, chociaż zakres dało się rozszerzyć i byłoby to dla nas korzystne.

Powód jest prosty: grupa użytkowników była zamknięta i znana, a zadanie polegało na przyjęciu zgłoszenia i skierowaniu go we właściwe miejsce. Do tego prosta rzecz wystarcza. Rozbudowa dołożyłaby kosztu utrzymania i nie dołożyła niczego, co ktokolwiek by zauważył.

Odwrotna sytuacja też się zdarza i wtedy mówimy o tym wprost. Jeśli wasze zgłoszenia są za każdym razem inne, a odpowiedź wymaga oceny sytuacji, żaden automat tego nie zdejmie. Zdejmie to osoba. Możemy najwyżej dać jej narzędzie, żeby szybciej znajdowała informacje, a to jest inny projekt i inny rachunek.

Najgorszy wynik tej decyzji to nie jest wybranie złej opcji. To jest wdrożenie czegoś w połowie, utrzymywanie tego przez rok i nieumienie powiedzieć, czy pomaga.

Zanim się odezwiesz

Jeśli wasza obsługa polega na tym, że każde zgłoszenie jest inne i kończy się decyzją, nie sprzedamy wam chatbota. Powiemy, żebyście zatrudnili osobę, i tak samo powiemy, jeśli okaże się, że gotowe narzędzie z abonamentem załatwia sprawę taniej.

Jeśli natomiast po przejrzeniu pięćdziesięciu wiadomości widzicie kilka kubełków, które zjadają większość skrzynki, to jest zakres, od którego zaczynamy. Pierwszy krok jest mały i policzalny: jeden rodzaj zapytań, lista tematów zakazanych i sprawdzenie na waszych wcześniejszych rozmowach.

Zobacz, jak to robimy: Automatyzacja obsługi klienta.

Pytania i odpowiedzi(FAQ)

Zastąpi część pracy, nie osobę. W typowej skrzynce kilka powtarzalnych kubełków zajmuje większość wiadomości i to jest zakres do oddania. Sprawy jednostkowe zostają przy człowieku, bo wymagają decyzji. Firmy, które planowały redukcję etatu, zwykle kończą z tą samą osobą robiącą trudniejsze rzeczy.

Po tym, że zaczynacie od niego oczekiwać zapisu, a nie odpowiedzi. Dopóki system informuje, granice są miękkie. Kiedy ma wystawić dokument, zmienić status albo wpisać coś do systemu, którego nie kontrolujecie, potrzebna jest implementacja pisana pod ten proces. Drugi sygnał to rosnąca liczba wyjątków, których nikt nie przewidział przy uruchomieniu.

Może, ale to już nie jest ten sam rodzaj wdrożenia. Zapis wymaga przewidywalności na poziomie, którego gotowe elementy nie dają, a błąd nie kończy się poprawioną wiadomością, tylko wpisem w bazie. Przy takim zakresie liczymy inaczej i mówimy o tym na pierwszym spotkaniu, a nie po podpisaniu.

Przy jednym rodzaju zapytań pierwszą wersję uruchamiamy w kilka tygodni i efekt widać w tym samym miesiącu, bo mierzy się go liczbą wiadomości, które nie trafiły do człowieka. Nie obiecujemy natomiast, że pierwsza wersja obsłuży wszystko. Zakres rośnie o kolejne kubełki, kiedy widać, że poprzedni działa.

O autorze

Antoni Łubisz - Co-Founder, Frontend Developer

Antoni Łubisz

Co-Founder, Frontend Developer

Antoni Łubisz jest współzałożycielem i Frontend Developerem w AppWave - software house'ie, który pomaga founderom i rosnącym firmom wdrażać produkty oparte na AI i automatyzacje. Specjalizuje się w budowaniu interfejsów gotowych na produkcję, integracjach z systemami AI oraz aplikacjach webowych zamieniających złożoną logikę biznesową w proste, intuicyjne doświadczenia użytkownika. Działa z Łodzi.