Роботы и фоновые задачи — это автоматизация, которая срабатывает не по действию оператора, а по времени или по условию в фоне: напоминания, регулярные проверки, отложенные действия и обработка очередей. Разберём, чем они отличаются от обычных триггеров и как их применять.
Событийные и фоновые механизмы
Всю автоматизацию RetailCRM можно поделить на две категории по способу запуска. Понимание разницы избавляет от типичной ошибки — попытки решить фоновую задачу событийным триггером.
| Тип | Что запускает | Пример |
|---|---|---|
| Событийный триггер | Действие: создание, смена статуса, поля | Уведомить при оплате заказа |
| Фоновая задача (по времени) | Расписание или истечение срока | Проверить неоплаченные заказы раз в час |
Событие происходит мгновенно и однократно. Фоновая задача работает регулярно и просматривает данные, где никакого события не было, — например, заказы, которые слишком долго висят в одном статусе.
Триггеры по времени
Ключевой фоновый инструмент — триггеры, срабатывающие по времени в статусе или по расписанию. Они закрывают задачи, которые нельзя поймать событием:
- Зависшие заказы. «В статусе Новый дольше 2 часов» → напоминание менеджеру.
- Ожидание оплаты. «Не оплачен 24 часа» → напоминание клиенту, затем отмена.
- Брошенные корзины. Отложенное сообщение через N минут после создания.
В статусе «Ожидает оплаты» > 24 ч → письмо клиенту + задача менеджеру
Отложенные и цепочечные действия
Фоновая механика позволяет строить последовательности во времени — сценарии, растянутые на часы и дни:
- Клиент оформил заказ — сразу подтверждение (событие).
- Через 3 дня без движения — напоминание (фон).
- Через 7 дней — предложение помощи или скидки (фон).
Такие цепочки лежат в основе реактивации и работы с брошенными корзинами. Каждый шаг — отдельное правило с условием выхода: если клиент оплатил или ответил, цепочка прерывается, чтобы не слать лишнее.
Обработка очередей и внешние вызовы
Фоновые задачи часто работают в связке с внешними системами. Тяжёлые операции не выполняют синхронно — их ставят в очередь и обрабатывают в фоне:
- массовая выгрузка заказов в 1С или ERP по расписанию;
- синхронизация остатков и цен с маркетплейсами;
- регулярный пересчёт сегментов и обновление статусов клиентов.
Для своих сценариев используют API и вебхуки: триггер по времени дёргает внешний сервис, а тот пакетно обновляет заказы. Это разгружает интерфейс и укладывается в лимиты API.
Мониторинг фоновых задач
Событийный триггер виден сразу: не пришло уведомление — заметили. Фоновая задача незаметна, поэтому её нужно наблюдать специально. Что стоит держать на контроле:
| Что смотрим | Признак проблемы |
|---|---|
| Число сработок правила | Резкий рост или ноль — задача сломалась или зациклилась |
| Возраст заказов в статусе | Накапливаются «зависшие» — фоновая проверка не отрабатывает |
| Очередь интеграций | Растёт задержка выгрузки — упёрлись в лимиты API |
Полезно завести контрольные фильтры и регулярный отчёт по «долгим» заказам. Если фоновое правило внезапно перестало срабатывать, именно эти фильтры покажут проблему раньше, чем о ней сообщит клиент.
Практика надёжной автоматизации
Чтобы фоновая автоматизация работала предсказуемо, придерживайтесь нескольких правил:
- Условие выхода. У каждой цепочки должно быть условие остановки, иначе клиент получит сообщение после оплаты.
- Идемпотентность. Повторный прогон задачи не должен дублировать действие — проверяйте флаг «уже выполнено».
- Логирование. Фиксируйте, что и когда сработало, — фоновые сбои незаметны без логов.
- Тестовый контур. Проверяйте расписания на ограниченной выборке, прежде чем включать на всём потоке.
Фон опаснее событий именно незаметностью: ошибка событийного триггера видна сразу, а сбой ночной задачи можно не замечать неделями.
Итог
Роботы и фоновые задачи — это вторая половина автоматизации RetailCRM: там, где событийные триггеры реагируют на действие, фоновые механизмы работают по времени и по расписанию. Они закрывают зависшие заказы, брошенные корзины, реактивацию и интеграции. Главное — задавать условия выхода, защищаться от дублей и следить за нагрузкой и логами.
Мы в B2Bsite настраиваем фоновую автоматизацию как часть общей воронки: проектируем триггеры по времени, отложенные цепочки и фоновые интеграции, закладывая контроль дублей и нагрузки.
Частые вопросы
Чем робот отличается от обычного триггера?
Обычный триггер срабатывает на событие — создание или смену статуса. Робот, или фоновая задача, работает по времени и расписанию, просматривая данные без события.
Как отловить заказы, зависшие в статусе?
Триггером по времени в статусе: например, «в статусе Новый дольше 2 часов» запускает напоминание менеджеру. Событийный триггер такой случай не поймает.
Насколько точно срабатывают триггеры по времени?
Они проверяются системой периодически, а не мгновенно. Планируйте интервалы с запасом и не рассчитывайте на точность до секунды.
Как сделать цепочку сообщений на несколько дней?
Через последовательность отложенных правил по времени с условием выхода: если клиент оплатил или ответил, цепочка прерывается, чтобы не слать лишнее.
Можно ли выгружать данные в 1С по расписанию?
Да, это типичная фоновая задача: триггер по времени вызывает внешний сервис через API, а тот пакетно выгружает заказы, не нагружая интерфейс.
Почему клиент получает сообщение после оплаты?
Обычно у отложенной цепочки нет условия выхода. Добавьте проверку, что заказ ещё не оплачен, чтобы фоновое действие не срабатывало задним числом.
Как защититься от дублей в фоновых задачах?
Делайте действия идемпотентными: перед выполнением проверяйте флаг «уже сделано», чтобы повторный прогон задачи не отправил сообщение дважды.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.