Интеграция CRM и Wildberries

Интеграция CRM с Wildberries — это обмен по API продавца: сборочные задания приходят в систему, остатки и цены уходят на площадку, финансовые удержания ложатся в заказ. Штатного модуля WB нет ни у amoCRM, ни у Битрикс24 — их подключают приложением из каталога или собственным коннектором; у RetailCRM товарный контур родной, и площадка встраивается в него как еще один канал продаж. И главная эксплуатационная особенность, о которой лучше знать заранее: токен доступа живет 180 дней, после чего интеграция просто встает.

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

Что дает интеграция CRM с Wildberries

Четыре потока данных, и у каждого своя задача.

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

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

Есть и чисто операционный аргумент, специфичный для WB. Просроченное сборочное задание — это не выговор, а деньги: штраф считается от розничной цены товара на момент заказа, а для крупногабарита и доставки курьером площадки он растет с каждым часом опоздания. Условия WB периодически пересматривает, но направление неизменно: скорость сборки стоит денег. Ручной перенос заказов из кабинета в систему тут прямой путь к просрочке.

Схемы работы и как они называются в кабинете

Начнем с терминологии, потому что на ней спотыкаются даже опытные продавцы. То, что все привыкли называть FBO, в кабинете WB называется «Склад WB», то есть FBW. Схема FBS в интерфейсе подписана как «Маркетплейс». А заказ покупателя называется сборочным заданием — именно этим термином оперирует API, и именно так его стоит называть в вашей CRM, чтобы не путать команду.

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

Токен на 180 дней: то, из-за чего ломается большинство интеграций

Авторизация в API продавца идет по токену, который создается в личном кабинете. Тонкостей тут больше, чем кажется, и почти каждая однажды выстреливает.

Токен действует 180 дней. По истечении он перестает работать, интеграция останавливается, и никакого предупреждения от площадки не приходит. Обнаруживается это обычно по просроченным сборочным заданиям, то есть уже вместе со штрафами. Поэтому в наших проектах перевыпуск токена — это пункт регламента с напоминанием в календаре и уведомлением за две недели, а не «вспомним, когда сломается».

Создать или удалить токен может только владелец кабинета. Сотрудник с ограниченным доступом этого не сделает, и если проектом занимается подрядчик, доступ надо согласовать до старта.

Значение показывается один раз, при создании. Не сохранили — создавайте новый, посмотреть повторно нельзя.

Типов токенов несколько, и от выбора зависит скорость работы. Персональный делается под собственные интеграции, сервисный выдается при подключении через каталог решений, а базовый работает только на чтение, имеет вдвое более низкие лимиты и делит их между всеми базовыми токенами кабинета сразу. Если интеграция необъяснимо тормозит, тип токена стоит проверить в первую очередь.

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

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

Что синхронизируется на самом деле

Все держится на связи товаров. У WB своя система идентификаторов: артикул продавца, номенклатура, размер, баркод. Сопоставлять надежнее всего по баркоду, потому что именно он привязан к конкретному размеру и не меняется при правках карточки. Артикул продавца тоже подходит, но требует железной дисциплины и уникальности в каталоге.

Остатки на схеме FBS передаются в разрезе складов, и соответствие складов настраивается явно. Цены и скидки живут в отдельной категории API со своей логикой — это отдельный блок работ, а не «галочка рядом с остатками».

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

Финансовая часть подтягивается с задержкой в неделю и разносится по статьям: вознаграждение площадки, логистика, хранение, приемка, штрафы, возвраты. Ради этого блока интеграцию чаще всего и заказывают — без него разговор про юнит-экономику остается разговором.

Клиента вы не получите, а отвечать ему придется по правилам площадки

Персональных данных покупателя Wildberries не передает. Собрать базу и продавать напрямую не выйдет — это позиция площадки, а не ограничение интеграции.

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

Ответы на отзывы тоже живут по правилам: отредактировать свой ответ можно один раз и в ограниченный срок, около двух месяцев. Автоматизация ответов допустима, но площадка следит за неестественным поведением, поэтому шаблоны мы делаем разнообразными, а спорные обращения всегда уводим на человека.

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

amoCRM, Битрикс24 или RetailCRM: что выбрать

Короткий ответ: если маркетплейсы — основной канал, берите RetailCRM. Если WB соседствует с сайтом, розницей и оптом, обычно выигрывает Битрикс24. amoCRM имеет смысл, когда площадка для вас дополнительный источник, а основные деньги приносят услуги или B2B.

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

Битрикс24 берут, когда WB надо свести с сайтом, оптом и внутренними задачами компании. Приложения из каталога закрывают базовый обмен, но упираются в нестандартные сценарии — здесь мы дописываем логику своим коннектором на REST, а товарный учет выносим в МойСклад или 1С.

amoCRM — про воронку и сделку, а не про склад. Технически завести сборочные задания сделками можно, но остатки, себестоимость и удержания туда не положить. Честный сценарий для amoCRM: WB приносит оптовый запрос или клиента, а дальше сделка идет по нормальной воронке.

Порядок работ: как мы настраиваем интеграцию

1. Фиксируем схемы и кабинеты. Какие схемы используются, сколько кабинетов и юрлиц, где что лежит. От этого зависит объем работ и вообще перечень возможного.
2. Определяем источник истины по остаткам. Одна система главная, остальные читают. Если остаток правят и в CRM, и в кабинете, расхождения появятся на первой неделе.
3. Наводим порядок в каталоге. Уникальность артикулов, полнота баркодов, соответствие позиций и размеров. Скучный шаг, без которого дальше ехать нельзя.
4. Получаем доступы правильно. Токен нужного типа от владельца кабинета, отдельный под нашу интеграцию, только необходимые категории. Сразу заводим напоминание о перевыпуске.
5. Настраиваем сборочные задания и статусы. Маппинг статусов, сроки передачи, сценарии под каждую схему, стикеры и поставки.
6. Подключаем остатки, цены и финансы. Соответствие складов, логика цен и скидок, разнесение удержаний по статьям расходов.
7. Тестируем на живых сценариях. Обычное задание, отмена, возврат покупателем, товар в нескольких размерах, задание по другой схеме. Возвраты забывают чаще всего, а они ломают и остатки, и деньги.
8. Включаем мониторинг. Уведомления об ошибках обмена, о заданиях без движения и о приближении срока жизни токена. Интеграция ломается тихо, а штрафы приходят громко.

Ошибки, которые мы разбираем чаще всего

Токен закончился, и никто не знал. Абсолютный чемпион по частоте. Сто восемьдесят дней проходят незаметно, а последствия наступают в виде просрочек. Лечится календарем и мониторингом, а не героизмом.

Один токен на все подряд. Тот же ключ отдан аналитике, репрайсеру и коннектору, с полными правами. Компрометация одного сервиса означает проблемы во всем кабинете.

Каталог не приведен в порядок. Пропущенные баркоды, дубли артикулов, размеры без соответствия. Товары путаются, остатки уезжают не туда, разбор стоит дороже изначальной уборки.

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

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

Сроки и стоимость

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

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

Частые вопросы

Придут ли в CRM контакты покупателей с Wildberries?

Нет, персональные данные площадка не передает. Повторные продажи и рассылки по этой базе построить нельзя, и это правило самой площадки. CRM здесь дает операционный контур и экономику, а не клиентскую базу.

Почему интеграция внезапно перестала работать?

Первая версия, которую стоит проверить, — истек токен. Он действует 180 дней, после чего просто перестает приниматься. Вторая по частоте причина — превышение лимитов запросов при неаккуратно написанном коннекторе.

Можно ли отвечать на вопросы и отзывы покупателей из CRM?

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

Работает ли интеграция со схемой FBW?

По-другому. На складах площадки сборочных заданий в привычном виде нет, работа идет вокруг поставок и остатков. Готовые приложения чаще рассчитаны на FBS, поэтому контур под FBW проектируется отдельно.

Кто должен создавать токен для интеграции?

Только владелец кабинета — сотрудникам с ограниченным доступом это недоступно. Токен лучше делать отдельный под конкретную интеграцию и с минимальным набором категорий, а не выдавать один ключ всем сервисам сразу.

Нужна ли учетная система, если есть CRM?

Зависит от системы. RetailCRM закрывает товарный контур сама. Для Битрикс24 и особенно amoCRM склад и себестоимость разумнее держать в 1С или МойСклад, а в CRM видеть заказы и процессы вокруг них.

Коротко о главном

Интеграция CRM и Wildberries закрывает операционные задачи: сборочные задания в одном окне, актуальные остатки и цены, статусы без ручного переноса и понятная экономика с учетом удержаний. Чего она не делает — не превращает площадку в источник клиентской базы и не снимает ограничения на общение с покупателем.

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

Если хотите понять, какая связка подойдет вашему магазину и во сколько обойдется, — оставьте заявку, посмотрим каталог, схемы работы и текущие процессы.