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

Ручное переключение статусов — главный пожиратель времени операторов. RetailCRM умеет двигать заказы по воронке сама: по факту оплаты, по данным службы доставки, по времени в статусе. Разберём, как выстроить статусную модель и автоматизировать переходы.

Статусы и группы статусов

В RetailCRM статус — это конкретный этап заказа, а группа статусов — крупная стадия воронки, объединяющая несколько статусов. Настраиваются они в Настройки → Статусы.

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

Почему смену статусов стоит автоматизировать

Статус — это не просто метка. От него зависят уведомления клиенту, задачи менеджерам, отчётность и списание остатков. Когда статус двигают вручную, возникают типовые проблемы:

• заказ «застревает» — оплачен, но никто не перевёл в сборку;
• клиент не получает уведомление, потому что статус не сменили вовремя;
• аналитика врёт — воронка показывает не реальную картину;
• операторы тратят часы на механические клики.

Автоматическая смена статусов убирает человеческий фактор из самого частого действия в системе.

Как настроить переходы через триггеры

Основной инструмент — триггеры (Настройки → Коммуникации → Триггеры). Логика перехода описывается как «событие + условие → сменить статус».

1. Оплата получена → «Комплектация». Событие «Заказ изменён», условие «Оплата = получена И группа = Новый».
2. Отгрузка создана → «Доставка». При появлении трек-номера от службы доставки.
3. Доставлен → «Выполнен». По статусу от курьерской интеграции.
4. Нет активности N дней → «Не дозвонились». Событие «По времени».

Каждый переход — отдельное правило, а вместе они образуют конвейер: заказ сам идёт от «Нового» до «Выполнен».

Переходы по данным оплаты и доставки

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

• Оплата. Платёжный шлюз сообщает об успешной оплате — триггер двигает заказ в комплектацию.
• Доставка. СДЭК, DPD или Boxberry передают статусы отправления — заказ автоматически идёт «В пути», «Ожидает в ПВЗ», «Вручён».
• Маркетплейсы. Заказы Ozon и Wildberries тянут свои статусы отгрузки в единую воронку.

Защита от откатов и зацикливания

Главная опасность автопереходов — конфликтующие правила и повторные срабатывания. Заказ может «прыгать» между статусами, если два триггера тянут его в разные стороны на одно событие.

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

Контроль зависших заказов

Автоматизация переходов раскрывается вместе с контролем «застрявших» заказов. Событие «По времени» позволяет ловить заказы, которые слишком долго висят на этапе:

• оплачен, но не собран дольше суток — задача складу;
• в доставке дольше планового срока — задача менеджеру проверить трек;
• в согласовании дольше двух дней — напоминание перезвонить.

Такие правила не двигают статус силой, а привлекают внимание человека там, где конвейер сбоит. Это баланс между автоматикой и контролем.

Итог

Автоматическая смена статусов — это связка продуманной статусной модели, триггеров на переходы и интеграций с оплатой и доставкой. Заказ идёт по воронке сам, клиент вовремя получает уведомления, а аналитика отражает реальность. Ключ к стабильности — условия-предохранители и чистая карта переходов без лишних откатов.

Мы в B2Bsite проектируем статусные модели и автопереходы с нуля: от структуры групп статусов до связки с платёжными и логистическими сервисами. Поможем настроить воронку так, чтобы заказы двигались без ручных кликов.