Проактивні тригери в чаті, які працюють: сценарії для сторінок з цінами, оформленням замовлення та онбордингом

Ціни, оформлення замовлення й онбординг: три різні моменти

На сторінці з цінами головна підказка — час. Відвідувач, що зайшов і пішов за десять секунд, найімовірніше просто перевіряв цифру, яку вже й так підозрював; той, хто затримався на двадцять–тридцять секунд, порівнює тарифи, намагається зрозуміти, що входить у план, або шукає деталь, яку сторінка не пояснює достатньо чітко. Повідомлення, яке отримує відповідь, прямо називає цей момент — «Порівнюєте тарифи?» працює краще за загальне привітання, бо показує відвідувачу: повідомлення зрозуміло, що він насправді робить, — а коротка затримка приблизно у пʼятнадцять–двадцять секунд не дає йому спрацювати на тому, хто все одно збирався піти.

Сторінки оформлення замовлення й оплати мають найвищу ціну вагання, бо відвідувач, який іде звідси, був за секунди від рішення, яке тепер втрачене, а не просто відкладене. Найважливіше в тригері тут — коротша затримка, ніж деінде: на формі оплати не затримуються з цікавості, — у поєднанні з аудиторією лідів або авторизованих користувачів, а не анонімних відвідувачів, бо людина на такому етапі воронки зазвичай уже якось себе ідентифікувала. Повідомлення має звертатися до конкретної речі, яка гальмує оформлення: поле для промокоду, питання про валюту, невпевненість щодо того, що станеться після натискання кнопки, — а не пропонувати допомогу в загальних словах.

Онбординг — це місце, де проактивне повідомлення замінює лист-нагадування, який інакше прийшов би на день пізніше, ніж треба. Новий користувач, який застряг на одному кроці налаштування довше, ніж триває типова сесія, натякає, що справжня перешкода — у самому процесі, а не в продукті: обовʼязкове поле з незрозумілою підписом, крок, який передбачає інформацію, якої в користувача ще немає. Таргетинг за шляхом сторінки тут варто робити прицільно, під конкретний крок, а не під весь розділ онбордингу, бо повідомлення, яке допоможе людині, що застрягла на підключенні домену, — не те саме повідомлення, яке допоможе тому, хто застряг на запрошенні колеги.

Документація та продовження підписки потребують іншого тригера

Ставити тригер чату на сторінку документації — дивна ідея, адже відвідувач, що читає документацію, за визначенням намагається розвʼязати проблему, не звертаючись ні до кого. Тут варто ставити тригер за часом, а не за самим фактом заходу: кілька хвилин на одній статті або кілька статей за одну сесію — обидва випадки натякають, що документація насправді не відповіла на питання. Повідомлення варто прямо визнати це: не «чим можемо допомогти», що просто повторює те, що вже пропонує вся сторінка, а щось ближче до констатації факту, що це вже зайняло чимало часу, з пропозицією скоротити шлях — просто запитати.

Сторінка, повʼязана із закінченням тріалу чи продовженням підписки, — це, по суті, тригер повторного залучення, замаскований під правило за шляхом сторінки. Аудиторію варто звузити саме до наявних користувачів, бо повідомлення тут означає дещо інше — ближче до керування акаунтом, ніж до першого привітання, — а зміст має посилатися на реальний стан акаунту, а не на загальне нагадування; саме тут змінна персоналізації для назви акаунту чи тарифу виправдовує себе краще за статичний рядок.

Що спільного між пʼятьма сценаріями і як уникнути перетину

Усі пʼять сценаріїв мають однакову форму: сторінка, що натякає на конкретний вид вагання, затримка, підлаштована під те, скільки зазвичай триває це вагання, перш ніж минути самому собою, і аудиторія достатньо вузька, щоб повідомлення діставалося саме тих, хто в такій ситуації, а не всіх, хто просто відкрив сторінку. Жоден із пʼяти не спрацює, якщо скопіювати його на іншу сторінку без змін, бо причина вагання — а отже, і речення, яке до неї звертається, — щоразу інша.

Запуск кількох таких правил одночасно одразу створює одну проблему, яку варто продумати заздалегідь: перетин. Авторизований користувач, у якого от-от закінчиться тріал і який заодно потрапляє на сторінку з цінами, підпадає під два різні правила, побудовані для двох різних моментів, — і отримати обидва в одній сесії читається як шум, а не як увага. Впорядкуйте правила за специфічністю й дайте перемогти вужчому: повідомлення про закінчення тріалу, побудоване на реальному стані акаунту цього користувача, має мати пріоритет над загальним привітанням на сторінці з цінами, під яке він також підпадав би.

Вимірюйте й пріоритизуйте кожен сценарій окремо

Кожен сценарій заслуговує на своє місце завдяки власним цифрам, а не загальній сумі всієї програми. Повідомлення на сторінці з цінами з високою часткою відповідей і повідомлення на оформленні замовлення зі слабкою — це не доказ того, що проактивні повідомлення працюють чи ні; це два окремі результати, які потребують двох окремих рішень: перше залишити як є, а над другим — переглянути затримку або текст, перш ніж вирішувати, що сама сторінка була невдалим місцем для спроби.

Жоден із цих пʼяти сценаріїв не є шаблоном, який можна встановити й забути. Кожен — це конкретна ставка на те, чому відвідувач саме на цій сторінці й саме вагається, сформульована в тригері та тексті достатньо чітко, щоб можна було побачити: вона або спрацювала — і частка відповідей це покаже, — або ні, причому так, що це легко помітити й виправити.

Почніть з двох сторінок із найвищим наміром, а не з усіх пʼяти одразу

Спершу візьміть ціни й оформлення замовлення, бо вагання там і легко визначити — час на сторінці, стан кошика чи оплати, — і дорого ігнорувати, адже обидві сторінки стоять якраз перед рішенням, а не на початку перегляду сайту. Напишіть по одному повідомленню для кожної, звузьте аудиторію до тих, хто справді в такій ситуації, а решту правил відкладіть на потім.

Дайте кожному сценарію два-три тижні, перш ніж оцінювати його, і оцінюйте за якістю відповідей, а не лише за охопленням. Повідомлення зі скромною часткою відповідей, але розмовами, яким явно був потрібен такий поштовх, — працює; повідомлення, що дістається багатьох, але з відповідями на кшталт «а чому мені це написали» — потребує переписати заголовок, а не розширювати аудиторію.

Додавайте сценарії для документації, онбордингу й продовження підписки лише після того, як перші два налаштовані, а команда відчула, скільки навантаження реально створює одне проактивне правило. Пʼять правил, запущені одночасно, — це пʼять змінних, що змінюються водночас: якщо частка відповідей на якесь із них виглядає дивно, зʼясувати, через сторінку, затримку чи текст це сталося, буде неможливо.