Резерв товара в B2B нужен не для красивого статуса в личном кабинете. Он показывает, может ли поставщик выполнить обещанный заказ: удержать нужное количество, не продать его другому покупателю, собрать документы и отгрузить в срок без ручного тушения пожара после подтверждения.
На B2B-маркетплейсе резерв особенно важен, потому что покупатель принимает решение по карточке, сроку, цене и доступному остатку. Если площадка показывает товар как доступный, а менеджер через день сообщает, что партия уже ушла по другому заказу, проблема выглядит не как складская ошибка, а как нарушение доверия к поставщику.
Зачем поставщику отдельный процесс резерва
В B2B-продажах один и тот же остаток может одновременно видеть отдел продаж, интернет-витрина, маркетплейс, постоянный клиент, тендерная команда и склад. Каждый канал считает, что товар доступен именно ему. Если правил нет, побеждает тот, кто громче попросил или быстрее дошел до кладовщика. Для покупателя это выглядит как непредсказуемость поставщика.
Резерв нужен, чтобы отделить намерение от обязательства. Заявка без подтверждения может быть спросом. Подтвержденный заказ с согласованным сроком уже влияет на поставку, деньги и документы. Между этими состояниями должен быть понятный переход: кто проверяет наличие, кто ставит резерв, сколько он действует и при каких условиях снимается.
Гражданский кодекс РФ рассматривает поставку как передачу товаров для предпринимательской деятельности, а условия о товаре, количестве и сроке должны быть исполнимыми. Поэтому поставщику опасно обещать срок до того, как склад подтвердил, что нужная партия действительно может быть удержана и передана покупателю.
Начните с источника остатка
Резерв нельзя настроить надежно, если команда не доверяет данным об остатке. Складская система, учетная программа, файл менеджера и карточка на маркетплейсе часто обновляются с разной частотой. На бумаге доступно 120 единиц, в системе отгрузки уже собрано 80, а в карточке товара покупатель видит старое значение. Такой разрыв создает ложную доступность.
Определите главный источник остатка. Для одних компаний это WMS, для других учетная система, для небольших поставщиков — операционная таблица с регламентом обновления. Важно не название инструмента, а правило: именно этот источник решает, можно ли обещать товар. Все остальные каналы должны получать данные из него или иметь понятное ограничение по времени обновления.
Для маркетплейса проверьте, как остаток попадает в карточку и как быстро меняется после заказа. Если обновление идет раз в сутки, нельзя показывать редкую позицию как свободную до конца дня без буфера. Лучше оставить технический запас, чем собрать несколько заявок на одну и ту же партию.
Отдельно отметьте остатки, которые нельзя свободно обещать: товар на ответственном хранении, партия под гарантийный обмен, образцы для ключевых клиентов, позиции с неполным комплектом документов, товары в пути и продукция, которая уже собрана в заказ, но еще не отгружена. Такие категории должны уменьшать доступный остаток для продаж, даже если физически коробки лежат на складе.
Менеджер обещает товар по вчерашнему отчету и просит склад «как-нибудь придержать» нужное количество.
Обещание покупателю появляется только после проверки доступного остатка и фиксации срока резерва.
Задайте срок и основание резерва
Бессрочный резерв почти всегда ломает продажи. Товар зависает под покупателя, который еще не оплатил, не согласовал спецификацию или не подтвердил доставку. Другой клиент готов купить сейчас, но менеджер боится снять резерв, потому что нет правила. В итоге остаток есть физически, но им никто не управляет.
Срок резерва должен зависеть от стадии сделки. Для запроса цены достаточно короткого окна. Для согласованного счета срок может быть длиннее. Для предоплаты или подписанного договора резерв становится частью исполнения заказа. Если покупатель не выполнил следующее действие в срок, резерв снимается или продлевается только после решения ответственного.
Основание тоже важно. Резерв «по звонку» стоит отделять от резерва под счет, договор, спецификацию, оплату или подтвержденную заявку маркетплейса. Чем сильнее основание, тем выше приоритет. Так команда не будет спорить, почему пробный интерес одного покупателя блокирует реальный заказ другого.
В карточке заказа полезно хранить не только количество, но и дату постановки резерва, дату окончания, инициатора, основание и следующий шаг покупателя. Тогда любой сотрудник видит, почему товар удержан и что должно произойти дальше. Если следующего шага нет, резерв нельзя считать управляемым: он просто замораживает остаток.
Опишите приоритеты, а не решайте их вручную
Когда товара мало, ручные решения быстро становятся конфликтными. Постоянный клиент просит удержать партию до пятницы. Новый покупатель готов оплатить сегодня. Маркетплейс уже принял заявку. Тендерная команда просит не трогать остаток до решения комиссии. Если порядок не описан, каждый отдел защищает свою сделку.
Заранее задайте иерархию. Например: оплаченный заказ, подтвержденная поставка по договору, заявка с жестким сроком, счет в ожидании оплаты, коммерческое предложение без обязательства. Такая шкала не должна быть сложной. Она нужна, чтобы менеджер понимал, когда он может обещать товар, когда обязан согласовать исключение, а когда должен честно предложить альтернативу.
Для поставщика на маркетплейсе важно не скрывать риск от покупателя. Если остаток ограничен, а срок зависит от подтверждения склада, лучше показать это в условиях заказа и быстро дать статус. Тот же принцип работает при настройке минимальной партии на B2B-маркетплейсе: ограничение должно быть видно до того, как покупатель потратил время на заявку.
Не все покупатели требуют одинакового уровня защиты. Для стандартного расходного товара достаточно короткого резерва и быстрого подтверждения. Для дорогого оборудования, редкой партии или товара с длинной логистикой нужен более строгий контроль: кто согласовал удержание, какой срок поставки обещан, какая альтернатива есть при срыве и кто сообщает покупателю новый статус.
Свяжите резерв с документами
Резерв товара не живет отдельно от документов. Если счет, спецификация, УПД и заказ описывают разные партии или разные даты, склад может удержать физический товар, но сделка все равно зависнет. Федеральный закон «О бухгалтерском учете» требует оформлять факты хозяйственной жизни первичными учетными документами с обязательными реквизитами. Для поставщика это означает, что документы должны отражать реальную поставку, а не приблизительное обещание менеджера.
Проверьте три связки. Первая — резерв и счет: количество, цена, НДС, срок оплаты и срок действия предложения. Вторая — резерв и склад: партия, место хранения, упаковка, серийные номера или срок годности, если они важны. Третья — резерв и отгрузка: кто снимает товар с резерва, когда формируются документы и что происходит при частичной поставке.
Если резерв связан с предоплатой, особенно важно заранее определить момент перехода от ожидания денег к сборке заказа. Деньги могут поступить позже банковского дня, а склад уже закрыть отгрузочное окно. Поэтому в правилах должны быть не только «сколько держим товар», но и «до какого времени подтверждаем отгрузку сегодня». Это снижает споры вокруг срока, который был технически невозможен.
Если компания работает через ЭДО, электронные документы нужно готовить с учетом фактической партии. ФНС России указывает, что электронный счет-фактура является юридически значимым оригиналом, содержит реквизиты бумажного аналога, подписывается руководителем или доверенным лицом и выставляется в установленный срок. Поэтому резерв должен помогать документам совпасть с отгрузкой, а не создавать отдельную версию сделки.
Настройте резерв для маркетплейса отдельно
Маркетплейс добавляет еще один слой правил. Покупатель видит карточку, доступность, срок поставки и иногда автоматический статус заявки. Поставщик видит склад, внутренние приоритеты и фактическую готовность отгрузки. Если эти два вида не синхронизированы, конфликт проявится в самом неудобном месте: после того как покупатель уже выбрал товар и ждет подтверждения.
Для площадки стоит установить отдельный буфер доступности. Редкие позиции, товары с длинной поставкой, партии под конкретного клиента и остатки после крупной отгрузки лучше не отдавать в общий свободный остаток без проверки. Если платформа позволяет показывать срок подтверждения, используйте его честно. Если не позволяет, настройте внутреннее правило быстрого ответа по каждой заявке.
Также проверьте, кто отвечает за снятие резерва после отказа покупателя или истечения срока оплаты. На практике часть неликвидного «дефицита» появляется не из-за настоящего спроса, а из-за забытых резервов. Команда думает, что товар занят, хотя сделка давно не движется.
Отдельно проверьте товары с сезонным спросом и позиции, которые поставляются партиями от производителя. Для них простой статус «в наличии» часто не показывает реальную картину. Часть товара уже обещана постоянным клиентам, часть нужна для гарантийной замены, часть нельзя дробить из-за упаковки или минимальной отгрузки. Если такие ограничения не попадают в правила резерва, маркетплейс видит свободный остаток, а операционная команда вынуждена объяснять, почему он на самом деле недоступен.
Разберите исключения до первого дефицита
Даже хороший процесс резерва не отменяет исключения. Покупатель может задержать оплату по объективной причине. Склад может найти пересорт. Поставщик может получить срочный заказ от ключевого клиента. Вопрос не в том, чтобы запретить исключения, а в том, чтобы они не принимались в переписке без следа.
Опишите, кто имеет право продлить резерв, снять его досрочно, заменить партию, предложить частичную поставку или изменить срок. Для крупных заказов полезно фиксировать причину решения: ожидается оплата, покупатель согласовал замену, товар нужен под договорный срок, риск штрафа выше выгоды от новой продажи. Такая фиксация защищает команду от повторения одной и той же ошибки и помогает быстро объяснить решение покупателю, руководителю продаж и складу.
Если после резерва меняется состав заказа, используйте отдельный порядок согласования. Важно не смешивать обновление остатка и изменение обязательства перед покупателем. Подробно этот момент связан с процессом изменения заказа в B2B.
Полезно раз в неделю смотреть не только активные резервы, но и причины их снятия. Если покупатели часто не оплачивают счета, возможно, срок резерва слишком длинный или менеджеры ставят его до реального согласования. Если резервы срываются из-за склада, значит, источник остатка обновляется поздно. Если конфликт возникает между каналами продаж, нужна понятная шкала приоритетов. Такой разбор превращает резерв из ручной просьбы в управляемый показатель качества продаж.
Короткий чек-лист
- Определен главный источник остатка, которому доверяют продажи, склад и маркетплейс.
- Резерв ставится только после проверки доступного количества и срока отгрузки.
- Для каждой стадии сделки есть срок действия резерва и условие продления.
- Приоритеты описаны заранее: оплаченный заказ, договорное обязательство, счет, заявка, коммерческий интерес.
- Резерв связан со счетом, спецификацией, складской партией и документами на отгрузку.
- Для маркетплейса настроен буфер или быстрый ручной контроль ограниченного остатка.
- Забытые резервы регулярно снимаются, а исключения фиксируются с причиной и ответственным.
Частые вопросы
Можно ли резервировать товар без счета?
Можно, если это осознанный короткий резерв под проверку условий или согласование покупателя. Но такой резерв должен иметь срок действия и более низкий приоритет, чем оплаченный или договорный заказ.
Кто должен ставить резерв: менеджер или склад?
Менеджер может инициировать резерв, но подтверждать доступность должен источник остатка: складская система, учетная программа или ответственный сотрудник склада. Иначе продажа будет обещать то, что склад не проверил.
Что делать, если товара не хватило после подтверждения заказа?
Нужно быстро отделить учетную ошибку от фактического дефицита, предложить покупателю частичную поставку, замену или новый срок и письменно зафиксировать изменение. После этого стоит разобрать, почему резерв не защитил заказ.
Нужен ли отдельный резерв для маркетплейса?
Да, если площадка показывает остатки покупателям или автоматически принимает заявки. Для маркетплейса полезен буфер, быстрый контроль редких позиций и понятный срок подтверждения заказа.