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

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

Немного предыстории: о том, как здорово и сложно быть большим

Маркетплейс Детского мира отличается от других тем, что компания выходила в интернет, когда уже была огромной розничной сетью. Часть поставщиков продаёт товары в более чем 1 000 магазинов сети, а кто-то — теперь и для миллионов онлайн-пользователей. Это значит, Детскому миру всегда приходилось думать, как органично встраивать процессы интернет-торговли в уже существующие отлаженные механизмы розницы. А маркетплейс развивается очень быстро: несмотря на то, что мы запустили его только в 2020-м, к 2024 году на сайте и в приложении Детского мира было уже 900 000 товаров от 7 000 поставщиков.

Огромная история накладывала и свои традиции работы с партнёрами — всегда была ориентация на долгосрочные отношения и большие объёмы поставок. Чтобы каждый день в магазинах было всё, к чему привык покупатель. С этого начинался и маркетплейс. Сначала предлагали поставщикам работу по схеме FBO (Fulfilment by Operator). Когда они заранее привозят большие партии товаров, Детский мир хранит всё на своих складах, а затем доставляет по мере того, как пользователи делают заказы на сайте и в приложении. Опять-таки удобно, когда надо гарантировать покупателям, что нужный товар всегда есть на складе.

Но есть и большое количество позиций, с которыми работать по FBO очень неудобно, а иногда и невозможно. Продавцу колясок или кроваток нецелесообразно заполнять склад маркетплейса крупногабаритными товарами, а продавцу одежды — привозить горы всех моделей и размеров, ведь не угадаешь, какие точно выкупят. Но пользователи маркетплейсов привыкли, что у них всегда есть широкий выбор, а всё нужное можно купить в одном месте. Поэтому мы тоже очень хотели, чтобы в Детском мире появились новые классные бренды, а давние партнеры смогли начать поставлять нам больше разных товаров из своей линейки. Так мы подступились к запуску новой модели работы с поставщиками — FBS (Fulfillment by Seller).

Что такое FBS и какие вообще бывают схемы работы

Есть три основные схемы взаимодействия продавца и маркетплейса: FBO (Fulfilment by Operator), FBS (Fulfillment by Seller) и DBS (Delivery by Seller). В них варьируются три параметра:

• где хранятся товары;
• кто занимается упаковкой товара;
• и кто доставляет товар до покупателя.

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

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

У нас был план и мы его придерживались

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

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

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

И вот какой план мы наметили:

1. Оглядеться по сторонам и изучить устройство FBS у ближайших конкурентов: Ozon и Wildberries. Для этого нужно было провести кабинетное исследование и собрать всю доступную информацию по процессам и интерфейсам.
2. Понять, какие недостатки и преимущества схемы видят сами продавцы, какие практики не стоит повторять, а что у конкурентов сделано хорошо. Для этого — провести интервью с продавцами, которые работают по FBS на Ozon и Wildberries.
3. Переварить собранную информацию, приземлить её на наши вводные и, отталкиваясь от этого, сформулировать требования к дизайну.
4. Спроектировать интерфейс для новой схемы работы.
5. Протестировать прототип с пользователями и внести правки по замечаниям, если они будут. Возможно, провести повторное юзабилити-тестирование.
6. Реализовать задуманное.

Так мы провели 8 глубинных интервью с продавцами. Пообщались как с теми, кто обрабатывает заказы через личный кабинет маркетплейсов, так и с теми, кто работает по API в своей учётной системе (например, 1С).

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

Параллельно изучали справки и инструкции площадок, смотрели обзоры личных кабинетов продавца на YouTube — в общем всё, что можно было найти в интернете, чтобы лучше понять процесс и нюансы работы по FBS. Все собранные данные после интервью и кабинетного исследования объединили в единой карте а-ля CJM (Customer Journey Map) в Miro:

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

Проверка гипотезы, или первые ошибки

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

1. Создаёт склад: указывает время работы и срок, за который он обязуется привозить заказы на склад Детского мира. Этот шаг необходим, чтобы вообще начать работать по FBS.
2. Указывает, какие товары и в каком количестве хранятся на этом складе. С этого момента товары отображаются на сайте и в приложении Детского мира.
3. Получает заказ, как только покупатель делает его на сайте или в приложении.
4. Складывает товары в упаковки, наклеивает на них специальные этикетки и оформляет документы.
5. Отправляет заказ на склад Детского мира.

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

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

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

И предложили такой вариант:

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

Этот прототип мы отдали на юзабилити-тестирование и там нас ждали сюрпризы:

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

Когда меньше значит больше

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

1. Мы убрали необязательную информацию и реорганизовали обязательную так, чтобы список стал легче для чтения. Перед глазами у продавца стало меньше строк — а значит, чётче фокус.
2. Продавцы теперь могли менять количество товаров или удалять их из заказа в этом же списке. Так ушёл страх, что ещё до момента, когда заказ подтверждён поставщиком, он случайно сформирует поставку.
3. Вынесли номер этикетки в этот же список, чтобы продавцы смогли собирать товары по коробкам прямо по нему же.

Распределение товаров по упаковкам вынесли на этот же этап и сделали нагляднее:

Этот интерфейс тоже изменился:

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

Лучшее, конечно, впереди

FBS ещё в процессе запуска, а потому и для нас это только начало понимания, правильно ли мы всё внедрили и точно ли ничего не «сломали». Впереди ещё больше работы с фидбеком от поставщиков: продолжим приглашать их на интервью, а также будем собирать мнения прямо в интерфейсе с помощью инструмента UX Feedback. Но первые выводы мы точно учтём уже сейчас при доработке схемы FBS. Где главный из них — это даже если над вами давлеет задача «ничего не сломать», важно не бояться нового. Желая оставить максимально знакомый пользователю интерфейс, мы на самом деле осложнили ему жизнь. Несмотря на то, что старые маршруты привычны для пользователей, а разработчикам не нужно тратить время на разработку новых, в нашем случае оказалось выгоднее выделить дополнительные ресурсы и разработать новое решение.

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

Авторы статьи

• project-менеджер Ирина Масликова
• UХ-исследователь Ольга Яблонская
• ведущий дизайнер Виталий Ровный
• редактор Надежда Кияткина
• иллюстратор Катерина Иванова