Триггеры и правила RetailCRM для магазина на 1С-Битрикс

Заказ оформлен на сайте, упал в RetailCRM — и дальше начинается ручная рутина: менеджер вспоминает, что нужно позвонить, отправить реквизиты, поставить в резерв, обновить статус, а вечером свериться, кому не дозвонились. Пока заказов десятки в день, это терпимо. Когда их сотни и они приходят с сайта на 1С-Битрикс, из маркетплейсов и телефонии одновременно — ручное сопровождение начинает ронять конверсию: клиент не получил подтверждение вовремя, заказ «завис» в статусе, менеджер забыл перезвонить. Лечится это триггерами и правилами RetailCRM — сценариями, которые сами реагируют на события заказа и выполняют рутинные действия без участия человека.

Ниже — практическая настройка триггерных сценариев RetailCRM для магазина на Битрикс: какие бывают события и действия, как строить автоответы клиентам, автоматически двигать статусы, ставить задачи менеджерам и, главное, как связать всё это с заказами сайта, чтобы статусы в CRM и в Битрикс не расходились. Это выжимка из наших проектов по интеграции и настройке RetailCRM — без теории ради теории, с упором на то, что реально ломается на боевых магазинах.

Что такое триггеры и правила RetailCRM

Триггер в RetailCRM — это автоматический сценарий, который срабатывает на определённое событие и выполняет заданное действие. Его удобно держать в голове как формулу из трёх частей: событие (что произошло с заказом или клиентом), условие (фильтр, при котором сценарий вообще нужно запускать) и действие (что сделать в ответ). Например: «заказ создан» (событие) «и сумма больше 30 000 рублей» (условие) «→ поставить задачу старшему менеджеру» (действие).

Событий у заказа много: создание, смена статуса, изменение суммы, добавление или удаление товара, назначение ответственного, оплата, отсутствие активности в течение N часов. Событий у клиента тоже хватает: первая покупка, повторный заказ, день рождения, изменение сегмента. Действия — это отправка e-mail, SMS или сообщения в мессенджер, смена статуса заказа, назначение ответственного, создание задачи, добавление тега, вызов внешнего HTTP-запроса. Комбинируя события, условия и действия, вы описываете практически любую операционную логику магазина, не привлекая программиста на каждый чих.

Отдельно от триггеров существуют правила в блоке автоматизации и бизнес-процессы. Правило — это условие с фильтром, которое применяется к выборке заказов (например, «все неоплаченные заказы старше трёх дней перевести в статус „ожидает отмены“»). Бизнес-процесс — многошаговая цепочка с ветвлениями и ожиданиями, которая тянется днями. Для большинства повседневных задач магазина хватает именно триггеров: они простые, наглядные и срабатывают мгновенно. Разницу между этими инструментами мы подробно разберём в отдельном разделе ниже.

Зачем магазину на Битрикс триггерные сценарии

Магазин на 1С-Битрикс отвечает за витрину, корзину и оформление заказа, а RetailCRM — за то, что происходит с заказом после оформления: обработку, дозвон, резервы, доставку, повторные продажи. Триггеры закрывают именно эту «послевитринную» часть, где раньше всё держалось на памяти и дисциплине менеджеров. Что это даёт бизнесу на практике:

• Скорость реакции. Клиент получает подтверждение заказа и статус доставки в секунды после события, а не когда до него дойдут руки менеджера. Быстрый отклик напрямую снижает отмены и «я передумал».
• Ничего не теряется. Заказ без ответа, недозвон, неоплаченный счёт — на каждый такой случай триггер сам создаёт задачу с дедлайном. Воронка перестаёт «протекать» на человеческом факторе.
• Единый статус для клиента и склада. Автоматическая смена статусов держит в согласии CRM, сайт на Битрикс и склад: покупатель, менеджер и кладовщик видят одно и то же состояние заказа.
• Разгрузка менеджеров. Рутинные сообщения и переводы статусов уходят в автоматику, а люди занимаются тем, где действительно нужен человек — сложными заказами и продажами.
• Управляемая коммуникация. Все касания с клиентом описаны сценариями, а не импровизацией конкретного сотрудника. Тон, тайминг и содержание сообщений становятся предсказуемыми.

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

Архитектура: как связаны RetailCRM и заказы Битрикс

Чтобы настраивать триггеры осознанно, нужно держать в голове, как заказ путешествует между сайтом и CRM. Схема почти всегда одинаковая: заказ рождается на витрине Битрикса, по API уходит в RetailCRM, там его подхватывают триггеры, а результат их работы — новый статус, сообщение клиенту, задача менеджеру — возвращается на сайт через тот же обмен.

• Сайт на 1С-Битрикс. Оформление заказа, корзина, личный кабинет покупателя. Здесь заказ появляется впервые и здесь же клиент видит его статус.
• Модуль интеграции RetailCRM. Прослойка, которая по API передаёт заказы и клиентов на сторону CRM и принимает обратно изменения статусов, ответственных и трек-номеров.
• Ядро RetailCRM. Единая карточка заказа и клиента, воронка статусов, история коммуникаций. Именно здесь живут триггеры и правила.
• Движок триггеров. Слушает события заказов и клиентов, проверяет условия и выполняет действия — сообщения, смену статусов, задачи, HTTP-запросы.
• Каналы коммуникаций. E-mail, SMS, мессенджеры, телефония — через них уходят автоответы и уведомления, инициированные триггерами.

Понимание этой цепочки сразу подсказывает, где искать проблему. Если триггер отработал в CRM, но на сайте статус не поменялся — смотрим сопоставление статусов и логи модуля интеграции. Если сообщение клиенту не ушло — смотрим канал и шаблон. Если триггер вообще не запустился — проверяем событие и условие. Разделяйте «CRM-сторону» и «сторону обмена с Битриксом»: лечатся они по-разному.

Типы триггеров и события заказа

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

Дальше это множество событий раскладывается на несколько практических «жанров» триггеров, которые встречаются почти в каждом магазине:

• Транзакционные уведомления. Подтверждение заказа, смена статуса, трек-номер, напоминание об оплате. Самые важные и безопасные — с них стоит начинать.
• Операционные переводы статусов. Автоматическое «оплачен → в сборке», «недозвон → повторный дозвон», «нет оплаты 3 дня → ожидает отмены».
• Задачи и распределение. Постановка задач менеджерам, назначение ответственных, эскалация зависших заказов руководителю.
• Маркетинговые и реактивационные. Догоняющие цепочки, брошенная корзина, реактивация «спящих» клиентов. Их включают позже и осторожно.

Модель статусов и её синхронизация

Статусы заказа — это скелет, на котором держатся все триггеры. Именно смена статуса чаще всего служит и событием (по нему запускается сценарий), и действием (сценарий переводит заказ в новый статус). Поэтому прежде чем настраивать автоматику, приведите в порядок саму воронку статусов и её сопоставление между RetailCRM и Битриксом.

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

Практические правила проектирования воронки под триггеры:

• Один статус — одно состояние. Не смешивайте в одном статусе разные ситуации («недозвон» и «ждёт оплаты» — это разные статусы, иначе триггеры не смогут их различить).
• Полное сопоставление. Каждый статус RetailCRM, который может увидеть клиент на сайте, должен иметь пару в Битриксе, и наоборот.
• Конечные статусы отдельно. «Выполнен» и «Отменён» — терминальные, из них триггеры обычно уже не двигают заказ дальше, только фиксируют факт.
• Причины отмен — в отдельное поле. Не плодите десятки статусов отмены; используйте статус «Отменён» и справочник причин, по которому потом удобно строить аналитику.

Автоответы и уведомления клиенту

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

Типовой набор транзакционных автоответов для магазина на Битрикс:

• Подтверждение заказа. Сразу после события «заказ создан»: номер, состав, сумма, способ оплаты и доставки, контакт менеджера.
• Смена статуса. «Заказ собран», «передан в доставку», «готов к выдаче» — по ключевым переходам воронки, а не по каждому.
• Трек-номер. Когда заказ уходит в доставку, клиент получает ссылку на отслеживание.
• Напоминание об оплате. Если выбрана предоплата, а оплаты нет — мягкое напоминание с задержкой.
• Запрос отзыва. Через несколько дней после статуса «выполнен» — просьба оценить покупку.

Важнейший принцип автоответов — не превратить заботу в спам. Для этого разделяйте каналы и события: подтверждение заказа логично отправить и на e-mail, и коротким SMS, а вот сыпать SMS по каждому промежуточному статусу не нужно. Ставьте задержки там, где сообщение имеет смысл только через время (напоминание об оплате — не в ту же секунду, запрос отзыва — спустя дни). И обязательно учитывайте согласие на маркетинговую рассылку: транзакционные сообщения о заказе клиент ждёт, а вот «догоняющие» и рекламные требуют согласия и должны иметь отписку.

Автоматическая смена статусов

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

• «Оплачен» → «В сборке». Как только зафиксирована оплата предоплатного заказа, он автоматически уходит на комплектацию, а складу ставится задача.
• «Недозвон» с эскалацией. После первого недозвона заказ переводится в статус «повторный дозвон» с задачей менеджеру; после третьего — эскалация руководителю.
• «Нет оплаты 3 дня» → «Ожидает отмены». Неоплаченные счета не висят вечно: триггер по бездействию переводит их в предотменный статус и уведомляет менеджера.
• «Доставлен» → «Выполнен». После подтверждения вручения заказ закрывается, запускается запрос отзыва и начисление бонусов.

Главная опасность автоматической смены статусов — зацикливание и дубли. Если триггер ловит событие «сменился статус» и сам же меняет статус, легко получить цепочку срабатываний. Поэтому автоматические переходы всегда описывайте максимально узко: указывайте конкретный исходный и целевой статус («из „оплачен“ в „в сборке“», а не «в любой»), ограничивайте типами заказов и, где нужно, помечайте триггер как срабатывающий один раз на заказ. И держите в голове связку с Битриксом: каждый автоматический перевод статуса в CRM должен корректно доехать до сайта — проверяйте это на тестовом заказе, а не только в интерфейсе CRM.

Задачи менеджерам и распределение

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

Типовые задачные сценарии:

• Дозвон по новому заказу. Заказ создан → задача «связаться с клиентом» ответственному менеджеру с дедлайном в 15–30 минут.
• Согласование крупного заказа. Сумма выше порога → задача старшему менеджеру проверить состав и условия.
• Проблемная доставка. Статус «возврат» или «недоставлен» → задача разобраться, с пометкой приоритета.
• Зависший заказ. Нет активности N часов → напоминание ответственному, при повторе — эскалация руководителю.

Отдельная тема — распределение ответственных. RetailCRM умеет назначать менеджера не только «в лоб», но и по правилам: по кругу (round-robin), по загрузке, по региону или каналу заказа. Для магазина на Битрикс это удобно связать с источником: заказы с сайта — на одну группу, из маркетплейсов — на другую, оптовые — на менеджеров B2B-направления. Так триггер и ставит задачу, и сразу кладёт её на стол нужному человеку.

Правила, триггеры и бизнес-процессы — разница

Начинающие часто путают три инструмента автоматизации RetailCRM и берут не тот под задачу. Разберём различия по существу, потому что от выбора зависит и надёжность, и удобство поддержки.

Практическое правило выбора: если нужно «сделать что-то одно сразу после события» — это триггер. Если нужно «применить действие ко всем заказам, подходящим под фильтр» — это правило. Если нужна длинная цепочка с ожиданиями «подождать день, если не оплатил — написать, если и потом молчит — отдать менеджеру» — это бизнес-процесс. Большинство магазинов на Битрикс на 80% закрываются триггерами, и только сложные маркетинговые сценарии требуют бизнес-процессов.

Реализация: настройка триггеров пошагово

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

1. Опишите воронку и события. До открытия настроек составьте карту статусов и список событий, на которые хотите реагировать. Без этого триггеры быстро превращаются в хаос из противоречащих сценариев.
2. Сопоставьте статусы RetailCRM и Битрикс. В настройках интеграции задайте полную таблицу соответствия статусов в обе стороны. Это фундамент: без него смена статуса не доедет до сайта.
3. Настройте каналы коммуникаций. Подключите e-mail, SMS и мессенджеры, проверьте, что сообщения из CRM реально уходят и доходят до тестового адреса и номера.
4. Соберите шаблоны сообщений. Подготовьте тексты автоответов с переменными (номер заказа, имя, сумма, трек-номер). Проверьте, что переменные подставляются корректно.
5. Включите транзакционные триггеры. Начните с подтверждения заказа и уведомлений о ключевых статусах. Это самые безопасные сценарии — включайте их первыми и по одному.
6. Добавьте автоматические статусы. Настройте очевидные переходы («оплачен → в сборке») с узкими условиями «из статуса → в статус» и, где нужно, однократным срабатыванием.
7. Настройте задачи и распределение. Опишите задачные сценарии с дедлайнами и ответственными, задайте правила распределения по источнику заказа.
8. Прогоните тестовые заказы. Оформите заказ на сайте Битрикс и проведите его по всей воронке, проверяя на каждом шаге сообщения, статусы (в CRM и на сайте) и задачи.
9. Включайте по одному и наблюдайте. После проверки постепенно добавляйте маркетинговые и реактивационные сценарии, отслеживая эффект каждого по метрикам.

Связь с заказами сайта на 1С-Битрикс

Это раздел, ради которого чаще всего и настраивают триггеры именно в связке с Битриксом. Заказ живёт в двух системах одновременно, и задача — чтобы они всегда показывали согласованное состояние. Разберём, как это работает и что проверять.

Обмен между RetailCRM и сайтом идёт через модуль интеграции по API. Заказ, оформленный на витрине Битрикса, выгружается в CRM; изменения в CRM (статус, ответственный, трек-номер, комментарии) возвращаются на сайт. Когда триггер меняет статус в CRM, срабатывает исходящая синхронизация, и заказ в Битрикс переходит в сопоставленный статус — при условии, что сопоставление настроено. Клиент в личном кабинете сайта видит тот же статус, что и менеджер в CRM.

Что важно проверять именно на стороне связки с Битриксом:

• Полнота маппинга статусов. Каждый статус, который может выставить триггер, должен иметь пару в Битриксе. Непарные статусы — главная причина «зависших» заказов.
• Направление синхронизации. Определитесь, какая система — мастер по статусу заказа. Обычно операционные статусы ведёт CRM, а факт оплаты может приходить с сайта; двусторонний обмен без ясного «мастера» порождает конфликты.
• Задержки и очередь обмена. Синхронизация не всегда мгновенна: если обмен идёт пачками или по расписанию, клиент увидит новый статус на сайте с задержкой. Учитывайте это в текстах уведомлений.
• Логи и повторные попытки. Настройте, чтобы неудавшиеся синхронизации логировались и повторялись, а не терялись молча. По логам модуля интеграции проще всего искать, почему статус не доехал.

Тонкости самого обмена заказами и клиентами мы разбираем в отдельном материале про интеграцию 1С-Битрикс с RetailCRM, а вопросы единой карточки покупателя — в статье про синхронизацию клиентской базы между сайтом, CRM и 1С. Если триггеры должны ещё и начислять баллы или применять акции, смотрите разбор программы лояльности и бонусов в 1С-Битрикс — там про то, как связать статус заказа с бонусной механикой.

Шаблоны сообщений и переменные

Качество автоответов на 90% определяется шаблонами. Хороший шаблон — это не просто текст, а текст с переменными, который подставляет данные конкретного заказа и клиента. Плохой шаблон превращает автоматизацию в источник претензий: «пришло письмо с пустым номером заказа», «в SMS половина текста обрезалась».

Что должен уметь шаблон сообщения из триггера:

• Подставлять данные заказа. Номер, состав, сумма, способ оплаты и доставки, адрес, трек-номер — через переменные, а не вручную.
• Обращаться по имени. Имя клиента из карточки, с корректной обработкой случая, когда имя не заполнено.
• Указывать контакт менеджера. Ответственный по заказу и способ с ним связаться — чтобы клиент знал, к кому обращаться.
• Учитывать канал. Для SMS — короткий текст без HTML и в пределах лимита символов; для e-mail — полноценное письмо; для мессенджера — свой формат.

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

Тестирование и отладка триггеров

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

Практический порядок отладки:

1. Тестовый заказ на всю воронку. Оформите заказ на сайте Битрикс и проведите его по всем статусам, фиксируя на каждом шаге, что сработало и что нет.
2. Проверка на пограничных данных. Заказ без телефона, без имени, с нулевой суммой, самовывоз без адреса — сценарии не должны падать или слать бессмысленные сообщения.
3. Контроль дублей. Убедитесь, что триггер срабатывает столько раз, сколько задумано. Логи действий по заказу покажут, если сценарий сработал дважды.
4. Сверка статусов на обеих сторонах. После каждого перевода статуса смотрите не только CRM, но и заказ на сайте — они должны совпадать.
5. Пробный период на части заказов. Новые маркетинговые сценарии сначала включайте на сегменте или с ограничением, а не сразу на всём потоке.

Главный инструмент отладки — история действий по заказу и логи модуля интеграции. По истории видно, какой триггер и когда сработал, а по логам обмена — доехал ли результат до Битрикса. Если что-то пошло не так, начинайте разбор именно отсюда, а не с гадания.

Метрики и контроль эффективности

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

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

Частые ошибки при настройке

• Не сопоставили статусы RetailCRM и Битрикс до включения триггеров — смена статуса в CRM не доезжает до сайта, заказы «зависают», клиент видит устаревшее состояние.
• Условие триггера слишком широкое, без «из статуса → в статус» и без однократности — сценарий срабатывает по нескольку раз, клиент получает дубли сообщений.
• Смешали транзакционные и маркетинговые сообщения в одном сценарии — рекламная цепочка уходит без согласия на рассылку, растут жалобы и отписки.
• Включили все триггеры разом на боевом магазине — невозможно понять, какой сценарий что сломал, обмен статусами превращается в кашу.
• Задача менеджеру создаётся без дедлайна и ответственного — оседает в общем списке и не выполняется, автоматизация только имитирует контроль.
• Шаблоны не проверили на пустых значениях — клиент получает «Здравствуйте, !» и письма с голыми плейсхолдерами вместо номера заказа.
• Автоматический перевод статусов зациклился, потому что триггер реагирует на своё же действие — заказ прыгает по статусам, засоряет историю и обмен.
• Не настроили логирование и повторные попытки синхронизации — неудавшийся обмен теряется молча, а расхождение статусов всплывает только по жалобе клиента.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность триггерных сценариев перед запуском:

1. Воронка описана. Статусы разложены по этапам, каждое состояние заказа — отдельный статус, причины отмен вынесены в справочник.
2. Статусы сопоставлены. Полная таблица соответствия RetailCRM ↔ Битрикс задана в обе стороны, непарных статусов нет.
3. Каналы работают. E-mail, SMS и мессенджеры подключены и проверены на тестовых адресах и номерах.
4. Шаблоны собраны и протестированы. Переменные подставляются, пустые значения обработаны, SMS укладываются в лимит.
5. Транзакционные триггеры включены первыми. Подтверждение заказа и уведомления о ключевых статусах работают и проверены.
6. Автостатусы описаны узко. Переходы заданы «из статуса → в статус», где нужно — однократные, зацикливания исключены.
7. Задачи с дедлайнами. У каждой автоматической задачи есть ответственный и срок, распределение по источнику заказа настроено.
8. Синхронизация проверена сквозным заказом. Тестовый заказ проведён по всей воронке, статусы в CRM и на сайте совпадают на каждом шаге.
9. Логи и метрики настроены. Ошибки обмена логируются и повторяются, ключевые показатели снимаются до и после запуска.

Вывод

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