Интеграции сайта простыми словами: что связать с CRM, складом и оплатой

Ищите место, где данные приходится переносить вручную

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

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

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

Отделите передачу данных от решения сотрудника

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

Условный пример: клиент оставляет запрос на товар под заказ. Сайт создаёт обращение в CRM, прикладывает выбранный товар и комментарий. Менеджер согласует срок с поставщиком. Автоматически помечать такое обращение как подтверждённый заказ было бы ошибкой: передача состоялась, но решение ещё не принято.

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

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

Определите главный источник каждого типа сведений

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

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

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

Нарисуйте карту связей с конкретным содержанием стрелок

На карте разместите сайт, CRM, учётную систему, платёжный сервис и другие реально используемые участки. На каждой стрелке подпишите данные и событие передачи. «Заказ после сохранения» информативнее общего слова «API». API — способ программного взаимодействия; наличие такого интерфейса ещё не подтверждает готовую связь ваших систем.

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

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

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

Выбирайте готовый модуль по сценариям, а не по названию

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

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

У сервиса могут быть отдельные условия доступа к приложениям и программному интерфейсу. Например, актуальная справка Битрикс24 по Маркетплейсу описывает зависимость вебхуков и локальных приложений облачной версии в зоне ru от подписки. Это пример необходимости проверять текущие условия конкретного продукта, а не универсальное правило для любых CRM.

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

Заранее опишите повторы, задержки и недоступность

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

В документации ЮKassa такой подход описан через идемпотентность: повтор запроса с тем же ключом и теми же параметрами возвращает исходный результат в пределах предусмотренных сервисом условий. Заказчику не нужно реализовывать механизм; достаточно включить проверку «повтор после сбоя связи не создаёт лишнюю операцию» в приёмку.

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

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

Не переносите лишние данные и не раздавайте общие доступы

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

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

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

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

Проверьте цепочку на небольшом наборе контрольных записей

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

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

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

Для обмена с 1С добавьте профильные проверки из материала о диагностике обмена с сайтом. Эта статья помогает составить общий план, но не заменяет настройку конкретной конфигурации и модулей.

Запускайте связи в порядке, который позволяет увидеть результат

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

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

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

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