Если у продавца на маркетплейсе ежедневно оформляется хотя бы несколько десятков заказов, обработать их вручную через личный кабинет практически невозможно, требуется автоматизация. Хорошая новость — любой маркетплейс предоставляет необходимый для этого API. Плохая — у каждой площадки свои требования к организации инфообмена и самому процессу работы с заказами.
Сегодня на российском рынке сформировалась «большая пятерка» маркетплейсов, которые определяют правила игры: Ozon, Wildberries, Яндекс Маркет, СберМегаМаркет, AliExpress. Каждая площадка предлагает продавцам собственный API для интеграции и регламент, по которому должен работать селлер.
В статье я сосредоточусь на формате сотрудничества FBS — Fulfilment by Seller, при котором клиент подключает свой склад и торгует с него, отправляя товары через службу доставки маркетплейса, либо непосредственно сам доставляет заказы клиентам.
Работа с API маркетплейса
Для того чтобы организовать доставку заказов силами маркетплейса, селлеру необходимо:
Извлечь информацию о заказе из маркетплейса.
Загрузить полученные данные в свою учетную систему.
Обработать их и отправить задачу по сборке заказа на склад.
Отправить собранные товары в зону отгрузки.
Упаковать и корректно промаркировать товар в зависимости от требований маркетплейса.
Отгрузить товары службе доставки маркетплейса (вызвать курьерскую службу МП или самостоятельно привезти собранные заказы на склад МП).
Это общая схема. На некоторых маркетплейсах требуются дополнительные шаги, чтобы синхронизировать статус заказов. Разумеется, на каждом этапе придется оформлять необходимые документы и передавать в маркетплейс информацию о том, сколько и каких товаров будет направлено на склад.
Если количество заказов в сутки измеряется единицами, все эти операции можно выполнить через личный кабинет продавца на маркетплейсе. Когда счет идет на десятки, сотни и тысячи — это невозможно физически. Нужна автоматизация отгрузки заказов.
Причем просто подключить API, который предоставляет маркетплейс, не получится, для этого придется перестроить внутренние бизнес-процессы:
Изучить особенности работы определенного маркетплейса.
Воспроизвести их в «ручном режиме», чтобы обнаружить, какие системы и процессы внутри бизнеса нуждаются в изменении.
Привлечь разработчиков, изучить API маркетплейса и написать ТЗ по интеграции.
Интегрировать внутренние инфосистемы с API маркетплейса и протестировать каждый процесс.
Синхронизации внутренних бизнес-процессов с требованиями платформы может занять до полугода кропотливого труда по выявлению всех деталей, изменению внутренних регламентов, написанию кода и тестированию его работоспособности.
Каждый крупный продавец сегодня стремится продавать свои товары не на одной, а на всех доступных площадках. Но, даже сделав интеграцию, например, с AliExpress, инфообмен с Ozon придется настраивать практически с нуля, потому что маркетплейса свои требования. Кроме того, придется думать, как совместить регламенты разных маркетплейсов в ситуации, когда они противоречат друг другу.
Если вы думаете, что проблема надуманная и мы просто сгущаем краски, вот вам два примера для размышлений.
Пример 1
Что может быть проще обработки нового заказа? Все действия вроде бы описаны выше: извлечь информацию из маркетплейса, внести в свою систему и далее по списку, вплоть до отгрузки на склад МП. Но давайте посмотрим на практическом примере.
У Ozon нет понятия «логистический заказ», есть понятие «отгрузка». Селлеру приходит запрос: «Вот заказ, вот его состав, нужно упаковать товары и отправить по такому-то адресу».
На AliExpress запрос включает очень много параметров, например:
Заказали определенный товар.
Заказал вот этот определенный пользователь.
Заказ в этот город/страну.
Доставка осуществляется вот этой службой.
За доставку взимается вот эта сумма.
Сделана такая-то скидка.
Этот список может содержать десятки пунктов, каждый из которых необходимо учесть и как-то обработать, собрать заказ и упаковать его.
На Wildberries вообще каждый товар отправляется и маркируется отдельно. Понятие заказа может различаться на каждом из маркетплейсов, и это нужно учитывать, выстраивая инфообмен с каждой площадкой.
Пример 2
Как быть, если заказ большой и все товары не умещаются в одну посылку?
Проще всего с Wildberries — этот маркетплейс не разбивает заказы, у них своя логика, при которой каждый товар оформляется отдельно.
На AliExpress для каждой посылки необходимо создать собственный логистический заказ со своим новым номером (2, 3 и так далее). Логика: одному заказу может соответствовать несколько логистических заказов.
На Ozon есть основной заказ и заказ на отгрузку. Если в отгрузочный заказ нельзя упаковать весь основной заказ — селлеру нужно разбить основной заказ на два отгрузочных, и они обрабатываются уже по-своему, так как это два новых заказа. В процессе организации инфообмена у продавца неизбежно возникнет вопрос: что делать с номером старого основного заказа в собственной учетной системе? Придется вводить дополнительные процессы для обработки таких ситуаций.
XWAY API. Работа в режиме одного окна
Просто организовать «промежуточный шлюз», который позволит продавцу отправлять запросы ко всем маркетплейсам через единое подключение — решение, лежащее на поверхности, и… не работающее. Потому что не решает главной проблемы — приведения внутренних процессов продавца в соответствие с требованиями каждого МП.
Для того чтобы в дополнительном «промежуточном звене» появился реальный смысл и экономическая привлекательность для селлера, ему необходимо предоставить не только отдельный метод API, но и единый стандартный алгоритм, учитывающий особенности всех маркетплейсов.
Сформулируем задачу: продавец должен настроить на своей стороне интеграцию с API и все процессы по инфообмену только один раз, а дальше схема работы должна быть общей для всех площадок, чтобы никаких дополнительных доработок и технических вмешательств со стороны продавца при подключении нового маркетплейса не требовалось.
Что же такое XWAY API?
Отдельный стандартный алгоритм для селлера.
Отдельный метод API.
В XWAY API мы переработали всю логику обмена информацией. Если просто пересылать запросы от селлера на маркетплейс, продавцу все равно придется:
Обрабатывать каждую ошибку от конкретного маркетплейса.
На своей стороне выстраивать логику обработки для каждого маркетплейса отдельно.
При каждом изменении на любой из площадок уже на своей стороне дорабатывать детали.
Мы учли и свели в одно целое все особенности маркетплейсов, чтобы у селлера был единый алгоритм работы вне зависимости от конкретной площадки и их количества.
Техническая часть
Все тяжелые методы и запросы мы перевели на асинхронную схему, сохранив синхронный подход для быстрых ответов. Это позволило уменьшить количество данных, передаваемых между системами, и избавить селлеров от необходимости ожидать реакции системы.
Чтобы продавцам не приходилось постоянно проверять статус выполнения запроса, мы активно используем механику веб-хуков. После того как запрос будет обработан маркетплейсом, XWAY API уведомит селлера о результатах и предоставит необходимые данные. Это позволяет сделать работу максимально прозрачной, потому что у продавца всегда есть самая актуальная информация по ценам, товарам, возможным блокировкам, ошибкам и их интерпретации и так далее.
Поддержка
Каждый раз при интеграции с маркетплейсом есть два варианта развития событий:
Запуск и настройка определенных параметров, которые «фиксятся» только при появлении сбоев.
Постоянные тесты, разбор ошибок, мониторинг новых изменений в API маркетплейса и доработка собственных интеграций в соответствии с ними.
Первый вариант опасен тем, что периодически интеграция будет отсутствовать с момента сбоя до его устранения, а во втором случае уходит больше ресурсов на постоянную доработку. Если подключены все пять маркетплейсов, то и ресурсов необходимо больше. Это дополнительные затраты для селлеров.
В случае с XWAY API нужно поддерживать только одну интеграцию. Наш инструмент сам следит за тем, какие изменения произошли у маркетплейса, какие методы добавились. Если меняются какие-то процессы на стороне площадки, для селлера все остается неизменным.
Хочешь, чтобы что-то работало хорошо, сделай это сам. Мы сделали. Что вы об этом думаете — можно написать в комментариях или мне в Телеграм @anton_batashov