Настройка статусов заказов и групп

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

Двухуровневая модель

RetailCRM использует два уровня: группы статусов и сами статусы. Группа — это крупный этап обработки («Новый», «Комплектация», «Доставка»), а статусы внутри — конкретные состояния этого этапа. Именно группы отображаются как столбцы в канбан-доске и как этапы в отчётах по воронке.

Настраивается всё в разделе Администрирование → Статусы. Сначала создают группы, затем распределяют по ним статусы и задают порядок.

Типовая воронка заказа

Для интернет-магазина базовая воронка выглядит так:

Это отправная точка. Под конкретный бизнес воронку адаптируют, но резко раздувать её на старте не стоит.

Финальные группы

Две группы играют особую роль — «Выполнен» и «Отменён». Заказы в них считаются завершёнными: они уходят из активной работы, по-разному учитываются в отчётах и влияют на остатки. Отмена освобождает резерв, а выполнение фиксирует продажу.

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

Связь с остатками

Статусная модель напрямую управляет товаром. К переходам между группами привязываются резервирование и списание остатков, поэтому склад и статусы проектируют вместе.

1. При создании заказа товар резервируется.
2. В отгрузочной группе резерв превращается в списание.
3. При отмене резерв освобождается и остаток возвращается.

Если эти связи настроены неверно, склад «врёт»: товар либо висит в резерве по мёртвым заказам, либо продаётся дважды. Поэтому логику остатков проверяют тестовым заказом по всей воронке.

Статусы и автоматизация

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

• Уведомление клиенту при переходе в «Передан в службу».
• Задача менеджеру при зависании в «Не дозвонились».
• Автосмена статуса при поступлении оплаты.

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

Частые ошибки

Проблемы со статусами всплывают в отчётах и в работе менеджеров.

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

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

Итог

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

Мы проектируем статусную модель под ваши процессы и связываем её с остатками и триггерами при настройке и автоматизации RetailCRM. Это превращает воронку из формальности в рабочий инструмент контроля и роста конверсии.