Заявка с лендинга на Тильде падает в один telegram-чат, форма с корпоративного сайта на WordPress пишет менеджеру на почту, а в конце дня кто-то руками сводит всё в Excel и часть лидов теряется на стыке. CRM для Тильды и WordPress закрывает именно эту проблему: обе площадки отправляют заявки в одну систему, и по каждому лиду видна вся история независимо от того, с какого сайта он пришёл. Дальше показываю, как я собираю такую связку на практике: что настраиваю на Тильде, что меняю в формах WordPress и куда всё это стекается.
Почему две отдельные CRM для одной воронки не работают
На практике чаще всего вижу такую картину: рекламный лендинг крутится на Тильде, а основной корпоративный сайт или магазин на WordPress. У каждого сайта своя форма, свой набор уведомлений и часто своя записная система: где-то заявки падают в Google-таблицу, где-то в почту, где-то менеджер просто получает push в мессенджер и записывает имя в блокнот.
Проблема вскрывается не сразу. Сначала кажется, что два канала заявок это просто два источника лидов. Но когда отдел продаж работает с двумя разными списками, происходит стандартный набор потерь: заявка с Тильды не попадает в общую воронку и просто исчезает после закрытия вкладки с уведомлением; один и тот же клиент оставляет заявку на лендинге и на основном сайте, и менеджер звонит ему дважды с разным контекстом; никто не видит сквозную статистику, сколько лидов вообще пришло за месяц и с какого сайта конверсия выше.
Я веду один проект, где до объединения в CRM отдел продаж физически не видел часть заявок с Тильды: маркетолог получал их на почту и не всегда пересылал менеджерам. После того как обе формы завели в один amoCRM, число обработанных лидов выросло почти на треть без единого рубля в рекламу, просто за счёт того что заявки перестали теряться.
Как устроена связка технически: вебхуки, прослойка, CRM
Схема в большинстве случаев одна и та же. Тильда и WordPress по отдельности отправляют данные формы на один и тот же приёмник, это может быть сценарий в n8n, отдельный скрипт на сервере или готовый коннектор конкретной CRM. Приёмник приводит данные к общему виду (имя, телефон, email, источник, UTM-метки) и создаёт или обновляет сделку в CRM через её API. В одном из проектов такой приёмник параллельно с созданием сделки в Bitrix24 отправляет менеджеру сообщение в Telegram через aiogram-бота, и время до первого звонка клиенту сократилось с часа до нескольких минут.
Зачем нужна прослойка, а не прямая интеграция
Часть CRM позволяет принимать вебхук напрямую с Тильды или из плагина WordPress, без промежуточного сервиса. На небольших проектах я так и делаю. Но как только появляется вторая площадка, третий источник (например, заявки из телефонии или Telegram-бота) или нужно нормализовать телефон и отсеять тестовые заявки, прямое подключение начинает мешать: любое изменение формата данных на одной площадке требует переделывать логику во всех остальных местах.
Прослойка на n8n решает это иначе: у неё один сценарий с точками входа для каждого сайта и одной общей логикой на выходе. Она же удобна для дедупликации по телефону, для ретраев при недоступности CRM и для рассылки уведомления менеджеру в Telegram параллельно с созданием сделки.
Подключаю Тильду: вебхуки форм и нормализация полей
В настройках формы на Тильде есть блок «Вебхуки», туда добавляю URL приёмника, и после каждой отправки формы Тильда шлёт POST-запрос с данными: имя, телефон, email, название формы, адрес страницы и, если настроены скрытые поля, UTM-метки кампании.
Дальше в n8n принимаю этот запрос и привожу телефон к единому формату, потому что Тильда отдаёт номер в том виде, в каком его ввёл посетитель, с восьмёркой, без кода страны, с пробелами.
const raw = items[0].json.phone || '';
const digits = raw.replace(/\D/g, '');
const phone = digits.length === 11 && digits[0] === '8'
? '7' + digits.slice(1)
: digits;
return [{
json: {
name: items[0].json.name,
phone: `+${phone}`,
email: items[0].json.email,
source: 'tilda',
utm_source: items[0].json.utm_source || null,
},
}];После нормализации сценарий ищет в CRM контакт по телефону и либо создаёт новую сделку, либо добавляет комментарий к существующей, это и есть та самая дедупликация, которая не даёт менеджеру звонить одному клиенту два раза от имени двух разных сайтов.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Подключаю WordPress к той же точке сборки
На WordPress формы чаще всего собраны на Contact Form 7 или Gravity Forms. У обоих есть возможность отправить данные во внешний вебхук: у Contact Form 7 через дополнительный плагин или хук wpcf7_mail_sent в functions.php, у Gravity Forms через встроенный аддон Webhooks.
Важно, чтобы данные из формы WordPress приходили в приёмник в той же структуре полей, что и с Тильды: имя, телефон, email, источник. Тогда логика создания сделки в CRM остаётся одна на оба сайта, и не приходится дублировать код нормализации телефона и дедупликации отдельно под каждую платформу.
Если на WordPress стоит WooCommerce и сайт что-то продаёт, туда же подключаю вебхуки заказов: новый заказ, оплата через T‑Bank, статус доставки от СДЭК. Всё это идёт в ту же CRM и привязывается к тому же контакту, что и заявка с формы, так менеджер видит не только заявку, но и историю покупок клиента в одном окне.
amoCRM, Bitrix24 или retailCRM: что выбрать под связку двух сайтов
Разница между системами не в том, что одна дружит с Тильдой, а другая с WordPress: вебхуки принимают все три. Разница в наборе встроенных возможностей и в том, под какую модель бизнеса система заточена изначально.
| CRM | Входящие вебхуки | Телефония | Кому подходит |
|---|---|---|---|
| amoCRM | Есть из коробки, простая настройка | Через виджеты интеграторов (Sipuni, Manzana и т.п.) | Небольшой отдел продаж, быстрый запуск воронки |
| Bitrix24 | Есть, плюс открытый REST API | Встроенная Bitrix24.Телефония | Компаниям, которым кроме CRM нужны ещё сайт, задачи и документы в одной системе |
| retailCRM | Есть, заточены под интернет-магазины | Интеграция через модули и коннекторы | Магазин на WooCommerce плюс лендинги на Тильде с отдельными акциями |
Данные клиентов при этом держу на серверах в РФ и выбираю CRM с российским хостингом инстанса, это не только вопрос удобства, а прямое требование 152-ФЗ о локализации персональных данных.
Сроки и стоимость интеграции на практике
Простая связка, вебхук с одной формы Тильды плюс вебхук с одной формы WordPress в готовую CRM без дополнительной логики, занимает 3-5 дней и по деньгам укладывается в стоимость кастомного скрипта для Тильды, от 3 000 ₽ за доработку самой формы плюс настройка приёмника.
Комплексная интеграция (несколько форм на обоих сайтах, нормализация и дедупликация контактов, привязка заказов WooCommerce, уведомления менеджерам в Telegram, синхронизация статусов доставки от СДЭК) это уже интеграция CRM, эквайринга и логистики под ключ, и такие проекты у меня стартуют от 40 000 ₽ и занимают от двух до трёх недель в зависимости от количества источников заявок.
Отдельно оцениваю сценарий в n8n, если он должен обслуживать не только связку CRM, но и другие процессы, от 25 000 ₽ за настройку автоматизации.
Частые ошибки при объединении Тильды и WordPress в одну CRM
Дедупликация по телефону без проверки формата, частая причина, когда две разные заявки склеиваются в одну сделку из-за того, что один номер пришёл с восьмёркой, а другой с плюс семь. Нормализация телефона должна стоять до, а не после сравнения контактов.
UTM-метки часто теряются именно на прослойке: скрипт передаёт в CRM имя и телефон, а source и campaign обрезает как не обязательное поле. В результате отдел маркетинга не может посчитать, какая кампания реально приносит сделки, хотя в CRM исправно капают лиды.
Тестовые заявки с формы разработки или staging-версии сайта долетают до боевой CRM, если вебхук не проверяет домен отправителя. На стадии тестирования подключения стоит держать отдельный тестовый сценарий и не привязывать его к рабочей воронке продаж.
Частые вопросы
Можно ли обойтись без n8n и слать вебхуки напрямую в CRM?
Да, если источник один и логика простая, можно указать URL CRM прямо в настройках вебхука Тильды или в плагине WordPress. Как только источников становится два и больше или нужна нормализация данных, прослойка экономит время на поддержке за счёт единой точки логики.
Что делать, если на Тильде и WordPress разные наборы полей в формах?
Привожу оба набора к общей схеме на уровне прослойки: обязательные поля (имя, телефон, источник), а всё остальное (город, комментарий, выбранный тариф) передаю дополнительными полями сделки в CRM, без потери данных, но и без жёсткой привязки логики к конкретной форме.
Нужно ли переносить историю старых заявок в новую CRM?
Зависит от того, где они лежат сейчас. Если заявки копились в Excel или Google-таблице, перенос делаю разовым импортом через API CRM, отдельно от настройки самих вебхуков, это другая по объёму задача и оценивается отдельно.
Что делать, если один клиент оставил заявки на обоих сайтах?
При правильной дедупликации по нормализованному телефону вторая заявка не создаёт новую сделку, а добавляется как событие к уже существующему контакту, и менеджер видит, что человек интересовался и через лендинг, и через основной сайт.