Ошибки комплектации на маркетплейсах: сколько на самом деле стоит недовложение и как перенести контроль на ТСД
Парадокс маркетплейсов заключается в том, что чем больше у вас заказывают, тем дороже обходится каждая ошибка. Например, если в день вы отправляете 50–100 посылок, то пересорт или недовложение кажутся досадной мелочью. Ну да, придётся извиниться перед клиентом и оформить возврат. Так ведь ничего страшного.
Но как только поток переваливает за 300–500 заказов, склад начинает генерировать ошибки с пугающей регулярностью. И тогда каждая пересортица влияет не только на логистику, но и на алгоритмы ранжирования WB и Ozon, которые снижают количество показов карточки покупателям.
При работе по схеме FBO (Fulfillment by Operator) маркетплейс хранит товар магазина-продавца и собирает заказы со своего склада. То есть за комплектацию отвечает площадка. При FBS (Fulfillment by Seller) продавец хранит товар у себя и сам комплектует заказы. И если на FBO ошибка — это проблема маркетплейса, то на FBS цена ложится напрямую на показатели магазина.
Такие «невидимые» на первый взгляд убытки являются триггером для падения органического трафика. И многие селлеры пытаются решить эту проблему административно: проводят инструктажи, штрафуют кладовщиков, нанимают дополнительных контролёров. Но всё это лишь борьба с симптомами.
Сборку заказов вручную нельзя масштабировать без увеличения штата, когда ассортимент и оборачиваемость растут. Так и что же делать? Первым делом нужно разобраться в причинах и только после этого искать решение.
Почему ручной учёт не масштабируется
На старте процессы кажутся прозрачными: кладовщик берёт бумажный лист или смотрит в планшет, идёт в ячейку, берёт товар, кладёт в коробку. Но с ростом ассортимента и оборачиваемости эта схема разваливается по нескольким фронтам.
И проблема даже не в невнимательности сотрудников. Проблема в том, что ручная обработка не успевает за сложностью операций.
Ошибки возникают, когда:
- Товар выбирают визуально
Появляются SKU, отличающиеся только размером или оттенком. И достаточно часто вместо одного товара в заказа попадает другой — именно из-за схожести внешних признаков. - Данные дублируются и путаются
Если продавец работает на WB и Ozon одновременно, названия и артикулы в личных кабинетах часто не совпадают, и кладовщик путается в номенклатуре. - Наборы собирают «по памяти»
Сборные наборы из 5–10 позиций — это гарантированное недовложение, особенно если сборщик отвлёкся или в наборе закончился один из компонентов, а он этого не заметил. - Маркировку пропускают или делают формально
Для товаров, подлежащих маркировке, мало отсканировать штрихкод — нужно валидировать конкретный DataMatrix. Вручную это сделать нереально, и кладовщики часто «закрывают глаза» на этот шаг, чтобы выполнить план по отгрузке. - Сотрудник переключается между системами
Кладовщик вынужден разрываться между ПК с таблицей, сканером, коробками и принтером этикеток, теряя контекст задачи.
В итоге склад работает с отклонениями. Контроль качества смещается на этап упаковки или, что хуже, на этап получения товара покупателем.
Экономика ошибок
Когда ошибка уже случилась и товар уехал к покупателю, начинается цепочка последствий, которая бьёт по всем метрикам магазина. Маркетплейсы не смотрят на причины, по которым вы отправили не тот товар — они фиксируют факт и применяют санкции.
Сначала идут прямые убытки: вы платите за логистику товара к покупателю, за его возврат на СВХ (склад временного хранения) и обратную логистику. Плюс товар часто возвращается в повреждённой упаковке. Но это только верхушка айсберга.
Падает индекс качества магазина на Ozon и WB, снижается рейтинг продавца и карточки товара. Алгоритмы видят высокий процент возвратов по причине «брак/пересорт/недовложение» и снижают карточку в поиске. И вы теряете органический трафик. А уж если при продаже маркированного товара передали не тот DataMatrix или вообще не передали код в Честный ЗНАК — ждите штрафов от ГИС МТ и блокировки карточки со стороны маркетплейса.
На потоке в 1000 заказов в день даже 1% ошибок — это 10 возвратов ежедневно. В месяц это 300 единиц товара, которые просто сжирают всю вашу маржу. Согласитесь, звучит совсем не радужно!
Как перестроить процесс
Пытаться решить проблему пересорта за счёт «повышения внимательности» кладовщиков — заведомо провальный путь. На складе внимательность — ресурс исчерпаемый, особенно к концу смены. Лучшим решением здесь будет встроить жёсткий технологический контроль в сам процесс сборки, который физически не даст ошибке уйти дальше.
Правильный сценарий работы с FBS-заказами выглядит иначе:
- Заказы со всех маркетплейсов агрегируются в единую очередь в учётной системе.
- Кладовщик получает задание на ТСД, и система сама строит оптимальный маршрут по складу.
- Включается жёсткое сканирование — кладовщик не может перейти к следующей позиции, пока не отсканирует штрихкод текущей. Если SKU не совпадает, ТСД блокирует операцию.
- При сборке наборов система раскладывает набор на спецификацию: «2 шт. артикул А, 1 шт. артикул Б».
- Для товаров с ЧЗ система требует отсканировать именно DataMatrix, связывая конкретный экземпляр с конкретным заказом.
- Этикетка маркетплейса печатается только после успешного прохождения всех шагов.
При такой организации работы — когда с персонала снимается операционная нагрузка и необходимость что-то контролировать — ошибка физически не может уйти со склада. Кладовщик просто не сможет закрыть заказ, если в коробке лежит не тот товар.
Подобная схема сборки реализована в мобильном приложении «Маркетплейс 15» для ТСД. Решение заточено именно под e-commerce и FBS, чтобы селлерам и фулфилментам не пришлось писать такие интеграции с нуля или мириться с ограничениями базовых WMS.
Операционка меняется сразу по нескольким направлениям:
- Единое окно для склада
Кладовщик не переключается между вкладками WB, Ozon и Яндекс.Маркета. Вся очередь задач, статусы и приоритеты отображаются на экране терминала.
- Защита от недовложений
При сборке наборов интерфейс ТСД показывает их состав. Сборщик физически не сможет нажать «Готово», пока не отсканирует каждый компонент из спецификации. - Бесшовная работа с ЧЗ
Интеграция с Честным ЗНАКом уже вшита в процесс. Сканирование DataMatrix-кодов происходит во время комплектации. - Адресное хранение
Система знает, где лежит товар. Если ячейка пуста, ТСД подскажет альтернативную зону хранения, чтобы кладовщик не бегал по складу впустую.
Вместо заключения
Ошибки комплектации на FBS выливаются в итоге в складские издержки, которые сложно просто списать на операционные расходы. Потому что они влияют на все метрики магазина: от индекса качества до видимости карточек в поиске. И чем выше поток заказов, тем дороже обходится каждая пересортица и недовложение.
При этом ни увеличение штата, ни дополнительные инструктажи, ни даже штрафы не решают проблему. При таком подходе человеческий фактор на складе никуда не денется — особенно на пике сезона, когда нагрузка вырастает в разы, а сотрудники работают на пределе. И компания продолжит «лечить симптомы».
Единственный способ разорвать этот круг — перенести контроль из головы кладовщика на терминал сбора данных. Когда каждая операция подтверждается сканированием, а система физически не даёт закрыть заказ с ошибкой, процент пересорта падает до статистической погрешности.
Автоматизация на базе решений вроде «Маркетплейс 15» как раз и заточены под то, чтобы дать селлерам и фулфилментам такую схему без необходимости писать интеграции с нуля или переделывать всю складскую логику. Внедрение ТСД окупается за счёт снижения возвратов и роста метрик магазина — обычно это видно уже в первый месяц работы.