SLA IT: czym różni się czas reakcji od czasu naprawy

Dwie oferty, dwie liczby. Pierwsza obiecuje reakcję w 10 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 10 minut oznacza automatyczne potwierdzenie przyjęcia zgłoszenia, a technik zaczyna pracę po południu.

Skrót SLA rozwija się jako Service Level Agreement, czyli 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: dostawca formalnie dotrzymuje warunków, a klient czuje się oszukany. Obie strony mają rację, bo mówią o dwóch różnych rzeczach.

SLA opisuje, jak szybko ktoś zajmie się zgłoszeniem, w jakiej kolejności, kto o tym decyduje, kiedy sprawa idzie wyżej i jak to wszystko zostanie zmierzone. Obietnica, że każdą awarię da się usunąć w godzinę, nie jest jego treścią. Dobrze napisane SLA daje Wam przede wszystkim przewidywalność obsługi.

Liczby w przykładach poniżej ilustrują zasadę. Tam, gdzie opisujemy własne pakiety NexaIT, mówimy o tym wprost.

Co dokładnie mierzy SLA

Zacznijmy od 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 jakości i sam w sobie zobowiązaniem nie jest.

Ma to praktyczne znaczenie przy czytaniu ofert. Zdanie „nasz średni czas reakcji to 12 minut” opisuje KPI za jakiś okres. Średnia z zeszłego kwartału nie mówi nic o tym, co stanie się z Waszym zgłoszeniem w piątek o 16:50.

Ramy ITIL 4 opisują to podejście jako osobną praktykę zarządzania poziomem usług. Według opisu kursu wydawanego przez PeopleCert jej celem jest ustalanie jasnych celów usługi, opartych na potrzebach biznesu. W małej firmie przekłada się to na proste pytanie: które systemy zatrzymują przychód i ile czasu możecie bez nich wytrzymać.

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ę.
• Okno wsparcia: godziny, w których 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). To jednak parametr usługi, zwykle konkretnego systemu albo łącza. Z zobowiązaniem do naprawy dowolnej awarii w 43 minuty nie ma nic wspólnego.

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 diagnozę. Automatyczna wiadomość „przyjęliśmy zgłoszenie, numer 4417” jest jedynie potwierdzeniem rejestracji. Jeśli oferta chwali się reakcją w minutę, dopytajcie, czy chodzi o człowieka, czy o skrypt. Miarą tego etapu bywa MTTA, czyli ś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 z góry nie wiadomo, 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 ma znaczenie 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, 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 z niższym priorytetem. Miarą całości bywa MTTR, czyli średni czas przywrócenia usługi. Ta wartość ma sens tylko wtedy, gdy wiadomo, czy mierzy obejście, czy rozwiązanie.

Cel przywrócenia działania przy awarii krytycznej bywa zapisany na dwa sposoby: jako cel operacyjny albo jako twarda gwarancja z karą umowną. Oba warianty są uczciwe, jeśli umowa nazywa je wprost. Kary umowne pojawiają się zwykle w wyższych pakietach, bo dostawca musi utrzymać na nie rezerwę ludzi.

Priorytety zgłoszeń P1-P4 z przykładami

Priorytet nie powinien zależeć od tego, jak bardzo ktoś jest zdenerwowany. Wynika z dwóch zmiennych: wpływu (ile osób i procesów dotyczy) oraz pilności (czy da się poczekać).

Tabela poniżej pokazuje typową logikę klasyfikacji. Konkretne definicje i czasy zawsze wynikają z umowy z danym dostawcą.

Priorytet	Kiedy	Przykład	Typowe oczekiwanie
P1 (krytyczny)	Cała firma lub kluczowy proces stoi, brak obejścia	Nie działa serwer ERP i nikt nie wystawia dokumentów. Awaria łącza w jedynej lokalizacji. Podejrzenie ataku ransomware	Natychmiastowe podjęcie, praca ciągła, obejście przed rozwiązaniem
P2 (wysoki)	Istotna funkcja niedostępna, ale istnieje obejście albo dotyczy części firmy	Nie działa poczta w jednym dziale. Awaria drukarki sieciowej, gdy jest druga	Podjęcie w krótkim, uzgodnionym czasie w oknie wsparcia
P3 (standardowy)	Pojedynczy użytkownik lub urządzenie, praca jest możliwa	Wolno działający komputer. Problem z konfiguracją poczty u jednej osoby	Podjęcie w standardowym czasie
P4 (niski)	Prośba, zmiana, pytanie	Nowe konto dla pracownika za dwa tygodnie. Zmiana uprawnień	Realizacja planowa, w uzgodnionym terminie

Dzięki osobnym czasom dla każdego priorytetu awaria serwera nie czeka w tej samej kolejce co wymiana tonera, a dostawca może realnie dotrzymać tego, co podpisał. Przy podpisywaniu umowy ustalcie jeszcze trzy rzeczy.

Kto nadaje priorytet. Jeśli robi to wyłącznie dostawca, ma wbudowaną zachętę do zaniżania, bo niższy priorytet to luźniejszy licznik. Jeśli wyłącznie klient, w ciągu miesiąca wszystko będzie krytyczne. Rozsądny model: Wy proponujecie, dostawca może zmienić priorytet z uzasadnieniem, a Wy macie ś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 zwracają uwagę na rzecz, którą łatwo przeoczyć w negocjacjach: krótszy czas reakcji najpewniej podniesie koszt umowy. Jednogodzinna reakcja w cenie reakcji jednodniowej oznacza zwykle, że coś innego wycięto z zakresu.

Okno wsparcia i moment startu licznika

Tutaj mieszka większość realnych nieporozumień. Sama liczba w ofercie niewiele mówi, dopóki nie wiadomo, jak jest liczona.

Od kiedy biegnie licznik. Od momentu wysłania zgłoszenia przez użytkownika, od jego rejestracji w systemie dostawcy czy „od kiedy zauważymy”? Przy zgłoszeniu telefonicznym o 8:58, gdy wsparcie zaczyna o 9:00, różnica bywa istotna. Zdrowa zasada: licznik startuje w momencie rejestracji zgłoszenia kanałem opisanym w umowie.

Stąd znaczenie kanału zgłoszeń. Problem zgłoszony SMS-em do technika, którego akurat znacie, zwykle nie uruchamia żadnego licznika, bo nie trafia do systemu.

Okno wsparcia. Decyduje o rzeczywistym czasie oczekiwania bardziej niż sama liczba. Reakcja „1 h” w oknie od poniedziałku do piątku, 9:00-17:00, oznacza, że awaria zgłoszona w piątek o 18:00 czeka do poniedziałku, chyba że pakiet przewiduje dyżur. Cztery godziny reakcji w oknie 8:00-16:00 sprawiają, że zgłoszenie z 15:30 może czekać do 11:30 następnego dnia, i formalnie SLA zostanie dotrzymane. Ta sama „reakcja w 4 godziny” w trybie całodobowym to inna usługa i inna cena.

Ustalcie też, co dzieje się w weekendy i święta, czy istnieje osobny tryb dla awarii krytycznych poza oknem i ile kosztuje praca poza nim. Wiele umów przewiduje dyżur 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 zewnętrznych

SLA jest zobowiązaniem dwustronnym, choć oferty rzadko to podkreślają. Dostawca odpowiada za to, na co ma wpływ.

NCSC zaleca, żeby umowa zawierała macierz odpowiedzialności: co robi dostawca, a czego oczekuje się od klienta. W kontekście SLA oznacza to spisanie Waszych obowiązków:

• 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 bez wiedzy dostawcy.

Ostatni punkt bywa źródłem najbardziej gorzkich sporów. Jeśli ktoś w firmie samodzielnie przekonfiguruje router, dostawca odpowiada za skutki tylko na tyle, na ile w ogóle o zmianie wie.

Osobna kategoria to podmioty trzecie: operatorzy łączy, producenci oprogramowania, serwisy sprzętu. Dostawca IT nie naprawi światłowodu przekopanego przez koparkę. Może zgłosić awarię, eskalować i pilnować terminu, ale nie odpowiada za czas usunięcia. Umowa powinna to nazywać, a raport pokazywać osobno.

To warunek uczciwości SLA. Zobowiązanie do rzeczy, na które dostawca nie ma wpływu, jest albo pustą obietnicą, albo ryzykiem wliczonym w cenę, za które płacicie w abonamencie.

Zapytajcie przy okazji o podwykonawców samego dostawcy. NCSC zaleca ocenę ryzyka jego łańcucha dostaw, bo część prac może wykonywać ktoś, kogo nie znacie.

Raport SLA dla zarządu

Lista zamkniętych zgłoszeń raportem SLA jeszcze nie jest. 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ń:

1. 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ś psuje się strukturalnie.
2. Czy SLA zostało dotrzymane, z osobnym wykazaniem przekroczeń i ich przyczyn. Raport bez ani jednego przekroczenia przez rok powinien wzbudzić pytania.
3. Ile czasu licznik był zatrzymany i dlaczego. To pokazuje, gdzie proces zacina się po Waszej stronie.
4. Co się powtarza. Pięć zgłoszeń miesięcznie o tej samej drukarce to jeden nierozwiązany problem.
5. Co wymaga decyzji i pieniędzy. Sprzęt bez wsparcia, kończące się licencje, zidentyfikowane ryzyka.

Poproście o przykładowy raport przed podpisaniem umowy. To jeden z lepszych testów dojrzałości dostawcy: firma, która ma proces, pokaże zanonimizowany dokument bez wahania.

Pytania do dostawcy przed podpisaniem umowy SLA

Zestawianie samych liczb prowadzi na manowce. Te pytania sprowadzają oferty do wspólnego mianownika:

• Czy podana liczba dotyczy reakcji, obejścia czy rozwiązania?
• Reakcja oznacza działanie człowieka czy automatyczne potwierdzenie?
• Od kiedy liczy się czas reakcji: od rejestracji zgłoszenia czy od momentu, gdy dostawca je zauważy?
• W jakim oknie wsparcia biegnie zegar i jak liczony jest czas poza nim?
• Co dzieje się ze zgłoszeniami poza oknem wsparcia i ile to kosztuje?
• Jaki jest cel przywrócenia działania dla awarii krytycznych i czy jest gwarancją, czy celem operacyjnym?
• Kto nadaje priorytet i jak możemy 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?

Jeśli dostawca odpowiada na te pytania wprost i ma je zapisane w umowie, to dobry znak. Odpowiedź „proszę się nie martwić, zawsze reagujemy szybko” powinna Was zaniepokoić.

Punktem odniesienia mogą być wartości z wytycznych NCSC: reakcja poniżej godziny dla spraw pilnych, jeden dzień roboczy dla zwykłych zapytań i dwa-trzy dni robocze na rozwiązanie rutynowych spraw o średnim priorytecie. To wskazówki dla rynku brytyjskiego, które w Polsce nie mają mocy normy. Przydają się wtedy, gdy oferta odbiega od nich bardzo mocno w którąkolwiek stronę i warto zapytać, dlaczego.

Zdrowa zasada praktyczna: oferta z gorszymi liczbami i jasnymi zasadami jest zwykle lepsza od oferty z lepszymi liczbami bez zasad, bo pierwszą da się wyegzekwować. Szerszą listę kryteriów wyboru dostawcy, poza samym SLA, zebraliśmy w poradniku jak wybrać firmę do outsourcingu IT.

Przykładowa oś incydentu

Poniższy przykład ilustruje mechanizm. Nie opisuje rzeczywistego zdarzenia ani nie deklaruje czasów. Zakładamy hipotetyczną umowę z oknem wsparcia 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 zarejestrowane
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 18 min czasu roboczego (bez pauzy)

Trzy obserwacje z tej osi. Po pierwsze, firma wróciła do pracy po 53 minutach, choć problem rozwiązano po 16:00, i dla niej liczyło się właśnie obejście. 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.

Ile kosztuje firmę każda godzina takiego przestoju, możecie oszacować w kalkulatorze kosztu przestoju. Ta liczba pomaga ustalić, który priorytet naprawdę potrzebuje dyżuru.

Jak liczymy czas reakcji w pakietach NexaIT

W naszych umowach czas reakcji to czas podjęcia zgłoszenia i rozpoczęcia diagnozy, liczony w oknie wsparcia danego pakietu. Zegar startuje od rejestracji zgłoszenia w kanale helpdesk, a nie od pierwszej próby kontaktu. Czasu usunięcia awarii nie mieszamy z czasem reakcji.

Przykład z cennika: w pakiecie START IT okno wsparcia obejmuje dni robocze od poniedziałku do piątku w godzinach 9:00-17:00, a reakcja na zgłoszenie P1 wynosi do 4 godzin roboczych. Wyższe pakiety mają szersze okno i krótsze czasy, a tryb całodobowy dla zgłoszeń krytycznych przewidujemy tylko w pakiecie ENTERPRISE IT. Definicje priorytetów P1-P4 są częścią umowy, a pełne zestawienie znajdziecie na stronie outsourcingu IT.

SLA jako umowa o przewidywalności

Najważniejsze pytanie przy czytaniu oferty brzmi: 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ównujecie oferty, zacznijcie od listy systemów, które zatrzymują przychód, bo od niej zależy sensowna klasyfikacja zgłoszeń. Możemy przejść przez nią razem podczas bezpłatnego przeglądu IT.

---

Zastrzeżenie

Materiał ma charakter informacyjny i wyjaśnia mechanikę umów o poziomie usług. Wartości liczbowe w przykładach, poza opisem pakietów NexaIT, służą wyłącznie ilustracji zasad i nie stanowią oferty. 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 2.10.2026)
• PeopleCert, ITIL 4 Practitioner: Service Level Management, https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-service-level-management-3867 (dostęp 2.10.2026)

Stan na 2 października 2026 r.