Статусы заказов в Битрикс: как согласовать понятный порядок обработки

Назовите факт, который подтверждает каждый статус

Заказ отмечен «В работе», но никто не знает, проверил ли менеджер наличие и можно ли складу начинать сборку. Название состояния само по себе не организует обработку. Статусы заказов Битрикс полезны, когда команда связывает каждый переход с подтверждённым действием, ответственным и следующим шагом.

Начните с фактического пути заказа. Кто видит его первым, что уточняет, когда склад получает поручение, как фиксируется выдача или передача перевозчику? Не копируйте длинный список стадий из чужого магазина. У компании с товарами под заказ и у магазина с самовывозом могут быть разные условия, даже если внешне карточки похожи.

Для каждого состояния закончите фразу: «Мы ставим этот статус, когда…». Если окончание звучит как «менеджер занимается заказом», уточните, что уже произошло. Например, подтверждены состав и условия, либо товар собран и ожидает передачи. Состояние должно помогать следующему участнику действовать без устного выяснения контекста.

Не пытайтесь отразить одним статусом всё одновременно. Заказ может ожидать отгрузку, быть частично оплаченным и содержать товар, который поступит позже. Если каждое сочетание превращать в отдельное название, список быстро станет непригодным. Платёжные и складские факты нужно различать до настройки интерфейса.

Разделите заказ, оплату и отгрузку

В официальном курсе 1С-Битрикс статусы разделены на типы для заказа и доставки; также описаны специальные начальные и финальные состояния. Поэтому изменение списка требует учёта штатных правил установленной версии. Нельзя считать, что любое название можно удалить или переиспользовать без последствий.

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

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

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

Составьте таблицу переходов до настройки магазина

В таблице зафиксируйте исходное состояние, условие перехода, исполнителя и результат. Названия ниже приведены как учебный пример, а не обязательный набор Битрикс. Их требуется сопоставить со штатными состояниями и особенностями вашей версии. Цвет статуса можно выбрать позже: он не заменяет смысл.

Добавьте, что видит клиент при переходе: запись в кабинете, письмо, сообщение менеджера или отсутствие отдельного уведомления. Внутренний статус может иметь более подробное название, чем сообщение покупателю. Клиенту полезно понимать, что происходит и нужно ли от него действие, а не устройство вашей смены.

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

Назначьте ответственного за переход и ожидание

У каждого состояния должен быть исполнитель следующего действия. Если заказ ждёт подтверждения, понятно, какой менеджер его проверяет. Если он комплектуется, видно, кто отвечает за складскую работу. Само перемещение карточки между состояниями не гарантирует передачу ответственности, если сотрудники не видят уведомления или используют разные рабочие списки.

Согласуйте, кто имеет право менять существенные признаки и как это проверяется под обычной учётной записью. Администратор может выполнить действие, недоступное менеджеру, поэтому демонстрация только с полными правами недостаточна. В официальной документации предусмотрено управление доступом в связи со статусами; конкретный набор прав исполнитель проверяет на установленной версии.

Определите допустимое ожидание для каждого этапа по режиму компании. Это внутреннее условие, а не универсальный норматив. Заказ с ожидаемым поступлением товара может ждать дольше заказа с товаром на складе, но у ожидания должна быть причина и дата следующей проверки. Без них статус становится местом, где карточки пропадают из внимания.

В небольшой команде менеджер может выполнять несколько ролей. Всё равно полезно отделить подтверждение условий от факта сборки: в разные моменты нужны разные сведения. При передаче смены новый сотрудник должен понять положение заказа по записи, а не восстанавливать разговоры за предыдущий день.

Опишите отсутствие товара, изменение состава и отмену

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

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

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

Условный пример: клиент убрал один товар после начала комплектации. Менеджер фиксирует новый состав, склад подтверждает изменение поручения, затем проверяются сумма и доставка. Переход дальше разрешается после согласованных подтверждений. Если система не поддерживает нужное ограничение штатно, исполнитель оценивает доработку или понятный ручной контроль; наличие нужного ограничения нельзя предполагать.

Проверьте, какие сообщения запускаются при смене статуса

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

Покупателю обычно нужны номер заказа, понятное состояние, действие с его стороны и способ связи. Не используйте внутренние сокращения склада без объяснения. Если условия ещё уточняются, не обещайте конкретное время выдачи. Если заказ передан перевозчику, сообщайте именно это, не подменяя передачу подтверждением доставки.

Повторный переход может вызвать повторное сообщение в зависимости от настройки. Испытайте исправление ошибочного статуса и возврат на предыдущий этап. Клиент не должен получать противоречивую цепочку «готов — не готов — выполнен», пока сотрудник разбирается в интерфейсе. При необходимости согласуйте, какие переходы не запускают внешние уведомления.

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

Принимайте настройку на разных учебных заказах

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

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

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

Проверку обмена статусами с учётной системой оформите отдельным набором. Внутренний цикл может работать, а внешнее обновление — приходить с задержкой или менять значение. Разбор таких проблем есть в материале об ошибках обмена 1С и Битрикс. Само оформление заказа дополнительно проверяется по сценарию покупки без регистрации, если он используется.

Сохраните короткий регламент обработки

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

Перед изменением действующего списка определите судьбу открытых заказов. Как старые значения соответствуют новым, какие карточки требуют ручной проверки, что увидит покупатель? Не переименовывайте состояние так, чтобы исторические записи получили другой смысл. Исполнитель должен показать план переноса и проверку результатов на копии или согласованной выборке.

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

Для настройки порядка работы магазина подготовьте путь обычного заказа и несколько проблемных примеров без персональных данных. Этого достаточно, чтобы обсудить настройку статусов заказа Битрикс, разграничить штатные возможности и доработки и принять результат по реальным действиям менеджера и склада.