Baza wiedzy PrestaShop

Koszt godziny przestoju to przychód, który sklep osiąga w tej konkretnej godzinie, powiększony o budżet reklam kierujących w tym czasie ruch na niedziałającą stronę. Przy sprzedaży na poziomie 100 000 zł miesięcznie przeciętna godzina to około 140 zł, ale godzina w szczycie kampanii jest warta wielokrotnie więcej, bo wtedy ruch i konwersja są najwyższe.   Jak to policzyć dla swojego sklepu: 1. Przychód z godziny, w której zdarzyła się awaria: weź z analityki przychód z tej samej godziny i dnia tygodnia, a nie średnią z miesiąca, bo awarie najbardziej bolą wieczorem i w weekend. 2. Opłacony ruch: dolicz koszt reklam, które w czasie przestoju prowadziły klientów na niedziałający sklep. 3. Czas do pełnej sprawności: przestój nie kończy się w chwili przyjęcia zgłoszenia, bo liczy się czas diagnozy i naprawy, a ten jest najdłuższy, gdy nikt nie zna sklepu. 4. Skutki odroczone: porzucone koszyki, klienci, którzy nie wrócą, a przy dłuższych problemach także spadek pozycji w wyszukiwarce.   Porównaj wynik z rocznym kosztem stałej opieki: jeśli jeden poważny przestój w szczycie kosztuje więcej niż kilka miesięcy abonamentu, rachunek jest prosty. Różnice między modelami współpracy opisują odpowiedzi o abonamencie wsparcia i pomocy ad hoc oraz o tym, czym stała opieka różni się od współpracy z freelancerami. Abonament WayCare łączy w jednej umowie infrastrukturę, monitoring 24/7 i zespół, który reaguje na incydenty krytyczne przez całą dobę.

Każdą zmianę w ścieżce zakupu wdrażaj tak, żeby dało się ją zmierzyć i szybko wycofać: najpierw na środowisku testowym, potem na produkcji poza szczytem ruchu, z porównaniem konwersji przed i po. Spadek konwersji po wdrożeniu rzadziej wynika z samej funkcji, a częściej z tego, że nikt nie sprawdził jej wpływu na koszyk i szybkość sklepu.   Pięć zasad, które chronią sprzedaż: 1. Testy na kopii sklepu: nowa funkcja przechodzi przez środowisko z aktualnymi danymi, łącznie z pełną ścieżką od karty produktu do płatności. 2. Pomiar szybkości przed publikacją: nowy moduł potrafi wydłużyć ładowanie każdej podstrony, a to wystarczy, żeby część klientów rezygnowała z zakupu. 3. Publikacja poza szczytem: wdrażaj na przykład we wtorek rano, a nie w piątek przed kampanią. 4. Test A/B dla zmian w koszyku i na karcie produktu: porównanie dwóch wersji na realnym ruchu rozstrzyga, czy zmiana pomaga, zamiast opierać decyzję na przeczuciu. 5. Plan wycofania: zanim zmiana trafi na produkcję, wiadomo, jak ją cofnąć w kilka minut.   Jak policzyć, ile kosztuje spadek konwersji, pokazujemy w tekście o niskim współczynniku konwersji. Jeśli nie wiesz, które elementy ścieżki zakupu hamują sprzedaż, zacznij od audytu UX. Testy A/B na realnym ruchu Waynet wdrożył między innymi w sklepie Okularium, a cały proces, od analizy danych po testy i monitoring efektów zmian, prowadzimy w usłudze WayCRO.

Przed kampanią ustal z partnerem technicznym cztery rzeczy: termin zamrożenia zmian, dyżur na czas kampanii, kanał zgłaszania awarii i progi alertów w monitoringu. Szybka reakcja niewiele daje, jeśli zespół techniczny nie wie, kiedy rusza kampania i jakiego ruchu się spodziewać.   Co zrobić na dwa tygodnie przed startem: 1. Zamroź zmiany: ostatnie wdrożenia zaplanuj najpóźniej kilka dni przed kampanią, a potem wprowadzaj wyłącznie poprawki krytyczne, bo awarie w szczycie często wynikają ze zmian wprowadzonych w ostatniej chwili. 2. Przekaż plan marketingu zespołowi technicznemu: daty, godziny wysyłki mailingów, przewidywany ruch i adresy landingów, żeby zespół przygotował się na konkretny szczyt, a nie na ogólnie „większy ruch”. 3. Zrób test obciążeniowy: symulacja ruchu z kampanii pokazuje, przy jakim wolumenie sklep zwalnia, a metodę opisujemy w tekście o testach wydajnościowych przed Black Week. 4. Ustal dyżur i ścieżkę eskalacji: kto odbiera zgłoszenie wieczorem i w weekend, po jakim czasie zaczyna pracę i kto decyduje o wycofaniu zmiany. 5. Monitoruj koszyk i płatności: sama dostępność strony głównej nie wystarczy, bo sklep może się ładować i jednocześnie nie przyjmować zamówień.   Najczęstsze scenariusze awarii w szczycie zebraliśmy w tekście o kosztownych awariach PrestaShop w Black Friday, a szybkie przyspieszenie sklepu opisuje odpowiedź o wydajności przed sezonem. Stabilność w szczytach ruchu to zakres usługi WayBooster: przygotowanie trwa standardowo około dwóch tygodni, odbywa się na kopii sklepu, a po uruchomieniu obowiązuje SLA z reakcją do 1 godziny przez całą dobę.

Dla średniej i większej marki bezpieczniej jest rozwijać sklep etapami z jednym partnerem, który odpowiada zarówno za development, jak i za integracje. Najwięcej ryzyka w projektach e-commerce powstaje na styku systemów, a przy kilku dostawcach ten styk nie ma właściciela.   Jak podział między dostawców zwiększa ryzyko projektu: 1. Błędy na styku systemów: gdy integracja z ERP przestaje synchronizować stany, dostawca integracji wskazuje na moduł sklepu, a zespół sklepu na integrację, więc diagnoza się przeciąga, a sprzedaż stoi. 2. Rozjechane harmonogramy: każdy etap czeka na gotowość drugiej strony, więc jedno opóźnienie przesuwa cały plan. 3. Testy bez całości: każdy dostawca testuje swój fragment, a pełnej ścieżki zamówienia, od koszyka do ERP, nie testuje nikt.   Model etapowy z jednym partnerem zaczyna się od audytu technicznego i mapy zależności między systemami. Każdy kolejny etap przechodzi przez środowisko testowe i test pełnej ścieżki zamówienia, zanim trafi na produkcję, dzięki czemu na końcu etapu masz działający sklep, a nie fragment systemu czekający na resztę. Podział ma sens wtedy, gdy masz własny zespół IT, który realnie koordynuje dostawców i odpowiada za całość. Więcej na ten temat piszemy w odpowiedziach jeden partner czy kilku podwykonawców oraz jak sprawdzić, czy agencja poradzi sobie z rozbudowanymi integracjami. W realizacjach Waynet, takich jak Gerlach czy Konopka Shoes, integracja z ERP była częścią tego samego projektu co rozwój sklepu, a zakres takich prac opisujemy na stronie integracji PrestaShop.

Po pierwszym kwartale opieki agencja powinna przedstawić trzy rzeczy: opis stanu sklepu z dnia przejęcia, listę naprawionych problemów krytycznych i porównanie podstawowych wskaźników sprzed przejęcia i po nim. Bez punktu odniesienia z dnia przejęcia nie da się później ocenić, czy opieka cokolwiek poprawiła.   Co po trzech miesiącach powinno dać się zmierzyć: 1. Stan wyjściowy na piśmie: audyt techniczny wykonany na starcie wskazuje dług techniczny, nadpisania rdzenia i ryzykowne moduły, więc to on jest punktem odniesienia dla kolejnych raportów. 2. Liczba zgłoszeń i czas ich obsługi: ile było awarii, jak szybko zespół zaczynał pracę i ile problemów wykrył monitoring, zanim zauważyli je klienci sklepu. 3. Dostępność sklepu: mierzona niezależnym monitoringiem, a nie deklaracją. 4. Szybkość kluczowych podstron: czas odpowiedzi serwera i LCP na kategorii, karcie produktu i w koszyku. 5. Aktualizacje i bezpieczeństwo: które wersje i moduły zostały podniesione, a które czekają i z jakiego powodu.   Jeśli po kwartale agencja nie potrafi pokazać tych danych, problemem jest brak monitoringu i raportowania, a nie sam sklep. Sam proces przekazania sklepu opisuje odpowiedź o przejęciu sklepu od innej agencji, a wariant awaryjny odpowiedź o tym, jak przekazać rozwój sklepu nowemu wykonawcy w ciągu tygodnia. W abonamencie WayCare sklep i infrastruktura są monitorowane całą dobę, kluczowe funkcje przechodzą automatyczne testy, a backupy test odtwarzania.

Wiarygodne case study wydajnościowe podaje pomiar przed zmianą i po niej, wykonany w tych samych warunkach i na tych samych podstronach. Zdanie „sklep działa szybciej” niczego nie dowodzi, dopóki nie wiadomo, co i jak zmierzono.   Na jakie wskaźniki patrzeć: 1. Czas odpowiedzi serwera (TTFB): mierzony na kategorii i karcie produktu, a nie tylko na stronie głównej, która zwykle jest najlżejsza. 2. Largest Contentful Paint (LCP) z danych rzeczywistych użytkowników: czyli z raportu Core Web Vitals, a nie z jednorazowego testu w PageSpeed. 3. Zachowanie pod obciążeniem: przy jakim ruchu sklep zaczynał zwalniać przed zmianą i przy jakim zwalnia po niej, co pokazuje test wydajnościowy przed sezonem. 4. Dostępność w szczycie: czy sklep przetrwał kampanię albo Black Friday bez przestoju. 5. Wpływ na sprzedaż: zmiana współczynnika konwersji w porównywalnym okresie. To najmocniejszy dowód, ale najtrudniej przypisać go samej optymalizacji, więc rzetelna agencja zaznacza, co jeszcze zmieniło się w tym czasie.   Ostrożnie podchodź do wyników podanych wyłącznie w procentach, bez wartości wyjściowej, oraz do pomiarów z jednego dnia. W realizacjach Waynet wydajność była osobnym obszarem prac między innymi w sklepach Drapieżnik (cache Varnish na szczyty promocyjne), Nutropharma (CDN i szybsza wyszukiwarka przy ruchu z kampanii) oraz Goldenmark (warstwa cache przy wzmożonym ruchu), a taki zakres prac realizujemy w usłudze WayBooster.

Poproś o kontakt do klienta, którego sklep agencja utrzymuje od co najmniej roku, a nie do takiego, któremu tylko zbudowała sklep. Portfolio wdrożeń pokazuje, że agencja potrafi postawić sklep, natomiast o jakości utrzymania mówi dopiero to, jak zespół zachowuje się przy awariach, aktualizacjach i zmianach w działającym sklepie.   Pięć pytań do klienta referencyjnego, które dadzą Ci więcej niż odpowiedź „jest OK”: 1. Jak długo trwa współpraca i czy obejmuje stałą opiekę? Rok utrzymania mówi o agencji więcej niż trzy udane wdrożenia. 2. Ile trwała reakcja przy ostatniej poważnej awarii? Poproś o konkretny przykład: kiedy klient zgłosił problem, kiedy ktoś zaczął nad nim pracę i kiedy sklep znów sprzedawał. 3. Czy aktualizacje albo nowe funkcje coś zepsuły i co agencja wtedy zrobiła? Dopytaj, czy wycofała zmianę, naprawiła ją na własny koszt, czy wystawiła za poprawkę fakturę. 4. Kto pierwszy zauważa problemy: agencja czy klienci sklepu? Odpowiedź pokazuje, czy działa monitoring, czy zespół czeka na zgłoszenia. 5. Czy skład zespołu po stronie agencji się zmieniał i czy było to odczuwalne? W utrzymaniu ciągłość wiedzy o sklepie znaczy więcej niż w jednorazowym projekcie.   Rozmowę z referencją połącz z lekturą case studies, bo dobre studium przypadku opisuje problem, zastosowane rozwiązanie i efekt, a nie tylko listę funkcji. Pełną listę kryteriów znajdziesz w odpowiedzi o tym, jak sprawdzić wiarygodność agencji PrestaShop, a porównanie kandydatów ułatwi odpowiedź o wyborze agencji do stałej obsługi i rozwoju sklepu. W Waynet opieka techniczna i rozwój PrestaShop to osobna, stała usługa, dlatego o referencje warto pytać nas właśnie z tego obszaru, a nie tylko z wdrożeń.

W ciągu tygodnia realnie da się zrobić trzy rzeczy: zabezpieczyć dostępy, wykonać audyt otwierający i wdrożyć poprawki krytyczne. Czego nie da się zrobić bezpiecznie w tydzień, to większe prace rozwojowe w nieznanym kodzie. Kolejność ma znaczenie: najpierw dostępy i kopia zapasowa, potem diagnoza, dopiero na końcu zmiany. Odwrócenie tej kolejności jest najczęstszą przyczyną przestoju przy zmianie wykonawcy.

Zanim zadzwonisz do kogokolwiek, zabezpiecz pięć rzeczy. To jedyny etap, którego nie zrobi za Ciebie żadna agencja, a bez niego nowy zespół nie ruszy:

1. Dostęp do kodu i repozytorium. Jeśli kod jest tylko na serwerze, a nie w repozytorium, odnotuj to jako ryzyko numer jeden.
2. Dostęp do hostingu i panelu serwera, wraz z danymi do bazy.
3. Domena. Sprawdź, czy jest zarejestrowana na Waszą firmę, a nie na wykonawcę. To najczęstszy punkt zapalny przy rozstaniu.
4. Konta zewnętrzne: płatności, kurierzy, ERP, analityka, licencje modułów komercyjnych.
5. Świeża kopia zapasowa plików i bazy, pobrana na Wasz dysk, nie tylko „u wykonawcy”.

Realny harmonogram pierwszego tygodnia:

• Dzień 1 do 2: przekazanie dostępów, NDA, kopia zapasowa z testem odtworzenia, uruchomienie monitoringu.
• Dzień 2 do 4: audyt otwierający: stan kodu, nadpisania rdzenia, moduły bez wsparcia, integracje, wydajność. Wynikiem jest lista rzeczy krytycznych i plan.
• Dzień 4 do 7: środowisko testowe i naprawa rzeczy blokujących sprzedaż. Zmiany wchodzą poza godzinami szczytu, z możliwością szybkiego wycofania.
• Od drugiego tygodnia: prace rozwojowe, gdy zespół zna już środowisko.

Czego nie robić, nawet pod presją: nie zrywaj współpracy z dotychczasowym wykonawcą, zanim masz komplet dostępów i zweryfikowaną kopię zapasową. Nie przenoś hostingu w pierwszym tygodniu, bo migracja pod presją to najczęstsze źródło przestoju. Nie zaczynaj od nowych funkcji, tylko od stabilizacji. I nie zamawiaj prac bez środowiska testowego, nawet jeśli ktoś obiecuje, że „to drobna zmiana”.

Rozmowa z dotychczasowym dostawcą. Poproś na piśmie o dokumentację, listę środowisk, dostępy i informację o zaległych pracach. Nawet chłodne rozstanie zwykle kończy się przekazaniem materiałów, jeśli prośba jest konkretna i rzeczowa. Jeśli kontakt jest zerwany, audyt techniczny odtworzy większość obrazu z samego kodu, choć zajmie to więcej czasu.

W Waynet ten scenariusz przechodzimy regularnie, bo znaczna część sklepów pod naszą opieką trafiła do nas po innym wykonawcy. Start zaczyna się od audytu technicznego, a stabilizację i dalszy rozwój prowadzimy w ramach WayCare, gdzie SLA na incydenty wynosi poniżej 2 godzin, a monitoring działa 24/7. Pełny opis procesu znajdziesz w pytaniu jak wygląda przejęcie sklepu PrestaShop od innej agencji, a przed wyborem nowego partnera sprawdź czerwone flagi przy wyborze agencji.

Ani jedno, ani drugie nie jest bezpieczne samo z siebie. Moduł dedykowany daje pełną kontrolę nad kodem i mniejszą powierzchnię ataku, bo nie jest publicznie znany, ale jego bezpieczeństwo zależy wprost od jakości wykonawcy. Gotowy moduł z marketplace bywa lepiej przetestowany na tysiącach instalacji, ale wprowadza zależność od wydawcy, który może przestać go aktualizować.
Realne ryzyka gotowego rozszerzenia:

• Znane podatności. Popularny moduł jest publicznie opisany, więc luka w nim jest natychmiast skanowana masowo. To najczęstszy wektor ataku na sklepy PrestaShop, co pokazujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop, gdzie pierwszym punktem są niezałatane podatności CVE w modułach komercyjnych.
• Porzucenie przez wydawcę. Moduł bez aktualizacji od dwóch lat zostaje z Wami przy każdej kolejnej wersji PrestaShop.
• Nadmiarowe uprawnienia. Rozszerzenia często proszą o szerszy dostęp do danych, niż wymaga ich funkcja.

Realne ryzyka modułu dedykowanego:

• Brak zewnętrznego audytu. Kod widzi tylko wykonawca, więc błąd może żyć długo niezauważony.
• Bus factor. Jeśli moduł napisał jeden freelancer bez dokumentacji, utrzymanie po nim jest kosztowne.
• Aktualizacje na Was. Nikt nie wyda łatki za Was, gdy zmieni się rdzeń platformy.

Jak ocenić gotowy moduł przed instalacją, w pięciu krokach:

1. Data ostatniej aktualizacji i lista wspieranych wersji PrestaShop.
2. Historia zmian: czy wydawca reaguje na zgłoszenia bezpieczeństwa, czy tylko dodaje funkcje.
3. Zakres uprawnień i danych, do których moduł sięga.
4. Test na środowisku stagingowym, nigdy pierwsza instalacja na produkcji.
5. Plan wyjścia: co zrobicie, jeśli wydawca zniknie.

Kiedy funkcja wymaga rozwiązania dedykowanego: gdy dotyka danych osobowych lub płatności. Moduły płatnicze podlegają wymogom PCI DSS, a wszystko, co przetwarza dane klientów, podlega RODO, w tym obowiązkowi zgłoszenia naruszenia w 72 godziny. W takich obszarach kontrola nad kodem przestaje być wygodą i staje się wymogiem zgodności. Ten sam argument dotyczy integracji z ERP i magazynem, gdzie błąd nie tylko naraża dane, ale zatrzymuje sprzedaż.
Kiedy gotowy moduł w pełni wystarczy: funkcje standardowe i niekrytyczne, od wydawcy z aktualną historią zmian, przy sklepie z monitoringiem i aktualnymi kopiami zapasowymi. Trzecia droga, zwykle najbezpieczniejsza kosztowo: moduły autorskie agencji, która utrzymuje też Wasz sklep. Waynet rozwija katalog ponad 200 własnych modułów PrestaShop, aktualizowanych razem z platformą, a rozwiązania szyte na miarę realizujemy jako moduł PrestaShop na zamówienie. Zobacz też, jak wybrać między modułem dedykowanym a gotowym pod kątem kosztów i elastyczności oraz kto odpowiada za bezpieczeństwo sklepu PrestaShop.

Agencja ma sens, gdy nie macie w firmie programisty znającego PrestaShop, wdrożenie ma termin powiązany z sezonem sprzedażowym albo sklep od startu wymaga integracji z ERP i magazynem. Własny zespół wygrywa, gdy macie doświadczonych developerów, sklep jest rdzeniem biznesu i planujecie ciągły rozwój, a nie jednorazowy projekt. Przy zespole mieszanym najczęstszym błędem jest oddanie agencji wdrożenia bez ustalenia, kto utrzymuje sklep później.

Pięć kryteriów, które warto przyłożyć do własnej sytuacji:

1. 1. Budżet i jego struktura. Agencja to koszt projektowy, własny zespół to koszt stały. Rekrutacja i utrzymanie developera PrestaShop przez rok bywa droższa niż wdrożenie, ale przy ciągłym rozwoju proporcje się odwracają. Co realnie wpływa na wycenę, rozkładamy w tekście od czego zależy cena wdrożenia sklepu PrestaShop.
2. 2. Czas. Agencja startuje z gotowym zespołem i sprawdzonymi rozwiązaniami. Budowa kompetencji wewnętrznie to miesiące, a przy terminie powiązanym z sezonem zwykle nie ma tego zapasu.
3. 3. Kompetencje, ale te właściwe. Ogólne doświadczenie w PHP nie jest równe znajomości PrestaShop. Rdzeń, hooki i konflikty modułów to wiedza specyficzna, a jej brak generuje dług techniczny, którego skutki opisujemy w tekście o pięciu najczęstszych problemach technicznych w PrestaShop.
4. 4. Plany rozwoju. Jednorazowe wdrożenie i potem drobne zmiany to argument za agencją. Roadmapa z ciągłymi wdrożeniami co tydzień to argument za własnym zespołem lub modelem mieszanym.
5. 5. Odpowiedzialność za stabilność. Kluczowe pytanie: kto odbierze telefon, gdy sklep przestanie sprzedawać w piątek wieczorem. Własny zespół oznacza dyżury, urlopy i ryzyko jednej osoby. Agencja z SLA oznacza zapisany czas reakcji.

Kiedy agencja nie jest potrzebna: mały sklep na gotowym szablonie, bez integracji, z prostym katalogiem i akceptowalnym ryzykiem kilkugodzinnego przestoju. Wtedy własna konfiguracja plus doraźna pomoc wystarczą. Kiedy warto oprzeć się na gotowych rozwiązaniach zamiast budować od zera, opisujemy w tekście o szybkim starcie z PrestaShop.

Trzeci wariant, najczęstszy w średnich firmach: model mieszany. Wasz zespół odpowiada za treści, marketing i procesy biznesowe, a partner zewnętrzny za kod, serwer i bezpieczeństwo. Tak działa WayCare: infrastruktura, monitoring 24/7, bezpieczeństwo i prace programistyczne w jednym abonamencie, z jednym punktem kontaktu i SLA poniżej 2 godzin. Samo wdrożenie w wariancie pakietowym opisuje WayBox, a klasyczne wdrożenie PrestaShop ma sens przy nietypowych wymaganiach. Zobacz też, jak wybrać agencję PrestaShop do stałej obsługi oraz czy lepiej mieć jednego partnera, czy kilku podwykonawców.