Собственные мысли о работе с маркетплейсами
Небольшое введение
Я думаю ни для кого не секрет, что маркетплейсы это наше все? ;) Не согласны? Я тоже. Пока… ;) Но, как минимум, вряд ли вы станете спорить с тем, что они “отжирают” все больший кусок рынка у традиционных интернет-магазинов и вряд ли, в ближайшее время, ситуация изменится, а значит нужно учиться с ними работать.
Агитировать работать на них я вас не собираюсь. Я просто, более или менее, знаю как все там устроено, потому-что мы отгружаем туда десятки тысяч (чужих!) товаров ежедневно, а для этого нужно не только понимать эту “кухню”, но и уметь ее автоматизировать.
Опять же, это ведь рассуждения? Поэтому, с удовольствием обсужу с вами моменты, которые вам покажутся не верными или спорными. На истину в последней инстанции не претендую.
Я являюсь совладельцем одного из фулфилмент-операторов (называется reWorker, все-равно в комментариях спросите ведь ;)) и в силу специфики моего бизнеса (а я занимаюсь фулфилментом довольно давно), я уже много лет наблюдаю как меняется профиль нашего среднего клиента. Если лет 5-7 назад это были в основном перепродавцы привозившие товар из Китая или покупающие оптом в РФ, то уже года 3 как, это, в основе, сами производители. За перепродавцами остался в основном нишевой товар или это крупные бренды.
Фулфилмент — комплекс операций с момента оформления заказа покупателем и до момента получения им покупки. Термин используется без перевода. Как бизнес-услуга, фулфилмент наиболее востребован интернет-магазинами и часто передается на аутсорс фулфилмент-центрам. (с) Вики
Настало время маркетплейсов?
Стоит отметить, что в силу того, что маркетплейс фактически является посредником между продавцом и покупателем, а следовательно еще одним дополнительным звеном в цепочке продаж, то единственный вариант для них не уронить качество, это жестко контролировать все процессы продавцов (мерчантов), зачастую, перекладывая часть своих проблем на них.
Собственно, показательной является история с Амазон, когда вместо того чтобы научить свою WMS систему нормально разделять товары с одинаковыми штрих-кодами от разных мерчантов, они просто заставили маркировать КАЖДЫЙ входящий на их склад товар собственным штрих-кодом, фактически перевалив свою проблема на своих же продавцов и, тем самым, создав в Америке новый вид бизнеса - preparation (prep). А именно, подготовка товара для продажи на Амазон.
Вот именно этот нюанс, а точнее, более жесткое отношение к своим клиентам (мерчантам) и дает отличный шанс нам (фулфилмент-операторам) еще больше возможностей для продажи своих услуг, ведь если вы должны отгрузить сегодня, скажем в СДЭК, 100 заказов, но отгрузите 98 или 102, то совершенно никаких проблем у вас это не вызовет. СДЭК без проблем дождется недостающих 2х завтра или даже через неделю, чтобы спокойно доставит их покупателю, так же как он без проблем доставит лишние 2, которые, по идее, должны были быть отправлены только послезавтра. В вот маркетплейс - нет! Должны сегодня отгрузить 100? Извольте отгрузить именно 100! И именно те, которые маркетплейс ждет. Или будет больно! Больно, вплоть до отключения.
А чтобы отгружать всегда 100 и 100 нужны хорошая автоматизация склада + глубокая интеграция со всеми маркетплейсам.
А как это работает? Вот об этом и поговорим!
Как это работает и почему крайне желательна автоматизация процессов?
Чуть более года назад (в июле 2020) к нам пришел первый, достаточно крупный, клиент, которому требовалась работа с маркетплейсами. Точнее, ему требовалась работа по схеме FBS на довольно больших объемах. На тот момент мы уже давно работали по схеме FBO с тем же Wildberries и “промышляли” FBS, но в ручном режиме.
Тут, думаю стоит отдельно пояснить эти 2 понятия и добавить к ним еще одно:
FBS (Fulfillment by Seller) — при данном типе отгрузок вы сами храните свой товар на своем складе. Получив заказ маркетплейс передает вам информацию о нем. Вы самостоятельно собираете заказ и передаете его маркетплейсу для доставки.Это один из самых сложных, но при этом наиболее распространенный тип работы с маркетплейсами. Он, с одной стороны, требует максимальной автоматизации работы склада и четкого выполнения регламентов маркетплейсов, которые, при этом, могут отличаться от маркетплейса к маркетплейсу. С другой стороны, позволяет не распылять стоки по складам маркетплейсов и обрабатывать поступающие заказы с одного склада сразу во множество маркетплейсов.По данной модели работают такие маркетплейсы как Яндекс Маркет, СберМегаМаркет и Озон.
DBS (Delivery by Seller) — этот тип отгрузки похож на предыдущий, но есть одно существенное отличие: вы не только сами собираете поступающие заказы, но и самостоятельно доставляете их до клиента. В настоящий момент это довольно редкий способ работы с мерчантами ввиду того, что требует большого уровня доверия маркетплейсов к своим продавцам. А от продавцов максимального качества работы не только склада но и остальных процессов.Тем не менее TMALL в России работает в первую очередь по данной модели да и остальные МП активно “смотрят” в эту сторону, т.к. он может существенно снизить нагрузку с их собственных складов (которые сейчас трещат по швам от перегруза).
FBO (Fulfillment by Operator) — по данной модели вы поставляете на маркетплейс сразу большой объем товара, который хранится на складе маркетплейса. Заказы поступающие от покупателей маркетплейс обрабатывает, комплектует и доставляет самостоятельно. Это самый простой, но вместе с тем и самый затратный способ работы с маркетплейсами т.к. требует наличие отдельного стока на складе каждого маркетплейса.По данной модели работают такие маркетплейсы как Wildberries и Озон.
Сразу скажу, что все эти термины еще до конца не устоявшиеся… Началось все с FBA (Fulfillment by Amazon). Озон в России эту же схему назвал FBO (Fulfillment by Ozon), но ввиду того что по данной схеме работают практически все маркетплейсы, то со временем, “by Ozon” превратилось в “by Operator”. Как говорится, не забавы ради, а пользы для!
В общем, тут пока рано углубляться в термины, т.к. 100% уверен, что найдется с десяток коллег, которые со мной с удовольствием поспорят и по поводу самих терминов и по поводу их происхождения/перевода. Ну не устоялся еще этот вопрос. Пройдет годик/два и уже более уверенно можно будет порассуждать на эту тему.
Пока же пройдемся по этим самым *BS и D** более подробно!
FBS
Для работы с маркетплейсом по этой схеме требуется довольно высокий уровень автоматизации склада! Одном из основных плюсов модели FBS является то, что вам не нужно множить свои стоки пропорционально количеству маркетплейсов с которыми вы работаете. Товар стоит денег! И одно дело, когда все эти деньги (товар) лежат на одном складе. И уже совсем другое дело, когда тот же товар должен лежать на 5-ти складах? Это уже, извините, почти в 5 раз больше товара нужно! А если на одном маркетплейсе лучше продается один товар, а на другом другой? Или на одном МП товар быстро ушел, а на другом почти не продается?
Вот именно FBS-модель позволяет вам хранить товар на одном складе и отгружать заказы с него! Это ЖИРНЫЙ плюс! :)
Но есть и минусы:
Основной минус в том, что все МП крайне щепетильно относятся к таким заказам!
У большинства из них есть система рейтингов, которая прямо пропорциональна количеству неподтвержденных/перенесенных/отмененных/несобранных заказы.
Вот пример из ЛК СберМегаМаркета:
Плохой рейтинг напрямую влияет на продажи (место товара в выдаче маркетплейса), лимит заказов в день, а так же может вызвать блокировку мерчанта!
Если посмотреть на скриншот из ЛК СберМегаМаркета, то можно увидеть, что рейтинг считается по заказами за 14 дней, а значит, в случае блокировки система сама включит ваш аккаунт как только срок давности косяков истечет.
Но, в любом случае, рейтинг это “головная боль” любого мерчанта, поэтому очень важно поддерживать его хотя бы в “зеленой зоне”, а вот для этого и нужна максимальная автоматизация!
Кстати, при запуске всего этого дела, у нас были случаи, когда машину с заказами разворачивали на маркетплейсе потому-что количество заказов, которых ожидают на МП не совпадало с реально привезенным. В итоге, клиент, вместо того чтобы получить небольшой снижение рейтинга сходу получал блокировку аккаунта!
Рассказываю как это сделано у нас:
Интеграция
Тут все вроде как просто! С любым маркетплейсом (и не только! Фактически с любой внешней системой, с которой есть интеграционный модуль) нужно просто создать новую интеграцию, прописать ключи, полученные в ЛК маркетплейса. Провести ряд определённые настоек (связать склады, магазины и т.д.) и активировать ее.
Все! Мы имеем готовую связь WMS и маркетплейса.
Обычно на это уходит минут 10-15.
Если хотите скриншоты, их есть у меня, но думаю тут нет каких-то особых моментов. Заполнили поля, нажали сохранить. Все, как у всех в общем.
Маппинг товара
Классно, когда твоя система является источником данных, но к сожалению такие случаи крайне редки. Обычно клиент приходит со своей, внешней системой, в которой уже есть каталог товара. Это может быть сайт на любой из известных и неизвестных CMS. Это может быть 1С, retailCRM и т.д.
Да и в любом случае на PIM наша система пока явно не тянет. Совсем не те задачи.
PIM или Product information management system — система для централизованного управления большими массивами данных о товарах. Среди этих данных могут быть: маркетинговая информация, техническое описание, фотографии, информация о производителе, продажах и т. д. © Вики
Проблема в том, что мало хранить базовые данные о товаре (название, артикул, фотография, описание, цена), этого добра у нас хватает. НО! Каждый товар должен быть каталогизирован, т.е. “лежать” в одном или нескольких разделах каталога, иметь несколько различных фотографий, иметь различные поля характеристик, которые отличаются у каждого раздела. Но самое главное, это то, что все это дело разное для каждого маркетплейса! Т.е. имеем огромный массив товаров, которые привязаны к разделам каталогизатора, но самих каталогизаторов может быть много! У каждого раздела такого каталога могут быть свои наборы полей, свое описание, свои фотографии (далеко не все маркетплейсы будут в восторге от того, что вы выкладываете один и тот же контент и у них и у конкурентов)... В общем, я в сторону ушел. PIM’а у нас нет! Он был в планах, но пока я писал этот параграф, что-то он уже сам собой отодвинулся из планов средней дальности в дальние дали! ;)
Так вот! PIM’a у нас нет, есть источник снаружи, который загружает в нашу систему товары (можно и ручками из ЛК, если товаров не много, можно из эксела, в общем тоже не суть).
А дальше, система сама подключается к каждому маркетплейсу с которым имеется настроенная интеграция и связывает товары у себя и на маркетплейсе (маппит товар), находя аналогичный товар во внешней системе.
После этой операции, которая обычно проходит фоном, можно начинать работу.
Выгрузка остатков
Это вполне логичный, но крайне важный момент! Остатки должны ВСЕГДА быть актуальными на всех маркетплейсах, в любой момент времени. Именно эта операция позволяет вам (нам) добиться максимального качества отгрузок и максимального рейтинга на маркетплейсах.
Для этого мы “пушим” остатки в режиме реального времени, а не обновляем их по тайм-ауту. Т.е. если свободный остаток изменился у любого товара в системе (произошло резервирование товара под какой-то заказ, или провели приемку, а может провели возврат. Да что угодно!), то система в ту же секунду стучится в каждый подключенный маркетплейс и сообщает о том, что теперь такого-то вот товара у нас стало столько-то!
Это позволяет свести проблемы с заказами без свободного товара к минимуму.
Конечно и тут возможны различные “косяки”:
В теории, заказ на один и тот же товар может прийти в одно и то же время. На практике это случается довольно часто. Лечится только выгрузкой меньших остатков. Есть у нас один клиент, для которого мы вообще блокируем выгрузку товаров с остатком менее 3х на все маркетплейсы и продает их через свой интернет-магазин.
У яндекс-маркета есть проблема в том, что остатки они запрашивают сами, когда клиент заходит на страницу с товаром. Это во-первых, может создать приличную нагрузку на систему, если товар популярный и его ломанутся смотреть множество людей сразу. Во-вторых, если клиент зашел на страницу, а потом пошел чай пить и вернулся через час, то заказ оформить ему дадут, а вот товар мог давно уже уйти по другому заказу. Это пока никак не лечится, приходиться мириться с данной особенностью.
- Если пуш с остатками по какой-то причине не дошел до адресата, то получаем рассинхронизированы остатки (а МП обычно не возвращают обратно какой-то вразумительный ответ о приеме этих данных). Поэтому, раз в 3 часа мы еще синхронизируем остатки уже всех товаров.
В общем, все это дело житейское, но крайне нужное, т.к. без него вся работа с МП летит к черту под хвост!
Загрузка заказов и их подтверждение
Все заказы, оформленные покупателями на маркетплейсах автоматически проваливаются в нашу WMS. Либо их нам отдает сам МП в момент оформления заказа, либо мы их забираем сами. Все зависит от предоставляемых маркетплейсом в этом плане возможностей.
Далее, обычно у мерчанта, есть несколько часов чтобы зайти в ЛК и подтвердить этот заказ, либо отказаться от него (отказ обычно так-же понижает рейтинг).
В нашем случае, это опять же делает сама WMS.
Происходит это так:
Заказ из МП попадает в нашу систему
Под каждый товар в заказе ставится резерв
Система “убеждается”, что весь товар есть в наличии и мы можем его выполнить
Систем, по API, подтверждает заказ в МП
После получения подтверждения (или скорее вместе с ним) мы получаем дату, в которую заказ должен быть получен маркетплейсом.
Вот именно в этот день заказ будет отправлен на комплектацию WMS-систему и именно в этот день мы отгрузим его со склада.
В случае работы с маркетплейсами эта дата крайне важна, т.к. за отгрузку заказа в иной день, опять же, последуют санкции (раньше - просто не примут, позже - понизят рейтинг).
Упаковка, маркировка и отгрузка
И только тут наступает звездный час непосредственно самой WMS, которая в указанную дату отдает заказ на комплектацию.
Ребята на складе:
Собирают товар
Сортируют его по заказам
Упаковывают
Обмеряют и взвешивают
Маркируют бланками МП
Готовят акты
Отгружают на МП
Если вдаваться в подробности, то в рамки одной статьи мы явно не уложимся. Сразу начнем закапываться в дебри адресного хранения, волнового подбора, артикулярного учета и других страшных слов. Я планирую, постепенно развивать эту тему как в виде статей, так и на нашем youtube канале.
Пока же понятно, что заказ нужно не просто собрать и упаковать (очень желательно быстро и без ошибок), но еще и промаркировать бланками, полученными из маркетплейса (которые кстати еще и тормозят обычно).
Для затравки можно посмотреть видео конкретно этого процесса:
Собственно, я пока завершу повествование.
По DBS и FBO будет следующая статья, а то у меня уже возникло ощущение, что я это то не закончу никогда.
Ну или не буду продолжать, если вам не понравится (и таки да, это шантаж! ;)).
Спасибо, за то что дочитали до конца. Уверен, это было не просто! :)