Чтобы связать сайт с CRM, нужно договориться не только о том, в какое поле попадёт телефон. Нужен проверяемый маршрут обращения: сайт принимает и сохраняет заявку, передаёт её в CRM, получает подтверждение и сообщает сотруднику о результате. Если передача остановилась, должно быть понятно, где находится заявка и кто вернёт её в работу.
Сообщение «Спасибо, заявка отправлена» само по себе не подтверждает создание лида. Оно может означать лишь то, что сервер сайта принял обращение. Для бизнеса полезнее разделить эти два события и предусмотреть действия между ними.
Сначала решите, что должно появиться в CRM
Заявка с сайта — обращение клиента. В разных процессах оно превращается в лид, сделку или обращение, связанное с существующим контактом. Выбирать объект нужно вместе с ответственным за продажи: техническая интеграция должна поддерживать рабочий процесс сотрудников.
До подключения зафиксируйте:
- какие формы участвуют: обратный звонок, запрос расчёта, запись на услугу;
- какой объект создаётся, в какой воронке и на каком начальном этапе;
- кто получает обращение и что происходит, если ответственный недоступен;
- как поступать с новым запросом человека, который уже есть в CRM;
- где сотрудники увидят заявку, если CRM временно недоступна.
Готовая форма CRM, модуль сайта и собственный серверный обработчик могут решать эту задачу по-разному. При выборе проверяйте не только наличие подключения: выясните, где сохраняются обращения, как видны ошибки и можно ли безопасно повторить передачу. Если данные сразу уходят через форму провайдера, маршрут нужно проверять в этой системе; нельзя считать, что сайт автоматически хранит собственную копию.
Согласуйте поля, а не просто «передачу всех данных»
Подготовьте небольшую таблицу соответствий: поле формы, поле CRM, правило проверки и действие при отсутствии значения. Собирать данные «на всякий случай» не нужно. Для первого контакта передавайте сведения, необходимые именно для обработки этого обращения.
Например, для учебной формы запроса ремонта кофемашины таблица может выглядеть так. Это пример структуры, а не готовая настройка конкретной CRM.
| Данные | Куда и зачем передать | Что проверить |
|---|---|---|
| Выбранный способ связи и контакт | В соответствующее поле телефона или почты | Достаточно ли данных для выбранного способа связи; допускает ли CRM такой формат |
| Имя, если форма его запрашивает | В поле имени | Не превращать необязательное имя в причину потери обращения |
| Модель устройства и описание задачи | В поля обращения или комментарий | Длину, допустимый формат и сохранение смысла текста |
| Тип формы и страница обращения | В поля контекста | Сотрудник понимает, какую услугу и на какой странице запросили |
| Сведения о согласии, если оно служит основанием обработки | В защищённую запись, связанную с заявкой; в CRM — согласованный необходимый объём | Факт действия, время и версию текста, который видел пользователь |
| Идентификатор обращения на сайте | В поле внешнего идентификатора, если оно доступно | По нему можно сопоставить попытки передачи и запись CRM |
Проверки в браузере помогают человеку заполнить форму, но сервер должен проверить данные заново. Скрытые поля также нельзя считать достоверными только потому, что пользователь их не видит. Воронку, ответственного и разрешённый тип обращения лучше назначать по серверным правилам, а не принимать произвольные значения из формы.
Проверьте обязательные поля и справочники в самой CRM. Переименование поля на сайте или изменение этапа продаж может нарушить ранее работающую передачу. В частности, универсальный метод создания объектов Битрикс24 проверяет обязательные поля и права, а неизвестное поле может проигнорировать. Поэтому появление карточки ещё не доказывает, что все согласованные сведения записались правильно. Это пример поведения конкретного API, а не правило для любой CRM.
Если нужны рекламные метки, согласуйте отдельные поля и обработку пустых значений. Отсутствующую метку нельзя заменять выдуманным источником. Ограничения такой связи разобраны в статье о том, как понять, откуда пришла заявка с сайта.
Маршрут: от принятия сайтом до подтверждения CRM
Для собственного обработчика полезен следующий порядок. Это рекомендуемая схема; конкретная реализация зависит от сайта и возможностей выбранной CRM.
Сервер принимает и сохраняет обращение
Сервер проверяет поля и согласованные условия отправки, присваивает заявке идентификатор и сохраняет её в защищённом хранилище. Подтверждение приёма показывают после успешного сохранения. Если сохранить данные не удалось, интерфейс должен сообщить об ошибке и позволить повторить действие, а не показывать успех.
Сохранённая заявка и необходимость её отправить должны оставаться согласованными. Опасен промежуток: обращение уже записали, но до постановки задания на передачу процесс остановился. Один из способов закрыть его — одновременно сохранить заявку и запись о предстоящей отправке в одной транзакции базы данных. Отдельный обработчик затем забирает эти записи. Разработчик может выбрать другое решение, но должен показать, как оно обнаруживает и подхватывает незавершённую передачу.
Обработчик выполняет передачу
Фоновая очередь позволяет не держать посетителя у формы до ответа внешней системы. Для её работы нужен запущенный обработчик: наличие задания в очереди не означает, что оно выполнено. У обращения должны быть видны состояние передачи, последняя попытка и причина остановки.
При небольшой нагрузке возможен другой способ выполнения. Существенно, чтобы сохранённая заявка не исчезала из контроля после ошибки и чтобы повтор не создавал бесконтрольные новые записи.
CRM возвращает результат
Интеграция проверяет ответ по контракту выбранного API: код ответа, наличие ошибки, структуру результата и идентификатор созданной либо найденной записи. Например, в успешном ответе метода crm.item.add Битрикс24 сведения о созданном объекте находятся в result.item. Нельзя переносить этот формат на другую систему.
На сайте сохраняют связь между своим обращением и записью CRM. После подтверждения состояние передачи меняется на завершённое. Если CRM обрабатывает запрос асинхронно и сначала подтверждает только постановку в свою очередь, окончательный результат нужно получить предусмотренным ею способом.
Сотрудник получает уведомление
Созданная карточка должна быть доступна нужному сотруднику. На приёмке проверяют воронку, ответственного, права просмотра и уведомление, предусмотренное рабочим процессом.
Уведомление о новой заявке и уведомление о сбое — разные события. Если CRM приняла данные, но письмо сотруднику не ушло, повторно создавать лид не нужно: исправляют доставку уведомления. Если передачу ещё не подтвердили, сообщение сотруднику должно говорить об этом состоянии, а не утверждать, что лид уже создан.
Повторная отправка: ошибка не всегда означает отказ
Ошибки передачи лидов в CRM требуют разных действий. Конкретные коды и правила повторов нужно брать из документации подключаемой системы.
| Ситуация | Что делать с заявкой |
|---|---|
| CRM явно отклонила поле или обязательное значение | Сохранить обращение, исправить соответствие полей; одинаковый запрос не повторять бесконечно |
| Доступ отозван или недостаточно прав | Уведомить ответственного за интеграцию, восстановить доступ и затем выполнить контролируемую передачу |
| Получен документированный временный отказ или ограничение частоты | Назначить повтор с паузой, учесть указанный сервисом срок ожидания и допустимость повтора |
| Соединение оборвалось или время ожидания истекло | Считать результат неопределённым: запись в CRM могла уже появиться |
| Попытки исчерпаны или обработчик не работает | Оставить заявку в списке требующих действий и поднять уведомление; назначить человека для разбора |
Повторы должны иметь интервалы и предел по числу попыток либо времени. Пауза помогает не усиливать перегрузку внешней системы; исчерпание попыток должно приводить к видимому состоянию для разбора. Универсальных интервалов для всех CRM нет.
Особенно опасен учебный сценарий: CRM создала лид, но её ответ не дошёл до сайта. Сайт видит тайм-аут, повторяет создание и получает второй лид. Сетевой сбой не доказывает, что первая операция не состоялась. Даже ответ о серверной ошибке нужно оценивать по контракту API, а не автоматически считать разрешением на безопасное повторное создание.
Если CRM поддерживает идемпотентное создание, интеграция повторяет запрос с тем же ключом в пределах документированных условий. Идемпотентность означает, что повтор одной операции не создаёт дополнительный результат. Нужно проверить область действия ключа, срок его хранения и поведение при изменённых данных. Само добавление идентификатора в комментарий не даёт такой защиты.
Если этой поддержки нет, проверяют возможность найти запись по внешнему идентификатору и сверить результат. Однако последовательность «поиск ничего не нашёл — создать» сама по себе не исключает дубль: параллельный запрос может создать запись между этими действиями. При отсутствии надёжной защиты на принимающей стороне неопределённые результаты переводят на сверку, а риск дублей явно учитывают в рабочем процессе. Обещать ровно один лид при любом сбое нельзя.
Не путайте повтор операции и повторное обращение клиента
Для одной отправки формы полезен стабильный ключ операции. При повторе после сетевой ошибки он сохраняется, а сервер связывает его с уже принятой заявкой. Защиту от одновременных одинаковых отправок реализуют на сервере с атомарной проверкой и сохранением, а не только блокировкой кнопки. Такой ключ нельзя использовать как разрешение читать чужие обращения.
Новое осознанное обращение получает новый идентификатор. Человек может сегодня запросить ремонт, а завтра — обслуживание другого устройства. Один телефон не делает эти заявки дублями. Поиск существующего контакта и предотвращение повторного создания одной заявки — отдельные правила.
Согласуйте с продажами, что делать при совпадении контакта: создать новое обращение, добавить его к открытой сделке или отправить на разбор. Не удаляйте и не объединяйте сообщения автоматически лишь из-за совпадения телефона или текста. Менеджеру может потребоваться контекст обеих заявок.
Согласия и доступы должны сопровождать передачу
До запуска определите цель, состав данных, правовое основание обработки, участников передачи и сроки хранения. Для российского бизнеса согласие — одно из предусмотренных законом оснований, а применимость конкретного основания зависит от процесса. Если обработка опирается на согласие, оно должно быть оформлено отдельно от иных подтверждаемых документов; оператору нужно иметь доказательство его получения.
В техническом задании зафиксируйте, как сервер проверяет требуемое действие пользователя и где хранит время, версию текста и связь с обращением. Не ставьте отметку за человека. Форма для запроса услуги не должна автоматически давать согласие на любые дальнейшие рассылки: их условия согласуют отдельно. Юридические документы и применимость основания проверяет ответственный за персональные данные вместе с юристом.
Служебный доступ к CRM хранится на сервере в защищённой конфигурации. Токены, секреты вебхуков и пароли нельзя помещать в JavaScript публичной страницы, HTML или репозиторий. Скрипт, который выполняется у посетителя, не является местом для скрытого хранения общего ключа CRM. Предоставляйте интеграции только необходимые права и предусмотрите отзыв или замену доступа.
Телефон и сообщение клиента могут быть нужны в защищённой записи заявки. Это не повод копировать их в технические журналы, браузерную консоль и сервис аналитики. Для диагностики достаточно идентификатора обращения, состояния, времени, номера попытки и безопасного кода ошибки. Сырые ответы API тоже могут содержать данные клиента или секреты — их нельзя бесконтрольно записывать в лог.
Отдельно ограничьте доступ к хранилищу заявок, очередям, резервным копиям и служебному экрану разбора ошибок. Сроки хранения и удаления должны учитывать все копии данных, а не только карточку CRM.
Как принять интеграцию и затем находить сбой
Попросите исполнителя провести проверки на согласованных тестовых данных. Они не должны запускать звонки, рассылки и автоматические действия по реальным клиентам. Для итоговой проверки нужны подтверждения и на стороне сайта, и в фактически подключённой CRM.
- Обычная отправка. Сайт сохранил обращение; в CRM появился нужный объект с полями, внешним идентификатором и ответственным. Сотрудник открывает карточку и получает согласованное уведомление.
- Неполные данные. Сервер отклоняет недопустимые значения понятным сообщением. Отсутствие необязательного поля не мешает обработке.
- Повтор одной отправки. Двойное нажатие и повтор запроса с тем же ключом не создают вторую заявку на сайте. Отдельно проверяется защита на границе с CRM.
- Новое обращение того же человека. Оно обрабатывается по согласованному правилу, а не исчезает как технический дубль.
- Временная недоступность CRM. Заявка остаётся сохранённой, передача возобновляется по правилам, задержка видна ответственному.
- Запись создана, ответ потерян. Проверяется реальное поведение повтора или сверки. Если автоматическая защита невозможна, подтверждается предусмотренный ручной разбор.
- Остановка очереди, отзыв доступа и сбой уведомления. Каждая ситуация обнаруживается отдельно; восстановление не приводит к повторному созданию уже подтверждённого лида.
После запуска удобно смотреть список обращений, которые ещё не получили подтверждение CRM: сколько их, как давно они ожидают и какие требуют вмешательства. Допустимое время задержки и получателя сигнала определяет бизнес. Контроль должен замечать и остановленную очередь, при которой нет новых попыток и ошибок.
Когда сотрудник сообщает «заявки нет», начните с идентификатора обращения и последнего подтверждённого этапа. Проверьте запись на сайте, задание передачи, результат API и сохранённый идентификатор CRM. Если запись подтверждена, ищите её с учётом воронки, фильтров и прав сотрудника. Если результат неизвестен, сначала сверяйте CRM — кнопка «отправить заново» не должна становиться первым способом диагностики.
Для передачи проблемы разработчику достаточно времени обращения, формы, служебного идентификатора и состояния. Доступы передают безопасным согласованным способом, а персональные данные не прикладывают к общедоступной переписке. Цель в аналитике также не заменяет подтверждение CRM: это разные события. Их выбор описан в материале о целях Яндекс Метрики для сайта услуг.
Что включить в задачу исполнителю
Для интеграции сайта с CRM подготовьте названия форм, выбранную систему, таблицу полей, правила создания объектов и повторных обращений, условия согласий, сценарии ошибок и критерии приёмки. Возможности конкретной CRM и доступного интерфейса проверяют до оценки; название сервиса само по себе не подтверждает совместимость.
Если передача уже работает, но теряет поля, дублирует обращения или не показывает остановки, начните с проверки существующего маршрута. Доработка сайта может быть ограниченной задачей, когда причина и границы изменения установлены. В результате должно быть понятно, где хранится каждое принятое обращение, чем подтверждена его передача и кто разбирает незавершённые заявки.
