Соответствие статусов — узел, от которого зависит вся синхронизация заказов. Если статусы сайта и RetailCRM не сведены, заказы зависают, клиенты получают неверные уведомления, а аналитика по воронке искажается. Разберём, как выстроить маппинг корректно и без циклов.
Как устроены статусы в RetailCRM
В RetailCRM статусы двухуровневые: есть группы статусов и внутри них конкретные статусы. Группы фиксированы по смыслу этапа воронки, а статусы внутри можно добавлять под свои процессы.
| Группа | Смысл этапа |
|---|---|
| Новый | Заказ поступил, ещё не обработан |
| Согласование | Менеджер уточняет детали |
| Комплектация | Сборка и подготовка к отгрузке |
| Доставка | Передан в доставку |
| Выполнен | Заказ завершён |
| Отменён | Отказ или невыкуп |
У сайта, как правило, статусов меньше и они плоские. Задача маппинга — связать ограниченный набор статусов витрины с более подробной статусной моделью CRM.
Принцип двустороннего маппинга
Обмен идёт в обе стороны, поэтому нужны две таблицы соответствия.
- Сайт → CRM — с каким статусом заказ создаётся в CRM и как изменение на витрине переносится в CRM.
- CRM → сайт — какой статус витрины выставить, когда менеджер меняет статус в CRM.
Направления не симметричны: у CRM статусов больше, поэтому несколько статусов CRM могут вести к одному статусу сайта. Обратно — один статус сайта разворачивается в один конкретный статус CRM.
Где настраивается соответствие
Место настройки зависит от способа интеграции.
- В модулях CMS (OpenCart, CS-Cart, WooCommerce и др.) есть отдельная вкладка сопоставления статусов внутри настроек модуля.
- При интеграции по API маппинг вы держите на своей стороне и подставляете нужный статус в
order[status]при вызове/orders/edit.
Сами статусы CRM редактируются в Администрирование → Статусы заказов. У каждого статуса есть символьный код — именно его использует API, а не человекочитаемое название.
Защита от циклов
Главная опасность двустороннего обмена — зацикливание. Изменение статуса в CRM летит на сайт, сайт трактует это как своё изменение и шлёт статус обратно в CRM, и так по кругу.
- Не замыкайте один и тот же статус сам на себя в обеих таблицах без проверки источника.
- Финальные статусы (Выполнен, Отменён) обычно делают конечными — дальше их не переопределяют.
Отмены и причины
Отдельного внимания требует группа «Отменён». В RetailCRM отмена часто сопровождается причиной отмены — отдельным справочником.
- Сопоставьте статусы отказа сайта с конкретными статусами группы «Отменён».
- Если сайт передаёт причину (нет в наличии, передумал, недозвон), сведите её со справочником причин CRM.
- Не сливайте все отказы в один статус — иначе потеряете аналитику по причинам невыкупа.
Аналогично разведите статусы оплаты: «оплачен онлайн» на сайте и оплата в CRM — это разные сущности, их не стоит подменять статусом заказа.
Проверка и типовые ошибки
| Симптом | Причина |
|---|---|
| Статус не уходит на сайт | Нет соответствия для этого статуса CRM |
| Статус скачет туда-обратно | Цикл: не проверяется источник изменения |
| Заказ создаётся не в том статусе | Неверный статус по умолчанию для новых заказов |
| Отмены сливаются в одну | Все отказы замаплены на один статус |
Проверяйте сквозным тестом: проведите заказ по всей цепочке в CRM и следите, как статусы отражаются на сайте, и наоборот.
Итог
Настройка соответствия статусов — это две несимметричные таблицы, аккуратно разведённые финальные состояния и обязательная защита от циклов. Отдельно проработайте отмены с их причинами и не путайте статус заказа со статусом оплаты. Правильный маппинг делает синхронизацию заказов предсказуемой, а воронку — достоверной.
Мы выстраиваем статусную модель RetailCRM и её соответствие статусам сайта под реальные процессы магазина, включая триггеры и автоматизацию на смену статуса.
Частые вопросы
Чем группа статусов отличается от статуса в RetailCRM?
Группа задаёт смысл этапа воронки (новый, комплектация, доставка, выполнен и т. д.) и фиксирована. Внутри группы вы создаёте конкретные статусы под свои процессы.
Почему нужны две таблицы соответствия?
Обмен двусторонний. Одна таблица описывает перенос статуса сайт → CRM, вторая — CRM → сайт. Направления несимметричны, потому что у CRM статусов обычно больше.
Что такое зацикливание статусов?
Это когда изменение статуса в CRM уходит на сайт, тот воспринимает его как своё и шлёт обратно в CRM. Корректная интеграция проверяет источник изменения и не гоняет статус по кругу.
Где брать код статуса для API?
В разделе «Администрирование → Статусы заказов». API работает с символьным кодом статуса, а не с его названием на русском.
Как правильно обрабатывать отмены?
Сопоставьте отказы сайта с конкретными статусами группы «Отменён» и, если сайт передаёт причину, свяжите её со справочником причин отмены. Не сливайте все отказы в один статус.
Можно ли несколько статусов CRM свести к одному на сайте?
Да. Поскольку у сайта статусов меньше, несколько статусов CRM обычно ведут к одному статусу витрины. Обратно один статус сайта разворачивается в один статус CRM.
Как проверить корректность маппинга?
Проведите тестовый заказ по всей цепочке статусов в CRM и на сайте, следя, что каждое изменение корректно отражается на другой стороне и не зацикливается.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.