- Strategia oparta o dane i cele biznesowe.
- Rekomendacje UX, integracji i automatyzacji.
- Plan wdrożeń i wsparcie zespołu.
Pierwszy kontakt z umową SLA dla wielu właścicieli sklepów internetowych wygląda tak: dostajesz PDF z 8 stronami zapisu prawno-technicznego, podpisujesz „bo agencja tak ma w standardzie” i właściwie nie wiesz, na co się zgodziłeś. W poprzednim artykule omawialiśmy, co SLA powinno zawierać i jak negocjować kluczowe parametry. Tutaj skupiamy się na edukacji: jak czytać zapisy SLA, które sformułowania powinny wzbudzić czujność i jakie pytania zadać agencji przed podpisaniem. Więcej kontekstu o samej umowie znajdziesz w poprzednim artykule o SLA dla e-commerce.
Jak czytać definicje w SLA
SLA zaczyna się od definicji — i tu tkwi często „diabeł”. Jak zdefiniowany jest „incydent”? Czy to tylko całkowita niedostępność sklepu, czy też błąd w funkcji checkoutu, problem z synchronizacją stanów lub niedostępność panelu administratora? Wąska definicja incydentu może oznaczać, że 80% realnych problemów nie jest objętych gwarantowanymi czasami SLA. Sprawdź, czy w umowie są przykłady incydentów P1, P2, P3 — nie tylko definicja priorytetów, ale realne scenariusze, które do nich należą.
W VisioLab SLA ma konkretne liczby, zdefiniowane scenariusze i działający on-call. Porozmawiajmy o tym, czego potrzebujesz.
Jak zdefiniowany jest „czas reakcji”? Od momentu zgłoszenia przez klienta? Od momentu wykrycia przez monitoring agencji? Od momentu, gdy agencja potwierdzi odbiór? Te trzy punkty mogą dzielić 30–60 minut — co przy P1 ma znaczenie. Dobry zapis: „czas reakcji liczony jest od momentu wpłynięcia zgłoszenia na wskazany kanał kontaktowy (email/telefon/ticketing)”. Zły zapis: „staramy się reagować możliwie najszybciej”.
Zapisy, które powinny wzbudzić czujność
„Czasy SLA obowiązują w godzinach roboczych” bez definicji godzin roboczych — co to znaczy dla Twojego sklepu pracującego 24/7? Zapytaj o definicję i czy weekendy są objęte dla incydentów P1. „Wyłączenia: awarie infrastruktury zewnętrznej” — to może obejmować hosting, CDN, bramkę płatniczą, API kuriera. Jeśli większość realnych awarii Twojego sklepu wynika z problemów hostingowych lub z bramki płatniczej — możesz mieć SLA, które nic nie gwarantuje w praktyce. „Zmiany wprowadzone przez klienta” wyłączone z SLA bez definicji „zmiany” — czy aktualizacja wtyczki przez Twojego pracownika w panelu WP jest „zmianą”? Jasny podział: co klient może robić samodzielnie bez naruszenia SLA, a co wymaga zgłoszenia do agencji.
„Dostępność mierzona miesięcznie” — to może ukrywać 4–8 godzin przestoju w miesiącu. Zapytaj: jak agencja mierzy dostępność? Własny monitoring? Zewnętrzne narzędzie? Czy możesz zobaczyć dane historyczne? „Kredyty SLA są jedyną możliwą formą rekompensaty” — standardowy zapis, który wyłącza roszczenia odszkodowawcze. Warto wiedzieć, że kredyty SLA to zazwyczaj 10–30% miesięcznej opłaty — nie pokrywają realnych strat z awarii. Nie ma sensu negocjować tego zapisu (to standard branżowy), ale dobrze to rozumieć.
Pytania do agencji przed podpisaniem SLA
Lista pytań, które warto zadać: Jaki monitoring uptime używacie i jakie mam dostęp do raportów? Jak wygląda procedura on-call — kto reaguje poza godzinami roboczymi na P1? Jak długo w historii Waszych klientów trwały najdłuższe incydenty P1? Czy możecie podać przykłady z ostatnich 6 miesięcy? Jakie zmiany mogę robić samodzielnie (aktualizacje, treści) bez naruszenia SLA, a jakie wymagają zgłoszenia? Co się stanie, jeśli wdrożę nową wtyczkę i ona spowoduje awarię — czy jest objęta SLA? Jak wygląda proces eskalacji, jeśli on-call nie reaguje w ciągu 15 minut?
Agencja, która ma dobrze zdefiniowane procesy, odpowie na te pytania konkretnie i bez irytacji. Agencja, która unika konkretnych odpowiedzi lub mówi „wszystko będzie OK, nie martw się formalnościami” — to sygnał, że procesy nie istnieją poza dokumentem PDF. SLA jest tak silne, jak procesy, które za nim stoją — nie odwrotnie.
SLA a zarządzanie zmianami: co się zmienia w trakcie umowy
Sklep się zmienia: nowe wtyczki, nowe integracje, nowa wersja WooCommerce, zmiana motywu. Dobra umowa SLA powinna opisywać, jak te zmiany są zarządzane. Typowy mechanizm: zmiany znaczące (nowa integracja, aktualizacja głównych wtyczek) wymagają zgłoszenia z wyprzedzeniem, są testowane na środowisku staging przed wdrożeniem na produkcję, a po wdrożeniu jest okno monitorowania z podwyższoną czujnością (np. 48 godzin). Jeśli agencja nie ma środowiska staging i wdraża wszystkie zmiany bezpośrednio na produkcję — to jest ryzyk, którego SLA nie ochroni.
