Для кого эта статья?
Статья будет интересна как будущим владельцам отраслевых маркетплейсов, так и владельцам розничных интернет-магазинов, на площадках которых ещё нет автоматизированного процесса возврата товара.
В этом примере мы не просто описали алгоритм возврата товара на маркетплейсе, а показали основные проблемы бизнеса и его поставщиков при использовании неавтоматизированного процесса возврата продукции, а также измеряемую выгоду от внедрения претензионного механизма.
Несмотря на то, что в качестве кейса мы взяли внутренний маркетплейс крупной промышленной компании, он подходит для любых интернет-магазинов и электронных торговых площадок.
Алгоритм возврата товара в маркетплейсе – важная часть интернет-торговли
Исторически так сложилось: многие потребители уверены, что если дефект покупки не был обнаружен сразу – это его, потребителя, проблема. Но это не так.
Прозрачность отношений – правило хорошего тона. Если потребитель уверен в том, что товар вернут, даже если дефект был замечен не сразу, это повышает его лояльность к бренду.
Если говорить о работе с физическими лицами, в России клиенты интернет-магазинов и маркетплейсов защищены законом “О защите прав потребителей”. Они вправе рассчитывать на урегулирование вопроса, ведь закон устанавливает права потребителей на приобретение продукции надлежащего качества и безопасных для здоровья и жизни.
Независимо от того, был ли выявлен дефект производителя при получении или обнаружен спустя месяц – брак подлежит возврату.
Последствия игнорирования закона “О защите прав потребителей” можно измерить деньгами: штраф до 500 000 рублей за каждый выявленный случай продажи некачественного товара.
Но даже если поставщик соблюдает букву закона и всячески содействует замене проблемного товара, сам процесс приема, обработки заявки и вынесения решения “вручную” отнимает заметное время как поставщика, так и клиента (об этом ниже).
Для юридических лиц урегулирование споров и претензий определяется Договором заказчика и поставщика, но автоматизированный процесс урегулирования споров практически тот же самый.
Бизнес-цели внедрения алгоритма возврата товара на маркетплейсе
Заказчиком разработки выступил наш давний клиент – компания Евраз. Алгоритм возврата товара на Маркетплейсе необходимо было разработать для внутренней торговой площадки.
Главной болью заказчика были временные затраты на решение подобных споров.
Сотрудников компании Евраз не устраивал текущий бизнес-процесс, который сводился к переписке заявителя и поставщика, иногда с привлечением руководителей структурных подразделений.
Найм отдельного сотрудника-претензиониста для каждого подразделения был бы дорогим и бесперспективным, поэтому было принято решение автоматизировать работу с претензиями в личном кабинете.
Временные затраты на ручную обработку претензии
Цитируем представителей Заказчика: «Осуществлять возврат «вручную» было долго и неудобно. В основном занимались рекламацией дорогостоящих покупок».
Мы проанализировали основные трудности при ручном возврате товаров и выбрали участки с наибольшими потерями:
Два канала получения претензии – электронная почта и телефон. Причем чаще всего сначала поступал телефонный звонок, а затем пользователя Маркетплейса просили прислать нужную информацию по электронной почте. Но иногда претензию в буквальном смысле “надиктовывали” по телефону.
Общие затраты времени – От 1 до 2 часов.Сессионность получения информации – получение информации не за один звонок/одно письмо. Претензия могла быть отправлена по частям (например, “текст” по телефону, а “картинки” – почтой), даже в рамках одной позиции. Возможна приостановка процесса от 1 дня до недели.
Трудоемкий поиск и затратное хранение данных по претензиям – почтовый ящик не подходил для хранения и поиска первичной информации по претензии.
От 20 минут на одно письмо.Менеджерам поставщика приходилось вручную искать и переносить информацию в документ “Возврат от клиента” и выбирать компенсацию (денежную или замену). От 30 минут до 1 часа.
Экспедитор поставщика мог не иметь при себе необходимых документов и его не пропускали на КПП предприятия (сейчас при подтверждении возврата из системы выгружается акт на передачу в смежную систему пропусков на КПП). Остановка всего процесса от 1 дня до недели.
Итого, временные затраты на урегулирование споров по одной (!) заявке – до 4 часов чистого времени поставщика (при условии, что вся информация “под рукой”) с риском остановки процесса на срок до 2 недель.
Такой процесс был нежизнеспособным и замедлял работу как клиентов, так и поставщиков, поэтому к нему прибегали только в крайних случаях (1-2 раза в год).
Что такое алгоритм возврата товара для Маркетплейса?
Алгоритм возврата товара для маркетплейсов даёт возможность клиенту подать претензию на приобретенный продукт, а поставщику – рассмотреть заявку и вынести решение.
Для интернет-магазинов и маркетплейсов это относительное новшество. В то время как Ozon (в полной мере) и Wildberries (частично) уже давно применяют возврат заказов онлайн, бренды попроще ограничиваются информационными разделами с описанием алгоритма работы с претензиями: “Напишите на нашу почту, позвоните по этому номеру, после рассмотрения заявки мы с вами свяжемся…”
Особенности отраслевого маркетплейса компании Евраз
Внутренний Маркетплейс для сотрудников компании Евраз – нетипичный проект. Как следует из названия, основными пользователями площадки являются сотрудники компании. Здесь они могут заказывать у внешних поставщиков продукцию широкого спектра: от отверток за 19 рублей до дорогостоящих высоковольтных комплектных устройств. Оплачивает заказы Евраз централизованно в рамках договоров поставки.
Масштаб проекта «Внутренний маркетплейс Евраз»:
более 5 тысяч пользователей;
более 540 тысяч товаров;
более 1,5 млн. SKU от поставщиков;
более 6 тысяч заказов в месяц;
более 110 тысяч заказанных позиций в месяц;
13 крупных компаний-поставщиков.
Проект разрабатывался компанией Евраз при нашем участии в 2020 году и запущен в рекордные сроки – за три месяца.
С момента запуска платформа претерпела множество изменений – развитием проекта Евраз занимается по сей день, и мы принимаем в этом активное участие.
В этот раз перед нами стояла задача – разработать простой в использовании алгоритм возврата товара. Пользователь должен был иметь возможность выбрать заказ с браком и подать претензию, которую поставщик сможет обработать.
Заказчик хотел, чтобы в Личном Кабинете пользователя появился отдельный раздел – Урегулирование Споров.
У пользователя должна была появиться возможность создать Спор (Претензию) на основании одного заказа.
Причем количество единиц и позиций задавал пользователь.
Сам по себе Спор не должен быть безосновательным – помимо текстового поля для описания проблемы нужно было добавить возможность для загрузки фото.
Поставщик должен был получать претензию в систему и, после обработки, предлагать решение:
возврат оплаты;
возврат оплаты без получения проблемного товара;
замена брака;
урегулирование.
Из системы данные о решении по Спору должны были передаваться в Маркетплейс.
Если с первыми двумя пунктами всё предельно ясно, то вариант “Урегулирование” является своего рода продолжением спора. То есть, это несогласие поставщика на возврат денег или обмен. Менеджер, получив запрос на возврат товара поставщику в систему после очередного обмена с сайтом, выбирает это решение и указывает обоснование, если считает, что обмен или возмещение денег не обоснованы. Но точкой правды в споре является решение сотрудника Евраза, который делал заказ. Именно клиент принимает решение о прекращении спора.
Если пользователь платформы не соглашается с обоснованием поставщика, заявка на возврат идет по другому маршруту – решение принимает его руководитель.
Таким образом если менеджер Поставщика не может решить вопрос с обменом товара, клиент имеет возможность передать претензию “наверх”. Категорийный ответственный, имеющий больше полномочий, поможет решить спор и сможет договориться с клиентом.
Если менеджер удовлетворяет претензию пользователя Маркетплейса, Спор должен закрываться только после того, как экспедитор поставщика забирает брак и предоставляет акт на КПП. Если сотрудник Евраза на КПП отмечает в специализированной системе выполнение заявки на возврат, и если все позиции Спора закрыты, Спор должен закрываться. Если актом закрыта только часть позиций, Спор должен был возвращаться в статус “В обработке”.
Также важным требованием была автоматическая корректировка заказа: если поставщик возмещает деньги, то из заказа (на основе которого был создан Спор) должно автоматически убираться количество компенсированного товара.
Импортозамещение
Когда проект только начинался, к претендентам предъявлялось очень важное требование. Маркетплейс должен быть реализован на базе российского ПО:
Управление сайтом в качестве системы управления контентом сайта (CMS);
Управление торговлей в качестве учетной системы (ERP).
На момент старта проекта мы уже успели зарекомендовать себя в крупных проектах (в том числе и Евраза) как разработчики с высокими компетенциями, поэтому выбрали нас.
Проект был сделан за 3 месяца. Мы до сих пор гордимся рекордными сроками запуска промышленного Маркетплейса.
Мы знали, что проекты таких гигантов, как Евраз, постоянно развивается и новые задачи не заставили себя долго ждать.
Внедрение алгоритма возврата товара на Маркетплейсе (решение)
Изначально отсутствуют стандартные инструменты возврата товара поставщику в системы, поэтому разработка велась как на стороне сайта, так и на стороне учетной системы.
В личный кабинет нужно было добавить сценарии:
Оформление претензии (Спора) по заказу.
Выбор позиций заказа для Спора.
Выбор количества единиц.
Прикрепление фото и комментария к претензии.
Отправка претензии поставщику с сайта.
На стороне системы было решено разработать Кабинет Поставщика, где менеджеры поставщика смогут:
-
Принимать претензии пользователей.
Возвращать оплату.
Совершать обмен проблемного товара.
Оспаривать претензию.
Для реализации задачи на сайте была взята сущность “Заказ”. Это значительно упростило задачу в плане обмена данными с системой. Поэтому при разработке решения был переработан стандартный обмен – для того, чтобы научить механизм импорта заказов обрабатывать Споры по нашему алгоритму.
Основная информация по Спору хранится в свойствах заказа и корзины, по умолчанию они всегда попадают в обмен с системой. Однако при импорте заказа на сайт возникали сложности:
не поддерживалось обновление свойств заказа
системные ограничения импорта корзины препятствовали обновлению заказа.
Поэтому было решено доработать наш импорт заказа. Сайт научился обновлять свойства заказа из 1С и предварительно стал обрабатывать корзину заказа, определяя его позиции на обновление по специальному идентификатору.
В логике алгоритма возврата товара на Маркетплейсе участвуют следующие сущности:
Заказ. Связующая сущность
Свойства заказа. Используется для передачи признаков спора, даты открытия и пр.
Корзина. Связующая сущность
Свойства корзины. Используется для передачи даты открытия спора, текущего статуса спора, активности спора по строке, комментарий пользователя и поставщика и пр. Этих данных достаточно сайту и системе для возврата товара в маркетплейсе и понимания, как обрабатывать спор.
Highload-блоки “Статусы споров”. Предварительно выгружается из системы. Используются для понимания систем, в каком статусе находится спор.
Highload-блоки “Файлы споров”. Хранит фотографии, загруженные пользователями по спорам.
На схеме отображена картина основных зависимостей:
Сложности во время разработки
Во время разработки возникли трудности – ограничения обмена не позволяли обновлять корзину заказа из-за малейшего несоответствия позиций в отгрузке и в корзине заказа. В ходе технического исследований и отладки обмена было принято простое решение – во время обмена заказами производить обновление корзины заказа до того, как он будет обрабатываться системным импортом. Затем, после стандартного импорта производить обновление свойств заказа.
Следующей сложностью стало разбиение корзины спорного заказа. Попробуем их объяснить на примере:
пользователь магазина создает Спор на 3 батарейки из заказа.
Две из них поставщик соглашается заменить, а третий ставит на возмещение денежных средств. Фактически в заказе должно произойти разбиение одной позиции на две: “с заменой” и “на возврат”.
И такое разбиение – частый случай в претензиях. Это происходит при оспаривании, при оформлении приемки заказа, как на стороне сайта, так и в “Кабинете поставщика” в систему.
Еще одна проблема – это возможность повторного открытия Спора по заказу. По заказу невозможно открыть новый Спор, пока одна из позиций заказа находится в Споре. Это связано общим признаком, который дает системе понять, что заказ находится в обработке и формирование по нему документов ведется как по спорному заказу.
Проблема реализации повторного открытия Споров в том, что где-то должна хранится история Споров из заказа. Эту роль на себя взяла учетная система, а на сайте оставалось только настроить корректную обработку данных.
Другим подводным камнем стало условие задачи – помимо статусов “Возврат” и “Замена” должен быть статус “Урегулирование”, при котором поставщик имеет варианты:
отказать по Спору
вернуть деньги без осуществления возврата
Для этого в алгоритме возврата товара на Маркетплейсе необходимо было разработать в интерфейсе пользователя механизм выбора варианта продолжения Спора при урегулировании. Например, поставщик не согласился менять брак, но пользователь не согласен с этим решением. В таком случае пользователь может продолжить Спор или принять отказ.
Удобство пользователей и защитные механизмы
Если по Спору долго не происходит никакой активности или заявитель не согласен с действиями поставщика, то заявитель может подключить категорийного менеджера для разрешения спора. Для этого в интерфейсе открытого спора предусмотрена кнопка Узнать статус спора, где заявитель может оставить свое сообщение.
Спор может быть открыт повторно. Полная история споров хранится в системе, на сайте хранится история только за последний спор.
На сайте предусмотрена электронная приемка заказов, поэтому спор также принимается через интернет-магазин. Часть или полное количество позиций на замену могут быть отменены, если обнаруживается брак или другие недостатки.
Результаты и выводы.
После внедрения алгоритма возврата товара на Маркетплейс количество заявок выросло с 1-5 до 120 в год. У пользователей, которые раньше могли смириться с “допустимыми потерями”, появилась мотивация для осуществления рекламаций – процесс стал простым и быстрым, исключил главные боли Заказчика и Поставщика, а также сопутствующие “ручному” процессу ошибки.
Данные теперь не разрознены и хранятся:
для поставщика в учётной системе;
для сотрудников Евраза в Маркетплейсе (БД).
Оформление возврата “в ручном режиме” требовало больших усилий как со стороны пользователя торговой площадки, так и со стороны поставщика. Поэтому возврат оформлялся только в крайних случаях, когда стоимость товара намного превышала временные затраты и допустимые потери.
Теперь этим функционалом пользуются охотно. Пользователи быстро привыкли к интуитивно-понятному интерфейсу и высоко оценили эффективность новшества – трудоемкий в прошлом процесс теперь занимает не больше 20 минут.
Алгоритм рассылок и напоминаний о необработанных заявках сводит к нулю вероятность того, что претензия “потеряется” и не будет обработана. А иерархическая маршрутизация заявки не позволит претензии застрять на неразговорчивом менеджере поставщика – она будет передана “наверх” по желанию пользователя.
Сегодня к нам всё чаще обращаются с задачами на внедрение похожих механизмов. Онлайн-платформам для продажи и покупки товаров нужно быть в тренде. Один из сегодняшних трендов в онлайн-торговле – это не только удобство в использовании сайта, но прозрачность отношений с клиентом.
Наши заказчики понимают, что лояльность клиентов важна так же сильно, как и время их сотрудников.
Если Вы смогли защитить своего пользователя от мучительных ожиданий на горячей линии, от нервных разговоров с вежливо-равнодушными специалистами, а также ограничить процесс рекламаций одним каналом – в ответ вы получите довольного клиента. А довольные клиенты – возвращаются.