Dlaczego dobre rekomendacje e-commerce nie są wdrażane? Od audytu do wykonania

Dlaczego sama dobra rekomendacja nie wystarcza?

Zdanie:

Checkout wymaga poprawy.

może być całkowicie prawdziwe.

Ale nadal niewiele mówi osobie, która ma coś z tym zrobić.

Warstwa wykonawcza zaczyna się dopiero wtedy, gdy potrafimy powiedzieć:

W konkretnym miejscu checkoutu obserwujemy problem X. Dane lub analiza wskazują możliwą przyczynę Y. Wprowadzamy zmianę Z. Za doprowadzenie jej do wdrożenia odpowiada określona osoba lub funkcja. Po wdrożeniu sprawdzamy, czy sytuacja rzeczywiście się zmieniła.

To już można realizować.

Podobna różnica występuje między:

poprawić analitykę

a konkretnym zadaniem dotyczącym np. naprawy przekazywania wartości zdarzenia zakupu, zweryfikowania implementacji i dopiero późniejszego wykorzystywania tych danych do oceny działań.

Rekomendacja wskazuje kierunek. Zadanie uruchamia wykonanie.

Audyt może całkowicie poprawnie zakończyć się na rekomendacji. To nie jest zarzut wobec audytora. Zakres jego pracy może po prostu nie obejmować późniejszej koordynacji wdrożeń.

Problem pojawia się wtedy, gdy po przekazaniu dokumentu firma nie posiada dalszego mechanizmu działania.

Jeżeli chcesz zobaczyć wcześniejszy etap tego procesu, szerzej opisuję go w artykule Audyt e-commerce: co powinien sprawdzać, żeby prowadził do realnych decyzji?

7 powodów, przez które rekomendacje e-commerce nie są wdrażane

1. Wszystko zostaje uznane za priorytet

Jeżeli po audycie firma ma kilkadziesiąt ważnych zadań i większość z nich otrzymuje status „pilne”, realnie nie ma żadnych priorytetów.

Ma tylko długą listę rzeczy, które ktoś powinien zrobić możliwie szybko.

Efekt jest przewidywalny:

• rozpoczynanych jest wiele tematów jednocześnie,
• kolejność ciągle się zmienia,
• wykonawcy przeskakują między zadaniami,
• część prac zostaje rozpoczęta, ale nie zakończona,
• każda nowa sytuacja wymaga kolejnej decyzji właściciela,
• najgłośniejszy problem zastępuje poprzedni priorytet.

Priorytet nie oznacza:

to jest ważne.

Oznacza:

spośród wszystkich ważnych rzeczy właśnie tym zajmujemy się teraz.

A to automatycznie wymaga drugiej decyzji:

Czego teraz nie robimy?

Dlatego backlog po audycie trzeba uporządkować, a nie tylko zaakceptować. Sposób porównywania wpływu, kosztu, ryzyka i zależności opisuję szerzej w artykule Jak ustalić priorytety rozwoju sklepu internetowego?

2. Rekomendacja jest za ogólna, żeby stała się zadaniem

„Poprawić UX.”

„Zwiększyć konwersję.”

„Rozwinąć e-mail marketing.”

„Poprawić analitykę.”

„Przyspieszyć sklep.”

To nie są zadania.

To kierunki.

Weźmy rekomendację:

poprawić checkout.

Najpierw potrzebujemy problemu.

Przykładowo: użytkownik nie otrzymuje odpowiednio wcześnie informacji o warunkach dostawy.

Dopiero później określamy konkretną zmianę oraz warunek, po którym będzie można stwierdzić, że została wykonana zgodnie z założeniem.

Czy informacja rzeczywiście jest widoczna? Czy działa na mobile? Czy tekst odpowiada aktualnym zasadom sklepu?

Bez tego wykonawca może „zrealizować rekomendację”, a osoba zamawiająca mieć w głowie zupełnie inne rozwiązanie.

Dobre zadanie ogranicza pole do takich interpretacji.

Nie potrzebuje do tego kilkustronicowej specyfikacji. Czasami wystarczy kilka dobrze napisanych zdań.

3. Nie wiadomo, kto naprawdę odpowiada za temat

Zdanie:

developer ma to zrobić

określa wykonawcę części pracy.

Nie odpowiada jednak na pytanie:

Kto odpowiada za doprowadzenie zmiany od decyzji do rezultatu?

W jednym wdrożeniu mogą uczestniczyć:

• właściciel,
• E-commerce Manager,
• UX,
• developer,
• specjalista Ads,
• analityk,
• content.

To normalne.

Problem pojawia się wtedy, gdy każda osoba wykonuje tylko swój fragment, ale nikt nie pilnuje całej ścieżki.

Developer czeka na treść. Content czeka na decyzję właściciela. Właściciel zakłada, że temat prowadzi developer.

Po pewnym czasie wszyscy nadal „są w procesie”.

Nie potrzebujemy do rozwiązania tego problemu skomplikowanej metodologii.

Potrzebujemy jednej odpowiedzi:

Kto pilnuje, żeby temat rzeczywiście doszedł do końca?

Wiele osób może wykonywać pracę. Odpowiedzialność za domknięcie zadania nie powinna być rozmyta pomiędzy wszystkich.

4. Zadanie ma nierozwiązane zależności

Część projektów wygląda na opóźnione, choć tak naprawdę nigdy nie była gotowa do rozpoczęcia.

Przykłady:

• chcemy zwiększyć skalę kampanii, ale wartości konwersji są przekazywane błędnie,
• chcemy uruchomić automatyzację, ale dane klientów nie są przygotowane do potrzebnego podziału,
• chcemy przebudować kartę produktu, ale nie istnieją jeszcze potrzebne zdjęcia i treści,
• chcemy mierzyć nowy etap procesu, ale potrzebne zdarzenie nie zostało wdrożone,
• chcemy zmienić ofertę, ale nadal nie ma decyzji dotyczącej ceny.

W takiej sytuacji wrzucenie głównego zadania do realizacji tworzy tylko kolejny element w statusie „w toku”.

Przed rozpoczęciem warto więc zapytać:

Co musi istnieć, żeby to zadanie rzeczywiście mogło zostać wykonane?

Jeżeli najpierw potrzebujemy treści, pierwszym zadaniem nie jest development.

Jeżeli najpierw potrzebujemy decyzji biznesowej, nie ma sensu blokować czasu wykonawcy.

Kolejność jest częścią realizacji.

5. Bieżąca sprzedaż zawsze wygrywa z rozwojem

Ten problem jest szczególnie typowy, bo bieżący biznes zawsze dostarcza nowych pilnych tematów.

• Nadchodzi promocja.
• Trzeba przygotować mailing.
• Kampanie wymagają reakcji.
• Magazyn zgłasza problem.
• Klient czeka na odpowiedź.
• Coś przestaje działać.

Rozwojowe zadanie zostaje przesunięte.

Potem pojawia się kolejna pilna rzecz.

I kolejna.

W efekcie firma dobrze utrzymuje codzienną sprzedaż, ale projekty, które miały poprawić jej przyszłe działanie, przesuwają się między kolejnymi tygodniami.

Nie chodzi o ignorowanie bieżących problemów.

Sprzedaż musi działać.

Trzeba jednak rozdzielić w zarządzaniu:

• utrzymanie obecnego biznesu,
• zmiany mające poprawić jego przyszłe działanie.

Jeżeli rozwój nie posiada realnie zarezerwowanej przestrzeni wykonawczej, zwykle będzie przegrywał z zadaniami, które są pilne dzisiaj.

Nie potrzeba do tego sztywnej zasady dotyczącej procentu czasu przeznaczonego na rozwój.

Potrzebna jest świadoma decyzja, że wybrane inicjatywy nie znikają za każdym razem, gdy pojawi się kolejny temat operacyjny.

6. Zakres zmienia się w trakcie wdrożenia

Zaczynamy od poprawy jednego elementu checkoutu.

W trakcie pojawia się:

To może od razu zmieńmy layout.

Potem:

Przy okazji dodajmy integrację.

Następnie:

Skoro już to ruszamy, przebudujmy cały formularz.

Mała zmiana stopniowo staje się dużym projektem.

Rośnie koszt, liczba zależności, liczba potrzebnych decyzji i ryzyko błędów.

Później trudniej również odpowiedzieć, która ze zmian rzeczywiście wpłynęła na obserwowany wynik.

Nie oznacza to, że raz określonego zakresu nigdy nie wolno zmieniać.

W trakcie realizacji mogą pojawić się nowe informacje, które uzasadniają rozszerzenie projektu.

Powinna to jednak być nowa, świadoma decyzja, a nie automatyczne dokładanie wszystkiego, co „przy okazji” można jeszcze poprawić.

7. Nikt nie wraca do zadania po wdrożeniu

Typowy przebieg wygląda tak:

zadanie → development → produkcja → WDROŻONE → zamykamy.

A właśnie wtedy zaczyna się druga połowa pytania.

• Czy technicznie działa?
• Czy zachowanie użytkowników się zmieniło?
• Czy rozwiązaliśmy problem, który był powodem wdrożenia?
• Czy wynik jest zgodny z przyjętą hipotezą?
• Czy potrzebna jest kolejna iteracja?

Nie każda zmiana wymaga eksperymentu A/B.

Nie każda ma jedną idealną metrykę.

Czasem rezultatem jest usunięcie błędu. Czasem poprawa jakości danych. Czasem usprawnienie pracy operacyjnej. Czasem zmiana zachowania użytkownika, którą można obserwować w analityce.

GA4 pozwala weryfikować przesyłane zdarzenia i parametry w DebugView, a raport Checkout journey może pomagać obserwować przejścia użytkowników pomiędzy kolejnymi etapami procesu zakupowego, jeżeli odpowiednie zdarzenia zostały prawidłowo wdrożone.

Najważniejsze jest jednak coś innego:

Dla istotnej zmiany jeszcze przed wdrożeniem powinniśmy wiedzieć, jak później będziemy oceniać jej rezultat.

Od rekomendacji do wdrożenia — jak powinien wyglądać proces?

Nie potrzebujemy ciężkiego systemu zarządzania.

Potrzebujemy ciągłości pomiędzy decyzją i wynikiem.

DIAGNOZA
↓
PRIORYTET
↓
ZADANIE
↓
WŁAŚCICIEL
↓
ZALEŻNOŚCI
↓
REALIZACJA
↓
WERYFIKACJA
↓
DECYZJA

Diagnoza — co chcemy zmienić i dlaczego?

Najpierw problem.

Nie „wdrażamy nowy checkout”, tylko „obserwujemy konkretne ograniczenie i mamy określoną hipotezę dotyczącą jego przyczyny”.

Priorytet — dlaczego teraz?

Dlaczego właśnie to zadanie wygrywa z pozostałymi?

Zadanie — co konkretnie wykonujemy?

Zakres powinien być jednoznaczny dla osoby realizującej i odbierającej.

Właściciel — kto pilnuje końca?

Nie tylko kto programuje, pisze albo konfiguruje.

Kto odpowiada za to, że temat przejdzie całą drogę?

Zależności — co musi być gotowe wcześniej?

Materiały, dane, dostępy, decyzja cenowa, projekt, tracking — zależnie od konkretnego zadania.

Realizacja — kto wykonuje poszczególne części?

Tutaj angażujemy właściwe kompetencje.

Weryfikacja — czy działa?

Najpierw technicznie. Później — jeżeli ma to zastosowanie — biznesowo.

Decyzja — co dalej?

Po zebraniu informacji możemy:

• zostawić rozwiązanie,
• poprawić je,
• zwiększyć skalę,
• wycofać,
• wykonać kolejną iterację,
• przejść do następnego priorytetu.

Dopiero wtedy pętla jest zamknięta.

Jak powinno wyglądać dobre zadanie e-commerce?

Dobre zadanie nie musi być rozbudowaną dokumentacją.

Powinno po prostu usunąć najważniejsze niejednoznaczności.

Problem

Co obserwujemy?

Cel

Co chcemy zmienić?

Uzasadnienie

Dlaczego ten temat jest ważny?

Zakres

Co dokładnie wykonujemy?

Poza zakresem

Czego świadomie nie zmieniamy w ramach tego zadania?

Odpowiedzialność

Kto pilnuje tematu od rozpoczęcia do odbioru i późniejszej weryfikacji?

Zależności

Jakich materiałów, decyzji, dostępów lub wcześniejszych wdrożeń potrzebujemy?

Warunek wdrożenia

Po czym wiemy, że zadanie zostało technicznie zrealizowane zgodnie z założeniami?

Sposób oceny

Co później sprawdzimy, żeby ocenić rezultat?

Przy dużym wdrożeniu każdy z tych elementów może wymagać rozwinięcia.

Przy małej zmianie wszystko może zmieścić się w kilku zdaniach.

Celem jest jednoznaczność, nie biurokracja.

Backlog nie jest planem rozwoju

Backlog jest magazynem.

Może zawierać:

• błędy,
• pomysły,
• hipotezy,
• rekomendacje,
• potrzeby klientów,
• zadania techniczne,
• inicjatywy marketingowe.

I może być prowadzony bardzo dobrze.

Nadal nie jest planem.

Plan odpowiada na inne pytania:

Co robimy teraz? Co później? W jakiej kolejności? Kto za to odpowiada? Co musi wydarzyć się wcześniej?

Firma może mieć setki perfekcyjnie opisanych zadań i jednocześnie bardzo słabo zarządzać rozwojem, jeżeli co tydzień wybiera z tej listy coś innego.

Liczba zapisanych pomysłów nie świadczy o jakości zarządzania.

Plan powinien zawierać ograniczoną liczbę aktywnych tematów, odpowiadającą realnym możliwościom firmy.

Nie ma jednej poprawnej liczby dla każdego e-commerce.

Istotniejsze jest, czy rozpoczęte prace faktycznie kończą się wdrożeniem i oceną.

Dlaczego zbyt wiele rozpoczętych projektów spowalnia e-commerce?

Każde nowe zadanie wygląda początkowo jak dodatkowy postęp.

W praktyce zwiększa również liczbę rzeczy, które trzeba koordynować.

• Jeden projekt czeka na developera.
• Drugi na decyzję.
• Trzeci na materiały.
• Czwarty jest w testach.
• Piąty wymaga poprawki.
• Szósty został prawie skończony, ale zmienił się zakres.

Im więcej równoległych prac, tym więcej zależności, przekazywania informacji, oczekiwania i przełączania uwagi.

Trudniej również ocenić efekty.

Jeżeli w podobnym czasie jednocześnie zmienimy checkout, ofertę, reklamy, promocję i komunikację e-mailową, późniejsza interpretacja zmiany wyniku może stać się znacznie trudniejsza.

Dlatego często większą wartość daje:

skończyć kilka ważnych działań, sprawdzić je i dopiero później otworzyć następne

niż rozpocząć kilkanaście projektów, żeby wszystko było „w realizacji”.

Jak pracować z agencją, developerem i innymi wykonawcami?

Specjalista naturalnie patrzy przez swój obszar.

Osoba od Google Ads widzi możliwości w kampaniach. Developer zauważa problemy technologiczne. SEO widzi potencjał organiczny. UX identyfikuje bariery użytkownika.

To nie jest wada.

Właśnie po to zatrudniamy specjalistów.

Firma potrzebuje jednak jeszcze jednej warstwy:

Wspólnej odpowiedzi, co ma pierwszeństwo dla całego biznesu.

Dobre warunki współpracy z wykonawcami oznaczają:

• jeden zestaw aktualnych priorytetów,
• jasno określony zakres,
• właściciela decyzji,
• komplet informacji potrzebnych do rozpoczęcia,
• określoną kolejność,
• odbiór wykonanej pracy,
• późniejszą ocenę efektu tam, gdzie jest potrzebna.

Nie chodzi o „pilnowanie specjalistów”.

Chodzi o stworzenie im warunków, w których mogą wykonywać dobrą pracę nad właściwymi problemami i we właściwej kolejności.

Najlepszy developer niewiele zrobi z zadaniem, dla którego brakuje decyzji biznesowej.

Najlepsza agencja reklamowa nie rozwiąże samodzielnie problemu marży całego asortymentu.

Najlepszy specjalista UX nie powinien sam decydować, czy jego rekomendacja ma pierwszeństwo przed krytycznym problemem operacyjnym.

Te decyzje muszą zostać połączone na poziomie całego e-commerce.

Co zrobić, jeśli firma ma już kilkadziesiąt rekomendacji?

Nie wdrażać ich po kolei od pierwszego wiersza arkusza.

Najpierw trzeba uporządkować materiał.

1. Usuń duplikaty i rzeczy nieaktualne

Kilka audytów może opisywać ten sam problem innymi słowami. Część rekomendacji mogła również stracić znaczenie po wcześniejszych zmianach.

2. Pogrupuj rekomendacje według problemów

Kilka różnych zadań może być próbą rozwiązania jednego ograniczenia.

3. Oddziel diagnozy od sugestii

Czy wiemy, że istnieje problem? Czy mamy jedynie pomysł, który warto kiedyś sprawdzić?

To nie jest ten sam poziom pewności.

4. Określ zależności

Które zadania muszą wydarzyć się przed innymi?

5. Porównaj potencjalny wpływ i nakład

Nie każdy dobry pomysł zasługuje teraz na czas zespołu.

6. Zbuduj pierwszą sekwencję działań

Nie potrzebujesz od razu idealnej roadmapy na kilka lat.

Potrzebujesz pierwszego rozsądnego zestawu prac.

7. Resztę świadomie pozostaw w backlogu

Nie jest obowiązkiem firmy realizowanie każdej rekomendacji, którą kiedykolwiek otrzymała.

Jeżeli sam audyt pozostawił więcej pytań niż decyzji, warto wrócić do materiału Audyt e-commerce: co powinien sprawdzać, żeby prowadził do realnych decyzji?

90 dni jako horyzont wykonawczy — po co ograniczać zakres?

90 dni nie jest magiczną liczbą.

Nie każdą zmianę da się w takim czasie wykonać.

Nie każdy rezultat da się też w takim okresie wiarygodnie ocenić.

Wartość ograniczonego horyzontu jest gdzie indziej.

Zmusza firmę do odpowiedzi:

Co naprawdę chcemy dowieźć w tym okresie?

Dzięki temu łatwiej:

• ograniczyć liczbę równoległych inicjatyw,
• ustalić realny zakres,
• przygotować zależności,
• skupić wykonawców,
• zamknąć pełne cykle wybranych zmian,
• stworzyć konkretny moment ponownej oceny.

Taki cykl może wyglądać:

decyzja → wdrożenie → obserwacja → kolejna decyzja.

Celem nie jest „naprawienie całego e-commerce w 90 dni”.

Celem jest wykonanie ograniczonej liczby działań o wysokim znaczeniu, sprawdzenie ich rezultatów tam, gdzie jest to już możliwe, i podjęcie kolejnych decyzji na podstawie tego, czego firma się dowiedziała.

Kiedy potrzebujesz nie kolejnego audytu, ale etapu wykonawczego?

Jeżeli firma nadal nie wie, gdzie znajduje się problem, kolejna analiza może być uzasadniona.

Sytuacja wygląda jednak inaczej, gdy:

• problemy zostały już rozpoznane,
• istnieją rekomendacje,
• najważniejsze priorytety są względnie jasne,
• wykonawcy wiedzą, co mniej więcej trzeba zrobić,
• zadania przesuwają się między miesiącami,
• decyzje lub materiały blokują realizację,
• po wdrożeniach brakuje weryfikacji rezultatu.

Wtedy kolejny dokument może tylko powiększyć istniejący backlog.

Firma nie potrzebuje już przede wszystkim kolejnej odpowiedzi na pytanie:

Co można poprawić?

Potrzebuje przejść przez:

wybór → zadanie → koordynację → wykonanie → weryfikację.

Dlaczego dobre rekomendacje e-commerce nie są wdrażane — podsumowanie

E-commerce nie rozwija się od liczby rekomendacji zapisanych w arkuszu.

Dobra rekomendacja musi jeszcze zostać:

• wybrana spośród innych możliwości,
• zamieniona w konkretne zadanie,
• przypisana do odpowiedzialnej osoby lub funkcji,
• umieszczona we właściwej kolejności,
• wykonana,
• odebrana,
• sprawdzona po wdrożeniu,
• wykorzystana do podjęcia następnej decyzji.

Jeżeli któryś z tych elementów regularnie znika, firma może mieć bardzo dobrą wiedzę o własnym e-commerce i jednocześnie wolno go zmieniać.

Dlatego pomiędzy dobrym audytem a lepszym wynikiem znajduje się coś znacznie mniej efektownego niż kolejna prezentacja:

wykonanie.