- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
Umowa SLA (Service Level Agreement) w kontekście e-commerce to jedno z tych pojęć, które właściciele sklepów spotykają przy rozmowach z agencją lub firmą IT — i rzadko rozumieją w pełni, zanim czegoś nie podpiszą. Gwarantowany czas reakcji, dostępność systemu na poziomie 99,9%, maksymalny czas przywrócenia usługi — brzmi profesjonalnie. Ale co to znaczy w praktyce? Co agencja jest zobowiązana zrobić, a co „usilnie się stara”? Jakie zdarzenia są objęte umową, a jakie nie? Ten artykuł rozkłada SLA na czynniki pierwsze — z perspektywy właściciela sklepu, nie prawnika.
Czym jest SLA i czego nie jest
SLA to umowa o poziomie usług — zestaw mierzalnych zobowiązań dotyczących jakości i dostępności usługi, z określonymi konsekwencjami za ich niespełnienie. Kluczowe słowo: mierzalnych. SLA bez konkretnych liczb i metod pomiaru to nie SLA — to deklaracja dobrych chęci. „Staramy się reagować jak najszybciej” to nie SLA. „Reagujemy w ciągu 2 godzin na incydenty P1 w godzinach 8–20 w dni robocze, w ciągu 4 godzin poza tymi godzinami” — to SLA.
Oferujemy opiekę SLA z konkretnymi czasami reakcji, monitoringiem 24/7 i miesięcznym raportowaniem. Bez gwiazdek i małego druku.
SLA nie jest gwarancją braku awarii — jest gwarancją sposobu reakcji na awarie. Żadna agencja nie jest w stanie zagwarantować, że hosting nigdy nie padnie, wtyczka nie będzie miała buga lub cyberatak nie dotknie serwisu. To, co SLA gwarantuje: w określonym czasie ktoś zareaguje, zdiagnozuje i podejmie działanie naprawcze. To jest fundamentalna różnica — i wiele konfliktów między klientami a agencjami wynika z nierozumienia tej granicy.
Kluczowe parametry SLA — co negocjować
Czas reakcji (Response Time) to czas od zgłoszenia incydentu do potwierdzenia odbioru i rozpoczęcia diagnozy. Czas rozwiązania (Resolution Time) to czas od zgłoszenia do przywrócenia usługi do stanu operacyjnego. Oba parametry powinny być zdefiniowane osobno dla różnych priorytetów incydentów. Przykład: P1 (sklep niedostępny, checkout nie działa) — reakcja 30 minut, rozwiązanie 4 godziny. P2 (problem z pojedynczą funkcją, sklep działa) — reakcja 2 godziny, rozwiązanie 8 godzin roboczych. P3 (kosmetyczny błąd, niska pilność) — reakcja do 24 godzin, rozwiązanie do 5 dni roboczych.
Dostępność usługi (Availability) wyrażana jest zazwyczaj jako procent czasu w miesiącu, w którym system działa prawidłowo. 99,9% miesięcznie to 43 minuty dopuszczalnego przestoju. 99,5% to 3,6 godziny. 99% to 7,3 godziny. Te liczby brzmią podobnie, ale przekładają się na bardzo różne ryzyko dla sklepu. Co ważne: jak liczyć „przestój”? Czy to czas od zgłoszenia, od wykrycia przez monitoring, od faktycznego startu awarii? Zapis w umowie ma tu ogromne znaczenie i warto go doprecyzować.
Zakres pokrycia SLA to lista zdarzeń, które są objęte umową i tych, które nie są. Typowe wyłączenia: prace serwisowe planowane z wyprzedzeniem (maintenance window), awarie po stronie hostingu lub dostawcy zewnętrznego (CDN, bramka płatnicza, API kuriera), błędy wprowadzone przez zmiany dokonane przez klienta bez zgody agencji, zdarzenia siły wyższej. Każde wyłączenie zmniejsza rzeczywiste pokrycie SLA — warto się upewnić, że wyłączenia są konkretne i nie są „furtką do wyłączenia wszystkiego”.
Godziny obowiązywania SLA a e-commerce 24/7
Sklep internetowy działa 24 godziny na dobę, 7 dni w tygodniu. Awaria w sobotę o 22:00 to realna strata przychodów. Tymczasem większość SLA agencji IT obejmuje standardowe godziny pracy (8–17 lub 9–18, dni robocze) — co oznacza, że weekendowa awaria jest obsługiwana w poniedziałek rano. To jest fundamentalna rozbieżność między modelem pracy agencji a modelem biznesowym sklepu i musi być adresowana w negocjacjach umowy.
Opcje: całodobowe pokrycie SLA (24/7/365) — droższe, wymaga dyżurów lub on-call, ale daje prawdziwą ochronę dla e-commerce. Rozszerzone godziny (np. 8–22, 7 dni w tygodniu) — kompromis, który wyklucza tylko głęboka noc. Standardowe godziny z monitoingiem off-hours — agencja ma monitoring, który wybudza on-call przy krytycznych awariach, ale nie gwarantuje czasów SLA poza godzinami. Każdy model ma inną cenę i inny poziom ochrony — warto to zrozumieć przed podpisaniem umowy.
Kary umowne i kredyty SLA — jak egzekwować
SLA bez mechanizmu egzekucji to tylko obietnica. Dobre umowy SLA mają zapis o kredytach usługowych (service credits) — jeśli agencja nie dotrzyma parametrów SLA, klient otrzymuje proporcjonalne wynagrodzenie w postaci rabatu na kolejne miesiące lub dodatkowych godzin pracy. Typowy mechanizm: każde przekroczenie czasu reakcji lub rozwiązania o 100% skutkuje kredytem X% miesięcznej opłaty. Ograniczenie: kredyt rzadko pokrywa realne straty biznesowe z awarii — nie jest odszkodowaniem, jest ekwiwalentem usługi.
Warto pamiętać, że dobra agencja nie potrzebuje SLA z ostrymi karami, żeby działać szybko — robi to z własnej inicjatywy, bo reputacja i relacja z klientem są ważniejsze niż uniknięcie kary umownej. SLA jest mechanizmem bezpieczeństwa na wypadek, gdy coś pójdzie nie tak i trzeba mieć obiektywne kryterium oceny. Jeśli agencja nie chce wpisywać konkretnych czasów reakcji i rozwiązania do umowy — to jest sygnał ostrzegawczy, nie element negocjacji.
Co powinno być częścią dobrego pakietu opieki SLA
Poza reakcją na awarie, dobra umowa opieki technicznej dla sklepu e-commerce powinna obejmować: regularne aktualizacje WordPress, WooCommerce i wtyczek (z testowaniem na staging przed wdrożeniem na produkcję), monitoring uptime i błędów z alertami (o czym pisaliśmy szczegółowo w artykule o monitoringu sklepu), regularne backupy z testowaniem możliwości przywrócenia, miesięczny raport z wykonanych prac i statusu systemu. To są elementy, które odróżniają „opiekę techniczną” od „reagowania na awarie” — i które mają wartość zapobiegawczą, nie tylko interwencyjną.
