Podobne podejście przyjmuje Service Desk Institute w najnowszym ITSM Tools Buyer’s Guide 2026/27. Przewodnik zwraca uwagę m.in. na konieczność zdefiniowania wymagań przed rozpoczęciem demonstracji, ocenę dopasowania funkcjonalnego, integracji, możliwości skalowania, wsparcia, raportowania i kosztów.

W tegorocznej edycji przewodnika prezentowany jest również Mint Service Desk.

TL;DR: dobry wybór ITSM zaczyna się od określenia problemów i wymagań organizacji. Dopiero później warto porównywać funkcje. Szczególną uwagę należy zwrócić na model wdrożenia, integracje, bezpieczeństwo danych, architekturę AI, możliwości konfiguracji, wdrożenie i całkowity koszt utrzymania systemu.

1. Zacznij od problemu, a nie od listy funkcji

Jednym z najczęstszych błędów przy wyborze systemu ITSM jest rozpoczęcie projektu od ogromnego arkusza funkcjonalności.

Czy system posiada SLA? Tak.
Czy ma automatyzacje? Tak.
Czy obsługuje API? Tak.
Czy posiada portal? Tak.

Po kilkudziesięciu takich pytaniach większość produktów zaczyna wyglądać podobnie.

Problem polega na tym, że odpowiedź „tak” niewiele mówi o tym, jak dana funkcja działa w konkretnym procesie.

Znacznie lepiej rozpocząć od powodów, dla których w ogóle szukacie nowego systemu.

Może obecne narzędzie stało się zbyt kosztowne. Może jego konfiguracja nie odpowiada już sposobowi pracy zespołu. Być może SLA jest pilnowane ręcznie, użytkownicy omijają portal i nadal piszą na wspólną skrzynkę, a informacje o zasobach znajdują się w osobnym systemie.

W innych organizacjach problemem nie jest samo ITSM, ale model wdrożenia: polityka bezpieczeństwa wymaga utrzymania systemu na własnej infrastrukturze albo organizacja nie chce wysyłać danych ze zgłoszeń do zewnętrznych usług AI.

To właśnie takie ograniczenia powinny budować shortlistę dostawców.

‍

2. Cloud, Managed czy On-Premises? Deployment powinien być jednym z pierwszych filtrów

Model wdrożenia jest jednym z kryteriów, które potrafią wyeliminować część narzędzi jeszcze przed pierwszą prezentacją.

Nie istnieje jeden najlepszy model ITSM.

Cloud

SaaS zwykle pozwala uruchomić system szybko i ograniczyć pracę związaną z administracją infrastruktury. Aktualizacje i środowisko utrzymywane są przez dostawcę.

To dobry wybór, jeśli priorytetem są prostota administracji i szybkie uruchomienie.

Managed

Model zarządzany może być kompromisem między klasycznym SaaS a self-hostingiem. Organizacja korzysta z dedykowanego środowiska, natomiast jego technicznym utrzymaniem zajmuje się dostawca.

Przy takim modelu warto dokładnie ustalić, kto zarządza aktualizacjami, backupem, dostępem administracyjnym i infrastrukturą.

On-Premises

Wdrożenie on-premises daje organizacji największą kontrolę nad infrastrukturą i miejscem przetwarzania danych.

Jest szczególnie istotne tam, gdzie decyzję determinują polityki bezpieczeństwa, architektura sieci, wymagania dotyczące danych, integracje wewnętrzne lub konieczność uruchamiania AI lokalnie.

Jednocześnie większa kontrola oznacza większą odpowiedzialność za własne środowisko.

Mint Service Desk jest rozwijany w kilku modelach wdrożenia, a aktualne warianty i zakres funkcjonalności można sprawdzić w cenniku Mint Service Desk.

‍

‍

3. Sprawdzaj proces, nie obecność funkcji

Feature checklist ma sens dopiero wtedy, kiedy podstawowe wymagania są już znane.

W przypadku zgłoszeń nie pytaj tylko:

Czy system ma workflow?

Poproś dostawcę o pokazanie rzeczywistego procesu.

Przykładowo: pracownik zgłasza potrzebę dostępu do systemu. W zależności od działu, stanowiska lub aplikacji zgłoszenie może wymagać akceptacji przełożonego, później trafić do konkretnej kolejki, uruchomić SLA i automatycznie powiadomić użytkownika o wykonaniu zadania.

Dopiero na takim scenariuszu można zobaczyć, czy proces będzie wymagał prostej konfiguracji, czy dodatkowych prac wdrożeniowych.

To samo dotyczy incydentów, reklamacji, onboardingu, wniosków sprzętowych czy procesów ESM obejmujących HR, administrację i finanse.

Dlatego na demo warto przyjść z 3–5 własnymi procesami.

Jeżeli planujesz przejście z prostego help desku do bardziej uporządkowanego ITSM, przeczytaj również: Mint Service Desk: migracja z help desk do systemu ITSM.

4. „Mamy API” nie oznacza jeszcze łatwej integracji

Service Desk rzadko działa jako izolowany system.

W typowym środowisku może wymieniać informacje z Active Directory, systemem HR, platformą do zarządzania endpointami, monitoringiem, pocztą, CRM, ERP czy rozwiązaniem do inwentaryzacji zasobów.

Dlatego pytanie „czy macie API?” jest dopiero początkiem.

Warto ustalić, czy API jest dostępne w wybranej wersji produktu, w jaki sposób odbywa się autoryzacja, jakie istnieją gotowe integracje, kto utrzymuje połączenie i co stanie się po aktualizacji jednego z systemów.

Jeżeli organizacja korzysta z platformy do discovery, warto też sprawdzić, czy dane o zasobach mogą być dostępne bezpośrednio podczas obsługi zgłoszenia.

Przykładem takiego podejścia jest integracja Mint Service Desk z Lansweeper, gdzie dane wykrywane przez platformę Lansweeper mogą być synchronizowane z systemem service desk i powiązane ze zgłoszeniami.

5. Asset Management i CMDB to nie zawsze to samo wymaganie

W dokumentach zakupowych często pojawia się wymaganie „CMDB”, mimo że organizacji faktycznie zależy przede wszystkim na ewidencji zasobów.

Warto je rozdzielić.

Jeżeli agent potrzebuje wiedzieć, jaki komputer posiada zgłaszający, jakie oprogramowanie jest na nim zainstalowane albo jakie wcześniejsze zgłoszenia były z nim związane, odpowiednio zintegrowane Asset Management może być wystarczające.

Jeżeli natomiast organizacja potrzebuje modelowania Configuration Items, zależności między usługami, aplikacjami i infrastrukturą oraz prowadzenia zaawansowanej analizy wpływu, wymagania są znacznie szersze.

Dlatego przed wpisaniem „CMDB” jako obowiązkowego punktu w RFP warto odpowiedzieć:

Jaką konkretną decyzję operacyjną ma nam umożliwiać CMDB?

Mint Service Desk może wykorzystywać dane o zasobach m.in. z Lansweeper, baramundi lub importu CSV i łączyć je z obsługą zgłoszeń. Na stronie poświęconej Asset Management Mint wprost rozróżnia tę funkcjonalność od natywnej CMDB.

To ważne również przy porównywaniu dostawców: dwie funkcje opisane w tabeli jako „CMDB” mogą oznaczać zupełnie różny zakres.

6. Nie pytaj tylko, czy system ITSM ma AI

W 2026 roku samo określenie „AI-powered” mówi coraz mniej.

W praktyce sztuczna inteligencja w Service Desk może wykonywać bardzo różne zadania: podsumowywać długą historię zgłoszenia, proponować odpowiedź, klasyfikować sprawę, wspierać routing lub wyszukiwać podobne przypadki.

Ale funkcjonalność to tylko połowa pytania.

Druga brzmi:

Co dzieje się z danymi zgłoszenia, kiedy zaczyna je analizować model AI?

Treść ticketu może zawierać nazwiska, dane klientów, nazwy systemów, informacje o infrastrukturze, logi, wewnętrzną korespondencję albo dane dotyczące incydentu bezpieczeństwa.

Dlatego przed włączeniem AI warto ustalić przede wszystkim, jakie dane otrzymuje model, gdzie działa, czy informacje opuszczają środowisko organizacji, czy są przechowywane przez zewnętrznego dostawcę oraz czy są wykorzystywane do dalszego trenowania.

W wersji On-Premises Mint Service Desk moduł AI może działać lokalnie, we własnej infrastrukturze organizacji, bez konieczności przesyłania danych ze zgłoszeń do zewnętrznego modelu chmurowego. Więcej informacji znajduje się na stronie: AI On-Premises w Mint Service Desk.

‍

‍

7. Self-service trzeba testować z perspektywy pracownika

Portal samoobsługowy może mieć dziesiątki funkcji, ale jego sukces zależy od jednego: czy ludzie rzeczywiście będą z niego korzystać.

Dlatego podczas testów systemu nie warto ograniczać się do widoku administratora.

Daj pracownikowi, który nie uczestniczy w projekcie, trzy zadania:

zgłoszenie awarii, zamówienie dostępu oraz sprawdzenie statusu istniejącej sprawy.

Jeżeli użytkownik nie wie, którą kategorię wybrać, formularz wymaga informacji, których nie rozumie, albo nie potrafi znaleźć statusu sprawy, istnieje duże ryzyko, że po uruchomieniu systemu wróci do wysyłania e-maili.

Self-service jest więc nie tylko funkcją.

Jest problemem adopcji.

8. Dashboard nie jest jeszcze raportowaniem

Większość współczesnych systemów ITSM posiada dashboard.

Znacznie ważniejsze jest to, czy system potrafi odpowiedzieć na konkretne pytania operacyjne.

Gdzie rośnie backlog? Które SLA są zagrożone? Jakie typy zgłoszeń pojawiają się coraz częściej? Jak długo faktycznie trwa obsługa? Który proces generuje najwięcej ręcznej pracy?

Przed zakupem dobrze jest poprosić o przygotowanie dwóch lub trzech raportów odpowiadających na rzeczywiste pytania organizacji.

Jeżeli każda odpowiedź wymaga eksportu danych do Excela i ręcznego łączenia kilku zestawień, raportowanie może wyglądać dobrze podczas demo, ale nie rozwiąże problemu po wdrożeniu.

9. Zapytaj o wdrożenie, zanim podpiszesz umowę

Dobre narzędzie nie gwarantuje dobrego projektu.

Przed wyborem dostawcy trzeba wiedzieć, kto odpowiada za konfigurację, migrację danych, przygotowanie integracji, testy i szkolenie użytkowników.

Szczególnie dokładnie warto ustalić zakres migracji.

Czy naprawdę potrzebujesz dziesięciu lat starych ticketów?

Czy ważniejsze są artykuły bazy wiedzy?

Co z załącznikami, użytkownikami, polami niestandardowymi, historią zasobów i konfiguracją SLA?

Migracja wszystkiego „bo możemy” nie zawsze jest najlepszym rozwiązaniem. Często generuje dodatkowy koszt i komplikuje start nowego środowiska bez proporcjonalnej wartości biznesowej.

10. Porównuj TCO, nie tylko cenę licencji

Cena „za agenta miesięcznie” jest łatwa do porównania.

Niestety nie pokazuje całkowitego kosztu systemu.

Na Total Cost of Ownership mogą wpływać również wdrożenie, migracja danych, infrastruktura, integracje, płatne moduły, dodatkowe środowiska, przestrzeń dyskowa, konsultacje oraz administracja platformą.

Warto również sprawdzić, jak zmieni się cena po zwiększeniu liczby agentów, zasobów albo działów korzystających z systemu.

Dobrym rozwiązaniem jest policzenie nie jednego miesiąca, ale scenariusza trzyletniego:

Ile platforma będzie kosztować przy obecnej skali, a ile po jej przewidywanym wzroście?

Aktualne modele licencyjne Mint Service Desk można sprawdzić bezpośrednio w cenniku.

11. Nie oceniaj systemu wyłącznie na podstawie demo

Demo odpowiada przede wszystkim na pytanie:

„Czy system potrafi wykonać daną czynność?”

Decyzja zakupowa musi odpowiedzieć na szersze:

„Czy będziemy w stanie dobrze pracować na tym systemie przez kolejne lata?”

Dlatego po prezentacji warto ocenić wszystkich dostawców według tych samych kryteriów.

‍

‍

‍

Wagi nie powinny być identyczne dla każdej organizacji.

Dla firmy regulowanej deployment i bezpieczeństwo mogą stanowić 30% decyzji. Dla niewielkiego zespołu znacznie ważniejsze mogą być prostota i czas uruchomienia.

Najważniejsze jest, aby kryteria zostały ustalone przed wyborem zwycięzcy.

Jak Service Desk Institute podchodzi do wyboru ITSM?

W ITSM Tools Buyer’s Guide 2026/27 Service Desk Institute również podkreśla, że długa lista funkcji nie wystarcza do właściwego porównania platform.

W przewodniku pojawiają się m.in. takie kryteria jak:

incident, problem i change management, service request i catalogue management, automatyzacja workflow, asset i configuration management, raportowanie, self-service, integracje i API oraz skalowalność.

Co ważniejsze, SDI zwraca uwagę również na kwestie wykraczające poza funkcjonalność: czas wdrożenia, jakość onboardingu i wsparcia, raportowanie dla różnych interesariuszy czy skalowanie bez nieplanowanych kosztów.

Jedna z najbardziej praktycznych wskazówek z przewodnika sprowadza się do prostej zasady:

najpierw dokładnie zdefiniuj wymagania, dopiero później umawiaj demonstracje.

To ogranicza ryzyko wybierania narzędzia na podstawie najlepszego sales demo zamiast najlepszego dopasowania.

Gdzie w tym porównaniu znajduje się Mint Service Desk?

Mint Service Desk jest platformą ITSM/ESM przeznaczoną do zarządzania zgłoszeniami i procesami usługowymi. System może być wykorzystywany m.in. do ticket management, SLA, automatyzacji, self-service, raportowania oraz pracy z danymi o zasobach.

Szczególne znaczenie ma możliwość dopasowania modelu wdrożenia do wymagań organizacji oraz wariant On-Premises, w którym infrastruktura pozostaje pod kontrolą klienta.

W On-Premises dostępny jest również lokalny moduł AI, którego zadaniem jest wspieranie pracy z ticketami bez przesyłania ich treści do zewnętrznych modeli chmurowych.

Nie oznacza to jednak, że Mint powinien znaleźć się na każdej shortliście.

Jeżeli kluczowym wymaganiem organizacji jest na przykład rozbudowana, natywna CMDB do modelowania skomplikowanych zależności infrastrukturalnych, trzeba ocenić ten obszar osobno. Jeżeli natomiast priorytetem są kontrola nad deploymentem, elastyczne procesy service desk, integracja danych o zasobach ze zgłoszeniami i możliwość lokalnego wykorzystania AI, Mint Service Desk jest rozwiązaniem, które warto uwzględnić w porównaniu.

FAQ: wybór systemu ITSM

Jak wybrać system ITSM?

Najpierw należy określić problemy, które ma rozwiązać system, oraz wymagania obowiązkowe. Następnie warto porównać dostawców pod kątem procesów ITSM, modelu wdrożenia, bezpieczeństwa, integracji, automatyzacji, raportowania, doświadczenia użytkownika, wdrożenia i całkowitego kosztu posiadania.

Czym różni się Service Desk od systemu ITSM?

Service Desk koncentruje się przede wszystkim na obsłudze użytkowników i zgłoszeń. ITSM obejmuje szersze zarządzanie usługami IT i może uwzględniać m.in. SLA, knowledge management, service requests, problem management, asset management, automatyzację i raportowanie.

Cloud czy On-Premises — który ITSM jest lepszy?

Nie ma jednego najlepszego modelu. Cloud zmniejsza odpowiedzialność za infrastrukturę i zazwyczaj pozwala szybciej uruchomić środowisko. On-Premises zapewnia większą kontrolę nad serwerami, danymi i integracjami. Wybór powinien wynikać z polityki bezpieczeństwa, kompetencji zespołu, architektury organizacji i kosztów.

Czy system ITSM musi posiadać CMDB?

Nie każda organizacja potrzebuje pełnej CMDB. Jeżeli wymaganiem jest głównie ewidencja urządzeń i powiązanie ich ze zgłoszeniami, Asset Management może być wystarczający. CMDB staje się istotna, gdy konieczne jest modelowanie relacji między Configuration Items oraz analiza zależności i wpływu.

Na co zwrócić uwagę przy AI w ITSM?

Oprócz samych funkcji należy sprawdzić, jakie dane przetwarza model, gdzie odbywa się przetwarzanie, czy informacje opuszczają środowisko organizacji, jak długo są przechowywane i czy dostawca wykorzystuje je do trenowania modeli.

Ile kosztuje system ITSM?

Cena licencji jest tylko jednym składnikiem. W TCO należy uwzględnić również wdrożenie, migrację, integracje, infrastrukturę, płatne moduły, administrację i koszt skalowania systemu wraz ze wzrostem organizacji.

Czy warto przenosić wszystkie stare zgłoszenia do nowego ITSM?

Nie zawsze. Warto ustalić, które informacje mają nadal wartość operacyjną, biznesową lub prawną. Migracja całej wieloletniej historii może znacząco zwiększyć koszt i zakres projektu bez zapewnienia proporcjonalnych korzyści.

Funkcje nie wybierają systemu. Wymagania już tak.

Rynek ITSM oferuje wiele produktów potrafiących skutecznie rejestrować i obsługiwać zgłoszenia.

Prawdziwe różnice pojawiają się gdzie indziej: w architekturze, deployment modelu, integracjach, bezpieczeństwie, możliwościach konfiguracji, wdrożeniu i kosztach utrzymania.

Dlatego zamiast pytać:

„Który system ma najwięcej funkcji?”

lepiej zacząć od:

„Które wymagania naszej organizacji są niepodlegające negocjacji?”

Dopiero wtedy porównanie dostawców zaczyna mieć sens.

Jeżeli chcesz sprawdzić, jak Mint Service Desk wypada w kontekście Twoich wymagań, możesz zobaczyć możliwości platformy albo umówić prezentację.