Utrzymanie i opieka techniczna sklepu internetowego w Krasnymstawie to stały, powtarzalny proces: monitoring, aktualizacje, kopie zapasowe, bezpieczeństwo, wydajność i wsparcie. Nie chodzi o jednorazową naprawę po awarii, ale o taką pracę, żeby do awarii w ogóle nie dochodziło — a jeśli już się zdarzy, żeby miała jasny czas reakcji. W tym artykule znajdziesz zakres zadań, realne poziomy SLA, widełki cenowe od 400 do ponad 3000 zł miesięcznie i checklistę audytu, którą wykonasz w 30 minut. Ogólne zasady opieki nad sklepami w regionie opisaliśmy też w artykule o utrzymaniu i opiece technicznej sklepów w Lublinie. Jeśli prowadzisz sklep w Krasnymstawie lub okolicach na PrestaShop albo WooCommerce, to jest lista rzeczy do ustalenia jeszcze przed podpisaniem umowy.
Utrzymanie i opieka techniczna sklepu internetowego to stały nadzór nad działającą witryną: monitoring dostępności, aktualizacje, kopie zapasowe, bezpieczeństwo, wydajność i wsparcie przy bieżących problemach. To nie jednorazowa naprawa po awarii, ale powtarzalny proces z listą zadań, terminami i osobą odpowiedzialną. Efekt dobrze prowadzonej opieki jest prosty: o awarii dowiadujesz się z alertu, a nie z telefonu od klienta, który nie mógł zapłacić za zamówienie.
Różnica względem modelu doraźnego („dzwonię, gdy się zepsuje”) jest zasadnicza. Doraźnie jest taniej w miesiącu bez zdarzeń, ale drożej w momencie awarii: płacisz za godziny w trybie pilnym, zwykle po stawce wyższej niż abonament, i stoisz w kolejce, bo nie masz umowy. Opieka odwraca logikę — płacisz z góry za utrzymanie stanu, w którym awarie są rzadsze, a gdy już wystąpią, masz zagwarantowany czas reakcji. Dodatkowo zostaje historia zmian: wiesz, co, kiedy i dlaczego zostało zmienione. Bez tego po pół roku nikt nie odtworzy, dlaczego przestał działać checkout.
W Krasnymstawie i powiecie krasnostawskim najczęściej trafiamy na dwa typy wdrożeń MŚP. Pierwszy to WooCommerce: sklep z kilkuset produktami, wtyczką płatności, dwoma kurierami i modułem faktur. Drugi to PrestaShop — często wersja 1.7, z kilkoma tysiącami SKU i modułami B2B, gdzie aktualizacja do 8.x wymaga wcześniejszego sprawdzenia zgodności modułów i override’ów, o czym pisze wprost dokumentacja deweloperska PrestaShop. Oba typy mają dokładnie te same słabe punkty: kopie bez testu odtworzenia, aktualizacje robione „na produkcji” i brak monitoringu.
Jak wygląda to od strony umowy i zapisów SLA w większych ośrodkach regionu, opisaliśmy w artykule o utrzymaniu i opiece technicznej sklepów w Lublinie.
| Podejście | Kiedy płacisz | Co dostajesz | Główne ryzyko |
|---|---|---|---|
| Doraźne naprawy | Po zdarzeniu, za godziny | Efekt naprawy, bez historii | Długi czas oczekiwania, brak kopii, brak SLA |
| Stała opieka techniczna | Miesięczny abonament | Monitoring, kopie, aktualizacje, wsparcie, raport | Konieczność wyboru realnego zakresu, nie najtańszego pakietu |
Zakres warto rozbić na siedem bloków, z których każdy ma inne narzędzie i inny rytm. Tylko wtedy w umowie da się zapisać konkretne zadania, a nie ogólne „zajmiemy się sklepem”.
xmlrpc.php.Rytm pracy jest powtarzalny: codziennie monitoring i kopie, tygodniowo przegląd logów błędów i nieudanych logowań, miesięcznie raport, aktualizacje i przegląd wtyczek pod kątem porzuconych projektów.
W PrestaShop dokładamy obsługę cache Smarty, kompilacji szablonu i konfliktów override’ów po aktualizacji modułu. W WooCommerce najczęstsza pułapka to konflikt wtyczki cache z koszykiem i płatnościami — po włączeniu cache trzeba przeklikać całą ścieżkę zakupu, od dodania produktu do potwierdzenia płatności. Drugie miejsce to wtyczki księgowe i fakturowe, które przy aktualizacji WooCommerce potrafią przestać wystawiać dokumenty.
Od czego zacząć porządkowanie takiego zakresu, opisaliśmy w artykule o utrzymaniu i opiece technicznej sklepów w Chełmie.
| Zadanie | Częstotliwość | Co konkretnie sprawdzamy |
|---|---|---|
| Monitoring dostępności | co 1–5 minut, alert 24/7 | kod HTTP, czas odpowiedzi, SSL, miejsce na dysku |
| Kopie zapasowe | codziennie | baza i pliki, zapis poza serwerem, test odtworzenia raz w miesiącu |
| Aktualizacje | miesięcznie, poprawki bezpieczeństwa szybciej | rdzeń, moduły/wtyczki, PHP, najpierw na kopii testowej |
| Przegląd logów | tygodniowo | błędy PHP, odpowiedzi 500/404, nieudane logowania |
| Wydajność | miesięcznie | LCP, INP, CLS, rozmiar obrazów, cache |
| Raport i kontakt | miesięcznie | lista zmian, dostępność, incydenty, rekomendacje |
SLA to zapisane w umowie terminy i wyłączenia. Bez niego „reagujemy szybko” znaczy zwykle „reagujemy, kiedy możemy”.
Dwie liczby trzeba rozdzielić. Czas reakcji to moment, w którym zgłoszenie zostaje przyjęte, potwierdzone i zaczyna się diagnoza — nie oznacza naprawy. Czas naprawy to przywrócenie działania lub wdrożenie obejścia (workaround), które pozwala sprzedawać, nawet jeśli poprawka docelowa przyjdzie później.
Priorytety ustala się opisowo, nie po nazwie, żeby uniknąć sporów: krytyczny to sklep niedostępny albo płatności odrzucane, wysokie to np. niedziałająca metoda dostawy lub błąd w koszyku, normalne to literówka, drobna zmiana CSS czy nowy banner.
Wyłączenia z SLA wpisuje się wprost. Standardowo: siła wyższa i awarie po stronie dostawcy infrastruktury, awarie elementów poza zakresem umowy (np. hosting klienta, którego nie obsługujemy), brak dostępu — haseł, panelu, DNS, oraz brak kontaktu po stronie klienta. Do tego zgłoszenia zewnętrzne: jeśli problem leży u operatora płatności, mierzymy czas reakcji, ale nie czas usunięcia.
Trzy szczegóły, które warto dopisać: kanał zgłoszeń (mail do krytycznych plus telefon), godziny wsparcia (8:00–18:00 w dni robocze czy 24/7 — to zwykle różnica kilkuset złotych w abonamencie) oraz stawka godzinowa za prace poza pakietem, żeby nie było niespodzianek na fakturze.
Jak wyglądają zapisy SLA w praktyce, pokazujemy w artykule o utrzymaniu i opiece technicznej sklepów w Hrubieszowie.
| Priorytet | Przykład zdarzenia | Czas reakcji (przykład) | Cel naprawy |
|---|---|---|---|
| Krytyczny | sklep nie działa, płatności odrzucane | 1 h w godzinach wsparcia | 4–8 h |
| Wysoki | nie działa metoda dostawy, błąd w koszyku | 4 h | 1 dzień roboczy |
| Normalny | literówka, drobna zmiana wyglądu | 1 dzień roboczy | 3–5 dni roboczych |
Nie ma jednej ceny za utrzymanie sklepu. W Krasnymstawie i okolicy najczęściej spotykamy trzy progi — wynikają one z liczby modułów, integracji i wymaganego czasu reakcji, a nie z nazwy miejscowości.
Prace poza pakietem rozliczamy godzinowo: 120–150 zł/h za standard (aktualizacje, konfiguracja, poprawki w szablonie) i 180–250 zł/h za specjalizację (integracje API, optymalizacja wydajności, migracje, odzyskiwanie danych po awarii). Stawka rośnie wraz z tym, ile ryzyka bierzemy na siebie.
Na cenę wpływa pięć rzeczy: liczba modułów i wtyczek (każda to potencjalny konflikt i osobny test po aktualizacji), integracje (ERP, magazyn, księgowość, kurierzy), ruch i liczba zamówień, liczba osób z dostępem do panelu oraz deklarowany czas reakcji.
Model, który się sprawdza: pakiet godzin (np. 5 h/mies.) + monitoring + krótki raport raz w miesiącu. W umowie zapisz, czy niewykorzystane godziny przechodzą na kolejny okres i co dokładnie jest poza pakietem. Unikaj zapisów „nielimitowane wsparcie” bez SLA — w praktyce oznacza to kolejkę, nie szybkość. Jak konstruować takie zapisy, opisujemy przy okazji umowy o utrzymanie sklepu i poziomów SLA (Lublin).
Ten audyt wykonasz bez programisty. Potrzebujesz 30 minut, kartki i dostępu do panelu hostingu oraz administracji sklepu. Każdy punkt oceniaj jako: OK / do sprawdzenia / czerwona flaga.
Interpretacja jest prosta. Jedna czerwona flaga lub dwa punkty „do sprawdzenia” — zaplanuj naprawę w tym tygodniu. Brak kopii poza serwerem w połączeniu z przestarzałym PHP w sklepie przyjmującym płatności — wzywaj pomoc od razu. Jak wygląda to w mniejszych sklepach, pokazaliśmy w materiale o utrzymaniu i opiece technicznej sklepów w Biłgoraju.
| Wynik audytu | Co robić | Termin |
|---|---|---|
| 0 czerwonych flag, 0–1 punkt do sprawdzenia | Utrzymuj rytm: aktualizacje i kopie zgodnie z harmonogramem | Bieżąco |
| 1–2 czerwone flagi | Zaplanuj naprawę i wdrożenie monitoringu | Do 7 dni |
| 3+ czerwone flagi lub brak kopii przy płatnościach online | Wstrzymaj prace rozwojowe, wezwij pomoc techniczną | Natychmiast |
Większość awarii to nie atak hakerski, a powtarzalne sytuacje: nieudana aktualizacja, konflikt wtyczki, wygasły token API, przepełniona baza. Oto co widzimy najczęściej.
Procedura eskalacji powinna być spisana, nie wymyślana w panice: zgłoszenie z opisem (co, kiedy, krok odtworzenia, URL), priorytet (P1 — sklep nie sprzedaje, P2 — działa część funkcji, P3 — kosmetyka), dostępy przekazane przez menedżer haseł oraz ustalona częstotliwość informowania o postępie. Przykład takich zapisów zebraliśmy przy okazji poziomów SLA dla sklepów w Hrubieszowie.
Kopie to nie detal. Kopia przed każdą aktualizacją, kopia poza serwerem, test przywrócenia raz na kwartał i ustalone RTO/RPO — po jakim czasie sklep wraca do działania i ile zamówień możemy stracić. Bez tego każda awaria to odtwarzanie sklepu z pamięci.
Zacznij od trzech sygnałów. Pierwszy: w firmie nie ma nikogo, kto na co dzień dotyka serwera, bazy i modułów sklepu. Drugi: w ostatnim kwartale były co najmniej trzy przestoje dłuższe niż 2 godziny albo zdarzyło się, że klient nie mógł złożyć zamówienia. Trzeci: planujesz rozwój — nowe integracje, zmiany w koszyku, wdrożenie płatności. Jeśli występuje choć jeden z nich, doraźne naprawianie po fakcie kosztuje więcej niż stała opieka. Każda godzina przestoju to stracone zamówienia i telefon od klienta, który zapłacił, a nie dostał potwierdzenia.
Policz realnie. Etat to 8–15 tys. zł miesięcznie brutto w przypadku seniora, który zna PrestaShop lub WooCommerce i utrzyma serwer. Tyle że etat ma urlopy, zwolnienia L4 i jednoosobową wiedzę, która nie jest nigdzie zapisana. Freelancer za 300–1500 zł miesięcznie wykona aktualizacje, ale zwykle bez pisemnego SLA — jak zachoruje, zgłoszenie czeka. Agencja z zespołem wycenia się na 400–3000+ zł miesięcznie w zależności od liczby modułów, integracji i godzin wsparcia, ale ma procedury i zastępstwo. Zasady umowy SLA i czasy reakcji opisaliśmy szerzej w tekście o utrzymaniu i opiece technicznej sklepów Lublin.
Trzeci model — brak SLA i jedna osoba „od wszystkiego” — jest najtańszy do pierwszej awarii. Potem okazuje się, że nikt nie wie, gdzie są kopie, kiedy ostatnio aktualizowano PHP i kto ma hasło do panelu hostingu.
| Model | Koszt miesięczny | SLA | Główne ryzyko |
|---|---|---|---|
| Etat in-house | 8 000–15 000 zł brutto | brak formalnego, zależy od jednej osoby | urlop, L4, wypalenie, brak zastępstwa |
| Freelancer | 300–1 500 zł | zwykle brak lub ustne „postaram się szybko” | jedna para rąk, wiedza nieudokumentowana |
| Agencja | 400–3 000+ zł | zapisane czasy reakcji i naprawy, zastępstwo w zespole | wyższy koszt przy szerokim zakresie |
Jedna rozmowa telefoniczna wystarczy, żeby odsiać amatorów. Zadaj te pytania i zapisz odpowiedzi. Jeśli ktoś odpowiada ogólnikami („będziemy dbać”), to znaczy, że opieka będzie reagowaniem na awarie, a nie pracą, która ma do nich nie dopuścić.
Dopytać warto o PrestaShop i WooCommerce oraz o integracje z ERP (Subiekt, Comarch) i kurierami (InPost, DPD). To miejsca, w których najczęściej sypią się zamówienia. Podobne kryteria wyboru — i pułapki — opisaliśmy w artykule o utrzymaniu i opiece technicznej sklepów Narol – SLA i pakiety.
Start opieki nie polega na podpisaniu umowy i czekaniu. Ma sześć etapów i zajmuje realnie 3–7 dni roboczych od momentu przekazania dostępów.
Co dostaje klient: listę zadań, potwierdzone czasy reakcji, kontakt do konkretnego dewelopera (nie do ogólnej skrzynki) i raport miesięczny. Kolejność kroków i zakres pakietów rozpisaliśmy też w tekście o utrzymaniu i opiece technicznej sklepów Bełżec. Pułapka: zaczynanie od aktualizacji bez kopii i bez baseline. Zawsze najpierw kopia, potem zmiana.
Wybór najtańszej oferty bez zapisów SLA
Jak wykryć: W umowie nie ma czasów reakcji ani priorytetów — jest tylko kwota miesięczna i ogólne słowo „wsparcie”.
Jak naprawić: Poproś o tabelę SLA: priorytet krytyczny, wysoki i normalny, czas reakcji, czas naprawy oraz godziny, w których wsparcie faktycznie działa.
Kopie zapasowe, których nikt nigdy nie sprawdził
Jak wykryć: Nie wiesz, kiedy powstała ostatnia kopia i gdzie jest trzymana. Kopia na tym samym serwerze co sklep to nie kopia.
Jak naprawić: Ustal kopię co najmniej raz dziennie poza serwer produkcyjny i test odtworzenia raz na kwartał — z zapisem w raporcie.
Aktualizacje przekładane, „bo sklep działa”
Jak wykryć: Wersja PrestaShop, WooCommerce, WordPressa i modułów jest starsza niż 6–12 miesięcy; brak środowiska testowego.
Jak naprawić: Aktualizuj partiami: najpierw staging, test koszyka i płatności, potem produkcja w oknie niskiego ruchu.
Traktowanie opieki jak jednorazowej naprawy
Jak wykryć: Płacisz tylko wtedy, gdy coś padnie. Nie ma monitoringu, logów ani raportu z wykonanych prac.
Jak naprawić: Przejdź na pakiet miesięczny: monitoring, aktualizacje, kopie, bezpieczeństwo i raport, plus pula godzin na prace poza pakietem.
Testowanie zmian bezpośrednio na produkcji
Jak wykryć: Nowy moduł, zmiana szablonu czy reguła wysyłki są widoczne dla klientów natychmiast po wgraniu.
Jak naprawić: Osobne środowisko staging z kopią bazy. Wdrożenie dopiero po teście zamówienia, płatności i e-maili transakcyjnych.
Brak przekazanych dostępów do hostingu, FTP i panelu sklepu
Jak wykryć: Przy awarii wykonawca czeka na dane kilka godzin, a Ty nie masz kopii dostępów u siebie.
Jak naprawić: Zrób listę dostępów w menedżerze haseł, przekaż ją przy podpisywaniu umowy i aktualizuj przy każdej zmianie hasła.
Opieka techniczna nad sklepem w Krasnymstawie to pakiet stałych zadań z jasnym rytmem: codzienny monitoring i kopie, tygodniowy przegląd logów, miesięczny raport i aktualizacje. Sensowne SLA to 1 godzina reakcji przy awarii krytycznej, 4 godziny przy wysokim priorytecie i 1 dzień roboczy przy normalnym zgłoszeniu. Realne koszty mieszczą się w przedziale 400–1200 zł miesięcznie dla małego sklepu, 1200–3000 zł dla średniego i powyżej 3000 zł dla rozbudowanego. Zacznij od 30-minutowej checklisty — jeśli wypadnie kilka czerwonych flag, rozmowa o pakiecie i tak będzie tańsza niż pierwsza poważna awaria.
Naprawa awarii to reakcja po fakcie: sklep nie działa, płacisz za przywrócenie i liczysz utracone zamówienia. Opieka techniczna to praca wyprzedzająca — monitoring, aktualizacje, kopie i przegląd logów sprawiają, że część problemów nigdy nie trafia do klientów. Różnica jest też w rozliczeniu: pakiet miesięczny daje przewidywalny koszt, a model „płać za awarię” jest nieprzewidywalny i zwykle droższy w skali roku.
Standardowo: monitoring dostępności, aktualizacje sklepu i modułów lub wtyczek, kopie zapasowe z testem odtworzenia, podstawowe bezpieczeństwo, przegląd wydajności, poprawki błędów oraz wsparcie w konfiguracji. Rytm pracy bywa taki: codziennie monitoring i kopie, co tydzień przegląd logów, raz w miesiącu raport i okno aktualizacyjne. Zakres dla PrestaShop i WooCommerce różni się szczegółami — w PrestaShop większą uwagę przykłada się do modułów i szablonu, w WooCommerce do wtyczek i konfliktów z motywem.
Spotykane, sensowne poziomy to 1 godzina na reakcję przy awarii krytycznej (sklep nie działa, nie przyjmuje zamówień), 4 godziny przy priorytecie wysokim i 1 dzień roboczy przy normalnym zgłoszeniu. Ważne, żeby odróżniać czas reakcji od czasu naprawy — pierwszy to potwierdzenie, że ktoś się zajął sprawą, drugi zależy od przyczyny. Z SLA wyłącza się siłę wyższą, awarie po stronie klienta i brak dostępu do paneli.
Realne widełki miesięczne: 400–1200 zł dla małego sklepu z kilkoma modułami, 1200–3000 zł dla średniego z integracjami i większym ruchem, 3000 zł i więcej dla rozbudowanego wdrożenia z ERP, wieloma stanowiskami i krótkim SLA. Prace poza pakietem rozlicza się godzinowo, zwykle 120–250 zł/h zależnie od specjalizacji. Porównanie podejść do wyceny w innym mieście regionu opisaliśmy w artykule o utrzymaniu i opiece technicznej sklepów w Chełmie.
Czerwone flagi to: sklep zwraca błąd 500 lub biały ekran, koszyk gubi produkty, płatności albo etykiety InPost/DPD/DHL przestały działać, kopia zapasowa jest starsza niż tydzień, a w logach PHP sypie się ten sam błąd setki razy dziennie. Nie czekaj, aż klienci sami zgłoszą problem — pierwsze zgłoszenie od klienta to zwykle kilka godzin przestoju. Zasady reakcji na podobne sytuacje opiszliśmy w materiale o SLA dla sklepów w Hrubieszowie.
Nie. Opieka techniczna działa zarówno dla PrestaShop, jak i WooCommerce, a także dla sklepów mocno zmodyfikowanych wtyczkami lub własnym kodem. Przy pierwszym kontakcie warto pokazać listę modułów i integracji, bo to ona najbardziej wpływa na zakres prac i cenę. Jeśli sklep działa na nietypowym rozwiązaniu, trzeba to powiedzieć wprost — czasem uczciwszą odpowiedzią jest audyt i migracja, a nie pakiet opieki.
Zwykle zaczyna się od audytu i inwentaryzacji: wersje, moduły, kopie, dostępy, logi. Potem ustalamy zakres pakietu i SLA, a dopiero na końcu podpisujemy umowę z konkretną datą startu. Największe ryzyko to brak przekazanych dostępów i dokumentacji — dlatego warto ustalić to na piśmie jeszcze przed zakończeniem współpracy z poprzednim wykonawcą. Przykładowy zakres pierwszych tygodni opisaliśmy w artykule o utrzymaniu i opiece technicznej sklepów w Biłgoraju.
Jeśli chcesz sprawdzić, jak wyglądałby pakiet opieki dla Twojego sklepu, napisz do nas — bez zobowiązań przejrzymy wersje, kopie i logi. Powiemy wprost, co wymaga naprawy od razu, a co może poczekać.