UX Telegram‑бота: как сократить сценарий и снизить отток пользователей

При разработке ботов важно помнить, что для пользователя бот – это в первую инструмент для закрытия своих потребностей. Конечно, мы с помощью бота хотим собрать максимум информации об этом пользователе, получить как можно больше точек касания, контактов и затащить поглубже в воронку, но ему надо не это. У него есть конкретный вопрос, и он ищет конкретный ответ

Ниже я разберу типичные UX‑ошибки на уровне сценария, примеры «как не надо» и «как лучше», а также простые метрики, по которым можно заметить проблему в своём боте. 

Онбординг или первые 30 секунд

Все мы знаем присказки “Встречают по одежке” и “У тебя никогда не будет второго шанса произвести первое впечатление”. С ботом все то же самое. При первом знакомстве с ботом должно быстро считываться три вещи:

• что он умеет;

• что пользователь получит в итоге;

• сколько действий займет путь.

Для примера придумаем бота, который помогает подобрать оздоровительную программу 

В плохом сценарии бот начинает с длинного меню из восьми‑десяти пунктов (возраст, пол, цель, хронические заболевания, прием препаратов, аллергии, образ жизни, бюджет, удобное время для звонка), затем после выбора «Услуги» вываливает ещё один список из семи позиций, а после выбора «Подбор программы» просит ответить еще на несколько вопросов. Большинство закрывает чат уже на первом этапе, потому что ценность отодвинута на десять и более шагов вперёд и у пользователя нет ощущения контроля. 

В переработанном варианте бот сразу обозначает, что поможет подобрать программу за две минуты, и предлагает два пути: быстрый подбор за три вопроса или подробный разбор за семь. Пользователь выбирает быстрый вариант, отвечает на три коротких вопроса про главную цель, наличие диагностированных заболеваний и прием добавок, и сразу получает конкретный результат — два подходящих варианта программы с кратким описанием. Здесь человек за три‑четыре сообщения уже получил осмысленную выдачу и сам решает, углубляться или нет. В таком сценарии первый полезный результат — это не конец воронки, а первая конкретная рекомендация, список или чек‑лист 

Когда меня спрашивают, как сократить путь в боте, я советую выписать все шаги подряд. Затем убрать каждый, без которого нельзя показать первую пользу. Обычно после этого сценарий заметно сокращается.

Что я проверяю в первую очередь?

Чаще всего проблемы встречаются в четырех местах:

• длинный путь до целевого действия;

• меню из семи–десяти одинаково важных кнопок;

• сообщения, которые приходится долго прокручивать;

• ветки, из которых непонятно, как выйти.

Меню особенно легко испортить. Разработчик видит перед собой функции, а пользователь — экран, который нужно изучать. На старте я оставляю два-три главных действия. Все второстепенное уходит в "Еще".

Длинные сообщения лучше делить: одна мысль, один вопрос, одно действие. Если сценарий растянулся, добавляю прогресс: "Шаг 2 из 4". Тогда человек хотя бы понимает, сколько осталось.

У каждой ветки должен быть выход. Кнопки "Назад", "В меню" и "Начать заново" лучше предусмотреть еще при проектировании.

Возврат на предыдущий шаг зависит от того, как устроен сценарий. Обычно я храню текущий и предыдущий этапы в переменных, а переход назад запускаю отдельной командой.

Простые метрики, по которым можно заметить проблему

Не нужно строить сложные дашборды, обычно достаточно трёх‑четырёх базовых метрик.

Первая метрика — процент завершивших ключевой сценарий. Вы определяете один‑два ключевых сценария, например «подбор программы» или «заказ консультации», и считаете отношение числа пользователей, дошедших до финального шага, к числу пользователей, начавших сценарий, в процентах. Если из ста человек, начавших подбор, только пятнадцать доходят до выдачи вариантов, это сигнал, что сценарий слишком длинный или запутанный. Нормальный ориентир зависит от ниши, но если completion rate ниже 20–30%, стоит пересмотреть поток

Вторая метрика — точка максимального провала. Вы смотрите, на каком шаге пользователи чаще всего перестают отвечать. Например, на переходе с первого шага на второй уходят 10%, со второго на третий — 15%, с третьего на четвёртый — 40%, с четвёртого на пятый — 20%. Шаг три‑четыре — явная проблемная зона, скорее всего, там слишком много вопросов, непонятная формулировка или нет ощущения прогресса.

Третья метрика — среднее число шагов до первого полезного действия. Вы фиксируете, сколько сообщений или вопросов проходит от /start до первой выдачи ценности: списка, рекомендации, чек‑листа. Если в среднем это больше пяти‑семи шагов, скорее всего, пользователи устанут раньше.

Четвёртая метрика — доля пользователей, использующих «выход». Вы считаете, сколько людей нажимает «В главное меню», пишет /start, /stop, /menu. Высокая доля может означать, что пользователи не находят нужного в текущей ветке и пытаются «сбежать», или, наоборот, им нравится, что можно легко переключаться. Эту метрику смотрят в связке с completion rate: если много «выходов» и мало завершённых сценариев, вероятно, люди застревают и ищут выход.

Почему люди уходят, хотя сценарий короткий?

Короткий путь может быть таким же запутанным, как длинный. Я бы проверил:

• понятно ли сформулирован текст на кнопках;

• получает ли пользователь реакцию после нажатия;

• совпадает ли обещание с результатом;

• можно ли вернуться назад;

• ясно ли, что делать дальше.

Вместо "Продолжить" лучше написать "Получить расчет", потому что до нажатия человеку должно быть понятно, что произойдет дальше.

Сколько шагов до цели нормально?

Я ориентируюсь на первый полезный результат за два-три действия. У анкеты или регистрации шагов может быть больше, если человек видит прогресс, может вернуться назад и понимает смысл каждого вопроса. Вместо "Укажите телефон" лучше написать, зачем он нужен: например, чтобы отправить подборку или закрепить заявку.

Как вернуть человека, который бросил сценарий на середине?

Я сохраняю этап и отправляю одно напоминание с контекстом:

"Подборка готова на 70%. Продолжить со второго вопроса?"

Кнопки:

• "Продолжить";

• "Начать заново".

Возврат в нужную точку обычно работает лучше, чем повторный /start. Человеку не приходится снова проходить то, что он уже сделал.

Чек‑лист для быстрой диагностики своего бота

Пройдитесь по этим пунктам и отметьте, где есть проблемы.

1. Пользователь должен получать ясную ценность в первом сообщении, например «я помогу сделать X за Y шагов». 

2. Первый полезный результат — список, рекомендация, чек‑лист — должен приходить не позже трёх‑пяти сообщений. 

3. В главном меню должно быть не больше четырёх‑пяти кнопок, остальные спрятаны внутри веток.

4. На каждом нетривиальном шаге должны быть кнопки «Назад» и «В главное меню».

5. Не должно быть вопросов «на будущее» вроде контактов, бюджета, деталей до выдачи первой пользы. 

6. Сообщения должны быть короткими, с абзацами и списками, без «простыней». 

7. Должны быть «аварийные выходы»: если пользователь застрял, бот предлагает альтернативу — чек‑лист, менеджер, другая ветка. 

8. И, наконец, вы должны регулярно смотреть на completion rate и точку максимального провала и менять сценарий по этим данным.