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. Potencjalnie wrażliwe fragmenty są redagowane: adresy mailowe, numery telefonów, ciągi wyglądające jak tokeny albo numery IBAN. Normalizer sprawdza tekst pod kątem znanych wzorców manipulacji; jeśli wykryje coś podejrzanego, pytanie trafia do eskalacji, zanim gdziekolwiek dotrze.
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 wyłącznie tekst tego jednego dopasowanego wpisu i oczyszczone pytanie klienta. Reszta bazy i ogólna wiedza modelu zostają za drzwiami. Walidator sprawdza potem, czy szkic faktycznie powołuje się na dopasowany wpis przez jego identyfikator. Gdy model próbuje odpowiedzieć "ze swojej głowy", walidator to wykrywa i odrzuca szkic. Wymaga też pewności co najmniej 0,62 i sprawdza, czy szkic nie zawiera fraz ujawniających konfigurację systemu ani nie próbuje wywołać akcji zewnętrznych.
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" wysyła odpowiedź na skonfigurowany adres. Decyzja "reject" zapisuje odrzucenie w tabeli. Nic nie wychodzi bez tej decyzji.
Zatwierdzenie jest wbudowane w architekturę grafu. Graf przyjmowania pytań i węzeł wysyłki są fizycznie rozłączone. Ścieżka od pytania klienta do wysłania czegokolwiek nie istnieje w grafie intake. Widać to bezpośrednio w pliku workflow.json, w tablicy połączeń między węzłami. Tylko webhook zatwierdzenia może uruchomić węzeł wysyłki. Żadna manipulacja treścią pytania klienta nie może tego zmienić, bo ścieżki po prostu nie ma.
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:
https://github.com/kuliberdalabs/n8n-sme-workflows/tree/main/workflows/04-support-triage
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 /automatyzacje/asystent-odpowiedzi. Stronę kosztową takiego wdrożenia znajdziesz we wpisie /blog/ile-kosztuje-automatyzacja-procesow.
Bezpłatną diagnozę dla konkretnych procesów w firmie możemy przeprowadzić przez /kontakt.