Бюджет интеграции RetailCRM с Ozon и Wildberries: что делать самому

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

Из чего состоит рабочая связка RetailCRM и маркетплейсов?

Интеграция интернет-магазина с маркетплейсами — это не разовая настройка API, а связка из синхронизации каталога, обработки заказов, доставки и оплаты. Работать она должна без ручного вмешательства каждый день. Продавцы приходят с одной и той же картиной: сайт живёт отдельно, Ozon и Wildberries отдельно, а остатки сходятся раз в сутки вручную через Excel (разбор интеграции интернет-магазина с маркетплейсами, kalinkindev).

Внутри рабочей интеграции четыре блока. Каталог — остатки, цены, карточки. Заказы — новое отправление на Ozon или новый заказ на Wildberries сам создаёт заказ в CRM (кейс интеграции RetailCRM с маркетплейсами через Альбато). Статусы — сборка, передача в доставку, доставлено, и они должны уезжать обратно на площадку. Уведомления — письмо или SMS клиенту при смене статуса.

Ozon и Wildberries устроены по-разному. В каталоге расширений RetailCRM больше 200 готовых модулей под разные сервисы, но покрытие по площадкам отличается. На одной подключение занимает пару кликов в каталоге расширений, на другой приходится договариваться с внешним интегратором и платить отдельно (проверка трёх модулей на тестовых витринах, Lakki CRM).

Что можно настроить самому?

• Подключение площадки по готовому модулю из каталога расширений — при условии, что модуль есть под вашу площадку и под вашу CMS.
• Сопоставление товаров по артикулу: связать номенклатуру CRM с карточками на площадке.
• Одна схема отгрузки. Если товар лежит на своём складе и уезжает курьером или в ПВЗ, правил немного.
• Базовые уведомления клиенту: заказ принят, передан в доставку.
• Тестовые прогоны: заказ на площадке, изменение остатка, отмена.

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

Что стоит заказывать интегратору?

• Обмен с 1С и другими учётными системами, где правила выгрузки пишут под ваш учёт.
• Несколько складов и смешанные схемы: часть товара лежит на площадке, часть — у вас.
• Витрина на самописной CMS или нестандартная логика оформления заказа.
• Свой сайт и площадки в одной очереди обработки, когда заказ из любого канала должен попадать в общий список и распределяться между менеджерами.
• Расчёт доставки, который зависит от веса, габаритов и города получателя.
• Доработки после запуска: площадки меняют API, модули обновляются, сценарии приходится править.

Если своих часов не хватает, эти задачи закрывают на стороне: настраивают обмен, разводят каналы по менеджерам, собирают отчёты по продажам из разных источников и сводят обращения клиентов из всех каналов в одно окно. Разбор перед стартом обычно занимает меньше времени, чем сама настройка.

Отдельный случай — когда каналов уже много и в заказах начинается путаница. Объединить Ozon, Wildberries и свой сайт в одну воронку продаж проще на этапе проектирования, чем переделывать работающую связку (https://retailcrm.by/kak-obedinit-ozon-wildberries-i-svoy-sayt-v-odnu-voronku-prodazh).

Из чего складывается бюджет?

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

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

Для белорусского рынка логика та же: заказы и остатки с разных площадок должны сходиться в одной системе. Под локальные площадки готовых модулей может не оказаться, тогда связку собирают отдельно (https://retailcrm.by/integratsiya-retailcrm-s-belorusskimi-marketpleysami).

Типичные ошибки

• Синхронизируют заказы, а остатки продолжают вести руками. Площадка продаёт товар, которого на складе нет.
• Обмен настроен раз в сутки. За это время на площадке появляются новые заказы, и цифры снова расходятся.
• Товары сопоставлены по названию. Любая правка в карточке разрывает связь, позиция выпадает из обмена.
• Статусы не уезжают обратно. Покупатель видит «в обработке», когда посылка уже доставлена.
• Уведомления включены в двух местах сразу, и клиент получает два сообщения об одном заказе. Как свести SMS из CRM, сайта и 1С в одну цепочку, разбирают в гайде про объединение уведомлений (https://postsms.by/kak-ne-zadvoit-sms).
• Интеграцию запускают сразу на рабочих карточках, без тестового магазина и пробных заказов.

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

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

Отдельно проверьте отмену и возврат. Эти сценарии чаще всего остаются незакрытыми, а потом съедают время менеджеров. Заведите привычку сверять остатки утром: если разница повторяется третий день подряд, дело в настройке обмена. Как такие сбои выглядят и как их ловить, разобрано в материале о том, как не терять заказы при синхронизации RetailCRM с маркетплейсами (https://retailcrm.by/kak-ne-teryat-zakazy-pri-sinkhronizatsii-retailcrm-s-marketpleysami).