Управление backorder: не терять заказ, когда товара нет на складе

Пятница, 16:40. Менеджер по продажам уже пообещал клиенту 40 штук с отгрузкой в понедельник. Кладовщик открывает карточку: на остатке 46, но 34 из них зарезервированы под заказы, подтверждённые ранее на этой неделе. Реально доступно — 12. На оставшиеся 28 штук нет ни заказа поставщику, ни даты, которую можно защитить. В тот вечер эти 28 штук не видны никому. Через две недели клиент отменяет заказ, и восстановить, откуда взялось обещание, уже невозможно.

Управление отложенным спросом (backorder) закрывает именно этот разрыв. Ниже разбираем, что меняется, когда неудовлетворённый спрос фиксируется, а не отклоняется; в какой момент заказ становится backorder; таблицу критериев, по которой стоит решать, брать обязательство или нет; правила, по которым называют дату; поля самой записи; порядок распределения товара при поступлении; особый случай маркетплейсов; влияние на денежный поток; показатели, за которыми следит закупщик; и способы снизить количество backorder по существу. В конце — частые вопросы.

Что меняется, когда неудовлетворённый спрос попадает в систему?

Фраза «сейчас нет на складе» заканчивает разговор. Backorder превращает ту же ситуацию в открытое обязательство: спрос не отклоняют, его фиксируют, и при поступлении товара заказ закрывается автоматически. Разница проявляется в данных раньше, чем в отношении клиента. Отклонённый спрос нигде не записан: через два месяца на вопрос «почему по этой позиции такие слабые продажи» у вас останутся только цифры отгрузок, а упущенный спрос не оставит следа.

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

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

В какой момент заказ становится backorder?

Большая часть ошибок растёт из одного смешения понятий: остаток на складе и доступный остаток — разные числа. На складе может быть 46 штук, из которых часть уже зарезервирована под подтверждённые заказы. В Rocketly это разделение живёт в разделе Движения товара: приход, расход, перемещение и резерв — отдельные типы движений, и ни одно из них не удаляется задним числом; исправление добавляется новым движением. Панель здоровья склада показывает доступный и зарезервированный остаток рядом, и спор «но система показывала, что есть» на этом заканчивается.

Порог backorder считается именно от доступного количества. Когда спрос его превышает, есть два пути: держать заказ открытым целиком или отгрузить частично. Частичная отгрузка — это отправить сегодня имеющиеся 12 штук и оставить открытую строку на 28. Логистика при этом дороже, но если клиенту не нужен комплект целиком, такой обмен обычно выгоднее.

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

Какой заказ стоит брать в backorder, а какой нет?

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

Критерий	Backorder оправдан	Backorder рискован
Срок поставки	Поставщик подтвердил дату, которую можно защитить	Импорт, таможня или очередь на производстве без срока
Заменяемость товара	Изделие под размер, привязка к бренду или проекту	Массовая позиция с пятью аналогами на рынке
История клиента	Постоянный контрагент с историей закупок	Первая покупка, контакты не подтверждены
Условия оплаты	Есть аванс или договор	Оплачено полностью вперёд, отмена бьёт по кассе
Срок потребности	Клиент назвал дату, и она позже вашей оценки	Товар нужен раньше, чем вы способны привезти

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

Что вы на самом деле обещаете, называя дату?

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

Второе правило: называйте интервал, а не день. «Отгрузка 17-20 марта» ближе к правде, чем «18 марта», и небольшой сдвиг в цепочке поставок не превращается в инцидент. Третье правило: если дата сдвинулась, звоните вы. Задержка, о которой клиент узнал сам, всегда выглядит крупнее той, о которой вы предупредили.

Такое предупреждение редко работает через один канал. Кто-то не открывает почту, кто-то не берёт трубку. Разговор в том канале, которым клиент действительно пользуется, для уведомлений о backorder важнее, чем где-либо ещё: пропущенное сообщение — самая частая причина отмены.

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

Какие поля должна нести запись backorder?

Backorder стоит хранить как структурированную запись, а не как комментарий. Минимальный набор:

• Товар и вариант, недопоставленное количество, дата заказа
• Обещанный клиенту интервал отгрузки и допущение, на котором он построен
• Связанный заказ поставщику или ожидаемая приёмка
• Приоритет: значимость клиента, дата потребности, наличие аванса
• Условие закрытия: после какой даты строка закрывается сама
• Последнее уведомление клиенту и автор этого уведомления

Функция Управление backorder в Rocketly хранит именно такую запись: неудовлетворённый спрос не удаляется, остаётся открытой строкой и закрывается автоматически при поступлении товара. Вопрос «пришёл ли товар и кому он предназначался» адресуется записи, а не чьей-то памяти. Когда поставщик двигает срок, в дело вступает Ревизия заказа: уже отправленный заказ поставщику можно пересмотреть, и каждая ревизия сохраняется с перечнем изменений — то есть вторую названную клиенту дату можно проследить до причины.

Не менее важна видимость записи внутри команды. Если непонятно, кто отвечает на письмо «что с моим заказом», запись не работает: сбор входящих на одном экране команды не даёт вопросам по backorder остаться без ответа.

Кто определяет очередь распределения при поступлении товара?

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

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

Для товаров со сроком годности распределение — ещё и вопрос партии. Функция Учёт партий и серийных номеров даёт прослеживаемость по партии и серийному номеру и списывает по принципу FEFO, поэтому ожидающий клиент получает партию, которая дольше всех лежала на складе.

Чем дольше задержка, тем чаще претензии уходят из личной переписки в публичные каналы. Управлять большой очередью backorder без процесса обработки открытых обращений — значит объяснять одну и ту же задержку дважды и в двух формулировках.

Как устроен backorder при продаже на маркетплейсах?

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

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

Чем больше каналов, тем острее вопрос единого источника — и это самый предметный довод в пользу того, чтобы собрать многоканальные заказы в одном месте: вы перестаёте вести три разных числа по одному SKU в трёх личных кабинетах.

Как backorder отражается на денежном потоке?

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

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

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

Какие показатели показывают, что backorder под контролем?

Считать только количество открытых строк — значит обманывать себя: в период акции оно и должно расти. Информативны четыре показателя:

• Доля выполнения с первого раза: сколько заказов отгружено вообще без ожидания
• Возраст backorder: средний и максимальный срок открытой строки в днях
• Доля сдержанных обещаний: заказы, отгруженные в первом названном интервале
• Отмены из-за ожидания: заказы, от которых отказались, не дождавшись

Разрез важен не меньше суммы. Если наверху списка регулярно один и тот же SKU, проблема в планировании, а не в поставке; если позиции чередуются, вероятнее дело в поставщиках. Раздел Эффективность поставщиков в Rocketly ставит рядом число заказов и поставок, суммарные расходы и средний срок доставки — вы измеряете, кто держит дату, а не угадываете.

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

Как снизить количество backorder всерьёз и надолго?

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

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

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

Если вы продаёте наборы, порог считается на уровне компонентов. Функция Комплекты и наборы вычисляет, сколько наборов сейчас можно собрать из остатков компонентов, и ситуация «набор был доступен, а одна деталь закончилась» ловится до продажи, а не после. Чтобы проверить эти сценарии на своём ассортименте, откройте бесплатный аккаунт Rocketly и пройдите по складским экранам на собственных данных.

Частые вопросы

Backorder и предзаказ — это одно и то же?

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

Брать ли предоплату по backorder?

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

Когда закрывать открытую строку backorder?

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

Отгружать частями или ждать полное количество?

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