Статусы заказа и воронка выполнения на 1С-Битрикс

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

Эта статья — практическое руководство по жизненному циклу заказа: чем отличаются три оси (статус заказа, оплаты и отгрузки), как настроить свои статусы и их порядок, как автоматизировать переходы по событию оплаты, как раздать права, синхронизировать статусы с 1С и построить аналитику воронки выполнения. Материал основан на нашей практике разработки интернет-магазинов на 1С-Битрикс и интеграции с 1С — по делу, без обещаний «настроим воронку за час».

Зачем магазину продуманные статусы заказа

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

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

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

Три оси: статус заказа, оплаты и отгрузки

Главная концептуальная развилка, на которой спотыкаются многие магазины, — попытка описать заказ одним-единственным статусом. На деле у заказа в 1С-Битрикс есть три независимые оси, каждая отвечает на свой вопрос, и путать их нельзя.

Ось 1. Статус заказа — этап жизненного цикла

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

Ось 2. Статус оплаты — деньги

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

Ось 3. Статус отгрузки — логистика

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

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

Как устроены статусы в модуле «Интернет-магазин»

В 1С-Битрикс статусы живут в модуле «Интернет-магазин» и собраны из понятных частей. Разобравшись в них, вы будете настраивать осознанно, а не «по инструкции наугад».

• Список статусов заказа. Настраиваемый справочник значений оси цикла: у каждого статуса есть код, название, порядок сортировки и описание. Этот список вы редактируете под свой процесс.
• Флаги оплаты и отгрузки. Оси денег и логистики хранятся отдельно — как признаки оплаченности заказа и отгружённости его отгрузок, а не как значения в списке статусов.
• События заказа. При смене статуса, оплаты или отгрузки модуль генерирует события, на которые можно повесить обработчики — код, запускающий уведомления и переходы.
• Права на статусы. Для групп пользователей задаётся, кто какие статусы видит и на какие может переводить заказ.
• Связь с заказом и обменом. Текущий статус, оплата и отгрузка сохраняются в заказе и участвуют в обмене с 1С — уходят в учётную систему и приходят обратно.

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

Настройка своих статусов и их порядок

Штатный набор статусов в Битриксе минимален — по сути «принят» и «выполнен». Для реального магазина этого мало, поэтому список статусов расширяют под свой процесс. Делают это осознанно, по нескольким правилам.

Правило «один статус — один этап работы»

Каждый статус должен соответствовать этапу, на котором с заказом происходит что-то конкретное и понятно, чей ход. Если два статуса приводят к одинаковым действиям менеджера и системы, их объединяют. Статус существует не «для красоты», а чтобы за ним стоял набор действий и уведомлений.

Порядок и коды

• Порядок сортировки. Статусы выстраивают в логике движения заказа: сначала ранние этапы, потом поздние. От порядка зависит, как статусы показываются в списках и как читается воронка.
• Коды статусов. У каждого статуса свой код — по нему на статус ссылаются обработчики, бизнес-процессы и обмен с 1С. Коды задают осмысленно и не меняют потом «на ходу», иначе поедет автоматика.
• Финальные статусы. Отдельно помечают завершающие статусы («выполнен», «отменён») — после них заказ обычно не двигается дальше, и по ним считается результат воронки.

Практический совет: проектируйте статусы на бумаге в виде схемы «этап → что делает менеджер → что делает система → какое уведомление», и только потом заводите их в админке. Так вы сразу увидите лишние статусы (без действий) и недостающие переходы. Короткая понятная схема из 5–7 статусов почти всегда лучше дробной из двух десятков.

1. Опишите реальные этапы. Пройдите путь заказа от оформления до выдачи и выпишите этапы, на которых меняется ответственный или набор действий.
2. Отсеките дубли. Объедините этапы, которые приводят к одинаковым действиям и уведомлениям, — им не нужен отдельный статус.
3. Задайте порядок и коды. Выстройте статусы по движению заказа, присвойте осмысленные коды и пометьте финальные.
4. Привяжите действия. К каждому статусу определите, какое уведомление и какая задача запускаются при входе в него.
5. Разграничьте ручное и авто. Отметьте, какие переходы делает система сама, а какие требуют решения человека.

Типовой жизненный цикл заказа

Хотя каждый магазин уникален, есть типовой скелет жизненного цикла, от которого удобно отталкиваться. Для розничного интернет-магазина он выглядит так: новый → подтверждён → в сборке → передан в доставку → доставлен → выполнен, с ответвлениями «отменён» и «возврат». Разберём каждый этап.

• Новый. Заказ только оформлен. Ждёт подтверждения: проверки наличия, связи с покупателем при необходимости, прихода оплаты. Это входная точка воронки.
• Подтверждён. Наличие есть, данные корректны, оплата пришла или согласована. Заказ готов уйти в работу склада.
• В сборке. Склад комплектует заказ, резервирует и упаковывает товар. Здесь чаще всего образуется затор в пиковые дни.
• Передан в доставку. Заказ собран, отгружен со склада и передан курьеру или в службу доставки; присвоен трек-номер.
• Доставлен. Заказ довезён до покупателя или до пункта выдачи и вручён. Осталось закрыть заказ.
• Выполнен. Финал: заказ получен, оплата закрыта, претензий нет. Заказ уходит в историю и в статистику продаж.

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

Отменённые заказы и возвраты

Не все заказы доходят до «выполнен» — часть отменяется или возвращается. Эти ветки жизненного цикла проектируют так же аккуратно, как основной поток, иначе аналитика воронки перекосится, а деньги «повиснут».

• Отмена до отгрузки. Покупатель передумал, товара не оказалось, не прошла оплата. Заказ переводят в «отменён», снимают резерв со склада и, если была предоплата, инициируют возврат денег.
• Причина отмены. Полезно фиксировать, почему заказ отменён (нет в наличии, отказ покупателя, дубль, не дозвонились). По причинам потом видно, что чинить в процессе.
• Возврат после доставки. Товар доставлен, но покупатель вернул его. Это отдельный статус «возврат» со своей процедурой: приёмка товара обратно, возврат денег, оприходование на склад.
• Отделяйте отмену от возврата. Отмена — заказ не состоялся; возврат — состоялся, но развернулся обратно. Для воронки и финансов это разные события, и мешать их в один статус нельзя.
• Возврат денег — отдельная ось. Признак возврата средств живёт на оси оплаты. Статус заказа «отменён» и факт возврата денег связаны, но это разные вещи: заказ может быть отменён, а деньги ещё не вернули.

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

Статус оплаты: ось денег

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

• Не оплачен. Заказ создан, деньги не поступили. Для онлайн-оплаты это исходное состояние до подтверждения от платёжной системы.
• Оплачен. Платёжная система подтвердила оплату (или бухгалтерия отметила приход по безналу). Именно смена этого флага — самый частый триггер автоматического перехода статуса заказа.
• Частичная оплата. Для сценариев с предоплатой или несколькими платежами часть суммы получена. Это учитывают на уровне платежей заказа.
• Возврат средств. Деньги вернули покупателю полностью или частично. Признак возврата на оси оплаты связан со статусом «отменён» или «возврат» на оси цикла.

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

Статус отгрузки: ось логистики

Третья ось — отгрузка — описывает движение товара со склада. В Битриксе заказ может содержать одну или несколько отгрузок, и у каждой свои признаки. Эту ось двигает склад.

• Разрешена отгрузка. Признак, что заказ можно собирать и отгружать: наличие подтверждено, оплата или её условие выполнены. Это «зелёный свет» для склада.
• Отгружен. Товар физически ушёл со склада — собран, упакован, передан курьеру или в службу доставки. Смена этого флага — второй по важности триггер после оплаты.
• Несколько отгрузок. Крупный заказ может уезжать частями: что-то есть в наличии сейчас, что-то — под заказ. Тогда у заказа несколько отгрузок с разными статусами.
• Связь со складом и 1С. Отгрузка опирается на реальные остатки и резервы. Если учёт ведётся в 1С, признак отгрузки часто приходит именно оттуда — по факту сборки на складе.

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

Автоматизация переходов: событие оплаты → статус

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

Самый частый и полезный автопереход — по событию оплаты. Логика такая:

1. Платёжная система подтверждает оплату. Приходит уведомление, заказ помечается оплаченным на оси денег.
2. Срабатывает событие смены оплаты. Модуль «Интернет-магазин» генерирует событие «заказ оплачен», на которое повешен обработчик или робот.
3. Автоматика меняет статус заказа. Заказ переводится из «новый» в «подтверждён» (или сразу в «в сборке») на оси цикла.
4. Запускаются уведомления и задачи. Покупателю уходит письмо «заказ подтверждён», складу ставится задача на сборку, печатаются документы.
5. Менеджер видит результат. В админке заказ уже в правильном статусе — без ручного клика. Менеджер занимается только исключениями.

По той же схеме автоматизируют и другие переходы: отгрузка со склада → статус «передан в доставку» и письмо с трек-номером; отметка доставки службой → статус «доставлен»; закрытие заказа → «выполнен» и просьба оставить отзыв. Принцип один: смена флага на одной оси автоматически двигает статус на оси цикла и запускает коммуникацию. Ручным оставляют только то, где нужно человеческое решение, — например, подтверждение проблемного заказа или согласование в B2B.

Бизнес-процессы, обработчики и роботы

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

Обработчики событий (код)

Классический путь: на события заказа (смена статуса, оплаты, отгрузки) вешают обработчики на PHP. Это максимально гибко — можно реализовать любую логику, обратиться к внешним системам, проверить сложные условия. Минус — нужен разработчик, и логика живёт в коде, а не «на виду» у менеджера.

Бизнес-процессы

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

Роботы и триггеры

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

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

Уведомления клиенту на статусах

Статусы ценны не только внутри магазина — они превращаются в коммуникацию с покупателем. Уведомление на смене статуса снимает поток вопросов «а что с заказом» и повышает доверие. Но здесь легко переборщить.

• Уведомляйте на значимых этапах. «Заказ принят», «оплачен», «передан в доставку» с трек-номером, «доставлен» — это события, которые покупателю действительно важны. Промежуточные («в сборке») чаще не требуют письма.
• Один канал — один смысл. Не дублируйте одно и то же письмом, SMS и мессенджером одновременно. Выберите канал под важность события: критичное — SMS, подробное — e-mail.
• Понятный текст. Пишите на языке покупателя, а не в терминах статусов Битрикса. «Ваш заказ собран и передан курьеру» лучше, чем «статус изменён на shipped».
• Полезные данные. В уведомление кладут то, что нужно для действия: трек-номер, код получения из постамата, адрес и часы работы пункта выдачи, срок хранения.

Технически уведомления запускаются от смены статуса — тем же обработчиком, роботом или бизнес-процессом, что двигает заказ. Каналы (e-mail, SMS, мессенджеры) подключают отдельно; как это настроить и не завалить покупателя спамом, мы разбираем в материале про интеграцию SMS и мессенджеров в 1С-Битрикс. Там же — про выбор канала под тип события и про шаблоны сообщений.

Уведомления менеджеру и внутренние сигналы

Вторая половина коммуникации на статусах — внутренняя. Смена статуса должна не только информировать покупателя, но и запускать работу команды. Иначе автоматизация «наполовину»: заказ перешёл в статус, а никто об этом не узнал.

• Задача складу на сборку. Как только заказ подтверждён и оплачен, складу автоматически ставится задача собрать его — без пересылки заказов вручную.
• Сигнал о новом заказе. Менеджеру приходит уведомление о заказе, который требует его внимания: не прошла оплата, нужен звонок, нестандартный состав.
• Эскалация по времени. Если заказ висит в статусе дольше норматива, сигнал уходит руководителю — это уже про SLA, к которому вернёмся ниже.
• Ответственный за заказ. Полезно на каждом статусе понимать, чей это ход. Автоматика может назначать ответственного при входе в статус.

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

Права: кто может менять статус

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

• Права по группам пользователей. В Битриксе доступ к заказам и статусам настраивается для групп: одни только просматривают, другие двигают заказ по этапам, третьи имеют право отменять и закрывать.
• Ограничение переходов. Помимо прав «кто», задают правила «куда»: заказ нельзя перевести из «нового» сразу в «выполнен», минуя сборку и доставку. Допустимые переходы описывают бизнес-процессом или обработчиком.
• Ответственные и видимость. Менеджер видит и правит свои заказы, руководитель — все. Это и про безопасность, и про то, чтобы каждый работал в своей зоне.
• Автопереходы вместо ручных. Чем больше очевидных переходов делает система сама, тем меньше кнопок у менеджера и меньше поводов для ошибки. Ручное действие оставляют там, где нужно решение.

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

Синхронизация статусов с 1С: кто хозяин

Если магазин обменивается заказами с 1С, статусы начинают жить в двух системах сразу — и здесь возникает самый частый источник боли. Заказ меняет статус и на сайте, и в 1С, а при обмене значения перезаписывают друг друга. Чтобы статус не «прыгал», до настройки обмена решают главный вопрос: кто хозяин статуса.

Хозяин статуса — это система, чьё значение считается истинным и перезаписывает другое при обмене. Вариантов два, и выбор зависит от того, где реально ведётся работа по заказу.

• Хозяин — 1С. Если сборка, оплата и отгрузка учитываются в 1С, логично сделать её источником истины по статусу выполнения. Сайт тогда — витрина: он показывает покупателю статус, пришедший из 1С, но сам его не меняет по этой оси.
• Хозяин — сайт. Если заказами занимаются менеджеры прямо в админке Битрикса, статус ведут на сайте, а в 1С уходит уже готовое значение. 1С тогда получает статус, но не переопределяет его.
• Маппинг статусов. Наборы статусов на сайте и в 1С почти никогда не совпадают один в один. Поэтому составляют таблицу соответствия: какой статус сайта какому статусу/состоянию в 1С отвечает. Без маппинга обмен «не понимает» статусы.
• Правила по осям. Хозяина определяют для каждой оси отдельно. Часто оплату и отгрузку ведёт 1С (там учёт), а этап цикла — сайт (там работают менеджеры) или наоборот. Главное — зафиксировать это явно.

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

Статусы для B2B и согласование

Розничная воронка «оформил → оплатил → получил» коротка и линейна. У оптового и B2B-заказа появляется дополнительный слой — согласование, — и жизненный цикл удлиняется. Просто добавить B2B-заказы в розничную схему статусов не выйдет: они застрянут между этапами.

• Этап согласования. Между «новым» и «в сборке» у B2B-заказа появляется статус «на согласовании»: подтверждение цен и условий, проверка лимита и дебиторки, утверждение со стороны закупщика клиента. Пока согласование не пройдено, заказ не уходит в сборку.
• Оплата по счёту. B2B часто платит не онлайн, а по безналу с отсрочкой. Появляются статусы «выставлен счёт» и «ожидает оплаты по счёту», отличные от розничного «оплачен онлайн».
• Роли и видимость. Менеджер видит внутренние этапы, а клиент в личном кабинете — только релевантные ему («на согласовании», «счёт выставлен», «в доставке»). Одни и те же статусы показывают по-разному разным ролям.
• Многошаговое утверждение. В крупных закупках согласование идёт в несколько рук — со стороны и магазина, и клиента. Это удобно вести бизнес-процессом с последовательными шагами утверждения.

Важно, чтобы B2B-ветка не ломала розничную: обычно это отдельные статусы и правила переходов, которые применяются к оптовым заказам, но не мешают быстрой рознице. Сам сценарий согласования — кто утверждает, какие проверки проходит заказ, как это выглядит в личном кабинете клиента — мы подробно разбираем в материале про согласование заказов на B2B-портале. Там же показано, как встроить согласование в жизненный цикл, не превращая воронку в лабиринт.

Аналитика воронки выполнения

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

Что смотрят в воронке выполнения:

• Распределение по статусам. Сколько заказов сейчас в каждом статусе. Даже простой отчёт «количество заказов по статусам» показывает, где скапливается очередь.
• Конверсия между этапами. Какая доля заказов доходит от «нового» до «выполнен» и где отваливается больше всего. Резкий провал на этапе — сигнал о проблеме.
• Доля отмен и возвратов. Сколько заказов уходит в «отменён» и «возврат» и по каким причинам. Это прямая метрика качества процесса.
• Динамика во времени. Как меняется картина по дням и неделям — например, растёт ли очередь в сборке в пиковые дни распродаж.

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

Время в статусе и застревание заказов

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

1. Фиксируйте переходы с временем. Каждую смену статуса записывают с датой и временем. Это даёт основу для расчёта длительности нахождения в статусе.
2. Считайте время в каждом статусе. По меткам переходов вычисляют, сколько заказ провёл в «новый», «в сборке», «в доставке». Среднее и максимальное время — ключевые показатели.
3. Ищите узкие места. Статус, где растёт среднее время и копится много заказов, — это затор. Например, очередь в «в сборке» означает, что склад не успевает.
4. Разбирайте застревания. Заказы, висящие в статусе аномально долго, выносят в отдельный список для разбора — они чаще всего и есть будущие жалобы.
5. Улучшайте процесс. По найденным узким местам меняют процесс: усиливают склад в пики, автоматизируют переход после оплаты, добавляют людей на подтверждение.

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

SLA обработки заказов

Финальный слой зрелой статусной модели — SLA, внутренние нормативы времени на этапы. SLA превращает воронку из отчёта, который смотрят раз в неделю, в живой инструмент, который сам сигналит о проблемах в реальном времени.

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

SLA логично вводить, когда базовая воронка уже выстроена: есть внятные статусы, фиксируется время в них, работает аналитика застреваний. Тогда нормативы ложатся на готовую основу, а не повисают в воздухе. Начинать же стоит с простого — с честных статусов и автоматических переходов; SLA и эскалации нарастают сверху по мере роста потока заказов.

Отладка и тестирование статусной модели

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

• Полный путь заказа. Проведите тестовый заказ от «нового» до «выполнен» и убедитесь, что все переходы срабатывают и статусы меняются в правильном порядке.
• Автопереход после оплаты. Оплатите тестовый заказ и проверьте, что он сам перешёл в нужный статус и ушли уведомления, — без ручного клика менеджера.
• Отмена и возврат. Прогоните ветки «отменён» и «возврат»: снимается ли резерв, запускается ли возврат денег, корректно ли считается в воронке.
• Права доступа. Проверьте под разными ролями, что менеджер не может «перепрыгнуть» этапы или закрыть заказ, если это ему не положено.
• Обмен с 1С. Смените статус на сайте и в 1С, проведите обмен и убедитесь, что хозяин статуса перезаписывает значение по правилам, а маппинг верный.
• Уведомления. Проверьте, что на каждом значимом статусе уходит правильное сообщение в правильный канал и не дублируется.
• Края. Заказ без оплаты, заказ из нескольких отгрузок, B2B-заказ с согласованием — крайние случаи чаще всего вскрывают пробелы в переходах.

Особое внимание — стыку с обменом 1С и правам доступа: именно там всплывают «прыгающие» статусы и несанкционированные переходы, которые в обычном тесте одного заказа не видны. Прогоните сценарии с несколькими ролями и полным циклом обмена, прежде чем открывать модель для всех менеджеров.

Частые ошибки при настройке статусов

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

• Слишком много статусов. Два десятка дробных статусов выглядят солидно, но на деле заказы залипают в промежуточных этапах, менеджеры путаются, а воронка нечитаема. Оставьте 5–7 статусов с реальными действиями за каждым.
• Смешение трёх осей. Попытка описать заказ одной шкалой и завести «оплачен»/«отгружен» в списке статусов заказа приводит к путанице и рассинхрону. Держите оси цикла, оплаты и отгрузки раздельно.
• Ручные переходы вместо авто. Если статус после оплаты меняет менеджер вручную, заказы будут висеть в «новый», пока он не заметит. Очевидные переходы автоматизируют по событиям.
• Рассинхрон с 1С. Не решён вопрос хозяина статуса — и значение «прыгает» на каждом обмене, а менеджеры не знают, какому верить. Договоритесь о хозяине по каждой оси и сделайте маппинг.
• Статусы без действий. Статус, за которым не стоит ни уведомления, ни задачи, ни решения, — «мёртвый»: он только засоряет воронку. Каждый статус должен что-то запускать.
• Нет ограничений переходов. Если заказ можно перевести из любого статуса в любой, воронка теряет смысл, а аналитика врёт. Опишите допустимые переходы.
• Спам уведомлениями. Письмо и SMS на каждый чих раздражают покупателя и обесценивают важные сообщения. Уведомляйте только на значимых этапах и выбирайте канал под важность.
• Отмена и возврат в одном статусе. Смешение «заказ не состоялся» и «состоялся, но развернулся обратно» ломает и финансы, и аналитику. Разведите их на отдельные статусы с причинами.
• Меняют коды статусов «на ходу». Переименование кода уже работающего статуса ломает обработчики, роботы и обмен, которые на него ссылаются. Коды задают заранее и не трогают.
• Логика размазана по всем механизмам. Один и тот же переход частично в коде, частично в бизнес-процессе, частично в роботе — и разобраться, почему сменился статус, невозможно. Договоритесь, что где живёт.

Чек-лист статусной модели

Короткий список, по которому удобно свериться перед запуском статусной модели и воронки выполнения:

1. Три оси разведены: статус заказа, оплаты и отгрузки не смешаны в одну шкалу.
2. Список статусов заказа описан под реальные этапы, 5–7 значений, у каждого — действие за ним.
3. Порядок и коды статусов заданы осмысленно; финальные статусы помечены.
4. Жизненный цикл нарисован: новый → подтверждён → в сборке → в доставке → доставлен → выполнен, плюс отменён и возврат.
5. Автопереходы настроены: событие оплаты и отгрузки двигают статус без ручного клика.
6. Механизмы автоматизации распределены: роботы, бизнес-процессы, обработчики — понятно, что где живёт.
7. Уведомления покупателю заданы на значимых статусах, каналы выбраны под важность, без спама.
8. Внутренние сигналы: задачи складу и менеджеру запускаются от смены статуса.
9. Права розданы: кто видит и двигает статусы; критичные переходы — за старшими ролями.
10. Хозяин статуса определён по каждой оси, составлен маппинг статусов сайта и 1С.
11. B2B-ветка с согласованием заведена отдельно и не ломает розничную воронку.
12. Аналитика и SLA: фиксируется время в статусе, видно застревания, заданы нормативы обработки.

Вывод

Статусы заказа в 1С-Битрикс — это не подпись в карточке, а каркас всей операционной работы магазина. Начинается он с ключевой развязки на три оси: статус заказа описывает этап цикла, статус оплаты — деньги, статус отгрузки — логистику, и смешивать их нельзя. На этом каркасе строится понятный жизненный цикл — от «нового» до «выполнен», с явными ветками отмены и возврата, — а очевидные переходы автоматизируются по событиям оплаты и отгрузки через роботов, бизнес-процессы и обработчики.

Главное помнить: статус существует только там, где за ним стоит действие, а перечень статусов должен быть коротким и читаемым. Автоматизируйте рутинные переходы, оставляя ручными решения человека; раздайте права, чтобы воронка не превращалась в хаос; заранее договоритесь, кто хозяин статуса при обмене с 1С, чтобы значение не «прыгало». Тогда статусная модель даст главное — честную аналитику воронки выполнения: вы увидите, где застревают заказы, сколько времени они проводят на каждом этапе, и сможете задать SLA. Смежные темы разбираем в статьях про интеграцию магазина с 1С и согласование заказов на B2B-портале, а также в рубрике «Оплата и доставка».