SiteGuard4 ноября 202612 мин чтения

Заявки с сайта не попадают в CRM: как проверить создание лида

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

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

Найдите последний подтверждённый этап передачи

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

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

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

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

Воспроизведите одну заявку и сохраните её идентификатор

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

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

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

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

Проверьте, что обработчик действительно принял заявку

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

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

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

Сохраните собственные статусы, например «принята», «ожидает доставки», «результат неизвестен», «передана», «требует исправления». Это пример внутренней модели, а не стандарт Битрикс24. У каждого статуса должны быть проверяемое основание, ответственный за следующий шаг и правило обработки слишком долгого ожидания.

Проверьте портал, тип объекта и режим CRM

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

Уточните ожидаемый объект: лид, сделка, контакт или элемент смарт-процесса. В Битрикс24 метод crm.settings.mode.get различает классический режим с лидами и простой режим без лидов. Если бизнес работает со сделками и контактами, проверка только раздела лидов не соответствует его процессу.

В простом режиме созданный лид может сразу преобразоваться в сделку: такой результат описан в документации по лидам. Поэтому отсутствие карточки при чтении через crm.lead.get проверяйте вместе с режимом CRM и результатом конвертации, прежде чем объявлять заявку потерянной.

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

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

Сверьте авторизацию и права на создание и чтение

Для Битрикс24 определите способ подключения: входящий вебхук или приложение с авторизацией. Проверьте действующую конфигурацию на сервере, доступность нужного REST-функционала для портала и разрешения интеграции. Не используйте успешный вход администратора в браузере как доказательство прав отдельной учётной записи API.

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

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

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

Сопоставьте поля формы с форматом выбранного метода

Запишите таблицу соответствий: поле формы, нормализованное значение на сервере, поле CRM и правило обязательности. Для методов crm.lead.* описание полей возвращает crm.lead.fields. Проверяйте пользовательские поля, множественность, допустимые значения справочников и возможность записи, а не только видимые подписи карточки.

Разные семейства методов используют разные имена. В актуальном официальном примере с crm.item.add лид задаётся через entityTypeId: 1, используются camelCase и массив fm. У crm.lead.add поля вроде TITLE, PHONE и EMAIL имеют другой формат. Не смешивайте фрагменты этих контрактов при исправлении существующей интеграции.

В документации crm.lead.add отмечен как метод с остановленным развитием. Для новой интеграции используйте crm.item.*; приведённые ниже примеры crm.lead.add и crm.lead.get помогают проверить уже существующее подключение. Менять его во время диагностики без проверки всего контракта не требуется.

Следующий JSON иллюстрирует только набор параметров для crm.lead.add. Это не команда отправки и не универсальный полный набор обязательных полей вашего портала. Адрес почты и клиент вымышлены.

{
  "fields": {
    "TITLE": "Тестовая заявка web-149-0042",
    "NAME": "Тестовый клиент",
    "EMAIL": [
      { "VALUE": "lead-test@example.invalid", "VALUE_TYPE": "WORK" }
    ],
    "ORIGINATOR_ID": "site-demo",
    "ORIGIN_ID": "web-149-0042"
  }
}

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

Сохраните ответ API и подтвердите объект по ID

Обработчик должен разбирать HTTP-статус и тело ответа CRM, а не только факт завершения сетевой функции. Сохраните безопасную категорию результата и код ошибки. Проверяйте наличие полей ошибки: у crm.lead.add поле error может быть пустым, хотя error_description описывает отказ. Проверка только непустой строки error способна пропустить такой результат.

Для успешного вызова crm.lead.add документация показывает идентификатор в result. Сокращённый учебный ответ выглядит так:

{ "result": 90217 }

Сохраните связь web-149-0042 → 90217 в своей системе. Для другого метода извлекайте ID по его контракту: у crm.item.add объект находится в result.item. Ни ответ 200 от сайта посетителю, ни любой непустой JSON не заменяют проверки правильного результата создания.

Затем прочитайте карточку. Для выбранного в примере семейства методов используется crm.lead.get с полученным ID. Сверьте связь с заявкой, контактные данные, ответственного и значимые пользовательские поля. Отказ чтения требует проверки доступа; он не доказывает, что предыдущий вызов ничего не создал.

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

Проверьте, почему созданный лид не виден менеджеру

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

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

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

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

Разберите лимиты и зависшие попытки доставки

Сбой может проявляться только в часы рекламы, когда несколько форм или интеграций одновременно обращаются к CRM. В документации лимитов Битрикс24 различаются ограничения интенсивности и ресурсоёмкости облачной версии. Для коробочной версии проверьте настройки сервера и модуля REST: параметры облака нельзя автоматически переносить на свой портал. В частности, QUERY_LIMIT_EXCEEDED связан с интенсивностью и статусом 503, а OPERATION_TIME_LIMIT — с накопленным временем метода и статусом 429.

Не считайте любую ошибку 503 доказательством лимита: нужен код ответа конкретного API. Сохраните его вместе со временем, методом и номером попытки. Для временного ограничения применяйте контролируемое ожидание согласно документации и полученным указаниям сервиса. Ошибка обязательного поля или доступа не исправится от сотни одинаковых повторов.

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

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

Не превращайте таймаут в повторное создание

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

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

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

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

Пример: лид создан, но сайт сохранил неизвестный результат

Рассмотрим учебную ситуацию. Сервер сохранил заявку web-149-0042 и отправил её в CRM. Вызов завершился таймаутом, поэтому локальный статус остался «результат неизвестен». Менеджер дополнительно сообщил, что не видит обращение в списке своих лидов. Эти два наблюдения ещё не подтверждают потерю заявки.

Проверка	Учебный результат	Действие
Локальная запись	Заявка и внешняя метка сохранены	Использовать эту связь для сверки
Разрешённый поиск в нужном портале	Найден один кандидат с ID 90217	Прочитать его и проверить данные
Чтение карточки	Заявка совпадает, назначен другой сотрудник	Сохранить CRM-ID и проверить правило назначения
Проверка менеджером	Фильтр показывал только его обращения	Согласовать доступ и рабочее представление

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

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

Как принять исправление передачи заявок в CRM

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

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

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

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