ИИ для e-commerce

Продавцу на маркетплейсе ИИ продают в двух совершенно разных смыслах. Первый — бесплатный генератор, который за минуту напишет описание одной карточки. Второй — производственный процесс: выгрузка каталога, генерация по схеме атрибутов категории, автоматическая проверка перед публикацией, разбор отклонений и повторный прогон. Мы занимаемся вторым, и он имеет смысл начиная с объёма, при котором ручная работа перестаёт быть дешевле контроля.

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

Где каталог теряет деньги

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

Вторая зона потерь — обратная связь. Отзывы, вопросы и обращения приходят непрерывно, отвечать на них нужно быстро, а качество ответа проверяет модерация площадки, а не только покупатель. Третья — данные: продавец знает, что «что-то не так с размерами», но не может показать это цифрой, потому что информация лежит в тысячах свободных текстов.

Предварительный анализ ищет не «всю работу с маркетплейсами», а одну операцию с известным объёмом: сколько SKU в месяц проходит через руки, сколько времени тратится на один, какая доля возвращается с отклонением и сколько стоит день простоя карточки.

Какие процессы подходят для проверки

1. Пакетная подготовка и обогащение карточек

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

2. Ответы на отзывы и вопросы под правила модерации

Это тот случай, когда «просто подключить языковую модель» не работает. Правила Wildberries требуют предварительной модерации всех ответов и прямо запрещают в них контактные данные и ссылки, просьбы связаться и предоставить фотографии, эмоциональные высказывания, сленг, смайлики, текст в верхнем регистре, упоминание проблем логистики и склада, а также ответы с большим количеством орфографических ошибок. Модель по умолчанию нарушает половину этого списка, поэтому ценность решения — в детерминированных проверках поверх генерации и в шаблонах для типовых ситуаций, а не в самом тексте.

3. Классификация обращений и черновики ответов поддержки

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

4. Разбор отзывов в структурированные признаки

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

5. Поиск по внутренним регламентам и требованиям площадок

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

6. Подготовка данных для ассортиментных решений

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

Какие данные и системы понадобятся

Для ограниченного пилота нужен не весь каталог, а контролируемая выборка:

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

Обмен строится через API площадок, учётную систему или PIM, либо через согласованные выгрузки. На этапе пилота решение не должно публиковать изменения самостоятельно: результат сначала проходит контроль, и только после подтверждения качества обсуждается автопубликация части случаев.

Как выглядит ограниченный пилот

1. Выбираем одну категорию и одну операцию: карточки, отзывы или обращения.
2. Фиксируем требования площадки и внутренние правила как проверяемые условия.
3. Формируем контрольную выборку с эталонными и заведомо проблемными случаями.
4. Настраиваем генерацию, детерминированные проверки и очередь исключений.
5. Сравниваем результат системы и сотрудника на одной и той же выборке.
6. Решаем, что можно публиковать автоматически, а что всегда проверяет человек.

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

По каким метрикам принимать решение

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

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

Что нельзя обещать до анализа

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

Отдельно стоит учитывать регулирование. Федеральный закон от 31.07.2025 № 289-ФЗ «Об отдельных вопросах регулирования платформенной экономики в Российской Федерации» на момент публикации в силу не вступил: он начинает действовать с 1 октября 2026 года согласно пункту 1 статьи 23. Процессы, которые вы автоматизируете сейчас, стоит проектировать так, чтобы правила проверок и шаблоны ответов можно было заменить без переписывания всего решения.

Связанные решения и материалы

• Автоматизация обработки первичных документов — тот же принцип: генерация отдельно, детерминированные проверки отдельно.
• Корпоративный поиск и база знаний — ответы по внутренним регламентам со ссылкой на источник.
• Внедрение речевой аналитики в отделе продаж — разбор обращений и контроль качества коммуникации.
• Снижение расходов и оптимизация штата — экономика повторяющихся операций с каталогом и обращениями.
• Оптимизация рекламных кампаний — управление платным трафиком по качественным лидам и ДРР.
• Как выбрать процесс и посчитать эффект автоматизации — исходная линия, матрица процесса и паспорт пилота.