Хьюстон, на связи Антон Баташов, руководитель отдела интеграции и технической поддержки в компании XWAY. Вы-таки будете смеяться, но у нас проблема! Чат-центр, реализованный в интерфейсе личного кабинета AliExpress, предназначен для индивидуального предпринимателя с китайским терпением, а от наших запросов и темперамента — грустит и впадает в задумчивость.
Всем привет, а теперь чуть более серьезно. Большая часть современных маркетплейсов изначально построена по схеме FbM (Fulfillment by Marketplace), в которой товары хранятся на складе площадки, а коммуникация с покупателями идет через чат-центр маркетплейса. Так работают OZON, СберМегаМаркет, Яндекс.Маркет и Wildberries, которые содержат собственные отделы продаж и поддержки клиентов. Если продавцу понадобится собственный чат с покупателями, к его услугам — интеграция через API маркетплейса.
С AliExpress все немного с точностью до наоборот — его базовая схема FbS (Fulfillment by Seller), в которой товар хранится, отгружается и доставляется самим продавцом, подразумевает, что общение с покупателями тоже осуществляется напрямую. Для этого прямо в личном кабинете AliExpress есть отдельный чат-центр. Но он рассчитан на небольшой магазин с ограниченным ассортиментом и одним единственным оператором.
Почему неудобно работать через личный кабинет
Первая и основная беда — он личный. То есть, имеется только одна точка входа. Если у нас несколько менеджеров, им необходимо работать по очереди.
Второе неудобство — стоит переключиться с одного чата на другой, и сообщение в предыдущем помечается как прочитанное. Вернуть ему прежний статус уже не получится. Начинается регламентостроение и договоренности об отметках цветом, звездочками и прочие хитрости для того, чтобы не терять чаты с клиентами и понимать, в каком они состоянии.
Если же магазин не один, допустим, их несколько (компания большая, решили разделить товары по категориям и продавать компьютеры отдельно от сантехники, например) — у каждого специалиста поддержки должны быть открыты несколько браузеров, по числу магазинов. Как вариант — разные браузеры или даже компьютеры. Если вас такая перспектива до сих пор не восхитила — добавьте к этому необходимость множественных авторизаций. Проще говоря: «Добро пожаловать в ад, боец!»
API интегрировали интегрировали, да не выинтегрировали
Да, у AliExpress замечательный API для интеграции. Но, как мы уже упоминали в статье про особенности организации инфообмена с маркетплейсами, у китайской площадки есть определенная инерционность в обновлении методов. Если же какой-то функционал сам AliExpress не считает первостепенным, то мы оказываемся в ситуации, когда API для интеграции чата вроде бы есть, а по факту — его нет. А тому, что предлагается — место в краеведческом музее. Проблема понятна, но мы же интеграторы, а значит — обязаны найти решение. И мы его нашли. Рассказываю!
Первым делом мы реализовали свой сервис, который парсит нужные нам личные кабинеты и складывает все чаты в единый интерфейс, доступный всем менеджерам поддержки. Дали возможность каждому специалисту видеть неограниченное количество магазинов из числа тех, к которым он допущен. В самих чатах добавили функционал смены статуса, переназначения ответственного, группировки по магазинам, сортировки и поиска нужного сообщения. Разумеется, предусмотрели и возможность сбора статистики — хочется же знать, насколько быстро конкретный менеджер отвечает на сообщения, какова его продуктивность и загрузка.
На этом этапе мы столкнулись с тем, что AliExpress считает множественные обращения к разным магазинам подозрительными и очень не любит, когда его парсят. В сочетании с требованиями к безопасности клиента это приводит к нескончаемому потоку запросов на повторную авторизацию с введением кода, капчами и прелестями двухфакторной аутентификации через почту или телефон. Мы потратили много усилий, чтобы нас не выкидывало из сессий и можно было спокойно пользоваться интерфейсом.
Решать возникшую проблему пришлось в несколько шагов. Первым делом после регистрации магазина мы настраиваем автоматическую пересылку писем с определенным шаблоном из почтового ящика, указанного при регистрации — на наш внутренний почтовый сервер. В результате запрос на авторизацию попадает на внутреннюю почту, к которой имеет доступ защищенная система аутентификации. Робот парсит полученное письмо, находит код подтверждения и подставляет его в ответ маркетплейсу.
Если в запросе присутствует капча — мы используем платные сервисы разбора. Для варианта аутентификации через телефон клиента мы настроили телеграм-бот, который отправляет запрос на номер клиента, привязанный к магазину. Но такая ситуация происходит крайне редко.
* * *
Требования бизнеса не всегда совпадают с тем, что задумывали создатели маркетплейсов. Но, при определенной изобретательности и понимании того, как устроен инфообмен между продавцом и площадкой — можно решить любую задачу. С вами был Антон Баташов. Если остались вопросы — пишите их в комментариях или отправляйте в телеграм @anton_batashov.
