Mail gotowy. Ale jeszcze go nie wysyłamy
Wyobraźcie sobie, że otwieracie zgłoszenie klienta, a obok czeka już szkic odpowiedzi. AI zebrało kontekst i pomogło napisać wiadomość. Wy porównujecie ją z pytaniem, sprawdzacie odbiorcę i decydujecie o wysyłce. Tak proponujemy zacząć automatyzację obsługi: od konkretnej pomocy, którą można obejrzeć przed użyciem.
W n8n służy do tego przegląd wywołań narzędzi agenta. Brzmi technicznie, ale zasada jest prosta: wskazane działanie czeka na decyzję człowieka. Według dokumentacji zatwierdzenie pozwala uruchomić narzędzie z przygotowanymi parametrami, a odrzucenie anuluje akcję. Na tym oprzemy nasz proces.
Co dokładnie zatwierdzamy?
Nad przyciskiem akceptacji pokażcie odbiorcę, temat, całą wiadomość, powód jej przygotowania i link do zgłoszenia. Jeśli klient pyta o termin, trzeba móc porównać jego pytanie z odpowiedzią. Szukanie tego po kilku systemach szybko odbierze sens pomocy przy pisaniu.
Zmienna $tool udostępnia w n8n nazwę narzędzia i parametry wywołania. Możecie z nich zbudować komunikat dla osoby zatwierdzającej. Nie zastępujcie pełnej treści samym streszczeniem wygenerowanym przez model: mogło zgubić adres albo jedno ważne zdanie.
Jeśli w wiadomości pojawiają się kwota, termin lub załącznik, wyróżnijcie je. To dobry moment, żeby zajrzeć do zgłoszenia, a nie dopiero do wysłanego maila. Całą ścieżkę możemy rozpisać tak:
A jeśli klikniemy „nie”?
Odrzucony szkic może zostać do ręcznej edycji. Można też poprosić AI o kolejną wersję, ale ją również trzeba pokazać do zatwierdzenia. Zgoda na wcześniejszą wiadomość nie obejmuje zdania, które model dopisze chwilę później.
Pozostaje jeszcze cisza. Nikt nie kliknął, sprawa czeka. Ustalcie, czy ma czekać dalej, czy wrócić do zwykłej kolejki obsługi. Brak odpowiedzi nie powinien przez przypadek zamienić się w zgodę na wysyłkę. Zapiszcie tę ścieżkę i przejdźcie ją na testowym zgłoszeniu.
Jeden klient nie potrzebuje dwóch takich samych maili
Przed podłączeniem skrzynki klientów użyjcie testowego odbiorcy. Przejdźcie zgodę, odmowę, brak decyzji i ponowne uruchomienie tej samej sprawy. Przy tym ostatnim wyobraźcie sobie konkretną awarię: mail wyszedł, ale proces przerwał się przed zapisaniem wyniku. Kolejna próba nie powinna wysłać go jeszcze raz. Ochronę przed duplikatami projektujemy osobno; sam przycisk zatwierdzania jej nie zapewni.
Przy okazji zobaczcie, ile pracy wymaga przejrzenie szkicu. Jeśli za każdym razem trzeba odszukać tę samą informację, przenieście ją na ekran decyzji. Jeśli stale poprawiacie jedno zdanie, wróćcie do instrukcji przygotowania odpowiedzi. Właśnie takie drobne poprawki będzie czuć przy następnej wiadomości.
Źródła i dalsza lektura
Materiały, na których opiera się ten tekst. Instrukcje i przykładowe scenariusze są propozycjami redakcji.