Case Study: Loomi. Jak agenci AI zautomatyzowali obsługę 13 000 zgłoszeń miesięcznie w Jira Service Desk
Wiele projektów AI zaczyna się od poszukiwania najlepszego modelu językowego. My zaczęliśmy od zdefiniowania problemu: jak odciążyć Service Desk z ręcznego triażu, routingu i wyszukiwania wiedzy przy tysiącach zgłoszeń miesięcznie.

Efektem tego podejścia jest Loomi – nasz autorski agent AI działający bezpośrednio w środowisku Jira Service Desk. W przeciwieństwie do klasycznego chatbota Loomi nie czeka na pytanie użytkownika, ale działa bezpośrednio w procesie obsługi zgłoszeń.
System każdego miesiąca automatycznie analizuje, klasyfikuje i rozdziela około 13 tysięcy zgłoszeń. Dla 6–8 tysięcy z nich przygotowuje sugerowane rozwiązania. Nie każda podpowiedź jest bezbłędna, ale skuteczność systemu pokazuje, że dobrze zaprojektowana automatyzacja może realnie odciążyć zespoły wsparcia. Zanim jednak przejdziemy do szczegółów technicznych, warto pokazać, jak to wszystko się zaczęło.
Loomi nie jest wynikiem wielomiesięcznego, odgórnie narzuconego programu transformacji cyfrowej. System powstał z inicjatywy Pawła Wójcika, IT Specialist w Silky Coders, który na co dzień mierzył się z dużą liczbą powtarzalnych zadań. To on samodzielnie opracował koncepcję, zaprojektował architekturę i zbudował rozwiązanie techniczne od pierwszego prototypu aż po wdrożenie produkcyjne.
Dziś w rozwój Loomi i zasilanie jego bazy wiedzy zaangażowane są zespoły IT, ale fundament systemu powstał jako inicjatywa jednej osoby. To przykład tego, jak oddolny pomysł może przerodzić się w realne, działające wdrożenie, które wspiera organizację na dużą skalę.
Jaki problem rozwiązuje automatyzacja zgłoszeń w Service Desk?
Każdego dnia do zespołów wsparcia trafiały setki zgłoszeń dotyczących wielu obszarów działania organizacji: systemów biurowych, logistyki, e-commerce, wsparcia sklepów stacjonarnych czy infrastruktury IT.
Zanim ekspert mógł zająć się faktycznym rozwiązaniem problemu, zgłoszenie musiało zostać przeczytane, zinterpretowane i ręcznie przypisane do właściwej grupy. Przy dużej skali operacyjnej oznaczało to tysiące rutynowych decyzji podejmowanych każdego miesiąca.
Właśnie tam pojawiło się największe wąskie gardło. Nie w samym rozwiązywaniu problemów, ale w ich klasyfikacji, routingu i wyszukiwaniu właściwej wiedzy. To był obszar, w którym automatyzacja mogła przynieść największą wartość.
W praktyce Service Desk potrzebował rozwiązania, które nie tylko podpowie odpowiedź, ale usprawni cały proces obsługi zgłoszenia: od jego rozpoznania, przez routing do właściwego zespołu, aż po przygotowanie sugestii rozwiązania w oparciu o firmową bazę wiedzy.

Od niedziałającego chatbota do agenta w procesie
Początkowy plan był prosty: stworzyć chatbota, który korzystałby z firmowej dokumentacji i podpowiadał technikom gotowe odpowiedzi. Założenie wydawało się logiczne. W praktyce szybko okazało się jednak, że zanim AI zacznie skutecznie wspierać proces, trzeba rozwiązać znacznie bardziej podstawowy problem.
Dokumentacja nie była gotowa na wykorzystanie przez algorytmy. Część materiałów była nieaktualna, a historycznym zgłoszeniom brakowało spójnego kontekstu. W efekcie technicy często szybciej rozwiązywali problemy samodzielnie, niż korzystali z pierwszej wersji bota.
To był moment zwrotny. Można było dalej rozwijać system oparty na nieuporządkowanych danych albo zrobić krok w tył i zmienić podejście.
Wybraliśmy drugą opcję.
Zamiast budować rozwiązanie na wiedzy, która nie była jeszcze gotowa, skupiliśmy się na tym fragmencie procesu, dla którego mieliśmy twarde dane. Zrezygnowaliśmy z idei „bota, który wie wszystko” i zbudowaliśmy dispatchera – komponent odpowiedzialny wyłącznie za rozdzielanie zgłoszeń na podstawie ich tematu i treści.
Efekt był szybki i mierzalny. System zaczął poprawnie przypisywać ponad 70% zgłoszeń. To potwierdziło potencjał rozwiązania i dało podstawę do dalszego rozwoju – już nie jako prostego chatbota, ale jako agenta głęboko osadzonego w konkretnym procesie biznesowym.
Modułowa architektura i technologia
Kolejnym krokiem było zaprojektowanie Loomi w oparciu o architekturę wyspecjalizowanych agentów AI. Nie budowaliśmy jednego, trudnego w utrzymaniu monolitu. Zamiast tego postawiliśmy na niezależne moduły odpowiadające za konkretne zadania.
Jeden z nich odpowiada za routing zgłoszeń, inny analizuje załączniki, a kolejny przeszukuje bazę wiedzy i przygotowuje sugestie rozwiązań. Taki podział daje większą kontrolę nad jakością działania systemu i pozwala rozwijać go krok po kroku, bez przebudowy całej architektury.
Od strony technologicznej Loomi łączy Jira Service Desk z warstwą AI opartą o Google Cloud i Vertex AI. System wykorzystuje modele Gemini, wyszukiwanie semantyczne, mechanizmy rankingowe oraz architekturę RAG, czyli Retrieval-Augmented Generation. Dzięki temu odpowiedzi są generowane na podstawie firmowej bazy wiedzy, a nie swobodnych domysłów modelu.
Przyjęliśmy jedną kluczową zasadę: zero halucynacji. Loomi opiera odpowiedzi wyłącznie na wiedzy organizacyjnej. Jeśli nie znajduje wystarczająco konkretnych informacji w zweryfikowanej bazie, nie próbuje zgadywać. Po prostu nie podaje sugestii.
Użytkownik Service Desku nie potrzebuje elokwentnego asystenta. Potrzebuje informacji, na których może polegać.

Efekty i wymierna wartość biznesowa
Liczby dobrze pokazują skalę wdrożenia. Dziś Loomi analizuje około 13 tysięcy zgłoszeń miesięcznie. Skuteczność automatycznego routingu wynosi około 92% w skali całego Service Desku, a w wybranych, bardziej ustandaryzowanych obszarach sięga 97%.
Najważniejszy efekt nie sprowadza się jednak wyłącznie do statystyk. Zespoły wsparcia odzyskały czas, który wcześniej poświęcały na ręczną segregację zgłoszeń. Automatyzacja routingu i klasyfikacji zgłoszeń w Jira Service Desk przejęła część powtarzalnych zadań, dzięki czemu specjaliści mogą skupić się na sprawach wymagających doświadczenia, analizy i wiedzy eksperckiej.
Wraz z rozwojem Loomi wdrożyliśmy też nowe podejście do zarządzania wiedzą. Każdy dobrze opisany przypadek, nowa instrukcja czy artykuł mogą zasilić system i zwiększyć jego skuteczność. Dzięki temu Loomi nie jest rozwiązaniem zamkniętym raz na zawsze, ale narzędziem, które rozwija się razem z organizacją.
To jedna z najważniejszych lekcji z projektu: skuteczne wdrożenie AI nie zaczyna się od wyboru modelu, ale od dobrze zdefiniowanego problemu, jakości danych i zrozumienia procesu, który chcemy usprawnić. W przypadku Loomi dopiero zmiana perspektywy – z „AI, które odpowiada” na „AI, które działa w procesie” – pozwoliła stworzyć rozwiązanie przynoszące realną wartość. To właśnie ta zmiana sprawiła, że Loomi przestał być eksperymentem AI, a stał się realnym elementem procesu Service Desk.



















