Czym jest utrzymanie i opieka techniczna sklepu internetowego

Opieka techniczna to abonament na stały proces, a nie jednorazowa usługa. W praktyce oznacza powtarzalny cykl: monitoring, aktualizacje, kopie zapasowe, bezpieczeństwo, wydajność, poprawki błędów i rozwój. Jeśli oferta mówi „10 aktualizacji wtyczek na kwartał”, to nie jest opieka techniczna — to pakiet prac porządkowych. Aktualizacja bez monitoringu i bez kopii to loteria: jedna niezgodność modułu z rdzeniem i sklep nie przyjmuje zamówień, a Ty dowiadujesz się o tym od klienta.

Gdzie kończy się projekt, a zaczyna abonament. Wdrożenie ma zakres, termin i odbiór — płacisz za etapy. Utrzymanie nie ma daty końcowej — płacisz miesięcznie za gotowość i czas reakcji. Granicę warto zapisać twardo: odbiór sklepu plus 30 dni gwarancji na prace wdrożeniowe. Błędy powstałe przy wdrożeniu poprawia wykonawca w ramach gwarancji, a nie w ramach abonamentu. Bez tego zapisu po dwóch miesiącach każda poprawka staje się „nowym zleceniem” z osobną wyceną.

Trzy filary i to, co w nich mierzymy:

• Dostępność (uptime) — monitoring z zewnętrznego serwera co 1 minutę, uptime liczony miesięcznie. 99,9% oznacza dopuszczalne około 43 minuty niedostępności w miesiącu.
• Bezpieczeństwo — liczba podatności i czas reakcji na nie, blokady WAF, wyniki skanowania malware, RPO (ile danych możesz stracić) i RTO (jak szybko odtworzysz sklep z kopii).
• Wydajność — TTFB, LCP, INP, CLS, liczba zapytań SQL, rozmiar bazy i grafiki. Punkt odniesienia dla tych wskaźników opisuje dokumentacja Web Vitals.

Brak opieki nie oznacza „nic się nie dzieje”. Oznacza, że całe ryzyko przechodzi na Ciebie: awaria o 3:00 w nocy zostaje wykryta rano przez klienta, a brak kopii oznacza brak czegokolwiek do odtworzenia. Jeśli dopiero układasz zakres, zacznij od przeglądu od czego zacząć układać zakres opieki technicznej.

Co dokładnie wchodzi w opiekę techniczną — 7 obszarów

Poniższe siedem obszarów to minimum, które powinno znaleźć się w umowie. Jeśli w propozycji brakuje chociaż jednego, dopytaj — najczęściej brakuje monitoringu i testu odtworzenia kopii, bo to najbardziej „niewidzialne” punkty.

1. Monitoring dostępności i kluczowych ścieżek. Co minutę: kod HTTP (200/500) i TTFB. Raz na godzinę: przejście koszyka do checkoutu. Raz dziennie: testowa transakcja płatności na 1 zł oraz wysyłka formularza zamówienia. Alert e-mail/SMS po trzech kolejnych nieudanych próbach, żeby uniknąć fałszywych alarmów.
2. Aktualizacje rdzenia, modułów i motywu. Zasada: najpierw staging (kopia sklepu), potem test koszyka, płatności, maili transakcyjnych i faktur, dopiero na końcu produkcja. Okno wdrożenia poza szczytem sprzedaży, changelog z numerami wersji. Przy modułach sprawdzaj zgodność z wersją rdzenia — wymagania znajdziesz w dokumentacji dla deweloperów PrestaShop.
3. Kopie zapasowe. Pełna kopia (pliki i baza) minimum raz na dobę, retencja 30 dni, przechowywana poza serwerem produkcyjnym. Raz na kwartał test odtworzenia z mierzonym czasem. Kopia, której nigdy nie odtwarzałeś, nie jest kopią.
4. Bezpieczeństwo. WAF, limit prób logowania (np. 5 prób na 15 minut), 2FA do panelu administracyjnego, codzienny skan malware, certyfikat SSL z automatycznym odnowieniem i alertem 14 dni przed wygaśnięciem.
5. Wydajność. Cache pełnostronicowy, optymalizacja zapytań SQL, kompresja obrazów do WebP, CDN, kontrola Core Web Vitals.
6. Poprawki i wsparcie. Zgłoszenia typu „klient nie może złożyć zamówienia”, błędy koszyka, płatności, maili transakcyjnych. To najczęstszy realny powód, dla którego firmy podpisują umowę.
7. Rozwój. Nowe moduły, integracje z ERP, kurierami i płatnościami — rozliczane osobno, poza abonamentem, ale realizowane z priorytetem wynikającym z SLA.

Porównując oferty, pytaj o każdy punkt osobno i żądaj zapisu w umowie. Ustne „oczywiście, że monitorujemy” nie jest zobowiązaniem.

SLA w praktyce: czasy reakcji i naprawy dla sklepu w Lublinie

Poniższe wartości traktuj jako punkt startowy do negocjacji. Ważne, żeby w umowie były liczby, a nie słowa „szybko” i „natychmiast”.

Okno wsparcia. Standard to godziny robocze pn–pt 8:00–17:00. Wsparcie 24/7 kosztuje zwykle 1,5–2,5 raza więcej niż abonament w trybie roboczym — warto rozważyć wariant pośredni: pełne wsparcie w godzinach roboczych plus dyżur wyłącznie dla zgłoszeń P1 w weekendy. Zapis, na który trzeba uważać: „reakcja liczona od przyjęcia zgłoszenia w oknie wsparcia”. Przy takim brzmieniu zgłoszenie z piątku 16:40 wchodzi w bieg dopiero w poniedziałek 8:00. Jeśli sprzedajesz w weekend, to zły zapis.

Kanały zgłoszeń. Umowa powinna gwarantować co najmniej jeden kanał z automatycznym potwierdzeniem i numerem zgłoszenia — najlepiej e-mail lub panel ticketowy, bo zostaje historia i da się zmierzyć czas reakcji. Telefon dyżurny bywa wyłącznie dobrą wolą wykonawcy i trudno go udowodnić.

Eskalacja i raportowanie. Ustal dwa poziomy: osoba techniczna, potem kierownik projektu. Przy P1 brak reakcji w 30 minut oznacza telefon do właściciela po stronie wykonawcy. Raz w miesiącu odbieraj raport: uptime, liczba zgłoszeń w podziale na priorytety, średni i maksymalny czas reakcji, przekroczenia SLA, wykonane aktualizacje, data i wynik ostatniego testu odtworzenia kopii. Bez tego raportu nie zweryfikujesz żadnej kary.

Kara umowna, która jest wykonalna. Musi opierać się na mierzalnym źródle. Zdefiniuj niedostępność: minimum trzy kolejne nieudane próby monitoringu, z dwóch lokalizacji. Przykład zapisu: 5% miesięcznego abonamentu za każde rozpoczęte 60 minut przekroczenia przy P1, maksymalnie 50% abonamentu. Wyłączenia: planowane prace z powiadomieniem 48 godzin wcześniej. Kwota ryczałtowa bez definicji pomiaru jest w praktyce nie do wyegzekwowania.

Zobacz też, jak formułujemy zapisy SLA w umowie na opiekę techniczną.

Opieka reaktywna, proaktywna i rozwojowa — którą wybrać

Trzy modele różnią się nie narzędziami, a sposobem rozliczenia i tym, kto pierwszy zauważa problem. Wybór zależy od liczby zamówień i od tego, ile realnie kosztuje Cię godzina przestoju.

Model reaktywny (pakiet godzinowy) — dla sklepów do ok. 50 zamówień/mies. Kupujesz np. 5 godzin miesięcznie i płacisz tylko za faktycznie wykorzystane. Monitoringu nie ma: problem zgłaszasz sam, po tym jak go zauważysz. Próg wejścia jest niski, ale każdą awarię wykrywa klient, nie wykonawca.

Model proaktywny (abonament z monitoringiem) — dla sklepów 100+ zamówień/mies. i B2B z umowami na dostawy. Stały budżet godzin (typowo 10–20 h) plus monitoring dostępności, kopie zapasowe, aktualizacje w oknie serwisowym i miesięczny raport. Nadwyżkę ponad budżet rozliczasz stawką godzinową. Taki układ ma sens, gdy niedziałająca płatność w piątek po 16:00 oznacza utracone zamówienia z całego weekendu. Jak zapisać to w umowie, opisuje tekst o SLA i pakietach dla sklepów w Narolu.

Model rozwojowy — dedykowany zespół i roadmapa. Dla sklepów z integracjami ERP oraz logiką B2B: ceny indywidualne, limity kredytowe, indywidualne cenniki per klient. Praca w sprintach, backlog, wycena indywidualna.

Trzy pytania, które rozstrzygają wybór:

• Jaki jest koszt godziny przestoju? Jeśli w szczycie liczysz go w tysiącach złotych, model reaktywny nie wystarczy.
• Jak często wdrażasz zmiany? Kilka drobnych zmian w miesiącu — pakiet godzinowy. Ciągły rozwój — model rozwojowy.
• Czy masz sezonowość? Jeśli tak, budżet godzin musi być przesuwalny na szczyt sprzedaży.

Pułapka: pakiet godzinowy bez przenoszenia niewykorzystanych godzin. Płacisz za 5 h, wykorzystujesz 2, reszta przepada — a w listopadzie potrzebujesz 12. Negocjuj przenoszenie do 3 miesięcy albo rozliczenie kumulacyjne w skali roku.

Ile kosztuje utrzymanie sklepu internetowego w Lublinie — widełki i co wpływa na cenę

W regionie lubelskim stawka za pracę deweloperską przy utrzymaniu sklepu to zwykle 120–220 zł/h netto. Dolna granica to proste zmiany treści i konfiguracji, górna — integracje, wydajność i migracje.

Pakiety miesięczne: mały sklep ze standardowym motywem to ok. 800–1200 zł/mies., co odpowiada 5–8 godzinom pracy. Sklep średni z integracjami (magazyn, kurierzy, płatności, ERP) to 2000–4500 zł/mies., czyli 15–25 godzin.

Co podnosi cenę:

• Liczba integracji. Każde połączenie z ERP, WMS czy API kuriera to osobny punkt awarii. Gdy dostawca zmienia API bez ostrzeżenia, integrację trzeba przepisać — tego nie da się zaplanować w budżecie.
• Niestandardowy motyw pisany od zera — trudniejszy w aktualizacji niż szablon z rynku.
• Ruch powyżej 100 tys. odsłon/mies. — dochodzi cache, CDN i optymalizacja zapytań do bazy.
• Wymóg 24/7 — dyżury poza oknem wsparcia to dodatkowa pozycja w umowie.

Co obniża cenę: standardowy PrestaShop lub WooCommerce na sprawdzonym hostingu, brak modyfikacji rdzenia, aktualny stos wtyczek i modułów, działający staging.

Dlaczego rozliczenie godzinowe jest zdrowsze niż stała kwota „za wszystko”: nieograniczony zakres to ryzyko po obu stronach. Wykonawca musi wliczyć w cenę bufor na prace nieprzewidziane, więc płacisz z góry za problem, który może nie wystąpić. Budżet godzinowy z ustaloną stawką za nadwyżkę daje przewidywalność i pokazuje realny koszt pracy. Od czego zacząć porządkowanie tego po stronie umowy, opisuje tekst o utrzymaniu i opiece technicznej sklepów w Chełmie.

Porównując oferty, pytaj zawsze o cztery rzeczy: stawkę godzinową za prace poza abonamentem; minimalny pakiet i sposób rozliczenia nadwyżki; zakres czynności poza abonamentem (nowe funkcje, migracje, wdrożenia); czy aktualizacje rdzenia i wtyczek są w cenie, czy fakturowane osobno.

PrestaShop, WooCommerce, WordPress — co zmienia się w opiece technicznej

Opieka nad sklepem na WordPressie z WooCommerce i nad PrestaShopem to dwie różne listy ryzyk. Wykonawca, który zna tylko jedną platformę, w drugiej będzie improwizował — na Twoim środowisku produkcyjnym.

WooCommerce. Realne ryzyka: konflikty wtyczek przy aktualizacjach (przy 20–40 aktywnych wtyczkach konflikt zwykle wychodzi dopiero po aktualizacji i dotyczy koszyka), zależność od wersji PHP — na PHP 8.x stara, nieutrzymywana wtyczka potrafi rzucić fatal error, oraz rozrost tabeli wp_postmeta. Przy katalogu kilku tysięcy produktów i wtyczkach zapisujących dane do postmeta baza dobija do milionów wierszy, a filtrowanie i wyszukiwanie zwalniają z każdym miesiącem.

PrestaShop. Moduły nadpisujące rdzeń (katalog /override/) utrudniają aktualizacje i diagnostykę. Migracja z 1.6 do 8.x to najczęściej przepisanie motywu i części modułów. Osobny temat to wydajność przy dużej liczbie kombinacji produktów — tysiące wariantów atrybutów obciążają generowanie list i kart produktu.

Wspólne zasady. Kolejność aktualizacji: PHP → rdzeń → moduły/wtyczki → motyw. Nigdy na produkcji bez stagingu. Po każdej zmianie test koszyka: dodanie produktu, kod rabatowy, wybór kuriera, płatność, mail potwierdzający. Zakres zmian w kolejnych wersjach śledź na bieżąco w dokumentacji dla deweloperów PrestaShop.

Kiedy pisać własny moduł. Kryterium to prosty rachunek: roczny koszt licencji wtyczki plus koszt jej utrzymania kontra koszt napisania modułu. Wtyczka za 300 zł/rok, która przy dwóch aktualizacjach w roku psuje checkout i zajmuje 2 h pracy, kosztuje realnie więcej niż jej licencja.

Hosting. Administracja serwerem lub VPS zwykle nie jest w pakiecie. Pytaj wprost: czy w cenie jest dostęp SSH, konfiguracja PHP-FPM, tuning MySQL, backupy poza serwerem, SSL i monitoring. Jeśli nie — to osobna pozycja w budżecie.

Jak policzyć koszt awarii sklepu i uzasadnić opiekę techniczną

Kalkulację oprzyj na trzech liczbach z panelu administracyjnego: liczba zamówień na dobę, średnia wartość koszyka i marża. Wzór: koszt przestoju = (zamówienia na godzinę × średnia wartość koszyka × marża) × godziny przestoju. Godzinę rozliczeniową licz z całej doby, nie z 8-godzinnego dnia pracy — klienci zamawiają też wieczorem.

Przykład ze sklepu w Lublinie sprzedającego części do warsztatów: 30 zamówień na dobę, koszyk 180 zł, marża 45%, czyli ok. 1,25 zamówienia na godzinę. Awaria 5xx w poniedziałek od 9:00 do 15:00 (6 godzin) to ~1400 zł utraconego przychodu i ok. 650 zł marży. Do tego obsługa po awarii: telefony od klientów, którzy zapłacili i nie dostali potwierdzenia, zwroty, korekty faktur.

Koszty, których nie widać w panelu:

• długotrwałe 5xx mogą skłonić Google do rzadszego crawlowania i wypadania adresów z indeksu — odbudowa widoczności trwa tygodnie;
• porzucone koszyki: klient, który trafił na błąd płatności, rzadko wraca tego samego dnia;
• B2B: niezrealizowana faktura w terminie to wstrzymana płatność i drugi dostawca w kolejce;
• 12 roboczogodzin wyjętych z pracy, gdy 6 h awarii obsługuje dwóch ludzi.

Punkt odniesienia dla wspólnika: koszt miesięcznej opieki porównaj nie z zerem, a z jednorazowym odtworzeniem sklepu z kopii — zwykle 4–8 roboczogodzin plus przerwa w sprzedaży. Zanim porównasz oferty, sprawdź, co wchodzi w SLA i pakiety opieki technicznej — bez tego stawki nie są porównywalne.

Kiedy opieka się nie opłaca: sklep w fazie testów, bez ruchu i zamówień. Wtedy abonament to koszt bez pokrycia — lepszy jest pakiet godzinowy na żądanie, np. 5 godzin miesięcznie rozliczanych w 15-minutowych blokach.

Lista kontrolna: jak wybrać wykonawcę opieki technicznej w Lublinie

Na pierwszym spotkaniu zadaj cztery pytania i zapisz odpowiedzi dosłownie: kto fizycznie pracuje na sklepie, jakie są czasy reakcji i naprawy dla każdego priorytetu, co jest poza umową oraz jak wygląda raportowanie. Odpowiedź „zazwyczaj szybko” oznacza brak SLA — nie ma czego egzekwować, gdy sklep padnie w piątek o 16:40.

Weryfikacja wykonawcy: ustal, czy firma pracuje bezpośrednio z deweloperem, czy przekazuje zlecenia dalej. Podwykonawstwo nie jest zabronione, ale musi być ujawnione w umowie — jeśli zgłoszenie przechodzi przez trzy ręce, zadeklarowane 30 minut reakcji jest nierealne. Poproś o kontakt do osoby technicznej i sprawdź, czy czyta dokumentację projektu, np. dokumentację deweloperską PrestaShop, czy działa metodą prób i błędów na produkcji.

Zapisy umowne, o które warto walczyć:

• dostęp do serwera, DNS, panelu płatności i Google Search Console pozostaje po Twojej stronie;
• eksport pełnej kopii (pliki + baza) na żądanie, w maksymalnie 24 h;
• okres wypowiedzenia 1–3 miesiące i zapis o zwrocie dostępów oraz przekazaniu dokumentacji;
• stawka za prace poza pakietem, żeby nie było „wyceny do uzgodnienia”.

Lokalność: wykonawca z Lublina lub Zamościa skraca czas przy problemach wymagających dojazdu i rozmowy na miejscu, ale nie zastępuje SLA. 60 km nie pomoże, jeśli nikt nie odbiera telefonu po godzinach. Sprawdź, jak wygląda utrzymanie i opieka techniczna sklepów Chełm — porównanie dwóch ofert z regionu pokazuje, które zapisy są standardem, a które wyjątkiem.

Pierwsze 30 dni opieki — plan wdrożenia krok po kroku

Tydzień 1 — audyt i dostępy. Sprawdzenie wersji PHP i silnika (PrestaShop, WooCommerce), listy modułów i wtyczek z datami ostatnich aktualizacji, ważności SSL, czasu TTFB i pełnego ładowania. Inwentaryzacja integracji: płatności, kurierzy, ERP, feedy do porównywarek. Dostępy trafiają do menedżera haseł, nie do maila.

Tydzień 2 — monitoring i kopie. Uptime sprawdzany co minutę z dwóch lokalizacji, alert na 5xx, alert na certyfikat 14 dni przed wygaśnięciem i alert na brak zamówień przez 6 godzin w oknie handlowym. Kopie: baza codziennie, pełny backup co tydzień, retencja 30 dni, kopia poza serwerem. Test odtworzenia na stagingu z mierzonym czasem — to liczba, którą wpisuje się do umowy.

Tydzień 3 — aktualizacje i bezpieczeństwo. Aktualizacje przechodzą ścieżką staging → produkcja w oknie serwisowym, nigdy w poniedziałek rano. Efektem jest lista zaległości technicznych z priorytetami i szacunkiem godzinowym (realnie 10–20 pozycji, 15–30 h pracy), którą wspólnie układasz na kwartał.

Tydzień 4 — raport startowy i kanał zgłoszeń. Dostajesz uptime za okres, czasy ładowania, listę ryzyk i plan na kwartał. Ustalasz jeden kanał zgłoszeń zwykłych i telefon do P1 — bez dwóch równoległych maili i Messengera.

Co miesiąc raportuj: uptime, liczbę zgłoszeń i średni czas reakcji, liczbę wdrożonych zmian oraz trend Core Web Vitals (LCP, INP, CLS) mierzony według wytycznych Web Vitals. Jeśli wdrażasz kolejne sklepy w regionie, ten sam schemat sprawdza się przy utrzymaniu i opiece technicznej sklepów w Biłgoraju oraz mniejszych instalacjach, np. opieka techniczna sklepów Frampol.

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

Lista kontrolna do odklikania

• Tabela priorytetów P1–P4 — Sprawdź, czy każdy priorytet ma czas reakcji, czas naprawy i przykłady zdarzeń. Wzorzec zapisów znajdziesz w artykule o SLA dla sklepów Hrubieszów: https://dropdigital.pl/utrzymanie-i-opieka-techniczna-sklepow-hrubieszow
• Okno wsparcia i dopłata za dyżur — Ustal, czy pn–pt 8:00–17:00 wystarcza, czy potrzebujesz weekendów, i jaka stawka obowiązuje za zgłoszenie poza oknem.
• Kanały zgłoszeń — W umowie musi być wskazany co najmniej jeden kanał gwarantowany (e-mail lub panel ticketowy) i czas, po którym zgłoszenie uznaje się za przyjęte.
• Osoby po stronie wykonawcy — Zapytaj, kto konkretnie obsługuje sklep i kto go zastępuje w czasie urlopu. Brak wskazanego zastępstwa to ryzyko przeniesione na Ciebie.
• Ścieżka eskalacji — Ustal, do kogo trafia zgłoszenie P1, gdy minie czas reakcji, i jak się z tą osobą kontaktujesz. Numer telefonu wpisz do umowy, nie do stopki maila.
• Raport miesięczny — Wymień w umowie, co ma zawierać: uptime, liczbę zgłoszeń wg priorytetu, średni i najdłuższy czas reakcji, wykonane aktualizacje, wynik testu kopii.
• Kara umowna lub rabat za niedotrzymanie SLA — Powiąż ją z miernikiem, np. rabat 5% abonamentu za każde przekroczenie czasu naprawy P1, z miesięcznym limitem.
• Limit godzin i stawka rozwojowa — Sprawdź, ile godzin wchodzi w abonament i jaka stawka obowiązuje za nadwyżkę. Stawka powinna być w umowie, a nie w cenniku na stronie, który może się zmienić.
• Kopie zapasowe — Potwierdź na piśmie częstotliwość (minimum raz dziennie), retencję (30 dni) oraz to, że odtworzenie kopii jest testowane raz na kwartał.
• Staging i zasada wdrożeń — Zapytaj, czy aktualizacje idą najpierw na kopię testową. Jeśli nie, każda aktualizacja jest wykonywana bezpośrednio na działającym sklepie.
• Zakres wyłączony z abonamentu — Ustal wprost, czego umowa nie obejmuje: migracji, prac graficznych, zmian treści, integracji z nowym ERP. Tam najczęściej pojawiają się dopłaty.
• Dostępy i 2FA — Ustal, kto ma hasła, czy do panelu włączone jest uwierzytelnianie dwuskładnikowe i w jakiej formie dostaniesz komplet dostępów przy rozstaniu.
• Wypowiedzenie i przekazanie — Zapisz długość okresu wypowiedzenia (np. 1 miesiąc) oraz termin przekazania dokumentacji, repozytorium i dostępów — najlepiej 14 dni.

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