Gdzie zaczyna się sekwencja trial-to-paid?
Onboarding i e-maile trial-to-paid wykonują dwa różne zadania. Sekwencja onboardingowa ma jeden cel: doprowadzić użytkownika do momentu „aha” – punktu, w którym wartość produktu staje się oczywista. To aktywacja. Nie zakup.
Sekwencja trial-to-paid zaczyna się w tym miejscu. Zakłada, że wartość została już dostarczona, i robi jedyną rzecz, której onboarding nie robi: prosi o kartę. Onboarding odpowiada etapowi cyklu życia klienta zwanemu aktywacją, a ta sekwencja – decyzji o przejściu z triala na płatny plan: to krótkie, dobrze zgrane w czasie popchnięcie, które kończy się przed końcem triala.
Jak wygląda sekwencja i kiedy wychodzi każdy e-mail?
Sześć e-maili rozłożonych na czas triala. Część wychodzi w reakcji na zachowanie, część według kalendarza. Pierwsze dwa reagują na to, co robi użytkownik; ostatnie cztery odliczają czas do wygaśnięcia. Silnik ścieżek obsługuje to połączenie – węzeł wait_
| Trial 14-dniowy | Trial 30-dniowy | |
|---|---|---|
| Sprawdzenie aktywacji | Dzień 2 | Dzień 3 |
| Podsumowanie wartości w połowie triala | Dzień 7 | Dzień 15 |
| Odpowiedź na zarzut (T-3) | Dzień 11 | Dzień 27 |
| Presja czasu (T-1) | Dzień 13 | Dzień 29 |
| Wygaśnięcie / dzień karencji | Dzień 14–15 | Dzień 30–31 |
| Win-back po wygaśnięciu | Dzień 18–21 | Dzień 34–37 |
Co właściwie powinien mówić każdy e-mail?
E-maile z podsumowaniem powinny wiązać wartość z tym, co użytkownik faktycznie zrobił w produkcie, a nie z Twoją listą funkcji. „Masz już 5 segmentów i 2 uruchomione ścieżki – oto, co z tego wyniknie w płatnym planie” wygrywa z „nasza platforma ma ogromne możliwości”. Konkrety, które odzwierciedlają własną aktywność użytkownika, to najmocniejszy argument, jaki masz.
- Podsumowanie wartości powiązane z realnym działaniem w produkcie, z liczbą, jeśli ją masz
- Dokładnie jeden zarzut, nazwany wprost i z odpowiedzią – cena, wysiłek związany z migracją albo brakująca integracja
- Opcjonalny społeczny dowód słuszności: jedno zdanie, jedna liczba, od podobnego zespołu
- Jedno jasne CTA – przejście na płatny plan – i nic, co z nim konkuruje
- Jasno o tym, co dzieje się po wygaśnięciu: co użytkownik zachowuje, a co traci
Wybierz jeden zarzut, który najprawdopodobniej zablokuje zakup, i odpowiedz na niego wprost – nie wymieniaj pięciu. To właśnie ocena, którą wnosi Lifecycle Marketer: wiedza, który zarzut jest realny w tym segmencie. Jeśli budujesz szerszy system, w którym działają te e-maile, zajrzyj do artykułu marketing cyklu życia klienta dla startupów.
Dzień wygaśnięcia i okres karencji
E-mail w dniu wygaśnięcia to nie przypis. Wyślij go w chwili, gdy trial się kończy: napisz, że dostęp się zmienił, i daj jedną drogę powrotu. Potem dodaj krótki okres karencji – dzień lub dwa, w których konto wciąż działa – i powiedz o tym. Jeśli zbierasz dane karty z góry, pamiętaj o zasadach dotyczących terminów: Userlist zwraca uwagę, że organizacje kartowe, takie jak Visa, wymagają co najmniej siedmiodniowego wyprzedzenia przed zamianą triala w płatną subskrypcję, więc Twoje przypomnienia muszą wychodzić na tyle wcześnie, żeby to spełnić.
Nie traktuj wygaśnięcia jako końca. Encharge, powołując się na analizę MadKudu, podaje, że mniej więcej połowa konwersji SaaS może nastąpić po zakończeniu triala – dlatego win-back po wygaśnięciu zasługuje na swoje miejsce. Wyślij lżejszą wiadomość reaktywacyjną kilka dni później. A gdy użytkownik już przejdzie na płatny plan, kolejnym przeciekiem są płatności: nieudane obciążenie po cichu odbiera Ci płacącego klienta, więc połącz tę sekwencję z dunningiem i odzyskiwaniem nieudanych płatności.
Czy warto dawać rabat?
Oszczędnie. Stałe 20% zniżki w każdym e-mailu na koniec triala uczy ludzi, żeby pozwalali trialowi wygasnąć i czekali na kupon – uczysz zwlekania właśnie tych użytkowników, którzy mają największą intencję zakupu. Postaw raczej na uczciwą presję czasu i podsumowanie wartości w trakcie trwania triala. Zachowaj rabat na celowany win-back do użytkowników, którzy odpadli bez konwersji – tam rabat jest prawdziwą drugą ofertą, a nie odruchem. Narzędzia takie jak Customer.io, Encharge i Loops potrafią ograniczyć taką ofertę do konkretnego segmentu osób, które odpadły.
Jak mierzyć konwersję z triala na płatny plan?
Wskaźnik konwersji trial-to-paid to liczba płacących klientów podzielona przez liczbę triali rozpoczętych w tej samej kohorcie – kohorty wyznaczaj według tygodnia rejestracji, a nie miesiąca kalendarzowego, bo inaczej późne rejestracje zniekształcą wynik. Podziel go na aktywnych i nieaktywnych; to na kohortę aktywnych Twoje e-maile mogą realnie wpłynąć. Benchmarki mocno zależą od konstrukcji triala: Baremetrics podaje, że triale opt-in (bez karty) często konwertują na poziomie ok. 15–25%, a triale z kartą podaną z góry często wypadają wyżej, mniej więcej 40–60%. Traktuj je jako punkty odniesienia, nie cele – prawdziwą liczbę wyznaczają Twój produkt i Twoi odbiorcy.
Zestaw startowy: zdarzenia, ścieżki i wiadomości
Wszystko poniżej to szablon do dostosowania, a nie wynik: nazwy zdarzeń, reguły ścieżek i szkice wiadomości przygotowane pod 14-dniowy trial. Podstaw własne działanie „aha”, długość triala i nazwy planów. Ten sam zestaw jest dostępny jako plik Markdown, który możesz wrzucić do swojego repozytorium lub wiki.
Śledź pięć zdarzeń
Całą sekwencję niesie pięć zdarzeń. Zdarzenia produktowe i rozliczeniowe wysyłaj ze swojego serwera, gdzie nie zablokuje ich adblocker ani nie podrobi odwiedzający, a dane osobowe trzymaj w profilu, a nie we właściwościach zdarzeń.
| Zdarzenie | Wysyłaj, gdy | Właściwości | Źródło |
|---|---|---|---|
| signup_ | Formularz rejestracji zostaje wysłany, przed weryfikacją adresu e-mail | source, plan_ | Przeglądarka |
| signup_ | Konto istnieje, a adres e-mail jest zweryfikowany. Tu zidentyfikuj użytkownika, z identyfikatorem, którego używa Twój system rozliczeń | trial_ | Serwer |
| activated | Użytkownik po raz pierwszy wykonuje Twoje działanie „aha” (zdefiniuj je raz, np. „pierwszy raport udostępniony”) | activation_ | Serwer |
| trial_ | Codzienne zadanie wykrywa, że do trial_ | days_ | Serwer, zadanie cykliczne |
| subscription_ | Twój dostawca płatności potwierdza pierwsze udane obciążenie | plan, interval, amount | Serwer, z webhooka rozliczeń |
Dwie zasady nazewnictwa sprawiają, że plan będzie czytelny jeszcze za rok: object_
Zbuduj trzy ścieżki
Dwie ścieżki onboardingowe rozdzielają aktywne i utknięte triale; trzecia ratuje trial przy wygaśnięciu. Wszystkie trzy mają te same zabezpieczenia: każdy wychodzi w chwili, gdy pojawi się subscription_
| 1 · Onboarding: pierwsza wartość | 2 · Onboarding: utknięty trial | 3 · Ratunek przy wygaśnięciu triala | |
|---|---|---|---|
| Wyzwalacz | signup_ | Brak zdarzenia activated 48 godzin po signup_ | trial_ |
| Filtr wejścia | Plan próbny; nie konto wewnętrzne ani testowe | To samo i brak odpowiedzi na e-mail powitalny | Jeszcze brak subscription_ |
| Kroki | E-mail powitalny → czekaj do 48 godzin na activated → e-mail z kolejnym krokiem | E-mail z pomocą → czekaj do 3 dni na activated → e-mail tekstowy od człowieka z pytaniem, jak idzie | Rozgałęzienie według activated: podsumowanie wartości z odpowiedzią na jeden zarzut albo pomoc z propozycją przedłużenia → przypomnienie T-1 → e-mail o wygaśnięciu i dniu karencji → e-mail reaktywacyjny 4 dni później |
| Wykluczenia | Kontakty wypisane i z twardym odbiciem nigdy nie wchodzą; najwyżej jeden e-mail marketingowy dziennie we wszystkich ścieżkach | To samo; wstrzymaj, gdy ktoś z zespołu odpowiada na wiadomość użytkownika | To samo; pomiń e-mail reaktywacyjny, jeśli użytkownik odpowiedział albo umówił rozmowę |
| Wyjście i cel | Cel: activated. Wyjście przy subscription_ | Cel: activated. Wyjście przy subscription_ | Cel i wyjście: subscription_ |
Dostosuj sześć wiadomości
| Wiadomość | Temat | Pierwsze zdanie | Jedno wezwanie do działania |
|---|---|---|---|
| Onboarding (powitanie) | Witaj w {product}: zacznij od jednej rzeczy | Większość zespołów zaczyna czerpać korzyści z {product} w dniu, w którym {aha_ | {aha_ |
| Aktywacja (kolejny krok) | Gotowe: {aha_ | Do tego kroku większość triali nigdy nie dociera. Następny to {next_ | {next_ |
| Pomoc (utknięty trial) | Problem z krokiem {setup_ | Od Twojej rejestracji minęło {days} dni, a etap „{aha_ | Odpowiedz na ten e-mail |
| Koniec triala się zbliża (T-3, T-1) | Zostało dni: {days_ | Do tej pory: {usage_ | Wybierz plan |
| Wygaśnięcie (dzień karencji) | Twój okres próbny się skończył. Twoja praca wciąż tu jest | Twój okres próbny zakończył się {trial_ | Zachowaj moje konto |
| Reaktywacja (win-back) | Wróć do tego, co już zaczęte | Od Twojego ostatniego logowania wprowadziliśmy {relevant_ | Wznów mój okres próbny |
Symbole zastępcze w nawiasach klamrowych pochodzą z właściwości profilu i danych zdarzeń. Każdą wiadomość napisz najpierw jako zwykły tekst, zostaw jedno wezwanie do działania, nie dawaj rabatów w głównej sekwencji i każde stwierdzenie o aktywności użytkownika opieraj na realnej właściwości, nigdy na domysłach.
Zanim to włączysz
- Przetestuj każdą ścieżkę na profilu testowym: wywołaj ręcznie każde zdarzenie i sprawdź, kto wchodzi, kto czeka, a kto wychodzi.
- Zapłać kartą testową w połowie ścieżki 3 i sprawdź, że pozostałe e-maile przestają wychodzić.
- Wysyłaj w strefie czasowej każdego użytkownika, nigdy w nocy, i ogranicz e-maile marketingowe do jednego dziennie we wszystkich ścieżkach.
- Jeśli zbierasz dane karty z góry, zaczynaj przypomnienia na tyle wcześnie, żeby spełnić opisane wyżej zasady organizacji kartowych dotyczące wyprzedzenia.
- Mierz konwersję trial-to-paid w kohortach według tygodnia rejestracji i zachowaj małą grupę holdout, jeśli chcesz wiedzieć, ile wnosi sama sekwencja.
Ten zestaw uruchomi każde narzędzie do ścieżek z wyzwalaczami zdarzeń, oczekiwaniem kończącym się zdarzeniem i regułą wyjścia. We fromHello pięć zdarzeń trafia przez kod śledzący lub API, a każda z powyższych ścieżek jest zbudowana z węzłów samego kreatora: Wyślij e-mail, Czekaj, Czekaj na zdarzenie, Rozgałęzienie, Cel i Wyjście. Startupy działające krócej niż dwa lata, które pozyskały mniej niż 5 mln €, mogą ubiegać się o 12 miesięcy planu fromHello Core w ramach naszego programu dla startupów.