W skrócie
Stała opieka techniczna nad sklepem nie powinna polegać wyłącznie na czekaniu na zgłoszenie awarii. Powinna obejmować regularne aktualizacje, monitoring, kopie zapasowe, utrzymanie integracji, reagowanie na incydenty oraz cykliczną analizę techniczną sklepu.
Dobry zespół utrzymaniowy powinien również proaktywnie wskazywać zmiany, które mogą poprawić szybkość działania, stabilność, bezpieczeństwo i ścieżkę zakupową. Część z nich nie będzie naprawą błędu, ale może mieć bezpośrednie znaczenie dla sprzedaży.
Dlatego przy porównywaniu ofert warto patrzeć nie tylko na liczbę godzin w abonamencie. Znacznie ważniejsze jest to, co dzieje się ze sklepem w miesiącu, w którym sam nie zgłosisz żadnego zadania.
Opieka techniczna to nie helpdesk
Najprostszy model utrzymania działa reaktywnie. Klient zgłasza zadanie lub awarię, wykonawca je analizuje, wycenia albo odejmuje czas od abonamentu i realizuje.
Taki model może być wystarczający dla części projektów, ale w przypadku aktywnie sprzedającego sklepu internetowego pozostawia dużo odpowiedzialności po stronie właściciela. To jego zespół musi jako pierwszy zauważyć, że coś przestało działać albo wymaga aktualizacji.
Stała opieka techniczna i rozwój powinny obejmować również pracę wykonywaną bez wcześniejszego zgłoszenia klienta. Mogą to być aktualizacje, analiza błędów, kontrola monitoringu, przegląd podatności, sprawdzanie integracji oraz rekomendowanie zmian wynikających z rozwoju technologii lub samego sklepu.
Jeżeli przez miesiąc klient nie zgłosi żadnego zadania, nie powinno to automatycznie oznaczać, że przez miesiąc nikt nie zagląda do sklepu.
Najpierw ustal, co właściwie jest objęte opieką
Sklep internetowy rzadko jest jednym systemem. Sprzedaż może zależeć jednocześnie od aplikacji sklepu, hostingu, operatora płatności, przewoźników, ERP, systemu księgowego, magazynu, marketplace'ów, systemu mailingowego i dodatkowych usług.
Na początku współpracy warto więc przygotować listę elementów objętych utrzymaniem i określić odpowiedzialność za każdy z nich.
| Element |
Co warto ustalić |
| Sklep |
kto odpowiada za kod, konfigurację, błędy i aktualizacje |
| Serwer |
kto administruje środowiskiem, PHP, bazą danych i usługami |
| Płatności |
kto diagnozuje problemy po stronie sklepu i kontaktuje się z operatorem |
| Dostawy |
kto odpowiada za moduł, API i błędy generowania przesyłek |
| ERP / magazyn |
kto kontroluje synchronizację produktów, stanów i zamówień |
| Marketplace |
kto odpowiada za wymianę danych i błędy synchronizacji |
| Analityka |
kto kontroluje poprawność pomiaru kluczowych zdarzeń |
Firma utrzymująca sklep nie ma wpływu na dostępność infrastruktury operatora płatności czy przewoźnika. Może jednak odpowiadać za diagnozę, zebranie informacji technicznych, kontakt z dostawcą oraz sprawdzenie, czy po usunięciu awarii cały proces ponownie działa prawidłowo.
Regularne aktualizacje powinny być częścią usługi
Aktualizowanie sklepu dopiero wtedy, gdy pojawi się błąd albo krytyczna podatność, prowadzi z czasem do narastania długu technicznego.
W przypadku WooCommerce oznacza to aktualizacje WordPressa, WooCommerce, motywu i wtyczek. W PrestaShop dochodzą aktualizacje platformy oraz używanych modułów. W sklepach tworzonych indywidualnie trzeba dodatkowo utrzymywać framework, biblioteki i pozostałe zależności aplikacji.
Nie każdą aktualizację trzeba instalować natychmiast po jej publikacji. Powinien jednak istnieć regularny proces, w którym zespół sprawdza dostępne wersje, ocenia ryzyko, wykonuje aktualizacje i weryfikuje sklep po wdrożeniu.
Przy większych zmianach warto wykorzystać środowisko testowe i przejść najważniejsze elementy ścieżki zakupowej przed aktualizacją produkcji.
Dzięki temu po kilku latach nie dochodzi do sytuacji, w której sklep działa na tak starym zestawie komponentów, że zwykła aktualizacja zmienia się w osobny projekt migracyjny.
Podatności wymagają innego trybu niż zwykłe aktualizacje
Regularny harmonogram aktualizacji nie powinien być jedynym mechanizmem.
Jeżeli w używanej wersji wtyczki, modułu albo biblioteki zostanie opublikowana poważna podatność, reakcja może być potrzebna przed kolejnym planowanym oknem aktualizacyjnym.
Dlatego w zakresie opieki warto ustalić, kto monitoruje podatności i co dzieje się po wykryciu zagrożenia dotyczącego konkretnej wersji zainstalowanej w sklepie.
Właśnie w takim modelu wykorzystujemy również monitoring DockRay: nie tylko do sprawdzania dostępności strony, ale również do skracania czasu pomiędzy pojawieniem się informacji o problemie a reakcją zespołu.
Monitoring powinien sprawdzać więcej niż stronę główną
Sklep może odpowiadać kodem HTTP 200 i jednocześnie nie sprzedawać.
Może przestać aktualizować statusy opłaconych zamówień, nie pobierać stanów magazynowych, nie wysyłać danych do ERP albo generować błędy dopiero podczas konkretnego etapu checkoutu.
Dlatego zakres monitoringu warto dopasować do architektury sklepu. W zależności od projektu może obejmować:
- dostępność sklepu i kluczowych usług,
- błędy aplikacji,
- czas odpowiedzi,
- ważność certyfikatu SSL,
- kolejki zadań,
- zadania cykliczne i cron,
- wybrane integracje,
- synchronizację zamówień lub produktów,
- procesy działające w tle,
- wydajność najważniejszych elementów sklepu.
Nie ma sensu monitorować wszystkiego tylko dlatego, że technicznie jest to możliwe. W pierwszej kolejności warto objąć monitoringiem elementy, których awaria może zatrzymać sprzedaż albo zakłócić realizację zamówień.
Alert musi trafić do osoby, która może zareagować
Monitoring bez ustalonego procesu reakcji jest przede wszystkim archiwum informacji o awariach.
Każdy istotny alert powinien mieć odbiorcę, priorytet i określony sposób postępowania. Trzeba również ustalić, co dzieje się z alertami poza standardowymi godzinami pracy.
Innej reakcji wymaga wygasający za 20 dni certyfikat, innej pojedynczy błąd aplikacji, a jeszcze innej sytuacja, w której wszystkie próby płatności kończą się błędem.
Dobra opieka techniczna powinna rozróżniać te przypadki zamiast traktować każde powiadomienie identycznie.
Czas reakcji to nie czas rozwiązania
Przy ustalaniu SLA trzeba precyzyjnie określić, czego dotyczy deklarowany czas.
Potwierdzenie otrzymania zgłoszenia, rozpoczęcie diagnozy, przygotowanie rozwiązania tymczasowego i pełne usunięcie przyczyny to cztery różne momenty.
Ma to szczególne znaczenie przy integracjach zewnętrznych. Jeżeli operator płatności ma awarię, firma utrzymująca sklep nie może zagwarantować czasu jej usunięcia. Może natomiast szybko ustalić, po której stronie występuje problem, przygotować dane do zgłoszenia i sprawdzić działanie sklepu po przywróceniu usługi.
Dlatego zamiast samego „reakcja do dwóch godzin” warto ustalić, co dokładnie wydarzy się w ciągu tych dwóch godzin.
Kopia zapasowa nie wystarczy, jeśli nikt nie sprawdził odtwarzania
Backup jest podstawowym elementem utrzymania sklepu, ale sama informacja, że kopie są wykonywane codziennie, niewiele mówi o możliwości odtworzenia sprzedaży po awarii.
Warto wiedzieć, gdzie znajdują się kopie, jak długo są przechowywane, czy obejmują pliki i bazę danych oraz jak wygląda procedura przywrócenia.
W ecommerce pojawia się dodatkowy problem: dane cały czas się zmieniają.
Jeżeli o 14:00 przywrócisz bazę z kopii wykonanej o 2:00, trzeba uwzględnić zamówienia, płatności, zmiany stanów magazynowych i konta klientów utworzone przez ostatnie 12 godzin.
Dlatego procedura awaryjna powinna opisywać nie tylko sposób technicznego odtworzenia backupu, ale również sposób postępowania z danymi powstałymi po jego wykonaniu.
Integracja wymaga utrzymania również po udanym wdrożeniu
Połączenie sklepu z ERP, hurtownią, operatorem płatności albo systemem kurierskim nie staje się bezobsługowe w dniu uruchomienia.
Dostawca może zmienić API, sposób uwierzytelnienia, strukturę danych albo wymagania dotyczące konkretnego endpointu. Token może wygasnąć, webhook może nie dotrzeć, a pojedyncza wartość może zacząć przychodzić w innym formacie.
Dobra integracja powinna być przygotowana również na ponawianie operacji i ich bezpieczne przetwarzanie.
Przykładowo Stripe informuje w swojej dokumentacji, że automatycznie ponawia dostarczanie zdarzeń webhook przez okres do trzech dni w środowisku produkcyjnym i nie gwarantuje kolejności ich dostarczenia. Kod obsługujący płatności powinien być przygotowany na takie zachowanie.
Przy stałej opiece trzeba więc ustalić, kto obserwuje błędy synchronizacji, gdzie są zapisywane oraz kto reaguje, gdy przepływ danych zostanie przerwany.
Stała opieka powinna również rozwijać sklep
Utrzymanie sklepu nie powinno sprowadzać się do zachowania stanu z dnia jego uruchomienia.
Zmieniają się przeglądarki, urządzenia, systemy płatności, wymagania dotyczące dostępności, możliwości platformy i zachowania klientów. Pojawiają się również nowe wersje PHP, WooCommerce, PrestaShop i używanych rozszerzeń.
Zespół, który regularnie pracuje ze sklepem, może zauważyć techniczne możliwości poprawy wcześniej niż osoba zajmująca się jego codzienną obsługą.
Dlatego częścią stałej współpracy powinny być proaktywne rekomendacje, a nie tylko realizowanie zadań przesłanych przez klienta.
Jakie zmiany techniczne mogą wspierać sprzedaż?
Nie każda rekomendacja musi oznaczać duży redesign albo przebudowę platformy. Często są to mniejsze zmiany wynikające z obserwacji działania sklepu.
Mogą dotyczyć na przykład:
- przyspieszenia stron kategorii i produktów,
- poprawy wyszukiwarki i filtrowania produktów,
- uproszczenia formularzy i checkoutu,
- poprawy działania sklepu na urządzeniach mobilnych,
- usunięcia błędów JavaScript występujących na ścieżce zakupowej,
- poprawy technicznego SEO,
- wdrożenia lub poprawienia danych strukturalnych,
- usprawnienia synchronizacji stanów i cen,
- ograniczenia czasu oczekiwania na zewnętrzne API,
- poprawy dostępności cyfrowej,
- usunięcia zbędnych rozszerzeń obciążających sklep,
- poprawy pomiaru zdarzeń i konwersji.
Nie każda taka zmiana automatycznie zwiększy sprzedaż. Powinna jednak wynikać z konkretnej obserwacji, danych albo technicznego ograniczenia i mieć jasno określony cel.
Rolą zespołu technicznego jest wskazanie możliwości i konsekwencji technicznych. W przypadku zmian związanych bezpośrednio z konwersją warto następnie mierzyć ich wpływ zamiast zakładać z góry, że przyniosą określony wynik.
Wydajność warto kontrolować również wtedy, gdy nikt się nie skarży
Spadek wydajności sklepu często nie następuje jednego dnia.
Przybywa produktów, zamówień, danych w bazie, skryptów marketingowych i kolejnych integracji. Zapytanie, które przy 5 tysiącach zamówień wykonywało się szybko, przy 500 tysiącach może zacząć być zauważalnym obciążeniem.
Dlatego przy dłuższej współpracy warto obserwować wydajność i reagować na pogarszające się parametry przed momentem, w którym użytkownicy zaczną zgłaszać wolne działanie sklepu.
Może to prowadzić do optymalizacji zapytań do bazy, cache, zadań wykonywanych w tle, wyszukiwarki, kodu frontendu albo infrastruktury. Mocniejszy serwer jest jedną z możliwości, ale nie powinien być automatycznie pierwszym rozwiązaniem.
Opieka powinna obejmować porządkowanie długu technicznego
Sklep rozwijany przez kilka lat gromadzi elementy, które kiedyś były potrzebne, ale dzisiaj nie mają już zastosowania.
Mogą to być nieużywane wtyczki, stare integracje, tymczasowy kod napisany przy jednej kampanii, nieaktualne biblioteki albo funkcje zastąpione później przez samą platformę.
Jeżeli nikt ich nie przegląda, liczba zależności rośnie i każda kolejna aktualizacja staje się trudniejsza.
Stała opieka daje możliwość usuwania takich elementów stopniowo. Dzięki temu modernizacja sklepu nie musi po kilku latach zaczynać się od dużego projektu porządkowego.
Warto ustalić stały przegląd techniczny
Nie wszystkie zadania wymagają codziennej obserwacji. Część można wykonywać cyklicznie, na przykład raz na miesiąc albo raz na kwartał.
Taki przegląd może obejmować wersje platformy i rozszerzeń, błędy aplikacji, wydajność, wykorzystanie zasobów, stan integracji, zaległe aktualizacje, podatności, kopie zapasowe oraz listę elementów wymagających dalszego rozwoju.
Efektem powinny być konkretne rekomendacje z określonym priorytetem. Klient może wtedy zdecydować, które zmiany realizować od razu, które zaplanować na kolejny miesiąc, a które nie mają obecnie wystarczającego uzasadnienia biznesowego.
Co powinieneś dostawać w ramach stałej opieki?
Zakres zależy od sklepu, ale przy porównywaniu ofert warto sprawdzić przynajmniej następujące elementy:
- obsługę bieżących zgłoszeń i błędów,
- ustalone czasy reakcji dla różnych priorytetów,
- monitoring najważniejszych elementów sklepu,
- regularne aktualizacje platformy i rozszerzeń,
- obsługę pilnych aktualizacji bezpieczeństwa,
- kopie zapasowe i procedurę odtwarzania,
- utrzymanie kluczowych integracji,
- środowisko testowe dla zmian wymagających weryfikacji,
- kontrolę działania po wdrożeniu,
- cykliczny przegląd techniczny,
- proaktywne rekomendacje dotyczące wydajności, bezpieczeństwa i sprzedaży,
- dokumentację istotnych elementów projektu,
- jasne zasady rozliczania prac wykraczających poza abonament.
Jak porównać dwie oferty opieki technicznej?
Pakiet zawierający 20 godzin miesięcznie nie musi być lepszy od pakietu zawierającego 10 godzin. Najpierw trzeba sprawdzić, co właściwie jest wliczane do tego czasu i jakie działania wykonawca realizuje niezależnie od zgłoszeń.
Przed podpisaniem umowy warto uzyskać odpowiedzi na kilka konkretnych pytań:
- Co dokładnie obejmuje opieka? Sklep, serwer, integracje, monitoring, aktualizacje czy tylko kod aplikacji?
- Kto pierwszy dowiaduje się o awarii? Klient czy wykonawca dzięki monitoringowi?
- Jak często wykonywane są aktualizacje? Czy istnieje regularny harmonogram i osobna ścieżka dla krytycznych poprawek?
- Co dzieje się, jeśli nie zgłoszę żadnego zadania? Czy zespół wykonuje wtedy przegląd, aktualizacje i rekomenduje potrzebne zmiany?
- Jakie są czasy reakcji? Czy zależą od wpływu awarii na sprzedaż?
- Kto zajmuje się integracjami? Czy wykonawca pomaga również w kontakcie z zewnętrznym dostawcą?
- Jak testowane są aktualizacje? Czy dostępne jest środowisko testowe i kontrola po wdrożeniu?
- Jak wyglądają kopie zapasowe? Czy istnieje sprawdzona procedura odtworzenia sklepu?
- Czy dostaję proaktywne rekomendacje? Kto wskazuje, że sklep można przyspieszyć, uprościć checkout albo poprawić techniczne elementy wpływające na sprzedaż?
- Co jest płatne dodatkowo? Warto znać granicę między abonamentem a osobno wycenianym rozwojem.
Najważniejsze pytanie: co dzieje się, gdy niczego nie zgłaszasz?
To jeden z najprostszych sposobów na rozróżnienie helpdesku od rzeczywistej opieki technicznej.
Jeżeli przez trzy miesiące sklep nie ma żadnej widocznej awarii, nadal pojawiają się nowe wersje oprogramowania, podatności, zmiany po stronie integracji i możliwości optymalizacji. Rosną również baza danych i liczba zamówień, a sam biznes może wprowadzać nowe produkty, kampanie i procesy.
W modelu reaktywnym wykonawca czeka, aż klient coś zgłosi. W modelu stałej opieki zespół powinien również obserwować projekt, wykonywać zaplanowane prace utrzymaniowe i zwracać uwagę na rzeczy, którymi warto się zająć.
Opieka techniczna powinna chronić sprzedaż i rozwijać sklep
W Dock traktujemy stałe utrzymanie i rozwój jako ciągłą pracę nad sklepem, a nie pakiet godzin uruchamiany dopiero po zgłoszeniu.
Obejmuje to bieżącą obsługę zadań i awarii, ale również monitoring, aktualizacje, kontrolę techniczną i wskazywanie zmian, które warto zaplanować. Jeżeli widzimy możliwość poprawy wydajności, procesu zakupowego, integracji albo innego technicznego elementu istotnego dla sprzedaży, rekomendujemy ją zamiast czekać, aż stanie się osobnym zgłoszeniem.
Zakres zawsze powinien wynikać z konkretnego sklepu. Innej opieki potrzebuje niewielki WooCommerce z kilkoma zamówieniami dziennie, a innej sklep połączony z ERP, kilkoma magazynami, marketplace'ami i własnymi integracjami.
Jeżeli chcesz uporządkować utrzymanie istniejącego sklepu albo przejąć projekt od poprzedniego wykonawcy, napisz do nas. Możemy zacząć od audytu obecnego środowiska i ustalić zakres opieki odpowiedni do tego, od czego rzeczywiście zależy sprzedaż.
