Utrzymanie i opieka techniczna sklepów w Bydgoszczy to w praktyce praca zdalna — z jednym warunkiem: ktoś po Twojej stronie musi mieć dostępy, a po stronie wykonawcy musi być jasne, kto reaguje pierwszy. Ten tekst dotyczy strony organizacyjnej, a nie technicznej. Poniżej masz listę ustaleń, które warto zrobić przed podpisaniem umowy: zakres, priorytety, kanały zgłoszeń, raporty, rozliczenie i zasady przekazania sklepu. Dzięki temu po pół roku nie okaże się, że płacisz za pakiet, który nie obejmuje ani jednej aktualizacji na stagingu.
W ofertach te dwa słowa są używane wymiennie, a znaczą co innego. Utrzymanie to bieżące prace: aktualizacja PrestaShop z 8.1 na 8.2, kopia bazy, poprawka modułu płatności, czyszczenie logów. Opieka to odpowiedzialność: kto odbiera zgłoszenie, w jakim czasie reaguje, co raportuje i kto decyduje o wdrożeniu na produkcję. Można kupić samo utrzymanie — płacisz wtedy za godziny i sam pilnujesz, żeby ktoś miał je na co przeznaczyć.
Zakres opieki nad sklepem sprowadza się do pięciu warstw:
Stały partner techniczny przydaje się w pięciu sytuacjach: nie masz w firmie nikogo, kto zna PHP i administrację serwerem; planujesz migrację (zmiana hostingu, wersji PrestaShop, szablonu); wchodzisz w sezon i nie chcesz wtedy wprowadzać zmian; płatności albo etykiety kurierskie działają „raz tak, raz nie”; sklep zaczął zwalniać i trzeba ustalić, czy problem siedzi w bazie, cache czy szablonie. Zmiany między wersjami PrestaShop najlepiej weryfikować w dokumentacji dla deweloperów PrestaShop — nie na forum.
Pułapka: umowa, w której „opieka” nie obejmuje dostępu do serwera i środowiska testowego, to w praktyce helpdesk. Bez stagingu każda aktualizacja idzie wprost na produkcję. Ogólny zakres takich prac opisujemy w sekcji utrzymanie stron internetowych.
| Obszar | Utrzymanie (prace) | Opieka (odpowiedzialność) |
|---|---|---|
| Aktualizacje | Wdrożenie modułu, test na stagingu | Decyzja, kiedy wdrażać, i raport z testu |
| Kopie zapasowe | Wykonanie backupu bazy i plików | Gwarancja retencji i test odtworzenia |
| Incydent | Diagnoza i naprawa | Czas reakcji, priorytet, informowanie Ciebie |
| Serwer | Konfiguracja PHP, MySQL, cron | Monitoring, limity, reakcja na alert |
Porównuj oferty punkt po punkcie. Poniżej parametry, które warto wpisać do umowy wprost:
Na końcu sprawdź dwie rzeczy: czy w pakiecie jest konkretna liczba godzin (np. 5 h miesięcznie) i co się dzieje, gdy ją przekroczysz — stawka za nadwyżkę powinna być w umowie. Układ priorytetów i zakres prac opisujemy szerzej w tekście o tym, jak poukładać utrzymanie i opiekę techniczną sklepów.
| Element | Typowy parametr do umowy |
|---|---|
| Monitoring | Interwał 1–5 min, alert SMS dla P1 |
| Backup | Baza co 6–24 h, retencja 30 dni, kopia offsite, test odtworzenia 1×/kwartał |
| Aktualizacje | Zawsze na stagingu, wdrożenie w oknie serwisowym, lista modułów w zakresie |
| Administracja VPS | Aktualizacje systemu 1×/mies., przegląd logów 1×/tyg. |
| Core Web Vitals | Raport LCP, INP, CLS 1×/mies. |
| Wsparcie integracji | Zakres: płatności, kurierzy, ERP; czas reakcji wg priorytetu |
Pierwsze rozróżnienie, które ratuje umowę: czas reakcji to potwierdzenie zgłoszenia i start diagnozy, a czas naprawy to przywrócenie działania sklepu. Bez tego rozdzielenia dostawca „reaguje” w 15 minut i naprawia trzy dni. Warto zapisać jeszcze trzecią wartość: czas obejścia (workaround), np. wyłączenie wadliwego modułu, żeby ludzie mogli kupować, mimo że przyczyna nie jest jeszcze usunięta.
| Priorytet | Przykład | Czas reakcji | Cel naprawy |
|---|---|---|---|
| P1 | Sklep nie działa, koszyk nie pozwala złożyć zamówienia, bramka płatności odrzuca transakcje | do 1 h | Praca ciągła do przywrócenia, informacja do Ciebie co 2 h |
| P2 | Nie generują się etykiety kurierskie, błąd 500 na kategorii, część produktów nie wchodzi do koszyka | do 4 h w godz. 8–16 | Do końca następnego dnia roboczego |
| P3 | Błąd wyświetlania, literówka w mailu, brakujące tłumaczenie | do 1 dnia roboczego | Do 5 dni roboczych |
| P4 | Kosmetyka, drobne zmiany treści, nowy tekst w opisie | do 5 dni roboczych | W ramach pakietu godzin |
Nie ma jednej stawki za opiekę nad sklepem. Cena wynika z pięciu rzeczy: platformy, liczby integracji, ruchu, tego kto administruje serwerem, oraz liczby modułów pisanych na zamówienie — czyli plików nadpisujących domyślne zachowanie sklepu (w PrestaShop katalog /override, w WooCommerce osobna wtyczka).
Dlatego uczciwiej działa rozliczenie godzinowe z miesięcznym minimum niż sztywny pakiet bez zakresu. Pakiety 8, 12 i 20 godzin miesięcznie mają sens, ale tylko wtedy, gdy umowa mówi wprost, co się w te godziny liczy: aktualizacje, backupy, monitoring, czas reakcji, drobne zmiany w szablonie, wsparcie dla osoby obsługującej zamówienia. Bez tego po pół roku okazuje się, że pakiet nie obejmował ani jednej aktualizacji na kopii testowej.
Co realnie podnosi koszt:
Co koszt obniża: porządek w modułach (lista wersji i autorów), monitoring dostępności i czasu odpowiedzi, krótka dokumentacja konfiguracji, poprawnie ustawiony cache (cache stron, OPcache, CDN). Szybciej działający sklep generuje mniej interwencji, a Google opisuje, jak Core Web Vitals przekłada się na wyniki w wyszukiwaniu.
Przykładowe rozbicie na pakiety i stawki znajdziesz w naszym cenniku utrzymania i opieki technicznej sklepów.
| Zakres w miesiącu | 8 h | 12 h | 20 h |
|---|---|---|---|
| Aktualizacje core i modułów na stagingu | raz w miesiącu | raz w miesiącu | wg potrzeb |
| Monitoring dostępności i reakcja na awarię | tak | tak | tak + dyżur telefoniczny |
| Drobne zmiany w szablonie i treściach | do 2 h | do 4 h | do 8 h |
| Prace rozwojowe (nowe integracje, moduły) | nie | rezerwa 2 h | rezerwa 6 h |
| Raport miesięczny | skrócony | pełny | pełny + rozmowa |
Platforma nie decyduje o tym, czy sklep da się utrzymać. Decyduje o tym, ile minut zajmuje każda czynność i jak szybko da się wdrożyć zmianę.
PrestaShop. Aktualizacja core (np. z 1.7.x na 8.x) wymaga przećwiczenia na stagingu, bo moduły i pliki w /override potrafią przestać działać. Dochodzi zgodność z PHP — moduł działający na 7.4 na 8.1 często sypie ostrzeżeniami typu „undefined array key”. Migracja bazy to kopia, sprawdzenie tabel z prefiksem sklepu i test zamówienia od koszyka do maila potwierdzającego. Plus: duża społeczność i dokumentacja dla deweloperów, więc typowe problemy mają opisane rozwiązania.
WooCommerce. To utrzymanie WordPressa: core, motyw, wtyczki. Najczęstszy problem to konflikt między wtyczkami po aktualizacji, dlatego automatyczne aktualizacje na produkcji to zły pomysł — najpierw staging. Drugi obszar to hosting: limit pamięci PHP, WP-Cron odpalany tylko przy ruchu, brak object cache przy dużym katalogu. Bezpieczeństwo wymaga pilnowania, bo wtyczki są najczęstszą drogą wejścia.
Sklep custom. Nie ma społeczności ani gotowych poprawek bezpieczeństwa. Potrzebny jest deweloper znający ten kod oraz dokumentacja: gdzie są klucze API, jak działa koszyk, jakie zadania siedzą w cronie. Bez tego każda zmiana zaczyna się od czytania cudzego kodu — i to jest realny koszt.
Tempo wdrożeń układa się podobnie jak ryzyko: najszybciej WooCommerce (wtyczka), średnio PrestaShop (moduł plus testy), najwolniej custom. Jak wygląda to w praktyce, opisujemy przy okazji wdrożeń w innym mieście: utrzymanie i opieka techniczna sklepów Zamość.
| Platforma | Główny obszar pracy | Backup | Główne ryzyko |
|---|---|---|---|
| PrestaShop | core, moduły, /override, PHP, baza z prefiksem | pliki + zrzut bazy, test odtworzenia | moduły niekompatybilne po aktualizacji |
| WooCommerce | WordPress, wtyczki, motyw, hosting | pliki, baza, katalog uploads | konflikt wtyczek i luki bezpieczeństwa |
| Custom | kod własny, brak gotowych patchy | wg skryptu klienta, często brak | uzależnienie od jednej osoby znającej kod |
Firma z Bydgoszczy nie musi wybierać wykonawcy z Bydgoszczy. Znaczenie mają cztery rzeczy: czas reakcji, kanał komunikacji, znajomość platformy i to, czy ktoś odbiera telefon, gdy sklep leży. Odległość nie wpływa na żadną z nich — zdalnie obsługuje się dziś większość zgłoszeń, a utrzymanie stron internetowych działa tak samo niezależnie od miasta.
Dostępy przekazujesz raz, bezpiecznie: SSH po kluczu, nie po haśle; VPN, jeśli serwer stoi w Twojej sieci; osobne konto techniczne w panelu hostingu zamiast współdzielenia Twojego; hasła w menedżerze (Bitwarden, 1Password) z możliwością odebrania dostępu jednym kliknięciem. Staging najlepiej na tym samym hostingu — inna wersja PHP na kopii testowej potrafi zmylić.
Inwentaryzacja na start to jedna tabela, która skraca każde kolejne zgłoszenie o kilkanaście minut: lista modułów i wtyczek z wersjami i autorami, lista integracji (płatności, kurierzy, ERP, feedy marketplace), miejsce przechowywania kluczy API, zadania w cronie, wersja PHP i bazy.
Procedura awaryjna: jedna wyznaczona osoba po Twojej stronie zgłasza; zgłoszenie trafia na maila lub do ticketu, nie na komunikator; przy niedostępnym sklepie jest eskalacja telefoniczna; w zgłoszeniu podajesz co się stało, od kiedy i czy dotyczy wszystkich, czy jednej metody płatności.
| Sytuacja | Praca zdalna | Wizyta na miejscu |
|---|---|---|
| Aktualizacja modułu lub wtyczki | tak | nie |
| Błąd 500 albo sklep nie odpowiada | tak, z eskalacją telefoniczną | tylko przy awarii sprzętu w serwerowni klienta |
| Migracja na serwer stojący w firmie | częściowo (konfiguracja zdalna) | tak |
| Szkolenie zespołu z obsługi zamówień | możliwe online | zwykle tak |
| Audyt przed sezonem | tak | opcjonalnie |
Oferta za 199 zł miesięcznie zwykle nie jest oszustwem — jest po prostu bardzo wąska. Kłopot zaczyna się przy awarii, gdy okazuje się, że w pakiecie nie ma ani jednej godziny na pracę poza rutynowymi aktualizacjami. Oto sześć zapisów, które kosztują najwięcej, bo wyglądają niewinnie.
1. Brak SLA i limitu godzin. Zdanie „reagujemy w ciągu 24 godzin” nic nie znaczy, jeśli nie wiadomo, czy liczą się godziny robocze czy kalendarzowe i czy chodzi o reakcję, czy o naprawę. W umowie muszą być trzy liczby: czas reakcji (np. 2 h w godz. 8–16), czas obejścia awarii (np. 8 h) oraz limit godzin w pakiecie (np. 5 h miesięcznie) ze stawką za nadwyżkę. Bez limitu pierwszy poważniejszy problem zjada budżet kwartału.
2. Backup tylko na tym samym serwerze i bez testu odtworzenia. Kopia leżąca obok sklepu na tym samym VPS znika razem z nim. Backup musi trafiać poza serwer (S3, Backblaze B2, osobny host), mieć retencję np. 30 dni, a raz na kwartał powinien zostać odtworzony na środowisku staging i zmierzony czas tego odtworzenia. Do umowy wpisz RPO i RTO.
3. Płatne wtyczki zamiast własnych modułów i uzależnienie od licencji. Moduł na licencji rocznej po jej wygaśnięciu potrafi przestać się aktualizować — przy sklepie z 40 rozszerzeniami to 40 punktów zapalnych. Zapytaj, które funkcje da się pokryć własnym modułem; punktem wyjścia do rozmowy jest dokumentacja PrestaShop dla deweloperów.
4. Brak dostępu do kodu i bazy po zakończeniu współpracy. Musi być zapis, że na koniec dostajesz repozytorium, zrzut bazy i pliki.
5. Opieka sprowadzona do klikania „aktualizuj”. Aktualizacja bez stagingu i bez planu wycofania to loteria, nie opieka.
6. Ukryte koszty. Licencje modułów, CDN, zewnętrzne API, integracje z kurierami i płatnościami, prace „poza pakietem” — poproś o listę z kwotami. Warto też przeczytać, co ustalić w umowie o utrzymanie sklepu, oraz szersze omówienie tego, jak poukładać utrzymanie i opiekę techniczną sklepów.
Rozmowa z potencjalnym wykonawcą powinna zająć 30–45 minut i skończyć się konkretami, nie ogólnikami. Zadaj te dziesięć pytań i zapisuj odpowiedzi — po dwóch rozmowach zobaczysz różnicę między firmą, która ma procedury, a taką, która improwizuje.
Oceniając odpowiedzi, patrz na cztery rzeczy: konkret (liczby i nazwy narzędzi, nie „nowoczesne rozwiązania”), przykłady („w zeszłym miesiącu aktualizacja modułu płatności wysypała koszyk, wycofaliśmy się w 20 minut”), zakres (co dokładnie jest w pakiecie, a co poza) i odpowiedzialność (imię i nazwisko osoby, która odbiera telefon). Jeśli wykonawca nie potrafi podać przykładu z ostatnich 3 miesięcy, prawdopodobnie nie prowadzi takich sklepów na co dzień. Zanim zaczniesz dzwonić, uporządkuj podstawy — kontekst znajdziesz w materiale o utrzymaniu stron internetowych.
| Obszar | Dobra odpowiedź zawiera | Czerwona flaga |
|---|---|---|
| SLA | osobny czas reakcji i naprawy dla godzin pracy oraz weekendów | „zajmiemy się szybko” |
| Monitoring | nazwę narzędzia, częstotliwość sprawdzeń, osobę odbierającą alert | „patrzymy na sklep” |
| Backup | lokalizację poza serwerem, retencję, datę ostatniego testu odtworzenia | kopia obok sklepu na tym samym VPS |
| Aktualizacje | staging przed produkcją i plan wycofania | aktualizacje wprost na produkcji |
| Raportowanie | miesięczny raport z listą prac i zużyciem godzin | brak raportu, tylko faktura |
| Zakończenie | repozytorium, baza, dostępy, dokumentacja | „to nasza własność” |
Wdrożenie opieki technicznej nie zaczyna się od podpisania umowy, tylko od uporządkowania stanu faktycznego. Poniższy plan zajmuje zwykle 2–4 tygodnie.
Umowa na opiekę bez tabeli priorytetów i czasów reakcji — „będziemy reagować szybko” to nie jest zapis, na którym można oprzeć decyzję w awarii.
Jak wykryć: Przeczytaj umowę i poszukaj konkretnych liczb: ile minut lub godzin od zgłoszenia, dla jakich sytuacji. Jeśli nie ma tam P1, P2, P3 ani żadnej siatki czasów, nie ma SLA.
Jak naprawić: Dopisz tabelę priorytetów z przykładami: sklep nie działa, płatności nie działają, błąd koszyka, literówka w opisie. Do każdego priorytetu przypisz czas reakcji i czas naprawy oraz kanał zgłoszenia.
Kupowanie pakietu „10 godzin miesięcznie” bez opisu zakresu. Wtedy nie wiesz, czy aktualizacja PrestaShop, konfiguracja modułu płatności i analiza logów to jedna pula, czy trzy osobne prace.
Jak wykryć: Sprawdź, czy oferta zawiera listę czynności wchodzących w pakiet i stawkę za prace poza pakietem. Brak stawki oznacza, że każda nadgodzina będzie negocjowana w najgorszym możliwym momencie.
Jak naprawić: Ustal trzy rzeczy: co jest w pakiecie, co jest poza nim i jaka stawka obowiązuje za prace dodatkowe. Poproś o przykładowe wyliczenie dla miesiąca bez awarii i miesiąca z jedną awarią P1.
Dostępy do domeny, hostingu, CDN, panelu płatności i konta Google Search Console zostają tylko u wykonawcy. Firma nie ma własnego menedżera haseł.
Jak wykryć: Zadaj pytanie: kto jest właścicielem konta w rejestratorze domeny i na hostingu. Jeśli odpowiedź brzmi „my, ale wiecie Państwo, że to działa”, to problem na przyszłość.
Jak naprawić: Zrób inwentaryzację: lista systemów, właściciel konta, osoba z dostępem. Konta główne powinny należeć do firmy, wykonawca dostaje dostępy imienne, odbierane przy zakończeniu współpracy.
Aktualizacje platformy i wtyczek robione bezpośrednio na produkcji, bez środowiska testowego.
Jak wykryć: Zapytaj wprost, czy przed aktualizacją powstaje kopia na stagingu i kto ją testuje. Brak stagingu w odpowiedzi to odpowiedź.
Jak naprawić: Wymagaj stagingu dla aktualizacji PrestaShop, WooCommerce i modułów oraz krótkiego opisu, co zostało przetestowane przed wdrożeniem na sklep. Test minimum: koszyk, płatność, wysyłka, logowanie.
Kopie zapasowe „są robione”, ale nikt nigdy nie sprawdził, czy da się z nich odtworzyć sklep.
Jak wykryć: Poproś o trzy informacje: częstotliwość kopii, okres retencji i miejsce przechowywania. Potem poproś o datę ostatniego testu odtworzenia.
Jak naprawić: Ustal w umowie częstotliwość, retencję, miejsce przechowywania poza serwerem produkcyjnym oraz to, kto i kiedy testuje odtworzenie. Test co najmniej raz na kwartał, z krótką notatką w raporcie.
Jeden kanał kontaktu — mail na biuro — bez eskalacji i bez numeru na sytuacje poza godzinami pracy.
Jak wykryć: Sprawdź, co się stanie, jeśli awaria płatności wystąpi w piątek o 20:00. Jeśli nie ma odpowiedzi w umowie, odpowiedź brzmi: nikt nie reaguje do poniedziałku.
Jak naprawić: Ustal dwa kanały: zgłoszenia rutynowe i kanał awaryjny. Dodaj listę kontaktów eskalacyjnych po obu stronach i zapis, które priorytety kwalifikują się do reakcji poza godzinami pracy.
Strona organizacyjna opieki technicznej to nie dokumenty dla porządku, a narzędzie na moment awarii. Jeśli w umowie nie ma priorytetów, czasów reakcji, kanału awaryjnego i listy dostępów, to przy pierwszym problemie liczy się wyłącznie to, kto odbierze telefon. Największą różnicę robią trzy rzeczy: jasny zakres, realne SLA i raport, z którego wynika, co zostało zrobione. Reszta — platforma, cennik, technologia — jest wtórna wobec tych ustaleń.
W większości przypadków nie. Prace nad serwerem, aplikacją sklepu, integracjami i kopiami zapasowymi wykonuje się zdalnie, a różnica strefy czasowej w Polsce nie występuje. Wizyta ma sens przy fizycznym sprzęcie w firmie, na przykład przy lokalnym serwerze czy urządzeniach sieciowych. Warto zapisać w umowie, czy dojazd jest w cenie i jaka jest jego stawka, żeby nie ustalać tego w trakcie awarii.
Od inwentaryzacji: domena, hosting, wersje PHP i platformy, lista modułów i wtyczek, integracje płatności i kurierów, dostępy. Dopiero na tej podstawie da się sensownie wycenić opiekę i ustalić priorytety. Jeśli nie wiesz, co dokładnie masz na serwerze, każda oferta będzie zgadywaniem. Punktem wyjścia może być ogólny opis usługi utrzymanie stron internetowych.
Typowy, sensowny układ to: P1 (sklep nie działa lub nie działają płatności) reakcja do 1 godziny, P2 (błąd koszyka, błąd wysyłki, awaria integracji) do 4 godzin, P3 (błąd wyświetlania, problem z pojedynczym produktem) do 1 dnia roboczego, P4 (literówka, drobna korekta treści) w kolejce prac. Ważne, żeby obok czasu reakcji był też czas naprawy albo przynajmniej zasada informowania o postępach. Sam czas reakcji bez naprawy nie rozwiązuje problemu.
Praktyczny model to mała pula godzin w abonamencie na prace planowane plus stawka godzinowa za prace poza nią. Sztywny pakiet bez opisu zakresu jest wygodny dla wykonawcy, nie dla Ciebie — nie wiadomo, co się w nim mieści. Rozliczenie godzinowe wymaga od obu stron ewidencji czasu, ale jest czytelne. Przykładowe stawki i pakiety znajdziesz w cenniku utrzymania i opieki technicznej.
Powinna, przynajmniej w części technicznej: poprawne kody odpowiedzi, mapy witryny, dane strukturalne, canonical, indeksacja oraz parametry Core Web Vitals. Są to kwestie techniczne i często wynikają z tych samych prac, co optymalizacja wydajności. Warto dopisać ten punkt do zakresu, a nie zakładać, że „SEO robi agencja”. Punkt odniesienia: dokumentacja Google o Core Web Vitals oraz artykuł Web Vitals na web.dev.
Konta główne — domena, hosting, panel płatności, poczta — powinny należeć do firmy, a wykonawca powinien mieć dostępy imienne. Kopie zapasowe powinny być przechowywane także poza serwerem produkcyjnym, najlepiej u dostawcy niezależnego od hostingu sklepu. W umowie warto zapisać, kto ma obowiązek przekazania kopii przy zakończeniu współpracy i w jakim formacie. Bez tego zapisu odzyskanie danych bywa trudne.
Ustal okres wypowiedzenia z zapasem na co najmniej jeden pełny cykl raportowania. Przygotuj pakiet przekazania: lista dostępów, dokumentacja modułów, rejestr prac, informacja o wersjach i o znanych problemach. Nowy wykonawca powinien najpierw zrobić kopię i uruchomić staging, a dopiero potem dotykać produkcji. Dobrze działa też jeden wspólny tydzień, w którym stary i nowy wykonawca reagują na zgłoszenia.
Jeśli chcesz uporządkować zakres, SLA i zasady rozliczeń przed podpisaniem umowy, napisz do DropDigital i opisz swój sklep — powiemy, co ma sens przy Twojej skali i co można pominąć.