Статус — это состояние заказа в воронке, а группа статусов — это этап, который задаёт поведение системы: резервировать товар или нет, считать заказ закрытым или активным, запускать ли автоматизацию. Правильно выстроенная статусная модель — основа порядка в RetailCRM: по ней строятся фильтры, отчёты, триггеры и распределение работы между операторами.
Как устроена статусная модель
В RetailCRM каждый заказ в любой момент времени находится ровно в одном статусе. Все статусы объединены в группы статусов — укрупнённые этапы жизненного цикла заказа. Иерархия строгая: статус всегда принадлежит одной группе, группа содержит один или несколько статусов.
Различие принципиальное: статус вы видите в карточке и в списке заказов, а группа определяет техническое поведение системы. Например, десяток разных статусов («Ждёт сборки», «На комплектации», «Собран») может входить в одну группу «Комплектация» — и для всех них товар будет одинаково зарезервирован на складе.
- Статус — точка воронки, которую меняет оператор вручную или триггер автоматически.
- Группа — этап, к которому привязаны правила резерва, признак финальности и логика отчётов.
- Символьный код — латинское имя статуса и группы, по которому к ним обращается API и импорт.
Стандартные группы статусов
В новом аккаунте RetailCRM уже есть базовый набор групп, покрывающий типовой путь заказа в интернет-магазине. Их можно переименовать, дополнить или скрыть под свои процессы.
| Группа | Смысл этапа | Резерв товара |
|---|---|---|
| Новый | Заказ создан, но ещё не обработан оператором | Да |
| Согласование | Уточнение состава, наличия, условий с клиентом | Да |
| Комплектация | Сборка и подготовка заказа к отгрузке | Да |
| Доставка | Заказ передан в службу доставки или курьеру | Да |
| Выполнен | Заказ доставлен и оплачен — финальный успех | Списание |
| Отменён | Заказ не состоялся — финальный отказ | Нет |
Две последние группы — финальные. После перехода в них заказ считается закрытым: он выпадает из активной работы, перестаёт держать резерв «в пути» и попадает в соответствующую сводку — продажи или отказы.
Резерв, финальные группы и отмены
Главная бизнес-логика, завязанная на группу, — резервирование товара. Пока заказ находится в рабочей группе (Новый, Согласование, Комплектация, Доставка), его позиции удерживаются на складе и уменьшают доступный остаток, чтобы товар не был продан дважды.
При переходе в группу Выполнен происходит списание — товар уходит со склада окончательно. При переходе в группу Отменён резерв освобождается, и остаток возвращается в продажу. Именно поэтому важно, чтобы каждый статус был привязан к правильной группе: ошибочная привязка ломает учёт остатков.
- Финальных групп может быть несколько — например, отдельные группы отмены «Отказ клиента» и «Нет в наличии» для аналитики причин.
- Группа отмены обычно требует указать причину отмены — это заполняется в карточке и попадает в отчёты.
Настройка справочника статусов
Статусы и группы настраиваются в разделе Администрирование → Справочники → Статусы заказов. Здесь можно создавать группы, добавлять внутрь них статусы и управлять их отображением.
- Создайте или отредактируйте группу: задайте название, тип (рабочая или финальная), поведение резерва.
- Добавьте в группу статусы: название, символьный код, цвет для наглядности в списке.
- Настройте порядок статусов и групп перетаскиванием — он определяет последовательность в выпадающем списке карточки.
- При необходимости ограничьте переходы и видимость статуса для отдельных групп операторов через права доступа.
Каждому статусу присваивается символьный код (например, assembling или delivering). Его лучше задать осмысленным и не менять после запуска — на код завязаны триггеры, интеграции и импорт.
Коды статусов в API и интеграциях
Во внешних системах заказ идентифицируется не по названию статуса, а по его символьному коду и коду группы. Это важно при интеграциях с сайтом, 1С, маркетплейсами и службами доставки: маппинг состояний строится именно на кодах.
Получить справочник статусов можно методом API GET /api/v5/reference/statuses, а группы — GET /api/v5/reference/status-groups. Смена статуса заказа выполняется передачей поля status с нужным кодом в методе редактирования заказа.
- Код статуса уникален в пределах аккаунта — по нему система понимает, в какую группу попадёт заказ.
- При интеграции с маркетплейсами внешние статусы (например, отгрузка Ozon) сопоставляются с внутренними кодами RetailCRM в настройках интеграции.
- Переименование статуса в интерфейсе не меняет его код — интеграции продолжают работать.
Статусы и автоматизация
Смена статуса — самое частое событие-триггер в RetailCRM. На нём строится большая часть автоматизации продаж и логистики.
- Триггеры запускаются по условию «статус изменился на …»: отправить SMS клиенту при переходе в «Доставка», создать задачу оператору в «Согласование», уведомить склад в «Комплектация».
- Автораспределение может назначать ответственного при попадании заказа в определённую группу.
- Отчёты и воронка продаж считают конверсию именно по группам — сколько заказов дошло от «Новый» до «Выполнен» и где отваливаются.
- Фильтры и сегменты позволяют собрать все заказы в конкретном статусе или группе для массовой обработки.
Поэтому статусную модель проектируют не как визуальный ярлык, а как каркас процесса: каждый переход должен что-то запускать или о чём-то сигнализировать. «Мёртвые» статусы, на которых ничего не происходит, стоит убирать.
Типичные ошибки и рекомендации
Чаще всего статусную модель ломают не технические сбои, а несогласованность с реальным процессом.
| Ошибка | Последствие | Как правильно |
|---|---|---|
| Статус в неверной группе | Неверный резерв и остатки | Проверять тип группы при создании статуса |
| Слишком много статусов | Операторы путаются, теряется скорость | 1–3 статуса на группу, понятные названия |
| Удаление старого статуса | Разрыв истории и интеграций | Скрывать, а не удалять |
| Нет причин отмены | Непонятно, почему теряются заказы | Разделить группы отмены по причинам |
Перед запуском полезно нарисовать реальный путь заказа на бумаге и только потом переносить его в справочник. Так статусы будут отражать процесс, а не наоборот.
Итог
Статус — это состояние заказа, группа — этап, задающий резерв, финальность и автоматизацию. Стандартных групп (Новый, Согласование, Комплектация, Доставка, Выполнен, Отменён) хватает большинству магазинов, но их важно донастроить под свой процесс: правильно распределить статусы по группам, задать осмысленные символьные коды и не плодить лишние состояния. От этого напрямую зависят корректность остатков, точность отчётов и работа триггеров.
Мы в B2Bsite выстраиваем статусную модель RetailCRM под конкретный бизнес — от аудита процессов и справочника статусов до триггеров, автораспределения и маппинга с сайтом и маркетплейсами. Если нужно навести порядок в воронке заказов или запустить систему с нуля — поможем сделать это без ошибок в учёте.
Частые вопросы
Чем статус отличается от группы статусов?
Статус — это конкретное состояние заказа, которое видит оператор. Группа — укрупнённый этап, к которому привязано поведение системы: резерв товара, признак финальности и автоматизация. Один статус всегда принадлежит одной группе.
Сколько статусов оптимально заводить?
По 1–3 статуса на группу. Избыток состояний запутывает операторов и замедляет обработку. Лучше держать модель компактной и понятной, отражающей реальные этапы работы.
Что происходит с резервом товара при смене статуса?
Пока заказ в рабочих группах, товар зарезервирован. При переходе в группу «Выполнен» товар списывается, а при переходе в группу отмены резерв освобождается и остаток возвращается в продажу.
Можно ли удалить ненужный статус?
Удалять статус, по которому уже проходили заказы, не рекомендуется — это разрывает историю и настроенные интеграции. Правильнее скрыть статус из работы, оставив его код в системе.
Где настраиваются статусы и группы?
В разделе Администрирование → Справочники → Статусы заказов. Там создаются группы, добавляются статусы, задаются цвета, порядок и символьные коды.
Как статусы связаны с интеграциями?
Внешние системы обращаются к статусам по символьным кодам, а не по названиям. При интеграции с сайтом, 1С или маркетплейсами внешние состояния сопоставляются с внутренними кодами RetailCRM.
Можно ли запускать автоматизацию по смене статуса?
Да, смена статуса — основное событие для триггеров. По нему отправляют уведомления клиентам, ставят задачи операторам, назначают ответственных и строят воронку продаж.
Зачем нужно несколько групп отмены?
Разделение отмен по причинам (отказ клиента, нет в наличии, дубль) даёт наглядную аналитику потерь. Так видно, на каком этапе и почему заказы не доходят до продажи.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.