SLA i KPI w umowie B2B - jak zapisać, żeby nie skończyć jak na etacie

W kontraktach IT, utrzymania, agencjach i consultingu pojawia się to samo zdanie: „będziemy mierzyć jakość”. Potem w załączniku ląduje tabela pełna procentów, a nikt nie wie, od kiedy liczy się awaria i kto raportuje. Albo odwrotnie: klient chce daily o 9:00, ticketów „na już” i KPI frekwencji w spotkaniach. To już nie jest SLA. To zarządzanie jak na etacie.

Dobrze zapisane SLA chroni obie strony. Klient wie, czego może oczekiwać. Wykonawca wie, za co odpowiada i gdzie kończy się odpowiedzialność. Źle zapisane SLA albo zamienia się w nieskończoną dyspozycyjność, albo w pustą deklarację bez konsekwencji.

Tekst ma charakter edukacyjny. Przy poważnym kontrakcie warto przejść go z prawnikiem branżowym, szczególnie przy karach i limitach odpowiedzialności.

SLA, SLI, KPI - bez żargonu na siłę

SLA (Service Level Agreement) to umowne poziomy usługi. Klasyczne przykłady: dostępność systemu, czas reakcji, czas obejścia, czas naprawy, godziny obsługi.

SLI to konkretny wskaźnik pomiaru (np. uptime liczony miesięcznie). SLO bywa celem wewnętrznym. KPI to miara sukcesu, często biznesowa: liczba obsłużonych zgłoszeń, czas wdrożenia leadu, NPS. W umowie B2B przenoś do zobowiązań tylko to, co da się zmierzyć i powiązać z Twoją usługą.

Jeśli nie umiesz opisać, jak liczysz wskaźnik, nie wpisuj go do SLA. Procent „99,5%” bez definicji okna pomiaru i wyłączeń jest ozdobą, nie zobowiązaniem.

Kiedy SLA ma sens na B2B

Ma sens przy:

• utrzymaniu aplikacji i infrastruktury,
• helpdesku / supportcie,
• usługach ciągłych (monitoring, moderacja, performance marketing z bieżącą optymalizacją),
• kontraktach, gdzie przestój generuje realną stratę.

Rzadziej potrzebujesz pełnego SLA przy jednorazowym wdrożeniu albo projekcie kreatywnym. Tam ważniejsze są etapy, kryteria odbioru, procedura change request i protokół. Możesz mieć terminy odpowiedzi na uwagi, ale to nie musi być „SLA 24/7”.

Co musi być w załączniku SLA

Dobre SLA odpowiada na pytania, które i tak padną w sporze:

1. Co jest usługą objętą SLA, a co nie.
2. Godziny obsługi (np. dni robocze 9-17 CET) i kanały zgłoszeń.
3. Kategorie incydentów (krytyczny / wysoki / niski) z definicjami.
4. Czas reakcji, czas obejścia, czas rozwiązania dla każdej kategorii.
5. Sposób pomiaru (od kiedy liczy się zegar, kto zatrzymuje zegar).
6. Wyłączenia: awarie po stronie klienta, brak dostępu, siła wyższa, zaplanowane prace.
7. Raportowanie: kto, jak często, w jakiej formie.
8. Konsekwencje naruszenia: service credits, kary, prawo odstąpienia przy powtórzeniach.

Bez punktów 5-6 tabela czasów jest pułapką. Klient zgłasza mailowo w piątek o 18:40, a w poniedziałek rano oczekuje, że „minęły już 40 godzin”.

Przykład parametrów (orientacyjny, do dopasowania)

Dla supportu aplikacji w godzinach roboczych:

• P1 (system niedostępny dla wszystkich użytkowników): reakcja 1 h, obejście 4 h, rozwiązanie 8 h roboczych.
• P2 (istotna funkcja nie działa, jest obejście): reakcja 4 h, rozwiązanie 2 dni robocze.
• P3 (usterka uciążliwa): reakcja 1 dzień roboczy, rozwiązanie według kolejki.

Dla dostępności SaaS często pojawia się 99,5% lub 99,9% miesięcznie. Dopisz, czy liczysz od całej platformy czy od konkretnego endpointu, czy okno maintenance wchodzi do wyliczenia i jak raportujecie.

To przykłady robocze, nie uniwersalny standard. Parametry muszą pasować do ceny. SLA 24/7 przy retainerze za niski pakiet godzin zwykle kończy się konfliktem albo ukrytym etatem dyżurnym.

Kary, service credits i art. 483 k.c.

W polskich umowach często pojawiają się kary umowne. Zgodnie z art. 483 § 1 Kodeksu cywilnego można zastrzec karę na wypadek niewykonania lub nienależytego wykonania zobowiązania niepieniężnego. W SLA typowo wiąże się ją z przekroczeniem czasu naprawy albo spadkiem dostępności poniżej progu.

Przy konstruowaniu kar:

• ustal progi (nie każda minuta od razu generuje karę),
• określ stawkę (np. % miesięcznego wynagrodzenia za usługę),
• dodaj limit łączny kar w miesiącu / roku,
• napisz, czy kara wyczerpuje odszkodowanie, czy klient może dochodzić więcej (art. 484 § 1 k.c.),
• pamiętaj, że rażąco wygórowaną karę sąd może miarkować.

W modelach SaaS popularniejsze bywają service credits (obniżka faktury) zamiast klasycznej kary. Mechanizm musi być równie precyzyjny: od jakiego poziomu naruszenia, w jakiej wysokości, czy jest jedynym środkiem.

Limit odpowiedzialności

Sam SLA bez limitu odpowiedzialności zostawia wykonawcę z otwartym ryzykiem utraconych korzyści klienta. Typowy zapis ogranicza odpowiedzialność do wielokrotności wynagrodzenia (np. opłaty z 3, 6 lub 12 miesięcy) i wyłącza utracone korzyści, z zastrzeżeniem że nie wyłączasz odpowiedzialności za szkodę wyrządzoną umyślnie (art. 473 § 2 k.c.).

Sprawdź spójność systemu:

• czy kary wliczają się do limitu,
• czy limit jest per zdarzenie i per okres,
• czy dotyczy całej umowy, czy konkretnej usługi.

Bez tej mapy w sporze każda strona czyta dokument inaczej.

Jak nie wpaść w podporządkowanie przez „reporting”

Tu zaczyna się część PIP-owa. Od lipca 2026 r. organy mocniej patrzą na praktykę współpracy. Raportowanie samo w sobie nie jest zakazane. Problem pojawia się, gdy KPI i statusy działają jak zarządzanie pracownikiem.

Sygnały ryzyka:

• obowiązkowy daily o stałej godzinie bez związku z incydentami,
• ocena „frekwencji na spotkaniach” zamiast dotrzymania SLA,
• bieżące polecenia co do sposobu pracy, nie tylko priorytetów biznesowych,
• KPI obecności, dyspozycyjności 8 godzin dziennie, „bycia online”,
• kary za spóźnienie na stand-up.

Bezpieczniejszy model:

• raportujesz naruszenia SLA i status krytycznych ticketów,
• spotkania koordynacyjne są uzgodnione i służą zakresowi, nie kontroli grafiku,
• Ty organizujesz sposób naprawy w ramach parametrów,
• klient ustala priorytety biznesowe i akceptuje odbiory,
• ewidencja czasu (jeśli jest) służy rozliczeniu, nie obecności.

Pierwsze interpretacje GIP po reformie pokazywały, że koordynacja projektu, procedury jakości czy wymagania bezpieczeństwa nie muszą oznaczać etatu, jeśli nie ma pracowniczego kierownictwa. Różnica między „koordynacją” a „kierownictwem” jest jednak cienka. Lepiej opisać ją w umowie i trzymać w praktyce.

Relacja SLA do wynagrodzenia

Nie podpisuj agresywnego SLA przy modelu, który tego nie finansuje. Jeśli klient chce P1 z reakcją 15 minut przez całą dobę, cena musi zawierać dyżur albo osobną opłatę on-call. W przeciwnym razie albo niedotrzymasz parametrów, albo będziesz żył w trybie etatowego pogotowia.

Dobre powiązanie:

• podstawowy retainer = SLA w godzinach roboczych,
• pakiet premium / on-call = osobna stawka,
• przekroczenie wolumenu ticketów = dopłata albo wydłużenie kolejek według umowy.

Checklista przed podpisem SLA

• Czy każdy parametr ma definicję i sposób pomiaru?
• Czy są godziny obsługi i kanały zgłoszeń?
• Czy wyłączenia są spisane?
• Czy konsekwencje naruszeń mają progi i limit łączny?
• Czy limit odpowiedzialności jest spójny z karami?
• Czy raportowanie dotyczy usługi, a nie obecności?
• Czy cena pokrywa realny koszt dyżurów?
• Czy możesz odmówić zakresu poza SLA bez „dyscyplinarki”?

Użyj generatora klauzul i checklisty umowy, zanim wyślesz „OK, podpisuję”.

Podsumowanie

SLA i KPI w B2B mają sens, gdy są mierzalne, płatne i powiązane z usługą. Tabela procentów bez definicji liczenia nic nie daje. Kary bez limitu i bez związku z ceną są miną. Codzienny reporting frekwencji zamiast statusu rezultatów przybliża model do etatu, zwłaszcza w realiach PIP 2026.

Zapisuj zobowiązanie jak usługę: parametr, pomiar, wyjątki, konsekwencja, cena. Resztę zostaw poza kontraktem albo przenieś na etat, jeśli rola naprawdę tego wymaga.