Отгрузка и логистика FBO и FBS: как автоматизировать процесс без ручных сбоев

Автоматизация отгрузки и логистики FBO и FBS - это про то, чтобы заказ с маркетплейса проходил путь от "принят в работу" до "уехал на склад площадки или к покупателю" без ручных передач на честном слове и напоминаний в чате. Прямой ответ на вопрос, как автоматизировать этот путь: не одним волшебным сервисом, а связкой из трёх вещей - синхронизация данных между складом и кабинетами Wildberries, Ozon и Я.Маркета, жёсткая последовательность шагов сборки и упаковки, которую нельзя пройти наполовину, и видимость узких мест до того, как они превратились в штраф или отмену заказа.

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

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

Чем автоматизация FBS отличается от автоматизации FBO

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

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

На практике у растущего продавца обе схемы работают параллельно: часть товара едет на склад маркетплейса (FBO), часть собирается под заказ у себя (FBS). Значит и автоматизировать нужно оба маршрута, а не только тот, что сейчас болит больше.

Где чаще всего рвётся маршрут заказа

Модельный список точек, где ручное управление обычно даёт сбой:

1. Заказ пришёл в кабинет площадки, но сборщик узнал об этом с опозданием - никто не увидел уведомление вовремя.
2. Пересорт при сборке - взяли не тот артикул или не тот размер, потому что сверяли по памяти, а не по чек-листу с фото.
3. Упаковка не соответствует требованиям конкретного маркетплейса (материал, пломба, вложение) - это либо штраф, либо возврат уже на этапе приёмки.
4. Этикетка распечатана заранее и не совпадает с итоговым составом заказа после частичной отмены позиции.
5. Заказ собран и упакован, но физически не передан курьеру или в пункт приёма до конца окна - просрочка по FBS.
6. Для FBO - поставка сформирована без сверки с лимитом приёмки склада или без пересчёта остатков, из-за чего часть коробов не принимают или принимают с расхождением.

Ни одна из этих точек не решается напоминанием в чате "не забудьте проверить". Она решается тем, что шаг физически нельзя закрыть, пока не выполнено условие внутри него.

Регламент теряется в переписке? В Legend BMS шаг физически нельзя пропустить. Посмотреть →

Как выстроить процесс сборки и отгрузки FBS без пропущенных шагов

Рабочая последовательность для FBS выглядит так: заказ поступил - сборка - контрольная сверка - упаковка - маркировка - передача в доставку. Каждый шаг имеет своего исполнителя, срок и обязательное подтверждение - например, фото собранного заказа перед упаковкой или скан этикетки перед передачей курьеру.

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

Отдельная точка контроля - частичные отмены и объединение заказов в одну отгрузку. Здесь особенно легко ошибиться вручную: состав заказа изменился, а собранная упаковка и распечатанная этикетка - нет. Автоматическая синхронизация статуса заказа с шагом сборки закрывает именно этот разрыв.

Планирование поставок FBO без интуиции

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

Автоматизация здесь строится на связке остатков на складе, темпов продаж по каждому артикулу и лимитов приёмки конкретного склада маркетплейса на конкретную дату. Формирование поставки, генерация коробов и печать этикеток становятся задачей внутри процесса, а не отдельным ручным действием, которое кто-то может сделать в последний момент и ошибиться в количестве.

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

Контроль сроков и штрафов, которые автоматизация снимает первыми

Штраф за просрочку отгрузки FBS или за отказ в приёмке FBO - это реальные деньги, которые компания платит площадке, а не абстрактная "потеря времени". Именно поэтому контроль сроков - первое, что стоит автоматизировать: система должна сама показывать, какой заказ приближается к дедлайну сборки, а не ждать, пока об этом напомнит штраф в личном кабинете.

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

Что видно руководителю, когда весь путь оцифрован

Когда сборка, упаковка и отгрузка идут через процесс, а не через чат и память сотрудников, руководителю не нужно спрашивать "как там с отгрузками сегодня" - он видит это сам: сколько заказов в очереди, на каком шаге застряла конкретная позиция и у кого, сколько по факту занимает сборка одного заказа против нормативного времени.

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

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