Кому из продавцов и зачем нужна API-интеграция с маркетплейсами. Советы от Бета ПРО

Источник: Ecomhub.ру

«API-интеграции обеспечивают омниканальность логистики на маркетплейсах» - вероятно, вы слышали об этом от нас или других экспертов. Когда на конференциях нас спрашивают – как селлеру выбрать фулфилмент-оператора, который без ошибок (отмен и просрочек) обработает заказы – мы отвечаем: «проверяйте наличие API-интеграций».

Что такое API-интеграция

API-интеграция – синхронизация складской системы продавца с учетной системой маркетплейса через API-протокол, что полностью исключает ручную обработку данных. Ежедневно селлер и маркетплейс автоматически передают друг другу по API следующие данные: состав заказа и дату отгрузки, пункт доставки и статусы движения товара, в том числе на этапе возвратов, название, описание, характеристики карточки и цены на товары, этикетки для маркировки заказов, акты и товарные накладные, различные отчеты. Преимущества API-интеграции очевидны:

• Минимизируетпроцент ошибок при передаче данных. Проблемы в автоматизированном обмене возможны, если API маркетплейса внезапно изменилось, а продавец не перенастроил операции в WMS, или в складской системе селлера случился сбой.
• Сокращает расходы на ФОТ. С интеграцией селлер не нанимает и не вкладывает в развитие отдельного специалиста, который бы механически обновлял цены, менял названия, описания в карточках, выгружал данные по заказам и формировал задания для склада и т.д. Вместо этого он может сократить кадры, перенаправить и переквалифицировать 1-2 специалистов на аналитические, креативные задачи магазина на маркетплейсах.
• Поддерживает рейтинг селлера. Процент отмен по вине продавца завязан на скорости обновления остатков. Любая задержка приводит к oversales. В магазин начинают поступать заказы на товары, которых нет в наличии. Если продавец не успевает в срок привезти отсутствующие товары на склад, собрать и отвезти их в пункт приема или покупателям, он вынужден отменять заказы. Маркетплейс фиксирует это и уменьшает рейтинг магазина.
• Сохраняет заказы. Низкий рейтинг снижает позиции товаров, дает меньше заказов и сокращает выручку. Правило действует на любом маркетплейсе – будь то Wildberries, OZON, AliExpress Россия или др.
• Работает на конкурентоспособность продавца. Для покупателей маркетплейсов низкая цена – критерий выбора товаров, они ставят его на первое место (по данным Data Insight за 2021 год). Поэтому селлеры вынуждены конкурировать друг с другом за спрос через управление ценой. И в этой конкуренции ценится оперативность. Через API можно быстро и точно реагировать на изменения рынка и корректировать цены.

У каждого маркетплейса свой API, разработанный для конкретной модели – FBS (Fulfillment by Seller) или DBS (Delivery by Seller). Поэтому под площадку и схему продавцы делают разные интеграции. Как бы не привлекали преимущества, API-интеграции нужны не всем селлерам.

Кому подключать API-интеграции

Мы советуем настраивать их продавцам, которые:

• Торгуют товарами со своего склада (модель FBS, DBS).
• Ежемесячно обрабатывают не менее 50 заказов.
• Получают заказы с 2-х и более маркетплейсов.

Так или иначе первое, на что вы ориентируетесь – объем заказов. Открывая магазин на маркетплейсе, селлеры стартуют с небольшого ассортимента (тестируют площадку) и получают единичные продажи. Чтобы править карточки, корректировать сток, выгружать документы, передавать заказы на склад и статусы маркетплейсу – достаточно личного кабинета. По мере роста платного и органического трафика селлер будет переходить с 2 заказов в день на 10, 15 и больше. Масштабирование не поменяет алгоритм действий, но повысит нагрузку на сотрудника. И тогда потребность в API-интеграциях стает существенной. Поэтому продавцы приступают к настройке.

Инвестиции, без которых не запустить интеграцию

Без вложений даже одну интеграцию не создать. Процесс требует инвестиций и экспертизы. Настройка – это адаптация WMS-системы склада, включая биллинг, под правила работы маркетплейса с заказами FBS или DBS. Если вы знакомы со складской обработкой заказов для Wildberries, OZON, СберМегаМаркета или других площадок, вы понимаете, требования маркетплейсов крайне редко пересекаются.

Предположим, от селлера СберМегаМаркета поступил заказ из 2-х вложений. Собрать их в единое грузовое место нельзя, иначе селлер нарушит товарное соседство «тяжелое-хрупкое». Поэтому задача склада – разделить товары, создать 2 грузовых места и сообщить об этом маркетплейсу, чтобы получить не 1, а 2 этикетки для маркировки. Следовательно, возможность передать такую инфомацию маркетплейсу – неотъемлемая фича в интеграции со СберМегаМаркетом по FBS. Разделений не будет у Wildberries, на маркетплейсе 1 товар – это 1 заказ.

Еще одна сложная, но нужная фича – синхронизация остатков. У маркетплейсов разные системы резервации товаров. Вопрос сведения остатков между каналами продаж остро стоит перед магазинами, которые работают с 2-3 и более площадками. Ваши настройки API должны это учитывать и не допустить oversales.

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

• Собираете воедино правила работы с товарами, заказами на маркетплейсе.
• Получаете описание API маркетплейса.
• Составляете информационную технологическую карту.
• Программируете, добавляете новые процессы в WMS-систему.
• Тестируете каждую операцию в интеграции.

Иными словами, задействуете 3 вида вложений: в сотрудников и перестройку технологий, в IT-специалиста, отвечающего за программирование и воплощение технологической карты, а также специалиста, который будет следить за обновлениями API маркетплейсов и решать проблемы при сбоях в интеграции.

Объективно говоря, настраивать одну интеграцию долго. В зависимости от компетенций сотрудников, объема инвестиций процесс может идти до полугода. Но только создать интеграцию – недостаточно, ее надо регулярно поддерживать. Маркетплейсы часто меняют условия работы и обновляют API. Если API маркетплейса изменено, а ваши процессы адаптированы под прежние условия, будут появляться ошибки, которые снизят качество работы и рейтинг продавца. И так по каждой схеме, по каждому маркетплейсу. Неизбежны вложения в настройку и поддержку интеграций. Выходом для селлера модели FBS или DBS, может стать партнерство с фулфилмент-оператором полного цикла, который обеспечит складской, логистический и маркетинговый сервис и закроет потребность в API-интеграциях с маркетплейсами.

Модель FBS «устоялась» в сознании селлеров, поэтому крупные операторы уже проинтегрировались с ведущими маркетплейсами. Подчеркиваем – крупные операторы. Небольшие фулфилмент-провайдеры либо передают и выгружают информацию вручную, либо часть задач по обмену данными забирают себе, другую – делегируют продавцам.

Со схемой DBS, напротив, иная история. Модель новая, поэтому по рынку количество подключений к DBS ниже, чем к модели FBS. По нашим прогнозам, DBS – модель перспективная. Особенно для селлеров с высоким средним чеком, или с товарами, которые маркетплейсы не принимают на свой склад по FBO. В связи с этим наличие API-интеграций по DBS с маркетплейсами у фулфилмент-операторов – единичные случаи. Поэтому если вы в поиске подрядчика, уточняйте лично у менеджера, есть ли API-интеграция у провайдера, и по каким моделям.

Таким образом, при выборе самостоятельной настройки или партнерства с фулфилмент-операторов, нужно учитывать объем заказов и выручки, процент маржинальности, состояние логистической и IT-инфраструктуры, наличие человеческих ресурсов.