Dlaczego klienci rezygnowali z kursu tuż przed płatnością

Dobry produkt, który strona utrudniała kupić

Klienci byli zadowoleni z kursów, wielu przychodziło z polecenia. Problem nie polegał na tym, że ludzie nie chcieli kupić. Strona nie pomagała im podjąć decyzji: chowała to, czego szukali, przesuwała się podczas ładowania i nie budowała zaufania tam, gdzie było najbardziej potrzebne.

Najdroższy wyciek był na końcu ścieżki. Prawie cała sprzedaż do klientów indywidualnych przechodziła przez jeden formularz zapisu, a duża część osób, które do niego dotarły, nie kończyła zakupu. Zespół widział, że ludzie odpadają, ale nie wiedział dlaczego.

Klienci nie rezygnowali z kursu. Rezygnowali z formularza, chociaż decyzja o zakupie już zapadła.

Kluczowy wniosek z audytu

Pięć miejsc, w których uciekała sprzedaż

Zestawiłem dane z analityki, nagrania i mapy kliknięć z sesji użytkowników oraz ankietę wśród klientów. Przyjmowałem tylko te wnioski, które potwierdzały co najmniej dwa niezależne źródła. Wyszło pięć miejsc:

1. Terminy poza zasięgiem wzroku. Na stronie kursu klient szukał przede wszystkim terminu. Ten był nisko, ładował się z opóźnieniem, a wiele osób wychodziło, zanim w ogóle go zobaczyło.
2. Formularz jak ściana pól. Dane osobowe, adres, faktura, uwagi i zgody na jednej długiej stronie, bez podziału na kroki. Na telefonie to kilka ekranów przewijania, zanim wpisze się pierwszą literę. Łatwo odłożyć to „na wieczór”, a potem już nie wrócić.
3. Wrażliwe dane bez wyjaśnienia. Formularz prosił o PESEL w pierwszym rzędzie, zanim klient zobaczył cokolwiek, co buduje zaufanie, i bez słowa o tym, do czego jest potrzebny.
4. Niejasny następny krok. Przycisk mówił tylko „Zarezerwuj”. Nie było wiadomo, czy teraz nastąpi płatność, czy można się jeszcze wycofać, a zgoda nad przyciskiem brzmiała jak wiążące zobowiązanie. Do tego podsumowanie zamówienia znikało po pierwszym przewinięciu.
5. Wyjścia awaryjne na stronie zakupu. Pod formularzem zapisu był drugi formularz kontaktowy z niemal identycznym przyciskiem, a niżej promocja innej usługi marki. Niezdecydowany klient miał łatwą alternatywę dla zakupu.

Pod spodem były jeszcze dwa problemy techniczne. Strona przesuwała się podczas ładowania, więc ludzie klikali nie tam, gdzie chcieli. A analityka gubiła część ruchu i zawyżała wyniki jednego z kanałów reklamowych, czyli decyzje o budżecie zapadały na niepewnych danych.

Źródła: dane z analityki za cały rok, mapy kliknięć i nagrania sesji, ankieta wśród klientów, pomiary szybkości strony, przegląd ścieżki zakupu na telefonie i komputerze.

Od danych do backlogu, który developer bierze od ręki

Zacząłem od danych, żeby zobaczyć, gdzie ludzie odpadają i ile to kosztuje. Potem przeszedłem przez kluczowe strony, zaczynając od telefonu, bo tam odbywała się większość sprzedaży. Każdą obserwację opisałem w ten sam sposób: co widzę, co z tego wynika i co proponuję. Otwarcie zaznaczałem też, czego nie wiem, na przykład gdzie dane są niepełne albo gdzie ankieta nie dociera do klientów firmowych.

Na koniec każdą zmianę oceniłem w trzech wymiarach: wpływ na sprzedaż, pewność, że zadziała, i koszt wdrożenia. Najwyżej ocenione trafiły do backlogu jako gotowe zadania: co zmieniamy, dlaczego i jak dokładnie ma działać na telefonie i komputerze, razem z makietami. Developer nie musiał niczego zgadywać, a właściciel widział, od czego zacząć.

Jak sprawdzić, czy to działa

Zanim cokolwiek zmierzymy, trzeba uporządkować analitykę, żeby ruch i kanały były liczone poprawnie. Potem do każdej zmiany przypisałem wskaźnik:

• odsetek osób, które od strony kursu przechodzą do zapisu,
• ukończenie formularza, osobno dla każdego kroku, żeby widać było, gdzie ludzie odpadają,
• kliknięcia w przycisk płatności i telefon do obsługi,
• porównanie strony zakupu z drugim formularzem i bez niego w teście A/B.