Wnioski od szefa działu AI w Hiver
Większość osób zakłada, że tworzenie funkcji AI dla platformy obsługi klienta polega jedynie na planowaniu, realizacji i wdrażaniu.
Jeśli jednak porozmawiasz z osobami stojącymi za kulisami, przekonasz się, jak bardzo rzeczywistość się od tego różni.
Anurag Maherchandani, szef działu AI w Hiver, jest jedną z takich osób. W Hiver, platformie obsługi klienta opartej na AI, używanej przez ponad 10 000 zespołów wsparcia do obsługi rozmów z klientami na dużą skalę, presja, by „dodać AI”, pojawiła się wcześnie i była bardzo silna. Każda skrzynka odbiorcza, każde zgłoszenie i każda interakcja z klientem wydawały się naturalnymi kandydatami do automatyzacji.
Anurag kieruje wszystkimi inicjatywami AI Hivera, co oznacza, że odpowiada za ustalenie, co należy zbudować, jak to zrobić i dlaczego powinno to mieć znaczenie dla klientów. Oto jego zdanie na temat tego, czego naprawdę potrzeba, aby tworzyć działające funkcje AI.
Zacznij od rezultatu, nie od modelu
Podstawowa zasada stojąca za każdą decyzją dotyczącą AI w Hiverze brzmi: AI nie jest produktem. Produktem jest rezultat.
W praktyce oznacza to, że punktem wyjścia dla każdej funkcji AI nigdy nie jest pytanie „co potrafi ten model?”, lecz „gdzie ludzie poświęcają czas na podejmowanie decyzji, których nie powinni musieć podejmować?”
To rozróżnienie kształtuje wszystko, co następuje później — od wyboru problemu po sposób prezentowania funkcji w interfejsie użytkownika.
„Kiedy zespoły mówią, że „tworzą produkt AI”, zwykle mają na myśli integrację modelu, udostępnienie go za pośrednictwem interfejsu użytkownika i osiągnięcie wysokich wyników dokładności. Nic z tego nie gwarantuje jednak wartości. Użytkownicy nie kupują inteligencji. Kupują ulgę: w powtarzalnej pracy, niepewności i tarciach operacyjnych” — mówi Anurag.
Nawet jeśli model świetnie wypada podczas testów, prawdziwym sprawdzianem jest to, czy wpływa na sposób pracy użytkowników.
Want to learn more about Hiver?
Wnioskowanie czy reguły: najpierw wybierz właściwe narzędzie
Zanim jakikolwiek problem przejdzie do etapu wyboru modelu lub oceny danych, pojawia się bardziej fundamentalne pytanie: Czy to rzeczywiście wymaga wnioskowania?
Wnioskowanie oznacza, że system musi uogólniać na podstawie wzorców, których nie widział wcześniej wprost, i dokonywać ocen, których nie da się w pełni określić z wyprzedzeniem.
Reguły oznaczają, że logikę można zapisać jawnie: jeśli X, to Y. Tych dwóch podejść nie można stosować zamiennie, a sięganie po wnioskowanie tam, gdzie wystarczyłyby reguły, zwiększa koszty, opóźnienia i nieprzewidywalność bez żadnych korzyści.
Kiedy zespół Hivera musiał skonfigurować routing wiadomości e-mail od określonych segmentów klientów, takich jak konta VIP, wybrane branże czy konkretne domeny, początkowo planowano stworzyć model AI, który identyfikowałby je automatycznie.
Zamiast tego Hiver stworzył konfigurowalne obiekty reguł. Wykorzystują one jawną logikę opartą na domenach, słowach kluczowych i metadanych. Rezultat jest przewidywalny, łatwy do debugowania i możliwy do skonfigurowania przez użytkowników końcowych bez angażowania zespołu AI Hivera.
Na przykład jeśli firma chce, aby wszystkie wiadomości e-mail z domeny @enterprise.com lub wiadomości zawierające słowo „umowa” trafiały do skrzynki priorytetowej, może skonfigurować regułę w ciągu kilku minut. Nie wymaga to AI i nie pozostawia żadnych wątpliwości co do sposobu obsługi wiadomości e-mail.
Jak ujmuje to Anurag: „Jeśli potrafisz zapisać reguły, zapisz reguły. Zachowaj AI dla problemów, w przypadku których nie dałoby się wyliczyć wszystkich reguł, a system musi uogólniać na podstawie wzorców, których wcześniej wprost nie widział.”
Ocena problemów, które wymagają wnioskowania
Gdy problem rzeczywiście wymaga wnioskowania, Hiver ocenia go według czterech kryteriów, zanim zdecyduje się na jego rozwiązanie:
- Częstotliwość. AI wiąże się z rzeczywistymi kosztami: kosztem wnioskowania, dodatkowym opóźnieniem oraz nieprzewidywalnymi sposobami występowania błędów. Takie obciążenie ma sens tylko wtedy, gdy zadanie jest wykonywane wystarczająco często, aby automatyzacja przynosiła kumulacyjne korzyści. Zadanie wykonywane kilka razy w tygodniu rzadko uzasadnia tę złożoność. Zadanie, które agenci wykonują setki razy dziennie — tak.
- Przewidywalność. Niektóre klasyfikacje zależą od informacji obecnych w danych wejściowych (treści wiadomości e-mail, temacie, metadanych), a nie od uczenia się na podstawie dostępnych danych. Inne zależą od kontekstu, którego model po prostu nie ma: poziomu klienta, wewnętrznych zasad eskalacji czy osądu agenta wypracowanego z czasem. Przed podjęciem decyzji o rozpoczęciu prac zespół przeprowadza testy wykonalności na danych historycznych, aby ustalić, czy dana prognoza jest w ogóle możliwa do uzyskania z użytecznym poziomem pewności. Jeśli nie ma odpowiedniego sygnału, żadna decyzja dotycząca architektury tego nie zmieni.
- Zapotrzebowanie klientów. Czy rozwiązanie odpowiada na problem, który klienci sami wskazali, czy na problem, którego istnienie zespół założył? W pierwszym przypadku prawdopodobieństwo przyjęcia rozwiązania jest znacznie wyższe. Drugi przypadek zwykle prowadzi do powstawania funkcji, które działają dobrze, ale są ignorowane, jeśli chodzi o ich przyjęcie przez użytkowników.
- Stawka i odwracalność. Co się dzieje, gdy model się pomyli? Błędnie przypisana etykieta, którą agent poprawia jednym kliknięciem, wiąże się z zupełnie innym profilem ryzyka niż błędnie wysłana odpowiedź do klienta lub pominięta eskalacja. Prognozy o niskiej stawce, które można łatwo odwrócić, są dobrymi kandydatami do automatyzacji. Decyzje o wysokiej stawce wymagają kontroli człowieka albo znacznie wyższych progów pewności, zanim spowodują określone działanie.
Funkcja automatycznego tagowania firmy Hiver działa, ponieważ spełnia wszystkie cztery kryteria. Wykorzystuje model do określenia najbardziej odpowiedniej etykiety dla przychodzącej konwersacji. Agenci nie muszą ręcznie kategoryzować każdego zgłoszenia.
Zespoły definiują zestaw etykiet w panelu administracyjnym, takich jak „Rozliczenia” lub „Wsparcie techniczne”. Pełnią one funkcję celów predykcji. Model uczy się wzorców na podstawie treści wiadomości e-mail, tematu i metadanych. Uwzględniane są wyłącznie etykiety, dla których występują wyraźne sygnały.
Agenci wykonują to zadanie niemal przy każdej konwersacji, co oznacza wysoką częstotliwość. Sygnał jest obecny w treści wiadomości e-mail dla uwzględnionych etykiet, dzięki czemu można go przewidywać. Klienci Hiver wyraźnie prosili o ograniczenie ręcznego segregowania zgłoszeń, co napędza przyjęcie rozwiązania. Gdy model się pomyli, etykietę można poprawić jednym kliknięciem, dzięki czemu stawka pozostaje niska, a błąd można łatwo odwrócić.
Analiza nastrojów opiera się na tym samym schemacie. Analizuje ton każdej konwersacji, aby określić, czy klient jest sfrustrowany, neutralny czy pozytywnie nastawiony. Zespoły obserwują to w każdej konwersacji, więc częstotliwość jest wysoka. Ton jest obecny w tekście, dzięki czemu można go przewidywać.
Zespoły chcą wcześnie identyfikować sfrustrowanych klientów, co tworzy wyraźne zapotrzebowanie. Jeśli model się pomyli, agenci mogą zastąpić jego wynik bez wpływu na rezultat, dzięki czemu rozwiązanie pozostaje niskiego ryzyka.
Testowanie wykonalności przed rozpoczęciem budowy
Jednym z bardziej wymagających pod względem dyscypliny elementów procesu Hiver jest przeprowadzanie testów wykonalności dokładności przed napisaniem jakiegokolwiek kodu produkcyjnego.
Funkcja sugerowania etykiet jest pouczającym przykładem. Jeśli na przykład wiadomość e-mail zawiera treść „Pobrano ode mnie opłatę dwukrotnie”, model powinien wybrać „Rozliczenia”. Próbował jednak również wybierać etykiety takie jak „Klient VIP” lub „Eskaluj do menedżera”, których nie można wywnioskować z samej wiadomości e-mail. Precyzja była niska, a agenci przestali ufać wynikom.
Podstawowym problemem było nierozróżnienie przewidywalnych i nieprzewidywalnych typów etykiet. Etykiety kategorii, takie jak „Rozliczenia”, „Wsparcie techniczne” i „Zwroty”, odpowiadają wzorcom językowym w treści wiadomości e-mail. Można ich nauczyć model.
Etykiety operacyjne, takie jak „Klient VIP”, „Oczekiwanie na dział prawny” i „Eskaluj do menedżera”, zależą od kontekstu spoza danych wejściowych: historii konta, wewnętrznych zasad biznesowych i koordynacji między zespołami. Żaden model wytrenowany na wiadomościach e-mail klientów nie będzie w stanie wiarygodnie ich przewidywać.
Rozwiązanie miało charakter strukturalny: zanim dowolny typ etykiety zostanie uwzględniony jako cel predykcji, przechodzi test wykonalności. Czy dane historyczne pozwalają wiarygodnie przewidywać ten wynik? Jeśli nie, etykieta jest wykluczana z zakresu modelu, niezależnie od tego, jak użyteczna teoretycznie byłaby jej automatyzacja.
„Dyscyplina polegająca na stwierdzeniu: „ten typ etykiety nie jest dobrym kandydatem do automatyzacji”, była trudniejsza niż zbudowanie modelu. Oznaczała jednak, że wdrażaliśmy wyłącznie prognozy, którym agenci mogli ufać.”
Wbudowanie AI w przepływ pracy, a nie umieszczanie go ponad nim
Miejsce, w którym AI znajduje się w produkcie, jest równie ważne jak to, co robi.
Funkcja, która zmusza użytkowników do zatrzymania się, wpisania polecenia i sprawdzenia wyniku przed podjęciem działania, dodała krok do przepływu pracy, zamiast go usunąć. To wynik netto negatywny, nawet gdy AI jest dokładne. Użytkownicy, którzy pracują szybko i obsługują zgłoszenia jedno po drugim, będą omijać wszystko, co zakłóca ten rytm.
Kierunek projektowy, który się sprawdza, to AI działające, zanim użytkownik będzie musiał o nim pomyśleć. W Hiver:
- Wiadomości e-mail są oznaczane przed ich otwarciem przez agentów.
- Nastroje są analizowane i oznaczane, zanim agent otworzy rozmowę: sfrustrowany klient pojawia się już na górze kolejki.
- Kolejność w kolejce odzwierciedla sygnały dotyczące priorytetów, bez konieczności konfigurowania czegokolwiek przez agentów.
- Wersje robocze odpowiedzi pojawiają się bezpośrednio w interfejsie jako sugestie.
- Sprawy, w których pewność modelu spada poniżej określonego progu, są przekazywane do weryfikacji przez człowieka, zamiast być automatycznie obsługiwane.
Interfejs nie jest oparty na proszeniu AI o pomoc. Agenci nie muszą jej uruchamiać. Wiadomości e-mail są oznaczane i priorytetyzowane, zanim agenci je otworzą. AI usuwa konieczność wykonywania dodatkowej pracy, zanim agent w ogóle musi się nad nią zastanowić.
Wewnętrzna miara skuteczności tego rozwiązania brzmi: "Jeśli użytkownicy zauważają AI, prawdopodobnie zaprojektowaliście je niewłaściwie."
Kiedy wszystko działa prawidłowo, użytkownicy przestają wspominać o funkcji AI. Mówią o krótszym czasie rozwiązywania spraw, mniejszej liczbie zaległości i łatwiejszym wdrażaniu nowych agentów. AI przestaje być widoczne i staje się elementem struktury systemu.
| 📌 Migawka klienta: jak wygląda to w praktyce |
|---|
| 📌 Migawka klienta: jak wygląda to w praktyceW firmie ITS Logistics zespoły obsługiwały rozmowy z klientami w rozproszonych skrzynkach odbiorczych, ręcznie przekierowywały zapytania i często wchodziły sobie w drogę, wysyłając powielone odpowiedzi lub pomijając dalsze działania. Po przejściu na Hiver sytuacja szybko się zmieniła. W ciągu zaledwie trzech tygodni czas przygotowania ofert skrócił się o 61%, a większość przychodzących zapytań była automatycznie kierowana do właściwej osoby. Co ważniejsze, każda rozmowa miała jasno określonego właściciela, a menedżerowie zyskali wreszcie wgląd w postęp prac. Rezultatem był system, który mógł obsługiwać rosnący popyt bez zwiększania złożoności ani zatrudnienia, ponieważ sama praca stała się bardziej uporządkowana i przewidywalna. „Hiver przekształcił rozproszone zapytania w uporządkowany system obsługi klienta. Każde zapytanie jest śledzone, ma właściciela i jest rozwiązywane szybciej.” — Alejandro Arboleda, dyrektor operacyjny, ITS Logistics. |
Dokładność i zaufanie to różne problemy
System może osiągać 95% dokładności i nadal zawodzić w środowisku produkcyjnym, jeśli użytkownicy nie mają wiarygodnego wyobrażenia o tym, kiedy może się pomylić.
Zaufanie wynika z przewidywalności i kontroli. Użytkownicy muszą wystarczająco dobrze rozumieć działanie systemu, aby wiedzieć, kiedy na nim polegać, a kiedy zastąpić jego działanie własną decyzją. Jeśli nie potrafią wyrobić sobie takiego obrazu, albo przestaną korzystać z funkcji, albo przestaną sprawdzać jej wyniki — oba scenariusze oznaczają niepowodzenie.
Podejście Hiver polega na tym, aby korekta była podstawowym elementem projektu, a nie rozwiązaniem awaryjnym na wypadek błędów. Agenci mogą jednym kliknięciem zmienić dowolną prognozę. System rejestruje te zmiany jako sygnały zwrotne. Progi oparte na poziomie pewności decydują o tym, co zostanie zastosowane automatycznie, a co zostanie przekazane do weryfikacji.
Jak mówi Anurag: "Zamiast traktować nadpisywanie decyzji jako błąd, uczyniliśmy z niego funkcję. Dzięki temu agenci zachowują kontrolę, a my tworzymy pętlę uczenia się bez konieczności trenowania systemu na danych klientów. System staje się lepszy, obserwując rezultaty."
Rozwiązuje to również problem związany z danymi. Ponieważ korekty wracają do systemu jako sygnały zwrotne, model doskonali się na podstawie obserwowanych rezultatów, zamiast wymagać dostępu do surowych danych klientów.
Granica prywatności pozostaje nienaruszona, a system z czasem staje się coraz dokładniejszy.
Dwa pytania przed wdrożeniem dowolnej funkcji AI
Przed zatwierdzeniem jakiejkolwiek nowej funkcji AI należy zadać dwa pytania:
"Gdyby jutro usunięto tę funkcję, czy użytkownicy by zaprotestowali?"
Jeśli odpowiedź brzmi „nie”, funkcja stanowi dodatek, ale nie jest niezbędna. Nie zmieniła jeszcze sposobu pracy ludzi. To właśnie do takiego poziomu warto dążyć.
"Czy ta funkcja ogranicza liczbę decyzji, czy tworzy nową?"
Jeśli użytkownicy muszą zdecydować, czy zaufać AI, skonfigurować ją lub zinterpretować jej wynik, zanim będą mogli działać, AI zwiększyła obciążenie poznawcze zamiast je zmniejszyć.
To niepowodzenie, niezależnie od wyników technicznych.
Rzeczywista praca stojąca za funkcjami AI
Tworzenie AI, która działa w środowisku produkcyjnym, w mniejszym stopniu polega na wyborze modelu, a w większym na wyborze problemu, testowaniu wykonalności i projektowaniu z myślą o tym, jak ludzie rzeczywiście pracują. Sama AI stanowi najmniejszą część problemu.
"Produktem nigdy nie były klasyfikacja, analiza nastrojów, tworzenie wersji roboczych ani podsumowywanie. Produktem było mniej decyzji podejmowanych przez każdego agenta, szybsze rezultaty, mniejsze obciążenie poznawcze i skalowalne operacje. AI była mechanizmem, a mechanizm działa tylko wtedy, gdy zostanie zastosowany do właściwego problemu i oparty na danych, które rzeczywiście wspierają rozwiązanie."
Jeśli zastanawiasz się, gdzie AI pasuje do Twoich operacji wsparcia, porozmawiaj z nami w Hiver. Pokażemy Ci, jak możemy pomóc Ci zapewniać empatyczne wsparcie.
