Сценарии в RetailCRM — это механизм автоматизации, который реагирует на события в системе и сам выполняет действия: меняет статус заказа, ставит задачу, отправляет уведомление или вызывает внешний сервис. По сути это связка «событие → условие → действие», которая работает без участия оператора.
Что такое «Сценарии» и как они устроены
Сценарий (в интерфейсе RetailCRM его основа — триггер) — это правило, которое система проверяет при наступлении определённого события: создан заказ, сменился статус, изменилось поле клиента, пришло сообщение в чат. Если условия правила выполнены, RetailCRM автоматически запускает одно или несколько действий.
Логически любой сценарий состоит из трёх частей:
- Событие — что должно произойти, чтобы правило проверилось (например, «Заказ изменён»);
- Условия — фильтр, при котором действия сработают (статус, сумма, источник, склад, метод оплаты);
- Действия — что сделать (сменить статус, назначить менеджера, отправить SMS/email, вызвать webhook).
Где искать инструмент в системе
Настройки автоматизации живут в административном разделе. Ориентиры для навигации:
Настройки → Триггеры— основной раздел, где создаются и редактируются правила;Настройки → Коммуникации → Правила— автоматизация чатов и распределения диалогов;Настройки → СтатусыиГруппы статусов— на них опираются условия и действия сценариев.
Доступ к настройкам сценариев обычно есть только у администратора и ответственных за автоматизацию. Операторам правила не видны — они просто пользуются результатом: заказ сам «переезжает» по воронке, задачи появляются вовремя, клиент получает уведомления.
На какие события реагируют сценарии
Набор событий определяет, когда вообще запускается проверка правила. Основные типы:
| Событие | Когда срабатывает | Типовое применение |
|---|---|---|
| Заказ создан | При появлении нового заказа с сайта, маркетплейса, вручную | Первичное распределение, автостатус «Новый» |
| Заказ изменён | При смене статуса, суммы, состава, полей | Задачи менеджеру, уведомления клиенту |
| Клиент изменён | При обновлении данных или сегмента | Пометки, программы лояльности |
| Входящее сообщение | Новое обращение в чат или мессенджер | Автоответ, распределение диалога |
| По расписанию | Через заданный интервал после события | Догоняющие письма, контроль сроков |
Отдельно стоит выделить отложенные сценарии: они срабатывают не сразу, а через N часов или дней после события — это база для брошенных корзин и напоминаний.
Зачем это нужно бизнесу
Сценарии убирают ручную рутину и делают воронку предсказуемой. Что это даёт на практике:
- Скорость реакции. Заказ распределяется на менеджера и уходит в работу за секунды, а не после того, как кто-то заглянул в список.
- Единый стандарт. Клиент всегда получает уведомление о смене статуса, а менеджер — задачу. Человеческий фактор минимизируется.
- Экономия времени операторов. Рутинные переводы статусов, заполнение полей и рассылки уходят на автомат.
- Контроль SLA. Сценарий по расписанию подсветит зависшие заказы и не даст им «протухнуть».
Чем сценарии отличаются от смежных механизмов
В RetailCRM автоматизация не сводится к одному инструменту. Разграничим понятия, чтобы не путать их при настройке:
- Триггеры — событийная автоматизация внутри CRM (то, что мы и называем сценариями).
- Правила коммуникаций — распределение и обработка диалогов в чат-центре.
- Динамические сегменты — не действия, а живые выборки клиентов по условиям; сценарии могут на них опираться.
- API и webhooks — внешняя логика: когда действий стандартного триггера не хватает, сценарий передаёт событие во внешний сервис.
На практике зрелая автоматизация — это комбинация: сегменты задают «кому», триггеры — «когда и что», а webhooks расширяют «как» за пределы коробки.
С чего начать внедрение
Не стоит сразу строить десятки правил. Разумный порядок:
- Опишите воронку статусов на бумаге — какие переходы обязательны и кто за них отвечает.
- Выделите 3–5 самых частых ручных операций (перевод статуса, назначение менеджера, уведомление клиенту).
- Сделайте по ним первые сценарии и обкатайте на реальном потоке пару дней.
- Только потом добавляйте ветвления, отложенные действия и интеграции.
Итог
«Сценарии» в RetailCRM — это фундамент автоматизации ритейла: событие запускает проверку условий, а система сама выполняет нужные действия. Инструмент экономит время операторов, стандартизирует воронку и ускоряет обработку заказов. Начинать стоит с простых правил на частых операциях и постепенно наращивать логику.
Мы в B2Bsite помогаем спроектировать статусную модель, собрать первые рабочие сценарии и связать их с интеграциями так, чтобы автоматизация приносила пользу, а не хаос. Если нужен запуск с нуля или ревизия существующих правил — подключимся на любом этапе.
Частые вопросы
Триггеры и сценарии — это одно и то же?
В контексте RetailCRM да: основа сценария автоматизации — триггер, который реагирует на событие и выполняет действия. «Сценарий» — более общее название для такой связки правил.
Нужен ли программист, чтобы настроить сценарий?
Базовые сценарии настраиваются в интерфейсе без кода. Программист нужен, когда требуется вызвать внешний сервис через webhook или обработать нестандартную логику через API.
Сколько сценариев можно создать?
Жёсткого лимита в интерфейсе обычно нет, но избыток пересекающихся правил усложняет поддержку. Лучше несколько продуманных сценариев, чем десятки дублирующих друг друга.
Сценарий срабатывает мгновенно?
Событийные триггеры отрабатывают почти сразу после события. Отдельно есть отложенные и периодические сценарии, которые запускаются через заданный интервал.
Можно ли временно отключить правило?
Да, любой триггер можно деактивировать без удаления. Это удобно на время отладки или сезонных акций.
Видят ли операторы сами сценарии?
Обычно нет — доступ к настройкам автоматизации есть у администратора. Операторы работают с результатом: статусами, задачами и уведомлениями.
С чего начать, если автоматизации ещё нет?
С описания воронки статусов и 3–5 самых частых ручных операций. По ним делают первые сценарии и обкатывают на реальных заказах.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.