Kwadrans przed otwarciem ktoś w biurze odpisuje na pytanie o godziny otwarcia w sobotę. Wczoraj odpisywał na to samo pytanie, jutro odpisze znowu. Ta praca niczego nie buduje.
Chatboty mają tutaj złą reputację. Uzasadnioną. Standardowe rozwiązania odpowiadają z ogólnej wiedzy modelu zamiast z polityki konkretnej firmy. Klient pyta o termin zwrotu, bot cytuje unijne przepisy zamiast faktycznego regulaminu. Albo coś wymyśla. Obawa właściciela jest konkretna: wolę odpowiadać sam, niż żeby AI napisało klientowi głupoty.
Szósty wpis tej serii opisuje workflow zbudowany pod tę obawę. Model AI wchodzi późno i dostaje bardzo mało swobody. Każdy szkic odpowiedzi czeka na zatwierdzenie przez człowieka, a ta bramka siedzi w samej budowie grafu.
Jak przebiega obsługa pytania klienta
Pytanie klienta trafia najpierw do etapu normalizacji. Normalizer redaguje rozpoznane wzorce adresów mailowych, numerów telefonów, tokenów i numerów IBAN. Nie gwarantuje to usunięcia wszystkich danych wrażliwych. Oznacza też znane wzorce manipulacji do przeglądu. Samo oznaczenie nie zatrzymuje wywołania modelu, jeśli pytanie pasuje do bazy wiedzy.
Potem następuje dopasowanie do zamkniętej bazy wiedzy - zestawu wpisów, który firma sama buduje i aktualizuje. Godziny otwarcia, warunki zwrotów, polityka reklamacyjna, cennik. Próg dopasowania wynosi 0,45. Jeśli pytanie nie pasuje do żadnego wpisu z wystarczającą pewnością, trafia do kolejki eskalacji i czeka na człowieka. System nie zgaduje. Model przy takim pytaniu w ogóle nie jest wołany.
Przy dopasowaniu model AI dostaje tekst jednego dopasowanego wpisu i oczyszczone pytanie klienta. Instrukcja każe oprzeć odpowiedź na tym źródle. Walidator sprawdza potem, czy szkic wskazuje identyfikator właściwego wpisu, deklaruje pewność co najmniej 0,62 i nie zawiera znanych fraz ujawniających konfigurację ani prób zlecania akcji zewnętrznych. Sam poprawny identyfikator źródła nie dowodzi jednak zgodności każdego zdania z bazą. Dlatego treść nadal sprawdza człowiek.
Szkic, który przeszedł walidację, trafia do kolejki przeglądu i wyzwala powiadomienie mailowe. Zatwierdzenie odbywa się przez osobny webhook z własnym tokenem i autoryzacją. Decyzja "approve" lub "edit" dla zgłoszenia w stanie "Draft Ready" wysyła zatwierdzoną treść na skonfigurowany adres. Żądanie musi zawierać tę treść, liczącą co najmniej 20 znaków; zapisany szkic nie jest wysyłany domyślnie. Decyzje "reject" i "escalate" zapisują wynik przeglądu bez wysyłki odpowiedzi.
Zatwierdzenie jest wbudowane w architekturę grafu. Graf przyjmowania pytań nie ma połączenia z węzłem wysyłki zatwierdzonej odpowiedzi. Widać to w tablicy połączeń w pliku workflow.json: ten węzeł uruchamia osobny webhook zatwierdzenia. Intake może natomiast wysyłać wewnętrzne powiadomienia o szkicu lub eskalacji. Ograniczenie dotyczy więc odpowiedzi, a nie całej korespondencji wysyłanej przez workflow.
Adresaci są stałymi w konfiguracji. Adres odbiorcy jest ustawiony raz, w konfiguracji grafu. Nic z treści pytania ani z wyjścia modelu nie wybiera odbiorcy. Próba wymuszenia wysyłki na inny adres nie ma gdzie zadziałać, bo odbiorca nie pochodzi z żadnego dynamicznego źródła.
Obrona przed manipulacją jest warstwowa. Tekst klienta jest traktowany jako dane zewnętrzne na każdym etapie grafu. Normalizer redaguje wrażliwe fragmenty i flaguje znane wzorce injection. Instrukcja systemowa modelu mówi wprost, że treść klienta to dane, nie polecenia do wykonania. Walidator odrzuca szkice zawierające podejrzane frazy lub próby wywołania akcji zewnętrznych. Człowiek przegląda każdy szkic przed wysyłką. Żadna z tych warstw nie jest jedyną linią obrony.
Co jest w repozytorium
Szablon jest dostępny bezpłatnie:
Pobierz szablon obsługi pytań klientów z GitHuba.
To jeden z ośmiu szablonów n8n opublikowanych z katalogu 14.
Granice wersji z repo:
Baza wiedzy to demo z czterema przykładowymi wpisami. Na etapie produkcyjnym trzeba ją zbudować z prawdziwych pytań i odpowiedzi, z przypisanym właścicielem, datami przeglądu i procesem aktualizacji, gdy zmienia się oferta albo procedury. Pytania, na które system eskaluje, to sygnał o lukach w bazie - warto je zbierać i uzupełniać.
Szablon nie jest podłączony do realnej skrzynki mailowej. Intake działa przez webhook. Zatwierdzone odpowiedzi trafiają na jeden skonfigurowany adres testowy, nie do oryginalnego klienta. Przepięcie do właściwej skrzynki wsparcia to osobna, świadoma decyzja konfiguracyjna - szablon tego za klienta nie zrobi.
Kiedy szablon nie wystarcza
Sam szablon to dobry punkt do sprawdzenia, czy taki model pracy ma sens w konkretnej firmie. Praca produkcyjna zaczyna się po imporcie.
Ktoś musi zbudować bazę wiedzy i ta praca nie kończy się przy wdrożeniu. Baza wymaga właściciela, który ją aktualizuje, gdy zmienią się godziny otwarcia, regulamin, cennik. Pytania eskalowane czytaj jako listę brakujących wpisów.
Trzeba też zdecydować, który kanał zgłoszeń zasila workflow, jak wygląda zatwierdzanie, gdy w biurze jest kilka osób, i co dzieje się z eskalacjami. Czy trafiają do jednej skrzynki, czy do systemu ticketowego.
Jeśli firma odpowiada na te same pytania w kółko - agencja usługowa, serwis techniczny - warto zmierzyć, ile czasu tygodniowo to pochłania, zanim zdecydujesz o automatyzacji.
Wdrożenie produkcyjne opisuję na karcie asystenta odpowiedzi. Stronę kosztową takiego wdrożenia znajdziesz we wpisie ile kosztuje automatyzacja procesów.
Bezpłatną diagnozę dla konkretnych procesów w firmie możemy przeprowadzić przez formularz kontaktowy.
Wróć na początek ↑