Как мы сделали ИИ-саппорт для маркетплейсов и не подключили Ozon API за 1,1% от оборота

Я — Анатолий Сивожелезов, маркетолог и менеджер по развитию ИИ‑решений в команде moyrab.ru Мы помогаем компаниям расти и оптимизировать процессы за счёт внедрения цифровых сотрудников: находим узкие места, проектируем решение и доводим его до рабочего состояния.

Этот материал — разбор одного из таких проектов.

Когда бизнес говорит «нам нужен ИИ‑ассистент для службы поддержки», обычно сразу думают про нейросеть: подключим модель, зальём базу знаний — и она начнёт отвечать покупателям.

Мы делали ИИ-агента поддержки для бренда БАДов, который продаёт на Ozon и Wildberries: больше 5 000 отзывов и вопросов в квартал. Чтобы работать с отзывами Ozon через публичный API, клиенту пришлось бы подключать платный контур примерно за 1,1% от оборота — то есть платить процент с продаж навсегда. Расскажу, как мы это обошли и как подошли к поддержке как к продукту.

С Wildberries всё прямолинейно: есть официальный API для отзывов и вопросов. С Ozon сложнее. Вопросы покупателей доступны через обычный Seller API — для поддержки этого хватает. А вот отзывы через публичный API открываются только в платном тарифном контуре, который на тот момент стоил около 1,1% от оборота.

Для бизнеса это две разные истории. Одно дело — один раз оплатить разработку интеграции. Другое — навсегда привязать поддержку к проценту с продаж: чем больше компания продаёт, тем дороже доступ к данным. При этом поддержке не нужны ни финансы, ни заказы, ни остатки. Ей нужен узкий набор: текст отзыва и вопроса, товар, SKU, история ответа и статус обработки.

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

В результате клиент не стал подключать избыточный платный контур ради одной узкой задачи. Главный вывод для ИИ-проектов в e-commerce: стоимость владения складывается не только из разработки, модели и токенов.

Запрос пришёл не от поддержки, а от CEO. И боль была не в том, что обращений много — их обрабатывали. Боль в том, что команда снова и снова обсуждала одни и те же вопросы. Представьте: выходной, а в рабочем чате снова обсуждают вопрос покупателя: оператор, руководитель, подрядчик, иногда медспециалист.

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

Так что реальная задача была глубже, чем «подключить нейросеть»:

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

До любого промпта важно определить: какие обращения типовые, что можно автоматизировать, что передавать человеку, где ИИ не должен импровизировать, какие формулировки допустимы и где есть медицинские ограничения. Без этого получается красивая демка, которая в реальности даёт нерелевантные или рискованные ответы. Для health-брендов это уже не только про репутацию, но и про юридические последствия.

Поэтому мы начали с разбора поддержки как системы: кто и как отвечает, где хранятся знания, где возникают задержки. Собрали всё — скрипты, FAQ, регламенты, ответы экспертов, удачные кейсы и tone of voice. Затем разложили реальные обращения по типам: вопросы, позитив, негатив, претензии, жалобы, чувствительные кейсы и ситуации для эскалации.

Самое сложное оказалось не в технологии, а в формализации знаний. Многое существовало «в головах»: операторы знали, как правильно, эксперт — где опасно, руководитель — как звучит бренд. Всё это пришлось превратить в систему.

Потому что качество ответов ИИ всегда ограничено качеством базы, на которой он работает.

ИИ-агент должен отвечать не просто правильно, а в манере бренда. У компании уже есть свой голос: как лидер бренда объясняет продукты, снимает тревогу, работает с возражениями и чувствительными вопросами про здоровье. Поэтому мы собирали не только формальные документы.

В базу знаний вошли:

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

Мы не «загрузили документы в ИИ» — мы упаковали опыт компании. База знаний здесь не справочник, а память компании, к которой ИИ обращается на каждом ответе.

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

обращение → приведение к единому виду → классификация → поиск по базе знаний → черновик ответа → проверка ограничений → автоответ или эскалация → аналитика

Сначала система приводит обращение к единой карточке (площадка, товар, SKU, текст, статус, тип) и определяет, что перед ней. Затем ищет опору в базе знаний — не выдумывает ответ «из головы», а смотрит в FAQ, составы, правила бренда и исторические ответы. Формирует черновик и проверяет: можно ли ответить автоматически, нужно ли показать модератору, есть ли медицинский риск, достаточно ли уверенности. Хороший ИИ-саппорт знает, где остановиться.

1. Собирает обращения. Отзывы, вопросы, жалобы и негатив с обеих площадок попадают в единое окно.
2. Классифицирует. Понимает, вопрос это, отзыв, претензия, негатив или чувствительный кейс.
3. Готовит ответ. Черновик опирается на базу знаний и правила бренда, а не на «фантазию» модели.
4. Проверяет риски. Медицинская тема, претензия или низкая уверенность — обращение уходит человеку.
5. Помогает оператору. Модератор видит текст, предложенный ответ и причину классификации и может принять, отредактировать или отклонить.
6. Собирает аналитику. Показывает, что чаще спрашивают, на что жалуются и какие товары создают негатив.

Это не самостоятельный «говорящий бот», а управляемая система, где понятно, почему предложен такой ответ, на какие данные он опирался и почему кейс ушёл человеку.

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

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

Так поддержка становится частью клиентского пути и работает на кросс-сейл и средний чек — особенно ценно там, где карточка товара ограничена форматом, а обращение даёт больше контекста.

Это, пожалуй, главная ценность, даже если бы не было автоответов. Раньше обращение жило как отдельный кейс: пришёл вопрос — ответили, появился негатив — сгладили. Управленческий смысл при этом терялся: что-то обсуждали в чатах, что-то помнили отдельные сотрудники, что-то пропадало между сменами.

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

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

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

Возможность «100% автоматизации». Что реально меняется:

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

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

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

Если появились вопросы по ИИ-саппорту, архитектуре — обращайтесь.

Анатолий Сивожелезов
Стратегический партнёр по росту, маркетингу и ИИ интеграциям
Telegram: @sivozhelezov