Utrzymanie i opieka techniczna sklepu w Hrubieszowie to nie jedna usługa, a trzy obszary: serwer, sama aplikacja sklepu (PrestaShop albo WooCommerce) i ciągły rozwój. Jeśli dostawca nie rozdziela ich w umowie, po pół roku nie ustalisz, co właściwie zrobił za abonament, a co powinno być osobnym zleceniem. Ten tekst porządkuje temat od strony umowy i organizacji pracy: co podpisać, o co zapytać i co miesiąc sprawdzać. Konkretne widełki cenowe i pełny zakres pakietu znajdziesz w pozostałych sekcjach artykułu.
Najczęstszy spór o umowę na sklep w Hrubieszowie nie dotyczy ceny, tylko zakresu. Klient słyszy „opieka techniczna” i zakłada, że wszystko jest w środku. Dostawca ma w głowie aktualizację modułów. Po pierwszej awarii bazy okazuje się, że kopie robił hosting, a nikt ich nigdy nie odtwarzał. Zakres trzeba więc rozbić na trzy filary i każdy opisać w umowie osobno.
SLA bez żargonu. To zapis, co się dzieje, gdy sklep padnie: jak szybko ktoś odbierze zgłoszenie (czas reakcji), jak szybko zacznie naprawiać i co uznajemy za awarię krytyczną. Uptime to procent czasu, w którym sklep odpowiada — 99,5% w miesiącu to do około 3,6 godziny przestoju, 99,9% to około 43 minut. Pułapka numer jeden: „reakcja w 15 minut” nie znaczy „naprawa w 15 minut”. Reakcja to potwierdzenie zgłoszenia, naprawa to osobny parametr, którego w umowach często nie ma. Ustal też, czy SLA obowiązuje 24/7, czy tylko w dni robocze 8:00–16:00 — ta różnica potrafi zmienić koszt pakietu o kilkadziesiąt procent.
Przykład: PrestaShop 1.7.x → 8.x. W ramach utrzymania robi się aktualizacje modułów kompatybilnych z nową gałęzią, test na kopii sklepu, wykonanie i weryfikację backupu oraz poprawki błędów PHP po wdrożeniu. Osobnym zleceniem rozwojowym jest przepisanie szablonu pod nowy theme, przerobienie modułów własnych, migracja kilku tysięcy produktów i zdjęć oraz testy regresji koszyka i płatności — w praktyce 20–60 roboczogodzin. Jeśli dostawca wrzuca to do abonamentu za 500 zł, to albo tego nie zrobi, albo zrobi byle jak. Zgodność modułów z wersjami sprawdzisz w dokumentacji deweloperskiej PrestaShop.
| Filar | Co obejmuje | Jak to rozliczać |
|---|---|---|
| Utrzymanie serwera / VPS | Dostępność, zasoby CPU/RAM/dysk, kopie zapasowe, SSL, firewall, wersje PHP i MySQL, monitoring | W abonamencie |
| Utrzymanie aplikacji (PrestaShop / WooCommerce) | Aktualizacje core i modułów, poprawki błędów, wydajność, bezpieczeństwo, integralność bazy | W abonamencie |
| Rozwój i drobne moduły | Nowe funkcje, integracje, zmiany szablonu, optymalizacja konwersji, migracje wersji | Osobne zlecenie, rozliczane godzinowo |
Poniższa lista to prace wykonywane cyklicznie. Jeśli w ofercie nie ma częstotliwości, przyjmij, że ich nie ma.
Integracje. InPost (ShipX API): geowidget z listą paczkomatów, limity wagi i gabarytów, zmiany cennika. DPD (WebAPI, Pickup): etykiety i godziny odbioru. DHL: etykiety, wysyłki zagraniczne. Przelewy24, PayU, tpay: wersje SDK, obsługa 3DS2, notyfikacje webhook, testy zwrotów i płatności odrzuconych. Każda zmiana po stronie operatora wymaga testu na sandboxie i na produkcji — zwykle 1–2 godziny.
Monitoring obejmuje uptime (sklep, panel, API płatności), ważność SSL, PHP error log i czas odpowiedzi serwera. Bez pomiaru co minutę awaria trwająca pół godziny przechodzi niezauważona. Podobny zakres prac opisujemy przy sklepach z sąsiednich miejscowości, np. w materiale o utrzymaniu i opiece technicznej sklepów Józefów.
| Zakres stały (abonament) | Zakres rozliczany godzinowo |
|---|---|
| Monitoring, kopie zapasowe i test odtworzenia | Nowe funkcje i moduły własne |
| Aktualizacje bezpieczeństwa, przegląd logów | Migracje wersji (np. PrestaShop 1.7 → 8.x) |
| Test zamówienia i płatności, raport miesięczny | Integracje ERP i systemów magazynowych |
| Drobne poprawki do 1 h miesięcznie | Zmiany szablonu, optymalizacja wydajności, przenosiny hostingu |
Ceny netto w abonamencie miesięcznym zależą przede wszystkim od liczby zamówień i liczby integracji, nie od wielkości miejscowości.
Stawka godzinowa za prace poza abonamentem: freelancer 80–150 zł/h, agencja 120–250 zł/h, prace specjalistyczne (migracje, ERP, optymalizacja wydajności) 200–350 zł/h.
Kiedy koszt rośnie. Migracja PrestaShop 1.7 → 8.x to 20–60 godzin. Integracja z Subiektem, WF-Magiem czy Optimą to 60–150 godzin i późniejsze utrzymanie tej integracji. Sezon to osobna historia: przed Black Friday i Bożym Narodzeniem monitoring schodzi do pomiaru co minutę, dochodzi dyżur w weekendy i zamrażanie wdrożeń na 3–5 dni przed szczytem — abonament rośnie wtedy o 30–50% na 1–2 miesiące.
Wycena z godzin, nie z sufitu. Przykładowe 8 godzin pracy w miesiącu: 1 h na analizę logów i wdrożenie poprawek po aktualizacji modułu, 2 h na migrację z PHP 7.4 na 8.1 z testami, 1 h na poprawkę modułu płatności po zmianie API operatora, 1,5 h na konfigurację nowej metody dostawy i testy etykiet, 2,5 h na optymalizację indeksów bazy po wzroście katalogu. Przy 180 zł/h daje to 1 440 zł netto. Taki zapis w ofercie da się sprawdzić punkt po punkcie, a „pakiet 3 000 zł” nie. Podobne widełki stosujemy przy wycenach dla sklepów w Krasnobrodzie i w całym regionie.
| Typ sklepu | Zamówienia / mies. | Abonament netto | Orientacyjny czas pracy |
|---|---|---|---|
| Mały sklep | ~50 | 350–800 zł | 4–6 h |
| Średni sklep | ~500 | 900–2 500 zł | 8–15 h |
| Sklep z ERP / duży katalog | 2 000+ | 2 500–6 000 zł | 20–40 h |
| Sam serwer / VPS, bez aplikacji | — | 150–400 zł | 1–3 h |
Umowa SLA to dokument, który rozstrzyga spór wtedy, gdy sklep nie przyjmuje zamówień w piątek o 21:00. Zanim ją podpiszesz, poproś o sześć konkretów. Każdy powinien być liczbą, nie przymiotnikiem.
1. Czas reakcji (response time). Ile trwa potwierdzenie przyjęcia zgłoszenia. Realne wartości: 1 godzina w godzinach 8:00–16:00, 4 godziny poza nimi. Reakcja nie oznacza naprawy — może to być wiadomość „przyjęliśmy zgłoszenie, pracujemy”.
2. Czas naprawy (resolution time). Do kiedy problem ma być usunięty albo wdrożone obejście (workaround). Zapisz to osobno dla priorytetów: P1 (brak możliwości złożenia zamówienia lub płatności) — np. 4 godziny; P2 (błąd w karcie jednego produktu) — 3 dni robocze. Jeden wspólny parametr dla wszystkiego to najczęstszy błąd w umowach.
3. Kanały zgłoszeń i godziny wsparcia. 8x5 (poniedziałek–piątek, 8:00–16:00) to standard w abonamencie. 24x7 to osobny dyżur i zwykle 2–3x wyższa stawka bazowa, bo ktoś musi mieć włączony telefon w nocy. Uważaj na zapis „monitoring 24/7, reakcja w godzinach pracy” — to nadal 8x5.
4. Kary umowne / rekompensaty. Bez nich SLA jest deklaracją. Typowy mechanizm: 5–10% miesięcznego abonamentu za każde przekroczenie, z limitem np. 50% opłaty. Jeśli w umowie nie ma słów „kara”, „rekompensata” albo „service credit” — nie ma czego egzekwować.
5. Zakres i wyłączenia. Lista prac, które są osobnym zleceniem: zmiana szablonu, nowa integracja z kurierem, migracja, przebudowa koszyka. Bez tej listy po pół roku nie ustalisz, co dostawca zrobił w abonamencie, a co powinno mieć osobną wycenę.
6. Raportowanie. Miesięczny raport z uptime, czasami reakcji i listą wykonanych prac oraz dostęp do monitoringu (np. UptimeRobot, status page). Raport, którego nie widzisz, nie istnieje.
Pytanie kontrolne na koniec rozmowy: „Kto odbiera zgłoszenie o 22:00 w piątek i jak mam się do niego dodzwonić?” Jeśli odpowiedź brzmi „formularz kontaktowy”, masz 8x5 — niezależnie od nagłówka umowy. Sposób rozbicia prac i pakietów na godziny pokazujemy też przy okazji utrzymania i opieki technicznej sklepów w Biłgoraju.
| Parametr | Co wpisać do umowy | Typowa wartość |
|---|---|---|
| Czas reakcji (P1) | potwierdzenie przyjęcia zgłoszenia | 1 h w 8:00–16:00, 4 h poza |
| Czas naprawy (P1) | przywrócenie sprzedaży lub obejście | 4 h robocze |
| Godziny wsparcia | 8x5 albo 24x7 — z ceną | 8x5 w abonamencie, 24x7 z dopłatą 2–3x |
| Kary umowne | % abonamentu za przekroczenie | 5–10%, limit 50% opłaty |
| Wyłączenia | prace poza abonamentem | nowe funkcje, migracja, szablon |
| Raportowanie | raport miesięczny + dostęp do monitoringu | uptime, czasy reakcji, lista prac |
Ta lista działa bez znajomości PHP i SSH. Dwanaście punktów, każde z kryterium OK/zła i miejscem sprawdzenia. Przejście zajmuje 20–30 minut raz w miesiącu.
| # | Punkt kontrolny | Kryterium | Gdzie sprawdzić |
|---|---|---|---|
| 1 | Czas odpowiedzi serwera | TTFB poniżej 500 ms | Pingdom, GTmetrix lub panel hostingu → statystyki wydajności |
| 2 | Certyfikat SSL | Ważny dłużej niż 30 dni, brak ostrzeżeń | Panel hostingu → SSL; kliknij kłódkę w przeglądarce |
| 3 | Kopia zapasowa | Ostatnia kopia młodsza niż 24 h | Panel hostingu lub panel dostawcy backupu |
| 4 | Wersja PHP i logi | Wersja wspierana (8.1–8.3), zero błędów fatalnych | Hosting → wersja PHP; PrestaShop: Zaawansowane → Logi; WooCommerce: Status → Logi |
| 5 | Miejsce na dysku i baza | Zajęte poniżej 80% limitu | Panel hostingu → użycie dysku i MySQL |
| 6 | Testowe zamówienie | Zamówienie za 1 zł przechodzi całą ścieżkę | Sklep → koszyk → płatność → potwierdzenie; tryb testowy bramki |
| 7 | Zamówienia bez statusu | Zero „oczekuje na płatność” starszych niż 48 h | Panel sklepu → Zamówienia, filtr po statusie i dacie |
| 8 | E-maile transakcyjne | Potwierdzenie dochodzi w 2 minuty, nie do spamu | Test na własną skrzynkę, SPF/DKIM, np. mail-tester.com |
| 9 | Search Console | Zero nowych błędów krytycznych indeksowania | GSC → Indeksowanie stron → Raporty |
| 10 | Core Web Vitals | LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 | GSC → Core Web Vitals lub PageSpeed Insights |
| 11 | Aktualizacje | Każda przeszła najpierw na kopii testowej | Raport miesięczny od dostawcy + pytanie o staging |
| 12 | Błędy JS w koszyku | Konsola bez czerwonych błędów na koszyku i płatności | F12 → Console na stronie koszyka i płatności |
Gdy punkt wypada źle, kolejność dzwonienia jest zawsze taka sama.
1. Sprawdź u siebie. Otwórz sklep na telefonie w LTE, nie po Wi-Fi. Jeśli tam działa, problem jest lokalny — przeglądarka, cache, VPN.
2. Zgłoś w kanale P1. Jeśli koszyk albo płatność nie działają dla wszystkich, dzwonisz, nie piszesz maila. Zapisz godzinę zgłoszenia — to podstawa rekompensaty z SLA.
3. Brak odpowiedzi w czasie reakcji? Dzwonisz do hostingu, jeśli podejrzewasz serwer (500, brak odpowiedzi, wygasły SSL), i równolegle wysyłasz maila z tematem „P1 – brak reakcji”.
4. Reszta czeka na zgłoszenie mailowe. Wolna podstrona, literówka, brakujący opis — nie telefon w nocy.
Dla punktów 1 i 10 punktem odniesienia są progi zdefiniowane przez Google: Web Vitals — dokładnie te same wartości widzisz w Search Console, więc nie musisz nic liczyć samodzielnie.
Te pięć sygnałów sprawdzisz przed podpisaniem umowy, nie po roku współpracy. Każdy z nich ma konkretne pytanie weryfikacyjne.
1. Brak dostępu do repozytorium i kodu modułów własnych. Objaw: moduły wgrywane przez FTP, odpowiedź „kod jest u nas na serwerze”. Pytanie: „Gdzie jest repozytorium i czy po zakończeniu umowy dostanę ostatnią wersję kodu z historią zmian?”. Jeśli nie — przy zmianie wykonawcy zaczynasz od zera, a przepisanie modułu do koszyka czy integracji z kurierem to często kilka tysięcy złotych.
2. Obietnice bez miernika: SLA bez kar umownych plus uptime „99,9%” bez podanego monitoringu. Pytanie: „Czym mierzycie uptime, za jaki okres i gdzie zobaczę historię?”. Bez status page i bez raportu to liczba z oferty, nie z serwera.
3. Płatne wtyczki mnożone zamiast jednego modułu z kodem. Siedem wtyczek po 100–200 zł rocznie to 700–1400 zł i siedem źródeł aktualizacji, z których część dubluje funkcje. Alternatywa: jeden moduł na zamówienie, do którego masz prawa i który nie zniknie, gdy autor wtyczki porzuci projekt — na PrestaShop to typowa sytuacja po 2–3 latach.
4. Pośrednicy bez kontaktu z deweloperem. Objaw: pytanie techniczne idzie przez handlowca i wraca po trzech dniach. Pytanie: „Czy mogę porozmawiać z osobą, która robi wdrożenie?”.
5. Faktura bez rozbicia na godziny i zakres. Wiesz, ile płacisz, ale nie za co. Żądaj miesięcznego zestawienia: ile godzin poszło na wsparcie, ile na rozwój, ile na zadania jednorazowe.
Czerwona flaga nie zawsze oznacza „uciekaj”. Oznacza „dopytaj i wpisz odpowiedź do umowy”. Sposób, w jaki sami przypisujemy zadania do abonamentu, opisujemy przy okazji utrzymania i opieki technicznej sklepów we Frampolu.
| Flaga | Jak wygląda w praktyce | Pytanie weryfikacyjne |
|---|---|---|
| Brak repozytorium | moduły tylko przez FTP, brak historii zmian | Gdzie jest repo i czy dostanę kod po zakończeniu umowy? |
| Obietnice bez miernika | SLA bez kar, uptime 99,9% bez monitoringu | Czym mierzycie uptime i gdzie widzę historię? |
| Mnożenie wtyczek | kilka płatnych wtyczek zamiast jednego modułu | Czy moduł jest mój i czy mam do niego kod? |
| Pośrednik | pytania techniczne idą przez handlowca | Czy mogę rozmawiać z deweloperem wdrożenia? |
| Faktura bez rozbicia | jedna kwota „opieka techniczna” | Poproszę zestawienie godzin wg zadań |
Hrubieszów leży w powiecie hrubieszowskim, około 50 km od Zamościa. Ta odległość realnie wpływa na model wsparcia. Codzienna praca idzie zdalnie — zdalny pulpit, SSH, panel hostingu, zgłoszenia mailem. Dojazd na miejsce to 50–60 minut w jedną stronę, więc jeśli dostawca obiecuje „wizytę w godzinę”, prawdopodobnie nie sprawdził, gdzie leży Hrubieszów.
W umowie SLA zapisz dwie liczby: ile wizyt na miejscu wchodzi w abonament (typowo jedna na miesiąc) i jaki jest czas reakcji, gdy sprawa wymaga fizycznej obecności — serwer w szafie w biurze, padnięty dysk, podmiana routera, drukarka etykiet Zebra, konfiguracja terminala płatniczego. Bez tego zapisu każdy wyjazd staje się osobnym zleceniem rozliczanym godzinowo plus czas dojazdu.
Profil sklepów w regionie jest konkretny: rolno-spożywcze (pasze, nawozy, nasiona, środki ochrony roślin), chemia i drogeria, części rolnicze i do maszyn, odzież robocza i BHP. To inna specyfika niż moda czy elektronika:
Do tego kurierzy: mniej punktów obsługi i jedna godzina odbioru w ciągu dnia. Cutoff (np. 13:00) warto wpisać na stronie i w mailu potwierdzającym, bo to najczęstszy powód telefonów „czy dotrze na jutro”. Ciężkie zdjęcia produktowe i rozbudowane karty bolą podwójnie na telefonach w słabszym zasięgu — warto pilnować parametrów opisanych w Web Vitals, bo LCP i INP przekładają się na realne porzucenia koszyka.
Zakres dla sąsiednich gmin opisaliśmy osobno: utrzymanie i opieka techniczna sklepów w Narolu, opieka techniczna sklepów w Bełżcu, a także Biłgoraj, Frampol, Krasnobród i Józefów.
| Typ sklepu w regionie | Co sprawdzić przed podpisaniem abonamentu |
|---|---|
| Rolno-spożywczy (pasze, nawozy, nasiona) | Reguły wysyłki palet, jednostki tona/litr, synchronizacja stanów z Subiektem, harmonogram prac poza sezonem wiosennym |
| Chemia i drogeria | Ograniczenia wysyłki niektórych produktów, grupy cenowe B2B, poprawność opisów i kart charakterystyki |
| Części rolnicze i do maszyn | Duża liczba wariantów i numerów katalogowych, wyszukiwarka po numerze OEM, stany magazynowe dzień do przodu |
| Odzież robocza i BHP | Rozmiary i rozmiarówki, zwroty i wymiany, atrybuty zbiorcze (opakowanie 10 par), zdjęcia w rozdzielczości mobilnej |
Przejście z wdrożenia pod opiekę nie powinno być skokiem w nieznane. Robimy to w trzech krokach i zwykle całość zamyka się w 10 dniach roboczych.
1. Audyt (1–2 dni robocze). Sprawdzamy wersję PrestaShop lub WooCommerce, wersję PHP, liczbę modułów i wtyczek (także wyłączonych — dalej siedzą w bazie), nadpisania w katalogu /override/, rozmiar bazy, stan kopii zapasowych, logi błędów PHP, TTFB i Core Web Vitals z Google Search Console. Kończymy raportem z listą usterek podzieloną na „napraw teraz”, „do planu na kwartał” i „nie ruszać”. Wspierane gałęzie wersji sprawdzamy w dokumentacji dla deweloperów PrestaShop, a nie na forach.
2. Plan i wycena. Audyt zamienia się w listę prac z liczbą godzin. Ustalamy pakiet godzinowy (np. 5, 10 albo 20 godzin miesięcznie na rozwój) i stawkę za prace poza pakietem. W umowie rozdzielamy wprost: co jest w abonamencie (monitoring, kopie, aktualizacje bezpieczeństwa, reakcja na awarię), a co jest osobnym zleceniem (nowa funkcja, migracja, integracja z ERP, optymalizacja kampanii).
3. Uruchomienie monitoringu (do 5 dni roboczych). Zewnętrzny monitoring dostępności z interwałem 60 sekund, monitoring błędów PHP, alerty na maila i SMS, dostępy do panelu hostingu i strefy DNS, zamówienie testowe z pełną ścieżką płatności i fakturą.
Pierwszy tydzień opieki to stały zestaw czynności:
Kiedy opieka nie jest potrzebna. Sklep z mniej niż 20 zamówieniami miesięcznie, bez planów rozwoju, bez integracji i bez danych klientów w panelu nie potrzebuje abonamentu SLA. Wystarczy przyzwoity hosting z kopiami po stronie dostawcy i jedna aktualizacja na kwartał. Abonament za 300–600 zł miesięcznie w takiej sytuacji nic nie daje, jeśli godzina przestoju nie kosztuje Cię realnych pieniędzy. Ten sam schemat sprawdzamy w utrzymaniu i opiece technicznej sklepów w Biłgoraju.
| Krok | Czas | Efekt na koniec kroku |
|---|---|---|
| Audyt sklepu | 1–2 dni robocze | Raport z usterkami i ryzykami, lista prac z podziałem na priorytety |
| Plan i wycena | 1–3 dni robocze | Pakiet godzin, stawka, podział na abonament i osobne zlecenia |
| Monitoring i pierwszy tydzień opieki | do 5 dni roboczych | Alerty, kopie zapasowe z testem odtworzenia, hardening, baseline wydajności |
Podpisanie umowy na opiekę bez listy czynności i częstotliwości ich wykonania. Klient płaci abonament, ale nie wie, czy dostawca w tym miesiącu zrobił cokolwiek poza aktualizacją, która i tak wyszła sama z panelu.
Jak wykryć: Przeczytaj umowę i załącznik zakresowy. Jeśli nie ma tam tabeli: czynność, częstotliwość, kto wykonuje, to znaczy, że zakres jest umownie otwarty na interpretację dostawcy.
Jak naprawić: Poproś o załącznik z listą prac cyklicznych (tygodniowych i miesięcznych) oraz o raport miesięczny z potwierdzeniem wykonania. Bez raportu nie ma czego rozliczać.
Brak dostępu do serwera, repozytorium i kodu modułów własnych. Klient zostaje z abonamentem i bez możliwości zmiany wykonawcy bez zaczynania od zera.
Jak wykryć: Zapytaj wprost: czy po zakończeniu współpracy dostanę kopię modułów własnych i dostęp do repozytorium. Wymijająca odpowiedź to sygnał ostrzegawczy.
Jak naprawić: Ustal to w umowie jako punkt: dostępy i kod są przekazywane w ciągu 5 dni roboczych od zakończenia współpracy, także przy sporze o faktury.
Aktualizacje i poprawki robione bezpośrednio na działającym sklepie, bez kopii i bez środowiska testowego. Jedna nieudana aktualizacja potrafi wyłączyć sprzedaż na kilka godzin w środku dnia.
Jak wykryć: Sprawdź, czy przed ostatnią aktualizacją dostałeś informację o terminie i czy była zrobiona kopia. Zobacz też, czy istnieje adres testowy sklepu (staging).
Jak naprawić: Ustal zasadę: kopia, testy na stagingu, potem produkcja — i to w oknie o niskim ruchu, np. we wtorek rano, nie w piątek po południu.
SLA istnieje tylko w ofercie handlowej, a w umowie nie ma ani czasów reakcji, ani kar umownych. W praktyce nie masz czym wyegzekwować terminu.
Jak wykryć: Porównaj liczbę parametrów SLA w ofercie i w podpisywanej umowie. Jeśli w umowie został sam zapis o należytej staranności, SLA nie działa.
Jak naprawić: Zażądaj dopisania do umowy czasów reakcji i naprawy oraz rabatu albo kredytu w abonamencie za ich niedotrzymanie.
Monitoring ograniczony do uptime. Sklep może odpowiadać kodem 200, a jednocześnie nie wysyłać maili transakcyjnych albo odrzucać płatności — i nikt tego nie widzi.
Jak wykryć: Sprawdź, czy dostawca monitoruje certyfikat SSL, logi błędów PHP, czas odpowiedzi serwera i kolejkę maili. Zapytaj, kto dostaje alert i o której godzinie.
Jak naprawić: Dopisz do zakresu monitoring czterech warstw: uptime, SSL, error log, kolejka maili. Dodatkowo raz w miesiącu testowe zamówienie z prawdziwą płatnością i etykietą kurierską.
Prace rozwojowe topione w abonamencie bez ewidencji godzin. Klient nie wie, ile godzin faktycznie zużył, a przy większym projekcie abonament nagle przestaje wystarczać.
Jak wykryć: Poproś o zestawienie przepracowanych godzin z poprzedniego miesiąca. Brak takiego zestawienia przy jednoczesnych deklaracjach o elastyczności to typowy problem.
Jak naprawić: Rozdziel zakres stały (abonament) od prac rozliczanych godzinowo i ustal, że każda godzina poza pakietem wymaga Twojej akceptacji przed wykonaniem.
Utrzymanie i opieka techniczna sklepu to trzy osobne obszary: infrastruktura, aplikacja i rozwój — i wszystkie trzy muszą być opisane w umowie. Najczęstszy błąd to brak listy czynności z częstotliwością oraz brak kar umownych, przez co SLA zostaje sloganem, a nie zobowiązaniem. Nie da się porównać dwóch ofert po cenie, jeśli nie wiesz, ile godzin pracy faktycznie się za nią kryje. Zacznij od 12 punktów z listy kontrolnej powyżej — nawet jeśli nie podpiszesz z nami umowy, będziesz wiedzieć, o co pytać dostawcę.
Technicznie nie — serwer i kod nie wiedzą, gdzie siedzi wykonawca. Różnica praktyczna jest w organizacji: strefa czasowa i godziny wsparcia są te same, więc kluczowe są kanał zgłoszeń oraz czas reakcji, a nie odległość. Warto zapytać, kto konkretnie odbiera zgłoszenia i czy da się umówić na pracę poza standardowym oknem, gdy sklep padnie wieczorem.
Sam abonament w małym sklepie (kilkadziesiąt zamówień miesięcznie) zwykle zużywa kilka godzin roboczych: kopie, aktualizacje, monitoring, przegląd logów i testy integracji. Wszystko powyżej tego zakresu to już prace rozwojowe rozliczane godzinowo. Dlatego przed podpisaniem umowy poproś o rozbicie pakietu na konkretne czynności i szacunek czasu — inaczej nie porównasz dwóch ofert o różnych cenach.
Nie i warto to ustalić na piśmie. Bieżące aktualizacje bezpieczeństwa i drobne poprawki to utrzymanie aplikacji, czyli zakres stały. Migracja między głównymi wersjami to projekt: audyt modułów, testy na środowisku testowym, poprawki szablonu i integracji, testy zamówień oraz płatności. Taki projekt wycenia się na godziny i realizuje etapami, z jasno określonym terminem i listą rzeczy, które mogą przestać działać.
Może próbować, ale nie powinieneś się na to zgadzać. Serwer, domena, kod sklepu i moduły własne to Twoja własność — opłacasz hosting i zlecałeś wykonanie prac. Ustal w umowie, że dostępy i kopia modułów własnych są przekazywane w ciągu 5 dni roboczych od zakończenia współpracy, niezależnie od tego, kto wypowiada umowę.
Poproś o miesięczny raport z listą wykonanych czynności i datami. Dobrym uzupełnieniem są automatyczne powiadomienia: monitoring uptime, historia kopii zapasowych i log aktualizacji w panelu sklepu. Jeśli dostawca nie chce pokazywać żadnych danych, a jedynie opisuje pracę słowami, traktuj to jako brak dowodu — niezależnie od tego, jak dobre ma intencje.
Najpierw ustal to przed podpisaniem umowy: kto odbiera zgłoszenie o 22:00 w piątek i co jest wtedy gwarantowane. Realny tryb 24x7 kosztuje i ma sens głównie w sklepach z dużym wieczornym ruchem. W pozostałych przypadkach wystarczy jasny zapis, że poza godzinami wsparcia dostawca reaguje rano, a Ty masz dostęp do awaryjnego kontaktu na wypadek braku sprzedaży.
Hrubieszów to nasz główny obszar, ale pracę zdalną prowadzimy też dla firm z okolic. Zakres pakietu i zasady współpracy są takie same m.in. dla sklepów z Biłgoraja, Narola i Józefowa. Niezależnie od miejscowości liczy się jedno: ustalony zakres prac, czas reakcji i dostęp do serwera po Twojej stronie.
Jeśli chcesz, żebyśmy przeliczyli Twój obecny pakiet opieki na konkretne godziny i czynności, wyślij nam adres sklepu i zakres, jaki masz teraz w umowie. Odpowiemy, co jest w nim niedoprecyzowane.