Opieka techniczna sklepu internetowego to stały proces — aktualizacje, kopie zapasowe, monitoring, testy płatności i drobne poprawki — a nie jednorazowe wezwanie po awarii. Hosting odpowiada wyłącznie za to, żeby serwer działał; nie sprawdzi, czy moduł płatności nadal łączy się z bramką, ani czy kurier przyjmuje etykiety. Różnicę widać dopiero wtedy, gdy sklep przestaje przyjmować zamówienia w środku sezonu. Poniżej znajdziesz zakres pakietu rozbity na godziny, listę sygnałów ostrzegawczych, sposób czytania umowy SLA i realne widełki cenowe na 2025 rok.
Opieka techniczna to stały proces rozłożony na cztery filary. Każdy z nich ma inny zestaw zadań i inny rytm pracy.
Hosting obsługuje wyłącznie pierwszy filar i to w wąskim zakresie: dostawca pilnuje, żeby maszyna działała i miała zasoby. Nie zajrzy do modułu płatności po aktualizacji ani nie sprawdzi, czy wtyczka generująca etykiety InPost nadal zwraca poprawny plik. Regulaminy hostingów zwykle mają zapis, że dostawca nie odpowiada za działanie aplikacji — i to jest uczciwe, bo to nie jego rola.
Różnica w praktyce. Sklep, którego opieka kończy się na hostingu: działa jedenaście miesięcy bez zmian, w grudniu producent modułu płatności wypuszcza aktualizację, zmienia nazwę jednego pola w API i klient nie może dokończyć zamówienia. Nikt tego nie wychwycił, bo nikt nie testuje płatności po każdej zmianie. Sklep z aktywną opieką: wdrożenie najpierw na kopii, potem test transakcji niskokwotowej na produkcji, a monitoring pilnuje, czy zamówienia nadal spływają.
Kto realnie potrzebuje opieki: sklep z 50 zamówieniami miesięcznie i więcej (przy dwóch zamówieniach dziennie każdy dzień przestoju boli), firmy B2B z integracją ERP — Subiekt, Comarch, WF-Mag — gdzie zmiana w API potrafi zatrzymać stany magazynowe, oraz każdy sklep w pierwszych trzech miesiącach po migracji lub zmianie szablonu. Podobny zakres stosujemy w utrzymaniu i opiece technicznej sklepów w Zamościu i okolicach.
Zakres da się policzyć w godzinach, a nie tylko w jednej opłacie miesięcznej. Poniżej realny podział 10-godzinnego pakietu dla sklepu na PrestaShop z 200–400 zamówieniami miesięcznie i dwoma modułami integracyjnymi (płatności i kurier).
Co konkretnie dzieje się w tych godzinach:
/var/logs, w starszych wersjach /log), sprawdzenie, czy nocna kopia ma sensowny rozmiar i datę, podglądowa kontrola uptime i ważności SSL./admin.Czego pakiet nie obejmuje i dlaczego: nowych funkcji (konfigurator produktu, program lojalnościowy, przebudowa karty produktu) — to projekt z osobnym zakresem, nie rutynowa opieka; kampanii sezonowych, landingów i kodów rabatowych; migracji z 1.7 na 8.x albo na inny hosting, bo to wdrożenie z testami i przekierowaniami; pracy nad treściami i SEO, bo to inna kompetencja.
Pułapka przy podpisywaniu umowy: pakiet bez limitu godzin brzmi dobrze w ofercie, ale przy czterech zgłoszeniach tygodniowo zamienia się w niekontrolowany etat. Z kolei rozliczanie wyłącznie za efekt („płacisz, gdy coś padnie”) nie pokrywa pracy prewencyjnej, która właśnie do awarii nie dopuszcza. Widełki dla takich pakietów opisujemy w zestawieniu ceny utrzymania i opieki technicznej sklepu na 2025 rok.
| Zadanie w pakiecie 10 h | Godziny / mies. | Co obejmuje |
|---|---|---|
| Aktualizacje rdzenia i modułów | 2 h | PrestaShop 1.7/8.x, moduły płatności i kurierów, test na kopii przed wdrożeniem |
| Kopie zapasowe i monitoring | 1 h | Weryfikacja, czy backup się wykonał i da się odtworzyć; uptime, SSL, miejsce na dysku |
| Drobne poprawki | 4 h | CSS, teksty, szablony maili, konfiguracja modułu, poprawki po zgłoszeniach |
| Raport i spotkanie | 1 h | Logi błędów, czasy ładowania, zużycie zasobów, lista zadań na kolejny miesiąc |
| Bufor na zdarzenia | 2 h | Awaria po aktualizacji, błąd płatności, nieudane logowania, próba ataku |
Problemy techniczne rzadko pojawiają się z dnia na dzień. Zwykle zostawiają ślady, które da się zmierzyć, zanim klient napisze, że nie może zapłacić.
/admin. To najczęściej zautomatyzowane próby zgadywania hasła.Jak to sprawdzić samemu: PageSpeed Insights dla czasów ładowania (progi opisane w dokumentacji Web Vitals), log błędów PHP na serwerze, panel operatora płatności po statusach, panel InPost lub DPD po przesyłkach ze statusem błędu generowania etykiety.
Punkt odniesienia dla decyzji: policz sam — średnia wartość zamówienia razy liczba zamówień w dniu szczytu razy godziny przestoju. Nie chodzi o straszenie wymyślonymi kwotami, tylko o porównanie: roczny pakiet opieki to zwykle ułamek tej liczby.
SLA (Service Level Agreement) to zapis, w którym dostawca zobowiązuje się do konkretnych parametrów reakcji i naprawy. Najczęstszy błąd to czytanie SLA jak cennika: klient widzi „reakcja do 2 h” i zakłada, że po dwóch godzinach sklep normalnie przyjmuje zamówienia. Tymczasem to dwie różne liczby:
Realny SLA, który da się wyegzekwować: reakcja do 4 h w dni robocze 8:00–17:00, naprawa krytyczna do 24 h, komunikacja co 4 h do zamknięcia zgłoszenia, dwa kanały zgłoszeń (e-mail plus telefon do konkretnej osoby). Wskaźnik dostępności 99,5% miesięcznie oznacza około 3,6 h dopuszczalnego przestoju. Sprawdź, czy liczy się go od serwera hostingu, czy od działania sklepu — dla Ciebie liczy się to drugie.
W umowie pilnuj pięciu rzeczy: zakresu (aktualizacje rdzenia i wtyczek czy tylko wtyczek), wyłączeń (nowe funkcje to zwykle osobne zlecenie), kanału zgłoszeń, kar umownych (np. 5% abonamentu za każdą godzinę przekroczenia naprawy krytycznej) i procedury przekazania dostępów na wypadek zmiany dostawcy.
Pułapka: „wsparcie 24/7” w cenniku bez definicji. Zapytaj, kto realnie odbiera zgłoszenie o 3:00 w niedzielę i czy to wliczone w abonament, czy płatna interwencja poza pakietem. Mniejszym firmom wystarcza 8:00–18:00 w dni robocze plus jasno wyceniona eskalacja poza godzinami. Typowe zapisy umowy rozbieramy szerzej w materiale o SLA i umowie w pakiecie utrzymania sklepów z Łęcznej.
Widełki abonamentów na 2025 rok dla sklepów ze Szczebrzeszyna, Zamościa i okolicznych gmin (kwoty netto, miesięcznie):
Stawka godzinowa poza pakietem: 120–220 zł/h netto. Prace deweloperskie w PrestaShop i WooCommerce mieszczą się zwykle w 120–170 zł/h, prace serwerowe i DevOps (Nginx, PHP-FPM, Redis, migracje, konfiguracja backupów) w 150–220 zł/h. To nie widzimisię — diagnostyka wydajności serwera to inna kompetencja niż poprawka w CSS.
Co podnosi cenę: liczba wtyczek i modułów (każdy trzeba przetestować po aktualizacji), integracje z ERP i systemem magazynowym, wolumen ruchu i zamówień, długość czasu reakcji w SLA oraz to, czy dostawca utrzymuje środowisko testowe. Przy rosnącym ruchu dochodzą prace nad wydajnością — cache, kompresja, parametry Core Web Vitals — i to osobny blok godzin w miesiącu.
Porównanie z życia: trzy płatne wtyczki po 80 USD rocznie to około 1000 zł. Brzmi tanio, ale każda dokłada ryzyko konfliktu i 1–2 h testów po aktualizacji, czyli 150–400 zł miesięcznie pracy, której nikt nie planuje. Szerzej rozpisane widełki cenowe utrzymania sklepów z Zamościa na 2025 pokazują, że różnica między ofertami wynika najczęściej z zakresu, nie z jakości.
Platforma nie zmienia faktu, że sklep trzeba utrzymywać — zmienia charakter pracy i ryzyko.
PrestaShop. Aktualizacja rdzenia, np. z 1.7.8 na 8.x, to operacja na kopii i środowisku testowym. Rdzeń bywa nadpisywany przez motyw i moduły (katalog /override/), więc po aktualizacji potrafi wyłączyć się katalog produktów albo szablon zamówienia. Za to przyrost liczby zamówień mniej boli niż w Woo — architektura jest bardziej przewidywalna. Uwaga na moduły pisane pod PHP 7.x, których autor przestał je rozwijać. Punkt odniesienia dla zmian w kodzie to dokumentacja deweloperska PrestaShop.
WooCommerce. Aktualizacje wtyczek i motywów potrafią się kłócić: konflikt jQuery, niekompatybilność z HPOS, rozjechane style po zmianie szablonu. Podstawa to cache (LiteSpeed, WP Rocket), Redis lub Memcached, ograniczenie autoloadu w tabeli wp_options i indeksy w tabelach zamówień. Bez tego 100 zamówień dziennie kładzie panel administracyjny na kilkanaście sekund przy każdym zapisie produktu.
Kiedy własny moduł jest tańszy niż kolejny plugin. Trzy sytuacje: integracja z nietypowym ERP nie ma gotowego łącznika, logika wysyłki jest specyficzna (palety, gabaryty, strefy), a każda aktualizacja wtyczki psuje coś, co działało. Moduł na zamówienie to 3000–8000 zł jednorazowo. Płatna wtyczka to 400 zł rocznie plus 6 h testów po każdej aktualizacji, czyli 700–1300 zł. Po dwóch latach własny kod bywa tańszy, a przede wszystkim jest przewidywalny. Zakres takiej opieki opisujemy przy okazji utrzymania i opieki technicznej sklepów w Zamościu.
| Zadanie w pakiecie | PrestaShop | WooCommerce |
|---|---|---|
| Aktualizacja platformy | Rzadsze, ale ryzykowniejsze — kopia, środowisko testowe, weryfikacja katalogu /override/ | Częste i drobne — aktualizuj wtyczki partiami, po każdej sprawdź koszyk i płatność |
| Typowy konflikt po aktualizacji | Moduł nadpisujący pliki motywu | Wtyczka kontra wtyczka lub szablon |
| Wydajność przy wzroście zamówień | Mniej wrażliwa na ruch, rośnie baza i zapotrzebowanie na cache | Wymaga cache, Redis i optymalizacji bazy, inaczej panel zwalnia |
| Integracja z ERP | Gotowe łączniki bywają płatne i rzadko aktualizowane — często własny moduł | Wtyczek dużo, jakość nierówna — własny plugin stabilniejszy |
| Kopia zapasowa | Baza, /modules, /override, motyw + test odtworzenia | Baza, /wp-content (wtyczki, motyw, uploads) + test odtworzenia |
Kopii nie robi się „na wszelki wypadek”. Robi się je według rytmu, który da się sprawdzić w panelu. Dla sklepu na PrestaShopie sensowny układ to kopia różnicowa raz dziennie (pliki zmienione + baza) i pełna raz w tygodniu, obie poza serwer produkcyjny — inny dostawca albo storage S3-compatible w innej lokalizacji. Jeśli kopie leżą na tym samym hostingu co sklep, awaria hostingu zabiera jedno i drugie. Retencja: 30 dni dziennych, 12 tygodniowych, 3 miesięczne.
Raz w miesiącu trzeba wykonać test odtworzenia: wgranie kopii na staging i sprawdzenie czterech rzeczy — czy baza importuje się bez błędów, czy zdjęcia produktów się ładują, czy zamówienia z ostatnich 48 godzin są w bazie, czy koszyk i płatność działają. Kopia, której nikt nie odtworzył, to nie kopia, a plik.
Aktualizacje idą etapami: staging → test płatności i wysyłek → produkcja. Test płatności to transakcja na 1 zł w trybie sandbox (Przelewy24, PayU, Stripe) albo realna mała płatność ze zwrotem; test wysyłek to etykieta próbna w integratorze (Apaczka, Furgonetka, BaseLinker). Okno aktualizacji: wtorek–czwartek, 6:00–8:00 lub 22:00–24:00, nigdy w piątek po południu przed weekendową promocją. Uwaga na modyfikacje w plikach modułów i motywu — aktualizacja je nadpisze. Zmiany w motywie trzymaj w child theme, poprawki w modułach jako overrides. Przeskok np. z 1.7 na 8.x to migracja, nie kliknięcie „aktualizuj” — opisuje to dokumentacja dla deweloperów PrestaShop.
Monitoring: uptime sprawdzany co minutę z zewnątrz, alert na błędy PHP 500 i skok 404, wydajność bazy (wolne zapytania, długie blokady), SSL i domena — alerty na 30, 7 i 1 dzień przed wygaśnięciem. RODO: umowa powierzenia przetwarzania danych (art. 28), indywidualne konta zamiast wspólnego „admin”, 2FA, minimalne uprawnienia i rejestr tego, kto i kiedy miał dostęp. Rytm pracy przy podobnych sklepach pokazujemy w utrzymaniu i opiece technicznej sklepów Zamość.
| Zadanie | Częstotliwość | Dowód wykonania |
|---|---|---|
| Kopia różnicowa | codziennie, ok. 2:00 | wpis w panelu backupu z rozmiarem |
| Kopia pełna | raz w tygodniu (niedziela) | link do archiwum poza serwerem sklepu |
| Test odtworzenia kopii | raz w miesiącu | notatka: data, wersja, wynik importu |
| Aktualizacje modułów | raz w miesiącu, po stagingu | lista zmian + wynik testu płatności |
| Aktualizacja rdzenia / migracja | 1–2 razy w roku | plan migracji i okno serwisowe |
| Test płatności i wysyłek | po każdej aktualizacji | zrzut transakcji testowej i etykiety |
| Monitoring uptime | co 1 minutę | raport miesięczny z czasem niedostępności |
| SSL i domena | alerty 30/7/1 dzień | potwierdzenie odnowienia i weryfikacja DNS |
Szczebrzeszyn leży około 20 km od Zamościa — dojazd zajmuje jakieś 25 minut. Od tego zależy, czy „lokalny partner” jest realną przewagą, czy hasłem w ofercie.
Lokalny kontakt ma sens, gdy problem jest fizyczny: konfiguracja drukarki etykiet na stanowisku pakowania, podłączenie sklepu do lokalnego systemu magazynowego lub księgowego, szkolenie pracowników z panelu zamówień, problem z internetem w magazynie. Wtedy ktoś, kto przyjedzie i zajmie się tym w godzinę, bywa tańszy niż trzygodzinna sesja zdalna, w której tłumaczysz przez telefon, gdzie jest przycisk.
Nie ma znaczenia, gdy praca dotyczy serwera: aktualizacja modułu, poprawka w szablonie, błąd 500, konfiguracja cronów, wpis w .htaccess, analiza logów. To robi się przez SSH, SFTP lub panel hostingowy. Firma z Lublina czy Rzeszowa z reakcją w 2 godziny wygra z lokalną, która odpisuje po dwóch dniach. Jeśli partner mówi, że „optymalizuje wydajność”, zapytaj o metryki LCP, INP i CLS opisane w materiałach web.dev o Web Vitals, a nie o „przyspieszenie strony”.
Bezpośrednio z deweloperem czy przez account managera? Przy pakiecie 5–10 godzin miesięcznie AM to dodatkowe ogniwo: zgłoszenie przechodzi przez niego, zanim trafi do osoby, która naprawia. To potrafi dodać od godziny do dwóch dni. AM ma sens, gdy masz kilka sklepów, kilku wykonawców i potrzebujesz jednej osoby pilnującej terminów i rozliczeń.
Kryteria do sprawdzenia w jeden dzień: wyślij zgłoszenie testowe w piątek o 21:30 i zobacz, kiedy przyjdzie merytoryczna odpowiedź (autoresponder się nie liczy). Zapytaj, czy dostaniesz dostęp do logów i historii zgłoszeń. Poproś o dokumentację przekazaną po wdrożeniu: repozytorium, opis serwera, listę modułów z wersjami, dane dostępowe. Czerwone flagi: brak widełek cenowych w ofercie, SLA tylko w rozmowie, brak dostępu do własnego kodu po zakończeniu współpracy. Jak to wygląda w mniejszych miastach regionu, opisujemy w opiece technicznej sklepów Krasnystaw.
Ofertę opieki da się porównać tylko wtedy, gdy zadajesz te same pytania każdemu wykonawcy. Poniżej dwanaście, które w praktyce oddzielają poważny pakiet od „będziemy w kontakcie”.
Co dostajesz na starcie: audyt techniczny (wersja PHP i PrestaShop, lista modułów z datą ostatniej aktualizacji, obecność child theme, kto ma dostępy, status SSL i domeny, konfiguracja cronów, czas odpowiedzi serwera), dostęp do panelu zgłoszeń oraz kontakt do konkretnego dewelopera — imię, mail, telefon, nie numer centrali.
Punkt kontrolny po 30 dniach. Sprawdź trzy liczby: średni czas pierwszej reakcji wyliczony z historii zgłoszeń, ile godzin z pakietu faktycznie wykorzystano i na co, oraz czy raport zawiera rzeczy, których nie zlecałeś (kopie, alerty, monitoring). Jeśli po miesiącu nie wiesz, ile godzin zużyto i na jakim zadaniu, umowa nie działa — niezależnie od tego, jak brzmiała. Zapisy SLA i wzór umowy omawiamy szerzej przy SLA i umowie w opiece technicznej sklepów Łęczna.
| Pytanie do partnera | Co uznajemy za dobrą odpowiedź |
|---|---|
| Jaki jest czas reakcji i naprawy przy awarii krytycznej (sklep nie przyjmuje zamówień)? | np. reakcja 1 h, naprawa 4 h w godz. 8–20, osobny tryb poza godzinami |
| Co dokładnie obejmuje SLA, a co jest wyłączone? | wypisane wyłączenia: prace rozwojowe, zmiany w szablonie, migracje |
| Jak często robicie kopie i gdzie leżą? | dzienne różnicowe + tygodniowe pełne, poza serwerem sklepu |
| Kiedy ostatnio testowaliście odtworzenie kopii? | konkretna data i wynik, nie słowo „regularnie” |
| Jak wygląda raport miesięczny? | co wykonano, ile godzin, co wykrył monitoring |
| Kto ma dostęp do mojego panelu i serwera? | imienne konta, 2FA, minimalne uprawnienia |
| Czy podpiszecie umowę powierzenia przetwarzania danych? | tak, z załącznikiem opisującym zabezpieczenia |
| Do kogo należy kod i repozytorium po zakończeniu umowy? | do klienta, z przekazaniem repo, bazy i dostępów |
| Jak przekazujecie pracę, jeśli zrezygnuję? | opisana procedura, termin np. 14 dni, dokumentacja |
| Ile kosztuje godzina poza pakietem? | podana stawka w zł/h, bez widełek „od–do” |
| Czy aktualizacje idą etapowo przez staging? | tak, z testem płatności i wysyłek przed produkcją |
| Jaki jest okres wypowiedzenia i czy są opłaty na koniec? | podany okres, brak ukrytych kosztów przekazania |
Traktowanie hostingu jako opieki technicznej. Klient płaci 300 zł miesięcznie za serwer i zakłada, że ktoś pilnuje aktualizacji, kopii i płatności.
Jak wykryć: Otwórz umowę z dostawcą hostingu i poszukaj zapisów o aktualizacjach modułów, testach płatności i odtwarzaniu kopii. Zwykle ich tam nie ma — jest tylko dostępność serwera.
Jak naprawić: Rozdziel dwie umowy: hosting (infrastruktura) i opieka techniczna (aplikacja sklepu). W drugiej zapisz konkretne zadania i godziny, nie hasło „wsparcie”.
Kopia zapasowa trzymana na tym samym serwerze co sklep albo w tym samym panelu hostingowym.
Jak wykryć: Zapytaj dostawcę, gdzie fizycznie leży kopia i kiedy ostatnio odtwarzano ją na środowisku testowym. Jeśli odpowiedź brzmi „mamy backupy”, ale nikt tego nie testował, to nie jest kopia.
Jak naprawić: Ustal zasadę: kopia lokalna (szybkie odtworzenie), kopia poza serwerem produkcyjnym i test odtworzenia raz na kwartał, z krótkim protokołem.
Aktualizacje wtyczek i rdzenia robione bezpośrednio na produkcji, bez kopii i bez okna serwisowego.
Jak wykryć: Sprawdź, czy istnieje środowisko testowe (staging) i czy zmiany w kodzie są wersjonowane w Git. Brak obu rzeczy oznacza, że każda aktualizacja to loteria.
Jak naprawić: Wprowadź kolejność: kopia → staging → test koszyka i płatności → wdrożenie na produkcję w oknie o najniższym ruchu → ponowny test płatności.
SLA bez zdefiniowanych czasów. W cenniku jest „wsparcie 24/7”, ale nigdzie nie zapisano, ile wynosi czas reakcji i czas naprawy.
Jak wykryć: Przeczytaj umowę i wypisz, jakie czasy są podane dla zdarzeń krytycznych (sklep nie przyjmuje zamówień) i dla zwykłych zgłoszeń. Puste miejsce to brak zobowiązania.
Jak naprawić: Dopisz tabelę SLA: czas reakcji, czas naprawy krytycznej, częstotliwość komunikacji do zamknięcia zgłoszenia i kanał przyjmowania zgłoszeń.
Zgłoszenia wysyłane „na WhatsAppie do programisty”, bez rejestru i bez jednego kanału.
Jak wykryć: Policz, ile zgłoszeń z ostatnich trzech miesięcy da się odtworzyć: kto zgłosił, kiedy, co zmieniono i jak zamknięto temat. Jeśli to mniej niż połowa, masz problem procesowy.
Jak naprawić: Ustal jeden kanał zgłoszeń (mail na wspólny adres albo system ticketowy) i krótki rejestr: data, opis, status, kto pracował, czas zamknięcia.
Instalowanie wtyczek i modułów tylko dlatego, że są tanie albo darmowe, bez sprawdzenia wsparcia i zgodności z wersją rdzenia.
Jak wykryć: Sprawdź datę ostatniej aktualizacji modułu, changelog i liczbę otwartych zgłoszeń wsparcia. Wtyczka nieaktualna od roku to dług techniczny.
Jak naprawić: Zr ób audyt modułów raz na kwartał: zostaw te, które mają aktywne wsparcie i są zgodne z używaną wersją PrestaShop lub WooCommerce, resztę zastąp lub usuń.
Opieka techniczna to stały proces, nie naprawa po awarii — a hosting to tylko jeden z jej elementów. Zakres da się policzyć: pakiet 10 godzin miesięcznie rozkłada się na aktualizacje, kopie i monitoring, drobne poprawki, raport oraz bufor na nieprzewidziane. Zanim podpiszesz umowę, sprawdź, czy SLA rozdziela czas reakcji od czasu naprawy i czy kary umowne są w ogóle wyegzekwowalne. Zacznij od własnej checklisty — jeśli kilka punktów wypada źle, problem już jest, tylko jeszcze nie widać go w sprzedaży.
Hosting odpowiada za to, żeby serwer i baza danych działały — koniec zakresu. Opieka techniczna obejmuje aplikację sklepu: aktualizacje rdzenia i modułów, kopie zapasowe z testem odtworzenia, monitoring dostępności, testy płatności i kurierów, przegląd logów oraz drobne poprawki. Możesz mieć najlepszy hosting i sklep, który nie przyjmuje zamówień, bo moduł płatności nie został zaktualizowany. To dwie różne usługi i dwie różne umowy.
W praktyce rynkowej pakiet podstawowy to 400–800 zł miesięcznie, standard 800–1800 zł, a rozszerzony z integracjami ERP 1800–4000 zł. Prace poza pakietem rozlicza się stawka godzinową 120–220 zł netto, zależnie od tego, czy to praca deweloperska, czy DevOps. Na cenę wpływa liczba modułów, integracje, wolumen ruchu i zapisy SLA. Widełki dla regionu opisaliśmy szerzej w materiale o cenach utrzymania sklepów w 2025 roku.
SLA to zapisane zobowiązanie dotyczące obsługi zgłoszeń. Kluczowe są dwie różne liczby: czas reakcji (kiedy ktoś potwierdza zgłoszenie i zaczyna pracę) oraz czas naprawy (kiedy problem jest usunięty). Realny przykład: reakcja do 4 godzin w dni robocze, naprawa krytyczna do 24 godzin, komunikacja co 4 godziny aż do zamknięcia zgłoszenia. Dopytaj też o wyłączenia z zakresu, kanał zgłoszeń, wskaźnik dostępności i kary umowne. Wzór zapisów omawiamy przy okazji umowy i SLA dla sklepów.
Nie zawsze w pełnym pakiecie. Przy kilkudziesięciu zamówieniach miesięcznie sensowny jest pakiet minimalny: kopie zapasowe z testem odtworzenia, aktualizacje bezpieczeństwa i test płatności raz na kwartał. Pełny pakiet z monitoringiem i SLA zaczyna się opłacać przy sklepie powyżej 50 zamówień miesięcznie, w modelu B2B z integracjami ERP albo po migracji na nową wersję platformy. Warto policzyć, ile kosztuje jedna doba przestoju w szczycie sprzedaży.
Zacznij od czterech miejsc: pomiar Core Web Vitals dla kilku kart produktu, log błędów PHP z hostingu, panel operatora płatności z raportem odrzuceń oraz panel kuriera. Do tego zajrzyj do listy modułów i sprawdź daty ostatnich aktualizacji. Jeśli któryś moduł nie był ruszany od ponad pół roku, to pierwszy kandydat do przeglądu. Metryki i progi opisuje dokumentacja Web Vitals.
Najczęściej spotyka się upust w abonamencie za miesiąc, w którym przekroczono czas naprawy krytycznej — rzędu 10–30% opłaty miesięcznej, z limitem łącznym np. 50%. Ważniejsze od samej kary jest to, czy czas naprawy ma zdefiniowany start (moment zgłoszenia) i co dokładnie się liczy jako zdarzenie krytyczne. Zapis bez definicji jest niesprawdzalny, więc trudno go wyegzekwować.
Zwykle nie — pakiet obejmuje utrzymanie istniejącego rozwiązania: aktualizacje, kopie, monitoring i drobne poprawki. Nowe moduły, zmiany w szablonie graficznym, kampanie sezonowe i migracje wycenia się osobno, bo to projekty, a nie obsługa. Zapisz ten podział w umowie, żeby uniknąć sporów o to, czy „drobna poprawka” obejmuje budowę nowego integratora. Zakres pakietu dla sklepów w regionie opisujemy w materiale o utrzymaniu i opiece technicznej sklepów.
Jeśli chcesz wiedzieć, jak wygląda Twoja sytuacja bez zgadywania, wyślij nam adres sklepu i powiemy, które punkty z checklisty wymagają uwagi w pierwszej kolejności. Kontakt do DropDigital znajdziesz na stronie głównej.