Интеграция: CRM + СДЭК

CRM собирает историю отношений: заявки, сделки, звонки, задачи и сегменты клиентов. Для интернет-магазина это источник повторных продаж и база для рассылок.

Типовые системы на этом конце: Битрикс24, amoCRM, RetailCRM, YCLIENTS (для сервисных сценариев).

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

Как с ней работать технически: API v2: расчёт тарифов, работа с пунктами выдачи и их расписанием, создание заказа, получение наклеек, трекинг по номеру, заявки на возврат. Есть тестовый контур и договорной режим.

В CRM уходят контакты, заказы, суммы, история покупок и события (регистрация, брошенная корзина, возврат); обратно — задачи менеджерам, статусы сделок и сегменты для кампаний.

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

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

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

Главная проблема — дубли контактов и конфликт правок: клиент может быть заведён и магазином, и менеджером. Нужен единый ключ (телефон, e-mail или ID клиента) и правило, какая система считается источником истины. Второй момент — лимиты API: массовая синхронизация должна идти очередями.

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

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

Часть ограничений обходится архитектурой (кэш, очередь, разделение каналов обмена), часть — нет: тогда мы предлагаем изменить процесс, а не имитировать его в коде.

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

Сроки обычно определяет не разработка, а согласования: доступы к системе, тестовый контур, договор с провайдером, правила расчёта и требования бухгалтерии. Мы выносим эти пункты в чек-лист подготовки, чтобы они не останавливали работы в середине проекта.

Первый шаг — обследование: смотрим, какие данные уже ведутся, кто владелец каждой сущности и какие ограничения есть у API. Затем делаем прототип обмена на тестовом контуре, проверяем нештатные сценарии (повтор, отмена, частичное выполнение) и только после этого выводим интеграцию в продуктив.

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