Управление заказами: что это и как настроить
Как вести заказ на одной записи от приёма до доставки: жизненный цикл, резервирование остатков, частичные отгрузки, отмены, возвраты и ключевые метрики.
Четверг, вторая половина дня: двое сотрудников склада ищут один и тот же товар. Один собирает заказ из WhatsApp, второй — заказ, упавший с маркетплейса. Остатка на полке хватит только одному. В это же время менеджер по телефону говорит третьему покупателю: «Есть на складе, завтра отгрузим». Никто не нарушил правил. Не хватало одного — единой записи заказа, в которой видны все три обещания сразу.
Управление заказами закрывает именно этот разрыв: заказ ведётся на одной записи с момента появления до доставки и закрытия. Ниже разбираем, почему заказ — отдельная сущность, а не коммерческое предложение и не счёт, из каких этапов состоит его жизненный цикл, как работают частичные отгрузки и остаток к поставке, как свести заказы из всех каналов в один пул и в каком порядке всё это выстраивать.
Что такое управление заказами и почему это отдельная запись
Управление заказами — процесс, который начинается в момент согласия покупателя и заканчивается закрытием выполненного обязательства. Как запись заказ хранит: кто купил, из какого канала пришёл, какие товары и количества, на каких ценовых условиях, куда доставляем, какая дата обещана, на каком этапе находится сейчас и какая часть уже отгружена.
Многие команды такую запись не заводят: используют вместо неё коммерческое предложение или счёт. Оба варианта дают сбои. КП — это предложение: оно меняется, отклоняется, теряет срок действия. Счёт — бухгалтерский документ: после выставления его трудно менять, и появляется он обычно тогда, когда работа фактически закончена. Заказ живёт в подвижной зоне между ними. После согласования КП строки всё ещё можно отгрузить частично, одну позицию отменить, дату сдвинуть. Ни КП, ни счёт эту динамику не держат.
Практическое разделение простое: КП отвечает на вопрос «что мы предложили», счёт — «что мы выставили», заказ — «что мы должны клиенту прямо сейчас». Все три ответа могут различаться одновременно, и это нормально. Всю цепочку от предложения до денег на счёте мы разбираем в материале от КП до оплаты: процесс quote-to-cash; здесь фокус — на звене заказа в середине этой цепочки.
Жизненный цикл заказа: от принятия до закрытия
Здоровый процесс — это короткий список этапов, которые все называют одинаково. Не изобретайте двадцать статусов: семи хватает почти любому бизнесу.
Принят и подтверждён
«Принят» означает, что заявка попала в систему, но ещё не проверена. Подтверждение проверяет три вещи: верны ли товар и количество, действительны ли цена и условия оплаты, реалистичны ли адрес и дата доставки. В B2B добавляется проверка дебиторки — новый заказ клиенту, который уже вышел за лимит, просто переносит проблему на службу взыскания. Команды, пропускающие подтверждение, находят ошибку на складе или в пути, где исправление стоит в разы дороже.
Резерв, сборка, отгрузка, доставка
После подтверждения заказ начинает занимать место на складской стороне: строки резервируются. Дальше сборка и упаковка, затем отгрузка, доставка и, наконец, закрытие. Закрытие выглядит формальностью, но ею не является. Между «доставлен» и «закрыт» заказ может ещё находиться в окне возврата, иметь непокрытый остаток или оставаться без счёта. Там, где закрытие — отдельный этап, в конце месяца не спорят, завершена работа или нет.
Синхронность со складом: логика резервирования
Суть управления заказами — видеть разницу между «есть на остатке» и «доступно к продаже». На полке может лежать десять единиц, но если шесть обещаны другим заказам, продать можно четыре. Резерв делает именно это: подтверждённый заказ блокирует строки, физически не снимая товар.
Где такого разделения нет, разворачивается знакомая цепочка: одну единицу продают дважды, один заказ уезжает в просрочку, просрочку объясняют по телефону, доверие тает. Складскую дисциплину мы выстраиваем в материале об управлении складскими запасами. Со стороны заказа важны три правила: резерв на подтверждении, физическое списание на отгрузке, снятие резерва в день отмены.
Последнее правило забывают чаще всего. Отменённые заказы с неснятым резервом создают товар, который на бумаге продан, а на деле стоит в проходе. Для критичных позиций подключите пороги — как их настроить, показываем в материале про оповещения о запасах.
Частичная отгрузка и остаток к поставке
В жизни заказ редко уходит одной посылкой. Три позиции из пяти готовы, две в пути от поставщика. Остаются два плохих варианта: держать всё до прихода недостающего или отгрузить неполный комплект и пометить запись как выполненную. Оба вводят в заблуждение и клиента, и учёт.
Правильная схема — учёт по строкам. У каждой строки собственные количества: заказано, отгружено, осталось. Заказ закрывается только тогда, когда остаток обнулён или оставшаяся часть осознанно отменена. Каждая частичная отгрузка порождает свою накладную и при необходимости свой счёт, а запись заказа остаётся крышей, которая держит всё это вместе.
Если состояние заказа описывается одним словом, этот заказ, скорее всего, ещё не встречался с реальностью.
Статус оплаты и статус заказа — разные оси
Самая частая ошибка проектирования — свести оплату и исполнение в одно поле. «Оплачен» — не этап логистики, «отгружен» — не факт поступления денег. Слепив их в один список, вы перестаёте читать на одном экране клиентов по предоплате и клиентов с отсрочкой.
| Ось | Что описывает | Примеры значений |
|---|---|---|
| Статус заказа | Физический путь товара | Принят, подтверждён, в сборке, отгружен, доставлен |
| Статус оплаты | Состояние денег | Ожидает, частично оплачен, оплачен, возвращён |
| Закрытие | Состояние самой записи | Открыт, частичный, закрыт, отменён |
Разделив три оси, вы получаете самую рискованную группу — «доставлен, но не оплачен» — одним фильтром. Для B2B с отсрочкой платежа этот фильтр работает как система раннего предупреждения по денежному потоку.
Привяжите отмены и возвраты к заказу
Отмена — отзыв обязательства, которое ещё не отгружено; возврат — приход обратно того, что уже уехало. Это разные потоки с одним общим требованием: оба должны быть привязаны к исходной записи заказа. Возврат, висящий сам по себе, без ссылки на заказ, не поправит ни остатки, ни маржинальность.
Выстроенный возврат — ещё и шанс удержать клиента; как собрать этот поток, описываем в материале возврат товара и RMA. Со стороны заказа нужно всего два условия: возврат ссылается на заказ и конкретную строку, а подтверждение возврата одновременно обновляет остаток и взаиморасчёты.
Как свести заказы из всех каналов в один пул
Заказы больше не приходят в одну дверь. Они падают из панелей маркетплейсов, с вашего сайта, из WhatsApp, по телефону и с планшета торгового представителя в поле. Именно то, что каждый канал живёт в своём экране, и сталкивает людей на складе.
Логика объединения проста: канал должен быть полем, а не отдельной системой. Откуда бы заказ ни пришёл, он превращается в одну и ту же запись, использует один список статусов и резервирует из одного пула остатков — различается только значение «источник». Техническую сторону маркетплейсов разбираем в материале про интеграцию маркетплейсов, а подключение собственного магазина — в статье об интеграции e-commerce и CRM.
Дилерские и оптовые заказы — отдельный мир: цены зависят от контрагента, количества кратные, частота повторных заказов высокая. Тем, кто хочет вывести этот трафик из почты, пригодится материал про B2B-портал заказов для дилеров.
Корневые причины ошибок в заказах
Разберите проблемные заказы по одному — причины повторяются с удивительным постоянством:
- Дубли: один и тот же заказ собирают дважды, потому что он есть и в панели канала, и в ручной записи, а остаток списывается два раза.
- Пропущенное подтверждение: сборка стартует до проверки адреса или количества, и ошибка всплывает только при возврате посылки.
- Обещание без резерва: продажи говорят «есть», в системе ничего не блокируется, и единицу забирает тот, кто отгрузил первым.
- Незакрытые записи: доставленные заказы остаются открытыми, список раздувается, и реальная загрузка перестаёт быть видимой.
- Устные правки: клиент меняет позицию по телефону, запись не обновляют, склад собирает по старому списку.
У всех пяти один корень: нет единственного места, где фиксируется изменение. Причина лечится не новым слоем проверок, а соблюдением правила одной записи.
Что измерять: три базовые метрики
Операция по заказам управляется тремя числами. Первое — доля доставок в срок: сколько заказов пришло к обещанной дате. Второе — точность заказа: доля заказов, доехавших в полном составе, без пересорта и повреждений. Третье — время от заказа до отгрузки: среднее число часов от подтверждения до передачи перевозчику.
Читать эти три числа нужно только вместе. Кто гонится за скоростью, теряет точность; кто гонится за точностью, растягивает сроки. Считайте в разрезе канала, товарной группы и склада — среднее никогда не подскажет, где именно болит. Время меряйте в часах, а не в днях: дни прячут задержки, которые можно было отыграть в тот же день.
Пошаговая настройка
Если строите с нуля, важен порядок. Большинство команд ошибается, начиная с автоматизации.
- Опишите список статусов: назовите семь этапов и одной фразой задайте условие перехода к следующему.
- Зафиксируйте структуру записи: разделите шапку заказа, строки, канал, дату доставки, статус оплаты и закрытие.
- Приведите в порядок товар и остатки: при неверных вариантах, штрихкодах и единицах измерения резерв тоже будет неверным.
- Подключите каналы в один пул: начните с двух самых загруженных, остальные добавьте, когда поток устоится.
- Внедрите правила резерва и списания: резерв на подтверждении, списание на отгрузке, снятие резерва при отмене.
- Автоматизируйте отгрузку: свяжитесь со службой доставки, чтобы трек-номер попадал в запись без ручного ввода.
- Подключите уведомления: смена статуса должна уходить покупателю автоматически.
- Соберите отчёт и читайте его еженедельно: выведите три метрики на дашборд и раз в неделю просматривайте открытые заказы и остатки к поставке.
Детали шестого шага мы разбираем в материале про интеграцию служб доставки, а сценарий уведомлений из седьмого шага — в статье про автоуведомления о статусе заказа.
Реалистичный старт для небольшой команды
Всё сразу внедрять не нужно. Правило одной записи, учёт по строкам и разделение оплаты и исполнения — эти три вещи сами по себе убирают большую часть ошибок. Остальное добавляется по мере роста объёмов.
В Rocketly запись заказа лежит рядом с товарами, складом, взаиморасчётами и счетами, поэтому резервы, частичные отгрузки и контроль оплат не расползаются по разным системам; смену статусов можно повесить на автоматизацию бизнес-процессов и там же собрать уведомления и задачи. Чтобы начать вести заказы на одной записи, заведите аккаунт в Rocketly и подключите первый канал.