Agent AI do tras serwisantów: plan dnia w 30 sekund (i czemu Excel pęka już przy 3 serwisantach)

Dlaczego Excel sypie się dokładnie przy trzecim serwisancie

Z jednym serwisantem grafik to w zasadzie lista. Z dwoma, jeśli obaj pracują na podobnym terenie, da się to ogarnąć telefonicznie i kartką przyklejoną do monitora. Problem zaczyna się przy trzecim, bo wtedy liczba możliwych kombinacji „kto, gdzie, w jakiej kolejności” rośnie szybciej niż intuicja dyspozytora. Dochodzi czwarte zlecenie wrzucone w środku dnia, klient dzwoni że przesuwa godzinę, serwisant utyka w korku na obwodnicy. Excel nie ma mechanizmu, który przeliczy to wszystko na nowo, więc dyspozytor robi to w głowie, a w głowie nie mieści się macierz odległości między dziesięcioma adresami.

W firmach, z którymi pracowaliśmy przy automatyzacji procesów serwisowych, ten próg faktycznie wypada między trzecim a piątym serwisantem, przy jakichś 15–20 zleceniach dziennie na cały zespół. Poniżej tej liczby ręczne planowanie jest tańsze niż wdrożenie narzędzia, powyżej, każdy dzień bez optymalizacji to realnie stracone kilometry i godziny. Widzieliśmy grafiki, w których serwisant jeździł rano na jeden koniec miasta, po południu wracał w to samo miejsce, bo zlecenie wpadło później i nikt nie przeliczył trasy na nowo. To nie jest wina dyspozytora, to jest granica tego, co da się ułożyć ręcznie w rozsądnym czasie.

Jak wygląda agent do planowania tras w praktyce

Mówiąc „agent AI do tras” mamy na myśli konkretny, dość wąski mechanizm, nie ogólną sztuczną inteligencję, która „myśli” za dyspozytora. To automat zbudowany najczęściej w n8n lub Make, który wykonuje cztery kroki: zbiera zgłoszenia, dopasowuje je do dostępnych serwisantów, liczy optymalną kolejność wizyt i wysyła powiadomienie do klienta. Każdy z tych kroków da się zweryfikować osobno, co jest ważne, bo łatwiej naprawić jeden zepsuty etap niż cały „czarny skrzynek”.

Skąd biorą się dane wejściowe

Zgłoszenie trafia z formularza na stronie, z infolinii (transkrypcja rozmowy), z CRM albo z maila. Agent wyciąga z niego adres, typ usługi, szacowany czas realizacji i priorytet (awaria vs przegląd planowy). Tu pojawia się pierwsze ograniczenie, które trzeba uczciwie powiedzieć: jeśli zgłoszenie jest niejednoznaczne, np. klient napisał tylko „nie działa piec”, agent nie powinien sam zgadywać, ile to potrwa. Lepiej, żeby oznaczył takie zlecenie jako „wymaga potwierdzenia” i zostawił decyzję dyspozytorowi, niż żeby wpisał średni czas i rozjechał cały dzień.

Optymalizacja trasy: Google Maps i OptimoRoute

Samo układanie kolejności wizyt to zadanie typu vehicle routing problem, które da się rozwiązać dwoma sposobami. Pierwszy to wywołanie Google Maps Distance Matrix API, które liczy czasy przejazdu między wszystkimi punktami, a logika w n8n lub Make dobiera najkrótszą sensowną trasę. To rozwiązanie tańsze i wystarczające dla małych zespołów, do 4–5 serwisantów i kilkunastu przystanków dziennie. Drugi sposób to dedykowane narzędzie typu OptimoRoute, które ma gotowy silnik optymalizacyjny, uwzględnia okna czasowe, umiejętności serwisanta (np. uprawnienia gazowe), a nawet kolejność załadunku części w aucie. OptimoRoute integruje się z n8n i Make przez API, więc nie trzeba przepisywać całej logiki od zera, agent wysyła dane zgłoszeń, a narzędzie zwraca gotowy plan dnia dla każdej osoby.

Wybór między tymi dwiema opcjami to w praktyce pytanie o skalę. Przy trzech, czterech serwisantach wolimy prostsze podejście na Distance Matrix, bo wdrożenie jest tańsze i szybsze do uruchomienia. Przy dziesięciu i więcej osobach w terenie, z różnymi specjalizacjami i twardymi oknami czasowymi, dedykowany silnik się zwraca, bo ręczne dopisywanie reguł w n8n robi się nieczytelne.

SMS z oknem czasowym: mało kosztuje, dużo zmienia

Ostatni krok to komunikat do klienta: „Serwisant dotrze między 13:00 a 14:30”. To banalny element z punktu widzenia technologii, ale w praktyce odpowiada za sporą część redukcji telefonów do biura, bo klient wie, kiedy czekać, zamiast dzwonić co godzinę z pytaniem „to kiedy w końcu”. SMS transakcyjny w Polsce w 2026 roku kosztuje w typowych cennikach bramek (SMSAPI, SerwerSMS, Vonage i podobne) zwykle 0,06–0,15 zł za wiadomość przy rozliczeniu pakietowym, więc koszt tej części automatyzacji jest praktycznie pomijalny, nawet przy kilkudziesięciu wiadomościach dziennie.

Dlaczego pełna autonomia agenta to błąd, który już widzieliśmy

Tu dochodzimy do najważniejszego wniosku z naszych wdrożeń. Kuszące jest zbudowanie agenta, który sam przydziela zlecenia, sam układa trasę i sam wysyła SMS-y bez udziału człowieka. Brzmi efektywnie, w praktyce w jednym z wdrożeń doprowadziło to do dwóch typów problemów: kolizji terminów, gdy agent przydzielił dwa zlecenia temu samemu serwisantowi na nakładające się okna czasowe po tym, jak jedno z nich zostało przesunięte przez klienta, oraz pustych przebiegów, gdy automat zoptymalizował trasę matematycznie poprawnie, ale zignorował fakt, że serwisant akurat kończy inne zlecenie w zupełnie innej części miasta i fizycznie nie zdąży.

Powód jest prosty: agent ma dostęp do danych, które mu wprowadzono, ale nie ma kontekstu, który ma dyspozytor w głowie. Wie, że klient X czasem nie wpuszcza serwisanta bez wcześniejszego telefonu. Wie, że serwisant Y jest nowy i lepiej nie dawać mu trudnej instalacji bez wsparcia. Takiej wiedzy nie da się w pełni zakodować w regułach, przynajmniej nie w rozsądnym budżecie wdrożenia.

W naszym modelu agent każdego ranka (albo po każdym nowym zgłoszeniu w trybie ciągłym) generuje gotową propozycję: kto, gdzie, w jakiej kolejności, z jakim oknem czasowym. Dyspozytor dostaje to jako listę lub widok na mapie, zerka, czy nic się nie gryzie, ewentualnie przesuwa jedną pozycję przeciągnięciem, i klika zatwierdź. Dopiero wtedy wychodzą SMS-y do klientów. To jest różnica między „budowaniem grafiku” a „kontrolą jakości gotowego grafiku”, a te dwie czynności zajmują zupełnie inną ilość czasu. Pierwsza to 40–60 minut dziennie przy kilku serwisantach, druga to właśnie te 30 sekund do kilku minut, zależnie od liczby wyjątków.

Dla kogo to się opłaca, a dla kogo jeszcze nie

Najlepiej ten mechanizm sprawdza się tam, gdzie zlecenia mają jasno określony adres i orientacyjny czas trwania, a liczba serwisantów i wizyt dziennie jest na tyle duża, że ręczne układanie trasy faktycznie boli. W praktyce to serwis AGD i HVAC, firmy instalacyjne, przeglądy techniczne (np. kotłów, klimatyzacji, instalacji gazowych) oraz hydraulika. Wszystkie te branże mają podobny wzorzec: zgłoszenie przychodzi z niewielkim wyprzedzeniem, lokalizacje są rozproszone po mieście lub regionie, a klient oczekuje konkretnej godziny, nie całego dnia „między 8 a 18”.

Jeśli masz jednego lub dwóch serwisantów i sześć zleceń dziennie, szczerze mówiąc nie polecam tej automatyzacji na start. Koszt wdrożenia (konfiguracja n8n lub Make, integracja z Distance Matrix albo OptimoRoute, bramka SMS, testy na realnych trasach) nie zwróci się szybko przy tak małej skali, a kartka papieru czasem po prostu wystarczy. Dopiero od trzech serwisantów w górę, przy minimum kilkunastu wizytach dziennie łącznie, liczby zaczynają działać na korzyść automatyzacji: mniej pustych przejazdów, mniej telefonów „gdzie pan jest”, krótszy czas dyspozytora na układanie grafiku.

Jak to wdrożyć krok po kroku, bez przesady

Nie zaczynałbym od razu od pełnego systemu z OptimoRoute i automatycznymi SMS-ami do wszystkich klientów. Sensowniejsza kolejność wygląda tak: najpierw uporządkować źródło zgłoszeń, czyli sprawić, żeby każde zlecenie miało adres, typ usługi i szacowany czas w jednym miejscu, nie w trzech różnych notatnikach. Potem podłączyć prosty mechanizm liczenia trasy na Distance Matrix dla jednego serwisanta jako pilotaż, sprawdzić, czy proponowana kolejność rzeczywiście jest sensowna w terenie, nie tylko na papierze. Dopiero po tygodniach testów warto dodać automatyczne SMS-y z oknem czasowym, bo to jest element, który klient widzi bezpośrednio i błąd tutaj kosztuje reputację, nie tylko czas.

Na końcu dochodzi integracja z resztą procesu: po zakończonej wizycie serwisant potwierdza wykonanie w aplikacji, co może automatycznie uruchomić wystawienie faktury czy protokołu. To już temat na osobne wdrożenie, opisane szerzej przy automatyzacji faktur, ale warto o nim pomyśleć już na etapie projektowania agenta do tras, żeby dane nie musiały wędrować ręcznie między systemami. Podobnie komunikacja z klientem, czyli nie tylko SMS z oknem czasowym, ale też obsługa pytań „czy serwisant już jedzie”, da się spiąć z szerszym procesem opisanym przy automatyzacji obsługi klienta, żeby klient nie musiał dzwonić, tylko dostał odpowiedź z bota lub automatycznego powiadomienia.

Jedno zastrzeżenie na koniec tej części: agent nie zastąpi dyspozytora przy prawdziwym chaosie, czyli gdy w ciągu godziny trzeba przełożyć pięć wizyt, bo serwisant złapał gumę, a drugi zachorował. W takich sytuacjach automatyzacja pomaga przeliczyć trasy pozostałych osób szybciej niż ręcznie, ale decyzję, kogo wysłać zamiast chorego i które zlecenie przełożyć na jutro, zostawiamy człowiekowi. To nie jest słabość systemu, to jest świadomy wybór, który chroni przed sytuacją, gdzie automat podejmuje decyzję biznesową, za którą nikt nie chce wziąć odpowiedzialności.