Utrzymanie i opieka techniczna sklepu w Toruniu to stały proces, a nie jedna naprawa po awarii. W praktyce oznacza comiesięczny zestaw prac: aktualizacje, monitoring, kopie zapasowe z testem przywracania, pilnowanie integracji z kurierami i płatnościami oraz kontrolę czasów odpowiedzi serwera.
Stała opieka opłaca się, gdy rośnie ruch, sklep jest podłączony do ERP, sprzedajesz w kilku kanałach albo dziennie wpada kilkadziesiąt zamówień — wtedy każda godzina przestoju to policzalna strata. Poniżej znajdziesz zakres pakietu, poziomy SLA, realne widełki kosztów i checklistę wdrożenia krok po kroku.
Jeśli szukasz szerszego kontekstu dla stron i sklepów, zobacz nasze utrzymanie stron internetowych.
Naprawa doraźna kończy się w chwili, gdy sklep znowu działa: dostajesz fakturę i temat jest zamknięty do następnej awarii. Utrzymanie i opieka techniczna to inny model — miesięczny abonament na powtarzalny zestaw prac, wykonywanych także wtedy, gdy nic się nie zepsuło. Zakres utrzymania stron internetowych w sklepie obejmuje sześć obszarów, które trzeba pilnować równolegle:
Kiedy stała opieka realnie się opłaca? Trzy sygnały. Pierwszy: ruch rośnie i serwer zaczyna się dusić — przy 200 sesjach dziennie problemy bywają kosmetyczne, przy 2000 widać je w koszyku. Drugi: sklep jest spięty z ERP (Subiekt, Comarch, WMS) — aktualizacja wtyczki potrafi rozsypać mapowanie pól zamówienia. Trzeci: sprzedajesz w kilku kanałach i wpada kilkadziesiąt zamówień dziennie, gdzie godzina przestoju to policzalna strata.
Jeśli żaden z tych punktów nie jest prawdziwy, wystarczy prostszy pakiet: monitoring plus aktualizacje raz w miesiącu. Nie kupuj SLA na poziomie P1, jeśli sklep robi pięć zamówień tygodniowo — zapłacisz za dyżur, którego nie wykorzystasz. Odwrotnie też to działa: przy pracy magazynu na żywo z zamówieniami obietnica „reakcja w 4 godziny” bez kontaktu telefonicznego jest warta tyle, co jej potwierdzenie na piśmie.
| Kryterium | Naprawa po awarii | Stała opieka techniczna |
|---|---|---|
| Moment płatności | po zdarzeniu, za każdą interwencję | stały abonament miesięczny |
| Start pracy | od momentu zgłoszenia i wyceny | od wejścia w życie umowy |
| Kopie zapasowe | zwykle brak lub robione doraźnie | dzienne, z testem przywracania |
| Aktualizacje | dopiero gdy coś przestanie działać | cykliczne, na kopii testowej |
| Znajomość sklepu | od zera przy każdym zgłoszeniu | stały zespół i dokumentacja wdrożenia |
| Koszt przy spokojnym miesiącu | 0 zł | stała opłata za gotowość |
Pakiet da się porównać tylko wtedy, gdy w ofercie są częstotliwości, a nie hasła typu „kompleksowa opieka”. Poniżej zakres, o który warto dopytać w każdej ofercie.
/checkout i robić testowe zamówienie raz na dobę, bo strona główna może działać, gdy koszyk już nie.Pułapka z życia: sklep ma w pakiecie „aktualizacje co miesiąc”, ale bez stagingu. Przy 20 wtyczkach jedna niezgodność potrafi wyłączyć płatność kartą na kilka godzin w środku dnia.
| Obszar | Częstotliwość | Co konkretnie sprawdzić |
|---|---|---|
| Monitoring dostępności | co 1–5 min | HTTP 200, czas odpowiedzi, /checkout, API kurierów |
| Certyfikat SSL | kontrola dzienna | data wygaśnięcia, poprawność łańcucha, przekierowanie HTTPS |
| Aktualizacje | 1x miesiąc (małe), 1x kwartał (duże) | test koszyka, płatności, maili, etykiet po wdrożeniu |
| Kopie zapasowe | dziennie + baza co 4–6 h | retencja 30 dni, kopia off-site, test przywracania 1x kwartał |
| Wydajność | 1x miesiąc raport | LCP, INP, CLS, TTFB, zużycie CPU i RAM |
| Integracje | logi codziennie | błędy API, limity, statusy przesyłek, synchronizacja stanów |
Najczęstsze nieporozumienie w umowach o opiekę: klient czyta „reakcja w 1 godzinę” i rozumie „naprawa w 1 godzinę”. To dwie różne liczby. Czas reakcji to potwierdzenie zgłoszenia, nadanie priorytetu i rozpoczęcie diagnozy. Czas naprawy to przywrócenie działania sklepu. W umowie muszą być oba, inaczej nie masz czego egzekwować.
Przykładowe poziomy, które firma może wynegocjować, wyglądają tak:
Do tego trzy elementy, o które warto zapytać przed podpisaniem. Okno serwisowe — aktualizacje i prace planowane poza szczytem, np. 1:00–5:00, z powiadomieniem 24–48 h wcześniej i zamrożeniem wdrożeń w Black Friday oraz w tygodniu przed świętami. Kanały zgłoszeń — osobny telefon lub komunikator dla P1 i panel zgłoszeń dla reszty, z jednym źródłem prawdy o statusie sprawy. Eskalacja i raportowanie — kto odbiera zgłoszenie, kto decyduje o obejściu problemu, kto po stronie klienta jest kontaktem technicznym.
Pułapka: zapis „dostępność 24/7” bez wskazania, kto fizycznie odbiera telefon nocą. Zanim podpiszesz, sprawdź też co ustalić w umowie o opiekę nad sklepem — kilka zapisów warto mieć czarno na białym.
| Priorytet | Przykład zdarzenia | Czas reakcji | Czas naprawy |
|---|---|---|---|
| P1 | sklep nie działa, brak możliwości złożenia zamówienia, padła płatność | 1 h | 4 h |
| P2 | nie działa jedna metoda dostawy, brak synchronizacji z ERP | 4 h | 1 dzień roboczy |
| P3 | błąd kosmetyczny, literówka, poprawka treści | 1 dzień | 3 dni robocze |
Za comiesięczną opiekę nad sklepem w Toruniu zapłacisz dziś realnie 500–2500 zł netto, jeśli sklep działa na PrestaShopie lub WooCommerce, ma kilka integracji (płatności, kurier, fakturowanie) i jeden kanał sprzedaży. Widełki 2500–6000+ zł netto dotyczą sklepów połączonych z ERP, z modułami pisanymi na zamówienie, dużym ruchem albo kilkoma kanałami sprzedaży. Poniżej rozbicie na typy sklepów.
Poza abonamentem licz się ze stawką 150–350 zł/h. Dolna granica to drobne prace: konfiguracja, treści, korekta w szablonie. Górna — moduły własne, integracje z ERP, debugowanie na produkcji. Cztery rzeczy podnoszą koszt najbardziej: liczba integracji (każda to osobne API, webhooki i logi), moduły własne (nadpisane kontrolery potrafią blokować aktualizację rdzenia — wtedy update zajmuje 2–6 h analizy zamiast 20 minut), wolumen zamówień (baza i indeksy wymagają optymalizacji, cronów trzeba pilnować) oraz SLA 24/7 — dyżur oznacza, że ktoś realnie odbiera telefon w sobotę o 22:00 i tego nie da się zmieścić w 500 zł. Do tego dochodzi środowisko testowe i licencje.
Najczęstsza pułapka: oferta za 300–500 zł/mies. z „aktualizacjami i kopią”, ale bez testu przywracania, bez SLA i bez raportu. Płacisz mało do pierwszej awarii, a wtedy odtworzenie sklepu liczy się w tysiącach złotych i dniach przestoju. Monitoring warto oprzeć na mierzalnych wskaźnikach z Web Vitals — LCP, INP i CLS pokazują pogorszenie zanim zobaczy je klient. Jak ułożyć zakres i priorytety, opisujemy w artykule o utrzymaniu i opiece technicznej sklepów Toruń – co ustalić.
| Typ sklepu | Zakres prac w miesiącu | Abonament netto |
|---|---|---|
| Prosty sklep MŚP, 1 kanał, 2–3 integracje | Aktualizacje, kopie zapasowe, monitoring, do 2 h prac własnych | 500–1200 zł |
| Sklep rosnący, 3–5 integracji | Jak wyżej + 3–5 h prac, poprawki po kampaniach i zmianach w szablonie | 1200–2500 zł |
| Sklep z ERP, moduły custom, 5+ integracji | 10–20 h prac, środowisko testowe, pilnowanie synchronizacji | 2500–4500 zł |
| Duży ruch, SLA 24/7, kilka kanałów | 20+ h prac, dyżur, wydania tygodniowe, optymalizacja bazy | 4500–6000+ zł |
Sklep B2B rządzi się innymi zasadami niż detal. Trzy obszary generują najwięcej zgłoszeń.
1. Cenniki klientów i grupy. W PrestaShopie to grupy klientów plus reguły cenowe katalogowe i reguły koszyka. Pułapka numer jeden: nakładające się reguły o różnych priorytetach — po każdej zmianie trzeba przejść testowe zamówienie na koncie z każdej grupy, bo błąd w priorytecie oznacza sprzedaż poniżej kosztu. Pułapka numer dwa: strony z rabatami indeksowane przez Google. Ceny B2B wyciekają przez sitemapę albo linki w kategoriach. Dostęp dla niezalogowanych trzeba zamknąć, a wygenerowane adresy wykluczyć z indeksu.
2. Limity kredytowe i płatność odroczona. Klient B2B zamawia na przelew 14 lub 30 dni. Limit kredytowy musi zgadzać się z ERP (Subiekt, Comarch Optima, WF-Mag). Jeśli limit siedzi tylko w sklepie, po pierwszej synchronizacji salda się rozjadą i handlowiec dowie się o tym od klienta. Ustal jedno źródło prawdy — ERP — a sklep niech tylko czyta stan.
3. Logowanie i faktury. Logowanie zamiast zamówienia gościa, zamówienie zbiorcze, pole na numer zamówienia klienta, faktura z jego wewnętrznym numerem. Każde z tych pól trzeba przetestować na fakturze PDF, nie tylko w koszyku.
Do tego dochodzą integracje EDI i API oraz wiele kanałów sprzedaży. Stany muszą schodzić z ERP, bo inaczej sprzedasz coś, czego nie ma na magazynie. Przy własnych modułach opieraj się na dokumentacji dla deweloperów PrestaShop — szczególnie przy WebService API i uprawnieniach kluczy.
Zdalnie czy lokalnie? Nie musisz mieć wykonawcy z Torunia. Ważniejsza jest ta sama strefa czasowa, okno wdrożeniowe po godzinach pracy (np. 18:00–22:00) i ustalony z działem IT dostęp VPN lub RDP do ERP. Lokalny wykonawca przydaje się w dwóch momentach: uruchomienie B2B i migracja cenników. Reszta spokojnie działa zdalnie. Jak to wygląda po drugiej stronie regionu, opisujemy w materiale o utrzymaniu i opiece technicznej sklepów Bydgoszcz dla firmy.
Zanim podpiszesz umowę, zadaj te pytania i poproś o odpowiedzi mailem. Odpowiedź „to standard, damy radę” bez konkretów oznacza, że zakres nie jest przemyślany.
Umowa powinna mieć załącznik z listą prac w abonamencie i cennikiem prac dodatkowych, okres wypowiedzenia 1–3 miesiące oraz zapis o przekazaniu dokumentacji w 14 dni przy zmianie wykonawcy. Bez tego ostatniego punktu zmiana dostawcy zamienia się w wielotygodniowe odtwarzanie wiedzy. Ogólne zasady znajdziesz w materiale o utrzymaniu stron internetowych, a porównanie stawek w regionie — w tekstach o koszcie utrzymania i opieki technicznej sklepów.
| Pytanie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Gdzie leży kopia zapasowa i jaka jest retencja? | Baza + pliki, kopia poza produkcją, retencja 30 dni, szyfrowanie | „Serwer robi backup” bez wskazania lokalizacji i okresu |
| Kiedy był ostatni test przywracania? | Raport z datą, środowisko testowe, podane RTO i RPO | „Backup działa, sprawdzamy na bieżąco” |
| Co obejmuje SLA? | Osobno czas reakcji i naprawy, godziny pracy, kanał zgłoszeń | Jedno „24 h” bez rozróżnienia reakcji od naprawy |
| Kto realnie pracuje nad sklepem? | Imiona i role, deweloper w zespole wykonawcy | „Zajmie się tym nasz partner” bez szczegółów |
| Do kogo należą moduły własne? | Kod klienta, repozytorium Git z dostępem klienta | Kod zostaje u wykonawcy, dostęp tylko na żądanie |
| Czy dostanę pełne dostępy? | Serwer, hosting, back office admin, repozytorium, konta integracji | Tylko konto do back office z ograniczeniami |
| Procedura awaryjna płatności i kurierów | Lista kontaktów, kto dzwoni do operatora, plan B w koszyku | „Zgłosimy ticket do operatora i czekamy” |
| Stawka poza abonamentem | 150–350 zł/h, próg 30 min, cennik w umowie | „Wycena indywidualna” przy każdym zleceniu |
| Co przy zmianie wykonawcy? | Dokumentacja w 14 dni, brak blokad licencyjnych w kodzie | Temat pomijany w rozmowie |
Onboarding opieki to nie podpisanie umowy i czekanie. To pięć kroków, z których każdy kończy się dokumentem albo testem. Bez tego pierwszy miesiąc opieki jest zgadywaniem.
Zakres samego utrzymania po wdrożeniu opisujemy w sekcji utrzymanie stron internetowych — warto porównać go z tym, co faktycznie dostajesz od obecnego wykonawcy.
| Krok | Co powstaje | Realny czas |
|---|---|---|
| Audyt sklepu i hostingu | raport ryzyk, lista wtyczek, wyniki testów API | 1–3 dni |
| Dostępy i dokumentacja | menedżer haseł, opis środowiska, konto serwisowe | 1 dzień |
| Monitoring, backup, staging | alerty, kopie z retencją, subdomena testowa | 1–2 dni |
| Test przywracania i rollback | protokół z datą i czasem odtworzenia | 2–4 godziny |
| Raport i kanały zgłoszeń | harmonogram, wzór raportu, kontakty | 1 dzień |
Większość awarii sklepów, które przejmowaliśmy, nie wynikała z braku opieki, tylko z braku weryfikacji. Poniżej sześć pułapek i sposoby sprawdzenia ich w kilkanaście minut.
Zakres obowiązków i to, co powinno być w umowie, rozpisujemy w materiale co ustalić w umowie na utrzymanie sklepu w Toruniu.
| Wskaźnik | Wartość zdrowa | Sygnał ostrzegawczy |
|---|---|---|
| TTFB | poniżej 0,5 s z cache, poniżej 1 s dynamicznie | powyżej 1,5 s |
| Czas przywrócenia kopii | poniżej 2 godzin, potwierdzony testem | brak testu lub powyżej 4 godzin |
| Wtyczki bez aktualizacji 6+ miesięcy | zero | trzy i więcej |
| Błędy 5xx w logach | pojedyncze wpisy | powtarzalne serie w godzinach sprzedaży |
| Test API kuriera | etykieta i status pobrane poprawnie | 401, 429, 500 bez alertu |
Własny moduł ma sens wtedy, gdy sklep przestaje pasować do gotowych wtyczek. Typowy przypadek: płatna wtyczka do integracji z ERP działa, ale przy każdej aktualizacji wysypuje mapowanie pól, a support odpowiada po dwóch dniach. Drugi: potrzebujesz niestandardowego sposobu liczenia kosztu dostawy albo wystawiania dokumentów. Wtedy pisanie własnego modułu pod PrestaShop przestaje być droższe niż kolejna roczna licencja i kolejne godziny stracone na obejścia.
Wycena nie idzie z cennika z sufitu. Rozbijamy pracę na godziny: analiza, kod, testy na stagingu, wdrożenie i dokumentacja. W naszej praktyce drobna poprawka modułu to 1–3 godziny, nowy moduł integracyjny 20–60 godzin, migracja sklepu z zachowaniem danych 40–80 godzin. Dostajesz liczbę godzin i stawkę, więc wiesz, za co płacisz — również wtedy, gdy zakres trzeba dociąć.
Po wdrożeniu zostaje opieka: aktualizacje, monitoring, kopie z testem przywracania, pilnowanie API kurierów i płatności oraz raport miesięczny. SLA ustalamy na piśmie: czas reakcji w dni robocze, czas naprawy błędu krytycznego (najczęściej 24 godziny), stawka za prace poza pakietem. Bez tego „opieka” oznacza, że ktoś reaguje, kiedy ma czas.
Pracujesz bezpośrednio z deweloperem, który czyta logi Twojego sklepu, a nie z pośrednikiem przekazującym zgłoszenia dalej. Przy awarii nie ma dwóch firm przerzucających się odpowiedzialnością za API i hosting. Jeżeli to model, który Ci pasuje, napisz — po krótkiej rozmowie wiemy, czy wystarczy pakiet opieki, czy najpierw trzeba domknąć audyt. Zakres i sposób pracy na innych rynkach pokazujemy na przykładzie utrzymania i opieki technicznej sklepów Zamość.
Kupowanie „opieki technicznej”, która nie ma zdefiniowanego zakresu prac ani częstotliwości.
Jak wykryć: W ofercie nie ma tabeli prac (co, jak często), liczby godzin w abonamencie ani listy wyłączeń. Jest tylko ogólne zdanie o „dbaniu o sklep”.
Jak naprawić: Poproś o harmonogram z częstotliwością: aktualizacje co X tygodni, przegląd kopii co miesiąc, raport miesięczny. Zapisz to jako załącznik do umowy.
Backup jest robiony, ale nikt nigdy nie sprawdził, czy da się z niego przywrócić sklep.
Jak wykryć: Wykonawca pokazuje listę plików kopii, ale nie potrafi wskazać daty ostatniego testu odtworzenia środowiska.
Jak naprawić: Wpisz do umowy test przywracania minimum raz na kwartał na środowisku staging i żądaj krótkiego raportu z wynikiem oraz czasem odtworzenia.
Aktualizacje PrestaShop, WooCommerce i wtyczek wgrywane wprost na produkcję, w godzinach sprzedaży.
Jak wykryć: Po każdej aktualizacji klient zgłasza błędy koszyka, płatności albo wyglądu. Brak środowiska testowego lub jest ono nieaktualne.
Jak naprawić: Ustal staging odwzorowany z produkcji, aktualizacje najpierw tam, potem wdrożenie poza szczytem i szybki rollback, jeśli coś się wysypie.
Umowa nie rozróżnia czasu reakcji od czasu naprawy.
Jak wykryć: Zapis typu „reagujemy w ciągu godziny” bez informacji, kiedy problem ma zostać usunięty.
Jak naprawić: Dopisz osobno dla każdego priorytetu czas reakcji i czas naprawy, np. P1: reakcja 1 h, naprawa 4 h — razem z definicją, co jest incydentem P1.
Prace serwisowe i wdrożenia planowane w godzinach największego ruchu.
Jak wykryć: Restarty, migracje czy zmiany w bazie wypadają między 9:00 a 17:00 w dni robocze, a zamówienia w tym czasie spadają.
Jak naprawić: Ustal okno serwisowe poza szczytem (np. 22:00–6:00) i wymóg powiadomienia z wyprzedzeniem o pracach planowanych.
Firma nie ma dostępu do kodu, repozytorium ani modułów własnych, więc nie może zmienić wykonawcy.
Jak wykryć: Po pytaniu „proszę o dostęp do repo i hostingu” pojawia się opór albo odpowiedź, że „to jest po stronie wykonawcy”.
Jak naprawić: W umowie zapisz, że kod, moduły i dostępy są własnością zamawiającego, oraz dopisz procedurę przekazania środowiska innemu wykonawcy.
Stała opieka techniczna sklepu to zestaw powtarzalnych prac z określoną częstotliwością, a nie obietnica „reagowania na awarie”. W umowie muszą być trzy rzeczy: zakres prac, rozdzielone czasy reakcji i naprawy oraz zasady dostępu do kodu i kopii.
Dla prostego sklepu MŚP realny budżet to 500–2500 zł miesięcznie, dla sklepów z ERP i modułami własnymi 2500–6000 zł i więcej. Zanim podpiszesz cokolwiek, przeprowadź test przywracania backupu i ustal, kto odbiera alert w nocy.
Nie. Hosting to infrastruktura, na której stoi sklep — serwer, miejsce na pliki, baza danych. Opieka techniczna to praca ludzi: aktualizacje, monitoring, kopie zapasowe, naprawa błędów, wsparcie integracji i optymalizacja.
Możesz mieć dobry hosting i sklep, który nie był aktualizowany od roku — to dwa osobne tematy i osobne pozycje w budżecie.
Doraźna naprawa wystarczy, gdy sprzedaż jest sporadyczna, nie masz integracji z ERP i możesz pozwolić sobie na dzień przestoju. Stała opieka zaczyna się opłacać, gdy rośnie ruch, dziennie wpada kilkadziesiąt zamówień albo sklep jest podłączony do systemu księgowego lub magazynowego.
Punkt graniczny jest prosty: jeśli godzina przestoju kosztuje więcej niż miesięczny abonament, opieka jest tańsza niż naprawianie skutków awarii.
Czas reakcji to moment, w którym wykonawca potwierdza zgłoszenie i zaczyna nad nim pracę. Czas naprawy to moment, w którym problem jest faktycznie rozwiązany i sklep działa normalnie.
Oferty często podają tylko czas reakcji, bo brzmi dobrze i jest łatwy do dowiezienia. W umowie muszą być oba parametry, osobno dla każdego priorytetu.
W dobrym pakiecie tak, choć często jako osobna pozycja albo limit godzin w miesiącu. Warto zacząć od pomiaru — Google opisuje te wskaźniki w dokumentacji Search Central.
Realny zakres to poprawa LCP na karcie produktu, ograniczenie skryptów blokujących renderowanie i sprawdzenie czasów odpowiedzi serwera. Nie oczekuj jednak, że samo podbicie wyniku w PageSpeed przełoży się na sprzedaż — to jeden z elementów, nie cel sam w sobie.
Dla prostego sklepu bez ERP i bez modułów własnych typowe widełki to 500–2500 zł miesięcznie. Sklepy z integracją ERP, modułami custom i dużym ruchem wchodzą w 2500–6000 zł i więcej.
Poza abonamentem prace dodatkowe rozlicza się zwykle stawką 150–350 zł za godzinę. Orientacyjne stawki i zakres znajdziesz na stronie utrzymania i opieki technicznej sklepów Toruń.
Zdalna współpraca działa dobrze, jeśli masz jasne kanały komunikacji, ustalone SLA i dostęp do dokumentacji. Lokalny wykonawca z Torunia lub okolic bywa wygodniejszy przy integracjach z fizyczną infrastrukturą, dostawcami czy przy szybkich spotkaniach wdrożeniowych.
Ważniejsze od odległości jest to, kto realnie pracuje nad sklepem i czy masz kontakt do tej osoby, a nie tylko do handlowca. Podobne zasady ustalania współpracy opisujemy też dla sklepów w Bydgoszczy.
Najpierw sprawdź umowę: kto jest właścicielem modułów własnych i kto ma prawo do repozytorium. Jeśli zapisów nie ma, wyślij formalne żądanie wydania kopii kodu, bazy i dokumentacji z terminem.
Równolegle zabezpiecz dostępy do hostingu, domeny i DNS, jeśli należą do firmy. Brak takiej procedury na starcie to najczęstsza przyczyna kosztownego przepisywania sklepu od zera.
Jeśli chcesz porównać swój obecny zakres opieki z tym, co opisaliśmy, napisz do nas — powiemy wprost, czego brakuje w umowie i co warto poprawić. Zajmujemy się utrzymaniem sklepów PrestaShop i WooCommerce, integracjami oraz serwerami.