Utrzymanie i opieka techniczna sklepu to nie hosting i nie gwarancja na wdrożenie, tylko powtarzalny zestaw prac wykonywanych co tydzień, miesiąc i kwartał. W praktyce oznacza aktualizacje bezpieczeństwa, weryfikację kopii zapasowych, monitoring dostępności, przegląd logów i gotowość do reakcji wtedy, gdy sklep przestaje sprzedawać. Poniżej znajdziesz zakres tych prac, realne widełki godzinowe, wzór SLA do umowy i listę kontrolną do porównania ofert. Dla sklepów w Bełżcu i okolicy zasady są identyczne jak wszędzie — różni się tylko kanał kontaktu i to, czy potrzebna jest obecność na miejscu.
Najwięcej nieporozumień na tym rynku bierze się z mieszania trzech różnych rzeczy. Rozdzielmy je raz i na zawsze.
Przykład z życia. Sklep na PrestaShop 1.7.6, PHP 7.4, ostatnia aktualizacja dwa lata temu. Co widać po wejściu w logi? W katalogu logów setki wpisów 404 dziennie od botów skanujących stare ścieżki modułów. W logu PHP ostrzeżenia o przestarzałych funkcjach, które przy kolejnej zmianie PHP zamienią się w błędy krytyczne. Slow query log pokazuje zapytania do tabel produktowych po 3–5 s. Tabela ps_connections urosła do kilkuset megabajtów i spowalnia panel. Certyfikat TLS wygasł, a nikt tego nie zauważył, bo przeglądarka klienta pokazała tylko ostrzeżenie. Żadna z tych rzeczy nie jest „awarią hostingu” ani „błędem z wdrożenia”. To skutek braku opieki. Mechanika jest identyczna w każdej gminie – zobacz, jak wygląda utrzymanie i opieka techniczna sklepów w Biłgoraju, bo różnice dotyczą wyłącznie kanału kontaktu i ewentualnej obecności na miejscu.
Zgodność modułów z rdzeniem i zasady aktualizacji opisuje dokumentacja deweloperska PrestaShop: PrestaShop Developer Documentation.
| Warstwa | Co obejmuje | Kto odpowiada | Kiedy się kończy |
|---|---|---|---|
| Hosting | Serwer, dysk, baza, poczta, kopie po stronie dostawcy | Dostawca hostingu | Nie kończy się, dopóki płacisz |
| Wsparcie powdrożeniowe | Błędy i braki z zakresu wdrożenia | Wykonawca wdrożenia | 14–90 dni od odbioru |
| Opieka techniczna | Aktualizacje, backupy, monitoring, logi, rozwój, wsparcie obsługi | Wykonawca opieki | Trwa, dopóki jest umowa |
Dobra oferta opieki da się rozłożyć na czynności z konkretną częstotliwością. Jeśli wykonawca pisze tylko „aktualizacje i wsparcie”, nie masz czego porównywać.
Tydzień: aktualizacje bezpieczeństwa – poprawki rdzenia PrestaShop w gałęzi, którą realnie utrzymujesz, aktualizacje modułów krytycznych (płatności, kurierzy, faktury) i PHP w wersji wspieranej przez producenta. Każda aktualizacja modułu to najpierw staging, potem produkcja, nigdy odwrotnie. Do tego weryfikacja kopii zapasowych: nie „czy zadanie się wykonało”, ale czy plik ma sensowny rozmiar i datę oraz czy da się z niego odczytać bazę. Monitoring uptime co 1–5 minut z alertem na maila i SMS. Przegląd logów błędów: log PHP, log serwera WWW, logi aplikacji, w PrestaShop dodatkowo katalog z logami i ps_log w bazie.
Miesiąc: zestawienie błędów 404 i 5xx (ile, z jakich adresów, czy to boty czy prawdziwi klienci na zepsutym linku), najwolniejsze zapytania z slow query log przy long_query_time ustawionym na 1 s, zajętość dysku i przyrost bazy, data wygaśnięcia certyfikatu TLS – Let’s Encrypt żyje 90 dni, więc kontrola ważności musi być cykliczna, a nie „kiedyś”. Wydajność mierzysz realnymi metrykami: Web Vitals na kluczowych szablonach (karta produktu, kategoria, koszyk).
Kwartał: audyt bezpieczeństwa (uprawnienia do panelu i FTP, konta nieaktywnych pracowników, nieużywane moduły), test odtworzenia backupu na środowisku staging – backup, którego nie odtworzyłeś, nie jest backupem, przegląd licencji modułów i terminów ich wsparcia.
Granica między abonamentem a pracami zlecanymi jest prosta: abonament to prace powtarzalne i reakcja na awarie. Nowa funkcja, nowa integracja, przebudowa szablonu, migracja sklepu – to godziny zlecane osobno. Zapisz tę granicę w umowie, bo spory zawsze dotyczą właśnie jej. Za wzorzec zakresu możesz wziąć utrzymanie i opiekę techniczną sklepów Krasnobród – rytm pracy jest ten sam, niezależnie od miejscowości.
| Częstotliwość | Co konkretnie robimy | Typowy czas (średni sklep) |
|---|---|---|
| Tydzień | Aktualizacje rdzenia, modułów i PHP, weryfikacja backupu, monitoring, przegląd logów | 1–4 h |
| Miesiąc | 404/5xx, slow query log, dysk, ważność certyfikatu TLS, Web Vitals | 1–3 h |
| Kwartał | Audyt bezpieczeństwa, test odtworzenia backupu na staging, przegląd licencji | 2–6 h |
Nie ma jednej ceny rynkowej, która byłaby prawdziwa dla każdego sklepu. Jest za to liczba godzin, którą da się policzyć i wpisać do umowy. Poniżej widełki miesięczne dla trzech typowych sytuacji.
Mały sklep – jeden język, kilkanaście modułów, brak integracji z systemem księgowym: 2–5 godzin miesięcznie. Średni sklep – kilkaset do kilku tysięcy SKU, płatności online, kilku kurierów, kilka modułów własnych: 8–16 godzin miesięcznie. Sklep z integracją ERP i wieloma kanałami sprzedaży (marketplace, porównywarki, dwa języki): 20 godzin i więcej, bo dochodzi uzgadnianie stanów magazynowych i mapowanie zamówień.
Model rozliczenia, który się sprawdza: stawka godzinowa wpisana w umowę plus pakiet godzin w abonamencie. Do tego jedna, jednoznaczna zasada: co dzieje się z godzinami niewykorzystanymi w miesiącu. Do wyboru są dwa uczciwe warianty – przenoszenie maksymalnie na jeden kolejny miesiąc albo przepadanie. Oba są w porządku, ale muszą być zapisane, bo inaczej każdy rozumie to inaczej. Poproś też o miesięczne zestawienie zużytych godzin; bez niego nie da się zweryfikować faktury.
Przykład kalkulacji: przy stawce 150 zł/h netto (podstaw swoją) 12 godzin to 1800 zł netto miesięcznie i 21 600 zł rocznie. To liczby, które warto zestawić z kosztem jednego dnia przestoju w sezonie.
Co podnosi koszt: moduły pisane na zamówienie (każda aktualizacja rdzenia wymaga ich przetestowania), integracja ERP, wielojęzyczność i wielowalutowość, skok ruchu w sezonie, niestandardowe szablony. Kiedy abonament się nie opłaca: przy sklepie poniżej kilkudziesięciu zamówień miesięcznie często wystarczy opieka minimalna 1–2 godziny na backup, aktualizacje krytyczne i monitoring oraz wsparcie na żądanie rozliczane godzinowo. Warto wtedy zadbać o wydajność i widoczność w wyszukiwarce osobno – punkt odniesienia masz w Core Web Vitals według Google Search Central. Podobne stawki i zakres obowiązują dla utrzymania i opieki technicznej sklepów Zwierzyniec.
| Typ sklepu | Godziny / miesiąc | Co dominuje w tych godzinach |
|---|---|---|
| Mały sklep, 1 język | 2–5 h | aktualizacje, backup, monitoring |
| Średni sklep, płatności + kurierzy | 8–16 h | wydajność, błędy integracji, rozwój funkcji |
| Sklep z ERP i wieloma kanałami | 20+ h | synchronizacja stanów, mapowanie zamówień, wsparcie obsługi |
Umowa SLA bez tabeli czasów jest życzeniem, nie zobowiązaniem. Poniżej model, który da się wyegzekwować w sklepie obsługiwanym przez jednego dewelopera lub małą agencję.
Kanały zgłoszeń – trzy, nie pięć.
Dlaczego wiadomość na Facebooku to zgubione zgłoszenie. Messenger nie ma właściciela sprawy, numeru zgłoszenia ani zegara. Gdy zmieni się osoba obsługująca profil, historia rozmowy nie jest niczyja. Zgłoszenie w komentarzu pod postem to dodatkowo publiczna informacja, że sklep nie działa – widzą ją klienci i konkurencja. Wyjątek: pytanie marketingowe albo prośba o kontakt.
Brak pośredników skraca naprawę. Jeśli sklep wdrażała ta sama osoba, która go utrzymuje, zna niestandardowy moduł do przeliczania kosztu dostawy według wagi i progu darmowej wysyłki. Nowy wykonawca bez tej wiedzy diagnozuje go 3–5 godzin zamiast 30 minut. Przy stawce 120–180 zł netto za godzinę różnica widać na pierwszej fakturze.
Co musi znaleźć się w umowie:
| Typ incydentu | Czas reakcji | Czas rozwiązania |
|---|---|---|
| Sklep offline / niedostępny | 30 minut | 2 godziny |
| Błąd płatności (przelewy, karta, BLIK) | 1 godzina | 4 godziny |
| Literówka, drobna poprawka treści | 24 godziny | 5 dni roboczych |
Cztery rzeczy sprawdzisz sam, przed kontaktem z wykonawcą. W większości przypadków odpowiedź jest już w logu.
Co psuje się najczęściej.
ps_cart, ps_connections, ps_guest. WooCommerce: wp_woocommerce_sessions. Przy 30 tys. wizyt miesięcznie tabela koszyka rośnie do kilku GB. Sprawdzenie: SELECT COUNT(*) FROM ps_cart WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY); Setki tysięcy wierszy oznaczają, że baza pracuje na dysku zamiast w pamięci.www-data, nie root. Katalog var/cache w PrestaShop musi być zapisywalny dla serwera WWW. Objaw: nie da się zapisać produktu, brakuje miniatur.Gdzie zajrzeć. Log błędów serwera: plik error_log w katalogu sklepu albo panel hostingu → Logi błędów. WooCommerce → Status → Logi (pliki w wp-content/uploads/wc-logs/). PrestaShop → Zaawansowane → Logi – włącz na czas diagnostyki, potem wyłącz, bo zapisuje każdą operację. Konsola przeglądarki: F12 → Console i Network, szukaj kodów 500, 404 i zasobów ładowanych po HTTP na stronie HTTPS.
Objawy spowolnienia. Wysoki TTFB (powyżej 800 ms) przy poprawnym całkowitym czasie ładowania oznacza problem po stronie serwera lub bazy, nie motywu – definicje i progi Core Web Vitals opisuje web.dev. Druga rzecz to liczba zapytań na stronę produktu: 80–120 to norma, 400 i więcej zwykle oznacza moduły pobierające wszystko na każdej stronie. Strukturę modułów opisuje dokumentacja dla deweloperów PrestaShop.
Migracja z 1.6 na 8.x. Ma sens, gdy 1.6 nie dostaje już łatek bezpieczeństwa, a moduły płatności i kurierów przestały działać na nowszym PHP. Sklep z 500–2000 SKU to 120–200 godzin pracy i 3–6 tygodni. Przed startem: lista modułów z wersjami i informacją, czy mają wydania dla 8.x, motyw (z 1.6 nie przenosi się), diff plików core pod kątem własnych modyfikacji, przekierowania 301 dla starych adresów, test pełnej ścieżki zamówienia i płatności.
| Objaw | Gdzie sprawdzić | Prawdopodobna przyczyna |
|---|---|---|
| Biała strona lub 500 | error_log, panel hostingu | Konflikt modułu z wersją PHP |
| Produkty ładują się kilka sekund | SHOW TABLE STATUS, phpMyAdmin | Przerośnięta tabela koszyka/sesji, brak indeksów |
| Nie da się zapisać produktu | Uprawnienia plików w SFTP | Zły właściciel lub tryb plików po migracji |
| Koszyk pustoszeje | Logi WooCommerce / PrestaShop | Błędna konfiguracja ciasteczek lub cache |
Bełżec to gmina w powiecie tomaszowskim, kilkadziesiąt kilometrów od przejścia granicznego w Hrebennem. Skala sklepów z tego rejonu jest podobna: jedno- lub dwuosobowa firma, w której właściciel robi zamówienia, faktury i marketing, a sklep działa na hostingu wybranym przy zakładaniu.
Trzy typy sklepów. Pierwszy to handel lokalny – zamówienie z Bełżca czy Tomaszowa Lubelskiego, często z odbiorem osobistym. Drugi to sprzedaż ogólnopolska z magazynu w powiecie: kilkanaście do kilkudziesięciu paczek dziennie. Trzeci to sklep sezonowy, rozkręcający się wiosną i latem razem z ruchem turystycznym na Roztoczu. W tym trzecim przypadku awaria w maju boli znacznie mocniej niż w listopadzie, więc prace serwisowe planuje się poza sezonem.
Typowe integracje. InPost (Paczkomaty i kurier), DPD, DHL – generowanie etykiet i statusów wprost z panelu zamówień. Najczęstsza usterka to wygasły token API po zmianie hasła w panelu przewoźnika: sklep przyjmuje zamówienia, ale etykiety się nie generują i nikt tego nie widzi, dopóki klient nie napisze. Drugi obszar to fakturowanie i stany magazynowe. Dopóki sprzedaż idzie jednym kanałem, wystarczy eksport CSV albo API co 15 minut. ERP zaczyna mieć sens przy dwóch–trzech kanałach sprzedaży, powyżej 500 zamówień miesięcznie albo gdy stany w magazynie i w sklepie rozjeżdżają się regularnie.
Hosting. Dla sklepu obsługującego region i klientów B2B serwer w Polsce ma dwa konkretne skutki: niższe opóźnienia dla krajowych użytkowników i prostszą umowę powierzenia danych. W B2B liczy się jeszcze jedno – klienci firmowi pracują w dni robocze 8–16, więc migracje i prace serwisowe planuje się na noc. Warunki SLA hostingu (dostępność, czas reakcji, kopie poza serwerem) sprawdza się przed podpisaniem umowy, nie po awarii.
Te same zasady opisujemy dla sąsiednich miejscowości: utrzymanie i opieka techniczna sklepów w Biłgoraju, Józefów, Zwierzyniec, Krasnobród, Szczebrzeszyn i Frampol.
Zasada 3-2-1 brzmi prosto: trzy kopie danych, na dwóch różnych nośnikach, z czego jedna poza serwerem produkcyjnym. Dla sklepu na PrestaShop oznacza to dump bazy MySQL, katalog plików (motyw, /modules, /img, /upload) oraz plik konfiguracyjny z danymi dostępowymi. Trzy kopie trzymane na tym samym hostingu to w rzeczywistości jedna kopia — awaria konta zabiera wszystkie naraz.
Ważniejsza od samego kopiowania jest weryfikacja. Kopia, której nie odtworzono, nie jest kopią zapasową — jest plikiem zajmującym miejsce. Raz na kwartał odtwórz sklep na środowisku testowym: wgraj dump bazy, podmień dane dostępowe w pliku konfiguracyjnym, wyłącz wysyłkę maili i indeksowanie, a potem sprawdź trzy rzeczy: czy produkty mają zdjęcia, czy zamówienie testowe przechodzi całą ścieżkę i czy panel płatności odpowiada. Taki test zajmuje 60–90 minut i jest jedynym sposobem, żeby wiedzieć, że procedura działa. Zakres tych prac rozpisaliśmy też przy okazji utrzymania i opieki technicznej sklepów w Biłgoraju.
Przy kilkudziesięciu zamówieniach dziennie RPO i RTO przestają być pojęciami z podręcznika. RPO mówi, ile zamówień możesz stracić — przy kopii raz na dobę to potencjalnie kilkadziesiąt rekordów i tyle samo wyjaśnień do klientów. RTO mówi, jak długo sklep stoi. Ustal oba parametry na piśmie, bo bez nich nie da się ocenić, czy opieka jest wystarczająca.
Po stronie RODO minimum to umowa powierzenia przetwarzania danych (art. 28 RODO) podpisana zarówno z hostingiem, jak i z firmą wykonującą opiekę techniczną — dostęp do bazy i panelu to dostęp do danych klientów. Prowadź rejestr czynności przetwarzania: kto, kiedy i po co wchodził do panelu oraz eksportował listę klientów. W formularzach zbieraj tylko to, co niezbędne do realizacji zamówienia i faktury; pola z datą urodzenia czy dodatkowymi zgodami bez jasno określonego celu lepiej wyłączyć.
| Parametr | Co oznacza | Wartość do uzgodnienia dla sklepu z 30–50 zamówieniami dziennie |
|---|---|---|
| RPO | Ile danych możesz stracić od ostatniej kopii | Kopia bazy co 1–2 godziny; przy kopii raz na dobę ryzyko utraty kilkudziesięciu zamówień |
| RTO | Jak długo sklep może być niedostępny | 2–4 godziny na przywrócenie z kopii, 6–8 godzin przy pełnym odtworzeniu plików i bazy |
| Test odtworzenia | Potwierdzenie, że kopia jest użyteczna | Raz na kwartał, na środowisku testowym, 60–90 minut pracy |
| Retencja kopii | Jak daleko wstecz sięgasz | 30 dni kopii dziennych, 12 miesięcy kopii miesięcznych |
Zanim podpiszesz umowę na opiekę, wyślij ten sam zestaw pytań do trzech firm. Odpowiedzi porównuj na piśmie, nie przez telefon — różnice widać dopiero wtedy, gdy obok siebie leżą konkretne liczby.
Trzy sygnały ostrzegawcze w cenniku:
Przykład z życia: klient podpisał umowę za 150 zł miesięcznie, a po roku okazało się, że kopie robi hosting raz na dobę i nigdy ich nie testowano, a motyw sklepu należy do wykonawcy. Zmiana firmy kosztowała więcej niż rok tamtej opieki. Zakres i sposób przekazania ustal przed startem, nie po. Ten sam zestaw pytań zadaj, porównując oferty dla utrzymania i opieki technicznej sklepów we Frampolu oraz opieki technicznej sklepów w Krasnobrodzie — stawki i zakresy różnią się między firmami, nie między miastami.
Zacznij od bezpłatnego audytu technicznego. 45 minut, zdalnie lub na miejscu, bez dostępu do danych klientów — wystarczy panel hostingu i adres sklepu. W tym czasie sprawdzamy: wersję PHP i PrestaShop, listę modułów wraz z tym, które nie były aktualizowane od ponad roku, konfigurację kopii zapasowych (kiedy ostatnia, gdzie leży, czy ktokolwiek ją odtworzył), certyfikat TLS i wymuszenie HTTPS, zabezpieczenie panelu administracyjnego, czas odpowiedzi serwera, logi błędów 500 i 404 z ostatnich 30 dni oraz rozmiar bazy.
Na wyjściu dostajesz notatkę na 1–2 strony: uporządkowaną listę 5–10 punktów w kolejności od największego ryzyka, z informacją, ile czasu zajmie naprawa i czy to praca jednorazowa, czy element stałej opieki. Bez prezentacji sprzedażowej i bez zobowiązania.
Pracujemy z firmami z Bełżca, Tomaszowa Lubelskiego i okolic. Dojazd nie jest problemem, ale w praktyce większość prac wykonujemy zdalnie, a zgłoszenia przyjmujemy mailem lub telefonicznie w ustalonych godzinach. Zakres usług obejmuje aktualizacje i bezpieczeństwo, kopie zapasowe z testem odtworzenia, monitoring dostępności, drobne poprawki w sklepie i integracjach oraz raport miesięczny. Jeśli chcesz najpierw zobaczyć, jak taki zakres wygląda opisany krok po kroku, zajrzyj do materiałów o utrzymaniu i opiece technicznej sklepów w Józefowie i utrzymaniu i opiece technicznej sklepów w Zwierzyńcu.
| Etap | Czas | Co dostajesz |
|---|---|---|
| Audyt techniczny | 45 minut | Notatka z listą 5–10 ryzyk w kolejności ważności |
| Zakres i wycena | do 48 godzin od rozmowy | Katalog prac w pakiecie, stawkę godzinową, czasy reakcji |
| Umowa | 1 rozmowa i podpis | Umowa miesięczna z miesięcznym okresem wypowiedzenia |
| Start opieki | do 5 dni roboczych | Przejęcie dostępów, pierwszą kopię z testem odtworzenia, monitoring |
Traktowanie hostingu jako opieki technicznej nad sklepem.
Jak wykryć: W umowie jest wyłącznie SLA serwera (np. 99,9% uptime), a nie ma ani słowa o aktualizacjach, kopiach zapasowych, przeglądzie logów czy testach płatności.
Jak naprawić: Rozdziel odpowiedzialności: hosting odpowiada za dysk, sieć i dostępność maszyny, opieka techniczna za aplikację. Dwie umowy to normalna sytuacja, ale każda musi mieć inny zakres.
Backup istnieje, ale nikt nigdy nie sprawdził, czy da się go odtworzyć.
Jak wykryć: W dokumentacji jest zapis o kopiach, ale wykonawca nie potrafi podać daty ostatniego testu odtworzenia na środowisku staging.
Jak naprawić: Raz na kwartał odtworzyć kopię na staging i zapisać wynik: czas odtworzenia, kompletność bazy i plików oraz to, czy sklep działa po zmianie domeny na testową.
Aktualizacje rdzenia i modułów robione hurtem, bezpośrednio na produkcji, najlepiej w piątek po południu.
Jak wykryć: Historia zmian pokazuje kilkanaście aktualizacji w jednym dniu, brak kopii sprzed zmian i brak środowiska testowego.
Jak naprawić: Aktualizować partiami po 2–3 elementy, najpierw na staging, w dni robocze przed południem, z kopią i gotowym planem wycofania zmiany.
Zgłaszanie awarii przez wiadomość prywatną na Facebooku albo w komunikatorze.
Jak wykryć: Zgłoszenie nie ma numeru, nie ma potwierdzenia odbioru i nie da się wskazać, ile minut upłynęło do pierwszej reakcji.
Jak naprawić: Jeden oficjalny kanał: dedykowany adres e-mail lub panel zgłoszeń. Telefon wyłącznie do awarii krytycznych, z czasem reakcji zapisanym w umowie.
Nieuprzątnięte tabele sesji i koszyków w MySQL, przez co baza rośnie mimo stałej liczby zamówień.
Jak wykryć: Rozmiar bazy zwiększa się miesiąc do miesiąca, a w tabelach sesji i koszyków leżą wpisy sprzed roku.
Jak naprawić: Ustawić cykliczne zadania czyszczące i skrócić czas życia sesji do wartości odpowiadającej realnemu porzucaniu koszyków. Po zmianie sprawdzić, czy rozmiar bazy faktycznie przestał rosnąć.
Umowa bez zakresu, bez wykluczeń i bez zapisu o własności kodu oraz dostępów.
Jak wykryć: W dokumencie widnieje ogólne sformułowanie o opiece nad sklepem, bez liczby godzin, listy prac i bez okresu wypowiedzenia.
Jak naprawić: Dopisać zakres prac planowanych, listę wykluczeń, stawkę za prace dodatkowe, okres wypowiedzenia oraz własność modułów pisanych na zamówienie i wszystkie dostępy.
Opieka techniczna to konkretny zestaw czynności z określoną częstotliwością, a nie deklaracja „dbamy o Twój sklep”. Jeśli wykonawca nie potrafi pokazać tygodniowej i miesięcznej listy prac oraz czasów reakcji, nie da się tego rozliczyć ani wyegzekwować. Zacznij od własnej listy kontrolnej i porównaj z nią ofertę — często wystarczy jedno pytanie o test odtworzenia backupu, żeby zobaczyć różnicę w poziomie obsługi.
Hosting odpowiada za infrastrukturę: serwer, dysk, sieć i dostępność maszyny. Gwarancja na wdrożenie dotyczy błędów w kodzie, który dostarczył wykonawca, i zwykle wygasa po kilku miesiącach. Opieka techniczna to ciągły proces: aktualizacje, kopie, monitoring, przegląd logów i reakcja na awarie. Te trzy obszary mogą obsługiwać różne firmy, ale wtedy trzeba na piśmie ustalić, kto odpowiada za co — inaczej przy awarii wszyscy wskazują na siebie.
Mały sklep na PrestaShop lub WooCommerce z kilkudziesięcioma zamówieniami miesięcznie to zwykle 2–5 godzin pracy w miesiącu. W tej liczbie mieszczą się aktualizacje bezpieczeństwa, weryfikacja kopii, monitoring i podstawowy przegląd logów. Średni sklep z większą liczbą modułów i kanałów sprzedaży to 8–16 godzin, a sklep zintegrowany z ERP i marketplace'ami — 20 godzin i więcej. Zakres prac nie zależy od miejscowości: tak samo wygląda w Bełżcu, w Józefowie i w Zwierzyńcu.
Zwykle nie. Abonament pokrywa prace planowane: aktualizacje, kopie, monitoring, przeglądy i drobne poprawki. Rozwój funkcji, nowe integracje czy przebudowa szablonu to prace zlecane, rozliczane godzinowo poza pakietem. Jeśli oferta nie rozdziela jednego od drugiego, przy pierwszym większym zadaniu pojawi się spór o fakturę, a nie o technikalia.
Najprościej wtedy, gdy sklep robi mniej niż kilkadziesiąt zamówień miesięcznie i nie ma rozbudowanych integracji. Sensowniejsza bywa wtedy jednorazowa usługa porządkowania: audyt bezpieczeństwa, uporządkowanie kopii zapasowych, ustawienie monitoringu i aktualizacje z zaległości. Koszt takiego uporządkowania bywa zbliżony do dwóch–trzech miesięcy abonamentu, a później wystarczy rozliczana godzinowo reakcja na konkretne zdarzenia.
Praktyczny wzorzec: sklep offline — reakcja do 30 minut, przywrócenie do 2 godzin. Błąd płatności lub składania zamówienia — reakcja do 1 godziny, rozwiązanie do 4 godzin. Literówka, zmiana treści czy drobna korekta — reakcja do 24 godzin, realizacja do 5 dni roboczych. Ważne, żeby czasy były rozpisane na typy zdarzeń, a nie zapisane jednym zdaniem „reagujemy szybko”.
Jeden kanał: dedykowany adres e-mail albo panel zgłoszeń, w którym widać numer, status i czas reakcji. Telefon awaryjny powinien być zarezerwowany dla sytuacji, gdy sklep nie działa lub nie da się zapłacić. Wiadomość na Facebooku nie ma numeru ani właściciela, więc przy kilku zgłoszeniach dziennie po prostu ginie w skrzynce.
Od kopii i testu jej odtworzenia — bez tego każda kolejna czynność jest ryzykiem. Potem inwentaryzacja: wersja PHP, lista modułów, zgodność z tą wersją i wtyczki bez aktualizacji od ponad roku. Aktualizacje wykonuje się partiami po 2–3 elementy na środowisku staging, nie na produkcji. Zakres zmian technicznych w PrestaShop opisuje dokumentacja deweloperska PrestaShop.
Jeśli chcesz porównać obecny zakres opieki z tym, co realnie trzeba robić w sklepie na PrestaShop lub WooCommerce, napisz do nas krótko: platforma, przybliżona liczba modułów i integracje. Odpowiemy widełkami godzinowymi, bez zobowiązań.