Pilotaż agenta AI: 1 proces, 2-4 tygodnie, jasny KPI (i jak zdecydować: skalować czy wycofać)

Gdy klient przychodzi z pomysłem „wdrożmy agenta AI do obsługi klienta”, pierwsze pytanie, jakie zadajemy, brzmi: na którym konkretnie procesie i jak zmierzymy, że to zadziałało. Nie na pytanie, jakiego modelu użyć albo czy lepszy będzie GPT czy inny dostawca. To pytanie przychodzi później. Firmy, które od razu podłączają agenta do wszystkich skrzynek mailowych, czatu na stronie i infolinii, zwykle po trzech miesiącach mają gorszy obraz sytuacji niż przed startem: więcej eskalacji, sfrustrowanych klientów i zespół, który nie ufa narzędziu. Pilotaż na jednym procesie to nie jest ostrożność dla ostrożności. To sposób, żeby błąd kosztował tydzień pracy, a nie kwartał budżetu i reputację firmy wobec klientów.

Dlaczego nie wdrażamy agenta wszędzie naraz

Agent AI, nawet dobrze skonfigurowany, uczy się specyfiki danej firmy dopiero na realnych danych i realnych przypadkach brzegowych. Dokumentacja produktowa, baza wiedzy, ton komunikacji, wyjątki od reguł: to wszystko trzeba przetestować na mniejszej próbce, zanim puści się ruch produkcyjny. Jeśli od razu obsługuje pięć kanałów i trzydzieści typów zgłoszeń, trudno zidentyfikować, który element nie działa. Czy to zła konfiguracja promptu, brakujące dane w bazie wiedzy, czy po prostu proces, który od początku był zbyt skomplikowany dla automatyzacji. Jeden proces daje czysty sygnał. Widać wyraźnie, co się psuje i dlaczego.

Jest też kwestia zaufania w zespole. Pracownicy, którzy mają obawę, że agent zabierze im pracę albo zepsuje relację z klientem, chętniej akceptują zmianę, gdy widzą ją na wąskim wycinku, z jasnym planem oceny, niż gdy ktoś „z góry” wdraża system na cały dział z dnia na dzień. Pilotaż to też proces budowania akceptacji, nie tylko test technologii.

Jak wybrać proces do pilotażu

Nie każdy proces nadaje się na pierwszy test. Szukamy procesu, który spełnia trzy warunki naraz: ma wysoką powtarzalność, jasne reguły decyzyjne i mierzalny wynik. Dobrym kandydatem jest na przykład obsługa pytań o status zamówienia, prostych reklamacji albo odpowiadanie na powtarzalne pytania przedsprzedażowe. Złym kandydatem na start jest proces, w którym każda sprawa jest inna, decyzje wymagają kontekstu z kilku systemów naraz albo błąd kosztuje bardzo dużo, na przykład decyzje kredytowe czy spory prawne.

Jeśli zespół obsługi klienta codziennie traci godzinę na odpowiadanie na te same pięć pytań o status przesyłki, tam szukamy pierwszego pilotażu, nie w bardziej złożonym, ale rzadszym procesie, który brzmi efektowniej w prezentacji dla zarządu. To samo dotyczy księgowości: dekretacja prostych, powtarzalnych faktur kosztowych nadaje się na pilotaż znacznie lepiej niż obsługa nietypowych transakcji wymagających interpretacji przepisów. Więcej o tym, jak wygląda to konkretnie przy fakturach, piszemy przy okazji automatyzacji faktur, a przy procesach biura rachunkowego warto spojrzeć też na automatyzację biura rachunkowego jako całość, bo pilotaż jednego procesu zwykle jest pierwszym krokiem w szerszym planie.

Framework pilotażu: 2-4 tygodnie, trzy etapy

Typowy pilotaż, jaki prowadzimy, trwa od dwóch do czterech tygodni. Krócej zwykle nie starcza na zebranie wiarygodnej próbki danych, dłużej oznacza, że ktoś się boi podjąć decyzję i przeciąga etap testowy bez konkretnego powodu. Dzielimy ten czas na trzy etapy.

Etap 1: konfiguracja i dane testowe (dni 1-5)

Na tym etapie agent nie dotyka jeszcze realnych klientów. Konfigurujemy go na historycznych danych: zgłoszeniach z ostatnich miesięcy, fakturach z archiwum, nagraniach rozmów. Sprawdzamy, jak radzi sobie z typowymi przypadkami i z przypadkami brzegowymi, które zespół zna z doświadczenia. To moment, w którym ustala się też bazowy punkt odniesienia: ile czasu zajmuje dany proces dziś, bez automatyzacji, i jaki jest obecny poziom błędów. Bez tego punktu odniesienia żadne porównanie po pilotażu nie będzie miało sensu.

Etap 2: test na realnym ruchu z nadzorem człowieka (dni 6-15)

Agent zaczyna pracować na żywych sprawach, ale z człowiekiem w pętli. W praktyce oznacza to, że albo odpowiedzi agenta są zatwierdzane przed wysyłką, albo agent działa w pełni, ale pracownik na bieżąco przegląda próbkę jego decyzji, na przykład co piątą sprawę. To etap, w którym wychodzą prawdziwe problemy: nieoczekiwane sformułowania klientów, luki w bazie wiedzy, sytuacje, których nikt nie przewidział przy projektowaniu. Dobry pilotaż zakłada, że te problemy się pojawią, i ma na nie czas, zamiast traktować je jako powód do przerwania testu w trzecim dniu.

Etap 3: analiza wyników i decyzja (dni 16-20, do 4 tygodni)

Zbieramy dane z etapu drugiego i porównujemy je z punktem odniesienia z etapu pierwszego. Tu nie ma miejsca na wrażenia w stylu „chyba działa nieźle”. Potrzebne są konkretne liczby, o których niżej, i decyzja: skalujemy na kolejne kanały, poprawiamy konfigurację i testujemy jeszcze raz, czy rezygnujemy z tego procesu jako kandydata do automatyzacji.

Co mierzyć: trzy KPI, nie dwadzieścia

Pokusa, żeby mierzyć wszystko, jest duża, ale rozprasza decyzję. W większości pilotaży wystarczą trzy wskaźniki, śledzone konsekwentnie przez cały okres testu:

• Czas obsługi zgłoszenia: od momentu wpłynięcia sprawy do jej zamknięcia, porównany z czasem sprzed pilotażu.
• Procent spraw załatwionych bez udziału człowieka: ile zgłoszeń agent zamknął samodzielnie, bez eskalacji i bez poprawek pracownika.
• Liczba błędów i eskalacji: ile razy agent podał błędną informację, poszedł w złym kierunku albo klient musiał wracać do sprawy, bo odpowiedź go nie zadowoliła.

Te trzy liczby razem dają pełny obraz. Wysoki procent spraw załatwionych automatycznie przy dużej liczbie błędów nie jest sukcesem, tylko sygnałem, że agent działa szybko, ale źle. Krótki czas obsługi przy wysokiej liczbie eskalacji oznacza, że agent tylko przyspiesza moment, w którym sprawa i tak trafia do człowieka, czyli w praktyce nic nie automatyzuje.

Decyzja go/no-go: jak ją podejmujemy

Decyzję o skalowaniu podejmujemy dopiero wtedy, gdy mamy dane z co najmniej dwóch tygodni realnego ruchu, nie z pierwszych trzech dni. Pierwsze dni pilotażu zawsze są gorsze niż kolejne, bo agent dopiero uczy się specyfiki firmy na podstawie poprawek. Jeśli ktoś ocenia pilotaż po tygodniu i widzi słabe wyniki, często rezygnuje za wcześnie, zanim konfiguracja zdążyła się ustabilizować.

Z drugiej strony, jeśli po czterech tygodniach wyniki nadal są słabe i nie widać trendu poprawy, to nie jest moment na przedłużanie testu o kolejny miesiąc w nadziei, że samo się naprawi. Tu potrzebna jest konkretna decyzja: albo zmieniamy podejście (inny zakres procesu, inne dane, inny model), albo wracamy do procesu ręcznego i szukamy lepszego kandydata do automatyzacji. Niewdrożenie agenta tam, gdzie się nie sprawdza, to nie porażka pilotażu, tylko dokładnie jego cel. Pilotaż ma chronić firmę przed kosztownym wdrożeniem czegoś, co nie działa, nie udowadniać z góry przyjętą tezę, że agent musi zadziałać.

Najczęstsze błędy, które widzimy przy pilotażach

Pierwszy błąd to brak punktu odniesienia. Firma wdraża agenta i po miesiącu nie ma danych sprzed automatyzacji, więc nie da się nic sensownie porównać. Drugi błąd to zbyt szeroki zakres pilotażu: zamiast jednego typu zgłoszeń testuje się od razu całą obsługę klienta, co wraca do problemu opisanego na początku tego tekstu. Trzeci błąd to zbyt krótki czas bez realnego nadzoru: agent działa bez poprawek przez pierwsze dni, zbiera złe opinie klientów, zanim ktokolwiek zdąży zareagować.

Czwarty, może najbardziej kosztowny błąd, to podejmowanie decyzji o skalowaniu na podstawie wrażeń kierownictwa, a nie liczb z pilotażu. Jeśli prezentacja na zarząd wygląda dobrze, bo agent efektownie odpowiedział na trzy pytania podczas demo, to nie jest dowód, że sprawdzi się na tysiącu realnych zgłoszeń miesięcznie. Te same zasady dotyczą zresztą nie tylko obsługi klienta: przy automatyzacji obsługi klienta widzimy to najczęściej, bo tam presja na szybkie pokazanie efektu jest największa, a koszt błędu najbardziej widoczny dla klientów firmy.

Co dzieje się po udanym pilotażu

Jeśli pilotaż kończy się decyzją go, nie przechodzimy od razu do stu procent ruchu na wszystkich kanałach. Skalujemy stopniowo: najpierw drugi, podobny proces albo drugi kanał dla tego samego procesu, dalej monitorując te same trzy KPI. Dopiero gdy wyniki utrzymują się stabilnie na kolejnym etapie, mówimy o pełnym wdrożeniu w całej organizacji. To wydłuża całkowity czas projektu, ale drastycznie zmniejsza ryzyko, że skalowanie ujawni problem, którego nie było widać na małej próbce.