Utrzymanie
Opieka nad sklepem
PrestaShop
W sklepie internetowym awaria kosztuje inaczej niż na stronie firmowej. Godzina bez działającego koszyka to nie tylko brak zamówień z tej godziny, ale też klienci, którzy zdążyli kupić gdzie indziej i już nie wrócą.
Dlaczego sklep wymaga innej opieki niż strona
PrestaShop to system znacznie bardziej złożony od typowej strony firmowej. Poza samym silnikiem i szablonem działa w nim zwykle kilkanaście modułów odpowiadających za płatności, przesyłki, integracje z magazynem, fakturowanie i marketing. Każdy z nich dotyka procesu, w którym po drugiej stronie są pieniądze klienta.
Skutkuje to inną hierarchią problemów. Na stronie firmowej najgorsze, co się zdarza, to niedziałający formularz. W sklepie awaria potrafi być cichsza i droższa: płatność przechodzi, ale zamówienie nie zapisuje się w systemie. Albo koszyk działa na komputerze, a na telefonie przycisk zamówienia znika pod belką z ciasteczkami.
Dlatego opieka nad sklepem to nie tylko aktualizacje. To także regularne przechodzenie całej ścieżki zakupowej — od karty produktu, przez koszyk i dostawę, po realną płatność testową i potwierdzenie mailem.
Zakres stałej obsługi sklepu
Punktem wyjścia jest lista czynności wykonywanych cyklicznie. Do tego dochodzą sprawy zgłaszane na bieżąco, obsługiwane w ramach godzin z pakietu.
- Aktualizacje silnika i modułów, zawsze najpierw na kopii testowej
- Kopia zapasowa plików i bazy przechowywana poza serwerem sklepu
- Comiesięczny test zakupu: koszyk, dostawa, płatność, faktura, mail
- Monitoring dostępności i czasu odpowiedzi sklepu
- Kontrola poprawności integracji z magazynem i kurierami
- Przegląd wydajności listingu i wyszukiwarki wewnętrznej
- Porządkowanie bazy: koszyki porzucone, logi, stare sesje
- Pula godzin na zmiany w treści, kategoriach i konfiguracji
Stare wersje: kiedy aktualizować, a kiedy przepisać sklep
Duża część sklepów w Polsce działa na wersjach 1.6 i 1.7, które nie dostają już poprawek bezpieczeństwa albo dostają je w ograniczonym zakresie. Aktualizacja do wersji 8 bywa prosta, ale przy mocno przerobionym szablonie i kilkunastu płatnych modułach staje się osobnym projektem.
Zanim cokolwiek doradzimy, sprawdzamy trzy rzeczy: ile modułów ma odpowiedniki w nowej wersji, jak bardzo zmieniony jest szablon i czy istnieją własne przeróbki w kodzie silnika. Ostatni punkt jest kluczowy, bo takie zmiany znikają przy aktualizacji i wracają jako niespodzianka po wdrożeniu.
Czasem wniosek brzmi: nie aktualizować, tylko zbudować sklep od nowa i przenieść dane. Wychodzi to podobnie kosztowo, a zostawia sklep, który da się rozwijać przez kolejne lata. Mówimy to wprost, także gdy oznacza to większy projekt niż zakładałeś.
| Sytuacja | Rekomendacja | Orientacyjny wysiłek |
|---|---|---|
| Standardowy szablon, kilka modułów | Aktualizacja do 8.x | kilka dni |
| Przerobiony szablon, moduły płatne | Aktualizacja etapami | 2–4 tygodnie |
| Zmiany w kodzie silnika | Budowa nowego sklepu i migracja | projekt |
| Sklep na 1.6 bez wsparcia autorów | Migracja, także na WooCommerce | projekt |
Płatności i przesyłki, czyli miejsca, gdzie boli najbardziej
Moduły płatnicze aktualizują się niezależnie od sklepu, a ich dostawcy zmieniają sposób komunikacji częściej, niż sklepy o tym pamiętają. Najczęstszy scenariusz to wygasły klucz albo zmiana adresu powiadomień, po której płatność jest pobierana, ale zamówienie zostaje w statusie oczekującym.
Sprawdzamy to comiesięcznym testem: realna transakcja na niską kwotę, przejście całej ścieżki i weryfikacja, czy zamówienie zmieniło status, czy poszedł mail i czy dokument sprzedaży się wygenerował. Kwotę zwracamy, a Ty masz pewność, że proces działa dziś, a nie działał w dniu wdrożenia.
Podobnie z przesyłkami: cenniki kurierów się zmieniają, a błędnie przeliczona dostawa potrafi po cichu zjadać marżę na każdym zamówieniu przez wiele tygodni, zanim ktoś to zauważy w rozliczeniu.
To nie ta, przy której sklep nie działa — tę widać od razu. To ta, przy której wszystko wygląda normalnie, a zamówienia po prostu nie dochodzą.
Wydajność sklepu przy rosnącym katalogu
PrestaShop zwalnia w sposób przewidywalny: wraz z liczbą produktów, kombinacji i filtrów. Sklep, który przy pięciuset produktach działał świetnie, przy pięciu tysiącach potrafi ładować listing kilka sekund — a to bezpośrednio przekłada się na liczbę porzuconych wizyt.
Typowe przyczyny są znane: brak indeksów w bazie po imporcie, filtry przeliczane przy każdym wejściu, wyłączone mechanizmy pamięci podręcznej i zdjęcia serwowane w rozmiarach oryginalnych. Zobacz też optymalizację baz danych, jeśli sklep obsługuje duży katalog.
Przy większych katalogach sprawdzamy dodatkowo, czy serwer w ogóle odpowiada wymaganiom. Sklep z kilkunastoma tysiącami pozycji na współdzielonym hostingu za kilkadziesiąt złotych rocznie to problem, którego nie da się rozwiązać samą optymalizacją kodu.
Integracje z magazynem i księgowością
Większość sklepów, które prowadzimy, wymienia dane z systemem magazynowym: stany, ceny, zamówienia i dokumenty sprzedaży. Ta wymiana bywa najbardziej wrażliwym elementem całości, bo problem po jednej stronie natychmiast widać po drugiej.
W ramach opieki pilnujemy, żeby synchronizacja faktycznie chodziła i żeby błędy nie ginęły w logach. Sprawdzamy liczbę zsynchronizowanych pozycji, wychwytujemy produkty, które wypadły z wymiany, i reagujemy, gdy stany w sklepie zaczynają się rozjeżdżać z magazynem. Więcej o samych połączeniach: integracje z ERP.
Ile kosztuje opieka nad sklepem
Sklep wymaga więcej pracy niż strona firmowa, więc i abonament jest wyższy. Poniższe kwoty to punkt wyjścia — ostateczna zależy od wielkości katalogu, liczby integracji i tego, ile zmian ma być wliczonych w miesiąc.
| Pakiet | Dla kogo | Godziny w cenie | Cena |
|---|---|---|---|
| Bezpieczeństwo | Mały sklep, do 500 produktów | 1 h | od 249 zł / mies. |
| Standard | Sklep z integracją magazynu | 4 h | od 499 zł / mies. |
| Rozwój | Sklep z ruchem i kampaniami | 10 h | od 999 zł / mies. |
Godziny niewykorzystane w danym miesiącu przechodzą na kolejny, do wysokości jednego pakietu. Nie chodzi o to, żeby sztucznie wypełniać czas pracą, tylko żeby w miesiącu z większą potrzebą było z czego czerpać.
Sklep działa bez zarzutu, a wszelkie drobne poprawki robione są od ręki.
Przejęcie sklepu po innym wykonawcy
Sporo zgłoszeń zaczyna się od zdania, że poprzednia firma przestała odpisywać. Robimy wtedy przegląd startowy: co jest zainstalowane, w jakiej wersji, gdzie leżą kopie, jakie moduły są płatne i czy licencje są przypisane do właściwej firmy.
Ten ostatni punkt bywa nieprzyjemną niespodzianką. Płatne moduły kupione na konto wykonawcy działają dalej, ale nie da się ich zaktualizować bez jego udziału. Pomagamy to uporządkować — czasem przez przepisanie licencji, czasem przez zakup na nowo, ale zawsze z jasną informacją o koszcie przed decyzją.
Przegląd startowy jest bezpłatny i kończy się listą znalezisk uporządkowaną według pilności. Nawet jeśli nie zdecydujesz się na współpracę, wiesz, co masz.
- Moduły płatne przypisane do konta byłego wykonawcy
- Brak środowiska testowego — zmiany robione na żywym sklepie
- Kopie zapasowe tylko na serwerze sklepu
- Silnik bez aktualizacji bezpieczeństwa od lat
- Zmiany wprowadzone bezpośrednio w kodzie silnika
Współpraca
Jak to wygląda krok po kroku
Przegląd startowy
Wersje, moduły, licencje, kopie, wydajność, bezpieczeństwo. Raport z listą znalezisk.
Uporządkowanie
Środowisko testowe, kopie poza serwerem, zaległe aktualizacje, monitoring.
Praca cykliczna
Aktualizacje na kopii, test zakupu, przegląd integracji, raport miesięczny.
Zgłoszenia bieżące
Zmiany i drobne poprawki w ramach godzin z pakietu, z jasnym priorytetem.
Rozwój sklepu
Nowe funkcje i integracje wyceniane osobno, wdrażane najpierw na kopii.
Pytania
Zanim zapytasz
Tak. Prowadzimy oba systemy i pomagamy wybrać, gdy sklep trzeba budować od nowa — zobacz sklepy internetowe. Przy migracji z PrestaShop przenosimy produkty, klientów i zamówienia razem z przekierowaniami.
Tak. Aktualizację przygotowujemy na kopii, testujemy pełną ścieżkę zakupu i dopiero wtedy przełączamy. Przestój ogranicza się zwykle do kilku minut i planujemy go na porę najmniejszego ruchu.
Sprawdzamy zakres zmian przed aktualizacją. Jeśli przeróbki są w szablonie, zwykle da się je przenieść. Jeśli w kodzie silnika — mówimy o tym wprost, bo to zmienia zarówno koszt, jak i rekomendację.
Tak, realną transakcją na niską kwotę, którą potem zwracamy. Testy w trybie piaskownicy nie wychwytują części problemów, które pojawiają się dopiero na produkcji.
W godzinach pracy podejmujemy temat zwykle w ciągu dwóch godzin. Dla sklepów z pakietu Rozwój ustalamy indywidualne czasy reakcji, także poza standardowymi godzinami.
Tak. Przed okresami takimi jak Black Friday sprawdzamy wydajność pod obciążeniem i przygotowujemy sklep na większy ruch. To praca, którą trzeba wykonać z wyprzedzeniem, nie w dniu kampanii.
Powiązane usługi
Co jeszcze może się przydać
Twoje miasto
Opieka nad sklepem PrestaShop w Twoim mieście
Dla każdego z tych miast mamy osobną stronę z lokalnym rynkiem, cenami i przykładami — a nie ten sam tekst z podmienioną nazwą.
Zajmiemy się Twoim sklepem PrestaShop
Podaj adres sklepu — zrobimy bezpłatny przegląd startowy i powiemy, co wymaga pilnej uwagi, co może poczekać, a co da się poprawić od ręki.