Как связать форму на сайте с CRM и не потерять заявку при сбое

17 сентября 2026 г.

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

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

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

Путь заявки начинается не с CRM, а с формы

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

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

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

Как заявка должна попадать в CRM

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

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

Успешной передачей следует считать не сам факт отправки запроса с сайта, а подтверждённое создание нужной записи. Интеграция получает ответ CRM, сохраняет её идентификатор и связывает его с исходной заявкой. Тогда можно проверить цепочку: заявка № 154 на сайте превратилась, например, в сделку № 8271 в CRM.

Кто становится ответственным

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

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

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

Уведомление — отдельный этап

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

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

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

Как защититься от дублей

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

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

Проверка только по номеру телефона для этого подходит не всегда. Один клиент может законно оставить несколько разных обращений. Лучше иметь идентификатор конкретной отправки и дополнительно применять согласованные правила поиска дублей.

Что делать, если CRM временно недоступна

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

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

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

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

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

Ошибка должна быть заметна сотруднику

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

Например, ответственному или администратору приходит сообщение: «Заявка 154 не передана в CRM после пяти попыток». Желательно показать время поступления, контакт клиента, причину ошибки и понятное следующее действие. Если правила компании позволяют, сотрудник сможет связаться с клиентом вручную, пока техническая проблема устраняется.

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

Что уточнить о CRM до начала разработки

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

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

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

Что проверить при приёмке интеграции

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

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

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

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