Technik dojechał, otworzył obudowę i okazało się, że potrzebna część leży w magazynie sto kilometrów dalej. Druga wizyta jest najdroższą rzeczą w Waszym serwisie — i to od niej, nie od chatbota, zaczyna się tu AI

Jedna liczba, która rozstrzyga cały projekt

Zanim pojawi się dostawca, demo i słowo „agent”, warto wyliczyć jedną rzecz: jaki odsetek zgłoszeń zamykacie przy pierwszej wizycie. W branży nazywa się to skutecznością pierwszej naprawy, a liczy się ją prosto — ile zleceń zostało zakończonych bez konieczności ponownego przyjazdu do tego samego problemu, podzielone przez wszystkie zlecenia w okresie. Bez tej liczby każda rozmowa o AI w serwisie jest rozmową o wrażeniach.

Z naszego doświadczenia w polskich firmach serwisowych tej liczby najczęściej nikt nie zna, a kiedy po raz pierwszy się ją policzy, wychodzi niżej, niż zakładał zarząd. Powód jest techniczny: w systemie zgłoszeniowym druga wizyta bywa rejestrowana jako nowe zlecenie, więc statystyka pokazuje więcej zrealizowanych zleceń, a nie więcej problemów rozwiązanych. To jest pierwszy wniosek z audytu i nie wymaga żadnego narzędzia — wymaga sprawdzenia, czy potraficie powiązać wizyty z jednym problemem jednego urządzenia.

Druga liczba, która powinna stać obok: ile średnio kosztuje Was jeden dojazd. Paliwo, amortyzacja, czas w drodze w obie strony, czas przezbrojenia zlecenia, godziny dyspozytora na przeplanowanie reszty dnia. W firmach z terenem rozrzuconym po kilku województwach ta kwota bywa wyższa niż wartość samej naprawy, a jednak nie występuje w żadnym raporcie, bo rozpływa się między kosztami flotowymi i wynagrodzeniami.

Te dwie liczby razem dają coś, czego żaden dostawca Wam nie da: punkt odniesienia. Jeżeli skuteczność pierwszej naprawy wynosi dziś 70%, to wiecie, ile warte jest podniesienie jej do 80% i czy ten projekt ma w ogóle sens. Jeżeli jej nie znacie, każda obietnica poprawy jest nieweryfikowalna — a dokładnie tak upada większość wdrożeń, które opisywaliśmy w tekście o testowaniu wdrożeń AI.

Trzy różne rzeczy sprzedawane jako „AI w serwisie”

Pod jednym hasłem sprzedaje się dziś co najmniej trzy produkty o różnych danych, różnym ryzyku i różnej cenie. Mieszanie ich w jednym postępowaniu zakupowym jest najczęstszym powodem, dla którego firma kupuje coś, czego nie potrzebowała.

Pierwsza rzecz to kanał zgłoszeń: chatbot na stronie, portal klienta, agent odbierający telefon. To jest warstwa kontaktu — poprawia dostępność i odciąża dyspozytora, ale nie poprawia ani diagnozy, ani planowania. Jeżeli zgłoszenie przyjęte przez bota jest tak samo ubogie jak to przyjęte przez telefon, zmieniliście tylko to, kto je zapisuje.

Druga to wsparcie techniczne: model, który z historii napraw, dokumentacji i kodów błędów podpowiada najbardziej prawdopodobne przyczyny i listę części. To warstwa wiedzy i tutaj leży największa część korzyści, bo działa bezpośrednio na skuteczność pierwszej naprawy.

Trzecia to planowanie: przypisanie zleceń do techników, kolejność wizyt, trasa, okna czasowe, kwalifikacje. To nie jest zadanie dla modelu językowego i wrócimy do tego osobno, bo jest to najczęściej popełniany błąd techniczny w tych projektach.

Z tej trójki radzimy zaczynać od drugiej, równolegle porządkując dane wejściowe pierwszej, a planowanie zostawić na koniec. Odwrotna kolejność — najpierw bot, potem planista, a wiedza nigdy — daje szybkie demo i zero zmiany w liczbach.

Gdzie naprawdę znika czas między zgłoszeniem a wyjazdem

Warto raz przejść ten proces z zegarkiem, bo w opisach procedur wygląda zupełnie inaczej niż w praktyce. Typowa sekwencja w firmie serwisowej średniej wielkości wygląda tak.

• Klient dzwoni albo pisze maila. Opis brzmi „nie działa”, „wyrzuca błąd”, „wycieka”. Nie ma numeru seryjnego, bo tabliczka jest z tyłu urządzenia, a osoba zgłaszająca nie jest tą, która je obsługuje.
• Dyspozytor przepisuje to do systemu. Przepisuje, czyli interpretuje — i od tego momentu zgłoszenie żyje własnym życiem, zwykle w jednym zdaniu w polu „opis”.
• Nikt nie sprawdza historii. Sprawdzenie, czy to samo urządzenie było już naprawiane i co wtedy zrobiono, wymaga otwarcia kilku ekranów albo przeczytania skanów raportów, więc w praktyce odbywa się tylko wtedy, gdy klient sam o tym przypomni.
• Technik dowiaduje się o zleceniu rano, często z telefonu, i sam dzwoni do klienta, żeby dopytać. To jest ten moment, w którym proces faktycznie zbiera dane — tylko odbywa się po przydzieleniu zlecenia, a nie przed.
• Części dobiera się z pamięci. Albo bierze się „co zwykle”, albo nie bierze nic, bo i tak trzeba będzie wrócić. To drugie podejście staje się samospełniającą się prognozą.
• Po naprawie powstaje raport. Zwykle na papierze albo w formularzu z czterdziestoma polami, z czego wypełnione są trzy, a w polu opisu widnieje „naprawiono zgodnie ze zgłoszeniem”. Ten jeden fragment decyduje o tym, czy w ogóle będziecie mieli z czego zbudować warstwę wiedzy.

Warstwa pierwsza: zgłoszenie, które ma dane

Pierwsze wdrożenie, które proponujemy, jest nudne i dlatego działa. Nie chodzi o to, żeby model odpowiadał klientowi, a o to, żeby ze zgłoszenia — niezależnie od tego, czy przyszło mailem, z formularza, z portalu czy jako transkrypcja rozmowy — powstał kompletny rekord. Model językowy jest w tym mocny, bo to jest zadanie na zamianę nieuporządkowanego tekstu w strukturę.

Z treści zgłoszenia wyciąga się: identyfikację urządzenia (model, numer seryjny, lokalizacja, numer umowy serwisowej), objaw przełożony na Wasz własny słownik objawów, informację, czy urządzenie stoi, czy pracuje z ograniczeniem, dostępność obiektu i osoby kontaktowej, oraz to, czy zgłoszenie mieści się w gwarancji, umowie serwisowej, czy jest odpłatne. Ostatni punkt jest zaskakująco dochodowy i wrócimy do niego przy rachunku.

Drugie zadanie jest ważniejsze niż samo wyciąganie danych: wskazanie, czego brakuje. System, który przy zgłoszeniu bez numeru seryjnego od razu generuje pytanie zwrotne do klienta — konkretne, z informacją, gdzie szukać tabliczki, najlepiej z prośbą o zdjęcie — podnosi kompletność zgłoszeń szybciej niż jakiekolwiek szkolenie dyspozytorów. A zdjęcie z telefonu klienta model odczyta i dopasuje do bazy urządzeń.

Trzecie: powiązanie z historią. Zgłoszenie powinno od pierwszej minuty mieć przy sobie listę poprzednich wizyt na tym urządzeniu, z czym przyjeżdżano i co wymieniano. To jest ta informacja, której dziś nikt nie czyta, bo jest rozproszona, i która najczęściej decyduje o tym, czy wizyta będzie jedna.

Technicznie ta warstwa opiera się na tym samym mechanizmie, który opisywaliśmy przy AI na firmowej skrzynce e-mail, a kiedy kanałem jest telefon — przy agencie głosowym po polsku. Z jednym zastrzeżeniem, które w serwisie jest mocniejsze niż w obsłudze klienta: zadaniem tej warstwy nie jest odpowiedzieć, a przygotować. Odpowiada człowiek albo nikt.

Warstwa druga: diagnoza wstępna z własnej historii napraw

To jest miejsce, w którym ten projekt zarabia. Zadanie brzmi: na podstawie objawu, modelu urządzenia, jego historii i dokumentacji technicznej przygotować dla technika krótkie podsumowanie przed wyjazdem — trzy najbardziej prawdopodobne przyczyny, czego sprawdzić najpierw, jakie części warto mieć ze sobą i czy w tym modelu występuje znana usterka seryjna.

Źródłem nie jest wiedza ogólna modelu, a Wasze dokumenty: raporty serwisowe z ostatnich lat, dokumentacja techniczno-ruchowa, instrukcje producenta, listy kodów błędów, biuletyny serwisowe, katalogi części. Mechanizm to przeszukiwanie własnych treści i odpowiadanie wyłącznie na ich podstawie — opisaliśmy go w tekście o asystencie AI na dokumentach firmy. Różnica wobec zwykłego czatu jest zasadnicza: każda podpowiedź musi mieć wskazane źródło, czyli konkretny raport albo stronę dokumentacji, żeby technik mógł to w pięć sekund zweryfikować.

Warto powiedzieć wprost, czym to nie jest. To nie jest diagnoza. Model nie ustala przyczyny usterki — model przypomina, co w tej firmie działo się wcześniej w podobnych przypadkach. Różnica nie jest filozoficzna: decyduje o tym, jak formułujecie wynik dla technika. „Najczęstsza przyczyna tego objawu w tym modelu w ostatnich dwóch latach, na podstawie jedenastu zgłoszeń” to zdanie użyteczne. „Uszkodzony zaworek rozprężny” to zdanie, które przy trzeciej pomyłce kończy zaufanie do narzędzia.

I rzecz, która rozstrzyga o powodzeniu tej warstwy, zanim ktokolwiek wybierze model: jakość raportów serwisowych. Jeżeli w stu ostatnich raportach w polu opisu widnieje „naprawiono”, „wymieniono część”, „usunięto usterkę”, to nie macie z czego zbudować tej warstwy i żadne narzędzie tego nie nadrobi. To nie jest wina techników — to skutek formularza, który karze za pisanie.

Raport serwisowy jest w tym projekcie najważniejszym dokumentem

Dlatego w naszej praktyce pierwszym krokiem bywa nie model diagnostyczny, a naprawienie sposobu, w jaki powstaje raport. Logika jest prosta: raport jest jednocześnie dowodem wykonania pracy, podstawą faktury, źródłem danych do diagnozy i jedyną pamięcią firmy o tym urządzeniu. A powstaje w najgorszych możliwych warunkach — po ośmiu godzinach pracy, w samochodzie, na telefonie, gdy technik chce już jechać do domu.

Rozwiązanie, które się sprawdza, jest odwrotne do typowego odruchu działu jakości. Zamiast dodawać pola, usuwa się je i zostawia jedno: technik mówi, co zrobił, przez trzydzieści sekund do telefonu, a model zamienia to w strukturę — objaw potwierdzony, czynność, wymienione części z numerami katalogowymi, czas pracy, zalecenia, czy wymagana jest kolejna wizyta i po co. Mechanizm jest ten sam, który opisaliśmy przy notatkach AI ze spotkań, tylko wynik idzie do systemu serwisowego, a nie do maila.

Efekt jest podwójny i drugi jest cenniejszy. Pierwszy: raport powstaje na miejscu, a nie w piątek za trzy tygodnie, więc fakturowanie przyspiesza, a spory o zakres prac maleją. Drugi: po pół roku macie zbiór opisów usterek w jednolitej strukturze — i dopiero wtedy warstwa diagnostyczna z poprzedniej sekcji ma na czym stanąć. To jest typowa kolejność w tych projektach: najpierw naprawiacie sposób zbierania danych, potem dostajecie model, który coś z nich potrafi.

Jedno ostrzeżenie organizacyjne, bo ta zmiana bywa czytana opacznie. Dyktowanie raportu nie może zostać wprowadzone jako nowa forma kontroli technika. Jeżeli pierwsza rozmowa o nagraniach dotyczy tego, kto pracował za krótko, zespół w ciągu dwóch tygodni wróci do „naprawiono zgodnie ze zgłoszeniem” — tylko tym razem powie to głosem. Opisywaliśmy ten mechanizm przy okazji tekstu o tym, dlaczego zespół nie używa AI.

Warstwa trzecia: części na samochodzie

Samochód serwisowy jest magazynem, tylko nikt go tak nie traktuje. Zwykle jest zapełniany historycznie: tym, co kiedyś było potrzebne, tym, co technik woli mieć, i tym, co zostało z poprzedniego zlecenia. W efekcie w jednym samochodzie leży zapas, który nie rotuje od roku, a brakuje dokładnie tej jednej części, która generuje drugą wizytę.

Zadanie dla analityki jest tu konkretne: na podstawie objawu ze zgłoszenia, modelu urządzenia i historii wymian wskazać części z najwyższym prawdopodobieństwem użycia, a na poziomie floty — ustalić, co ma stale leżeć w którym samochodzie, biorąc pod uwagę profil urządzeń w danym regionie. To bliżej zarządzania zapasem niż modelu językowego i warto to liczyć tymi samymi metodami, które opisaliśmy przy stanach magazynowych i martwym zapasie oraz przy prognozowaniu popytu.

Jest tu jednak różnica, o której trzeba pamiętać przy ustawianiu progów. W serwisie koszt braku części jest nieporównywalnie wyższy od kosztu jej trzymania, bo brak oznacza drugi dojazd i naruszone SLA, a trzymanie oznacza kilkaset złotych stojące w bagażniku. To znaczy, że optymalizacja zapasu na samochodzie nie polega na minimalizacji wartości, a na maksymalizacji pokrycia najczęstszych scenariuszy przy zadanym limicie miejsca. Dostawca, który proponuje Wam tu „redukcję zapasu”, mierzy nie tę liczbę, co Wy.

Drugi pożytek pojawia się po stronie zamówień. Jeżeli system wie, jakie części pójdą w najbliższych dniach, to zapotrzebowanie do magazynu centralnego przestaje być serią telefonów rano. Pierwsza wersja proponuje listę — zamawia człowiek, bo zamówienie jest decyzją finansową.

Warstwa czwarta: harmonogram i trasa, czyli miejsce, gdzie model językowy nie pracuje

Tu popełnia się najpoważniejszy błąd techniczny w tych projektach. Przypisanie trzydziestu zleceń do ośmiu techników, z oknami czasowymi, kwalifikacjami, czasem przejazdu i czasem pracy, nie jest zadaniem dla modelu językowego. To jest zadanie optymalizacyjne, które rozwiązuje się solverem — tak samo jak grafik pracy, o czym pisaliśmy przy planowaniu grafików pracy, i tak samo jak trasy, o czym pisaliśmy przy AI w spedycji i transporcie.

Rozróżnienie ma skutki praktyczne. Model językowy poproszony o grafik wygeneruje coś, co wygląda jak grafik: będzie poprawne stylistycznie i będzie łamało ograniczenia, których nie widać na pierwszy rzut oka. Solver albo zwróci rozwiązanie spełniające wszystkie ograniczenia twarde, albo powie, że nie istnieje — i to drugie jest w serwisie informacją o ogromnej wartości, bo oznacza, że na dany dzień macie za mało ludzi z danymi uprawnieniami i trzeba zadzwonić do klienta dziś, a nie po terminie.

Lista ograniczeń twardych w polskim serwisie jest dłuższa, niż zakłada większość gotowych narzędzi, i warto ją spisać przed rozmową z dostawcą.

• Uprawnienia i certyfikaty. Uprawnienia SEP do prac przy urządzeniach elektrycznych, uprawnienia do obsługi i konserwacji urządzeń podlegających dozorowi technicznemu, certyfikat f-gazowy przy układach chłodniczych, szkolenia producenta warunkujące gwarancję, dostęp do obiektu po przeszkoleniu BHP u klienta. Technik bez właściwego dokumentu nie jest tańszą alternatywą — jest brakiem możliwości wykonania zlecenia.
• Okna czasowe z umowy. Czas reakcji i czas usunięcia usterki różnią się dla różnych klientów i różnych kategorii awarii, a liczone bywają w godzinach roboczych, nie kalendarzowych. To musi być w modelu jako ograniczenie, nie jako życzenie.
• Czas pracy i czas jazdy. Dobowy i tygodniowy odpoczynek, dyżury, nadgodziny, limity prowadzenia pojazdu tam, gdzie mają zastosowanie. Grafik, który spełnia SLA i łamie prawo pracy, jest kosztem, nie rozwiązaniem.
• Geografia i realny czas przejazdu. Nie odległość w kilometrach, a czas przejazdu o danej godzinie — w aglomeracji różnica między ósmą a jedenastą potrafi zmienić cały układ dnia.
• Dostępność obiektu. Zmiany produkcyjne, godziny otwarcia, obecność osoby z dostępem do pomieszczenia, planowane przestoje. Zlecenie wykonalne technicznie o czternastej bywa niewykonalne o siódmej.
• Części. Zlecenie, do którego brakuje części, nie powinno w ogóle wejść do harmonogramu jako wizyta naprawcza — i to jest miejsce, w którym warstwa trzecia łączy się z czwartą.

Gdzie w planowaniu model językowy faktycznie pomaga

Nie znaczy to, że w tej warstwie nie ma dla niego pracy. Są trzy zadania, w których jest lepszy od solvera i od człowieka.

Pierwsze: zamiana ustaleń na ograniczenia. Dyspozytor dostaje mailem „w listopadzie nie wpuszczamy nikogo w poniedziałki rano, bo mamy audyt”, a potem ta informacja żyje w jego pamięci. Model wyciąga z takich wiadomości reguły i zapisuje je w jednym miejscu, skąd czyta je solver.

Drugie: wyjaśnianie planu. Solver zwraca przydział, nie uzasadnienie. Pytanie „dlaczego Kowalski jedzie do Radomia, a nie Nowak” jest pierwszym pytaniem, które pada po uruchomieniu takiego systemu, i brak odpowiedzi na nie jest najczęstszą przyczyną porzucenia narzędzia. Model potrafi to opisać w dwóch zdaniach, odwołując się do ograniczeń, które zadecydowały.

Trzecie: komunikacja do klienta. Potwierdzenie terminu, powiadomienie o opóźnieniu, informacja, kto przyjedzie i co będzie robił, przełożone na ton Waszej firmy i na język klienta. Przy czym — jeżeli ta komunikacja jest dwustronna i automatyczna, wchodzi obowiązek informowania, że po drugiej stronie jest AI; wracamy do tego w sekcji o przepisach.

SLA jako zegar, nie jako zdanie w umowie

W serwisie B2B czas jest przedmiotem umowy i dlatego pierwszym wdrożeniem o natychmiastowym zwrocie bywa nie model, a zegar. Dokładnie tak samo jak w reklamacjach i zwrotach, gdzie decydującym elementem okazał się termin, a nie generowanie odpowiedzi.

Rzecz polega na tym, żeby każde zgłoszenie od pierwszej minuty miało policzony czas reakcji i czas usunięcia usterki według właściwej umowy, z uwzględnieniem godzin roboczych klienta, dni wolnych i kategorii awarii, oraz żeby zbliżanie się do terminu było widoczne, zanim termin minie. Brzmi banalnie i w większości firm serwisowych nie istnieje: terminy są w PDF-ach umów, a świadomość, że termin właśnie mija, pojawia się wtedy, gdy dzwoni klient.

Model językowy ma tu konkretne zadanie na wejściu: wyciągnąć z umów serwisowych parametry, które mają być pilnowane — czasy reakcji, czasy naprawy, kategorie awarii, godziny objęte wsparciem, kary i ich progi, zakres wyłączeń. Przy portfelu kilkudziesięciu umów, każdej napisanej inaczej, jest to praca na kilka dni, której nikt nie robi, bo nikt nie ma tych kilku dni. Potem to już zwykła logika, nie AI. Tę samą pracę opisaliśmy szerzej przy analizie umów od kontrahentów.

Dwa efekty uboczne są warte więcej niż samo pilnowanie terminów. Pierwszy: dowiadujecie się, których umów nie da się dotrzymać przy obecnej obsadzie — i to jest argument do renegocjacji albo do podwyższenia ceny, a nie do obwiniania dyspozytora. Drugi: widzicie, ile kar faktycznie zapłaciliście, co w wielu firmach jest liczbą nieznaną, bo kary potrącane są z faktur i znikają w rozliczeniach.

Przepisy: dwie rzeczy do sprawdzenia przed startem

Nie jesteśmy kancelarią, a poniższe warto potwierdzić z prawnikiem i inspektorem ochrony danych na Waszym konkretnym przypadku. Ale dwa obszary wracają w każdym takim projekcie i lepiej zająć się nimi przed, nie po.

Pierwszy to obowiązek informowania, że klient ma kontakt ze sztuczną inteligencją. Od 2 sierpnia 2026 roku obowiązują przepisy przejrzystości z artykułu 50 unijnego rozporządzenia o AI, a w Polsce nadzór i kontrole prowadzi KRiBSI — rozpisaliśmy to w tekstach o AI Act w małej firmie i o kontroli KRiBSI. W serwisie dotyczy to agenta odbierającego zgłoszenia telefonicznie, czatu na portalu klienta i automatycznych wiadomości o terminie, jeżeli prowadzą dialog. Nie dotyczy natomiast tego, co proponujemy jako pierwszy projekt — przygotowania zgłoszenia i podpowiedzi dla technika — bo tam model nie rozmawia z klientem.

Drugi to dane techników. Planowanie tras i rozliczanie czasu pracy prowadzi prosto do lokalizacji pracownika, a to jest w Polsce uregulowane: Kodeks pracy traktuje lokalizowanie pracowników jako jedną z form monitoringu, co w praktyce oznacza określenie celu, zakresu i sposobu zastosowania w regulaminie pracy albo obwieszczeniu, poinformowanie pracowników co najmniej dwa tygodnie przed uruchomieniem, ograniczenie do celu, dla którego monitoring wprowadzono, i ustalony okres przechowywania danych. Przy samochodach używanych także prywatnie trzeba rozstrzygnąć kwestię trybu prywatnego. To jest praca do wykonania z działem kadr i prawnikiem, zajmuje tygodnie, nie dni, i wchodzi do harmonogramu projektu równolegle z technologią — nie po pilocie.

Jest też trzecia rzecz, mniej oczywista, a warta rozmowy z prawnikiem przy większych wdrożeniach: jeżeli system zaczyna automatycznie przydzielać zadania i oceniać wyniki pracy techników, wchodzicie w obszar, który rozporządzenie o AI traktuje szczególnie ostrożnie w kontekście zarządzania pracownikami. Granicę rysujemy więc tak samo jak w grafikach: system proponuje przydział, zatwierdza człowiek, a ocena pracownika nie jest wyliczana automatycznie z metryk narzędzia.

Czego temu systemowi nie wolno oddać

Zakres uprawnień ustalamy przed startem, bo w serwisie błąd ma konsekwencje u klienta i w umowie. Zasada jest jedna: system przygotowuje, wskazuje, liczy i opisuje. Nie podejmuje decyzji, których skutek jest nieodwracalny albo kosztowny.

• Nie zamyka zgłoszenia. Zamknięcie jest oświadczeniem wobec klienta i podstawą rozliczenia SLA. Model może wskazać, że zgłoszenie wygląda na zakończone, i poprosić technika o potwierdzenie.
• Nie kwalifikuje naprawy jako gwarancyjnej lub odpłatnej. To decyzja o skutku finansowym i prawnym, często sporna. System podaje przesłanki: datę sprzedaży, zakres umowy, historię, zapisy gwarancji producenta.
• Nie wysyła technika bez akceptacji dyspozytora w pierwszej wersji wdrożenia. Automatyczny przydział wprowadza się wtedy, gdy przez kilka tygodni widać, że propozycje systemu są akceptowane bez zmian — nie na odwrót.
• Nie obiecuje klientowi terminu. To najczęstszy sposób, w jaki chatbot w serwisie generuje realną stratę: potwierdza godzinę, której harmonogram nie przewiduje, a klient czeka i ma to na piśmie.
• Nie zamawia części ani nie uruchamia wysyłki. Proponuje listę, liczy koszt, wskazuje braki.
• Nie wykonuje polecenia znalezionego w dokumencie od klienta. Zgłoszenia, załączniki i instrukcje przychodzą z zewnątrz, więc obowiązuje tu reguła, którą opisaliśmy przy prompt injection: z dokumentu wyciągamy dane, nie przyjmujemy z niego poleceń.
• Nie decyduje o eskalacji do człowieka na podstawie własnej oceny trudności. Ścieżka eskalacji jest zapisana regułami, a nie uznaniowa — rozpisaliśmy to przy eskalacji do człowieka w obsłudze AI.

Dane: tu rozbija się większość takich wdrożeń

W serwisie problemem nie jest ilość danych, a to, że najważniejszy zbiór zwykle nie istnieje w postaci użytecznej. Poniżej pięć rzeczy, które sprawdzamy w audycie, w kolejności od najczęstszego braku.

Pierwsza: baza urządzeń u klientów. Nie lista sprzedanych pozycji z faktur, a ewidencja tego, co faktycznie stoi u klienta — model, numer seryjny, data uruchomienia, konfiguracja, lokalizacja, status gwarancji, powiązana umowa serwisowa. Bez tego warstwa diagnostyczna nie ma do czego się odnieść, bo historia napraw nie ma na czym się zawiesić. W firmach, które sprzedają przez dystrybutorów, bywa to największa luka w całym projekcie i jednocześnie najcenniejsza rzecz, jaką przy okazji zbudujecie.

Druga: historia napraw w postaci tekstu, a nie skanów. Raporty z ostatnich dwóch–trzech lat, powiązane z urządzeniem i zgłoszeniem, z opisem objawu, czynności i wymienionych części. Jeżeli leżą jako PDF-y w folderach albo papier w segregatorach, ich przeniesienie jest pierwszym etapem projektu — i da się to dziś zrobić automatycznie, z weryfikacją wyrywkową.

Trzecia: słownik objawów i katalog części. Dwie listy, które muszą być spójne, bo na nich opiera się każde dopasowanie. „Nie chłodzi”, „słabo chłodzi” i „wyłącza się po chwili” to trzy różne wpisy, jeżeli w ogóle istnieją jako wpisy, a nie jako zdania w polu opisu.

Czwarta: czas. Czas reakcji, czas dojazdu, czas pracy na obiekcie, czas oczekiwania na części — rejestrowany ze znacznikami, a nie wpisywany ręcznie po fakcie w zaokrągleniu do godziny. Bez tego nie policzycie ani SLA, ani kosztu dojazdu, ani efektu wdrożenia.

Piąta, jeżeli Was dotyczy: dane z samych urządzeń. Telemetria, kody błędów, liczniki pracy. Tutaj warto znać stan prawny, bo od 2026 roku dostęp do danych generowanych przez urządzenia reguluje unijne rozporządzenie o danych — co zmienia pozycję zarówno serwisu niezależnego, jak i producenta. Rozpisaliśmy to w tekście o Data Act i danych z maszyn. Jeżeli macie telemetrię, naturalnym rozszerzeniem jest predykcyjne utrzymanie ruchu — ale jest to osobny projekt, z własnym rachunkiem, i nie powinien być pierwszym.

Rachunek, który trzeba zrobić przed rozmową z dostawcą

Ten projekt wycenia się od strony dojazdów i niezafakturowanych godzin, nie od strony liczby zapytań do modelu. Pięć pozycji, jedno popołudnie z arkuszem.

Pierwsza: liczba drugich wizyt w roku razy koszt dojazdu. Jeżeli nie potraficie policzyć drugich wizyt, weźcie liczbę zleceń, przy których zużyto część niezamówioną wcześniej, albo liczbę zleceń z więcej niż jednym wpisem czasu pracy. To niedoszacowanie, ale pokazuje skalę.

Druga: godziny, których nie zafakturowaliście, bo raport był niekompletny albo spóźniony. W firmach serwisowych z rozliczeniem godzinowym ta kwota regularnie zaskakuje zarząd, bo nie ma jej w żadnym raporcie — brakuje przecież tego, czego nie wystawiono.

Trzecia: naprawy wykonane jako gwarancyjne, które gwarancyjne nie były. To ta sama rodzina strat: wynika z braku szybkiego dostępu do daty uruchomienia, zakresu umowy i historii. W firmach z dużą bazą urządzeń bywa największą pojedynczą pozycją w tym rachunku.

Czwarta: kary i rabaty z tytułu naruszenia SLA plus koszty eskalacji — rozmowy, przyjazdy „grzecznościowe”, upusty na kolejne zlecenie.

Piąta: czas dyspozytora i kierownika serwisu. Przepisywanie zgłoszeń, telefony w celu uzupełnienia danych, przeplanowanie dnia, szukanie historii, wyjaśnianie klientowi. To jest etat albo dwa, rozlane po całym dniu, i najłatwiej go zobaczyć, licząc liczbę telefonów wychodzących z biura serwisu.

Po stronie kosztów są cztery pozycje i trzecia jest zwykle pomijana przy podpisywaniu umowy. Integracja z systemem serwisowym, ERP i bazą urządzeń. Przygotowanie danych: baza urządzeń, przeniesienie raportów, słownik objawów. Czas Waszych techników i dyspozytorów na ustalenie reguł, przejrzenie pierwszych podpowiedzi i poprawianie ich — tej pracy nie da się kupić na zewnątrz i to ona decyduje o jakości wyniku. Oraz utrzymanie po starcie, czyli to, co rozpisaliśmy w tekstach o koszcie wdrożenia AI i o utrzymaniu AI po wdrożeniu.

Wdrożenie w sześć tygodni

Kolejność jest ułożona tak, żeby po każdym tygodniu zostało coś użytecznego, nawet gdyby projekt stanął, i żeby żadna automatyzacja nie wyprzedziła zaufania do danych.

1. Tydzień pierwszy: liczby wyjściowe. Skuteczność pierwszej naprawy za ostatnie dwanaście miesięcy, koszt dojazdu, liczba drugich wizyt, czas od zgłoszenia do wyjazdu. Jeżeli czegoś nie da się policzyć, to jest pierwszy wynik projektu, a nie przeszkoda. Ten tydzień ma wartość sam w sobie.
2. Tydzień drugi: baza urządzeń i historia. Zebranie ewidencji tego, co stoi u klientów, powiązanie jej z umowami i przeniesienie raportów serwisowych do postaci tekstu. Najmniej efektowny etap i ten, który najbardziej poprawia wszystko, co przyjdzie później.
3. Tydzień trzeci: strukturyzacja zgłoszeń. Model wyciąga dane ze zgłoszeń przychodzących mailem i z formularza, wskazuje braki, generuje pytanie zwrotne, dokłada historię urządzenia. Dyspozytor pracuje jak dotychczas, tylko dostaje rekord gotowy. Mierzymy kompletność zgłoszeń, nie zachwyt.
4. Tydzień czwarty: podsumowanie przed wyjazdem. Trzy prawdopodobne przyczyny, co sprawdzić, jakie części, ze wskazaniem źródła. Pilot na jednej grupie urządzeń i dwóch–trzech technikach, którzy chcą w tym uczestniczyć. Mierzymy jedną rzecz: czy podpowiedź trafiła.
5. Tydzień piąty: raport dyktowany i zegar SLA. Dyktowanie z zamianą na strukturę, parametry z umów wyciągnięte i podłączone pod powiadomienia o zbliżającym się terminie.
6. Tydzień szósty: części i dopiero na końcu planowanie. Lista części pod zlecenie i pod samochód; przydział zleceń w trybie propozycji do akceptacji dyspozytora, jeżeli dane o czasie i uprawnieniach są kompletne. Jeżeli nie są — planowanie zostaje na kolejny etap i to jest prawidłowa decyzja, nie porażka.
7. Po sześciu tygodniach, nie wcześniej: decyzja o zakresie dalszym. Kryterium to dwie liczby — trafność podpowiedzi przed wyjazdem i zmiana skuteczności pierwszej naprawy na grupie pilotażowej. Jeżeli pierwsza jest niska, wracamy do raportów serwisowych, a nie do wyboru modelu.

Pięć sygnałów, że poszło w złą stronę

Te wdrożenia psują się przewidywalnie i widać to w pierwszym miesiącu. Każdy z poniższych objawów traktujemy jako powód do zatrzymania się, a nie do rozszerzania zakresu.

• Technicy nie otwierają podsumowania przed wyjazdem. To nie jest problem narzędzia, a trafności i formy: jeżeli podsumowanie ma półtorej strony, nikt go nie przeczyta na parkingu. Pięć zdań i lista części albo nic.
• Podpowiedzi są ogólne. „Sprawdzić zasilanie, sprawdzić czujnik, sprawdzić szczelność” to wynik świadczący o tym, że model nie ma oparcia w Waszych raportach, tylko mówi z wiedzy ogólnej. Wtedy problem jest w danych, nie w prompcie.
• Projekt urósł do wymiany systemu serwisowego. W trzecim tygodniu pojawia się wniosek, że najpierw trzeba wdrożyć nowe FSM. Czasem to prawda, ale jest to wtedy inny projekt, z innym budżetem i harmonogramem, a nie etap tego wdrożenia.
• Chatbot stanął przed resztą. Jeżeli pierwszą uruchomioną rzeczą jest rozmowa z klientem, a diagnoza i dane czekają, to wdrożyliście nową drogę wejścia dla tych samych ubogich zgłoszeń — plus obowiązek informowania, że to AI.
• Zaczęły się rozmowy o rankingu techników. Moment, w którym dane z narzędzia pojawiają się w rozmowie o premiach, jest momentem, w którym jakość raportów zaczyna spadać. Opisy stają się ostrożne, czasy okrągłe, a za pół roku nie ma z czego uczyć niczego.

Kiedy tego nie wdrażać

Są sytuacje, w których ten projekt radzimy odłożyć, i mówimy o tym na pierwszym spotkaniu, bo rozmowa o tym po trzech miesiącach jest znacznie droższa.

Jeżeli obsługujecie kilka zgłoszeń tygodniowo i jedna osoba zna pamięciowo każde urządzenie u klienta, nie ma czego automatyzować — koszt wdrożenia nie zwróci się nigdy, a pamięć tej osoby jest lepsza od każdego modelu. Problemem jest wtedy ryzyko, że ta osoba odejdzie, i to jest projekt dokumentacyjny, nie projekt AI.

Jeżeli nie macie żadnej ewidencji tego, co stoi u klientów, a sprzedaż idzie w całości przez dystrybutorów, pierwszy etap to zbudowanie bazy urządzeń. Da się to zrobić — z faktur, z kart gwarancyjnych, z raportów, z telemetrii — ale jest to osobny projekt na kilka miesięcy i trzeba go uczciwie wpisać do harmonogramu, zamiast odkrywać w trzecim tygodniu.

Jeżeli technicy pracują na zleceniach jednorazowych, bez powtarzalnych typów urządzeń, warstwa diagnostyczna będzie miała słabe oparcie w historii. Zostaje wtedy sensowna reszta: zgłoszenia, zegar SLA, raport i części — i warto zawęzić zakres do nich, zamiast kupować całość.

I jeżeli główny ból jest gdzie indziej — w wycenach, w ofertowaniu, w fakturowaniu — to niech projekt dotyczy tego. Opisaliśmy ten obszar przy wycenach i ofertach handlowych, a ogólną zasadę wyboru pierwszego procesu przy siedmiu procesach do automatyzacji.

Od czego zacząć

Najtańszy pierwszy krok nie wymaga ani dostawcy, ani budżetu i zajmuje jedno popołudnie. Wyciągnijcie z systemu dwie listy. Pierwsza: dwadzieścia ostatnich zleceń, które wymagały drugiej wizyty, z informacją, czego brakowało przy pierwszej — części, danych, uprawnień, dostępu do obiektu. Druga: dwadzieścia ostatnich raportów serwisowych w całości, tak jak je napisali technicy. Pierwsza lista mówi, gdzie są pieniądze. Druga mówi, czy macie z czego zbudować warstwę, która je odzyska. Jeżeli w drugiej liście nie ma zdań opisujących, co było zepsute i co z tym zrobiono, to macie już pierwszy etap projektu — i nie dotyczy on wyboru modelu.

Tak prowadzimy takie wdrożenia: najpierw audyt tego, jakie dane serwisowe realnie macie i w jakim stanie, potem kompletne zgłoszenie i historia urządzenia pod ręką, potem podsumowanie przed wyjazdem i raport dyktowany, a planowanie i trasy na końcu — bo mają sens dopiero wtedy, gdy dane o czasie i uprawnieniach są prawdziwe. Połączenie modelu z Waszymi systemami realizujemy zwykle przez MCP, a pytania do danych serwisowych w języku naturalnym opisaliśmy osobno przy pytaniach do danych firmy. Zakres konsultingu i wdrożeń AI opisaliśmy osobno, stawki znajdziecie w cenniku, a jeśli chcecie sprawdzić, ile kosztują Was dziś drugie wizyty i ile z nich da się usunąć w pierwszym kwartale — umówcie bezpłatną konsultację.