Jak tworzyć trwałe agentów głosowych: wnioski z wdrożeń inżynierskich u klientów

W większości firm rozwiązania punktowe dla obsługi klienta od dawna ocenia się na podstawie deflectionu. Oznacza to zmniejszanie liczby połączeń i ograniczanie kontaktu z żywymi konsultantami. Deflection nie oznacza jednak rozwiązania problemu, a właśnie w tej luce doświadczenie klienta się psuje. Aby ją zamknąć, agenci potrzebują nie tylko dostępu do danych, ale też do systemów, które pozwalają na ich podstawie działać. Dzięki temu mogą zwracać pieniądze, prowadzić klientów przez proces płatności i przekazywać sprawę konsultantowi z pełnym kontekstem, gdy sytuacja tego wymaga. Firmy mogą więc obsługiwać interakcje z klientami na dużą skalę, znacznie odciążając zespoły wsparcia i poprawiając doświadczenie po obu stronach rozmowy. W ramach niedawnego wdrożenia z Revolut, firmą fintech obsługującą 70 milionów klientów na świecie, skróciło to czas rozwiązania sprawy 8-krotnie i zapewniło 99,7% skuteczności połączeń. 

Firmy muszą wprowadzać zmiany tej skali stopniowo, w ścisłym związku z główną misją organizacji i przy mocnym wsparciu kadry zarządzającej. Na poziomie technicznym rozumowanie w nieustrukturyzowanym środowisku wiąże się z ryzykiem, którym trzeba uważnie zarządzać. Jeśli agent może działać w systemie zarządzania relacjami z klientami (CRM), zmieniać zamówienie w systemie sprzedażowym czy eskalować sprawę, model zarządzania jest równie ważny jak sam model. Pytanie nie brzmi już, czy agenci poradzą sobie z prawdziwą pracą, lecz jakie mechanizmy są potrzebne, by wdrażać ich bezpiecznie i powtarzalnie.

W tym artykule dzielimy się naszym doświadczeniem i pokazujemy, co decyduje o sukcesie agentów — od pierwszego wdrożenia po skalowanie ich na całą obsługę klienta w organizacji.

Wdrażanie agentów a wdrażanie oprogramowania

Zanim przejdziemy głębiej do tworzenia agentów, warto porównać wdrażanie agentów głosowych z tradycyjnym oprogramowaniem, które firmy wdrażają od dekad. Z tej perspektywy agentów można podzielić na dwa odrębne elementy: tradycyjne oprogramowanie i główny orkiestrator.

Oprogramowanie

Główny orkiestrator

Elementy tradycyjnego oprogramowania służą głównie poprawie działania i wydajności agenta. W ElevenAgents obejmują funkcje takie jak wersjonowanie, testy A/B, telefonia oraz konfiguracja pierwszej wiadomości, między innymi. Po wdrożeniu komponenty te wykazują niewielki lub zerowy dryf, więc ich działanie jest bardzo przewidywalne. Dzięki solidnym praktykom inżynierskim organizacje mogą szybko je rozwijać i dokładnie rozumieć ich działanie na produkcji za pomocą rygorystycznego zestawu metryk, śladów i logów. Poprawa opóźnień w tej warstwie opiera się na dobrze znanych wzorcach: cache'owaniu, puli połączeń, skalowaniu infrastruktury i optymalizacji protokołów — wszystkie te metody dają przewidywalne rezultaty.

Komponenty głównego orkiestratora są z natury trudniejsze do przewidzenia, ale decydują o działaniu agenta w czasie rzeczywistym — zarówno pod względem jakości odpowiedzi, jak i odczuwanego opóźnienia. W przeciwieństwie do tradycyjnego oprogramowania działają na języku naturalnym i audio, gdzie przestrzeń wejściowa jest praktycznie nieograniczona, a drobne zmiany sformułowania, kontekstu, szumu w tle czy zachowania użytkownika mogą z czasem dawać znacząco inne wyniki. Dlatego same konwencjonalne testy nie wystarczą: agent może bezbłędnie przejść setki przypadków testowych, a mimo to zawieść na produkcji w trudny do przewidzenia sposób. 

Opóźnienie w tej warstwie jest też mniej deterministyczne. Zależy od czasu inferencji modelu, dodawania artefaktów dźwiękowych, łańcuchów wywołań narzędzi oraz zmienności typowej dla systemów generatywnych. Dobre zarządzanie tymi komponentami wymaga innej dyscypliny: ram ewaluacji, monitorowania produkcji i gotowości do ciągłego iterowania na podstawie danych z prawdziwych rozmów, a nie tylko założeń sprzed wdrożenia.

To rozróżnienie określa, jak organizacje powinny podchodzić do wdrożenia: zacząć od zastosowań ważnych dla firmy, lecz niskiego ryzyka, a następnie celowo skalować rozwiązanie wraz ze wzrostem zaufania do systemu.

Cykl wdrożeniowy

Wybór pionierów

Dla zespołów, które zaczynają wdrażać agentów głosowych, wybór właściwych pionierskich zastosowań jest jedną z najważniejszych decyzji na początku. Ma też mniej wspólnego z technologią, niż większość osób się spodziewa. Zespoły, które szybko odnoszą sukcesy i unikają niekończącej się otchłani POC, zwykle mają coś wspólnego: potrafią jasno odpowiedzieć na poniższe pytania.

• Jak ten przypadek użycia tworzy mierzalną wartość biznesową? Na początek najlepiej wybrać nie najbardziej interesujący technicznie przypadek, lecz ten, który najpewniej wpłynie na wynik, na którym firmie już zależy. Mierzy się go wpływem na przychody, redukcją kosztów, satysfakcją klientów lub innymi wskaźnikami, które liderzy już śledzą i za które odpowiadają. Bez bezpośredniego związku z wartością biznesową trudno uzasadnić cykle iteracji potrzebne do dopracowania agenta, a tempo prac prawdopodobnie spadnie, zanim technologia zdąży się sprawdzić.
• Czy użytkownicy od razu rozumieją zakres i cel agenta? Niejasny zakres to jedno z najczęstszych źródeł dryfu między etapem tworzenia a produkcją. Użytkownicy, którzy nie rozumieją, co agent może, a czego nie może zrobić, będą testować jego granice w sposób, którego zestaw ewaluacyjny nie przewidział. Agent z jasno określonym zakresem od pierwszej wiadomości ustala oczekiwania i sprawnie obsługuje prośby wykraczające poza jego zakres. 
• Jak wyglądają dobre i złe interakcje oraz czy można ująć je w konkretny zestaw kryteriów ewaluacji? Dobra interakcja to nie tylko taka, w której agent wykonuje zadanie. To także taka, w której użytkownik czuje się wysłuchany, eskalacja następuje we właściwym momencie, a rezultat jest zgodny z intencją biznesową. Kryteria ewaluacji dzielą się na dwie kategorie: metryki ilościowe zbierane przez platformę, takie jak wskaźnik realizacji zadań i wskaźnik eskalacji, oraz kryteria oparte na transkrypcji, które wymagają analizy samej rozmowy. Wczesne zdefiniowanie tych drugich daje zespołowi konkretny cel. Wyznaczają też naturalny próg uruchomienia produkcyjnego. Gdy agent stale spełnia kryteria ewaluacji, a metryki platformy się stabilizują, możesz pewnie przejść na produkcję. Bez określonych kryteriów uruchomienie produkcyjne jest kwestią oceny.
• Jakie są kompromisy między wydajnością a kontrolą i co jest ważniejsze na tym etapie? Im więcej autonomii ma agent, tym bardziej naturalne i elastyczne są interakcje, ale tym większe ryzyko działania poza sprawdzonymi granicami. Silniejsza kontrola dzięki ograniczonym promptom i bardziej rygorystycznej logice eskalacji zmniejsza to ryzyko, ale agent może wydawać się sztywny. Żadna skrajność nie jest właściwa. Organizacje, które zbyt wcześnie wszystko blokują, kończą z rozbudowanym IVR. Te, które działają zbyt szybko, zanim zbudują zaufanie, tworzą obciążenie dla wsparcia większe niż zyski. Zrozumienie, gdzie ustawić ten suwak na każdym etapie dojrzałości, wpłynie na konfigurację modelu, logikę eskalacji i zakres wiedzy agenta zawartej w prompcie zamiast w pobranych lub ustrukturyzowanych źródłach.

Po odpowiedzi na te pytania organizacja może przejść od strategii do działania i zacząć określać zakres wdrożenia.

Ugruntowanie pierwszego wdrożenia 

Przechodząc do realizacji, zespoły mogą czerpać z metodologii niemal tak starych jak samo oprogramowanie. Test Driven Development (TDD) daje strukturę, która pozwala utrzymać zgodność agentów z kluczowymi metrykami przez cały proces tworzenia.

W praktyce zespoły deweloperskie i interesariusze biznesowi powinni wspólnie zdefiniować i stworzyć dwa podstawowe elementy: Kryteria oceny sukcesu, które określają, jak wygląda dobry rezultat zarówno dla pojedynczej rozmowy, jak i w ujęciu zbiorczym, oraz Testy agentów, które wielokrotnie sprawdzają konkretne zachowania oczekiwane od agenta. Pierwszy element najlepiej oprzeć na analizie prawdziwych rozmów z konsultantami, gdy tylko będą dostępne. Drugi tworzy się stopniowo: od początkowego zestawu oczekiwanych zachowań, rozszerzanego wraz z dodawaniem nowych i odkrywaniem przypadków brzegowych. 

Mając początkowy zestaw testów, rozwój agenta zaczyna się od promptu systemowego. To tutaj określa się jego zasady, ton i sposób działania: co powinien robić, czego nie powinien i jak zachowywać się na granicach swojej roli. Dobry prompt systemowy zależy tak samo od struktury, jak od treści. Podział instrukcji na jasno oznaczone sekcje, trzymanie powiązanych wytycznych razem i unikanie warunkowych sformułowań znacząco zwiększają spójność zachowania agenta. Na tym etapie często wracamy do przewodnika po promptach.

Równolegle z promptem systemowym konfiguruje się kluczowe komponenty agenta: LLM, model zamiany tekstu na mowę (TTS) i głos. Wybór LLM to przede wszystkim kompromis między opóźnieniem a wydajnością: modele zoptymalizowane pod szybkość zwykle rezygnują z części zdolności rozumowania i odwrotnie. W przypadku TTS, właściwy wybór zależy od najważniejszych wymagań danego zastosowania — ekspresyjności, niskiego opóźnienia lub obsługi wielu języków. Głos jest jednak decyzją zarówno techniczną, jak i związaną z marką. Kształtuje sposób, w jaki organizacja jest odbierana przez każdego rozmówcę, dlatego to jedna z nielicznych decyzji konfiguracyjnych, która należy w równym stopniu do zespołów marki i marketingu, jak do inżynierów budujących agenta. Wybór głosu może więc przebiegać równolegle z resztą prac, zamiast tworzyć wąskie gardło na początku lub końcu procesu. ElevenAgents zapewnia dostęp do ponad 10 000 głosów, a jeśli żaden nie pasuje, zespoły mogą sklonować lub stworzyć własny.

Następnie agenta można opcjonalnie rozszerzyć o Bazę wiedzy, narzędzia i konfiguracje kanałów. Każdy dodatek otwiera nowe możliwości, ale też poszerza zakres wymagający testów. Niezależnie od tego, czy chodzi o integrację telefoniczną, dostęp do zewnętrznych baz danych czy możliwość działania w imieniu klienta, przed rozszerzeniem zakresu warto sprawdzić te decyzje pod kątem kryteriów ewaluacji. Po dodaniu narzędzi prompt systemowy i opis narzędzia jasno określają, kiedy i jak należy ich używać, by agent robił to konsekwentnie i we właściwym kontekście.

Po stworzeniu tych podstaw agent jest gotowy do testów.

Gotowość do produkcji

Gdy testy i kryteria ewaluacji zdefiniowane na etapie przygotowania działają już na zbudowanym agencie, proces staje się zamkniętą pętlą: dodaj kolejne testy, znajdź błędy, zaktualizuj prompt systemowy lub konfigurację i uruchom ponownie. Większość błędów na tym etapie nie wynika z modelu, lecz z promptu. Instrukcja, która w izolacji wydawała się jasna, okazuje się niejednoznaczna, gdy agent napotyka ją w środku rozmowy. Pojawiają się przypadki brzegowe, których początkowy zestaw testów nie przewidział. Każdy z nich staje się nowym testem Next Turn, tworzonym na podstawie samej rozmowy. Pytanie, kiedy zakończyć iteracje, ma konkretną odpowiedź: gdy agent konsekwentnie spełnia kryteria ewaluacji w wielu uruchomieniach, a metryki platformy, takie jak wskaźnik realizacji zadań i eskalacji, ustabilizowały się w akceptowalnych zakresach. Dlatego tak ważne jest określenie tych kryteriów przed rozpoczęciem prac. Bez nich gotowość staje się kwestią oceny, a meta ciągle się przesuwa.

W praktyce większość zespołów zauważa, że za większość problemów odpowiada niewielki zbiór powtarzających się wzorców błędów. Najczęstsze to niejednoznaczność promptu, gdy agent otrzymuje sprzeczne lub zbyt ogólne instrukcje i przechodzi na nieprzewidywalne zachowanie; niewłaściwe użycie narzędzi, gdy agent wywołuje narzędzie w złym kontekście lub nie wywołuje go, choć powinien; oraz dryf eskalacji, gdy agent albo eskaluje zbyt agresywnie, albo zatrzymuje rozmowy, które powinien przekazać dalej. Każdy z tych problemów można rozwiązać na poziomie promptu. Zwykle wystarczy doprecyzować instrukcję, dodać wyraźny przykład lub zmienić próg eskalacji. Ryzyko polega na tym, by wykryć je przed uruchomieniem produkcyjnym.

Najczęstszy błąd zespołów polega na traktowaniu pozytywnego wyniku zestawu testów jak gwarancji, a nie sygnału. Zestaw obejmujący tylko idealny scenariusz łatwo przejdzie testy i niewiele z tego wynika. Wiarygodność wynikom daje pokrycie odmów, zmian kierunku w środku rozmowy, niejednoznacznych danych wejściowych i interakcji intensywnie korzystających z narzędzi. Podobnie zespoły, które pomijają testy symulacyjne i opierają się wyłącznie na testach pojedynczych tur, nie zauważają klasy błędów widocznych dopiero w całej rozmowie, takich jak dryf kontekstu, gdy agent gubi wcześniejsze tury, czy kumulujące się błędy, gdy małe potknięcie na początku rozmowy prowadzi do złego wyniku. Gdy powtarzające się wzorce błędów zostaną rozwiązane, a agent sprawnie — choć nie idealnie — radzi sobie z długim ogonem przypadków brzegowych, dodatkowe iteracje w środowisku stagingowym przynoszą coraz mniej korzyści. Wtedy cenniejszym sygnałem stają się prawdziwe rozmowy.

Uruchomienie produkcyjne nie oznacza końca iteracji. Oznacza, że źródło nauki przenosi się z testów syntetycznych na transkrypcje z produkcji. Kryteria ewaluacji, które określiły gotowość do uruchomienia, stają się punktem odniesienia do pomiaru działania na żywo, a cykl trwa dalej.

Pętle informacji zwrotnej, ewaluacja i moment zakończenia iteracji

Gdy testy są już zdefiniowane i działają, luki w procesie szybko stają się widoczne. Dzięki Analizie rozmów zespoły mogą wskazać dokładny moment, w którym interakcja poszła źle, i wykorzystać ten sygnał do stworzenia nowego testu oraz określenia potrzebnych zmian. Najczęstsze działania dotyczą promptów: doprecyzowanie opisów wywołań narzędzi, dodanie wyraźniejszych instrukcji dla przypadków brzegowych lub wyjaśnienie warunków eskalacji, które w praktyce okazały się niejednoznaczne. Czasem problem leży głębiej i trzeba wrócić do konfiguracji modelu bazowego, jeśli opóźnienie lub jakość rozumowania nie spełniają wymagań danego zastosowania. 

Najważniejszą zasadą na tym etapie jest weryfikowanie zmian, zamiast zakładania, że działają. Poprawka rozwiązująca jeden błąd może po cichu wprowadzić inny. ElevenAgents obsługuje wersjonowanie, więc zespoły mogą testować nowe iteracje na niewielkim odsetku użytkowników, zanim udostępnią je szerszej grupie. Dzięki temu można potwierdzić, że zmiany rzeczywiście poprawiają wyniki, zamiast tylko przenosić problem w inne miejsce.

Co może pójść nie tak

Najpoważniejszym błędem na tym etapie jest pominięcie wdrożeń rozgałęzionych i skierowanie zmian bezpośrednio do wszystkich użytkowników. Bez etapowego wdrażania tracisz możliwość odizolowania wpływu konkretnej zmiany, a przy dużej skali niemal nie sposób zrozumieć, co naprawdę poprawia lub pogarsza metryki platformy. Traktowanie całej bazy użytkowników jako środowiska testowego jest nie tylko ryzykowne — pozbawia cię obserwowalności potrzebnej do pewnego podejmowania kolejnych decyzji. 

Poza strategią wdrażania warto chronić się przed jeszcze dwoma typami błędów. Pierwszy to nadmierne skupienie na ostatnich awariach. Gdy ważna rozmowa pójdzie źle, naturalnym odruchem jest natychmiastowe i szerokie wprowadzenie poprawki, ale reaktywne zmiany promptu bez uruchomienia pełnego zestawu testów często powodują regresje w zachowaniach, które wcześniej były stabilne. Każdą zmianę, nawet drobną, należy traktować jako nową iterację i odpowiednio testować. Drugi problem to dryf ewaluacji. Z czasem zespoły mogą nieświadomie obniżać próg zaliczenia testu, zwłaszcza pod presją wdrożenia. Kryteria ewaluacji określone podczas ustalania zakresu powinny pozostać punktem odniesienia. Jeśli zaczynają wydawać się zbyt restrykcyjne, należy je przeanalizować i celowo zaktualizować, a nie pozwalać na nieformalne obniżanie standardów.

Skalowanie z pewnością

Zwiększenie ruchu to decyzja oparta na pewności, nie na czasie. Sygnałem do rozszerzenia wdrożenia jest konsekwentne spełnianie przez agenta kryteriów ewaluacji w wielu uruchomieniach testów, stabilizacja metryk platformy oraz brak istotnej regresji względem grupy kontrolnej w rozgałęzionych wdrożeniach. 

Częste pytanie na tym etapie brzmi: ile ruchu wystarczy, by wyciągnąć wnioski? Partie liczące mniej niż 100 połączeń na gałąź generują zbyt dużą zmienność, by rzetelnie ocenić wyniki. Wskaźnik zaliczenia 60% przy 25 połączeniach i 60% przy 100 połączeniach oznacza zupełnie inny poziom pewności. Poza ustaloną liczbą partia powinna być też wystarczająco duża, by ujawnić pełny zakres realistycznych danych wejściowych, w tym prawdopodobne przypadki brzegowe, rzadkie intencje i tryby awarii pojawiające się dopiero przy większym ruchu, a rzadko w małych próbach.

Większy ruch wzmacnia zarówno to, co działa, jak i to, co nie działa. Rozszerzanie wdrożenia przed rozwiązaniem kluczowych wzorców błędów tworzy obciążenie dla wsparcia, które trudno później cofnąć.

Powtarzaj proces

Wiedza, kiedy się zatrzymać, jest równie ważna jak wiedza, co naprawić. Korzyści z kolejnych iteracji maleją, a właściwym sygnałem do przerwy jest konsekwentne spełnianie przez agenta kryteriów ewaluacji określonych podczas ustalania zakresu. Wtedy kolejne zmiany niosą więcej ryzyka niż korzyści. 

To, jak wygląda „konsekwentne spełnianie kryteriów”, zależy od kontekstu. Zespoły z ograniczonym dostępem do danych lub niepełnymi integracjami mogą uznać wskaźnik eskalacji na poziomie około 50% za realistyczny limit, dopóki te ograniczenia nie zostaną usunięte. Tam, gdzie dostęp do danych jest dobry, najlepiej działające wdrożenia zwykle dążą do realizacji zadań powyżej 80% i eskalacji poniżej 20%. Ważniejsza od pojedynczej liczby jest stabilność: stałe wyniki przez kilka tygodni ruchu produkcyjnego, bez istotnej regresji w kolejnych testach, są prawdziwym sygnałem. Gdy marginalna korzyść z następnej iteracji jest mniejsza niż ryzyko regresji, pora się zatrzymać.

Nie oznacza to, że praca jest skończona. Gdy pojawią się nowe wymagania, proces zaczyna się od początku. Pytania dotyczące zakresu z pierwszego wdrożenia pozostają równie ważne przy drugim. Różnica polega na tym, że zespoły rozpoczynające drugi cykl mają już zestaw testów, bazowy poziom ewaluacji i doświadczenie operacyjne, które w pierwszym cyklu trzeba było stworzyć od zera. Ta narastająca przewaga odróżnia organizacje, które czerpią trwałą wartość z agentów głosowych agentów od tych, które pozostają na etapie proof of concept.

Podsumowanie

Zespoły, które widzieliśmy zamykające lukę między deflectionem a rozwiązaniem problemu, najpierw definiują, jak wygląda dobry rezultat, zachowują dyscyplinę przez cały cykl iteracji i traktują każde wdrożenie jako podstawę kolejnego. Agenci konwersacyjni nie są wdrażani tylko raz — prawdziwe rozmowy ujawniają przypadki brzegowe, których żaden zestaw testów w pełni nie przewidzi, a praca nad ulepszaniem nie kończy się wraz z uruchomieniem produkcyjnym.

ElevenAgents powstało z myślą o tej rzeczywistości. Testy agentów, Analiza rozmów i rozgałęzione wdrożenia tworzą podstawę, która zmienia proof of concept w system faktycznie rozwiązujący problemy klientów na dużą skalę — a nie tylko przekierowujący ich. To luka, którą warto zamknąć.