Co dokładnie obejmuje utrzymanie i opieka techniczna sklepu

W ofertach utrzymania i opieki technicznej sklepu dwa słowa są używane zamiennie, choć opisują inne obowiązki. Utrzymanie to reagowanie: coś padło, wykonawca wchodzi i naprawia. Opieka techniczna to stały nadzór: monitoring, aktualizacje, kopie zapasowe, przeglądy i planowanie z wyprzedzeniem. Różnica jest praktyczna — jeśli w umowie jest zapisane tylko „utrzymanie”, nie ma podstawy, żeby wymagać comiesięcznej aktualizacji modułów, testu odtworzenia backupu ani raportu z prac. Dlatego przed porównaniem ofert rozbij zakres na cztery obszary i przy każdym zapisz, kto co robi oraz w jakim czasie.

Przykład z pracy z klientami: sklep na WooCommerce z kilkudziesięcioma wtyczkami. Po aktualizacji WooCommerce przestała działać wtyczka od fakturowania — zamówienia schodziły, ale faktury się nie generowały. Wykonawca „utrzymania” naprawił to po dwóch dniach, bo w umowie nie było monitoringu integracji ani testu po aktualizacji. Opieka techniczna zakłada środowisko staging, wdrożenie tam pierwsze i sprawdzenie kluczowych ścieżek (koszyk, płatność, mail z potwierdzeniem) po wdrożeniu na produkcję.

Typowy przydział godzin w pakiecie to skala: 2 h/mc jako minimum (mały sklep, tylko aktualizacje, kopie i monitoring), 5–8 h/mc jako standard dla MŚP (dochodzi optymalizacja i drobne poprawki), 15 h i więcej przy B2B z integracjami ERP, wieloma kurierami i katalogiem wielojęzycznym. Godziny warto rozliczać w cyklu miesięcznym z jasną zasadą: przenoszone na kolejny miesiąc albo przepadające — obie opcje są spotykane, ale musi być to napisane wprost.

Czego opieka nie obejmuje: nowych funkcji sklepu (konfigurator produktu, program lojalnościowy, nowa bramka płatnicza), kampanii marketingowych i treści, zmian graficznych większych niż drobna poprawka, przebudowy szablonu i migracji sklepu. To osobne projekty wyceniane poza pakietem. Kiedy dostawca wrzuca je do „abonamentu”, zwykle kryje się za tym limit niejawny. Podobne różnice w zapisach umowy opisujemy przy okazji zestawienia dla sklepów z Łęcznej i okolic oraz przewodnika dla sklepów z Krasnegostawu.

Ile kosztuje utrzymanie sklepu internetowego – realne widełki

Punktem odniesienia jest stawka godzinowa za pracę deweloperską w Polsce: zwykle 120–200 zł netto. Różnica bierze się ze specjalizacji — osoba od motywu WooCommerce jest tańsza niż ktoś, kto pisze moduł do PrestaShop i integrację z systemem ERP. Z tej stawki wynikają widełki miesięczne: mały sklep na WooCommerce to 350–700 zł netto/mc, średni PrestaShop 800–1800 zł/mc, a sklep B2B z ERP i integracjami 2000–4000 zł/mc. Przy stawce 150 zł/h pakiet 5 h to 750 zł — więc oferta „opieka za 300 zł z nielimitowanymi poprawkami” oznacza, że w tej cenie nie ma prawdziwej pracy deweloperskiej, tylko automatyczne aktualizacje z panelu.

Co podnosi cenę: liczba modułów i wtyczek (każda to potencjalny konflikt po aktualizacji), integracje z ERP, systemami kurierskimi i bramkami płatniczymi, niestandardowy motyw, którego nie da się zaktualizować jednym kliknięciem, sklep wielojęzyczny oraz ruch powyżej 100 tys. wizyt miesięcznie — wtedy dochodzi CDN, konfiguracja cache, indeksy w bazie i pilnowanie metryk wydajności, których zasady opisuje dokumentacja Web Vitals.

Rozliczenie godzinowe z limitem jest bezpieczniejsze, gdy nie znasz swojego rytmu pracy: płacisz za faktycznie wykorzystane godziny, widzisz w raporcie, co zostało zrobione, i możesz zweryfikować stawkę. Abonament „wszystko w cenie” wygrywa tam, gdzie zakres jest naprawdę zamknięty i przewidywalny — np. stałe 8 h/mc regularnie wykorzystywane na rozwój sklepu, bez prac projektowych. Pułapki abonamentu: brak definicji „drobnej zmiany”, nadgodziny rozliczane po stawce wyższej niż w cenniku podstawowym, brak prawa do niewykorzystanych godzin przy mniejszym zakresie prac.

SLA w umowie: jakie zapisy mają sens i jak je sprawdzić

SLA to miejsce, w którym najczęściej sprzedaje się obietnicę bez pokrycia. Pierwsza zasada: reakcja to nie naprawa. Zapis „czas reakcji 1 h” oznacza, że ktoś odezwie się i zacznie diagnozę — nie że sklep wróci do sprzedaży w godzinę. W umowie powinny być trzy osobne liczby: reakcja (1–2 h w godzinach pracy dla incydentu krytycznego, 8–24 h dla zwykłego zgłoszenia), czas obejścia problemu (workaround, np. 8 h) i czas naprawy docelowej (24–48 h).

Druga zasada: zdefiniuj incydent krytyczny. Bez definicji każdy spór kończy się dyskusją. Krytyczne są sytuacje: sklep nie przyjmuje zamówień, błąd 500 na koszyku lub płatności, niedziałająca bramka płatnicza, brak dostępu do panelu lub podejrzenie wycieku danych, wygasły certyfikat SSL, awaria DNS. Trzecia: okno serwisowe na aktualizacje i wdrożenia, np. 22:00–6:00, z informacją o pracach z 24-godzinnym wyprzedzeniem. Wyjątkiem są pilne łatki bezpieczeństwa — te wdraża się od razu, ale i to warto zapisać jako wyjątek od reguły.

Czwarta: kanał zgłoszeń i eskalacja. Jeden adres e-mail lub panel zgłoszeń do wszystkiego plus numer telefonu wyłącznie na sytuacje krytyczne. Po stronie wykonawcy musi być wskazana osoba decyzyjna — z imienia i nazwiska, nie „dział wsparcia”. Piąta: konsekwencje przekroczenia SLA — rabat 10–20% na kolejny miesiąc, dodatkowe godziny w rozliczeniu albo prawo do wypowiedzenia bez okresu. Sprawdź też, jak szybko dostaniesz kopie zapasowe i dostępy po zakończeniu umowy — to jedyny realny sposób, żeby zmienić dostawcę. Harmonogram wydania wersji i kompatybilność modułów po aktualizacji PrestaShop opisuje dokumentacja dla deweloperów PrestaShop. Podobny układ zapisów stosujemy w umowach dla sklepów z Hrubieszowa i sklepów z Narola.

Co jest w pakiecie, a co zwykle okazuje się dopłatą

Spory rozliczeniowe prawie zawsze biorą się z jednego zdania w ofercie: „opieka techniczna”. Jeden wykonawca rozumie przez to 20 minut pracy w miesiącu, drugi – realny dyżur. Zanim porównasz ceny, ustal, co jest w abonamencie, a co osobnym zleceniem.

Do pakietu standardowo wchodzą: aktualizacje rdzenia i modułów, kopie zapasowe z retencją 30 dni, monitoring dostępności, pilnowanie certyfikatu SSL oraz drobne poprawki w ramach puli godzin. Dopłatą są nowe funkcje i moduły, migracja na nową wersję główną platformy, integracje z nowym systemem (ERP, magazyn, kolejny kurier) oraz optymalizacja wydajności po dużym wzroście ruchu.

Zasada pytania ofertowego: wyślij jedno zdanie – „proszę o listę zadań wchodzących w abonament i stawkę za prace poza nim”. Dwie oferty po 800 zł netto mogą różnić się zakresem trzykrotnie i dopiero ta lista to pokaże. Warto też zapytać, czy godziny z pakietu przechodzą na kolejny miesiąc, czy przepadają pierwszego dnia.

Backup sprawdzaj tak samo jak cenę. Trzy rzeczy do ustalenia: lokalizacja offsite (inne konto, inny serwer, nie ten sam dysk, na którym stoi sklep), częstotliwość minimum raz dziennie baza plus pliki oraz test odtworzenia co kwartał. Poproś o datę ostatniego testu i czas odtworzenia – wykonawca, który prowadzi log, poda je w minutę. Jeśli nikt nie potrafi tego pokazać, kopie prawdopodobnie nie zostały nigdy użyte.

Aktualizacje rdzenia PrestaShop wychodzą cyklicznie i mają sens tylko wtedy, gdy ktoś je wdraża – pełną listę zmian opisuje dokumentacja deweloperska PrestaShop. W umowie niech znajdzie się zapis, kto ponosi odpowiedzialność za nieudaną aktualizację i w jakim czasie przywraca działającą wersję.

• Godziny w pakiecie – czy przechodzą dalej, czy przepadają co miesiąc.
• Kto płaci za czas reakcji, gdy awaria jest po stronie hostingu, a nie sklepu.
• Czy drobne poprawki obejmują szablon, czy tylko treści i ustawienia.

Pierwsza umowa to najczęstsze miejsce na nieporozumienia – wzór zapisów i podział obowiązków opisaliśmy w przewodniku o utrzymaniu i opiece technicznej sklepów Łęczna.

7 sygnałów, że Twój sklep potrzebuje opieki już teraz

Autodiagnoza zajmuje kwadrans i nie wymaga programisty. Poniżej siedem objawów, które w praktyce najczęściej poprzedzają poważniejszą awarię.

1. Wersja PHP po zakończeniu wsparcia producenta. Sprawdź w panelu hostingu (DirectAdmin, cPanel, Plesk) albo przez plik phpinfo. PHP 7.4 i 8.0 nie dostają już łatek bezpieczeństwa – jeśli sklep na nich działa, jest odsłonięty.
2. Kopie zapasowe leżą tylko na tym samym serwerze co sklep. Awaria dysku albo błędna aktualizacja zabiera jedno i drugie. Sprawdź, czy archiwum trafia na inne konto lub do zewnętrznej przestrzeni.
3. PrestaShop albo WooCommerce starsze o 2+ wersje główne. Rośnie ryzyko, że automatyczna aktualizacja się zablokuje, a różnice w schemacie bazy i wtyczkach trzeba będzie nadrabiać ręcznie.
4. Brak monitoringu. O awarii dowiadujesz się mailem od klienta, nie z alertu. Podstawowy monitoring (np. UptimeRobot) sprawdza stronę co 1–5 minut i wysyła SMS, gdy odpowiedź nie wróci.
5. Błędy 5xx w Google Search Console lub rosnąca liczba 404 po zmianach. Raport „Indeksowanie stron” pokaże, czy problem jest jednorazowy, czy narasta. Wzrost 404 po przebudowie kategorii to utracone linki, nie „chwilowa statystyka”.
6. TTFB powyżej 0,8 s i LCP powyżej 2,5 s sprawdzane na telefonie. Próg 2,5 s to granica dobrego LCP w Core Web Vitals – powyżej niej tracisz część ruchu mobilnego.
7. Brak osoby, która w 15 minut wejdzie na serwer i sprawdzi logi. To nie kwestia umiejętności, tylko dyżuru: dostęp do SSH lub panelu, znajomość ścieżki logów, umiejętność odczytania ostatnich wpisów.

Dwa–trzy zaznaczone punkty to jeszcze nie pożar, ale sygnał, że sklep działa na szczęściu. Jeśli nie wiesz, od czego zacząć, kolejność pierwszych kroków opisaliśmy w przewodniku o utrzymaniu i opiece technicznej sklepów Chełm – od czego zacząć. Wartości progowe i sposób ich pomiaru znajdziesz w dokumentacji Web Vitals.

Jak wybrać wykonawcę opieki – pytania, które warto zadać

Opiekę techniczną łatwo sprzedać i trudno zweryfikować przed podpisaniem umowy. Poniższe pytania zadaj w tej samej rozmowie, w której dostajesz cenę – nie w drugim mailu po tygodniu.

Kto realnie pracuje na sklepie? Chcesz usłyszeć nazwisko lub rolę osoby, która odbierze telefon w krytycznym momencie, a nie „nasz zespół”. Jeśli dostawca jest pośrednikiem i zleca dalej, czas reakcji zwykle się wydłuża, a odpowiedzialność rozmywa.

Czy dostaję pełny dostęp do kodu, serwera i repozytorium? Odpowiedź musi być jednoznaczna: tak. Ustal też, co dzieje się z tymi dostępami po zakończeniu umowy – czy przechodzą na Ciebie bezwarunkowo, czy zostają u wykonawcy.

Jak wygląda przekazanie sklepu? Eksport bazy danych, repozytorium kodu, dokumentacja wdrożonych zmian, plik z konfiguracją integracji. Brak któregokolwiek z tych elementów oznacza, że przy zmianie dostawcy zapłacisz za odtworzenie tego, co już masz.

Czy robi Pan test odtworzenia z backupu na moich oczach? Test trwa zwykle kilkadziesiąt minut. Warto w nim uczestniczyć: widzisz, gdzie leży archiwum, jak długo trwa odtworzenie i czy po procedurze sklep działa.

Jak raportuje Pan pracę? Wymagaj logu godzin, opisu wykonanych zadań i wyceny przed każdą pracą poza pakietem. Zapytaj też o doświadczenie z Twoją platformą i konkretnymi integracjami: InPost, DPD, DHL, ERP.

• Zapisz terminy odpowiedzi na piśmie – „szybko” nie jest czasem reakcji.
• Ustal stawkę za prace poza abonamentem przed pierwszym zleceniem.
• Sprawdź, czy wykonawca pokaże logi z ostatniego miesiąca.

Jeśli porównujesz kilka ofert z regionu, pomocny będzie przegląd zapisów SLA w materiałach o utrzymaniu i opiece technicznej sklepów Hrubieszów oraz zestawienie pakietów w przewodniku o utrzymaniu i opiece technicznej sklepów Narol.

Świdnik i Lubelszczyzna – czy lokalny wykonawca ma przewagę

Lublin i Świdnik dzieli około 10 km, czyli 20–25 minut jazdy. To mniej więcej tyle, ile zajmuje przejazd z jednego końca Lublina na drugi. Praktyczny wniosek jest jeden: jeśli coś wymaga fizycznej obecności, wykonawca z Lublina jest na miejscu tego samego dnia, a nie „w przyszłym tygodniu, jak wrócę z delegacji”.

Większość pracy i tak odbywa się zdalnie. Standardowy warsztat to SSH/SFTP do serwera lub kontenera, panel hostingu (DirectAdmin, cPanel, Plesk albo panel dostawcy VPS), środowisko staging na subdomenie, dostęp do repozytorium Git i VPN, jeśli sklep łączy się z systemem ERP w firmie. Z mojej praktyki 95% zgłoszeń – aktualizacja modułu, poprawka szablonu, konfiguracja płatności, odnowienie certyfikatu SSL – nie wymaga wyjazdu. Dojazd nie jest więc przewagą codzienną, tylko awaryjną.

• Migracja sklepu na inny serwer lub zmiana hostingu – przepięcie DNS, przenosiny bazy, testy po stronie klienta.
• Przenosiny biura lub magazynu – zmiana drukarek etykiet, integracji magazynowej, sieci lokalnej.
• Szkolenie zespołu z panelu zamówień albo nowego modułu – dwie godziny przy jednym stole skracają tydzień maili.
• Duże wdrożenie integracji (kurierzy, ERP, hurtownia) – testy na żywych danych lepiej robić razem.

Jeśli wykonawca jest z innego miasta albo z innego kraju, ustal cztery rzeczy przed podpisaniem umowy: strefę czasową i realne godziny dostępności (nie „24/7”, a np. 8:00–16:00 CET), jeden kanał na sprawy krytyczne z numerem telefonu, osobę decyzyjną po swojej stronie oraz to, kto odbiera zgłoszenia w weekend. Jak wyglądają takie zapisy w praktyce, rozkładamy w przewodniku o utrzymaniu i opiece technicznej sklepów Lublin.

Sklepy ze Świdnika i okolic często pracują z jednym deweloperem prowadzącym całość: sklep, motyw, integracje z kurierami (InPost, DPD, DHL), czasem ERP. To plus – przy zmianie API kuriera nie trzeba zgadywać, kto odpowiada za moduł.

Pierwszy miesiąc opieki krok po kroku

Dobry onboarding ma daty, nie „etapy”. Jeśli wykonawca nie potrafi powiedzieć, co zrobi w pierwszych 30 dniach, pakiet jest raczej zbiorem intencji niż usługą.

Dzień 1–3 – audyt startowy. Do arkusza trafiają: wersja platformy (PrestaShop 1.7.x/8.x albo WordPress z WooCommerce), wersja PHP i MySQL/MariaDB, lista modułów i wtyczek z numerami wersji oraz statusem (aktualny, przestarzały, porzucony – brak wydania od dwóch lat), data wygaśnięcia certyfikatów SSL i sposób odnowienia (Let’s Encrypt vs. certyfikat płatny), wpisy cron z godzinami i sprawdzenie, czy zadania się nie nakładają, oraz stan kopii zapasowych. Audyt bez dostępu do serwera nie jest audytem – to oglądanie strony w przeglądarce.

Dzień 3–7 – kopia offsite i test odtworzenia. Kopia musi leżeć u innego dostawcy niż hosting (Backblaze B2, S3, prywatny serwer), być szyfrowana i mieć retencję, np. 30 wersji dziennych i 12 miesięcznych. Ważniejszy od samej kopii jest test: odtworzenie na środowisku testowym z zapisem daty, czasu trwania i wyniku – czy zamówienie testowe przechodzi całą ścieżkę.

Tydzień 2 – staging i zasady współpracy. Subdomena testowa z noindex i hasłem, harmonogram aktualizacji (rdzeń raz w miesiącu, poprawki bezpieczeństwa w 48 h od krytycznego CVE), oddzielny kanał na zgłoszenia rutynowe i osobny na awarie, godziny reakcji oraz tabela kontaktów: kto zgłasza, kto wykonuje, kto zatwierdza wdrożenie na produkcję. Standardy zapisu SLA opisujemy szerzej w przewodniku o utrzymaniu i opiece technicznej sklepów Krasnystaw.

Tydzień 3–4 – pierwsza aktualizacja kontrolowana w kolejności: rdzeń, potem moduły, na końcu motyw. Każdy krok kończy się testem zamówienia: koszyk, płatność w trybie testowym, mail potwierdzający, status w panelu. Pułapka numer jeden: aktualizacja rdzenia bez wcześniejszego testu odtworzenia kopii. Na koniec raport startowy – lista ryzyk z priorytetem (P1/P2/P3), szacowanym czasem i wyceną, żeby klient sam zdecydował, co robimy najpierw.

Jak mierzyć, że opieka techniczna realnie działa

Opieka bez pomiaru to abonament za spokój ducha. Poniżej wskaźniki, które sprawdzisz bez wiedzy technicznej – wystarczy miesięczny raport od wykonawcy i jeden rzut oka na zewnętrzne narzędzia.

Dostępność (uptime). Mierzona zewnętrznym monitorem (UptimeRobot, Better Stack, HetrixTools), nie z wewnątrz serwera – inaczej nie wykryjesz awarii całej maszyny. Monitor co 1–5 minut z dwóch lokalizacji, alert mailem i SMS-em. Wynik zapisywany co miesiąc, nie jako zrzut ekranu z jednego dnia.

Wydajność. Mierz TTFB oraz LCP na czterech kluczowych szablonach: strona główna, kategoria, karta produktu, koszyk. Punkt odniesienia to dane z CrUX i wytyczne Core Web Vitals (LCP, INP, CLS) z web.dev. Sensowne progi do zapisania w umowie: TTFB poniżej 0,8 s dla ruchu z Polski, LCP poniżej 2,5 s na 75. percentylu. Pomiar przed wdrożeniem opieki i potem co miesiąc na tych samych szablonach.

Reakcja i aktualizacje. Raport miesięczny powinien zawierać log zgłoszeń: data i godzina przyjęcia, pierwsza odpowiedź, moment zamknięcia. Jeśli SLA mówi 4 h w dni robocze, a średnia z miesiąca wychodzi 6 h, to jest złamanie umowy, a nie „duży ruch”. Osobno: liczba wykonanych aktualizacji, liczba testów odtworzenia z backupu i średni czas odtworzenia (dla sklepu do kilku GB realny cel to poniżej 2 h).

Efekty biznesowe traktuj jako skutek uboczny, nie dowód: spadek porzuconych koszyków po przyspieszeniu sklepu, mniej zgłoszeń „nie mogę złożyć zamówienia”, mniej reklamacji płatności. Korelacja to nie przyczynowość – jeden miesiąc nic nie dowodzi. Jak wygląda to w mniejszych miejscowościach regionu, opisujemy w przewodniku o utrzymaniu i opiece technicznej sklepów Chełm. Raz w roku zrób przegląd: czy lista zadań z pakietu nadal pasuje do sklepu, który doszedł nowy kurier, nowy rynek albo integracja z ERP.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Lista zadań w abonamencie na piśmie — Poproś o nią przed podpisaniem, nie po pierwszej awarii. Powinna wymieniać aktualizacje, kopie, monitoring i drobne poprawki.
• Liczba godzin w pakiecie i stawka poza pakietem — Minimum 2 h/mc dla małego sklepu, 5–8 h/mc dla standardu MŚP. Sprawdź, czy niewykorzystane godziny przechodzą na kolejny miesiąc.
• Czas reakcji i czas naprawy – osobno — 1–2 h reakcji dla incydentu krytycznego, 8–24 h dla zwykłego zgłoszenia. Naprawa musi być zapisana odrębnie.
• Definicja incydentu krytycznego — Sprawdź, czy umowa wymienia: brak przyjmowania zamówień, błąd 500 na koszyku, niedziałające płatności, wyciek danych.
• Okno serwisowe i informowanie o pracach — Typowo 22:00–6:00. Ustal, z jakim wyprzedzeniem dostajesz informację o aktualizacji lub wdrożeniu.
• Kanał zgłoszeń i eskalacja — Jeden adres e-mail lub panel plus numer telefonu na sytuacje krytyczne. W umowie powinna być wskazana osoba decyzyjna po stronie wykonawcy.
• Konsekwencje przekroczenia SLA — Rabat na kolejny miesiąc, doliczone godziny albo prawo do wypowiedzenia. Bez tego SLA jest deklaracją, nie zobowiązaniem.
• Backup: lokalizacja, częstotliwość, retencja — Kopia offsite, minimum raz dziennie baza i pliki, retencja 30 dni. Zapytaj, gdzie fizycznie leży kopia.
• Test odtworzenia kopii — Raz na kwartał, z logiem lub krótkim protokołem. To jedyny dowód, że backup działa.
• Monitoring dostępności i kluczowych ścieżek — Nie tylko ping do strony, ale też test koszyka i płatności. Sprawdź, kto dostaje alert i o jakiej porze.
• Dostępy i własność kodu — Ustal, że masz dostęp do hostingu, repozytorium i panelu. Zapytaj, na czyim koncie stoi domena i certyfikat SSL.
• Raport miesięczny — Krótkie zestawienie: co zaktualizowano, ile godzin wykorzystano, co zaplanowano. Pierwszy raport sprawdź już po 30 dniach.
• Zakres drobnych poprawek — Ustal, co znaczy „drobna poprawka” – np. zmiana tekstu, poprawka w CSS do 30 minut. Większe zmiany to już nowe zadanie.
• Procedura wyjścia — Termin wypowiedzenia, eksport danych, przekazanie dostępów i kodu. Sprawdź to przed podpisaniem, nie przy rozstaniu.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów