Как управлять ассортиментом на нескольких маркетплейсах: WB, Ozon, Яндекс Маркет и 1С в одной логике

Когда селлер продаёт на одном маркетплейсе и у него 20-30 SKU, ассортимент ещё можно контролировать вручную. Таблица с остатками, выгрузка заказов, несколько формул, ручная сверка цен - всё это кажется терпимым.

Но как только площадок становится несколько, ручная логика быстро ломается.

Один и тот же товар продаётся на Wildberries, Ozon и Яндекс Маркете. На каждой площадке свои комиссии, тарифы, рекламные инструменты, акции, остатки, склады, возвраты, сроки выплат, требования к карточкам и отчёты. Себестоимость лежит в 1С, заказы приходят из разных кабинетов, остатки обновляются не одновременно, акции идут по разным условиям, а собственник хочет понять простую вещь:

Какие товары действительно зарабатывают, где их нужно пополнять, а где лучше остановиться?

Проблема в том, что один SKU на разных маркетплейсах может вести себя совершенно по-разному.

На WB он может давать большой оборот, но низкую маржу.На Ozon - продаваться медленнее, но приносить больше прибыли.На Яндекс Маркете - иметь небольшие продажи, но стабильный спрос и низкие возвраты.В 1С - числиться как один товар с одной себестоимостью, но в реальности на каждой площадке у него разная экономика.

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

Разберём, как выстроить такую систему для WB, Ozon, Яндекс Маркета и 1С, какие данные нужно объединять, как не запутаться в SKU, как контролировать остатки и почему мультиплощадочное управление ассортиментом невозможно без единого учёта.

Почему один товар на разных маркетплейсах - это не один и тот же бизнес-результат

Формально товар один и тот же: одинаковый артикул, себестоимость, упаковка, поставщик, характеристики.

Но на каждой площадке у него своя экономика.

Различаются:

• комиссия маркетплейса;
• логистика;
• хранение;
• схема продаж;
• стоимость возврата;
• рекламные инструменты;
• скидки и акции;
• требования к карточке;
• конкуренты;
• аудитория;
• скорость продаж;
• выкуп;
• возвратность;
• сроки выплат;
• доступность по складам;
• региональная логистика;
• условия продвижения.

Поэтому нельзя смотреть на товар только в целом.

Например:

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

Главная ошибка селлера: управлять площадками отдельно

Частая ситуация: у бизнеса есть отдельная таблица по WB, отдельная по Ozon, отдельная по Яндекс Маркету, отдельно 1С, отдельно рекламные кабинеты, отдельно отчёты по выплатам.

На каждой площадке вроде бы всё понятно. Но управленческая картина не складывается.

Что происходит:

• один и тот же товар имеет разные названия;
• артикулы не совпадают;
• себестоимость не подтягивается автоматически;
• остатки не синхронизированы;
• товары заканчиваются на одной площадке и лежат на другой;
• рекламные расходы не связаны с прибылью;
• возвраты не учитываются в решениях по пополнению;
• выплаты сверяются отдельно;
• акции оцениваются по обороту, а не по марже;
• собственник не видит общую товарную матрицу.

В результате бизнес растёт по обороту, но управляемость падает.

Что значит "управлять ассортиментом в одной логике"

Единая логика управления ассортиментом - это когда по каждому товару видно:

• где он продаётся;
• под каким артикулом;
• какая у него себестоимость;
• сколько его осталось;
• как он продаётся на каждой площадке;
• сколько он зарабатывает;
• какие расходы по нему есть;
• какие возвраты;
• где он в рекламе;
• где он участвует в акциях;
• где его нужно пополнить;
• где его нужно остановить;
• где его стоит развивать;
• где он продаётся в минус.

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

Базовая структура данных

Для управления ассортиментом на нескольких площадках нужно собрать единую карточку SKU.

В ней должны быть:

Без такой структуры селлер будет видеть много отчётов, но не будет видеть решение.

Роль 1С в управлении ассортиментом

1С обычно является учётным центром бизнеса.

Там хранятся:

• номенклатура;
• закупки;
• себестоимость;
• остатки;
• склады;
• документы;
• движения товара;
• взаиморасчёты;
• данные для бухгалтерии и управленческого учёта.

Но сама по себе 1С не всегда даёт полную картину маркетплейсов. В ней может быть товар и себестоимость, но не всегда корректно подтянуты:

• комиссии площадок;
• логистика маркетплейсов;
• рекламные расходы;
• возвраты;
• удержания;
• статусы заказов;
• данные по акциям;
• площадочная аналитика;
• финансовые отчёты;
• фактическая сумма к перечислению.

Поэтому 1С должна быть не "отдельной системой", а частью связки: маркетплейсы → интеграция → 1С → управленческая аналитика.

Что нужно синхронизировать между маркетплейсами и 1С

Минимальный набор данных:

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

Чем больше данных передаётся вручную, тем выше риск ошибок.

Почему артикулы - основа всей системы

Самая частая проблема мультиплощадочного учёта - несостыкованные артикулы.

Например:

• в 1С товар называется "Крем увлажняющий 50 мл";
• на WB - "Крем для лица увлажняющий дневной";
• на Ozon - "Крем увлажняющий, 50 мл, для сухой кожи";
• на Яндекс Маркете - "Увлажняющий крем для лица 50 мл";
• артикулы у всех разные;
• штрихкод один, но в отчётах используется не везде;
• комплект на одной площадке продаётся как отдельный SKU.

Если нет единого внутреннего артикула, аналитика рассыпается.

Нужно завести внутренний мастер-SKU, к которому привязаны все площадочные идентификаторы.

Например:

Тогда бизнес видит один товар во всех каналах и может сравнивать результаты.

Как управлять ценами на нескольких площадках

Цена одного и того же товара не всегда должна быть одинаковой на всех маркетплейсах.

Почему:

• разные комиссии;
• разная логистика;
• разные акции;
• разные скидки;
• разные условия хранения;
• разная конкуренция;
• разный рекламный расход;
• разные ожидания покупателя.

Но минимальная цена должна считаться по единой формуле.

Минимальная цена должна учитывать:

• себестоимость;
• упаковку;
• доставку до склада;
• комиссию маркетплейса;
• логистику;
• хранение;
• рекламу;
• возвраты;
• скидку продавца;
• налоги;
• желаемую прибыль;
• дополнительные удержания.

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

Пример

Если смотреть только цену, WB кажется конкурентным. Если смотреть прибыль, видно, что Ozon для этого SKU выгоднее.

Как управлять остатками на нескольких площадках

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

Проблемы возникают, когда:

• общий товар лежит на одном складе;
• часть остатка зарезервирована под FBS;
• часть уже отправлена на FBO/FBW;
• на одной площадке товар закончился;
• на другой товар лежит без движения;
• в 1С остаток есть, а на маркетплейсе он недоступен;
• товар в пути не учтён;
• возвраты не вернулись в продажу;
• поставка зависла на приёмке.

Для селлера важно видеть не просто "остаток 500 штук", а распределение:

Так видно, где товар заканчивается, а где замораживает оборотку.

Как не допустить out-of-stock на одной площадке и залежей на другой

Один из типичных сценариев:

• товар хорошо продаётся на Ozon;
• на Ozon остаток закончился;
• на WB этот же товар лежит 300 штук;
• в 1С общий остаток вроде бы есть;
• собственник не видит проблемы, потому что общий склад не нулевой.

В результате прибыльная площадка теряет продажи, а слабая держит товар.

Чтобы этого не было, нужно смотреть:

• скорость продаж по каждой площадке;
• запас в днях;
• точку пополнения;
• остаток по складам;
• товар в пути;
• прибыль по площадке;
• возможность перераспределения.

Как считать прибыль по SKU на нескольких маркетплейсах

По каждому SKU нужно считать прибыль в двух разрезах:

1. Прибыль товара в целом.
2. Прибыль товара по каждой площадке.

Формула:

Прибыль SKU на площадке = выручка по выкупленным заказам − себестоимость − комиссия − логистика − реклама − скидки − возвраты − хранение − упаковка − налоги − прочие расходы

Затем можно собрать общую картину:

Так видно, где товар сильный, а где он только портит общую экономику.

Как учитывать рекламу

Рекламу нельзя смотреть отдельно от ассортимента.

Если товар продаётся на трёх площадках, то и рекламная эффективность будет разной:

• на WB товар может зависеть от продвижения;
• на Ozon может продаваться органически;
• на Яндекс Маркете может получать заказы через акции;
• на одной площадке реклама окупается;
• на другой - уводит товар в минус.

Поэтому в отчёте нужно видеть:

• рекламный расход по SKU;
• рекламный расход по площадке;
• прибыль после рекламы;
• ДРР;
• влияние рекламы на остатки;
• возвраты после рекламы;
• целесообразность продолжения кампании.

Нельзя принимать решение "товар рекламируем" в целом. Нужно принимать решение "рекламируем этот SKU на этой площадке при такой марже и таком остатке".

Как учитывать акции

Акции на разных маркетплейсах тоже нельзя оценивать одинаково.

Один товар может:

• на WB участвовать в большой распродаже;
• на Ozon продаваться по обычной цене;
• на Яндекс Маркете участвовать в промокоде;
• в 1С иметь одну себестоимость;
• после всех скидок иметь разную прибыль.

После акции важно сравнивать:

• цену до акции;
• цену в акции;
• продажи;
• прибыль;
• остатки;
• возвраты;
• рекламные расходы;
• эффект после акции.

Если на одной площадке акция усилила товар, а на другой продала его в минус, это два разных управленческих вывода.

Как учитывать возвраты

Возвратность по одному и тому же товару может отличаться на разных площадках.

Причины:

• разная аудитория;
• разные ожидания покупателей;
• разные карточки;
• разные фото;
• разная логистика;
• разные сроки доставки;
• разное качество упаковки;
• разные отзывы;
• разные способы получения товара.

Поэтому нужно смотреть:

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

Как принимать решения по ассортименту

Единая логика нужна, чтобы по каждому SKU был статус.

Возможные статусы:

• развивать;
• пополнять;
• пополнять осторожно;
• тестировать;
• доработать карточку;
• снизить рекламу;
• вывести из акции;
• перераспределить остаток;
• распродать;
• не пополнять;
• вывести из матрицы.

Пример:

Так собственник видит не хаотичный набор действий, а управляемую товарную матрицу.

Как связать WB, Ozon, Яндекс Маркет и 1С в одну систему

Минимальная логика связки выглядит так:

1. В 1С хранится номенклатура, себестоимость, закупки, остатки и документы.
2. Маркетплейсы передают заказы, продажи, остатки, возвраты, статусы, выплаты и расходы.
3. Интеграция связывает площадочные артикулы с внутренними SKU.
4. Управленческая система собирает данные по площадкам.
5. Собственник видит прибыль, остатки, возвраты, рекламу и решения по каждому SKU.

Важно: 1С не должна быть просто "бухгалтерским хвостом". Она должна быть источником себестоимости и товарного учёта для управленческой аналитики.

Какие отчёты нужны собственнику

1. Сводка по SKU

Показывает:

• общий оборот;
• общую прибыль;
• прибыль по площадкам;
• остатки;
• возвраты;
• статус товара.

2. Прибыль по площадкам

Показывает, где товар действительно зарабатывает.

3. Остатки и запас в днях

Показывает, где товар заканчивается, а где лежит слишком долго.

4. Товары в минусе

Показывает SKU, которые продаются, но не зарабатывают.

5. Разница между площадками

Показывает, где один и тот же товар работает лучше или хуже.

6. Рекомендации по пополнению

Показывает, что заказывать, куда везти и в каком количестве.

7. Расхождения с 1С

Показывает, где данные кабинетов, склада и учёта не совпадают.

Что должно быть в еженедельном отчёте

Раз в неделю собственник должен видеть:

• какие товары дают основную прибыль;
• какие товары убыточны;
• какие товары прибыльны только на одной площадке;
• где заканчиваются остатки;
• где товар залежался;
• где реклама съедает маржу;
• где выросли возвраты;
• какие SKU нужно пополнить;
• какие товары не стоит пополнять;
• какие остатки можно перераспределить;
• какие карточки нужно доработать;
• где данные не сходятся с 1С.

Частые ошибки при управлении несколькими маркетплейсами

Ошибка 1. Считать общий оборот и не считать прибыль по площадкам

Один маркетплейс может давать оборот, но тянуть товар в минус.

Ошибка 2. Не связывать артикулы

Если нет единого SKU, невозможно корректно сравнить площадки.

Ошибка 3. Вести остатки вручную

Ручные остатки быстро устаревают и приводят к oversell, out-of-stock и лишним закупкам.

Ошибка 4. Не учитывать разную себестоимость партий

Если себестоимость изменилась, старая цена может стать убыточной.

Ошибка 5. Смотреть рекламу отдельно

Реклама должна считаться по SKU и площадке, а не только общим бюджетом.

Ошибка 6. Не учитывать возвраты

Возвраты могут делать товар убыточным на одной площадке и нормальным на другой.

Ошибка 7. Планировать поставки по общему остатку

Важно смотреть остаток и скорость продаж по каждой площадке.

Ошибка 8. Не сверять выплаты и удержания

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

Как понять, что пора объединять управление ассортиментом

Признаки:

• больше одной площадки;
• больше 50-100 SKU;
• данные ведутся в нескольких таблицах;
• остатки часто не сходятся;
• товар заканчивается неожиданно;
• есть товары с оборотом, но без прибыли;
• менеджеры спорят, какие данные верные;
• собственник не видит прибыль по SKU;
• реклама считается отдельно от товаров;
• поставки планируются "по ощущениям";
• 1С не связана с фактическими продажами маркетплейсов;
• выплаты не совпадают с ожиданиями.

Если хотя бы несколько пунктов совпадают, бизнесу уже нужна единая логика управления.

Пошаговый план внедрения единой логики

Шаг 1. Навести порядок в артикулах

Собрать соответствие:

• внутренний артикул;
• артикул WB;
• артикул Ozon;
• артикул Яндекс Маркета;
• штрихкод;
• артикул в 1С.

Шаг 2. Обновить себестоимость

Проверить:

• закупочную цену;
• упаковку;
• доставку;
• дополнительные расходы;
• себестоимость новой партии;
• различия между партиями.

Шаг 3. Собрать остатки

По каждому SKU:

• общий остаток;
• остаток по площадкам;
• остаток на своём складе;
• FBO/FBW/FBY;
• товар в пути;
• возвраты;
• резерв.

Шаг 4. Рассчитать прибыль по площадкам

Для каждого SKU отдельно по WB, Ozon, Яндекс Маркету.

Шаг 5. Разделить товары по статусам

• развивать;
• пополнять;
• тестировать;
• распродавать;
• выводить.

Шаг 6. Настроить регулярный отчёт

Минимум раз в неделю.

Шаг 7. Связать решения с действиями

Если товар в минусе - не пополнять.Если остаток заканчивается - планировать поставку.Если на одной площадке товар слабый - доработать карточку или остановить продвижение.Если товар сильный - развивать и удерживать наличие.

Управленческий вывод

Управление ассортиментом на нескольких маркетплейсах - это уже не работа с отдельными кабинетами. Это работа с единой товарной матрицей, где каждый SKU оценивается по площадкам, остаткам, расходам, возвратам и прибыли.

Главный принцип:

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

Если WB, Ozon, Яндекс Маркет и 1С живут отдельно, бизнес неизбежно теряет управляемость: появляются расхождения, лишние остатки, out-of-stock, убыточная реклама, ошибки в поставках и неверные закупки.

Если данные собраны в одной логике, селлер видит главное:

• что продавать;
• где продавать;
• по какой цене;
• что пополнять;
• что не закупать;
• где отключить рекламу;
• где перераспределить остатки;
• какие товары выводить;
• где бизнес действительно зарабатывает.

Вопросы и ответы

Как TotalCRM помогает управлять ассортиментом на WB, Ozon, Яндекс Маркете и в 1С

Главная сложность мультиплощадочного управления - данные находятся в разных системах. WB, Ozon и Яндекс Маркет дают заказы, продажи, остатки, возвраты, отчёты и финансовые данные в своих кабинетах. 1С хранит номенклатуру, закупки, себестоимость, склады и документы. Реклама, акции и выплаты часто анализируются отдельно.

TotalCRM помогает собрать ключевые данные в единую систему:

• заказы;
• продажи;
• остатки;
• выплаты;
• удержания;
• возвраты;
• прибыльность SKU;
• работу с несколькими маркетплейсами;
• синхронизацию с 1С;
• расхождения между отчётами и фактическими данными.

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

С TotalCRM проще увидеть, где один и тот же SKU зарабатывает, где продаётся в минус, где заканчивается остаток, где товар залежался, где реклама не окупается, где данные не сходятся с 1С и какие товары нужно пополнять, перераспределять или выводить из матрицы.

Так управление несколькими маркетплейсами перестаёт быть ручным хаосом и становится системой контроля ассортимента, продаж, остатков и прибыли.