Собственная доставка селлера как резервный канал: когда схема окупается

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

Привет, я Антон Фокин — CEO Qtim. Предлагаю начать с другого вопроса: для какого сегмента заказов резервный маршрут способен выдержать и экономику, и обещание покупателю? Собственная доставка здесь не требует обязательного автопарка. В модели DBS (Delivery by Seller, «доставка силами продавца») продавец может отвечать за заказ сам или привлекать подрядчика. Он берёт на себя управление операцией от сборки до возврата.

Вопрос «когда схема окупается» получает ответ только после такого сравнения на проверенном сегменте. Универсального порога по числу заказов или радиусу доставки нет.

Рынок даёт этому вопросу вес. По оценке Data, в 2025 году российский e-commerce доставил 7,7 млрд посылок, на 24,9% больше, чем годом ранее. АКИТ оценивает объём интернет-торговли за тот же год в 11,5 трлн ₽. Эти цифры говорят о масштабе последней мили. Они не отвечают, выгоден ли дополнительный контур конкретному продавцу.

Считать нужно стоимость успешного заказа

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

Для пилота соберите такую модель:

Полная стоимость успешной резервной доставки =

(сборка + упаковка + диспетчеризация + маршрут/подрядчик + поддержка + неуспешные попытки + возвраты + доля постоянных затрат) ÷ число вручённых заказов.

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

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

DBS добавляет продавцу не только контроль

В официальной инструкции Wildberries для модели «Витрина» продавец хранит товар, обрабатывает заказ, упаковывает и доставляет его. Возврат в зависимости от сценария тоже может идти силами продавца. Это описание одной площадки, а не универсальное правило рынка. Оно хорошо показывает состав ответственности, который нельзя потерять в сравнительной таблице.

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

Резервный канал проверяют в сценарии с чёткой функцией. Для пилота подходят три варианта.

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

В расчёте нужно увидеть потери между складом и поддержкой

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

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

Доставка последней мили влияет на потребительский опыт не только скоростью. В обзоре литературы НИУ ВШЭ Кравченко выделяет её как значимый сервисный аспект e-commerce. Работа не устанавливает норму SLA и не доказывает эффект конкретной схемы. Она напоминает о границе расчёта: экономику нельзя отделить от того, как покупатель получает заказ и решает вопрос с возвратом.

В этот момент становится видно, нужна ли отдельная интеграция. Заказы, остатки, складские операции, статусы курьера и возвраты требуют согласованных данных. Мы проектируем e-commerce-контуры и интеграции с WMS, доставкой и API маркетплейсов.

Границы пилота: сегмент, окно доставки и исключения

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

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

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

Решение о масштабе принимают по двум условиям

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

Первый: резервная доставка выдержала полную стоимость успешного заказа на выбранном сегменте?

Второй: команда стабильно исполнила обещание по статусу, сроку и возврату?

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

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

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