Jak dodaliśmy asystenta AI do platformy SaaS — nie psując jej

Każdy zespół SaaS, z którym rozmawiamy, prędzej czy później wypowiada na głos to samo zdanie: "Powinniśmy wsadzić tu asystenta AI". Czasem to presja zarządu, czasem premiera konkurencji, czasem szczera potrzeba. Ciekawy nie jest nigdy sam pomysł — pomysł ma niemal każdy. Ciekawa jest przepaść między tym zdaniem a funkcją, na której prawdziwi użytkownicy naprawdę polegają. To historia jednego zespołu, który tę przepaść pokonał, i mało efektownych decyzji, które go tam doprowadziły.

Krótka uwaga na wstępie: zanonimizowaliśmy klienta i zaokrągliliśmy liczby. To mała, rentowna firma B2B SaaS — poniżej dwudziestu osób — sprzedająca narzędzie workflow zespołom operacyjnym. Zmieniliśmy dość szczegółów, byście ich nie rozpoznali, ale kształt projektu jest dokładnie taki, jak się wydarzyło. Liczby są poglądowe, nieaudytowane; wolimy pokazać wam wzorzec niż upiększać wykres.

Opisujemy to, bo projekt jest niemal wzorcowym przykładem tego, jak takie rzeczy naprawdę przebiegają. Nie poszło tak, jak zapowiadała prezentacja z kick-offu. Poszło lepiej — ale tylko dlatego, że byliśmy gotowi wyrzucić pierwszą wersję.

Sytuacja: dwa problemy w jednym kostiumie

Gdy założyciel odezwał się po raz pierwszy, prośba była prosta: "Chcemy chatbota AI w aplikacji". Tam zaczyna się większość projektów — i tam większość po cichu schodzi na manowce. "Chatbot AI" to nie cel, to kształt. Naszym pierwszym zadaniem było więc ustalić, jaki problem ma rozwiązać chatbot — i czy to w ogóle jeden problem.

Nie był. Pod tą jedną prośbą kryły się dwa całkowicie różne bóle. Pierwszy to obciążenie supportu: dwuosobowy zespół obsługi klienta tonął w powtarzalnych zgłoszeniach — "jak to wyeksportować", "gdzie jest ustawienie tego", "czemu mój raport się nie uruchomił". Około 60% przychodzących zgłoszeń to były pytania, na które odpowiedź już gdzieś istniała w dokumentacji pomocy. Drugi ból był cichszy i droższy: aktywacja. Ich produkt miał naprawdę potężną funkcję ukrytą trzy kliknięcia w głąb, której niemal nikt nie odkrywał sam. Użytkownicy, którzy ją znaleźli, zostawali na lata. Ci, którzy nie — odchodzili w pierwsze dwa miesiące.

Ten sam kostium, dwa problemy. I ciągnęły w różne strony. Bot supportowy chce odbijać pytania i schodzić z drogi. Asystent aktywacyjny chce zaczynać rozmowy i popychać ludzi ku rzeczom, o które nie pytali. Gdybyśmy zbudowali "chatbota AI" bez ich rozdzielenia, powstałoby coś, co obie role wykonuje kiepsko.

Zawężenie do czegoś, co dało się skończyć

W obliczu dwóch problemów pojawia się pokusa, by zbudować wielkiego asystenta obsługującego oba od pierwszego dnia. Odwiedliśmy zespół od tego. Nie dlatego, że wizja była zła, lecz dlatego, że sześciomiesięczny "asystent do wszystkiego" to dokładnie taki projekt, który wypada za późno, nie robi wrażenia i na kolejne dwa lata przyprawia wszystkich o niepokój wobec AI.

Wybraliśmy więc jeden. Postawiliśmy najpierw na odbijanie zgłoszeń, z trzech nudnych, lecz rozstrzygających powodów. Miało jasny, mierzalny cel — liczbę zgłoszeń. Korzystało z treści, które już istniały — dokumentacji pomocy i dawnych zgłoszeń. A gdyby wypadło słabo, strata była mała: użytkownik, który nie dostał dobrej odpowiedzi, po prostu robił to, co dotąd, i zakładał zgłoszenie. Niskie ryzyko, szybka informacja zwrotna, uczciwy wskaźnik. To zawsze dobra pierwsza funkcja AI.

Asystent aktywacyjny nie zniknął — odłożyliśmy go, na papierze, z jasną adnotacją: faza druga, gdy warstwa wyszukiwania się sprawdzi. Ta jedna decyzja prawdopodobnie uratowała projekt. Dała zespołowi metę, którą naprawdę mógł osiągnąć w tygodnie, a nie kwartały.

Pierwszy prototyp, który zbudowaliśmy — i usunęliśmy

Oto część, którą większość case studies pomija. Nasz pierwszy działający prototyp był — delikatnie mówiąc — niedobry. Zrobiliśmy rzecz oczywistą: podłączyliśmy artykuły pomocy produktu do dużego modelu językowego, dodaliśmy okno czatu i pozwoliliśmy użytkownikom zadawać pytania. W demie wyglądało to magicznie. W realnych testach rozpadło się w bardzo konkretny, bardzo pouczający sposób.

Model mylił się z pewnością siebie. Zapytany o ustawienie, które zmieniło nazwę pół roku wcześniej, radośnie wymyślał starą ścieżkę w menu. Zapytany o funkcję z wyższego planu, tłumaczył, jak jej używać — klientowi, który nie miał do niej dostępu. Każda odpowiedź brzmiała autorytatywnie, co czyniło te błędne gorszymi niż brak odpowiedzi. Bot supportowy, który uprzejmie kłamie, nie zmniejsza liczby zgłoszeń; generuje bardziej wściekłe.

Moglibyśmy to zamaskować poprawkami promptów. Zamiast tego zrobiliśmy coś, co wydawało się krokiem wstecz, a okazało się całą grą: wyrzuciliśmy pierwszy prototyp i przebudowaliśmy go wokół ścisłej zasady — asystent może odpowiadać wyłącznie na podstawie źródeł, które potrafi zacytować, a w przeciwnym razie musi powiedzieć "nie wiem".

Co ostatecznie zbudowaliśmy

Wersja, która trafiła na produkcję, była celowo skromna w tym, co próbowała, i ścisła w tym, jak się zachowywała. Pod maską był to asystent oparty na wyszukiwaniu: gdy użytkownik o coś pytał, system najpierw przeszukiwał wyselekcjonowaną, aktualną bazę wiedzy, a potem prosił model, by odpowiedział wyłącznie na podstawie tego, co znalazł, z linkiem do źródła. Brak źródła — brak pewnej odpowiedzi, tylko czyste przekazanie do człowieka.

Trzy decyzje projektowe wykonały większość ciężkiej pracy i żadna z nich nie jest ekscytująca. I o to chodzi — to nudne wybory zwykle rozstrzygają, czy funkcja AI zdobędzie zaufanie, czy zostanie po cichu wyłączona.

Oparcie na źródłach ponad spryt

Każda odpowiedź była powiązana z prawdziwym, aktualnym dokumentem. Więcej czasu poświęciliśmy na czyszczenie i strukturyzowanie bazy wiedzy niż na strojenie modelu. Mało efektowne, a zdecydowanie najbardziej dźwigniowe zadanie w projekcie. Przeciętny model na doskonałej, dobrze utrzymanej treści bije genialny model na przestarzałym bałaganie.

Płynne przekazanie

Gdy asystent nie był pewien, nie zgadywał. Mówił to i oferował drogę jednym kliknięciem do człowieka — niosąc kontekst rozmowy, by użytkownik nigdy nie musiał się powtarzać. Wbrew intuicji sprawiało to, że ludzie bardziej mu ufali: asystent przyznający się do granic wydaje się uczciwy, a oni polegali na nim w łatwych 60% właśnie dlatego, że usuwał się przy trudnych 40%.

Świadomy tego, kto pyta

Ponieważ żył wewnątrz produktu, asystent znał plan użytkownika, jego rolę i miejsce w aplikacji. Dzięki temu nigdy nie tłumaczył funkcji, do której ktoś nie miał dostępu, i mógł powiedzieć "przycisk, którego pan szuka, jest na ekranie, na którym pan właśnie jest". Ta świadomość produktu to prawdziwa przewaga asystenta w aplikacji nad ogólnym chatbotem doklejonym do strony marketingowej.

1. 1
   Wyczyszczenie i strukturyzacja bazy wiedzy

   Przejrzeliśmy każdy dokument pomocy, skasowaliśmy przestarzałe, a resztę otagowaliśmy według planu i funkcji. To był pierwszy tydzień — i najważniejszy.
2. 2
   Zbudowanie warstwy wyszukiwania

   Najpierw szukaj, potem odpowiadaj. Model widział wyłącznie zweryfikowaną, aktualną treść — i miał polecenie odmówić wszystkiego, czego nie umiał oprzeć na źródle.
3. 3
   Wpięcie kontekstu produktu

   Połączyliśmy asystenta z planem, rolą i bieżącym ekranem użytkownika, by odpowiedzi były dopasowane i nigdy nie wskazywały funkcji, z których dana osoba nie mogła korzystać.
4. 4
   Zaprojektowanie uczciwej ścieżki awaryjnej

   Ścieżkę 'nie jestem pewien — oto człowiek' zbudowaliśmy jako pełnoprawną funkcję, z pełnym kontekstem rozmowy przekazywanym zespołowi supportu.
5. 5
   Wdrożenie do 10% użytkowników za flagą

   Po cichu wdrożyliśmy do części kont, przez dwa tygodnie obserwowaliśmy prawdziwe rozmowy, naprawiliśmy to, co się psuło, a potem poszerzyliśmy wdrożenie.

Wyniki — i ten, który nas zaskoczył

Gdy asystent był dostępny dla wszystkich przez około trzy miesiące, obraz był jasny. Podamy zaokrąglone, poglądowe liczby — kierunek liczy się bardziej niż miejsca po przecinku.

Wskaźnik supportu był tym, który obiecaliśmy, i dostarczył: nieco ponad połowa powtarzalnych zgłoszeń po prostu przestała napływać, a dwuosobowy zespół odzyskał tydzień na sprawy, które naprawdę wymagały człowieka. Dobry wynik, dokładnie w zakresie.

Ale rezultatem, który naprawdę zaskoczył założyciela, był ten, pod który wcale nie optymalizowaliśmy. Ponieważ asystent cały dzień odpowiadał na pytania "jak zrobić X", w naturalny sposób wciąż kierował użytkowników ku tej ukrytej, przyciągającej funkcji — tej powiązanej z retencją. Nie zbudowaliśmy jeszcze asystenta aktywacyjnego. Bot supportowy po cichu wykonywał część jego pracy jako efekt uboczny, po prostu będąc pomocnym i świadomym produktu. Nowi użytkownicy znajdowali funkcję o tygodnie wcześniej niż wcześniej.

Co powiedzielibyśmy kolejnemu zespołowi

Jeśli jesteście zespołem SaaS wpatrzonym w to samo zdanie "powinniśmy dodać asystenta AI", kilka rzeczy z tego projektu sprawdza się znacznie szerzej.

• Rozdziel problemy, zanim zaczniesz budować. "Chatbot AI" niemal zawsze kryje dwa lub trzy odrębne zadania, które chcą różnych projektów.
• Zacznij od zastosowania, w którym błędna odpowiedź kosztuje najmniej. Odbijanie zgłoszeń to niemal idealny pierwszy ruch; awaryjnym rozwiązaniem jest status quo.
• Przeznacz większość wysiłku na treść, nie na model. Oparcie na czystych, aktualnych danych czyni asystenta godnym zaufania.
• Uczyń z 'nie wiem' funkcję, nie porażkę. Uczciwe przekazanie buduje zaufanie, dzięki któremu użytkownicy polegają na tym, co bot robi dobrze.
• Wdróż najpierw za flagą do małej części. Prawdziwe rozmowy nauczą cię rzeczy, których nie nauczy żadne demo.

Częste pytania