3

WebTech

Личный кабинет

Проекты, коммерческие предложения, документы и отчёты — в одном месте.

Войти Зарегистрироваться Забыли пароль?
CRM и продажи

Интеграция сайта с CRM-системами: обмен без двойного ввода

Обмен даже с той CRM, для которой нет коннектора

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

Что мешает связать сайт с CRM

Причины почти всегда одни и те же — независимо от того, идёт речь о самописной системе или о закрытом отраслевом решении.

Готового коннектора нет

Для популярных CRM модули продаются, для остальных — нет. Самописная система или закрытая отраслевая программа остаётся вне обмена.

API есть, описания нет

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

Справочники не совпадают

Статусы, источники, менеджеры и номенклатура названы по-разному. Без сопоставления данные приходят, но разложить их некуда.

Сбой обмена теряет заявки

Если CRM недоступна или вернула ошибку, отправка не повторяется, и обращение клиента исчезает. Обнаруживается это по жалобе, а не по журналу.

Способы стыковки с произвольной CRM

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

REST API с описанием

Самый предсказуемый путь: методы, лимиты и форматы известны. Описываем контракт, сразу закладываем идемпотентность и повторные попытки.

API без документации

Разбираем поведение системы по коду и реальным запросам, фиксируем найденное как контракт. Этот этап добавляется к проекту, но дальше обмен идёт по обычной схеме.

Вебхуки со стороны CRM

CRM сама сообщает об изменении сделки. Экономит запросы, но требует идемпотентной обработки: одно и то же уведомление может прийти повторно.

Файловый обмен

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

Промежуточная очередь

Отдельный слой между системами: хранит события, повторяет неудачные, ведёт журнал и снимает связанность. Заменить или добавить систему потом дешевле.

Направление обмена для каждой сущности

До разработки фиксируется, какая система считается источником правды по каждому полю. Без этого обе стороны считают себя главными и перезаписывают данные друг друга.

Заявки и обращения
Сайт → CRM
Форма, чат, звонок и письмо создают обращение с источником и метками. Отправка идёт через очередь, поэтому недоступность CRM не мешает клиенту отправить форму.
Контакты и компании
CRM ↔ сайт и учёт
Обмен в обе стороны по реквизитам и контактам. Важно заранее решить, какая сторона создаёт новую запись, иначе появляются дубли.
Сделки и их состояния
CRM → сайт, учёт, аналитика
Изменение статуса сделки расходится по внешним системам: клиент видит прогресс, учёт получает результат, аналитика — причину отказа или успеха.
Справочники
CRM ↔ учёт
Статусы, источники, ответственные, номенклатура и причины отказа сопоставляются таблицей соответствия. Это самый объёмный пункт контракта.
Задачи и ответственные
CRM → уведомления
Новая задача или просроченный шаг уходят туда, где сотрудник их увидит: в почту, мессенджер или другой рабочий канал.
Отчётность
CRM → хранилище и BI
Данные выгружаются в том виде, в котором их можно сравнивать с учётом: продажи, отгрузки и оплаты должны считаться из одних и тех же событий.

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

Что фиксируем в контракте обмена

Этот список согласуется письменно до начала разработки. Он же становится основой приёмочных проверок.

  • Сущности и поля: что передаётся, в каком формате и какие поля обязательны
  • Внешние идентификаторы: по какому ключу системы узнают одну и ту же запись
  • Правила сопоставления справочников: статусы, источники, менеджеры, номенклатура
  • Частота обмена: по событию, по расписанию или оба варианта для разных сущностей
  • Поведение при ошибке: очередь, повторные попытки, ручной повтор из журнала
  • Лимиты и доступы: ограничения по частоте запросов, отдельный пользователь интеграции

Как мы делаем обмен с произвольной CRM

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

  1. 01

    Аудит и схема

    Разбираем системы, сущности и потоки. Фиксируем, что считается источником правды и где сейчас расходятся данные.

  2. 02

    Контракт обмена

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

  3. 03

    Прототип

    Проверяем обмен на реальных данных в ограниченном объёме: несколько десятков записей в обе стороны.

  4. 04

    Внедрение

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

  5. 05

    Эксплуатация

    Мониторинг, сверка расхождений, обновление коннекторов при изменениях API на стороне сервиса.

Что делает обмен надёжным

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

Идемпотентность

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

Очередь и повторные попытки

Если внешняя система недоступна, операция ждёт и повторяется по расписанию, а не теряется.

Журнал обмена

Видно, что и когда ушло, что вернулось и что не прошло. Неудачную операцию можно повторить вручную.

Лимиты провайдера

Учитываем ограничения по частоте запросов, чтобы не получить блокировку со стороны сервиса.

Сверка расхождений

Регулярная сверка ключевых сущностей между системами: расхождение видно в отчёте, а не в конце квартала.

Мониторинг и оповещения

При остановке обмена приходит уведомление ответственным, а не выясняется из жалобы клиента.

Все категории интеграций

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

Частые вопросы об интеграции с CRM

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

У нас самописная CRM, документации по API почти нет. С чего вы начнёте?
С чтения кода и наблюдения за реальными запросами: смотрим, какие методы уже используются, какие поля обязательны, что происходит при ошибке. По результатам описываем контракт обмена и согласуем его до разработки, а не по ходу.
Можно ли обойтись без API — например, файлами по расписанию?
Иногда да, если задержка в несколько часов допустима и обмен идёт в одну сторону. Для заявок с сайта файловый вариант плох: клиент ждёт ответа, а ошибку разбора выгрузки замечают позже. Тогда используется API, а файлы остаются для отчётности.
Как вы защищаетесь от дублей, если событие придёт дважды?
Каждое событие несёт внешний ключ, а операция на принимающей стороне идемпотентна: повторная доставка обновляет существующую запись, а не создаёт вторую сделку или второй заказ. Это проверяется на прототипе до включения полного обмена.
Что нужно от нас, чтобы начать работу?
Доступ к тестовому контуру CRM и учётной системы, описание того, кто отвечает за справочники, и человек, который подтверждает правила сопоставления. Технические детали мы выясняем сами — важно, чтобы решения по данным принимались быстро.
Что будет, если через год CRM заменят на другую?
Обмен строится через отдельный слой: правила сопоставления и контракт живут вне кода конкретной CRM. При замене переписывается только адаптер к новой системе, а сайт, учёт и логика обработки заявок остаются на месте.

Расскажите, какая у вас CRM

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

Бесплатный аудит

Получите бесплатный аудит интернет-магазина

За 3 рабочих дня разберём: где вы теряете заявки, какие каналы недооценены, и что даст рост в первые 30 дней.

Разбор технической части сайта: скорость, SSR, фильтры
Аудит текущей рекламы: где сливается бюджет
Анализ конкурентов в вашей нише
Прогноз CPL, ROAS и окупаемости
План действий на первый месяц
За этот месяц
42 компании получили аудит
30 мин
реакция
3 дня
аудит
100%
доступ к кабинетам

Заявка на аудит

Без обязательств. С конкретными цифрами.

Бесплатно

Ответим в течение 30 минут в рабочее время