Umowa utrzymaniowa SLA dla sklepu - co powinna zawierać

Priorytety zgłoszeń w umowie utrzymaniowej sklepu

Tabela priorytetów jest sercem SLA. W sklepie nie ma sensu opisywać ich ogólnie, np. „awaria krytyczna to brak działania systemu”. Lepiej wymienić konkretne sytuacje, które zatrzymują sprzedaż lub wysyłkę, i przypisać je do priorytetów:

• Krytyczny - sklep nie przyjmuje zamówień, nie działa checkout lub płatności, zamówienia z marketplace'ów nie spływają, integracja kurierska nie generuje etykiet w godzinach pakowania.

• Wysoki - nie działa jedna metoda płatności lub dostawy, stany synchronizują się z dużym opóźnieniem, faktury nie wystawiają się automatycznie, ale jest obejście ręczne.

• Normalny - błąd na karcie produktu, filtrze lub w panelu, który utrudnia pracę, ale nie blokuje sprzedaży.

• Niski - drobne poprawki wyglądu, pytania, prośby o zmianę treści lub ustawień.

Każdy priorytet potrzebuje osobnego czasu reakcji i osobnego czasu przywrócenia działania lub obejścia. Przy awariach krytycznych liczy się przede wszystkim obejście: ręczne pobranie zamówień, wyłączenie wadliwego modułu, cofnięcie wdrożenia. Trwałe rozwiązanie przyczyny może przyjść później, w zwykłym trybie. Konkretne wartości czasów zależą od tego, ile sklep traci na przestoju i ile jest gotów zapłacić za gotowość wykonawcy wieczorami i w weekendy, dlatego ustalcie je wspólnie, zamiast przepisywać z cudzej umowy.

W umowie warto opisać też samą ścieżkę zgłoszenia awarii krytycznej, bo w stresie liczy się każda minuta:

[#chart:wpr82c]

Ważne jest, kto może zgłaszać awarie krytyczne i jakim kanałem. E-mail wysłany w piątek wieczorem może przeleżeć do poniedziałku, dlatego przy priorytecie krytycznym umowa powinna wskazywać telefon lub system zgłoszeń z powiadomieniami dla dyżurnego. Po stronie sklepu wyznacz osobę, która może podjąć decyzję o wyłączeniu modułu lub integracji, gdy właściciel jest niedostępny.

Monitoring jako część SLA

Najlepsza umowa nie pomoże, jeśli o awarii pierwszy dowiaduje się klient. Dlatego w zakresie utrzymania warto zapisać, co wykonawca monitoruje: dostępność sklepu, błędy integracji, opóźnienie w pobieraniu zamówień i długość kolejek. Wtedy czas reakcji może liczyć się od alertu, a nie od maila sklepu. Jak ustawić takie powiadomienia, opisujemy we wpisie monitoring integracji i alerty o błędach.

Aktualizacje i bezpieczeństwo w umowie utrzymaniowej

Oprogramowanie sklepu starzeje się nawet wtedy, gdy nikt go nie zmienia. Języki programowania, platformy i API mają własne cykle życia, a umowa powinna mówić, kto i kiedy za nimi nadąża. Dwa przykłady z dokumentacji producentów pokazują skalę zjawiska. PHP wspiera każdą gałąź aktywnie przez dwa lata od wydania, a potem przez kolejne dwa lata tylko w zakresie krytycznych poprawek bezpieczeństwa - dla PHP 8.2 wsparcie bezpieczeństwa kończy się 31 grudnia 2026 r. Shopify wydaje nową stabilną wersję API co kwartał i wspiera każdą co najmniej 12 miesięcy, a aplikacja odwołująca się do wersji niedostępnej dostaje odpowiedź z najstarszej dostępnej wersji (stan na październik 2026 - sprawdź aktualną dokumentację PHP i Shopify).

Z takich harmonogramów wynikają zapisy, które powinny znaleźć się w umowie:

1. Jak często wykonawca przegląda dostępne aktualizacje platformy, modułów i zależności, np. raz w miesiącu.

2. W jakim czasie wdraża poprawki bezpieczeństwa, z podziałem na krytyczne i pozostałe.

3. Że każda aktualizacja przechodzi test na środowisku testowym przed wdrożeniem na sklep.

4. Kto śledzi komunikaty o zmianach w API marketplace'ów, płatności i kurierów i z jakim wyprzedzeniem planuje dostosowanie.

5. W jakich oknach wolno wdrażać zmiany, a kiedy obowiązuje zamrożenie, np. przed Black Friday i w grudniu.

6. Jak wygląda plan cofnięcia wdrożenia i kopia przed każdą zmianą.

Migracja na nową wersję główną platformy lub języka to zwykle osobny projekt, a nie część abonamentu. Umowa powinna jednak zobowiązywać wykonawcę do uprzedzenia sklepu z wyprzedzeniem, że taka migracja będzie potrzebna, zanim wersja przestanie być wspierana.

Usługi zewnętrzne - czego wykonawca nie naprawi

Sklep zależy od wielu firm: platformy abonamentowej, hostingu, marketplace'ów, operatorów płatności, przewoźników i integratora. Gdy awaria leży po ich stronie, programista nie przywróci działania, ale może skrócić przestój. W umowie zapisz, że przy awarii usługi zewnętrznej wykonawca diagnozuje problem, potwierdza, że przyczyna leży po stronie dostawcy, zgłasza go z danymi technicznymi, wdraża obejście, jeśli jest możliwe, i po usunięciu awarii uzupełnia zaległe dane bez duplikatów. Czas takiej awarii nie powinien obciążać wykonawcy w rozliczeniu SLA, ale jego praca przy obejściu - powinna być objęta umową.

Pomocna jest prosta mapa zależności dołączona do umowy: lista usług zewnętrznych, z których korzysta sklep, adresy stron ze statusem usług, kanały zgłaszania problemów i osoba, która ma dostęp do konta u danego dostawcy. Gdy w nocy przestają spływać zamówienia z marketplace'u, dyżurny nie traci czasu na szukanie, kto może założyć zgłoszenie u dostawcy i gdzie sprawdzić, czy awaria dotyczy tylko jednego sklepu, czy wszystkich użytkowników.

Jak mierzyć, czy wykonawca dotrzymuje SLA

SLA bez pomiaru to deklaracja. Najprostszy wskaźnik to odsetek zgłoszeń obsłużonych w terminie, liczony osobno dla każdego priorytetu. Daty zgłoszenia, reakcji i przywrócenia działania muszą być zapisane w systemie zgłoszeń, do którego sklep ma wgląd:

[#chart:wpr82b]

Raport miesięczny powinien zawierać liczbę zgłoszeń według priorytetów, czasy reakcji i obejścia, przekroczenia z przyczynami, wykonane aktualizacje i wykorzystanie puli godzin, jeśli umowa ją przewiduje. Raz na kwartał warto omówić raport z wykonawcą i sprawdzić, czy priorytety nadal pasują do sklepu, np. po dodaniu nowego marketplace'u albo przejściu na inny system magazynowy.

[#tip] Poproś wykonawcę o krótką analizę po każdej awarii krytycznej: co się stało, jak długo trwało, jaka była przyczyna i co zmieniono, żeby się nie powtórzyło. Taka notatka jest cenniejsza niż kara umowna, bo realnie zmniejsza liczbę kolejnych awarii.

Godziny wsparcia i sezon sprzedaży w umowie SLA

Sklep sprzedaje wieczorami, w weekendy i w święta, a wykonawca zwykle pracuje w dni robocze. Umowa musi więc jasno mówić, w jakich godzinach liczy się czas reakcji, czy istnieje dyżur dla awarii krytycznych poza tymi godzinami i na jakich zasadach jest rozliczany. Zapis „reakcja do 2 godzin” przy wsparciu tylko w dni robocze oznacza, że awaria z sobotniego poranka może czekać do poniedziałku, a sklep traci cały weekend wysyłek.

Osobno warto opisać okresy szczytu. Przed Black Friday i w grudniu sklep potrzebuje szerszej gotowości, a jednocześnie mniejszej liczby zmian. Dobrą praktyką jest zapisanie w umowie możliwości zamówienia rozszerzonego dyżuru na wskazane dni, terminu ostatniego dużego wdrożenia przed sezonem oraz zasady, że w czasie zamrożenia zmian wdraża się wyłącznie poprawki błędów i bezpieczeństwa, zawsze z planem cofnięcia.

Jak przygotować sklep do umowy utrzymaniowej

Wykonawca wyceni i zaplanuje utrzymanie rzetelnie tylko wtedy, gdy wie, co zastanie. Zanim usiądziesz do negocjacji, zbierz podstawowe informacje o sklepie: platformę i jej wersję, listę modułów i aplikacji, własne modyfikacje kodu, listę integracji z opisem, co przesyłają, informację o hostingu, kopiach zapasowych i środowisku testowym oraz historię awarii z ostatniego roku. Taki spis pozwala ustalić realny zakres i uniknąć sytuacji, w której pierwsze miesiące umowy idą na odkrywanie, jak działa sklep.

Rozsądne jest też rozpoczęcie współpracy od audytu technicznego. Wykonawca przegląda wersje oprogramowania, logi integracji, zabezpieczenia i kopie zapasowe, a potem przedstawia listę ryzyk uporządkowaną według wagi. Na tej podstawie łatwiej ustalić priorytety, czasy reakcji i to, co trzeba naprawić przed startem SLA, zanim wykonawca zacznie odpowiadać za dostępność sklepu.

Własność kodu, dostępy i zakończenie umowy

Umowa utrzymaniowa kiedyś się kończy, a sklep musi działać dalej. Zapisy o zakończeniu współpracy trzeba ustalić na początku, kiedy obie strony są zainteresowane dobrą współpracą. Warto zapisać, że kod własnych modułów i integracji jest przechowywany w repozytorium należącym do sklepu, że konta techniczne, klucze API i aplikacje w portalach deweloperskich marketplace'ów są zakładane na sklep lub przekazywane wraz z dokumentacją, że wykonawca prowadzi aktualną dokumentację integracji i środowisk oraz że po wypowiedzeniu przez określony czas utrzymuje bieżącą obsługę i pomaga nowemu wykonawcy.

[#uwaga] Prawa autorskie do kodu, licencje, kary umowne, ograniczenie odpowiedzialności i powierzenie przetwarzania danych osobowych to zapisy prawne. Opisz w umowie swoje potrzeby biznesowe, a ich konstrukcję skonsultuj z prawnikiem.

Jak Vinson pomaga przy umowie utrzymaniowej sklepu

Zapewniamy wsparcie programistyczne dla sklepów i sprzedawców: integracje, automatyzacje, poprawki i rozwój sklepów oraz narzędzi. Pomagamy spisać zakres utrzymania, opisać priorytety językiem Twojego sklepu i ustalić czasy reakcji dopasowane do sprzedaży. W ramach utrzymania prowadzimy aktualizacje z testami na stagingu, monitorujemy integracje, reagujemy na awarie i przygotowujemy raporty z prac. Szczegóły znajdziesz na stronie Wsparcie programistyczne dla e-commerce.

Najczęściej zadawane pytania

Co powinna zawierać umowa utrzymaniowa SLA dla sklepu?

Listę utrzymywanych elementów oprogramowania, priorytety zgłoszeń opisane sytuacjami ze sklepu, czasy reakcji i obejścia dla każdego priorytetu, zasady aktualizacji i wdrożeń, sposób raportowania oraz plan zakończenia współpracy. Zapisy o odpowiedzialności i karach warto skonsultować z prawnikiem.

Czym różni się SLA od SLO?

SLO to docelowa wartość wskaźnika poziomu usługi, np. maksymalny czas przywrócenia działania przy awarii krytycznej. SLA to umowa, która zawiera takie cele i konsekwencje ich spełnienia lub niespełnienia. Takie rozróżnienie stosuje m.in. Google w książce Site Reliability Engineering.

Czy umowa utrzymaniowa obejmuje awarie Allegro, platformy lub operatora płatności?

Wykonawca nie naprawi awarii po stronie innej firmy, ale umowa powinna zobowiązywać go do diagnozy, zgłoszenia problemu dostawcy, wdrożenia obejścia, jeśli to możliwe, i uzupełnienia danych po usunięciu awarii. Czas samej awarii zewnętrznej zwykle nie jest wliczany do rozliczenia SLA.

Czy aktualizacje sklepu powinny być w abonamencie utrzymaniowym?

Regularne aktualizacje i poprawki bezpieczeństwa z testem na środowisku testowym zwykle tak. Migracja na nową wersję główną platformy lub języka to najczęściej osobny projekt, ale umowa powinna zobowiązywać wykonawcę do uprzedzenia o niej z wyprzedzeniem.

Co zrobić, gdy wykonawca nie dotrzymuje SLA?

Najpierw sprawdź raport i daty w systemie zgłoszeń, a potem omów przekroczenia z wykonawcą i poproś o analizę przyczyn. Jeśli problemy się powtarzają, skorzystaj z konsekwencji przewidzianych w umowie i przygotuj przejście do innego wykonawcy według planu zakończenia współpracy.

Dobra umowa utrzymaniowa nie jest najdłuższa, tylko najbardziej konkretna. Jeśli chcesz ustalić zakres i poziom utrzymania dla swojego sklepu i integracji, sprawdź wsparcie programistyczne Vinson.