Jaki problem to rozwiązuje
Polecenia już się dzieją, ale nikt nie prosi o nie systematycznie. Zadowoleni klienci kończą onboarding, odnawiają dwa razy i ani razu nie są zaproszeni do polecenia, recenzji czy wystąpienia. Gdy polecenie przychodzi, nie ma zapisu, kto je wysłał, więc nikt nie dziękuje, a zachowanie nigdy nie jest wzmacniane. Case studies i recenzje ścigane są ad hoc, gdy deal potrzebuje dowodu, zawsze od tych samych dwóch klientów, których ktoś akurat pamięta.
Jak pracujemy
Najpierw projekt: kto kwalifikuje się jako ambasador, na podstawie sygnałów, które już masz, wejścia od customer success, wyników ankiet, użycia i stażu; o co jest proszony, polecenia, recenzje, case studies, rozmowy referencyjne, przedstawienia; i co dostaje w zamian, co w B2B zwykle jest uznaniem, dostępem i realną wzajemnością, a nie gotówką. Mechanikę spisujemy jako zasady programu, żeby program przeżył osobę, która go uruchomiła.
Potem build w HubSpocie: listy zapisów i workflow, które identyfikują i zapraszają ambasadorów, przepływ przechwytywania polecenia wiążący polecającego z poleconym kontaktem i dealem, właściwości śledzenia, żeby pipeline ze źródeł poleceń był widoczny w raportowaniu, oraz automatyzacja podziękowań i nagród, żeby żaden ambasador nie został bez odpowiedzi. Dashboard programu pokazuje zapisy, prośby, odpowiedzi i pipeline z poleceń w jednym miejscu.
Sam start idzie celowo mały: początkowa kohorta dobrze dobranych ambasadorów zamiast masowej wysyłki, żeby prośby, ton i mechanika przeszły test na ludziach, którzy Cię lubią, zanim program się skaluje.
Deliverables
- Projekt programu: kryteria ambasadora, prośby, nagrody i spisane zasady
- Build HubSpota: listy zapisów, workflow, przechwytywanie poleceń, właściwości śledzenia
- Atrybucja poleceń wiążąca polecającego z poleconym kontaktem i dealem
- Assety zaproszeniowe i programowe
- Start z początkową kohortą ambasadorów
- Dashboard programu: zapisy, prośby, odpowiedzi, pipeline z poleceń