Chatbot HR/IT: opłaca się od 50 pracowników (i jak spiąć go z firmową dokumentacją zamiast scenariuszy)

Zanim ktokolwiek w firmie zapyta o budżet na chatbota HR, ja zapytałbym o coś innego: ile razy w zeszłym miesiącu dział kadr odpowiedział na pytanie "ile mam jeszcze dni urlopu" albo IT na "jak zresetować hasło do VPN". Jeśli nikt tego nie liczył, to pierwszy krok nie jest wyborem narzędzia, tylko audytem skrzynki hr@ i zgłoszeń z helpdesku IT z ostatnich dwóch, trzech miesięcy. W praktyce, w każdej firmie którą audytowaliśmy pod tym kątem, obraz jest bardzo podobny: te same kilkanaście pytań wraca co tydzień, tylko zadane innymi słowami przez inną osobę.

Dlaczego to nie jest projekt dla chatbota sprzedażowego

W tekstach o automatyzacji obsługi klienta chatbot zwykle sprzedaje albo odciąża konsultantów od powtarzalnych pytań klientów zewnętrznych. Tu mówimy o czymś innym: o wewnętrznym narzędziu, które ma odciążyć HR i IT od pytań własnych pracowników. Różnica jest istotna, bo zmienia się i publiczność (pracownicy, nie klienci), i źródło wiedzy (dokumenty wewnętrzne, nie baza produktowa), i konsekwencje błędu. Jeśli bot źle odpowie klientowi o promocji, to wstyd. Jeśli źle odpowie pracownikowi o liczbie dni urlopu albo procedurze L4, to realny problem kadrowy.

Branżowe dane, które się potwierdzają w naszych wdrożeniach, mówią, że 60–70% zgłoszeń do HR i IT to pytania powtarzalne, czysto informacyjne. Nie wymagają oceny, decyzji ani dostępu do poufnych danych konkretnej osoby, tylko znajomości regulaminu, polityki benefitów albo instrukcji IT. To jest dokładnie ten obszar, w którym bot ma sens. Reszta, czyli 30–40% zgłoszeń wymagających osądu, zostaje przy ludziach i tak powinno zostać.

Próg opłacalności: od ilu pracowników to w ogóle ma sens

Tu stawiam sprawę wprost: poniżej 40–50 pracowników zwykle odradzam budowę osobnego bota HR/IT. Nie dlatego, że technologia nie działa, tylko dlatego, że przy mniejszej skali liczba zgłoszeń miesięcznie (20–30 ticketów) jest zbyt mała, żeby uzasadnić koszt utrzymania infrastruktury: aktualizowania bazy wiedzy, pilnowania jakości odpowiedzi, monitorowania eskalacji. Jedna osoba z HR ogarnia to ręcznie w godzinę dziennie i nie traci na tym sensownej ilości czasu.

Matematyka zaczyna się zmieniać powyżej 50 osób w organizacji, a wyraźnie opłaca się przy 100-150+ pracownikach. Jeśli osoba w HR odpowiada codziennie na 15-20 pytań o urlopy, hasła, benefity i procedury, to w skali miesiąca jest to realnie tydzień pracy zjedzony przez rzeczy, które są gdzieś spisane, tylko nikt tego nie szuka. Bot przejmujący 60% tych zapytań oddaje HR-owcowi kilkanaście godzin miesięcznie, które można przeznaczyć na rekrutację, onboarding albo rozmowy, które faktycznie wymagają człowieka.

Architektura: bot tam, gdzie ludzie już rozmawiają

Dobry wewnętrzny helpdesk nie jest nową aplikacją, do której trzeba się osobno logować. Pracownicy mają już Slacka albo Teamsy i tam toczy się codzienna komunikacja. Bot wpięty jako integracja czatowa odpowiada wprost w kanale albo na wiadomość prywatną, bez przełączania kontekstu.

Technicznie najczęściej wygląda to tak: n8n jako warstwa orkiestracji, która odbiera pytanie, odpytuje bazę wektorową (Pinecone, Qdrant albo podobne) z zaindeksowaną dokumentacją firmową i przekazuje odpowiedni fragment do modelu językowego, który formułuje odpowiedź w naturalnym języku. To architektura RAG, czyli retrieval augmented generation: model nie zgaduje z pamięci, tylko wyszukuje konkretny fragment regulaminu czy instrukcji i na jego podstawie buduje odpowiedź.

Dla firm mocno osadzonych w ekosystemie Microsoft 365 sensowną alternatywą jest Microsoft Copilot, który ma natywną integrację z SharePoint i Teams i potrafi czerpać wiedzę bezpośrednio z firmowego intranetu bez budowania osobnej infrastruktury RAG od zera. To rozwiązanie szybsze do wdrożenia, jeśli firma już płaci za odpowiednie licencje, ale mniej elastyczne, jeśli ktoś chce dopiąć niestandardowe reguły eskalacji czy integracje z systemem kadrowym spoza ekosystemu Microsoft.

RAG zamiast sztywnych scenariuszy

Największy błąd, jaki widzieliśmy przy pierwszych podejściach firm do tego tematu, to próba zbudowania bota na drzewku decyzyjnym: jeśli pytanie zawiera słowo "urlop", odpowiedz X. Taki scenariusz sypie się przy pierwszym pytaniu sformułowanym inaczej, niż przewidział jego autor, a pracownicy formułują pytania na tysiąc różnych sposobów. "Ile mam urlopu", "zostały mi jakieś dni do wykorzystania", "czy mogę wziąć wolne w piątek" to dla człowieka to samo pytanie, dla sztywnego scenariusza trzy osobne ścieżki do zaprogramowania.

Dlatego zamiast pisać dialogi, podpinamy bota pod dokumenty, które w firmie już istnieją: regulamin pracy, politykę urlopową, zasady benefitów, instrukcje resetu hasła, procedury onboardingowe. Bot wyszukuje odpowiedni fragment i odpowiada językiem naturalnym, nie recytując z pamięci wyuczonych formułek. Konsekwencja jest praktyczna: kiedy firma zmienia regulamin, wystarczy podmienić dokument źródłowy i uruchomić reindeksację, zamiast przepisywać dziesiątki rozgałęzień dialogu.

Podobną architekturę stosujemy zresztą w automatyzacji obsługi klienta, tylko tam źródłem wiedzy jest baza produktowa, a odbiorcą klient zewnętrzny. Mechanizm pod spodem jest ten sam, zmienia się wyłącznie to, co bot ma czytać i komu odpowiada.

RODO: dane kadrowe w bazie wektorowej to nie jest formalność

Tu trzeba postawić twardą granicę, bo to miejsce, w którym projekty wewnętrznych botów najczęściej wpadają w kłopoty. Baza wiedzy, z której korzysta bot, nie powinna zawierać danych osobowych konkretnych pracowników. Nie wrzucamy do bazy wektorowej tabeli z nazwiskami, stanem wykorzystanego urlopu czy wynagrodzeniami. Bot odpowiada na pytania o politykę ogólną, czyli ile dni urlopu przysługuje po dziesięciu latach pracy, a nie ile dni zostało konkretnej osobie.

Pytania o indywidualny stan pracownika wymagają osobnej ścieżki: zapytania w czasie rzeczywistym przez API do systemu kadrowego, z uwierzytelnieniem przez firmowe SSO, bez zapisywania tych danych w długoterminowej bazie wektorowej bota. To rozdzielenie na dwa strumienie, wiedzę ogólną w RAG i dane osobowe pobierane na żywo z systemu źródłowego, jest w praktyce jedynym sensownym sposobem, żeby nie naruszyć RODO przy okazji wygody. Dodatkowo warto zadbać o hosting bazy wektorowej na serwerach w UE, umowę powierzenia przetwarzania z dostawcą narzędzia i jasno określony okres przechowywania historii rozmów z botem, bo pracownicy prędzej czy później zapytają go też o sprawy wrażliwe, jak zwolnienie lekarskie czy konflikt z przełożonym.

Czego bot nie powinien robić

Granicę kompetencji trzeba ustawić świadomo, nie z dumą, że bot "poradzi sobie ze wszystkim". Bot dobrze radzi sobie z pytaniami faktograficznymi: ile urlopu, jak zgłosić L4, jak zresetować hasło, kiedy wypłata, jak dołączyć do ubezpieczenia grupowego. Nie powinien samodzielnie decydować o przyznaniu urlopu bezpłatnego, odpowiadać na pytania o indywidualne wynagrodzenie, angażować się w rozmowy o konflikcie interpersonalnym ani uczestniczyć w sprawach dyscyplinarnych.

Przy takich tematach dobry bot sam rozpoznaje, że przekracza swoje kompetencje, i eskaluje: jasny komunikat w stylu "to wymaga kontaktu z działem HR, przekazuję zgłoszenie", a za nim realne utworzenie ticketa albo powiadomienie konkretnej osoby. Te 20-30% zgłoszeń, które zostają po odfiltrowaniu pytań FAQ, i tak trafiają do człowieka, co jest zdrowym rozwiązaniem: HR ma więcej czasu właśnie na nie, zamiast tracić go na odpowiadanie po raz setny, gdzie jest regulamin pracy zdalnej.

Jak to wdrożyć w praktyce

Pierwszym krokiem jest audyt, nie wybór narzędzia. Trzeba przejrzeć zgłoszenia z ostatnich dwóch, trzech miesięcy (mail HR, ticketing IT, historia na Slacku) i policzyć, jaki procent się powtarza. Dopiero ta liczba decyduje, czy w danej organizacji w ogóle warto ruszać dalej.

Drugi krok, zwykle niedoceniany, to zebranie i uporządkowanie dokumentacji źródłowej: regulaminu, polityk, FAQ IT. Tu często ujawnia się pierwszy realny problem, bo dokumenty bywają rozproszone po dyskach, nieaktualne albo wzajemnie się wykluczają. Samo to porządkowanie, zanim bot ruszy, potrafi być dla firmy równie wartościowe jak sam bot.

Dalej jest budowa bazy wektorowej i podpięcie jej pod Slacka lub Teams przez n8n, albo wdrożenie Copilota jeśli firma działa w Microsoft 365. Potem testy na realnych pytaniach wyciągniętych z historii zgłoszeń i kalibracja progu pewności, czyli momentu, w którym bot powinien powiedzieć "nie wiem, przekazuję do człowieka" zamiast zgadywać. Pierwsze dwa, trzy tygodnie po uruchomieniu to najważniejszy etap kalibracji: wtedy widać, gdzie dokumentacja źródłowa jest niejasna albo sprzeczna, i to samo w sobie porządkuje firmę niezależnie od samego bota.

Podobny tok myślenia, czyli najpierw policzyć skalę powtarzalnych zadań, potem dopiero automatyzować, stosujemy też przy automatyzacji procesów biurowych i kadrowo-księgowych. Zasada jest ta sama: automatyzuje się to, co faktycznie się powtarza w dużej skali, nie to, co wygląda efektownie w prezentacji.