Ten tekst jest o tym drugim koszcie. Pokazujemy, co w sklepie na WooCommerce faktycznie zjada godziny, ile czasu z praktyki zajmują typowe naprawy, jak wygląda cykl aktualizacji i ile godzin miesięcznie potrzebują trzy różne profile sklepów. Liczby podajemy jako rzędy wielkości z naszej pracy, a nie jako obietnicę. Jeżeli po przeczytaniu wyjdzie Ci, że Twój sklep potrzebuje trzech godzin miesięcznie i radzisz sobie sam, to też jest dobry wynik tej lektury.
Dlaczego sklep na WooCommerce zużywa godziny inaczej niż sklep na SaaS
Na platformie w modelu SaaS aktualizacja rdzenia dzieje się poza Tobą i w dużej mierze bez Twojego udziału. Ryzyko koncentruje się w kilku miejscach: aplikacje z marketplace, motyw i własny kod. Reszta jest problemem dostawcy platformy.
W WooCommerce jest odwrotnie. Rdzeń sam w sobie rzadko jest źródłem kłopotów. Typowy sklep o obrocie kilku milionów złotych ma od kilkunastu do kilkudziesięciu aktywnych wtyczek. Każda z nich wydaje aktualizacje we własnym rytmie, część kilka razy w miesiącu, część raz na pół roku. Część jest płatna i przestaje się aktualizować w dniu wygaśnięcia licencji. Część jest darmowa i przestaje się aktualizować, bo autor porzucił projekt. To właśnie ta warstwa, a nie rdzeń, generuje pracę: nie ma jednego terminarza, nie ma jednego dostawcy i nie ma jednego miejsca, w którym widać, co się zmieniło.
Druga różnica jest taka, że w WooCommerce odpowiadasz też za warstwę pod sklepem: serwer, wersję PHP, bazę danych, cache. W SaaS ta warstwa nie istnieje z Twojej perspektywy. Tutaj istnieje i potrafi być przyczyną awarii, która wygląda jak błąd sklepu.
Pięć rzeczy, które realnie psują sklepy na WooCommerce
Konflikt wtyczek po aktualizacji. Objaw: po nocnej aktualizacji przestaje działać jeden konkretny element, najczęściej wybór punktu odbioru, kupon albo wysyłka faktury. Przyczyna: dwie wtyczki modyfikują ten sam moment w procesie zamówienia i jedna z nich zmieniła sposób, w jaki to robi. Rząd wielkości naprawy: od 1 do 4 godzin, jeżeli mamy kopię sprzed aktualizacji i możemy porównać, znacznie więcej, jeżeli nie wiadomo, co i kiedy się zmieniło.
Przeciążona baza danych. Objaw: panel administracyjny mieli się coraz wolniej, lista zamówień otwiera się kilkanaście sekund, sklep zamula się przy większym ruchu. Przyczyna: tabela wp_options spuchnięta od wpisów ładowanych przy każdym żądaniu (autoload), sterty tymczasowych danych po wtyczkach, które dawno usunięto, oraz stary sposób przechowywania zamówień jako wpisy i metadane zamiast HPOS, czyli dedykowanych tabel zamówień. Rząd wielkości: od 3 do 8 godzin na porządki i pomiar efektu. Samo przejście na HPOS to osobny temat, bo wtyczki niezgodne z tym trybem są najczęstszą przyczyną problemów przy jego włączaniu, więc robi się to wyłącznie po przetestowaniu całej listy wtyczek.
Koszyk i checkout. Objaw: po zmianie motywu albo po aktualizacji znika pole, którego klienci potrzebują, albo checkout wygląda inaczej niż wczoraj. Przyczyna: w WooCommerce istnieją dwa warianty koszyka i checkoutu, klasyczny oparty na shortcode i nowszy oparty na blokach, a część wtyczek wspiera tylko jeden z nich. Sklep może mieć jeden tryb na stronie koszyka i drugi na stronie zamówienia, co jest źródłem trudnych do powtórzenia błędów. Rząd wielkości: od 2 do 6 godzin na ustalenie stanu faktycznego i doprowadzenie obu stron do jednego trybu, więcej, jeżeli trzeba wymienić wtyczkę.
Wygasłe licencje modułów płatnych. Objaw: wtyczka działa, ale nie da się jej zaktualizować, a w panelu pojawia się komunikat o kluczu. Przyczyna: licencja wygasła albo została wykupiona na prywatne konto osoby, która już nie pracuje w firmie. Rząd wielkości: od 15 minut do 2 godzin na wtyczkę, pod warunkiem że da się odzyskać dostęp do konta zakupowego. Jeżeli się nie da, zostaje zakup od nowa.
Wydajność przy większym katalogu. Objaw: filtrowanie i wyszukiwanie w kategorii z kilkoma tysiącami produktów trwa zbyt długo, import cen z ERP blokuje sklep. Przyczyna: zapytania po metadanych produktów, brak indeksów, import realizowany w jednym długim procesie. Rząd wielkości: od 6 do 20 godzin, bo to nie jest naprawa, tylko przebudowa konkretnego mechanizmu.
Szerszy przegląd typowych zdarzeń opisaliśmy w tekście o najczęstszych awariach sklepów internetowych.
Aktualizacje: dlaczego nie robimy ich automatycznie
Automatyczna aktualizacja wszystkiego to najtańszy sposób na to, żeby sklep przestał przyjmować zamówienia w nocy i żeby nikt się o tym nie dowiedział do rana. W sklepie, w którym kilkanaście wtyczek dotyka procesu zakupowego, aktualizacja bez testu jest po prostu zakładem.
Procedura, którą stosujemy, wygląda tak. Kopia sklepu trafia na środowisko testowe. Tam instalujemy zmiany, przechodzimy ścieżkę zakupową z płatnością testową, sprawdzamy wysyłkę, fakturę i przesył zamówienia do systemu magazynowego. Dopiero potem wdrażamy to na sklep produkcyjny, z kopią zapasową zrobioną bezpośrednio przed wdrożeniem. Aktualizacje krytyczne, czyli łatające podatności, robimy szybko i w oddzielnym cyklu, pozostałe zbieramy w paczki, żeby nie ruszać sklepu co drugi dzień.
Ile to kosztuje w godzinach z puli. Przy kilkunastu wtyczkach sam cykl aktualizacji to orientacyjnie od 1 do 2 godzin miesięcznie. Przy kilkudziesięciu wtyczkach i integracji z ERP to zwykle od 3 do 6 godzin miesięcznie, bo rośnie nie liczba kliknięć, tylko liczba ścieżek, które trzeba przeklikać po zmianie. Do tego dochodzi czas na sytuacje, w których aktualizacja nie przechodzi testu i trzeba zdecydować, czy zostajemy na starszej wersji, czy wymieniamy wtyczkę.
Ile godzin miesięcznie realnie potrzebuje sklep na WooCommerce
Trzy profile, które widzimy najczęściej.
Mały sklep stabilny. Kilkaset produktów, kilkanaście wtyczek, brak integracji z ERP, zmiany w sklepie sprowadzają się do banerów, promocji i drobnych poprawek treści. Realne zużycie: od 5 do 8 godzin miesięcznie, z czego połowa to aktualizacje i przeglądy. Pakiet Basic za 950 zł z pulą 10 godzin.
Średni sklep w rozwoju. Kilka tysięcy produktów, integracja z magazynem, kilka kanałów płatności i wysyłki, co miesiąc jakaś nowa funkcja lub kampania wymagająca zmian w szablonie. Realne zużycie: od 15 do 20 godzin miesięcznie. Pakiet Advanced za 1 900 zł z pulą 20 godzin.
Duży sklep wielokanałowy. Duży katalog, ceny B2B, feedy do porównywarek i marketplace'ów, kilka środowisk, praca ciągła nad konwersją. Realne zużycie: od 30 do 40 godzin miesięcznie. Pakiet Premium za 3 800 zł z pulą 40 godzin.
Godzina w ramach pakietu kosztuje 95 zł, godzina wykorzystana ponad pulę 150 zł, a usługa działa w dni robocze od 8 do 18. Najważniejsze zdanie w tej sekcji brzmi jednak inaczej: pakiet dobiera się według planowanego zakresu zmian, a nie według wielkości firmy. Sklep o obrocie 12 mln zł, który przez rok nic nie zmienia, spokojnie mieści się w Basicu. Sklep o obrocie 2 mln zł, który właśnie wchodzi na marketplace i przepina ERP, wykorzysta Advanced do zera. Jeżeli chcesz policzyć to szerzej, razem z hostingiem i licencjami, zrobiliśmy do tego osobny tekst o tym, ile kosztuje utrzymanie sklepu internetowego.
Co powinno być w opiece nad WooCommerce, a czego zwykle nie ma
Lista do sprawdzenia u obecnego dostawcy. Pięć pytań, na które powinieneś dostać odpowiedź w jednym mailu.
- Kto ma licencje płatnych wtyczek i na czyje konto zostały kupione. Odpowiedź "agencja to ma" jest odpowiedzią złą, bo licencje powinny należeć do Ciebie.
- Czy istnieje środowisko testowe i kiedy było ostatnio synchronizowane z produkcją. Środowisko sprzed roku nie jest środowiskiem testowym.
- Czy ktoś prowadzi listę dat wygaśnięcia licencji i certyfikatu, i kto dostaje o tym powiadomienie.
- Kto ma dostęp do serwera, panelu hostingu i bazy, a kto tylko do panelu WordPressa. To są dwie różne rzeczy i przy awarii różnica jest decydująca.
- Czy są kopie zapasowe i czy ktokolwiek kiedykolwiek odtworzył z nich sklep. Kopia nieprzetestowana to założenie, a nie zabezpieczenie.
W naszych umowach test odtworzenia kopii jest robiony raz na kwartał i zapisany, właśnie dlatego, że to jest punkt, w którym najczęściej okazuje się, że coś od miesięcy nie działa.
Granica między wsparciem a SLA na przykładzie WooCommerce
Wsparcie techniczne to pula godzin na zmiany, które zlecasz Ty. Nowy sposób naliczania rabatu, dodanie pola do formularza zamówienia, aktualizacja wtyczek, poprawka w szablonie e-maila, przeniesienie feedu. Zgłaszasz, my robimy, godziny schodzą z puli, zużycie widać w Gorilla Panelu.
SLA odpowiada na drugi rodzaj zdarzeń: sklep albo jego kluczowa funkcja przestały działać i chcesz się o tym dowiedzieć zanim dowie się klient. Sklep jest sprawdzany co 60 sekund, alert weryfikuje człowiek, przy zdarzeniu krytycznym prowadzimy diagnostykę i przekazujemy notatkę poawaryjną. Gwarantujemy czas reakcji, nie czas usunięcia awarii, bo przyczyna bywa po stronie hostingu albo zewnętrznej bramki płatności, na które nie mamy wpływu. Nadzór zaczyna się od 890 zł miesięcznie. Różnicę między tymi dwoma usługami rozbieramy dokładniej w tekście wsparcie techniczne czy SLA.
W praktyce sklep na WooCommerce potrzebuje obu rzeczy z innego powodu niż sklep na SaaS: to właśnie aktualizacje wtyczek są zdarzeniem, po którym najczęściej coś przestaje działać, więc ten sam cykl generuje zarówno pracę planową, jak i ryzyko, które ktoś musi obserwować.
Przejęcie sklepu prowadzonego wcześniej przez kogoś innego
Nie zaczynamy od zmian, tylko od ustalenia stanu. Audyt techniczny: wersje, wersja PHP, stan bazy, sposób przechowywania zamówień, tryb koszyka i checkoutu, własny kod w motywie potomnym. Inwentaryzacja wtyczek z podziałem na darmowe, płatne z ważną licencją, płatne z wygasłą licencją i takie, które nie są już rozwijane. Uporządkowanie dostępów: serwer, panel hostingu, domena, konta zakupowe wtyczek, repozytorium, jeżeli istnieje.
To zwykle od 8 do 16 godzin i kończy się jedną listą rzeczy do zrobienia, z podziałem na to, co jest ryzykiem teraz, i to, co poczeka. Dopiero po tym ma sens rozmowa o pakiecie, bo dopiero wtedy wiadomo, ile godzin miesięcznie ten konkretny sklep będzie zjadał.
Porównaj pakiety wsparcia i poziomy SLA na stronie /pl/sla-help-desk i wybierz ten, który odpowiada planowanemu zakresowi zmian w najbliższym kwartale. Jeżeli chcesz zacząć od danych, a nie od rozmowy, wpisz adres swojego sklepu w Tester eCommerce: dostaniesz darmową diagnozę stanu technicznego, którą możesz wykorzystać także u obecnego dostawcy.