Skip to main content
Полный перечень полей — в глоссарии.

Что это и зачем

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

Модель данных

Триггер этапа

В интерфейсе есть выбор HTTP-метода вебхука (POST, GET, PUT, PATCH, DELETE), но фактически система выполняет запрос только при выборе POST. Любой другой метод не приведёт ни к какому вызову.

Действия триггера

Действие «Документ» существует в перечне, но движок автоматизации его не обрабатывает — при смене этапа оно ничего не делает. Точно так же движок при обычной смене этапа не выполняет «Генерация лидов из заявок»: это действие запускается отдельно, по служебному флагу при сохранении правила (см. раздел ниже).

Лог смены этапа лида

Каждая фактическая смена этапа, выполненная авторизованным пользователем, записывается в историю.

Как срабатывает автоматизация

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

Что делает движок правил

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

Создать задачу

Создаётся задача по лиду: с указанным типом задачи, менеджером лида, описанием из правила и дедлайном, который отсчитывается от момента срабатывания на величину «Срок задачи» (по умолчанию — сутки).

Перенести в воронку

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

Отправить сообщение

Сообщение отправляется, только если у лида есть клиент и в правиле задан текст. Если клиента нет, правило просто пропускается, а остальные правила этапа продолжают выполняться.
  • По SMS отправляется текст сообщения как есть (без подстановки полей). Перед отправкой телефон клиента проверяется на корректность.
  • Через Wazzup (WhatsApp) текст сначала прогоняется через подстановку значений: имя клиента, телефон, имя менеджера, а если у лида есть заявка — её номер, даты начала и конца аренды (плановые и фактические), суммы (цена, цена со скидкой, стоимость инвентаря, услуг, доставки, оплаченная сумма) и человекочитаемый статус заявки. Суммы подставляются уже с символом валюты компании, даты — в коротком формате по времени Asia/Tashkent.
Шаблон сообщения для Wazzup поддерживает подстановку по именам полей. Если у лида нет заявки, поля, связанные с заявкой, в подстановке отсутствуют — используйте в шаблоне только имя, телефон и менеджера, либо убедитесь, что заявка к этому моменту уже создана.

Создать заявку

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

Сменить статус заказа

Самое «тяжёлое» действие с несколькими побочными эффектами.
  • Если у лида ещё нет заявки, она сначала создаётся (по тем же правилам, что и выше). Если создать заявку не удалось (нет клиента), действие прекращается.
  • Если заявка уже в нужном статусе, ничего не меняется.
  • Особый случай — перевод в аренду (статусы «в аренде» / «просрочено» из состояний «запрос», «забронировано», «в аренде», «просрочено»): система фиксирует фактический старт аренды, отмечает выдачу инвентаря, а для позиций на продажу проставляет цену и дату продажи. Если у заявки вообще нет инвентаря, перевод в аренду не выполняется. Также записывается действие о выдаче.
  • При любой смене статуса пересчитывается дочерний заказ и перегенерируются задачи по начислению пеней, после чего статус заявки сохраняется.
Перевод в аренду при отсутствии инвентаря в заявке прерывается досрочно — статус остаётся прежним, дочерний заказ и пени не пересчитываются. То есть «пустую» заявку это действие в аренду не переведёт.

Вызвать вебхук

Если задан адрес и выбран метод POST, на этот адрес отправляется POST-запрос с данными лида (этап, воронка, клиент, менеджер, источник, цена, заявка и т.д. в формате JSON). Если выбран любой метод, кроме POST, правило просто пропускается.
Если у правила «Вызвать вебхук» не задан адрес, движок правил обрывается целиком: все оставшиеся правила этого этапа, стоящие после него, не выполнятся. Это отличается от остальных случаев, где неподходящее правило просто пропускается. Настраивая вебхук, всегда указывайте адрес.
Вебхук вызывается синхронно, прямо в процессе сохранения лида, без фоновой задачи и без ограничения по времени ожидания. Медленный или недоступный внешний адрес затормозит операцию смены этапа.

Генерация лидов из заявок

Действие «Генерация лидов из заявок» стоит особняком: оно не срабатывает при смене этапа, а запускается вручную — при сохранении самого правила, если в запросе передан служебный флаг «Сгенерировать лиды». Как это работает:
  • Правило должно быть с действием «Генерация лидов из заявок», и у него должен быть задан статус-источник заявок. Иначе генерация не выполняется.
  • Для каждого этапа, к которому привязано правило, система берёт активные, неудалённые заявки с клиентом, находящиеся в статусе-источнике, и исключает те, у которых уже есть лид на этом этапе.
  • По каждой такой заявке создаётся лид: с клиентом и источником привлечения клиента, ценой из заявки со скидкой, ссылкой на заявку, на нужном этапе и в воронке этого этапа.
Лиды при генерации создаются массово, поэтому автоматизация этапа для них НЕ запускается — то есть привязанные к этапу правила (сообщения, задачи и т.п.) на сгенерированных лидах не сработают. Массовая генерация только «наполняет» этап лидами.

Управление правилами через API

  • Список правил можно отфильтровать по воронке (через этапы) и получить без постраничной разбивки; правила отсортированы по полю «Порядок» по убыванию.
  • Создание, чтение, изменение и удаление правила требуют авторизации.
  • Флаг «Сгенерировать лиды» доступен только на запись (в ответе не возвращается) и при создании, и при обновлении правила запускает описанную выше массовую генерацию.

Как это используется на практике

Типовые сценарии:
  • Прогрев по этапам. На этап «Новый лид» вешаем сообщение-приветствие через Wazzup, на этап «Согласование» — задачу менеджеру перезвонить в течение суток.
  • Автоматический переход к сделке. На этап «Выдача» вешаем «Сменить статус заказа» → «в аренде»: система сама создаст заявку (если нужно), зафиксирует старт аренды и оформит выдачу инвентаря.
  • Разветвление воронок. На финальном этапе вешаем «Перенести в воронку», чтобы лид автоматически уходил в другую воронку (например, постпродажного обслуживания).
  • Интеграция с внешними системами. Вебхук на нужном этапе отправляет данные лида в стороннюю систему.
  • Первичное наполнение воронки. Разово запускаем генерацию лидов из уже существующих заявок нужного статуса.

Связанные страницы

Глоссарий: Триггеры и автоматизация этапов

Полный перечень полей правил автоматизации, действий и лога смены этапов.

Продажи (воронки лидов)

Обзорная страница модуля продаж и всех его разделов.

Воронки и этапы

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

Лиды и их порядок

Лиды воронки, их связи с клиентом, заявкой и продажей, ручное упорядочивание и создание заявки из лида.

Задачи по лидам

Задачи и методы задач по лидам с дедлайном, назначением менеджера и уведомлениями.

Логи и массовые операции

История смены этапов лида и массовые действия над лидами этапа: перенос, удаление, рассылка.

Приём заявок с сайта и синхронизация Wazzup

Приём заявок с сайта через публичный вебхук и фоновая синхронизация сделок в Wazzup.