> ## Documentation Index > Fetch the complete documentation index at: https://docs.yume.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Триггеры и автоматизация этапов > Правила автоматизации этапов воронки: действия (сообщение, задача, статус заказа, перенос в воронку, создание заявки, вебхук), запуск через сигналы при смене этапа, побочные эффекты для заявок и заказов и генерация лидов из заявок. Полный перечень полей — в [глоссарии](/ru/logic/sales/triggers-glossary). ## Что это и зачем Триггеры этапов — это правила автоматизации, которые срабатывают в момент, когда лид попадает на определённый этап воронки. Одно такое правило описывает одно действие: отправить сообщение клиенту, поставить задачу менеджеру, создать или перевести заявку, сменить статус заказа, перенести лид в другую воронку или дёрнуть внешний адрес (вебхук). Идея простая: настройте один раз, к каким этапам привязано правило и что оно делает, — и дальше при каждом перетаскивании лида на этот этап система выполнит действие сама, без участия менеджера. Одно правило — одно действие. Тип действия определяет, какие из полей правила реально используются (например, для сообщения нужны текст и канал, для задачи — тип, срок и описание, для вебхука — адрес). Остальные поля при этом просто игнорируются. ## Модель данных ### Триггер этапа | Поле | Тип | Назначение | | ----------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Этапы срабатывания | связь многие-ко-многим | Этапы воронки, при попадании на которые правило выполняется. Одно правило можно повесить сразу на несколько этапов | | Действие | перечисление | Что именно правило делает (см. ниже список действий) | | Порядок | число | Порядок сортировки правил в списке через API (по убыванию). На фактический порядок выполнения правил при смене этапа он не влияет — движок перебирает правила этапа в порядке, который отдаёт база | | Текст сообщения | текст | Шаблон сообщения с подстановкой полей клиента и заявки (для действия «Отправить сообщение») | | Канал сообщения | перечисление | SMS или Wazzup (для действия «Отправить сообщение») | | Тип задачи | связь | Метод создаваемой задачи по лиду (для действия «Создать задачу») | | Срок задачи | длительность | Смещение от момента срабатывания до дедлайна задачи; по умолчанию 1 день | | Описание задачи | текст | Текст создаваемой задачи | | Статус заказа | перечисление | Статус, в который переводится заявка (для действия «Сменить статус заказа») | | Статус-источник заявок | перечисление | Статус заявок, из которых генерируются лиды (для действия «Генерация лидов из заявок») | | Целевая воронка | связь | Воронка, в которую переносится лид (для действия «Перенести в воронку») | | URL вебхука | ссылка | Адрес для вызова (для действия «Вызвать вебхук») | | HTTP-метод вебхука | перечисление | Метод запроса; на практике выполняется только POST | | Слот, Индекс | число | Служебные позиции для отображения в интерфейсе | | Дата создания, Дата изменения | дата/время | Служебные метки | В интерфейсе есть выбор HTTP-метода вебхука (POST, GET, PUT, PATCH, DELETE), но фактически система выполняет запрос только при выборе POST. Любой другой метод не приведёт ни к какому вызову. ### Действия триггера | Действие | Что делает | | ------------------------- | ------------------------------------------------------------------------- | | Отправить сообщение | Отправляет клиенту сообщение по SMS или через Wazzup (WhatsApp) | | Создать задачу | Создаёт задачу по лиду с указанным типом, сроком и описанием | | Сменить статус заказа | Переводит заявку лида в заданный статус (с побочными эффектами, см. ниже) | | Перенести в воронку | Переносит лид в другую воронку на её первый обычный этап | | Создать заявку | Создаёт заявку для лида, если её ещё нет | | Генерация лидов из заявок | Массово создаёт лиды из существующих заявок в заданном статусе | | Документ | Зарезервировано; при смене этапа не выполняется | | Вызвать вебхук | Отправляет данные лида POST-запросом на заданный адрес | Действие «Документ» существует в перечне, но движок автоматизации его не обрабатывает — при смене этапа оно ничего не делает. Точно так же движок при обычной смене этапа не выполняет «Генерация лидов из заявок»: это действие запускается отдельно, по служебному флагу при сохранении правила (см. раздел ниже). ### Лог смены этапа лида Каждая фактическая смена этапа, выполненная авторизованным пользователем, записывается в историю. | Поле | Тип | Назначение | | ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------- | | Лид | связь | Лид, у которого сменился этап | | Пользователь | связь | Кто выполнил смену (поле допускает пустое значение, но на практике запись создаётся только для авторизованного пользователя) | | Прежний этап | связь | Этап до перехода (пустой при первом попадании) | | Новый этап | связь | Этап после перехода | | Дата события | дата/время | Момент смены этапа | ## Как срабатывает автоматизация Автоматизация завязана на сохранение лида и работает в два шага. 1. **Перед сохранением** система запоминает прежний этап лида — тот, что был в базе до изменения. 2. **После сохранения** сравнивает прежний этап с новым. Если этап не изменился, ничего не происходит. Если изменился — запускается движок правил для нового этапа, а затем создаётся запись в истории смены этапов. При создании нового лида прежнего этапа нет (он считается пустым), поэтому если у лида сразу задан этап, это тоже считается сменой — и правила нового этапа выполняются уже при создании лида. Запись в историю смены этапа создаётся только тогда, когда действие выполнил авторизованный (неанонимный) пользователь. При этом сами правила автоматизации выполняются в любом случае — даже без пользователя (например, при системной смене этапа). То есть история может «недосчитаться» переходов, которые фактически произошли и запустили автоматику. ### Что делает движок правил Движок берёт все правила, привязанные к текущему этапу лида, и по очереди выполняет их. По умолчанию обрабатываются действия: создать задачу, перенести в воронку, отправить сообщение, создать заявку, сменить статус заказа, вызвать вебхук. Действия «Документ» и «Генерация лидов из заявок» при смене этапа не выполняются. Разберём каждое действие. #### Создать задачу Создаётся задача по лиду: с указанным типом задачи, менеджером лида, описанием из правила и дедлайном, который отсчитывается от момента срабатывания на величину «Срок задачи» (по умолчанию — сутки). #### Перенести в воронку Лид переносится в целевую воронку и ставится на её первый обычный этап (самый ранний по порядку этап обычного типа, то есть не системный «успех» и не «отмена»). Если целевая воронка не задана, действие пропускается. Перенос в воронку сам меняет этап лида и сохраняет его — а это снова считается сменой этапа и запускает движок правил уже для нового этапа. Настраивая цепочки переносов между воронками, следите, чтобы они не зацикливались. #### Отправить сообщение Сообщение отправляется, только если у лида есть клиент и в правиле задан текст. Если клиента нет, правило просто пропускается, а остальные правила этапа продолжают выполняться. * **По SMS** отправляется текст сообщения как есть (без подстановки полей). Перед отправкой телефон клиента проверяется на корректность. * **Через Wazzup (WhatsApp)** текст сначала прогоняется через подстановку значений: имя клиента, телефон, имя менеджера, а если у лида есть заявка — её номер, даты начала и конца аренды (плановые и фактические), суммы (цена, цена со скидкой, стоимость инвентаря, услуг, доставки, оплаченная сумма) и человекочитаемый статус заявки. Суммы подставляются уже с символом валюты компании, даты — в коротком формате по времени Asia/Tashkent. Шаблон сообщения для Wazzup поддерживает подстановку по именам полей. Если у лида нет заявки, поля, связанные с заявкой, в подстановке отсутствуют — используйте в шаблоне только имя, телефон и менеджера, либо убедитесь, что заявка к этому моменту уже создана. #### Создать заявку Если у лида ещё нет заявки, она создаётся. Заявка привязывается к клиенту лида и наследует из настроек компании: длительность аренды (плановые даты начала и конца), шаг и включённость пеней, процент и режим включения налога. Автором заявки становится текущий пользователь (или никто, если действие выполнено анонимно). Заявка не создастся, если у лида нет клиента, либо если заявка у лида уже есть. Это защищает от дублей. #### Сменить статус заказа Самое «тяжёлое» действие с несколькими побочными эффектами. * Если у лида ещё нет заявки, она сначала создаётся (по тем же правилам, что и выше). Если создать заявку не удалось (нет клиента), действие прекращается. * Если заявка уже в нужном статусе, ничего не меняется. * **Особый случай — перевод в аренду** (статусы «в аренде» / «просрочено» из состояний «запрос», «забронировано», «в аренде», «просрочено»): система фиксирует фактический старт аренды, отмечает выдачу инвентаря, а для позиций на продажу проставляет цену и дату продажи. Если у заявки вообще нет инвентаря, перевод в аренду не выполняется. Также записывается действие о выдаче. * При любой смене статуса пересчитывается дочерний заказ и перегенерируются задачи по начислению пеней, после чего статус заявки сохраняется. Перевод в аренду при отсутствии инвентаря в заявке прерывается досрочно — статус остаётся прежним, дочерний заказ и пени не пересчитываются. То есть «пустую» заявку это действие в аренду не переведёт. #### Вызвать вебхук Если задан адрес и выбран метод POST, на этот адрес отправляется POST-запрос с данными лида (этап, воронка, клиент, менеджер, источник, цена, заявка и т.д. в формате JSON). Если выбран любой метод, кроме POST, правило просто пропускается. Если у правила «Вызвать вебхук» не задан адрес, движок правил обрывается целиком: все оставшиеся правила этого этапа, стоящие после него, не выполнятся. Это отличается от остальных случаев, где неподходящее правило просто пропускается. Настраивая вебхук, всегда указывайте адрес. Вебхук вызывается синхронно, прямо в процессе сохранения лида, без фоновой задачи и без ограничения по времени ожидания. Медленный или недоступный внешний адрес затормозит операцию смены этапа. ## Генерация лидов из заявок Действие «Генерация лидов из заявок» стоит особняком: оно не срабатывает при смене этапа, а запускается вручную — при сохранении самого правила, если в запросе передан служебный флаг «Сгенерировать лиды». Как это работает: * Правило должно быть с действием «Генерация лидов из заявок», и у него должен быть задан статус-источник заявок. Иначе генерация не выполняется. * Для каждого этапа, к которому привязано правило, система берёт активные, неудалённые заявки с клиентом, находящиеся в статусе-источнике, и исключает те, у которых уже есть лид на этом этапе. * По каждой такой заявке создаётся лид: с клиентом и источником привлечения клиента, ценой из заявки со скидкой, ссылкой на заявку, на нужном этапе и в воронке этого этапа. Лиды при генерации создаются массово, поэтому автоматизация этапа для них НЕ запускается — то есть привязанные к этапу правила (сообщения, задачи и т.п.) на сгенерированных лидах не сработают. Массовая генерация только «наполняет» этап лидами. ## Управление правилами через API * Список правил можно отфильтровать по воронке (через этапы) и получить без постраничной разбивки; правила отсортированы по полю «Порядок» по убыванию. * Создание, чтение, изменение и удаление правила требуют авторизации. * Флаг «Сгенерировать лиды» доступен только на запись (в ответе не возвращается) и при создании, и при обновлении правила запускает описанную выше массовую генерацию. ## Как это используется на практике Типовые сценарии: * **Прогрев по этапам.** На этап «Новый лид» вешаем сообщение-приветствие через Wazzup, на этап «Согласование» — задачу менеджеру перезвонить в течение суток. * **Автоматический переход к сделке.** На этап «Выдача» вешаем «Сменить статус заказа» → «в аренде»: система сама создаст заявку (если нужно), зафиксирует старт аренды и оформит выдачу инвентаря. * **Разветвление воронок.** На финальном этапе вешаем «Перенести в воронку», чтобы лид автоматически уходил в другую воронку (например, постпродажного обслуживания). * **Интеграция с внешними системами.** Вебхук на нужном этапе отправляет данные лида в стороннюю систему. * **Первичное наполнение воронки.** Разово запускаем генерацию лидов из уже существующих заявок нужного статуса. ## Связанные страницы Полный перечень полей правил автоматизации, действий и лога смены этапов. Обзорная страница модуля продаж и всех его разделов. Воронки продаж и их этапы: системные типы успеха и отмены, автосоздание стартовых этапов и мягкое отключение. Лиды воронки, их связи с клиентом, заявкой и продажей, ручное упорядочивание и создание заявки из лида. Задачи и методы задач по лидам с дедлайном, назначением менеджера и уведомлениями. История смены этапов лида и массовые действия над лидами этапа: перенос, удаление, рассылка. Приём заявок с сайта через публичный вебхук и фоновая синхронизация сделок в Wazzup.