Czym naprawdę jest utrzymanie i opieka techniczna sklepu

W praktyce te dwa słowa opisują dwie różne prace. Utrzymanie to reakcja: sklep przestał działać, płatności zwracają błąd, koszyk nie zapisuje zamówień — ktoś wchodzi i naprawia. Opieka to zapobieganie: praca wykonywana wtedy, gdy wszystko działa, po to żeby awaria albo się nie zdarzyła, albo trwała 20 minut, a nie dwa dni. Umowa, w której widzisz wyłącznie słowo „utrzymanie”, zwykle oznacza, że dostawca czeka na Twoje zgłoszenie. Umowa na opiekę oznacza, że ktoś czyta logi, zanim napiszesz „nie działa”.

Prosty test na pierwszej rozmowie: zapytaj, co dostawca zrobi w środę, jeśli przez cały tydzień nie wyślesz żadnego zgłoszenia. Odpowiedź „będę czekał” to utrzymanie. Odpowiedź z listą czynności — kopie zapasowe, aktualizacje na środowisku testowym, przegląd logów, raport — to opieka.

Kto za co odpowiada — najczęstsze punkty sporne:

8 obszarów opieki technicznej – co musi być w umowie

Poniższe osiem punktów to lista kontrolna. Przechodzisz przez nią przy każdej ofercie i przy każdym punkcie zaznaczasz: jest / nie ma / nie wiem. Pozycje „nie wiem” to miejsca, w których zapłacisz podwójnie.

1. Kopie zapasowe. Minimum raz dziennie, retencja min. 14 dni, kopia off-site, czyli poza serwerem produkcyjnym. Raz na kwartał test odtwarzania na stagingu, z datą i wynikiem w raporcie. Backup trzymany na tym samym koncie hostingowym to nie backup.
2. Monitoring. Uptime sprawdzany co minutę, alert przy braku odpowiedzi, czas odpowiedzi PHP, błędy 500/502, kolejka mailowa i skrzynka kontaktowa. Bez tego o awarii dowiesz się od klienta.
3. Aktualizacje. Rdzeń, moduły/wtyczki i szablon — zawsze najpierw na staging, potem na produkcję, po sprawdzeniu koszyka, płatności i maili. Zmiany w rdzeniu i szablonie muszą być udokumentowane, inaczej znikną przy kolejnej aktualizacji. W PrestaShop strukturę rdzenia, modułów i szablonu opisuje dokumentacja dla deweloperów PrestaShop.
4. Bezpieczeństwo. WAF i firewall aplikacyjny, skanowanie malware, wymuszone 2FA dla wszystkich kont administracyjnych, limit nieudanych logowań. Konto „admin” z hasłem z 2019 roku to nie zabezpieczenie.
5. Wydajność. Audyt Core Web Vitals raz na kwartał (progi i definicje metryk opisuje web.dev), optymalizacja wolnych zapytań SQL, cache strony i cache obiektowy, obrazy WebP/AVIF.
6. Poprawki i drobne wdrożenia. Zdefiniuj „drobną zmianę” godzinowo — np. do 2 h w pakiecie miesięcznym. Bez tej definicji każda poprawka staje się osobną wyceną. Punkt odniesienia dla stawek znajdziesz w naszym cenniku utrzymania i opieki technicznej sklepów.
7. Wsparcie użytkownika. Jeden kanał: mail, ticket albo telefon. Godziny pracy, czas reakcji zależny od priorytetu, kontakt do konkretnej osoby lub zespołu.
8. Raporty. Miesięczny raport: wykonane prace, czas ich trwania, incydenty z czasem reakcji i naprawy, rekomendacje na kolejny miesiąc. Bez raportu nie sprawdzisz, czy abonament w ogóle działa.

Jeśli obsługujesz firmę z kilkoma sklepami albo kilkoma językami, zakres trzeba rozbić na osobne pozycje — utrzymanie i opieka techniczna sklepów w Zwierzyńcu pokazuje, jak wygląda takie rozbicie zakresu.

SLA – co musi zawierać umowa, żeby była coś warta

Oferta bez SLA jest warta tyle, co ustna obietnica. SLA to nie „24/7” na papierze, tylko tabela: co się stało, jak szybko ktoś reaguje i co się dzieje, jeśli nie zdąży. Poniżej przykład, który warto porównać 1:1 z tym, co dostałeś.

Trzy różne czasy. Czas reakcji to moment, w którym człowiek odezwie się na zgłoszenie. Czas rozpoczęcia pracy to chwila, gdy ktoś realnie zaczyna diagnozę. Czas rozwiązania to przywrócenie działania sklepu. W ofertach najczęściej pada tylko pierwszy — najkrótszy i najłatwiejszy do dotrzymania. W umowie muszą być wszystkie trzy, osobno dla każdego priorytetu i z jasnym zapisem, czy liczą się w godzinach zegarowych, czy roboczych.

Jak to się mierzy. Ustal, że każde zgłoszenie trafia do jednego systemu (ticket albo mail z automatycznym numerem), a czas liczysz od potwierdzenia przyjęcia zgłoszenia. Punkt końcowy definiujesz testem, np. „koszyk zapisuje zamówienie, a płatność kończy się sukcesem”. Bez tego nie policzysz kary, bo dostawca powie, że „naprawił”, a Ty nadal nie sprzedajesz.

Kary, okna serwisowe i weekendy. Typowy mechanizm: potrącenie kilku procent miesięcznego abonamentu za każde rozpoczęte 60 minut przekroczenia P1, z limitem np. 50% opłaty. Zapytaj, czy to potrącenie, czy osobna płatność, i czy kary nie zjadają pakietu godzin. Ustal okno serwisowe, np. 8:00–16:00 w dni robocze, i to, co dzieje się poza nim: dyżur dla P1 (w pakiecie albo za dopłatą) czy brak wsparcia. Weekend bez zapisu w umowie oznacza, że możesz czekać do poniedziałku — i to jest zgodne z umową. Zanim porównasz poziomy kar, sprawdź, ile kosztuje utrzymanie i opieka techniczna sklepów w praktyce.

Ile kosztuje utrzymanie sklepu – konkretne widełki

Pytanie „ile kosztuje utrzymanie sklepu” bez danych wejściowych nie ma odpowiedzi. Do wyceny potrzebne są trzy liczby: liczba SKU, liczba integracji zewnętrznych i liczba modułów lub wtyczek pracujących na produkcji. Realne widełki dla polskiego rynku wyglądają tak:

Metodologia jest prosta i powinna być zapisana w umowie: stawka godzinowa × założony budżet godzin. Stawki w Polsce to zwykle 120–220 zł/h netto. 6 h przy 150 zł/h daje 900 zł/mc. Nadwyżki rozliczasz osobno — tą samą stawką albo niższą pakietową (150–250 zł/h). Umowa musi też rozstrzygać, co dzieje się z niewykorzystanymi godzinami: przechodzą na kolejny miesiąc, przepadają, czy są rozliczane kwartalnie.

Cena zależy przede wszystkim od liczby punktów styku z systemami zewnętrznymi, nie od „wielkości” sklepu. InPost, DPD, DHL, ERP (Subiekt, Comarch Optima), bramki płatnicze, feedy Ceneo i Google Shopping, fakturowanie — każdy element psuje się niezależnie od pozostałych. Sklep z 200 SKU i sześcioma integracjami bywa droższy w utrzymaniu niż sklep z 3000 SKU i dwiema.

W standardowy pakiet zwykle nie wchodzą: nowe funkcje (moduł B2B, konfigurator produktu), migracje wersji platformy, kampanie marketingowe i SEO, nowy szablon, przeniesienie na inny hosting. To osobne projekty z osobną wyceną — jeśli dostawca tego nie rozdziela, prawdopodobnie dolicza te prace w abonamencie.

Ukryte koszty poza abonamentem: licencje płatnych wtyczek (300–1500 zł/rok za sztukę), certyfikat SSL (0 zł dla Let's Encrypt, do ok. 300 zł/rok za wildcard), CDN (20–100 zł/mc), backup poza serwerem (30–100 zł/mc), serwer z zapasem mocy (100–400 zł/mc). Poproś o pełną listę tych pozycji i porównaj ją z naszym cennikiem utrzymania i opieki technicznej sklepów.

PrestaShop vs WooCommerce – różnice w realnym nakładzie utrzymania

Platforma nie decyduje o tym, czy utrzymanie będzie tanie, ale zmienia profil ryzyka i liczbę godzin. Zestawienie poniżej opieramy na własnej praktyce, nie na deklaracjach producentów.

PrestaShop to architektura monolityczna: rdzeń, motyw i moduły działają w jednej aplikacji PHP na jednym serwerze. Mniej ruchomych części oznacza mniej codziennych konfliktów, ale aktualizacje idą skokowo. Przejście z 1.7 na 8.x to projekt, nie kliknięcie przycisku: trzeba sprawdzić zgodność modułów i motywu, przetestować koszyk, płatności i wysyłki na kopii, przygotować plan wycofania i dopiero potem wdrażać. Moduł 1-Click Upgrade tego nie zastąpi. Zakres zmian między wersjami najlepiej weryfikować w dokumentacji dla deweloperów PrestaShop, a nie na forach, gdzie informacje bywają nieaktualne.

WooCommerce to WordPress plus WooCommerce plus motyw plus wtyczki. Szybkie wdrożenie na starcie nie oznacza kompatybilności w ekosystemie: każda aktualizacja wtyczki może wejść w konflikt z inną, a winowajcę znajduje się metodą kolejnych wyłączeń na kopii. Praktyczny współczynnik: sklep z 20+ aktywnymi wtyczkami generuje zwykle dwa–trzy razy więcej godzin na aktualizacje i testy niż ten sam sklep z ośmioma.

Typowy wspólny incydent to porzucona płatna wtyczka lub moduł. Autor przestaje go rozwijać, wtyczka wywala błędy na PHP 8.2, a Ty masz dwie drogi: znaleźć zamiennik i przepisać konfigurację oraz dane albo zlecić moduł pisany na miarę. Koszt: od kilkuset złotych do kilku tysięcy. Dlatego przy wyborze rozszerzeń patrz na datę ostatniej aktualizacji i liczbę otwartych zgłoszeń, nie na liczbę pobrań. Porządek w tej liście to połowa sukcesu w utrzymaniu i opiece technicznej sklepów.

Kiedy potrzebujesz opieki technicznej – 7 sygnałów ostrzegawczych

Nie każde „sklep chodzi wolniej” oznacza, że musisz kupić abonament. Poniższe siedem sygnałów sprawdzisz samodzielnie w kilkanaście minut, bez dostępu do kodu.

• Sklep zwalnia w godzinach szczytu. Nie losowo, ale regularnie między 12:00 a 15:00 albo w poniedziałki. To zwykle brak cache na katalogu, wyczerpane workery PHP-FPM albo wolne zapytania SQL. Sprawdź TTFB w Search Console i wykres CPU w panelu hostingu, zanim uznasz to za urok platformy.
• Rosnący wskaźnik odrzuceń. Zestaw w GA4 raport zaangażowania z tym samym okresem rok wcześniej. Jeśli treść i cennik się nie zmieniły, a odrzucenia rosną, porównaj dane z Core Web Vitals i raportem Core Web Vitals w Search Console — najczęściej problem jest w LCP na stronie produktu lub kategorii.
• Błędy 502 i 504 w logach. Wejdź w log błędów nginx lub Apache i policz wystąpienia: grep -c " 50[24] " access.log. Regularne 504 to przekroczony timeout PHP-FPM, nie „chwilowy problem u dostawcy”.
• Spadek konwersji o więcej niż 10% bez zmiany cennika i kampanii. Zanim zaczniesz szukać winy w reklamach, sprawdź bramki płatnicze, e-maile transakcyjne, koszt dostawy i stany magazynowe.
• Nie umiesz odpowiedzieć, kiedy ostatnio testowano odtworzenie backupu. Backup, którego nie odtworzyłeś na środowisku testowym, nie jest backupem. Minimum: raz na kwartał przywrócenie kopii i sprawdzenie, czy zgadzają się zamówienia i konta klientów.
• Płatna wtyczka z ostatnią aktualizacją ponad 12 miesięcy temu. Sprawdź changelog i repozytorium autora. Brak aktualizacji przy PHP 8.x kończy się błędami w koszyku lub panelu.
• Brak dziennika zmian. Nikt nie potrafi powiedzieć, kto i kiedy zmienił coś na produkcji. Wystarczy arkusz z datą, autorem i opisem zmiany albo commit w repozytorium.

Trzy lub więcej punktów na tej liście to sygnał, że potrzebujesz uporządkowanej opieki. Ile to kosztuje w praktyce, rozpisaliśmy przy okazji utrzymania i opieki technicznej sklepów Zamość – ile to kosztuje.

7 pułapek w umowach o utrzymanie sklepów

Katalog pułapek jest krótki, ale każda z nich kosztuje albo pieniądze, albo tygodnie przestoju. Poniżej siedem zapisów, które warto wynegocjować, zanim podpiszesz cokolwiek.

1. Vendor lock-in, czyli brak dostępu do kodu. W PrestaShop moduły leżą w katalogu /modules, a modyfikacje wyglądu w /themes/nazwa_motywu. Jeśli dostawca pisze własne moduły i nie przekazuje repozytorium, po zakończeniu umowy zostajesz z kodem, którego nikt nie zaktualizuje. Strukturę modułów i nadpisań opisuje oficjalna dokumentacja dla deweloperów, ale dokumentacja nie zastąpi dostępu do źródeł. Wpisz w umowę: repozytorium Git z historią commitów, kod modułów i motywu jest Twoją własnością, licencje płatnych modułów przepisane na Twoją firmę.
2. Godziny „w pakiecie”, które przepadają. Model use-it-or-lose-it wygląda tak: 20 godzin miesięcznie, w lutym nic nie zleciłeś i 20 godzin znika. Negocjuj przenoszenie niewykorzystanych godzin (minimum 3 miesiące) albo czyste rozliczenie godzinowe.
3. Brak środowiska staging. Wdrożenia bezpośrednio na produkcji to standard w najtańszych ofertach. Wymagaj kopii sklepu na subdomenie, z osobną bazą i wyłączonymi płatnościami, oraz wdrożeń przez Git z możliwością cofnięcia zmiany.
4. SLA liczone w dniach roboczych. „Reakcja do 2 dni roboczych” oznacza, że sklep padnięty w piątek o 19:00 stoi do poniedziałku. Zdefiniuj P1 (brak możliwości złożenia zamówienia) z reakcją w godzinach i kanałem telefonicznym.
5. Aktualizacje „na życzenie klienta”. To nie opieka, to utrzymanie reaktywne. Zamiast tego harmonogram: przegląd miesięczny i poprawki bezpieczeństwa wdrażane do 14 dni od wydania.
6. Brak procedury wyjścia. Zapisz, że przy zakończeniu współpracy dostajesz kopię bazy i plików, listę licencji i dostawców, a dostępy są wygaszane w ustalonym terminie. Przyjmij 30 dni okresu przejściowego.
7. Ukryte koszty. Najazdy godzinowe poza pakietem i opłaty za „ekspertyzę” spoza zakresu. Żądaj cennika jednostkowego: stawka za godzinę, minimalny blok rozliczeniowy i limit godzin bez Twojej pisemnej zgody. Punkt odniesienia do negocjacji stawki znajdziesz w materiałach o tym, ile kosztuje utrzymanie i opieka techniczna sklepów.

Checklista wyboru dostawcy opieki – 12 pytań przed podpisaniem umowy

Te pytania zadaj na jednym spotkaniu i poproś o odpowiedzi na piśmie — w ofercie lub e-mailem. Odpowiedź „to zależy” bez liczb jest sygnałem ostrzegawczym.

1. SLA: jakie macie poziomy P1, P2, P3 i jakie czasy reakcji oraz naprawy — w godzinach, nie w dniach roboczych?
2. Dyżur: czy awarie w weekendy i święta obsługuje realna osoba, czy automat odpowiada e-mailem? Poproś o numer dyżurny i harmonogram.
3. Backup: jak często kopiujecie bazę (co ile godzin) i pliki (codziennie)? Gdzie leżą kopie, jaka jest retencja i kiedy ostatnio testowaliście odtworzenie?
4. Bezpieczeństwo: kto i w jakim terminie wdraża poprawki bezpieczeństwa — 7 czy 14 dni od wydania?
5. Kod: czy dostanę dostęp do repozytorium Git i czy moduły, które piszecie, będą moją własnością?
6. Środowisko: czy pracujecie na stagingu i kto zatwierdza wdrożenie na produkcję?
7. Proces zmiany: opiszcie ścieżkę zgłoszenie → test → staging → produkcja → rollback. Ile trwa powrót do poprzedniej wersji?
8. Raportowanie: co dokładnie dostaję co miesiąc? Poproś o przykładowy raport sprzed dwóch miesięcy, nie o opis szablonu.
9. Wydajność: czy monitorujecie Core Web Vitals i parametry serwera (czas odpowiedzi bazy, użycie CPU)? Metryki LCP, INP i CLS są opisane w dokumentacji web.dev i przekładają się na to, jak sklep wypada w wynikach wyszukiwania.
10. Doświadczenie: ile sklepów macie w utrzymaniu i na jakich platformach — PrestaShop, WooCommerce, inne?
11. Referencje: trzy kontakty do klientów, których sklepy prowadzicie dłużej niż rok. Zadzwoń do nich.
12. Eskalacja: do kogo trafia zgłoszenie, gdy nie ma postępu, i kto po stronie dostawcy podejmuje decyzje?

Jeśli chcesz porównać te odpowiedzi z konkretnym zakresem prac, zobacz, co obejmuje utrzymanie i opieka techniczna sklepów dla firm.

Podsumowanie: jak wybrać opiekę, która nie generuje problemów

Decyzja sprowadza się do trzech elementów: jasne SLA z czasami reakcji w godzinach, rozliczenie godzinowe z przenoszeniem niewykorzystanych godzin oraz zapis o dostępie do kodu i repozytorium po zakończeniu współpracy. Dostawca, który nie chce pokazać przykładowego raportu ani podać trzech referencji, zwykle nie ma procesu — ma tylko dobre chęci. Zestaw ofertę z tabelą poniżej i sprawdź, czy odpowiada na wszystkie punkty z checklisty.

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

Lista kontrolna do odklikania

• Kto robi backup i gdzie leży — Sprawdź częstotliwość (min. 1x dziennie), retencję (min. 14 dni) i czy kopia leży poza serwerem produkcyjnym. Poproś o datę ostatniego testu odtworzenia.
• Czy jest środowisko staging — Zapytaj, czy aktualizacje wtyczek i modułów idą najpierw na kopię testową. Brak stagingu oznacza, że każda aktualizacja jest testowana na klientach.
• Monitoring – co i jak często — Uptime co minutę, błędy 500/502, czas odpowiedzi PHP, monitorowanie logów i skrzynki mailowej. Poproś o przykład alertu i wskazanie, kto go odbiera.
• Kanały zgłoszeń i godziny pracy — Ustal, gdzie logujesz zgłoszenia (mail, ticket, telefon), co dzieje się po 16:00 i w weekendy oraz czy dyżur jest w pakiecie, czy płatny osobno.
• Tabela priorytetów i czasy reakcji — P1 30–60 min, P2 2h, P3 do 2 dni roboczych, P4 planowane. Sprawdź, od jakiego zdarzenia liczy się czas – od zgłoszenia w systemie, nie od telefonu.
• Definicja drobnej zmiany — Ile godzin w miesiącu jest wliczone (typowo 1–2h na jedno zgłoszenie) i co dzieje się z nadwyżką – stawka godzinowa czy blokada kolejnych prac.
• Kary umowne i sposób pomiaru — Ustal, kto loguje czas reakcji, w jakim narzędziu i na jakiej podstawie liczy się przekroczenie SLA. Bez zapisu o pomiarze kary są teoretyczne.
• Okno serwisowe — Sprawdź, czy prace planowe są wyłączone z SLA i w jakich godzinach się odbywają – to wpływa na dostępność sklepu w szczycie sprzedaży.
• Lista wyłączeń z pakietu — Co nie wchodzi w opiekę: nowe funkcje, migracje, kampanie SEO i reklamowe, nowy szablon. Poproś o to na piśmie w załączniku do umowy.
• Ukryte koszty — Licencje płatnych wtyczek i modułów (typowo 300–1500 zł/rok), certyfikat SSL, CDN, zewnętrzny backup – kto płaci i kto pilnuje terminu odnowienia.
• Raport miesięczny — Wymagaj podsumowania prac, incydentów i rekomendacji. Sprawdź, czy dostajesz go do 10. dnia kolejnego miesiąca i czy zawiera liczbę przepracowanych godzin.
• Dostęp awaryjny i wyjście z umowy — Ustal, czy wykonawca pracuje na własnych kontach z 2FA, czy na Twoich oraz co się dzieje z dostępami i dokumentacją po zakończeniu współpracy.
• Osoba decyzyjna po Twojej stronie — Wskaż jedną osobę akceptującą zmiany. Brak decydenta wydłuża każde wdrożenie i zjada godziny z pakietu na ustalenia wewnętrzne.

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