Как связать Ozon и Wildberries с CRM: план и проверка

Связать Ozon и Wildberries с CRM — значит настроить обмен нужными данными и проверить, что системы одинаково понимают товар, заказ и его состояние. Разберем план подключения, вопросы к интегратору и небольшой пилот, который поможет найти ошибки до расширения на весь ассортимент.

Сначала решите, какие данные должны совпадать

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

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

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

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

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

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

Есть проверяемый пример: официальная документация модуля RetailCRM с Ozon Seller описывает работу по FBS и обмен рядом операционных данных. Это пример конкретной связки, а не характеристика всех CRM и не подтверждение аналогичного модуля Wildberries.

Для выбранного решения откройте его действующую документацию. У RetailCRM есть отдельный раздел интеграции с Ozon Seller. Сопоставьте список возможностей со своей задачей и попросите показать ограничения на демонстрации.

• Какие кабинеты, страны регистрации и модели продаж поддерживаются?
• Какие данные читаются, а какие модуль умеет изменять?
• Как обрабатываются отмены, возвраты и частичные изменения заказа?
• Как часто идет обмен и как заметить задержку или ошибку?
• Какие тарифы и дополнительные расходы нужны для вашей конфигурации?
• Кто отвечает за обновление модуля после изменений API площадки?
• Как остановить записи и вернуться к прежнему процессу?

По Wildberries отдельно проверьте соответствие модели: например, официальное описание FBS помогает зафиксировать, какие операции остаются у продавца. Саму настройку CRM нужно брать из инструкции конкретного модуля, а не из общего гайда о площадке.

Как подготовить каталог и остатки

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

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

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

Учебный пример сверки остатка

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

Начните с небольшого набора товаров: простой артикул, вариант с размерами, товар с низким остатком. Такой пилот показывает ошибки связи лучше, чем просмотр большой выгрузки без ручной проверки.

Как сопоставить заказы и статусы

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

Договоритесь, какой статус означает подтвержденное действие. «Готовится» в CRM и «ожидает сборки» на площадке могут иметь разный смысл. Нужно сопоставление с операцией, а не только похожее слово.

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

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

1. Роли данных. Определите, кто хранит каталог, цену и остаток.
2. Сопоставление. Свяжите товар, вариант, кабинет и внешний номер.
3. Пилот. Проверьте заказ, повтор события, отмену и резерв.
4. Контроль. Согласуйте журнал ошибок, ответственного и остановку записи.

Как провести пилот на нескольких товарах

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

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

Учебный приемочный список пилота

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

Не создавайте фиктивные покупки ради статьи. В рабочем проекте используйте допустимый тестовый контур или согласованный контроль реальных операций. Условия проверки зависят от площадки и интегратора.

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

Где вести отзывы и чаты покупателей

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

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

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

Учебный пример передачи обращения

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

Кто проверяет ошибки после запуска

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

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

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

Если появилась массовая ошибка записи, сначала остановите ее распространение по согласованному плану. Затем зафиксируйте затронутый набор и восстановите корректные значения. Массовая повторная отправка без разбора причины может увеличить число дублей.

Как посчитать стоимость подключения

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

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

Учебный расчет трудозатрат

Используйте расчет как шаблон наблюдения, а не обещание результата. Если ошибочные остатки создают новые отмены, экономия ввода заказа не оправдывает запуск. Сначала исправьте обмен и повторите приемку.

Как подготовить передачу проекта новому сотруднику

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

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

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

Учебная карточка ошибки

Карточка не содержит API-ключа и лишних сведений покупателя. Ее задача — сохранить контекст и не заставлять следующего сотрудника заново выяснять, какой заказ и какая операция затронуты.

Когда стоит отложить расширение интеграции

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

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

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

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

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

Что в итоге

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

Источники

• Интеграция RetailCRM с Ozon Seller. Проверка 16.10.2026.
• Возможности модуля RetailCRM/Ozon. Проверка 16.10.2026.
• Чаты маркетплейсов Спикс. Проверка 16.10.2026.
• FBS на Wildberries. Проверка 16.10.2026.