Przepływ agenta AI dla obsługi zgłoszeń projektuje się w sześciu krokach: określ wyzwalacz, skataloguj typy zgłoszeń, wyznacz granice decyzji agenta, zaprojektuj sygnał eskalacji, zbuduj punkt przekazania z pełnym kontekstem i przetestuj wszystko na historycznych zgłoszeniach, zanim proces trafi na produkcję.

Krok 1 — Zdefiniuj wyzwalacz i źródła zgłoszeń

Zacznij od odpowiedzi, skąd w ogóle biorą się zgłoszenia, którymi ma zająć się agent: system ticketowy, skrzynka mailowa, formularz na stronie, czat na żywo. Jeśli źródeł jest kilka, ustal, czy trafiają do jednej kolejki, czy agent ma osobno obsługiwać każdy kanał — to wpływa na to, jak dużo kontekstu (historia klienta, wcześniejsze zgłoszenia) agent dostaje od razu na wejściu.

Warto też od razu zapisać, co dzieje się z priorytetem zgłoszenia — czy agent uruchamia się dla wszystkich zgłoszeń w kolejności napływu, czy istnieje osobna ścieżka dla klientów o wyższym priorytecie (np. z aktywną umową enterprise). Pominięcie tego pytania na starcie zwykle wraca jako pytanie od zespołu dopiero po wdrożeniu, kiedy zmiana kosztuje więcej.

Krok 2 — Skataloguj typy zgłoszeń i ustal, które są „standardowe"

Przejrzyj kilkadziesiąt do kilkuset ostatnich zgłoszeń i pogrupuj je w kategorie: pytania o status zamówienia, reklamacje, prośby o zwrot, pytania techniczne, sprawy nietypowe. Dla każdej kategorii zapisz, jaki odsetek zgłoszeń dziś obsługiwany jest bez eskalacji — to Twój punkt odniesienia. Kategorie, które w praktyce zawsze trafiają do człowieka (np. spory prawne), od razu wyłącz z zakresu agenta.

Ten katalog warto spisać razem z zespołem obsługi, nie tylko na podstawie danych z systemu ticketowego — osoby na pierwszej linii często wiedzą, które „standardowe" zgłoszenia mają w rzeczywistości nietypowe warianty, których statystyka nie pokazuje wprost.

Krok 3 — Wyznacz granice decyzji agenta

Dla każdej „standardowej" kategorii ustal konkretne, sprawdzalne warunki, w jakich agent może odpowiedzieć samodzielnie: górny limit kwoty zwrotu, zakres statusów zamówienia, lista tematów pokrytych bazą wiedzy. Unikaj granic opisowych typu „proste pytania" — zamień je na reguły, które da się sprawdzić automatycznie (kwota, kategoria, obecność słów kluczowych).

Krok 4 — Zaprojektuj sygnał eskalacji

Sygnał eskalacji to odwrotność granicy z kroku 3: konkretny warunek, po którym agent ma przestać działać samodzielnie. W praktyce dobrze sprawdzają się trzy typy sygnałów: przekroczenie progu liczbowego (kwota, czas oczekiwania), brak dopasowania w bazie wiedzy oraz wzorce językowe wskazujące na frustrację lub groźbę eskalacji ze strony klienta („chcę rozmawiać z kimś innym", „to już trzeci raz piszę"). Każdy sygnał powinien dać się przetestować na przykładach z kroku 2.

Krok 5 — Zbuduj punkt przekazania z pełnym kontekstem

Punkt przekazania to nie tylko adres kolejki — to konkretny pakiet informacji, jaki dostaje osoba przejmująca sprawę: cała historia rozmowy (nie tylko ostatnia wiadomość), dane klienta, powód eskalacji zapisany w jednym zdaniu i to, co agent już sprawdził albo zaproponował. Im mniej pracy musi wykonać człowiek, żeby zrozumieć kontekst, tym mniejsze ryzyko, że eskalacja zostanie zignorowana albo obsłużona później niż trzeba.

Krok 6 — Testuj na historycznych zgłoszeniach przed wdrożeniem produkcyjnym

Zanim przepływ zacznie obsługiwać realne zgłoszenia, przepuść go przez zestaw historycznych przypadków z kroku 2 — łącznie z tymi, które wcześniej wymagały eskalacji. Sprawdź nie tylko, czy odpowiedzi agenta są poprawne, ale też czy sygnał eskalacji faktycznie się uruchamia tam, gdzie powinien. Fałszywie rzadka eskalacja jest gorsza niż fałszywie częsta — kosztuje zaufanie zespołu i klientów, nie tylko czas.

Dobrą praktyką jest uruchomienie przepływu równolegle do istniejącego procesu przez pierwsze dwa–trzy tygodnie: agent proponuje odpowiedź, ale nie wysyła jej samodzielnie, a zespół porównuje jego decyzje z tym, co zrobiłby człowiek. Rozbieżności w tym okresie są najcenniejszym źródłem informacji o tym, gdzie granice trzeba doprecyzować, zanim przepływ zacznie działać w pełni samodzielnie.

Najczęstsze błędy przy projektowaniu tego przepływu

  • Zbyt szerokie granice na start. Łatwiej rozszerzać zakres decyzji agenta niż go zawężać po incydencie, który już wyszedł na jaw.
  • Testowanie tylko na przypadkach typowych. To właśnie wyjątki decydują, czy przepływ się sprawdzi.
  • Powiadomienie zamiast kontekstu w punkcie przekazania. Sama informacja „zgłoszenie #482 wymaga uwagi" bez historii rozmowy przenosi pracę z powrotem na człowieka.

Ile trwa wdrożenie takiego przepływu

Sam opis przepływu — kroki 1–4 — to zwykle kilka dni pracy zespołu, który zna proces od środka: osoby z obsługi klienta, kogoś z zespołu technicznego i osoby odpowiedzialnej za politykę zwrotów czy reklamacji. Krok 5 (integracja z systemem ticketowym) i krok 6 (testy na danych historycznych) zależą już od stosu technicznego, ale rzadko trwają dłużej niż projektowanie samych granic. Najczęstszym wąskim gardłem nie jest kod, tylko czas potrzebny na uzgodnienie progów między działami — np. ile dokładnie wynosi górna kwota zwrotu, którą agent może zatwierdzić bez pytania nikogo.

Czy trzeba objąć przepływem wszystkie typy zgłoszeń naraz? Nie — bezpieczniej zacząć od jednej, dobrze zrozumianej kategorii (np. pytania o status zamówienia), sprawdzić działanie sygnału eskalacji na żywych danych, a dopiero potem rozszerzać zakres o kolejne typy zgłoszeń.

Zanim zaczniesz projektować ten przepływ, warto ustalić samo pojęcie granic i punktu przekazania — opisaliśmy je w artykule Czym jest przepływ agentowy (agentic workflow)?. O tym, kiedy dokładnie sprawa powinna wracać do człowieka, piszemy szerzej w Human-in-the-loop w przepływach agentowych.