Заявка из Tilda в Битрикс24: как проверить сущность, поля и результат в CRM

Что должно появиться в Битрикс24

До настройки определите ожидаемый результат для конкретной формы:

• какая сущность является первой точкой обработки — лид или сделка;
• нужно ли создать или найти контакт и компанию;
• какие поля обязательны для менеджера;
• кто становится ответственным;
• в какую воронку и на какую стадию попадает обращение;
• как сохраняются форма, источник, рекламная кампания и UTM;
• что должно произойти при повторном обращении клиента.

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

Лид, сделка, контакт или компания

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

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

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

Поля и сопоставление данных

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

• имя, телефон и email;
• комментарий, услугу, город и бюджет;
• тему или название формы;
• источник и рекламные параметры;
• пользовательские поля, которые нужны менеджеру.

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

В Bitrix24 у элемента CRM есть стандартные поля, связи с контактами и компаниями, ответственный пользователь, UTM-поля и пользовательские поля. Это техническая возможность API, а не обещание, что штатная связка Tilda автоматически заполнит каждое поле. Фактическое сопоставление проверяется по конечной карточке.

Ответственный, воронка и стадия

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

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

Источник, UTM и дополнительные данные

Источник нельзя считать сохранённым только потому, что пользователь пришёл по рекламной ссылке. Сделайте тестовый переход с известными utm_source, utm_medium, utm_campaign и другими нужными параметрами. Отправьте форму и проверьте, в какие именно поля CRM они попали.

Если UTM, Client ID или referer нужны в собственной схеме, заранее определите, где они должны храниться: стандартное поле, пользовательское поле или отдельная обработка. Передача cookie или ответ Webhook не доказывают, что значение разобрано и записано в нужную карточку. Сравнивайте исходные данные Tilda, данные обработчика и конечный результат CRM.

Дубли и повторные обращения

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

Для повторного теста используйте тот же телефон или email и заранее определите ожидаемое поведение:

• новый лид;
• новая сделка;
• существующий контакт с новой активностью;
• обновление прежней записи;
• отказ от создания дубля;
• создание записи с привязкой к существующим контакту или компании.

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

Как принять результат интеграции

Проверяйте одну тестовую заявку от начала до конца:

1. В Tilda есть исходная заявка и подтверждён факт передачи.
2. В Битрикс24 найден ожидаемый тип сущности.
3. Зафиксирован ID карточки и время создания.
4. Заполнены обязательные и пользовательские поля.
5. Контакт и компания связаны корректно, если они нужны.
6. Ответственный, воронка и стадия соответствуют плану.
7. Источник и UTM видны в предусмотренных полях.
8. Повторный телефон/email дал ожидаемый результат по дублям.
9. Тест повторён для каждой значимой формы сайта.

Проверяйте карточку, а не только HTTP-ответ. Для Webhook Tilda ожидает доступный по HTTPS адрес обработчика и быстрый ответ 200. Это подтверждает приём запроса транспортом; правильный результат в CRM нужно дополнительно подтвердить по созданной или обновлённой сущности, полям и ID.

Если Tilda передала, а результата в CRM нет

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

Если Tilda подтверждает передачу, проверьте последовательно:

• выбранную сущность и режим CRM;
• права приложения, пользователя и ответственного;
• имя и формат каждого обязательного поля;
• наличие пользовательского поля и допустимое значение;
• фильтры, дату, стадию и ответственного при поиске;
• если используется Webhook, REST или собственный обработчик — ответ обработчика и ID, который он получил от Bitrix24;
• если используется REST или приложение — текст ошибки и код ошибки;
• не был ли тест отфильтрован как дубль.

Меняйте одну настройку за раз и используйте новый уникальный тест. Если используется Webhook, REST или собственный обработчик и приходит HTTP 200, но ID CRM не создан или карточка неполна, проблема находится уже после транспортного подтверждения — в сопоставлении полей, правах, сущности или бизнес-логике. Для штатной интеграции ориентируйтесь на фактическую карточку и доступные в портале сообщения, а не на технические данные собственного обработчика.

Когда нужен разработчик

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

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