Триггеры в RetailCRM: как работают

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

Что такое триггер и зачем он нужен

Триггер в RetailCRM — это правило вида «когда произошло событие и выполнены условия — сделай действия». Он работает в фоне: менеджеру не нужно нажимать кнопку, система реагирует на изменения в заказе или карточке клиента сама. Настраиваются триггеры в разделе Настройки → Коммуникации → Триггеры.

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

• Скорость — реакция происходит в момент события, а не когда до заказа дошли руки.
• Единообразие — процесс идёт одинаково у всех операторов и во всех сменах.
• Разгрузка — менеджер занимается продажей и клиентом, а не механикой.

Анатомия триггера: событие, условия, действия

Любой триггер состоит из трёх блоков, и понимание их связки — половина успеха при настройке.

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

Какие события бывают

Событие — это тип изменения, за которым триггер «наблюдает». В RetailCRM их несколько групп:

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

Условия и действия на практике

Условия строятся по полям заказа и клиента: статус, группа статусов, сумма, оплата, способ и служба доставки, источник, магазин, ответственный, пользовательские поля, принадлежность к сегменту. Условия можно комбинировать по И/ИЛИ, собирая довольно тонкий фильтр.

Действия — это то, ради чего триггер и создаётся:

1. сменить статус или группу статусов заказа;
2. назначить или сменить ответственного менеджера;
3. заполнить или очистить поле заказа/клиента;
4. отправить уведомление клиенту (SMS, email, сообщение в мессенджер);
5. поставить задачу менеджеру со сроком;
6. отправить данные во внешнюю систему по HTTP (вебхук).

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

Порядок срабатывания и защита от циклов

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

Хорошая практика — проектировать цепочку на бумаге: событие → условие → действие → какое новое событие это породит. Тогда видно, где нужен предохранитель.

Типичные ошибки при работе с триггерами

Большинство проблем с автоматизацией — это не баги RetailCRM, а неточная логика правил.

• Слишком широкие условия — триггер срабатывает на заказах, для которых не предназначался.
• Нет условия-предохранителя — правило зацикливается или шлёт клиенту повторные сообщения.
• Конфликт правил — два триггера тянут заказ в разные статусы на одно событие.
• Тесты на боевых заказах — клиент получает «черновые» SMS. Лучше проверять на тестовом заказе и отдельном номере.

Перед запуском полезно составить таблицу всех активных триггеров с их событиями и статусами — так конфликты видно заранее.

Итог

Триггер RetailCRM — это связка «событие → условия → действия», и вся автоматизация магазина строится из таких кирпичей. Понимая, когда правило просыпается, для каких заказов работает и что порождает, вы получаете предсказуемый конвейер вместо хаоса ручных действий. Ключ к надёжности — точные условия и защита от циклов.

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