Тильда CRM: какие связки не теряют заявки

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

Как Тильда передаёт заявки в CRM: формы, вебхуки и список лидов

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

Третий канал, который и делает Тильду CRM-совместимой, это раздел настроек с прямыми интеграциями CRM-систем плюс отдельная опция «Вебхук» в настройках формы. Вебхук отправляет POST-запрос с данными отправки на любой указанный URL, и это самый гибкий вариант, потому что принимать данные может что угодно: обработчик на вашем хостинге, сценарий в n8n или Albato, серверная функция CRM. Для интернет-магазина на Тильде отдельно работает обмен по CommerceML, через него синхронизируются товары, цены, остатки и заказы с 1С, это уже не про лиды, а про товарные данные, но при связке с CRM про этот канал тоже не стоит забывать, если CRM смотрит в ту же базу 1С.

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

Готовые интеграции Тильды с CRM: amoCRM, Bitrix24, Мегаплан

В настройках проекта Тильда даёт прямое подключение к нескольким популярным CRM без вебхуков и промежуточных сервисов. Для amoCRM это авторизация через аккаунт и выбор, какие формы и какая воронка получают новые лиды, при отправке формы в amoCRM создаётся сделка и контакт, источник помечается как Тильда. Для Bitrix24 понадобится входящий вебхук из раздела интеграций самого Bitrix24, его URL вставляется в настройки Тильды. Полный список приёмщиков данных задан в справке: «В настройках сайта вы выбираете один (или несколько) из 24 сервисов, заполняете необходимые поля и активируете сервис», и из CRM в нём есть Tilda CRM, AmoCRM, Мегаплан, Битрикс24, Monday.com, Pipedrive, Zoho CRM, Hubspot и Salesforce. RetailCRM среди штатных сервисов Тильды нет, её подключают только вебхуком или через промежуточный сервис.

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

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

Webhook и n8n: связка Тильды с CRM, которых нет в списке

Если нужная CRM не входит в список готовых интеграций Тильды, или логика передачи сложнее, чем «поле в поле» (например, нужно посчитать сумму заказа, подставить менеджера по региону, отправить дубль в мессенджер), вебхук заводят на промежуточный сервис. Я обычно собираю такие сценарии в n8n: он принимает вебхук от Тильды, разбирает поля, обращается к API нужной CRM и при необходимости параллельно шлёт уведомление в Telegram через бота на aiogram, чтобы менеджер увидел заявку даже если основная CRM в этот момент недоступна.

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

Заказы, оплата и CRM: эквайринг, СДЭК и статусы сделок

Для интернет-магазина на Тильде связка с CRM почти всегда завязана на оплату. В настройках платёжных систем Тильда поддерживает несколько провайдеров эквайринга, в том числе Т‑Банк, и после успешной оплаты заказу присваивается статус прямо в интерфейсе Тильды. Проблема в том, что готовая интеграция с CRM обычно передаёт заказ в момент создания, а не в момент смены статуса на «оплачен» или «отправлен». Если менеджеру важно видеть в CRM именно оплаченные заказы отдельно от брошенных корзин, этот момент нужно закрывать вебхуком на смену статуса заказа, а не рассчитывать, что готовый коннектор сам всё досинхронизирует.

С доставкой похожая история: СДЭК подключается в Настройки сайта → Доставка → CDEK по идентификатору и секретному ключу клиента, а стоимость считается по тарифам перевозчика («Для каждой настроенной доставки (тарифа) мы запрашиваем отдельно стоимость отправки»). Зон в этой настройке нет: под разные тарифы или города создаются отдельные варианты доставки. Яндекс Доставка подключается там же отдельным сервисом, ей нужен токен авторизации из профиля сервиса. И то и другое работает без js-виджета и без правок кода в head, поэтому стоимость и способ доставки уходят в CRM вместе с заказом штатными средствами. Кастомные зоны доставки с нестандартной логикой тарификации я закрываю уже отдельным скриптом, но это скорее исключение, чем правило.

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

Где теряются заявки при связке Тильды и CRM

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

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

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

Универсальное решение, которое я ставлю почти на каждый проект с вебхуками, простое: до пересылки данных в CRM сохранять сырой вебхук на своей стороне. Обработчик на PHP принимает запрос, пишет его в таблицу MySQL или в файл лога, и только потом обращается к API CRM. Важная деталь: тело вебхука Тильды это не JSON, а обычные поля формы, «Чтобы получить все поля и значения без изменений нужно обратиться к переменной $_POST», причём часть символов приходит экранированной и разворачивается через urldecode. Если CRM в этот момент недоступна, заявка не теряется, её видно в логе и можно переотправить.

<?php
$payload = file_get_contents('php://input');
$data = array_map('urldecode', $_POST);

file_put_contents(
    __DIR__ . '/leads.log',
    date('c') . ' ' . $payload . PHP_EOL,
    FILE_APPEND
);

// далее $data проверяется и передаётся в CRM через её API

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

Кастомный скрипт: интеграция Тильды с CRM без готового коннектора

Если CRM самописная или редкая, готового коннектора у Тильды для неё нет, и тут два рабочих варианта: собрать сценарий в no-code инструменте вроде n8n, о котором писал выше, или написать обработчик под конкретный API CRM руками. Второй вариант оправдан, когда логика нетривиальная: нужно матчить заявку с существующим клиентом по нескольким полям, распределять лиды по менеджерам по правилам, которые не выразить в конструкторе сценариев, или писать сразу в несколько систем одним вызовом.

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

Условия и возможности Тильды меняются, поэтому перед запуском я уточняю их у самого сервиса.

Частые вопросы

Какую CRM проще всего подключить к Тильде без программиста?

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

Что делать, если заявки из Тильды приходят, а в CRM их нет?

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

Нужен ли отдельный сервер для связки Тильды и CRM?

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

Можно ли синхронизировать не только заявки, но и статусы заказов после оплаты?

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