Представьте обычное утро у селлера. Открывается кабинет маркетплейса, а там несколько возвратов по одному и тому же товару. Не катастрофа, не пожар, просто неприятная рутина. Один покупатель написал, что товар не подошел. Другой приложил фото и выбрал причину "не тот товар". Третий до этого уже спрашивал в чате, подойдет ли аксессуар к его модели, но ответ получил слишком поздно.
Команда начинает разбирать заявки. Поддержка отвечает, склад готовится принять товар, кто-то проверяет, стоит ли открывать спор. Через день-два все выглядит закрытым: деньги вернули, товар вернулся, статус изменился.
Но товарная карточка осталась такой же. Описание не изменилось. Фото не изменились. Про совместимость по-прежнему написано где-то внизу. Инструкцию не добавили. Комплект не уточнили. Следующий покупатель снова видит то же обещание и снова может прийти к тому же разочарованию.
Вот этот момент обычно и стоит денег.
Возврат уже содержит подсказку
Возврат часто воспринимают как неприятный хвост продажи. Продали, не удержали, забрали обратно, пошли дальше. В операционном смысле так и есть: надо уложиться в сроки, не испортить отношения с площадкой, не зависнуть в споре.
Но у возврата есть второй слой. Покупатель уже объяснил, где его ожидание разошлось с реальностью. Иногда криво, иногда эмоционально, иногда одной фразой "не подошло". Но этот сигнал есть.
Яндекс Маркет в справке для продавцов прямо пишет: частые возвраты сигнализируют о потенциальных проблемах с товарами и заказами. В рекомендациях там фигурируют очень земные вещи: описание, реальные свойства товара, упаковка, партия, комплектация, инструкция, адаптация товара под покупателя.
То есть площадка не говорит продавцу просто "быстрее обработайте возврат". Она подталкивает к другому вопросу: почему этот возврат появился и что нужно поменять до следующей продажи.
Почему команда этого не видит
Потому что данные разъезжаются.
Причина возврата остается в кабинете площадки. Фото лежит внутри заявки. Переписка с покупателем живет в чате. Карточку редактирует другой человек. Склад знает, что партия пришла в новой упаковке, но не всегда связывает это с жалобами. Собственник смотрит на возвраты уже через деньги и процент выкупа.
Каждый видит кусок. Никто не видит рисунок.
Снаружи это похоже на нормальную работу: заявки закрываются, покупатели получают ответы, товар возвращается на склад. Но внутри может повторяться одна и та же причина. Например, покупатель не понимает совместимость. Или ждет полный комплект, хотя в коробке только базовая версия. Или видит на фото один оттенок, а получает другой. Или товар рабочий, но без инструкции выглядит сломанным.
Если такие причины не связывать с конкретным SKU, они превращаются в шум. В отчете будет "не подошло". В жизни будет еще один возврат.
У возврата есть владелец
Самая полезная мысль в таком разборе: у каждой повторяющейся причины должен быть владелец.
Если покупатель не понял совместимость, это чаще всего карточка и поддержка до покупки. Если не хватает детали, это комплект и склад. Если товар "не работает", но проблема решается настройкой, это инструкция и первый ответ поддержки. Если пришла новая партия с другим внешним видом, это закупка, склад и карточка.
Пока владелец не назван, возврат остается общей болью. А общая боль редко превращается в действие.
Wildberries в справке о рейтинге продавца пишет, что покупатели оценивают не только сам товар, но и весь процесс покупки: карточку, упаковку, ответы на вопросы, решение проблем. Там же указано, что рейтинг продавца влияет на выдачу. Для селлера это неприятная, но честная логика: проблема после покупки может вернуться в продажи через доверие и видимость.
Чем здесь может помочь автоматизация
Не тем, что "бот сам решит, кто прав". Это слабый и рискованный сценарий.
Полезный сценарий проще. Система собирает возвраты, отзывы, вопросы, чаты и карточки по SKU. Потом ищет повторяющиеся мотивы в человеческих формулировках. Не просто "не подошло", а "не подошло к такой-то модели", "ожидал другой комплект", "нет инструкции", "на фото выглядит иначе", "пришел другой цвет".
Дальше она предлагает действие и владельца: карточка, склад, закупка, инструкция, поддержка. И через две недели проверяет, ушла ли причина.
Получается не магия, а рабочий контур. Покупатель вернул товар, причина попала в разбор, карточка или процесс изменились, новый возврат проверили на ту же проблему.
Как проверить это у себя без внедрения
Возьмите 20 самых дорогих возвратов за последний месяц. Не самые частые, а именно самые дорогие по деньгам. Откройте каждый SKU рядом с его карточкой.
Смотрите не как продавец, который уже знает товар, а как покупатель. Что человек мог понять до покупки? Где карточка дала ему слишком широкое обещание? Где он должен был догадаться сам? Где поддержка могла снять вопрос до возврата? Где причина вообще уехала в склад или поставщика?
После этого запишите по каждому SKU одну фразу: что надо изменить до следующей продажи.
Если такой фразы нет, возврат закрыли только формально. Деньги вернули, товар приняли, но причина осталась в системе.
В этом и есть хорошая зона для AI-автоматизации. Не заменить людей в спорных решениях, а собрать разбросанные сигналы и показать, где товар снова приведет покупателя к возврату. Для селлера это намного полезнее, чем еще один чат-бот, который вежливо сообщает статус заявки.
Мы в Woghan помогаем строить такие контуры: данные из кабинетов, чатов, таблиц и CRM превращаются в понятные задачи по SKU. Без обещаний "автоматизировать все". Сначала ищем повторяющуюся причину, потом считаем, стоит ли ее чинить.
t.me/woghan_dev