Условное ветвление: разные пути клиентов в одном сценарии

Вторник, 9:40. В отделе продаж компании, которая делает софт для учебных центров, работает один приветственный сценарий: всем, кто заполнил форму, уходит одно и то же письмо, и запись попадает к следующему менеджеру по очереди. За утро в форму падает 34 заявки. Большая часть — репетиторы, работающие в одиночку, несколько — небольшие учебные центры, и четыре — сеть школ на несколько сотен учеников. Все получают одну строчку: «Ваш бесплатный доступ на 14 дней готов». Специалист по закупкам из сети школ удаляет письмо, не открывая: его вопрос был не про пробный доступ, а про договор, счёт и то, до скольких пользователей всё это масштабируется. В пятницу команда смотрит на конверсию и решает, что сценарий не работает. Сценарий работает. Просто он знает один-единственный маршрут.

Условное ветвление отвечает именно на это: один триггер, один сценарий и несколько маршрутов, которые выбираются по данным самой записи. Ниже разберём, где ломается одномаршрутный сценарий и на какие данные должно опираться решение о ветвлении. Затем сравним в таблице фильтр триггера, ветку if/else и отдельный сценарий и покажем, почему порядок условий меняет результат. В последних разделах — разумное число веток, паузы внутри веток, диагностика ветки, которая молчит, проверка до публикации и те цифры, которые действительно стоит читать после ветвления.

Где ломается одномаршрутный сценарий?

Одномаршрутный сценарий — это замаскированное допущение: все, кто пришёл через этот триггер, хотят одного и того же. На небольших объёмах этого не видно, потому что люди молча компенсируют несовпадение. Менеджер видит неподходящее письмо, дописывает свою фразу, и разрыв закрывается. Когда объём растёт, компенсировать становится некому, и сценарий проявляется ровно таким, каким его собрали.

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

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

На какие данные опирается решение о ветвлении?

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

У хороших данных для ветвления три свойства: они хранятся в самой записи, принимают ограниченный набор значений и не меняются в момент принятия решения. Размер компании, тип запроса, отрасль, канал источника и диапазон бюджета подходят. Оценочные поля вроде «уровень интереса» не подходят: двое менеджеров разметят одну и ту же запись по-разному. Если вы уже фиксируете стадию записи, картирование жизненного цикла клиента по этапам даёт готовую и непротиворечивую ось для ветвления.

В продукте это связка «Множественные триггеры» и шага «Условное ветвление»: запуск даёт отправка формы, вебхук, расписание или входящее сообщение, а следующий за ним шаг if/else читает поля записи и выбирает маршрут. Решение живёт не в чьей-то голове, а в самом сценарии — через полгода на вопрос «почему этот клиент попал в быструю ветку» ответ найдётся прямо в условии шага.

Фильтр, ветка или отдельный сценарий?

Не всякое различие заслуживает ветки. Часть разделений нужно делать до запуска сценария, часть — в середине, а часть выносить в отдельный сценарий. Неверно выбранный инструмент делает автоматизацию либо излишне запутанной, либо излишне грубой. Таблица ниже собирает критерии выбора.

Инструмент	Когда использовать	Что он скрывает
Фильтр триггера	Группа вообще не должна попадать в сценарий, разделение известно заранее	Отфильтрованные записи не видны нигде и теряются молча
Ветка if/else	Маршруты ведут к одной цели, но большая часть шагов у них общая	С ростом числа веток холст перестаёт читаться
Отдельный сценарий	У маршрутов разные триггеры, владельцы и метрики	Общие шаги приходится поддерживать в двух местах
Вызов вложенного сценария	Одна и та же последовательность повторяется в нескольких сценариях	Длинная цепочка усложняет понимание, что именно отработало

Рабочий порог такой: если два маршрута делят больше половины шагов — делайте ветку, если меньше — пишите отдельный сценарий. Когда общая часть появляется и в третьем сценарии, соберите её в одном месте шагом «Вызов вложенного сценария»: защита от циклов и от глубины не даст цепочке замкнуться на себе. Если привычка автоматизировать процессы условными правилами уже сложилась, выбор между этими тремя инструментами становится вопросом архитектуры, а не техники.

Как порядок условий меняет результат?

Цепочка if/else читается сверху вниз, и побеждает первое сработавшее условие. Из этого простого правила растёт самая частая поломка ветвлёных сценариев: широкое условие стоит выше узкого. Поставьте «отрасль — образование» над «больше 500 пользователей», и крупная сеть школ никогда не доберётся до корпоративного маршрута. Ветка собрана верно, порядок — нет.

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

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

Сколько веток много, а сколько мало?

Технического потолка на число веток нет, но есть практический: команда должна прочитать сценарий на одном экране. Опытные команды выпускают первую версию с двумя-тремя ветками. Четыре и больше оправданы, только если у каждой ветки действительно своё сообщение, свой владелец или свой ритм.

Быстрая проверка оправданности ветки — вопрос: что изменится для клиента, если её убрать? Если ответ «одна фраза в письме», используйте переменную внутри сообщения. Если ответ «кто звонит, когда звонит и что предлагает» — ветка нужна. Логика, разделяющая продажи enterprise и продажи малому бизнесу, работает здесь буквально: когда у маршрутов разные собеседники и разный темп, одно сообщение не сделает две работы.

Есть и обратная ошибка — веток слишком мало. Если в сценарии одна ветка «крупный клиент», а половина попавших в неё записей — это компании с большим числом пользователей и маленьким бюджетом, ветка ждёт повторного деления. Заметить это можно не по конверсии, а по разбросу времени первого ответа внутри ветки.

Что меняют паузы и расписание внутри веток?

Ветвление разделяет не только то, что отправляется, но и то, когда. Пауза в пять минут уместна на маршруте, где решает один человек; те же пять минут выглядят навязчиво там, где решение проходит через комитет. Длительность пауз в двух ветках одного сценария может и должна отличаться.

Рядом с шагом «Планировщик» здесь работают две страховки. «Ограничения по частоте и рабочим часам» задают потолок запусков в час, день или неделю и окно рабочего времени, поэтому запись, упавшая в три ночи, дождётся утра. «Остановка при ответе» отменяет ожидающие шаги, как только человек ответил или лид закрыт, — третье напоминание не уйдёт вдогонку уже написанному ответу.

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

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

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

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

«История запусков» — самый короткий способ их различить: видно, через какие шаги прошла каждая запись и с каким значением сравнивалось условие. «Автоматическая диагностика» сама находит оборванные шаги, ни разу не сработавшие сценарии и неподключённые каналы. «Анализ воронки» показывает, на каком именно шаге отваливаются люди: если после первого шага у ветки прямая линия, дело не в тексте, а в условии.

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

Как проверить ветвление до публикации?

Делать первый настоящий прогон ветвлёного сценария на живых клиентах дорого: корпоративная заявка, попавшая не в тот маршрут, оставляет первое впечатление, которое не отыграешь. Ровно для этого есть «Тестовый прогон»: сценарий проходится на тестовых данных от начала до конца, шаг за шагом показывает, какой путь отработает, и не отправляет ни писем, ни сообщений в WhatsApp или SMS.

Готовя тест, сделайте по одной тестовой записи на каждый маршрут и ещё одну, которая не подходит ни под одно условие. Для сценария с четырьмя маршрутами это пять записей. Если ожидаемый маршрут и сработавший не совпали, менять нужно условие, а не текст.

После публикации путь назад тоже остаётся открытым. «История версий» хранит каждое сохранение как версию: сломанный сценарий возвращается к прежней в один клик, и состояние до отката тоже сохраняется. На рискованном маршруте — например, там, где уходит предложение со скидкой, — шаг «Ожидание одобрения» останавливает сценарий, отправляет уведомление выбранному человеку и не даёт продолжить без подтверждения, если срок истёк.

Какие цифры имеют смысл после ветвления?

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

Чтение по веткам в первую очередь показывает, нужна ли была ветка вообще. Если цифры двух маршрутов почти совпадают, ветка, скорее всего, лишняя; устойчивая разница означает, что она делает свою работу. Во вторую очередь оно подсказывает, какой маршрут стоит улучшать: пара пунктов на малообъёмном, но дорогом маршруте иногда приносит больше, чем тот же прирост на массовом.

К счётным метрикам добавьте измерение опыта. Понять, как маршруты ощущаются со стороны клиента, помогает измерение удовлетворённости через NPS, CSAT и CES: задайте один и тот же вопрос записям из разных веток, и оценки покажут, чей темп воспринимается как давление.

Ещё раньше предупреждает тон входящих сообщений. Анализ тональности, который рано ловит недовольство, подсветит переусердствовавшую ветку до того, как просядет конверсия: резкий тон в одном маршруте почти всегда означает, что паузы там слишком короткие.

Чтобы собрать первое ветвление и прогнать его в тестовом режиме, вы можете открыть бесплатный аккаунт Rocketly.

Частые вопросы

Сколько веток можно сделать в одном сценарии?

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

Что будет, если поле в условии пустое?

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

Что произойдёт с записями в работе, если изменить ветки?

Пока вы не сохранили, ничего не публикуется; после сохранения новые запуски идут по новой версии. Как ведут себя уже ожидающие записи, покажет «История запусков», а если результат не тот, «История версий» вернёт предыдущую версию.

Можно ли собрать ветвление через AI Copilot?

Да. Опишите нужное разделение обычной фразой, и Copilot соберёт условный шаг на холсте, а следующие ваши сообщения будут править уже существующий сценарий. Copilot ничего не публикует сам: он обновляет черновик, решение сохранить остаётся за вами.