Dwie oferty, dwie liczby. Pierwsza obiecuje reakcję w 15 minut, druga w 4 godziny. Wybór wydaje się oczywisty – do momentu, w którym poczta przestaje działać w środę o dziewiątej rano i okazuje się, że owe 15 minut oznacza automatyczne potwierdzenie przyjęcia zgłoszenia, a technik zaczyna pracę po południu.
Skrót SLA rozwija się jako Service Level Agreement – umowa o poziomie świadczenia usług. Kupujący czytają go zwykle jako obietnicę szybkiej naprawy. To nieporozumienie kosztuje potem miesiące frustracji po obu stronach, bo dostawca formalnie dotrzymuje warunków, a klient czuje się oszukany. Obaj mają rację, bo mówią o dwóch różnych rzeczach.
SLA nie jest obietnicą, że każdą awarię da się usunąć w godzinę. Jest opisem tego, jak szybko ktoś się zgłoszeniem zajmie, w jakiej kolejności, kto o tym decyduje, kiedy sprawa idzie wyżej i jak to wszystko zostanie zmierzone. Innymi słowy: SLA IT kupuje przewidywalność, nie prędkość.
Ten materiał wyjaśnia mechanikę, a nie ofertę. Wszystkie liczby są przykładami ilustrującymi zasadę – nie są to wartości, do których zobowiązuje się NexaIT ani jakikolwiek inny dostawca.
Spis treści
- Co dokładnie mierzy SLA
- Reakcja, diagnoza, obejście i rozwiązanie
- Priorytety P1–P4 z przykładami
- Kiedy biegnie i zatrzymuje się czas
- Zależności od klienta i dostawców
- Raport SLA dla zarządu
- Jak porównywać oferty
- Przykładowa oś incydentu
Co dokładnie mierzy SLA
Zacznijmy od uporządkowania trzech pojęć, które w rozmowach handlowych bywają używane zamiennie, choć znaczą co innego.
SLA to zobowiązanie umowne – poziom usługi, do którego dostawca się zobowiązuje, zwykle z konsekwencjami niedotrzymania. SLO to cel wewnętrzny, który dostawca sobie stawia; bywa ostrzejszy niż SLA, bo daje margines. KPI to miernik, którym mierzy się jakość – sam w sobie nie jest zobowiązaniem.
Ma to praktyczne znaczenie przy czytaniu ofert. Zdanie „nasz średni czas reakcji to 12 minut” opisuje KPI za jakiś okres, a nie zobowiązanie. Średnia z zeszłego kwartału nie mówi nic o tym, co się stanie z Twoim zgłoszeniem w piątek o 16:50.
SLA w obsłudze IT składa się zwykle z kilku niezależnych elementów:
- Czas reakcji – po jakim czasie dostawca podejmie działanie po przyjęciu zgłoszenia.
- Czas obejścia – po jakim czasie przywróci działanie, choćby prowizorycznie.
- Czas rozwiązania – po jakim czasie usunie przyczynę.
- Godziny serwisowe – okno, w którym te czasy w ogóle biegną.
- Dostępność – jaki procent czasu usługa ma działać.
- Priorytety – jak klasyfikowane są zgłoszenia i kto o tym decyduje.
Osobnego komentarza wymaga dostępność, bo to najczęściej mylony parametr. Zapis o dostępności 99,9% w skali miesiąca dopuszcza około 43 minuty niedostępności (30 dni × 24 h × 60 min × 0,1% = 43,2 minuty). Ale to parametr usługi – zwykle konkretnego systemu albo łącza – a nie zobowiązanie do naprawy dowolnej awarii w 43 minuty. Dostępność i czas naprawy to dwie różne obietnice o dwóch różnych rzeczach.
Reakcja, diagnoza, obejście i rozwiązanie
Jedno zgłoszenie przechodzi przez cztery etapy. Mylenie ich to źródło większości sporów o SLA.
Reakcja. Ktoś przejmuje zgłoszenie i zaczyna nad nim pracować. Uwaga na pułapkę: automatyczna wiadomość „przyjęliśmy Twoje zgłoszenie, numer 4417″ nie jest reakcją – to potwierdzenie rejestracji. Jeśli oferta chwali się reakcją w minutę, warto dopytać, czy chodzi o człowieka, czy o skrypt. Miarą tego etapu bywa MTTA – średni czas do podjęcia zgłoszenia.
Diagnoza. Ustalenie, co się właściwie stało i jak szeroki jest problem. Ten etap bywa najdłuższy i najtrudniejszy do zobowiązania czasowego, bo nie da się z góry wiedzieć, czy przyczyną jest zepsuty kabel, czy awaria u operatora.
Obejście. Przywrócenie działania bez usuwania przyczyny. Drukarka w księgowości padła, ale dokumenty da się drukować na urządzeniu obok. Serwer aplikacji nie wstaje, ale użytkownicy pracują na zapasowej instancji. Firma działa – problem nadal istnieje.
Rozwiązanie. Usunięcie przyczyny. Nowa drukarka, naprawiony serwer, wymieniony przełącznik.
Rozdzielenie obejścia od rozwiązania jest kluczowe z dwóch powodów. Po pierwsze, dla firmy zwykle liczy się obejście – moment, w którym ludzie wracają do pracy. Po drugie, to najczęstsze miejsce nadużycia w raportach: dostawca zamyka zgłoszenie na etapie obejścia i wykazuje świetny czas rozwiązania. Formalnie awaria „rozwiązana”, faktycznie firma pracuje na prowizorce, a przyczyna czeka na powtórkę.
Dobrze skonstruowane SLA opisuje oba czasy osobno i wymaga, żeby zgłoszenie pozostawało otwarte do usunięcia przyczyny – nawet jeśli z niższym priorytetem. Miarą całości bywa MTTR, czyli średni czas przywrócenia usługi; wartość ta ma sens tylko wtedy, gdy wiadomo, czy mierzy obejście, czy rozwiązanie.
Priorytety P1-P4 z przykładami
Priorytet nie jest oceną tego, jak bardzo ktoś jest zdenerwowany. Powinien wynikać z dwóch zmiennych: wpływu (ile osób i procesów dotyczy) oraz pilności (czy da się poczekać).
Poniższa tabela jest przykładem edukacyjnym, pokazującym typową logikę klasyfikacji. Konkretne definicje i czasy zawsze wynikają z umowy z danym dostawcą.
| Priorytet | Kiedy | Przykład | Typowe oczekiwanie |
|---|---|---|---|
| P1 – krytyczny | Zatrzymana działalność lub proces przynoszący przychód | Nie działa serwer ERP, cała firma nie wystawia dokumentów. Awaria łącza w jedynej lokalizacji. Podejrzenie ataku ransomware | Natychmiastowe podjęcie, praca ciągła, obejście priorytetem nad rozwiązaniem |
| P2 – wysoki | Poważne utrudnienie, obejście istnieje lub dotyczy części firmy | Nie działa poczta w jednym dziale. Awaria drukarki etykiet przy jednej linii, gdy jest druga | Podjęcie w krótkim, uzgodnionym czasie w godzinach serwisowych |
| P3 – normalny | Pojedynczy użytkownik, praca jest możliwa | Wolno działający komputer. Problem z jedną aplikacją u jednej osoby | Podjęcie w ramach standardowego okna |
| P4 – niski | Wniosek, zmiana, zapytanie | Nowe stanowisko za dwa tygodnie. Prośba o dodatkowe uprawnienia | Realizacja planowa, w uzgodnionym terminie |
Trzy rzeczy warto ustalić przy podpisywaniu umowy.
Kto nadaje priorytet. Jeśli robi to wyłącznie dostawca, ma wbudowaną zachętę do zaniżania – niższy priorytet to luźniejszy licznik. Jeśli wyłącznie klient, wszystko będzie krytyczne w ciągu miesiąca. Rozsądny model: klient proponuje, dostawca może zmienić z uzasadnieniem, a klient ma ścieżkę odwołania do wskazanej osoby.
Że priorytet może się zmienić. Zgłoszenie zaczyna jako P3 „wolno działa aplikacja”, a po diagnozie okazuje się P1 „dysk macierzy się sypie”. Umowa powinna dopuszczać eskalację i przeliczenie licznika.
Że P1 kosztuje. Wytyczne brytyjskiego National Cyber Security Centre (publikacja 24.11.2025, przegląd 24.06.2026) zwracają uwagę na rzecz, którą łatwo przeoczyć w negocjacjach: szybsza reakcja podnosi koszt umowy. Nie da się mieć jednogodzinnej reakcji w cenie dziennej. Jeśli oferta obiecuje jedno w cenie drugiego, coś innego zostało z niej wycięte.
Kiedy biegnie i zatrzymuje się czas
Tutaj mieszka większość realnych nieporozumień. Sama liczba w ofercie nic nie znaczy, dopóki nie wiadomo, jak jest liczona.
Od kiedy biegnie licznik. Od momentu wysłania zgłoszenia przez użytkownika czy od jego zarejestrowania w systemie dostawcy? Przy zgłoszeniu telefonicznym o 8:58, gdy wsparcie zaczyna o 9:00, różnica bywa istotna. Zdrowa zasada: licznik startuje w momencie wpłynięcia zgłoszenia kanałem opisanym w umowie.
I to jest odpowiedź na pytanie, dlaczego kanał zgłoszeń ma znaczenie. Problem zgłoszony SMS-em do technika, którego akurat znasz, zwykle nie uruchamia żadnego licznika, bo nie trafia do systemu.
Godziny serwisowe. To decyduje o rzeczywistym czasie oczekiwania bardziej niż sama liczba. Cztery godziny reakcji w oknie 8:00-16:00 oznaczają, że zgłoszenie z 15:30 może czekać do 9:30 następnego dnia – i formalnie SLA zostanie dotrzymane. Ta sama „reakcja w 4 godziny” w trybie całodobowym to zupełnie inna usługa i inna cena.
Warto też ustalić, co dzieje się w weekendy i święta oraz czy istnieje osobny tryb dla awarii krytycznych poza godzinami. Wiele umów przewiduje tryb dyżurny dla P1 przy standardowym oknie dla reszty.
Co zatrzymuje licznik. Pauza jest uzasadniona, gdy sprawa czeka na coś, czego dostawca nie kontroluje. Typowe przypadki:
- oczekiwanie na informację lub decyzję klienta;
- oczekiwanie na dostęp do pomieszczenia albo urządzenia;
- oczekiwanie na dostawę części;
- oczekiwanie na odpowiedź producenta oprogramowania;
- oczekiwanie na usunięcie awarii u operatora łącza;
- zaplanowane okno serwisowe.
Zasada, która chroni obie strony: pauza musi być widoczna w systemie zgłoszeń wraz z powodem i godziną. Licznik zatrzymany po cichu i odkryty przy raporcie miesięcznym niszczy zaufanie skuteczniej niż przekroczone SLA.
Okna serwisowe. Zaplanowane prace nie powinny wliczać się do niedostępności – pod warunkiem że zostały zapowiedziane z uzgodnionym wyprzedzeniem. Bez tego zastrzeżenia „planowana konserwacja” staje się wygodnym workiem na wszystko.
Zależności od klienta i dostawców
SLA jest zobowiązaniem dwustronnym, choć oferty rzadko to podkreślają. Dostawca odpowiada za to, na co ma wpływ – i tylko za to.
NCSC wskazuje w cytowanych wytycznych, że umowa powinna jasno określać, za co odpowiada dostawca, a co pozostaje po stronie klienta. W kontekście SLA oznacza to spisanie obowiązków klienta:
- zgłaszanie problemów ustalonym kanałem;
- zapewnienie dostępu do pomieszczeń i urządzeń;
- wskazanie osoby decyzyjnej i jej dostępność;
- podejmowanie decyzji zakupowych w rozsądnym czasie;
- niewprowadzanie zmian w środowisku poza wiedzą dostawcy.
Ostatni punkt bywa źródłem najbardziej gorzkich sporów. Jeśli ktoś w firmie samodzielnie przekonfiguruje router, dostawca odpowiada za skutki na tyle, na ile w ogóle o zmianie wie.
Osobna kategoria to zależności od podmiotów trzecich: operatorów łączy, producentów oprogramowania, serwisów sprzętu. Dostawca IT nie naprawi światłowodu przekopanego przez koparkę – może zgłosić awarię, eskalować i pilnować, ale nie odpowiada za czas usunięcia. Umowa powinna to nazywać, a raport pokazywać osobno.
To nie jest wymówka dostawcy, tylko warunek uczciwości SLA. Zobowiązanie do rzeczy, na które nie ma się wpływu, jest albo nieuczciwe, albo wliczone w cenę jako ryzyko – i wtedy płacisz za nie w abonamencie.
Warto przy okazji zapytać o podwykonawców samego dostawcy. NCSC zaleca ocenę ryzyka łańcucha dostaw i wskazuje, że umowa powinna obejmować odpowiedzialność za podmioty trzecie wykorzystywane do świadczenia usługi.
Raport SLA dla zarządu
Raport, który jest listą zamkniętych zgłoszeń, nie jest raportem SLA. Zarządu nie interesuje, że zamknięto 47 zgłoszeń – interesuje go, czy firma jest stabilna i co grozi w przyszłym kwartale.
Użyteczny raport miesięczny odpowiada na pięć pytań:
- Ile było zgłoszeń w podziale na priorytety i jak to wygląda na tle poprzednich miesięcy. Rosnąca liczba P1 to sygnał, że coś się psuje strukturalnie.
- Czy SLA zostało dotrzymane – z osobnym wykazaniem przypadków przekroczenia i ich przyczyn. Raport bez ani jednego przekroczenia przez rok jest podejrzany, nie dobry.
- Ile czasu licznik był zatrzymany i dlaczego. To pokazuje, gdzie proces zacina się po stronie klienta.
- Co się powtarza. Pięć zgłoszeń miesięcznie o tej samej drukarce to nie pięć incydentów, tylko jeden nierozwiązany problem.
- Co wymaga decyzji i pieniędzy. Sprzęt bez wsparcia, kończące się licencje, zidentyfikowane ryzyka.
Warto poprosić o przykładowy raport przed podpisaniem umowy. To jeden z najlepszych testów dojrzałości dostawcy: firma, która ma proces, pokaże zanonimizowany dokument bez wahania.
Jak porównywać oferty
Zestawianie samych liczb prowadzi na manowce. Poniższa lista pytań sprowadza oferty do wspólnego mianownika:
- Czy podana liczba dotyczy reakcji, obejścia czy rozwiązania?
- Reakcja oznacza działanie człowieka czy automatyczne potwierdzenie?
- Jakie są godziny serwisowe i jak liczony jest czas poza nimi?
- Kto nadaje priorytet i jak mogę się odwołać?
- Co zatrzymuje licznik i czy pauzy są widoczne w systemie?
- Czy zgłoszenie może zostać zamknięte na obejściu?
- Co obejmuje dostępność, jeśli jest deklarowana?
- Które elementy zależą od podmiotów trzecich i jak są rozliczane?
- Co się dzieje, gdy SLA nie zostanie dotrzymane?
- Jak wygląda raport?
Dla porządku: cytowane wytyczne NCSC podają orientacyjne wartości – reakcję poniżej godziny dla spraw pilnych, jeden dzień roboczy dla drobnych i dwa–trzy dni robocze na rozwiązanie spraw rutynowych. To wskazówki opracowane dla rynku brytyjskiego, a nie norma obowiązująca w Polsce. Nie warto ich traktować jako miary, którą należy przykładać do polskich ofert; warto natomiast jako punkt odniesienia, gdy oferta odbiega od nich bardzo mocno w którąkolwiek stronę – i wtedy zapytać, dlaczego.
Zdrowa zasada praktyczna: oferta z gorszymi liczbami i jasnymi zasadami jest zwykle lepsza od oferty z lepszymi liczbami bez zasad. Pierwsza da się wyegzekwować, druga nie.
Przykładowa oś incydentu
Poniższy przykład jest ilustracją mechanizmu, nie opisem rzeczywistego zdarzenia ani deklaracją czasów. Zakładamy hipotetyczną umowę z godzinami serwisowymi 8:00–17:00 i reakcją na P1 do 1 godziny.
| Godzina | Zdarzenie | Stan licznika |
|---|---|---|
| 9:12 | Użytkownik zgłasza przez system: nie działa ERP, cała firma stoi | Start. Zgłoszenie wpłynęło |
| 9:18 | Dostawca klasyfikuje jako P1, przejmuje zgłoszenie, kontaktuje się z firmą | Reakcja: 6 minut. Dotrzymana |
| 9:20–10:05 | Diagnoza: baza działa, aplikacja nie odpowiada, przyczyną jest zapełniony dysk na serwerze | Biegnie |
| 10:05 | Obejście: zwolnienie miejsca, restart usługi, ERP działa | Obejście: 53 minuty od zgłoszenia. Firma pracuje |
| 10:10 | Zgłoszenie pozostaje otwarte — przyczyna nieusunięta, priorytet obniżony do P2 | Biegnie dla rozwiązania |
| 10:30 | Analiza: dysk zapełniają logi aplikacji, brak rotacji. Potrzebna decyzja o rozbudowie | Biegnie |
| 11:00 | Dostawca przedstawia dwa warianty i prosi o decyzję | Pauza – oczekiwanie na klienta, widoczna w systemie |
| 14:40 | Klient akceptuje wariant | Wznowienie |
| 15:30 | Wdrożenie rotacji logów, monitoring zajętości dysku | Biegnie |
| 16:10 | Rozwiązanie: przyczyna usunięta, zabezpieczenie przed powtórzeniem | Rozwiązanie: 3 h 12 min czasu roboczego (bez pauzy) |
Trzy obserwacje z tej osi. Po pierwsze, firma wróciła do pracy po 53 minutach, choć problem był rozwiązany po godzinie 16 – i to obejście, nie rozwiązanie, było tym, co się dla niej liczyło. Po drugie, blisko cztery godziny to była pauza po stronie klienta; gdyby licznik biegł, dostawca przekroczyłby SLA za cudzą zwłokę. Po trzecie, gdyby zgłoszenie zamknięto o 10:05 na obejściu, statystyka byłaby lepsza, a za miesiąc dysk zapełniłby się ponownie.
SLA kupuje przewidywalność, nie prędkość
Najważniejsze pytanie przy czytaniu oferty nie brzmi „ile minut”, tylko „co dokładnie mierzycie i jak to liczycie”. Dostawca, który potrafi opisać zasady licznika, pauzy, ścieżkę eskalacji i sposób raportowania, prawdopodobnie ma za tym proces. Ten, który podaje tylko efektowną liczbę, sprzedaje wrażenie.
Jeśli porównujesz oferty i chcesz omówić, jak te zasady wyglądałyby przy Twoich procesach – porozmawiajmy o priorytetach dla Twojej firmy. Zaczynamy od ustalenia, które systemy zatrzymują przychód, bo to od nich zależy sensowna klasyfikacja zgłoszeń. Zakres stałej opieki opisaliśmy na stronie outsourcingu IT.
Zastrzeżenie
Materiał ma charakter informacyjny i wyjaśnia mechanikę umów o poziomie usług. Wszystkie wartości liczbowe w przykładach służą wyłącznie ilustracji zasad i nie stanowią oferty ani zobowiązania. Ocena zapisów SLA w konkretnej umowie, w tym konsekwencji ich niedotrzymania, wymaga konsultacji z radcą prawnym.
Źródła
- National Cyber Security Centre, Choosing a Managed Service Provider (MSP), publikacja 24.11.2025, przegląd 24.06.2026 — https://www.ncsc.gov.uk/guidance/choosing-a-managed-service-provider-msp (dostęp 16.07.2026)
Stan na 16 lipca 2026 r.