Мы в МПФИТ делали модуль «Единый сток» и наивно думали, что задача звучит просто: есть поставщик, есть один или несколько магазинов, значит надо синхронизировать остаток и жить спокойно.
На практике спокойствия не наступает. Селлер ведет продажи на нескольких витринах, у поставщика свой склад, иногда есть партнеры по дропшиппингу, плюс FBS, где ошибка на последнем шаге превращается в отмену, штраф или плохую метрику продавца. А еще есть наборы, комплекты и прочие умные конструкции, которые выглядят безобидно в карточке, но подрывают учёт, если неправильно связать.
Что селлер обычно называет «единым стоком»
В разговоре единый сток звучит как пусть везде показывается одно число. Но в реальности это не число, а система правил:
Есть физический остаток у поставщика (или на вашем складе).
Есть несколько каналов продажи: разные магазины, разные площадки, иногда партнеры.
Есть логика продаж, которая не всегда одинаковая. FBS особенно строгая.
Есть риск oversell: продали больше, чем реально есть.
Есть риск противоположный: заморозили продажи, хотя товар есть, просто “не дошел остаток”.
Селлеры обычно приходят к единому остатку по двум причинам.
Первая причина: растет объем. До 30-50 заказов в день можно жить на внимательности. Когда в пике становится 100-300 заказов в день (а у неко��орых и больше), ручные корректировки начинают стоить слишком дорого.
Вторая причина: появляется распределение между каналами. Акции, разные цены, разные витрины, партнерские продажи. Без дисциплины один канал быстро начинает “высасывать” остаток.
Мы заложили в модуль две роли, даже если вы в голове просто селлер на Ozon, WB и т.д..
→ Поставщик: тот, кто держит физический остаток, его учет и пополнения.
→ Дропшиппер: тот, кто продает этот остаток через свою витрину (включая вашу же витрину, если вы продаете со склада поставщика).
Это позволяет говорить на одном языке: кто источник правды, кто потребитель остатка, кто должен делать ручные действия и где нужно ограничение.
Первая набитая шишка. Сопоставление SKU оказалось важнее синхронизации
Если вам нужно запомнить один тезис из статьи, пусть будет этот: единый остаток не начинается с остатков. Он начинается со связок.
Мы видели десятки сценариев, где люди начинали тюнить синхронизацию, увеличивали частоту обновления, добавляли ручные проверки, ругались на “реалтайм”, а проблема была в том, что карточки товаров сопоставлены неверно.
У нас в модуле предусмотрено три способа связки карточек:
Автоматическая связка
Она хороша, когда у поставщика и селлера совпадают идентификаторы или совпадает структура карточек, а отличия минимальны.Связка через Excel
Это основной рабочий способ, когда артикулы отличаются, варианты разъезжаются, а карточки на маркетплейсе не отражают структуру поставщика один к одному.Ручная связка
Ок для маленького ассортимента или для “досвязки хвоста”, когда Excel уже сделал основную работу.
Ключевой момент: в Excel-связке у нас две колонки, которые решают все: код товара поставщика и код товара дропшиппера. Дальше можно строить любые удобства, но если эти две штуки заполняются без дисциплины, единый сток превращается в генератор сюрпризов.
Пример из жизни про связки SKU
Один селлер продавал одежду на Wildberries. У поставщика размеры жили в одной карточке и отличались вариациями, а у селлера часть вариантов была разведена по разным SKU, причем артикулы различались сильнее, чем хотелось бы.
Автосвязка дала красивую картину: “все сопоставилось”. Через пар�� дней начались странности. На витрине размер “M” показывался как доступный, а на сборке выяснялось, что реальный остаток лежит в “L”. В системе все выглядело правдоподобно, потому что ошибка была не в остатках, а в том, что два разных варианта стали “одним товаром”.
Мы остановили запуск и перевели связки в Excel, но самое важное было не “перейти в Excel”, а добавить валидации.
Внедрили правило №1 → Перед включением остатков валидируем связки
Мы используем три проверки, которые спасают больше, чем любые частые обновления.
Проверка на дубликаты
Один и тот же код поставщика не должен маппиться на два разных кода дропшиппера. Если это случилось, вы получите «двойное списание» или «внезапный ноль».Проверка на варианты
Если товар имеет варианты (размер, цвет), маппинг должен учитывать конкретный вариант. Иначе вы будете продавать «усредненный товар», которого не существует.Проверка на изменения
Если вы обновили связки, это событие не должно бесконтрольно переписывать уже пришедшие заказы. Я вернусь к этому в FBS части, потому что там это особенно критично.
В среднем по рынку, когда селлер включает единый сток “на авось”, мы видим порядка 1–3% ошибочных связок на первых итерациях по ассортименту 500–2000 SKU. Кажется мелочью, но это тысячи рублей потерь и десятки отмен в месяц, потому что ошибка концентрируется на ходовых позициях.
Шишка вторая. Общий остаток без лимитов превращается в конфликт каналов
Вторая шишка обычно появляется у селлеров, которые уже выросли и продают через несколько витрин Ozon / Wildberries, либо подключили партнеров по дропшиппингу.
Сценарий простой: у вас есть общий остаток, и один канал внезапно начинает продавать активнее. Это может быть акция, изменение цены, удачная реклама, или просто сезон. Этот канал съедает весь доступный остаток, остальные каналы уходят в ноль и ловят отмены или нет в наличии.
Люди часто говорят: «Ну и хорошо, пусть продает тот, кто лучше продает». На практике это ломает бизнес-логику.
На разных витринах могут быть разные маржинальности.
У вас могут быть договоренности с партнерами.
У вас может быть приоритет: свои магазины важнее партнеров.
У вас может быть стратегия: держать остаток на одном канале для стабильности рейтинга.
Поэтому мы добавили настройку ограничение остатков на дропшиппера. В терминах селлера это звучит как квота или лимит на канал.
История клиента про лимиты
Селлер в косметике держал остаток у поставщика и продавал через два собственных магазина, плюс дал доступ двум партнерам. Один партнер включил агрессивную рекламу и за день “съел” весь доступный остаток по 20 топовым позициям.
С точки зрения партнера все ок: он продал. С точки зрения селлера начался пожар: свои магазины ушли в ноль, отмены посыпались на наиболее видимых карточках, рейтинг начал проседать.
Мы ввели лимиты на каждого партнера и договорились о политике: у партнеров фиксированная квота, у собственных магазинов больше лимит и право “добора”. Эффект был не в том, что продажи выросли, а в том, что продажи стали управляемыми.
Придумали правило №2 → Лимиты ставим до старта, а не после первых отмен
Если вы включаете единый сток на несколько витрин и не поставили лимиты, вы не управляете распределением. Вы просто наблюдаете, кто победит.
Вот типовая настройка для старта, если нет сложных приоритетов:
собственный основной магазин: 60% доступного остатка
второй собственный магазин: 20%
партнеры: по 10% каждый, или фиксированное число
Дальше вы калибруете на данных. За 2–4 недели обычно видно, где лимиты слишком жесткие (упущенная продажа), а где слишком мягкие (канал забирает все).
По опыту пилотов у селлеров, которые включают лимиты сразу, доля отмен из-за отсутствия товара после заказа может снижаться примерно в 2–3 раза. Если стартовали с 2.5–3% отмен по причине “нет товара”, можно прийти к 0.8–1.2% за счет дисциплины связок и лимитов. Это не чудо, это банальная управляемость.
И третья шишка. FBS и неприятная правда про «автоматику»
Вот эта шишка на десерт и она самая болезненная, потому что она обычно приходит не в спокойный день, а в пик, когда каждая минута важна.
Есть два FBS сценария, которые регулярно вызывают вопросы и раздражение.
Сценарий 1. Заказ пришел, когда остатка у поставщика не было
Селлер ожидает, что после пополнения все само подтянется: появился товар, значит заказ можно автоматически забронировать.
Мы сознательно не делаем автоматическую бронь в таком кейсе. Почему?
Потому что между заказ пришел при нуле и остаток пополнился может измениться контекст:
связки могли поменяться
поставщик мог привезти не тот вариант
часть остатка могла быть распределена лимитами на другие каналы
могли появиться параллельные заказы, которые должны занять этот остаток первыми
Автоматическая бронь в такой ситуации выглядит удобной, но на практике повышает риск oversell в других каналах. Лучше неприятная ручная проверка, чем красивый автомат, который делает дорогую ошибку.
Сценарий 2. Связки поменялись после того, как заказ уже пришел
Тут логика похожая. Если у вас пришел заказ, и вы вдруг перепривязали карточки, нельзя позволять системе задним числом переписать “что именно заказали”. Это прямой путь к тому, что вы соберете не то, отправите не туда, а потом будете искать, где исчезла единица товара.
Поэтому изменение связок не применяется автоматически к уже поступившим заказам. Это кажется неудобством, но это барьер от хаоса.
История одного нашего клиента про FBS
Селлер по электронике получил FBS заказ в момент, когда у поставщика был ноль. Через час поставщик принял поставку, остаток появился, и команда ожидала, что заказ автоматически подхватится.
Этого не произошло, и первое ощущение было будто система сломалась. Мы разобрали цепочку и оставили правило: после пополнения нельзя автоматически забронировать то, что пришло при нуле, без ручной проверки.
Дальше мы дали простой runbook оператору: где обновить остаток, где проверить связки, когда вручную подтвердить бронь и когда лучше отдать приоритет другому заказу.
Результат: да, добавился ручной шаг. Но количество “странных” ошибок в пике снизилось заметно. В цифрах это обычно выглядит так: вместо 15–25 минут суммарной паники и перепроверок на серию заказов, вы тратите 2–5 минут на точечную проверку и не ловите цепные ошибки.
Так родилось правило №3 → Для FBS обязателен короткий runbook, без него единый сток становится нервным
Вот минимальный runbook, который мы рекомендуем селлеру, который собирается подключатся к нашей WMS МПФИТ:
Если заказ пришел при нуле, не ждите автоподхвата.
После пополнения обновите остатки дропшиппера.
Проверьте связки по SKU в заказе, особенно если недавно что-то меняли в сопоставлении.
Проверьте лимиты на канал, чтобы не забрать остаток у более приоритетной витрины.
Только после этого подтверждайте сборку.
Это звучит как “лишняя бюрократия”, но на практике снижает вероятность дорогих ошибок.
Наборы и smart товары: почему мы связываем компоненты, а не набор целиком
Если вы продаете наборы (комплекты), то почти всегда наступает момент, когда хочется сделать простую связку: вот набор на витрине, вот набор у поставщика, давайте соединим.
Проблема в том, что набор как товар на витрине часто не равен тому, что реально лежит на складе. На складе лежат компоненты. Один набор может иметь вариативность, компоненты могут пересекаться между наборами, и остаток набора вычисляется из остатков компонентов.
Поэтому в едином стоке мы связываем штучные компоненты, а не набор целиком. После обновления связок создается внутренний заказ на сборку набора. Это делает поведение предсказуемым: вы видите, что именно должно быть собрано, и откуда это берется.
Селлеру это важно по простой причине - наборы часто продаются как красивая маркетинговая упаковка, и отмены по наборам особенно бьют по рейтингу, потому что это обычно товары с высокой ценой и высокой заметностью.
Чеклист запуска единого стока для селлера
Я специально делаю чеклист коротким, чтобы он работал, а не пугал.
Приведите ассортимент к нормальной структуре
Варианты, размеры, цвета должны быть описаны стабильно. Не идеально, но стабильно.Выберите стратегию связок
Если ассортимент больше 200 SKU, почти всегда нужна Excel-связка как база.Введите валидации связок
Это про дубликаты, варианты, контроль изменений.Настройте лимиты на каналы
Хотя бы грубо, чтобы избежать конфликта витрин.Опишите FBS runbook для двух edge cases
Заказ при нуле, изменение связок после заказа.Отдельно проверьте наборы
Связываются компоненты, а не набор как единица.Прогоните тестовый пик
Пусть это будет 20–30 заказов в симуляции, но с реальными вариантами и разными каналами.Включайте поэтапно
Сначала топ-50 SKU, потом топ-200, потом весь хвост. На хвосте ошибок больше, но цена ошибки ниже.
Подытожу
Единый сток для селлера на маркетплейсах выглядит как миссия синхронизировать остатки. Реальность ближе к инженерной задаче: сопоставление SKU, контроль распределения, защита от опасной автоматики, особенно на FBS.
Если у вас похожий сценарий, несколько витрин, дропшиппинг, FBS, наборы, можно начать с чеклиста из этого поста. Если нужно, могу подсказать, какие валидации и тесты лучше всего ловят ошибки до запуска. Контакты в профиле.
Роман Камушкен, аналитик из МПФИТ
