Optymalizacja back office PrestaShop: zamówienia, statusy i praca zespołu

Optymalizacja back office PrestaShop dotyczy kosztu, który nie pojawia się w żadnym raporcie z analityki. Zespół obsługujący zamówienia pracuje w panelu codziennie, po kilka godzin. Jeśli ta praca wymaga przełączania się między panelem, arkuszem i systemem ERP, przepisywania danych i pamiętania obejść, których nikt nie spisał, sklep płaci za to czasem ludzi, a nie budżetem reklamowym.

To obszar, w którym poprawki są najtańsze w stosunku do odzyskanego czasu, bo w większości polegają na konfiguracji, a nie na programowaniu. Wymaga za to czegoś, co bywa trudniejsze niż kod: rozmowy z osobami, które obsługują zamówienia, i zapisania tego, co robią naprawdę.

Optymalizacja back office PrestaShop: jak rozpoznać potrzebę

Sygnały są dość jednoznaczne i żaden z nich nie wymaga narzędzi do wykrycia. Wystarczy usiąść obok osoby obsługującej zamówienia na godzinę.

• Zespół prowadzi własny arkusz równolegle do panelu. Najmocniejszy sygnał, jaki istnieje. Arkusz powstaje zawsze z tego samego powodu: panel nie pokazuje czegoś, co jest potrzebne do pracy.
• Statusy zamówień są używane umownie. Status „w przygotowaniu” oznacza w praktyce trzy różne sytuacje, a zespół rozróżnia je z pamięci albo z notatki w komentarzu.
• Eksport do księgowości odbywa się ręcznie. Ktoś raz w tygodniu pobiera listę zamówień, przerabia ją w arkuszu i wysyła mailem.
• Nowy pracownik uczy się tygodniami. Nie samego panelu, tylko obejść. To miara długu, jaki narósł w konfiguracji.
• Ta sama informacja jest wpisywana dwa razy. Do sklepu i do systemu ERP, do panelu i do arkusza kurierskiego.

Każdy z tych sygnałów da się przełożyć na godziny miesięcznie. To liczba, która uzasadnia prace w tym obszarze lepiej niż jakikolwiek argument o porządku.

Warto przy tym pamiętać, skąd te obejścia się biorą. Zespół nie prowadzi arkusza z przekory, tylko dlatego, że musiał sobie poradzić z czymś, czego panel nie obsługiwał, i poradził sobie najtańszym dostępnym sposobem. Każde takie obejście jest więc informacją o konkretnej luce, a nie powodem do uwag pod adresem ludzi. Rozmowa prowadzona w tym duchu przynosi pełniejszą listę niż audyt prowadzony zza biurka.

Statusy zamówień: odwzorowanie realnego procesu

Domyślny zestaw statusów w PrestaShop opisuje ogólny przebieg zamówienia i w żadnym sklepie nie odpowiada procesowi dokładnie. Firmy radzą sobie z tym na dwa sposoby: używają statusów umownie albo dokładają kolejne, aż lista przestaje się mieścić na ekranie.

Właściwa droga zaczyna się od spisania, przez jakie etapy przechodzi zamówienie w Twojej firmie, i to w wersji, którą opisze osoba je obsługująca, a nie w wersji z prezentacji. Dopiero potem porównujesz tę listę ze statusami w panelu.

Każdy status w PrestaShop niesie ze sobą zestaw zachowań, które ustawiasz świadomie:

Praktyczna zasada: liczba statusów ma odpowiadać liczbie realnych decyzji w procesie. Status, przy którym nikt nic nie robi inaczej, jest zbędny. Etap, który zespół rozróżnia z pamięci, potrzebuje własnego statusu. Zakres zachowań przypisanych do statusu oraz sposób obsługi zamówień w warstwie danych opisuje dokumentacja deweloperska PrestaShop.

Zmiany w tym obszarze wprowadzaj z zapasem czasu przed szczytem sprzedaży, nie w jego trakcie. Statusy wpływają na stany magazynowe, na numerację dokumentów i na wiadomości wychodzące do klientów, więc błąd w konfiguracji ujawnia się na wszystkich zamówieniach naraz. Kolejność jest tu ta sama co wszędzie: najpierw środowisko testowe z kopią danych, potem partia zamówień testowych przechodząca całą ścieżkę, dopiero na końcu produkcja.

Lista zamówień: kolumny, filtry i zapisane widoki

Lista zamówień jest ekranem, na którym zespół spędza najwięcej czasu, i jednocześnie tym, który najrzadziej dostosowuje się do sposobu pracy. Domyślny zestaw kolumn odpowiada na pytania administratora sklepu, a nie osoby kompletującej wysyłki.

Trzy zmiany, które zwykle dają najwięcej:

Kolumny dopasowane do zadania. Metoda dostawy, informacja o dokumencie sprzedaży i sposób płatności są w codziennej pracy ważniejsze niż część kolumn domyślnych. Panel pozwala je przestawić, a zmiana zajmuje minutę.

Filtry zapisane jako punkt startowy. Zespół zwykle pracuje na jednym wycinku: zamówienia opłacone i gotowe do wysyłki, zamówienia oczekujące na płatność dłużej niż dobę, zamówienia z odbiorem w punkcie. Ustawienie filtrów raz i zapisanie widoku eliminuje kilkanaście kliknięć przy każdym wejściu.

Operacje na wielu zamówieniach naraz. Zmiana statusu, wydruk dokumentów i etykiet dla zaznaczonej grupy zamiast pojedynczo. Przy kilkudziesięciu zamówieniach dziennie różnica jest liczona w godzinach tygodniowo.

Uprawnienia i profile pracowników

Częstym stanem zastanym jest jedno konto administratora używane przez kilka osób. Wygodne przez pierwszy miesiąc, kosztowne później: nie wiadomo, kto wprowadził zmianę, każdy widzi wszystko, a odejście pracownika oznacza zmianę hasła dla całego zespołu.

PrestaShop obsługuje profile z uprawnieniami na poziomie poszczególnych sekcji panelu. Rozsądny podział w sklepie z kilkuosobowym zespołem obejmuje trzy do czterech profili:

• Obsługa zamówień – zamówienia, klienci, zwroty, bez dostępu do konfiguracji i modułów.
• Katalog – produkty, kategorie, atrybuty, ceny, bez dostępu do zamówień.
• Marketing – promocje, treści, newsletter, bez dostępu do danych osobowych klientów poza tym, co potrzebne.
• Administrator – pełny dostęp, przypisany imiennie, z osobnym kontem dla każdej osoby.

Podział ma też wymiar ochrony danych: dostęp do danych osobowych klientów powinien wynikać z zakresu obowiązków. Szerzej o warstwie bezpieczeństwa piszemy w tekście o bezpieczeństwie w PrestaShop.

Integracje: gdzie kończy się sklep, a zaczyna reszta firmy

Ręczne przepisywanie danych między sklepem a systemem ERP jest najdroższą pojedynczą czynnością w back office i jednocześnie najczęstszą. Powód rzadko jest techniczny. Zwykle integracja nie powstała, bo w momencie uruchamiania sklepu zamówień było kilka dziennie i przepisywanie zajmowało kwadrans.

Przy ocenie, co zintegrować najpierw, liczy się iloczyn częstotliwości i pracochłonności, a nie sama złożoność techniczna. Cztery przepływy, od których zwykle się zaczyna:

Przy każdej integracji dwie rzeczy rozstrzygają o tym, czy będzie działać po roku. Pierwsza to obsługa błędów: co się dzieje, gdy druga strona nie odpowiada, i kto się o tym dowiaduje. Integracja bez powiadomienia o błędzie cicho przestaje działać, a rozjazd danych odkrywa się przy inwentaryzacji. Druga to kierunek nadrzędny: dla każdego pola musi być ustalone, który system jest źródłem prawdy. Bez tego dwa systemy nadpisują się nawzajem.

Zwroty i reklamacje: proces, który zwykle żyje poza sklepem

PrestaShop obsługuje zwroty towaru i reklamacje wbudowanym mechanizmem, a mimo to w większości sklepów proces ten toczy się mailowo, z arkuszem po stronie obsługi. Powód jest ten sam co zwykle: mechanizm nie został skonfigurowany przy uruchamianiu sklepu, bo zwrotów było wtedy kilka miesięcznie.

Koszt takiego stanu jest podwójny. Klient nie widzi statusu swojego zgłoszenia, więc dzwoni i pisze, co obciąża obsługę. Firma nie ma danych o tym, które produkty wracają najczęściej i z jakiego powodu, a to jedna z najbardziej użytecznych informacji, jakie ma sklep, bo wskazuje wprost na błędy w opisach albo na problem z konkretnym dostawcą.

Uruchomienie tego obszaru wymaga trzech rzeczy: włączenia zwrotów w konfiguracji z ustawionym terminem zgodnym z regulaminem, przygotowania listy powodów zwrotu, którą wybiera klient, oraz przypisania statusów zgłoszenia do realnych etapów obsługi. Lista powodów jest tym elementem, który daje dane, więc warto ją ustalić z zespołem obsługi, a nie przepisać z ustawień domyślnych.

Prawa klienta w tym obszarze wynikają z przepisów i wymagają potwierdzenia z prawnikiem albo księgowością, zwłaszcza przy sprzedaży zagranicznej, gdzie terminy i obowiązki informacyjne bywają inne niż krajowe.

Codzienna praca z katalogiem

Druga po zamówieniach czynność, która pochłania czas zespołu, to wprowadzanie i aktualizowanie produktów. Kilka rzeczy skraca ją wyraźnie.

• Import z pliku zamiast wprowadzania ręcznego. PrestaShop obsługuje import produktów, kombinacji i stanów. Przygotowanie szablonu pliku raz oszczędza godziny przy każdej nowej partii towaru.
• Edycja masowa. Zmiana ceny albo dostępności dla całej grupy produktów bez wchodzenia w każdy z osobna.
• Ustalona konwencja nazewnictwa. Spisana i dostępna dla zespołu. Bez niej ten sam atrybut wchodzi do sklepu w czterech wariantach zapisu, a filtry przestają działać. Rozwijamy to w tekście o optymalizacji katalogu PrestaShop.
• Jedno miejsce, w którym powstają dane produktowe. Przy katalogu liczonym w tysiącach pozycji i kilku kanałach sprzedaży rolę tę przejmuje osobny system zarządzania danymi, opisany przy okazji integracji Akeneo z PrestaShop.

Wiadomości do klienta: obszar, który zdejmuje pracę z obsługi

Każde pytanie „gdzie jest moje zamówienie” to kilka minut pracy obsługi i sygnał, że klient nie dostał informacji, której oczekiwał. Szablony wiadomości w PrestaShop obsługują ten obszar automatycznie, ale w wersji domyślnej są zwięzłe do granicy nieużyteczności.

Trzy wiadomości, które warto przepisać w pierwszej kolejności, bo generują najwięcej zapytań:

• Potwierdzenie zamówienia. Poza numerem i listą pozycji powinno zawierać przewidywany termin wysyłki i informację, co dzieje się dalej. To ta wiadomość zastępuje pierwsze pytanie do obsługi.
• Zmiana statusu na wysłane. Numer przesyłki jako odnośnik do śledzenia, nie jako ciąg znaków do skopiowania. Różnica w liczbie zapytań jest wyraźna.
• Oczekiwanie na płatność. Z podanym terminem, po którym zamówienie zostanie anulowane, i z odnośnikiem pozwalającym dokończyć płatność. Bez tego zamówienia wiszą, a magazyn jest zablokowany.

Przy okazji przeglądu warto sprawdzić, które statusy w ogóle wysyłają wiadomości. Statusy techniczne, wprowadzone dla porządku wewnętrznego, nie powinny generować powiadomień. Klient otrzymujący pięć maili o jednym zamówieniu przestaje czytać wszystkie, łącznie z tym, który był istotny.

Wydajność panelu

Panel administracyjny bywa wolniejszy od sklepu i zwykle nikt tego nie mierzy, bo klienci go nie widzą. Widzi go za to zespół, przez kilka godzin dziennie, a każde oczekiwanie na wczytanie listy zamówień mnoży się przez liczbę wejść.

Prosty pomiar, który warto wykonać raz: zmierz czas wczytania listy zamówień z domyślnym filtrem i pomnóż go przez liczbę wejść dziennie razy liczba osób w zespole. Wynik wyrażony w godzinach miesięcznie zwykle wystarcza, żeby uzasadnić prace, na które wcześniej nie było budżetu, bo panel „przecież działa”.

Trzy najczęstsze przyczyny wolnego panelu w sklepie z historią: rozrośnięte tabele logów i statystyk, które nigdy nie były czyszczone; moduły dokładające własne zapytania do widoku listy zamówień; oraz brak indeksów na kolumnach używanych do filtrowania po dołożeniu własnych pól. Wszystkie trzy leżą po stronie bazy danych i adresuje je optymalizacja wydajności PrestaShop.

Od czego zacząć porządki

Kolejność, która daje efekt najszybciej, bo zaczyna od rzeczy nie wymagających programowania:

1. Godzina obserwacji. Usiądź obok osoby obsługującej zamówienia i zapisz każdą czynność wykonywaną poza panelem. Ta lista jest planem prac.
2. Statusy i widoki. Dopasowanie statusów do realnego procesu i ustawienie zapisanych widoków listy zamówień. Konfiguracja, jeden dzień.
3. Profile uprawnień. Imienne konta zamiast wspólnego administratora. Pół dnia.
4. Najdroższa integracja. Jedna, wybrana po iloczynie częstotliwości i pracochłonności. Zwykle stany magazynowe albo zamówienia do systemu ERP.
5. Import i edycja masowa katalogu. Przygotowanie szablonów i przeszkolenie zespołu.
6. Spisanie procedur. Krótki dokument opisujący obsługę zamówienia, zwrotu i reklamacji. Skraca wdrożenie nowej osoby z tygodni do dni.

Efekt tej pracy warto zmierzyć w jednostce, którą rozumie zarząd: w godzinach odzyskanych miesięcznie. Liczba czynności wykonywanych poza panelem, pomnożona przez ich częstotliwość i czas trwania, daje wartość przed zmianą. Powtórzony pomiar po kwartale daje wartość po. To jedyny obszar optymalizacji sklepu, w którym efekt da się policzyć tak bezpośrednio, bez zakładania czegokolwiek o zachowaniu klientów.

Trzy pierwsze punkty mieszczą się w dwóch dniach i nie wymagają wykonawcy technicznego. To rzadka sytuacja w optymalizacji sklepu, gdzie większość prac wymaga specjalistów. Dlatego właśnie back office bywa dobrym miejscem na start: pokazuje zespołowi, że praca nad sklepem przynosi odczuwalny efekt, i buduje zgodę na dłuższe, droższe etapy. Miejsce back office wśród pozostałych obszarów pokazuje przewodnik o optymalizacji PrestaShop.