Kierowanie zgłoszeń przez AI, rozpisane od początku do końca.
Przykład krok po kroku: dziesięć tygodni procesu, według którego naprawdę pracujemy, na jednym realistycznym problemie – łącznie z tym, co idzie nie tak. Nazwy i liczby są poglądowe; kolejność, decyzje i kompromisy są dokładnie takie jak w każdym naszym projekcie.
Aktualizacja: 24 września 2026 r.
Załóżmy, że 40-osobowy zespół wsparcia dostaje 4000 zgłoszeń tygodniowo, a dwie osoby całymi dniami zajmują się wyłącznie przekazywaniem ich do właściwych specjalistów.
Pokaż nam swój przypadek- Projekt
- Co wychodzi w trakcie pracy
- Decyzja, która to rozwiązuje
Wyceniamy proces, nie zapytanie
Przeczytaj cały etap: Tydzień 0To przykład poglądowy, a nie historia klienta – scenariusz i liczby są hipotetyczne. Prawdziwy jest sam proces. Takie kierowanie zgłoszeń wymaga wytrenowanego małego modelu, więc projekt trwa dłużej niż wdrożenie dwutygodniowego asystenta.
Jak działają małe prywatne modele Pokaż nam swój przypadek- 01 / 06 Tydzień 0 Scratch
Wyceniamy proces, nie zapytanie
Pierwsze dni spędzamy z dwiema osobami, które faktycznie kierują zgłoszenia. Bierzemy próbkę zgłoszeń z jednego tygodnia, mierzymy czas każdego kroku i wyceniamy proces w takiej postaci, w jakiej działa dziś – a nie takiej, jaką opisuje schemat organizacyjny. Im więcej powiesz nam na tym etapie – o wyjątkach, przypadkach brzegowych i zgłoszeniach, których nikt nie chce brać – tym większa część tego tygodnia pójdzie na ważenie opcji, a nie na dopytywanie. Następnie każde potencjalne zastosowanie oceniamy według czterech kryteriów: wolumenu, kosztu błędu, gotowości danych oraz tego, jaką część pracy model może uczciwie przejąć.
Ryzyko — Zły problemW briefie stoi „zautomatyzować kierowanie zgłoszeń”. Próbka często pokazuje coś innego: jeśli co trzecie zgłoszenie wraca, bo w pierwszej odpowiedzi trzeba było dopytać o numer seryjny, to kierowanie nigdy nie było najdroższą częścią tygodnia.
Decyzja — Wycenić obaWyceniamy oba zadania obok siebie na jednej karcie oceny i budujemy to, które szybciej się zwróci – z najprostszych komponentów, które udźwigną obciążenie. Duży model nie jest automatycznie właściwą odpowiedzią na mały problem, a rozwiązania, które nie potrafi się zwrócić, nie polecimy. Jeśli pierwsze ujęcie nie przekracza progu opłacalności, przeformułowujemy je razem z Tobą – węższy wycinek, inny fragment procesu – aż pojawi się wariant, który warto zbudować; stałą wycenę dostajesz właśnie na niego i sami za nią ręczymy.
- Zmierzony koszt bazowy procesu
- Karta oceny zastosowań
- Stała wycena realizacji
- 02 / 06 Tydzień 1–2 Scratch
Ustalamy, co znaczy „dobrze”, zanim cokolwiek zbudujemy
Model jest tak użyteczny jak miara, którą się go ocenia, dlatego miarę ustalamy najpierw. Bierzemy zgłoszenia z dwunastu miesięcy, z decyzji podjętych już przez Twój zespół budujemy wydzielony zbiór ewaluacyjny i spisujemy próg zaliczenia: jaka dokładność, na jakich segmentach ruchu, przy jakim koszcie na zgłoszenie i kto to ocenia. Tydzień zerowy pokazał, na czym polega problem; tutaj ustalamy, jak faktycznie się go rozwiązuje, zamiast przyjmować odpowiedź, która jedynie wygląda wiarygodnie.
Ryzyko — Zanieczyszczone etykietyHistoryczne przypisania to nie wzorzec prawdy. Zgłoszenia bywają przekazywane dalej raz, dwa, czasem trzy razy, zanim trafią na właściwe miejsce, więc trening na pierwszym przypisaniu uczy model dotychczasowych błędów zespołu, a potem na tych samych błędach się go ocenia. Wynik czyta się jak sukces – i to najdroższy sposób, żeby się mylić.
Decyzja — Etykiety z rozwiązańEtykietę nadajemy według kolejki, która faktycznie rozwiązała zgłoszenie, łańcuch przekazań zachowujemy jako osobny sygnał, a ostatni miesiąc odkładamy na bok, żeby końcowa ewaluacja objęła zgłoszenia, których nic w procesie budowy nigdy nie widziało. Dalej weryfikacja idzie etapami: co model robi, czego robić odmawia i jak zachowuje się każda część bazy wiedzy za nim. Im większa ta baza, tym dłuższy etap – wliczamy ten czas do wyceny, zamiast go skracać.
- Wydzielony zbiór ewaluacyjny
- Spisany próg zaliczenia i osoba odpowiedzialna
- Wskaźniki bazowe dla każdej kolejki
- 03 / 06 Tydzień 3 Prototype
Działający system już w trzecim tygodniu – obok głównego procesu
Dla jasności: to demo – prawdziwy system na prawdziwych danych, ale jeszcze nie gotowy na produkcję. Żadna jego decyzja nie dociera jeszcze do klienta.
Mały klasyfikator i agent kierujący zgłoszenia, wdrożone na Twoim prawdziwym backlogu i pokazane osobom, które dziś robią to ręcznie. To prawdziwe wdrożenie – ta sama ścieżka danych, to samo uwierzytelnianie, te same kolejki – tyle że system niczego jeszcze nie wykonuje: niczego nie decyduje i niczego nie zmienia. Te decyzje musi czytać ktoś po Twojej stronie, kto wie, jak wygląda dobry wynik, a przed końcem tygodnia będzie ich dość na pierwszy uczciwy raport o tym, gdzie system ma rację, a gdzie nie.
Ryzyko — Długi ogonOsiem kolejek obsługuje większość tygodnia. Pozostałe czterdzieści ma po kilkanaście przykładów i właśnie tam pewność siebie robi się kosztowna: wiadomość, która przez trzy akapity czyta się jak reklamacja rachunku, a potem wspomina, że klient widział cudze zamówienie, jest zgłoszeniem bezpieczeństwa. Takich jest dziewięć w roku, a skierowanie go do rozliczeń kosztuje znacznie więcej niż zostawienie go człowiekowi.
Decyzja — Prawo do „nie wiem”Agent może powiedzieć, że nie wie – a przy takim zgłoszeniu „nie jestem pewien, niech ktoś na to spojrzy” jest lepszą odpowiedzią: pewny siebie strzał oparty na błędnym założeniu generuje pracę na miesiące. Próg pewności dostrajamy na zbiorze ewaluacyjnym i przekazujemy Ci krzywą pokrycia względem dokładności, więc kompromis – kierować więcej czy bezpieczniej – to Twoja decyzja, oparta na liczbach. Gdy agent się wstrzymuje, przekazuje zgłoszenie człowiekowi: tak to zaprojektowaliśmy, to nie jest luka.
- Wdrożony prototyp na realnych zgłoszeniach
- Krzywa pokrycie / dokładność
- Sesje z zespołem kierującym zgłoszeniami
- 04 / 06 Tydzień 4–5 Build
Integracja z Twoim stosem, potem dwa tygodnie w trybie cienia
Prototyp staje się częścią systemów, w których ma docelowo działać: Twojego helpdesku, dostawcy tożsamości, grafiku dyżurów. Potem pracuje w trybie cienia – ocenia każde zgłoszenie, ale żadnego nie obsługuje – więc przez dwa tygodnie możesz przeglądać jego prawdziwe decyzje, zanim którakolwiek z nich dotknie choćby jednego klienta.
Ryzyko — Promień rażeniaAgent z kluczem API do helpdesku zwykle może odczytać każdą kolejkę w firmie, również te należące do HR i działu prawnego. To ryzyko integracyjne, które nigdy nie wychodzi podczas demo.
Decyzja — Zakres i logiOsobne konto usługowe na każdą kolejkę, spisana lista dozwolonych działań i wpis w logu audytowym przy każdym odczycie i zapisie. Dzięki trybowi cienia pierwsza decyzja, która dotyczy klienta, jest już tysięczną decyzją systemu.
- Ograniczony dostęp i pełny log audytowy
- Dwa tygodnie decyzji w trybie cienia
- Wycofanie zmian jednym przełącznikiem
- 05 / 06 Tydzień 6–8 Build
Różnica między demo a systemem
Ponawianie prób, ścieżki awaryjne, limity kosztów i test obciążeniowy przy trzykrotności ruchu z Twojego najbardziej obciążonego tygodnia. Alerty trafiają do osoby na dyżurze, a nie na dashboard, którego nikt nie otwiera. Wszystko to musi działać, zanim zespół przestanie pilnować systemu i po prostu zacznie z niego korzystać.
Ryzyko — Dryf kosztu jednostkowegoKoszt na zgłoszenie wydaje się stabilny – dopóki nie trafi się wątek z czterdziestoma wiadomościami i trzema załączonymi PDF-ami. Kilka takich dziennie może po cichu kosztować więcej niż cała reszta kolejki razem wzięta.
Decyzja — Kaskada + limitNajpierw klasyfikuje mały model, a duży wywołujemy tylko przy niskiej pewności. Wątki przycinamy do fragmentów istotnych dla kierowania, a twardy limit na zgłoszenie zatrzymuje rachunek, zanim stanie się tematem rozmowy z Twoim dyrektorem finansowym.
- Limit kosztu na zgłoszenie
- Test obciążeniowy przy 3× szczytu
- Awaryjne przekierowanie do człowieka przy niskiej pewności
- 06 / 06 Tydzień 9–10 Run
Działa, jest monitorowany i wciąż się poprawia
System startuje na hostingu, którym zarządzamy, albo w Twojej własnej chmurze, jeśli wymagają tego Twoje zasady dotyczące danych. Utrzymujemy go, monitorujemy i wdrażamy ulepszenia z rdzenia, gdy tylko się pojawią. W zamian prosimy o wyprzedzenie: gdy zmieniają się dane, gdy zmienia się sposób ich przetwarzania albo gdy ustalasz nowy standard dobrej odpowiedzi, powiedz nam, zanim to wejdzie w życie, a nie potem – żeby system był na to gotowy, zamiast po cichu oddalać się od Twoich oczekiwań.
Ryzyko — Cichy dryfPół roku później rusza nowa linia produktów, struktura zgłoszeń się zmienia, a dokładność niepostrzeżenie spada – system odpowiada równie pewnie jak wcześniej, choć coraz częściej się myli.
Decyzja — Ewaluacja przy każdej zmianieZestaw testów ewaluacyjnych uruchamia się przy każdej zmianie i co miesiąc na świeżej próbce Twoich zgłoszeń. Odsetek wstrzymanych odpowiedzi to wczesne ostrzeżenie: gdy przekroczy próg ustalony w drugim tygodniu, dowiadujemy się o tym jako pierwsi – i Ty też.
- Zarządzany hosting i monitoring
- Ewaluacja przy każdej zmianie i co miesiąc
- Aktualizacje rdzenia i modeli
To przykład poglądowy, a nie historia klienta – scenariusz i liczby są hipotetyczne. Prawdziwy jest sam proces. Takie kierowanie zgłoszeń wymaga wytrenowanego małego modelu, więc projekt trwa dłużej niż wdrożenie dwutygodniowego asystenta.
Jak działają małe prywatne modele Pokaż nam swój przypadekPrzynieś nam jeden proces. Powiemy, czego potrzebuje.
30-minutowa rozmowa. Przynieś jeden prawdziwy proces albo przykładowy dokument. Powiemy, czy potrzeba do tego LLM, małego modelu, czy wystarczy skrypt – i czego by to wymagało. Bez slajdów.