Воронка «Отложенный спрос» в Битрикс24: возвращаем потерянных клиентов

Зачем нужна отдельная воронка подогрева

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

Воронка «Отложенный спрос» решает это структурно:

• Основная воронка остаётся чистой - только активные переговоры.
• Каждый «отложенный» клиент фиксируется с датой следующего контакта и комментарием - что обсуждали, о чём договорились.
• Система сама ставит задачу менеджеру, когда наступает нужный момент.
• Руководитель видит всю «тёплую базу» в одном представлении, не копаясь в основной воронке.

Та же логика, кстати, работает в аккаунтинге - воронке сопровождения действующих клиентов. Там важно не пропустить дату следующей оплаты, согласования или продления договора.

Откуда берутся карточки в воронке

Карточки попадают в «Отложенный спрос» из основной воронки при переводе сделки на стадию «На подогрев». Это может быть:

• автоматически - карточка переходит сама, когда менеджер ставит определённую стадию отказа;
• вручную - сотрудник сам решает, что клиент не готов сейчас, но перспективен.

При первом перемещении нужно заполнить два поля - без них карточка не уйдёт на следующую стадию:

В указанную дату система автоматически ставит менеджеру задачу - с тем самым комментарием, который он написал при переводе. Это страховка на случай смены ответственного: новый менеджер сразу видит контекст.

О том, как настроить автоматические задачи через роботов, читайте в статье Роботы и триггеры в воронке Битрикс24: 7 полезных автоматизаций.

Стадии воронки «Отложенный спрос»

По нашей практике, воронка подогрева обычно строится из четырёх стадий:

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

Логика работы менеджера в воронке

Когда наступает дата связи и сотрудник получает задачу, его алгоритм такой:

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

flowchart TD
    A[Задача: выйти на связь с клиентом] --> B{Результат контакта}
    B -->|Однозначный отказ| C[Закрыть сделку как неуспешную\nУказать причину отказа]
    B -->|Не дал конкретики / вернуться позже| D[Перевести на стадию 'Ожидание связи'\nЗапланировать новое дело с датой]
    D --> A
    B -->|Подтвердил намерение купить| E[Закрыть как успешный прогрев]
    E --> F[Карточка автоматически\nпереходит в воронку Продажи]

Цикл «ожидание → контакт → решение» может повторяться сколько угодно раз. Всё зависит от того, насколько длинный цикл принятия решения в конкретном сегменте.

Воронка аккаунтинга: отложенный спрос для действующих клиентов

Аккаунтинг - смежная логика, но для уже подписанных клиентов. Задача другая: не потерять регулярные касания в ходе исполнения договора.

Типовые стадии воронки аккаунтинга:

На стадии «Проект в работе» роботы автоматически создают задачи на основе дат, которые продавец занёс ещё на этапе продаж:

• подготовка актов и счетов - за 7 дней до даты оплаты;
• возврат оригиналов актов в бухгалтерию - не позднее 5 дней после даты оплаты;
• подготовка отчётов - за 7 дней до даты сдачи;
• согласование материалов к съёмкам или выпускам - за 7 дней до события.

Ключевой принцип: данные, которые продавец вносит в карточку (даты оплат, документов), автоматически передаются в аккаунтинг и становятся основой для постановки задач. Связь двусторонняя: аккаунтинг в свою очередь отдаёт в воронку продаж информацию о подписанных актах.

Если интересно, как устроены связи между сущностями в Битрикс24 при передаче данных между воронками - это отдельная большая тема.

Настройка связей между воронками

У нас при настройке экосистемы из нескольких воронок стандартная схема выглядит так:

• Копия карточки остаётся в исходной воронке - конверсия считается корректно, статистика не ломается.
• Все заполненные поля передаются в новую карточку, чтобы менеджер сразу видел историю.
• Задачи с напоминаниями настраиваются на долгое нахождение карточки на одной стадии - страховка от «вечно зависших» сделок.

Связь между воронкой продаж и «Отложенным спросом» может повторяться несколько раз: клиент ушёл на подогрев, вернулся в продажи, снова ушёл на подогрев - и так до финального решения.

Для сложных случаев с несколькими ветками согласования смотрите воронку проектных продаж в Битрикс24 - там логика переходов между воронками ещё разветвлённее.

Что важно зафиксировать при настройке

До технической настройки нужно договориться о нескольких вещах:

1. Триггер перемещения - при переходе на какую стадию основной воронки карточка уходит в подогрев: стадия отказа, отдельная кнопка, смена ответственного?
2. Поля карточки - что фиксируем при переводе: причину, категорию клиента, бюджет?
3. Максимальный срок на стадии - через сколько времени руководитель получает контрольную задачу, если карточка не двигается?
4. Условия возврата - карточка возвращается в воронку продаж автоматически или менеджер делает это вручную?
5. Отчётность - какие срезы по воронке подогрева нужны РОПу: объём базы, конверсия в возврат, средний срок подогрева?

По второму пункту - пользовательские поля в Битрикс24 стоит проработать отдельно: состав полей в воронке подогрева часто отличается от основной воронки.

Типичные ошибки при внедрении

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

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

Дата связи не заполняется. Без даты автоматическая задача не ставится - клиент просто теряется. Сделайте поле «Дата следующей связи» обязательным при переходе на стадию «Ожидание связи». Тогда менеджер физически не сможет уйти дальше, не заполнив его.

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

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