Интеграция сайта с CRM: этапы и проверка заявок

1. Опишите путь обращения до действия менеджера

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

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

Ниже — учебный маршрут поставщика оборудования. Принятое правило: запрос на обслуживание создаёт сделку в воронке «Сервис», стадии «Новый запрос»; совпавший контакт связывается со сделкой, неоднозначное совпадение передаётся на разбор. Все обозначения и данные вымышлены. Это образец требований, а не описание уже установленной на вашем сайте интеграции.

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

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

2. Подготовьте карту полей и правила проверки

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

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

Перед запуском менеджер открывает карточку DEMO-DEAL-01 и сверяет её с каждой строкой, включая пустой комментарий и отсутствие меток в отдельных тестах. Если поле обязательное в CRM, но его неоткуда взять в форме, исправляют требования до публикации. Изменения обязательных полей CRM после запуска включают в сопровождение и повторную проверку.

3. Различайте повтор клиента и повтор доставки

Существующий клиент может оставить новый запрос на другую услугу. Это новое обращение, даже если телефон уже есть в базе. Двойное нажатие кнопки или повторная отправка того же события — другой случай. Если объединять всё по номеру телефона, можно потерять новый интерес; если всегда создавать контакт, база быстро наполнится дублями.

В Битрикс24 метод crm.duplicate.findbycomm позволяет найти лиды, контакты и компании с совпадающими телефонами или e-mail. Он помогает найти кандидатов, но не определяет бизнес-правило дальнейшего действия. Совпавший контакт можно связать с новой сделкой; неоднозначные совпадения направить на проверку менеджеру.

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

Документация: Битрикс24: поиск совпадающих контактов и лидов по телефону или e-mail;

4. Сохраняйте источник так, чтобы отчёт можно было объяснить

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

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

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

5. Предусмотрите временные сбои и повторную доставку

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

Временные ошибки обрабатывают повтором с увеличивающимися интервалами и ограничением числа попыток. Ошибки доступа или неверных полей требуют исправления причины. У Битрикс24 есть ограничения интенсивности REST-запросов и потребления ресурсов; обработчик должен учитывать актуальные правила конкретного сервиса.

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

Ниже — учебные правила обработки. Автоматические повторы разрешены только там, где известно, что запись не создана, либо предусмотрена проверенная защита от повторного создания. Обрыв ответа после отправки относится к неопределённому результату, а не к автоматически безопасной ошибке.

Если таблица не помещается на экране, прокрутите её по горизонтали.

Пример настройки для испытания: после первой безопасно повторяемой ошибки сделать ещё три попытки через 1, 5 и 15 минут; после последней неудачи передать человеку. Это четыре попытки всего, а не обещание скорости доставки. В рабочем проекте интервалы, число попыток, уведомления и предельный возраст очереди согласуют с процессом продаж и правилами API.

Документация: Битрикс24: ограничения REST API; Stripe: повторы событий, асинхронная обработка и проверка вебхуков;

6. Защитите доступ и сделайте ошибки наблюдаемыми

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

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

Учебная строка журнала: «10.09.2026 11:05, время Минска; request_id=DEMO-CRM-001; попытка=2; результат=передано; crm_id=DEMO-DEAL-01». Если возникла ошибка доступа, вместо ID сделки фиксируют безопасный код причины и состояние «нужна проверка». Контактные данные и секрет в эту запись не входят.

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

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

Документация: Битрикс24: входящие и исходящие вебхуки, права и защита секрета; OWASP: безопасное журналирование ошибок и событий;

7. Условный пример: повторное обращение после сбоя CRM

Продолжим учебный пример поставщика оборудования. Клиент с контактом DEMO-CONTACT-01 оставляет запрос на обслуживание DEMO-CRM-001, хотя раньше покупал технику. Сайт сохраняет обращение с отдельным ID, услугой и рекламными метками. Соединение с CRM не устанавливается до отправки запроса, поэтому обращение остаётся в очереди, а новая сделка ещё не создана.

При следующей попытке связь восстановлена. Интеграция находит единственный подходящий контакт, создаёт DEMO-DEAL-01 в воронке «Сервис» и сохраняет её ID. После подтверждения передачи создаётся задача менеджеру. Повтор обработки DEMO-CRM-001 возвращает уже известный результат: второй сделки и второй задачи нет. Если бы ответ оборвался после создания, сначала потребовалась бы сверка внешнего ID по правилам раздела об ошибках.

Позднее тот же клиент отправляет новый запрос DEMO-CRM-002 в новом визите, источник которого не удалось определить: нет меток, сведений о переходе и сохранённого источника текущего визита. По принятому бизнес-правилу это отдельная сделка DEMO-DEAL-02, связанная с прежним контактом. Итог проверки: один контакт, два новых обращения, две соответствующие сделки; рекламные метки первого запроса сохранены, второй запрос не приписан прежней рекламе. Сценарий иллюстрирует проектирование и приёмку, а не подтверждённый кейс ActiveLab.

8. Примите интеграцию вместе с будущими пользователями

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

Ошибки и обрывы воспроизводят на изолированном контуре или через управляемую имитацию API, без отключения рабочей CRM. Тестовые контакты используют адреса example.com; реальные клиентские сообщения отключены, записи исключены из отчётов продаж. Колонку «Факт / доказательство» заполняют после выполнения: пример не выдаёт непроведённые тесты за успешные.

Если таблица не помещается на экране, прокрутите её по горизонтали.

По каждой строке ставят «пройдено», «не пройдено» или «не применимо» с объяснением. Учебный пример записи: «T08 — не пройдено: после потери ответа создана вторая сделка; приложены два ID; исправление назначено разработчику, повторная проверка обязательна». Нельзя закрывать приёмку только потому, что обычная заявка прошла T01. Критерии допуска к запуску заранее согласуют; потеря обращения, дубли одного события и отсутствие доступа менеджера требуют исправления затронутого сценария.

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