Селлер на WB и Ozon: 800 карточек в месяц без контент-отдела
Карточки собираются из данных 1С по правилам двух площадок, проверяются до публикации, а отзывы превращаются в задачи по дефектам. Новинки выходят за два дня вместо трёх недель, контент ведёт один человек вместо двух.
С чем пришли
Владелец сформулировал задачу сроком, а не технологией: партия приходит на склад и начинает продаваться через три недели, при этом упирается всё в контент, а не в логистику. Нужно выпускать новинки за два-три дня и не раздувать отдел под план по расширению ассортимента. Отдельным пунктом — узнавать о браке в партии из отзывов на второй неделе, а не из отчёта по возвратам через два месяца. Условие: 1С не переписывать, работать программной надстройкой сверху и полностью удалённо.
Что делали по неделям — включая сложности
В реальных проектах всегда есть грабли. Мы показываем их здесь честно — потому что умение их проходить и есть то, за что вы платите.
Разбор каталога и правил площадок
Выгрузили все 6000 SKU из 1С и сопоставили с тем, что реально опубликовано на WB и Ozon. Собрали справочники обязательных атрибутов по 47 задействованным категориям обеих площадок. Тут же вскрылась главная проблема проекта: у 2100 позиций — это 34% каталога — характеристики лежали не в реквизитах, а в поле комментария свободным текстом вида «нерж. сталь, 1,8 л, крышка в комплекте».
PIM-словарь: три недели сверх плана
На разбор ассортимента закладывали неделю, ушло четыре. Написали разборщик свободного текста, вытащили атрибуты и вручную проверили контрольную выборку в 400 позиций — доля ошибок вышла 9%, что для веса и объёма недопустимо. Доработали правила, добавили словарь синонимов на 1400 нормализованных значений (нерж., нержавейка и нержавеющая сталь стали одним значением) и прогнали заново. Заполнили 1850 позиций из 2100. По оставшимся 250 угадывать не стали: поля остались пустыми, а закупщики получили в Битрикс24 задачи уточнить данные у поставщика.
Генератор карточек и профили площадок
Собрали конвейер: атрибуты из PIM-слоя, формулы заголовков и SEO-полей, генерация описания языковой моделью строго по подтверждённым фактам. Профили WB и Ozon вынесли в настройки — лимиты длин, обязательные поля, стоп-слова, справочники цветов и материалов. Первый прогон на 200 SKU редактор разбирал вместе с нами построчно: половина замечаний оказалась не про тексты, а про порядок слов в заголовке, и это ушло в формулы.
Слой валидации под каждую площадку
Вторая сложность: площадки валидируют одни и те же атрибуты по-разному. У WB свой лимит заголовка и свой справочник цветов; Ozon отклоняет названия с кавычками и оценочными формулировками и требует единицы измерения там, где WB их не спрашивает. Универсальный набор правил с исключениями начал разваливаться на третьей категории, поэтому переделали на два независимых профиля валидации. Разобрали больше 60 кодов отказа из ответов API и завели на каждый своё правило — ошибка ловится до отправки, а не после.
Отзывы и задачи по дефектам
Подключили сбор отзывов и вопросов с обеих площадок, классификацию по темам и порог срабатывания: 5 однотипных претензий по одному SKU за 14 дней поднимают задачу отделу качества. В задачу кладём цитаты, артикулы и номера партий — чтобы было с чем идти к поставщику, а не пересказывать общее ощущение.
Пилот на двух партиях
Прогнали через конвейер две реальные партии — 180 SKU. Замерили то, ради чего затевали: срок от приёмки до продающейся карточки на обеих площадках и долю отклонений модерации. Партии вышли на третий день, отклонений 3%, причём два из них оказались устаревшей записью в справочнике категории Ozon, а не ошибкой генерации.
Промышленный режим и передача
Перевели весь поток новинок на конвейер, написали регламент для редактора, настроили отчёт по очереди публикации и по срокам вывода. Второй контент-менеджер к этому моменту уже перешёл на аналитику ассортимента: открытую вакансию под эту задачу закрыли внутренним переводом вместо найма.
- PIM-слой поверх 1С:УТ: нормализованные атрибуты, словарь синонимов на 1400 значений, у каждого поля — признак источника и достоверности
- Генератор текстов на языковой модели с жёстким ограничением: только факты из PIM, пустое поле вместо правдоподобной выдумки
- Два независимых профиля площадок, WB и Ozon: формулы заголовков, справочники, лимиты и стоп-слова лежат в настройках, а не в коде
- Валидатор на 60+ правил: прогоняет карточку до отправки и раскладывает коды отказа площадок по конкретным полям
- Очередь публикации через Seller API обеих площадок с повторами, ограничением темпа и журналом каждой попытки
- Сборщик отзывов и вопросов с классификацией по темам и порогом на массовый дефект: 5 однотипных претензий за 14 дней — задача в Битрикс24
Цифры до и после
- Проект про карточки на две трети оказался проектом про данные. Мы оценили разбор ассортимента в неделю по описанию заказчика — характеристики есть в 1С — и потратили четыре, потому что у трети каталога они лежали свободным текстом в комментарии. Теперь мы просим выгрузку номенклатуры до подписания договора и сами считаем долю позиций с незаполненными реквизитами: это единственный способ назвать честный срок, а не тот, который приятно услышать.
- Универсальный слой правил для WB и Ozon — ловушка, в которую мы зашли сами. Кажется, что площадки требуют примерно одного и того же, и первые две категории это подтверждают. На третьей начинаются исключения, на пятой правила перестают читаться. Два независимых профиля дороже на старте примерно на неделю работы и заметно дешевле на дистанции: когда площадка меняет требования, правится один профиль, а не общая конструкция с оговорками.
- Самое полезное ограничение в генераторе — запрет придумывать. Модель не имеет права подставить правдоподобный вес или состав: нет факта в источнике — поле остаётся пустым, а закупщик получает задачу уточнить его у поставщика. По 250 позициям это затормозило публикацию на несколько дней и зато не породило расхождений между карточкой и товаром, которые возвращаются возвратами и падением рейтинга.
- Эффект считаем по ненанятым людям, а не по уволенным. План требовал 800 карточек в месяц; по старой технологии это пять ставок при двух имеющихся. Консервативно берём двух ненанятых менеджеров — 156 000 ₽ ФОТ с налогами. Плюс 300 новинок, выходящих на 14 дней раньше, при 11 ₽ валовой маржи с новой позиции в день — 46 200 ₽. Плюс три перехваченных массовых дефекта за четыре месяца, по 50 400 ₽ предотвращённых потерь на каждом — 37 800 ₽ в месяц. Итого 240 000 ₽ экономии против 65 000 ₽ расходов: 50 000 ₽ поддержки, около 9 000 ₽ на языковую модель и 6 000 ₽ на сервер. Чистыми 175 000 ₽ в месяц, внедрение в 690 000 ₽ окупается за 4 месяца. Выручку от позиций, до которых раньше просто не доходили руки, и восстановление рейтинга после снятых дефектов в расчёт не включали — это запас прочности, а не аргумент.
Похожая ситуация в вашем бизнесе?
Расскажите о ней — сравним с этим сценарием, найдём отличия и посчитаем вашу экономику. Диагностика бесплатна.
