Umowa SLA — co powinna zawierać dobra umowa wsparcia

Umowa SLA (Service Level Agreement) to dokument, który określa, na jaką pomoc może liczyć firma, gdy strona internetowa przestaje działać poprawnie, pojawia się błąd krytyczny albo potrzebna jest pilna zmiana. W praktyce to właśnie zapisy umowy SLA decydują o tym, czy w sytuacji awarii ktoś zareaguje w ciągu godziny, czy dopiero następnego dnia roboczego — i czy w ogóle wiadomo, kto za co odpowiada.

Problem w tym, że wiele umów wsparcia technicznego nazywa się „SLA” tylko z nazwy, bez konkretnych zobowiązań w treści. Brakuje w nich jasno określonych czasów reakcji, opisu zakresu usługi albo mechanizmu zgłaszania problemów. W tym artykule tłumaczymy, jakie elementy powinna zawierać dobra umowa SLA, żeby faktycznie chroniła firmę, a nie była wyłącznie deklaracją intencji.

Czym właściwie jest umowa SLA

Umowa SLA to część umowy o wsparcie techniczne (albo osobny dokument dołączony do niej), który precyzuje mierzalne parametry usługi. Zamiast ogólnego zapisu typu „zapewniamy wsparcie techniczne”, dobra umowa SLA odpowiada na konkretne pytania: w jakim czasie firma otrzyma odpowiedź na zgłoszenie, w jakim czasie problem zostanie rozwiązany, jakie kategorie zgłoszeń są w ogóle obsługiwane i co się dzieje, jeśli te zobowiązania nie zostaną dotrzymane.

Bez takich zapisów strona formalnie ma „opiekę techniczną”, ale w praktyce nie wiadomo, czego można się spodziewać w sytuacji awaryjnej. To właśnie różnica między umową o wsparcie a umową SLA — ta druga zamienia ogólne obietnice na konkretne, weryfikowalne zobowiązania.

Kluczowe elementy dobrej umowy SLA

Niezależnie od branży i wielkości firmy, dobrze skonstruowana umowa SLA powinna jasno opisywać kilka elementów. Ich brak jest sygnałem, że warto dopytać dostawcę, zanim umowa zostanie podpisana.

• Czas reakcji — maksymalny czas, w jakim zgłoszenie zostanie przyjęte i potwierdzone przez zespół wsparcia.
• Czas rozwiązania — maksymalny czas, w jakim problem danej kategorii zostanie usunięty lub obejściowo rozwiązany.
• Kategorie zgłoszeń (priorytety) — podział na awarie krytyczne, błędy średniej wagi i drobne poprawki, każda z osobnym czasem reakcji.
• Godziny i dni obsługi — czy wsparcie działa w standardowych godzinach pracy, czy również poza nimi i w weekendy.
• Zakres usługi — dokładna lista tego, co wchodzi w skład wsparcia (i co jednoznacznie jest poza nim).
• Kanał zgłoszeń — sposób, w jaki firma zgłasza problem (system ticketowy, e-mail, telefon) i sposób potwierdzenia przyjęcia zgłoszenia.
• Raportowanie — okresowe podsumowanie zgłoszeń, wykonanych aktualizacji i incydentów.
• Zasady dostępności (uptime) — deklarowany poziom dostępności strony oraz sposób jego wyliczania.

Im bardziej szczegółowo opisane są te punkty, tym łatwiej ocenić, czy dana usługa wsparcia faktycznie odpowiada potrzebom firmy, a nie tylko brzmi profesjonalnie w ofercie.

Czas reakcji i czas rozwiązania — to nie to samo

Jednym z najczęstszych nieporozumień przy czytaniu umowy SLA jest mylenie czasu reakcji z czasem rozwiązania problemu. Czas reakcji to moment, w którym ktoś z zespołu wsparcia potwierdza przyjęcie zgłoszenia i zaczyna nad nim pracować — nie oznacza to jeszcze, że problem zostanie w tym czasie naprawiony. Czas rozwiązania to z kolei termin, w którym zgłoszenie ma zostać faktycznie zamknięte.

Umowa, która gwarantuje wyłącznie szybki czas reakcji, ale nie określa czasu rozwiązania, w praktyce daje niewielką ochronę — formalnie ktoś odpowie na zgłoszenie błyskawicznie, ale sama naprawa może się przeciągać bez żadnego zobowiązania czasowego. Dlatego warto sprawdzić, czy w umowie SLA oba te parametry są zdefiniowane osobno, i to najlepiej dla każdej kategorii priorytetu z osobna — inny czas rozwiązania powinien obowiązywać dla awarii blokującej działanie strony, a inny dla drobnej poprawki kosmetycznej.

Zakres wsparcia — co powinno być opisane wprost

Drugim częstym źródłem sporów jest niejasny zakres usługi. Umowa SLA powinna precyzyjnie wskazywać, jakie działania wchodzą w skład wsparcia technicznego, a jakie wymagają osobnej wyceny. W praktyce dobrze opisany zakres obejmuje zwykle:

• monitorowanie dostępności strony i reakcję na awarie serwera,
• aktualizacje systemu CMS, wtyczek i bibliotek frontendowych,
• wykonywanie i weryfikację kopii zapasowych,
• usuwanie błędów zgłaszanych przez użytkownika lub wykrytych przez monitoring,
• drobne zmiany treściowe w ustalonym miesięcznym limicie godzin.

Poza zakresem zwykle pozostają większe zmiany funkcjonalne, rozbudowa strony o nowe moduły czy migracje — te elementy warto mieć jasno rozgraniczone, żeby uniknąć sytuacji, w której klient zakłada, że dana praca jest „w cenie SLA”, a wykonawca traktuje ją jako dodatkowe zlecenie. Zakres wsparcia technicznego naturalnie łączy się z szerszym tematem utrzymania strony po jej uruchomieniu — pełniej opisaliśmy to w artykule o opiece nad stroną po wdrożeniu.

Eskalacja, kary umowne i odpowiedzialność

Dobra umowa SLA opisuje też, co się dzieje, gdy zobowiązane czasy reakcji lub rozwiązania nie zostają dotrzymane. Może to być mechanizm eskalacji (zgłoszenie automatycznie trafia do osoby wyżej w strukturze zespołu wsparcia), rekompensata w postaci obniżenia opłaty za dany okres rozliczeniowy albo inna forma odpowiedzialności wykonawcy.

Bez takiego zapisu umowa SLA staje się jednostronnym zobowiązaniem bez konsekwencji — dostawca może nie dotrzymać deklarowanych czasów bez żadnych skutków dla siebie. Warto też sprawdzić, czy umowa jasno rozgranicza sytuacje, za które odpowiada wykonawca wsparcia (np. błąd po aktualizacji), od tych, na które nie ma wpływu (np. awaria po stronie dostawcy hostingu, jeśli jest odrębnym podmiotem). Ten podział ma znaczenie zwłaszcza wtedy, gdy strona korzysta z zewnętrznego serwera — dobór odpowiedniego dostawcy hostingu wpływa bezpośrednio na to, jak realistyczne są zobowiązania w umowie SLA, o czym piszemy w artykule jak wybrać hosting.

Jak ocenić ofertę SLA przed podpisaniem

Przed podpisaniem umowy warto przejść przez krótką listę kontrolną, która pozwala ocenić, czy dokument faktycznie spełnia funkcję umowy SLA, a nie jest tylko ogólnym opisem usługi wsparcia:

1. Czy są zdefiniowane osobne czasy reakcji i rozwiązania dla różnych priorytetów zgłoszeń?
2. Czy zakres wsparcia jest opisany wprost, z wyszczególnieniem tego, co jest poza umową?
3. Czy określono kanał zgłoszeń i sposób potwierdzania ich przyjęcia?
4. Czy umowa opisuje procedurę backupu i przywracania danych po awarii?
5. Czy istnieje mechanizm eskalacji lub konsekwencji przy niedotrzymaniu zobowiązań?
6. Czy umowa przewiduje okresowe raportowanie wykonanych działań?

Punkt dotyczący backupu i przywracania danych zasługuje na osobną uwagę — sama deklaracja „wykonujemy kopie zapasowe” nic nie mówi o tym, jak szybko strona zostanie odtworzona po realnej awarii. Warto sprawdzić, czy umowa SLA odnosi się też do planu na wypadek utraty danych, co szerzej opisujemy w artykule o backupie i disaster recovery.

Najczęstsze pytania

Czy każda umowa o wsparcie techniczne jest umową SLA?

Nie. Nazwa „SLA” bywa używana marketingowo dla dowolnej umowy o opiekę techniczną, nawet jeśli nie zawiera konkretnych, mierzalnych czasów reakcji i rozwiązania. Prawdziwa umowa SLA musi zawierać parametry, które można sprawdzić i wyegzekwować.

Jaki czas reakcji jest standardem w umowach SLA?

Nie ma jednego uniwersalnego standardu — zależy od priorytetu zgłoszenia, godzin obsługi i specyfiki strony. Istotne jest, żeby czas reakcji był jasno określony dla każdej kategorii zgłoszeń, a nie podany jako jedna ogólna wartość dla wszystkich problemów.

Czy umowa SLA obejmuje też hosting?

Zależy od modelu współpracy. Jeśli hosting jest dostarczany przez ten sam podmiot, który świadczy wsparcie techniczne, umowa SLA zwykle obejmuje też dostępność serwera. Jeśli hosting jest zewnętrzny, warto sprawdzić, jak umowa rozgranicza odpowiedzialność między dostawcą hostingu a zespołem wsparcia.

Co się dzieje, gdy wykonawca nie dotrzyma czasu rozwiązania z umowy SLA?

Powinno to być opisane w samej umowie — najczęściej w formie mechanizmu eskalacji zgłoszenia lub rekompensaty finansowej za dany okres rozliczeniowy. Brak takiego zapisu oznacza, że zobowiązanie czasowe nie ma realnego wsparcia prawnego.

Czy mała firma też potrzebuje umowy SLA?

Tak, choć zakres może być prostszy niż w przypadku dużego sklepu internetowego. Nawet podstawowa strona firmowa zyskuje na jasno określonym czasie reakcji i zakresie wsparcia — pozwala to uniknąć sytuacji, w której awaria trwa dłużej niż to konieczne, bo nikt nie ma jasno przypisanej odpowiedzialności za jej usunięcie.

Jeśli zastanawiasz się, jak powinna wyglądać umowa SLA dopasowana do skali Twojej strony — z konkretnymi czasami reakcji, jasnym zakresem wsparcia i przejrzystymi zasadami raportowania — sprawdź nasze pakiety wsparcia technicznego SLA, w których te zobowiązania są opisane wprost, a nie ukryte w ogólnych deklaracjach.