Разные CRM для форм на одном сайте Тильды: как настроить

Когда на сайте на Тильде висит десяток форм: заявка на консультацию, заказ звонка, регистрация на вебинар, обращение от дилера, отдел продаж быстро упирается в вопрос, куда всё это сыпать. Мне регулярно попадаются проекты, где нужны разные CRM для форм на одном сайте Тильда: заявки от частных клиентов летят в AmoCRM, обращения от партнёров в отдельную Bitrix24, а отклики на вакансии просто падают в Telegram-чат HR. Стандартная настройка Тильды такого не подразумевает: одна форма связывается с одной системой через панель интеграций. Расскажу, как обойти это ограничение и не переделывать логику заново каждый раз, когда на сайте появляется новая форма.

Почему одной CRM для всех форм Тильды недостаточно

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

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

Как Тильда передаёт данные форм и что можно с этим сделать

Каждый блок с формой в Тильде отправляет данные двумя путями. Первый: встроенные интеграции в настройках блока, там можно указать CRM, почту или мессенджер, куда пойдёт конкретно эта форма. Второй: вебхук в формате JSON, который Тильда отправляет на любой указанный URL при отправке формы. Во втором случае в теле запроса приходит name, phone, email, сам текст полей и, что важно для маршрутизации, formname и formid, то есть идентификатор конкретной формы и блока.

Именно formname и formid дают возможность построить логику «эта форма в AmoCRM, эта в Bitrix24, а эта в Telegram» на одном общем эндпоинте, не трогая настройки каждого блока по отдельности. Дальше вопрос только в том, где эту логику разместить: в самой Тильде через встроенные интеграции или на своём сервере через скрипт-роутер.

Способ 1: нативные интеграции Тильды по каждой форме

Самый быстрый путь: в панели управления сайтом Tilda зайти в раздел «Формы», выбрать конкретный блок и в настройках интеграций указать нужную CRM. Так можно привязать разные формы к разным системам буквально за 15-20 минут, без единой строчки кода. Работает для AmoCRM, Bitrix24, retailCRM и ещё нескольких сервисов из встроенного списка.

Ограничения у этого способа реальные. Список готовых интеграций закрытый, и если у клиента самописная CRM, Пачка, Мегаплан или что-то на базе 1С, встроенной кнопки для этого просто нет. Условной логики тоже нет: нельзя сказать «если сумма заказа больше 50 000 ₽, отправлять в отдел ключевых клиентов, иначе в общую воронку». И каждую новую форму приходится настраивать заново вручную, что для сайта с постоянно меняющимся набором лендингов быстро превращается в рутину.

Способ 2: скрипт-роутер, который сам решает, куда отправлять заявку

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

Простой пример роутера на Node.js, который принимает вебхук от Тильды и в зависимости от имени формы отправляет данные в разные CRM:

app.post('/tilda-webhook', async (req, res) => {
  const { formname, name, phone, email } = req.body;

  const routes = {
    'Форма заказа': process.env.AMOCRM_WEBHOOK,
    'Форма партнёра': process.env.BITRIX24_WEBHOOK,
    'Форма отклика на вакансию': process.env.TELEGRAM_WEBHOOK,
  };

  const target = routes[formname];
  if (!target) {
    console.error('Неизвестная форма:', formname);
    return res.status(200).send('ok');
  }

  await fetch(target, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ name, phone, email }),
  });

  res.status(200).send('ok');
});

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

Примеры маршрутизации: AmoCRM, Bitrix24, Telegram и n8n

На реальных проектах чаще всего встречается такая раскладка:

Отдельно стоит сказать про n8n. Вместо того чтобы писать и поддерживать свой сервер под роутинг, вебхук с Тильды можно завести прямо в n8n, а дальше нодой Switch развести поток по formname на нужные CRM-коннекторы, Telegram-ноду или HTTP-запрос в произвольную систему. Для несложных сценариев с 3-5 формами и 2-3 CRM это часто быстрее в поддержке, чем свой код, особенно если в команде нет постоянного разработчика, который будет обновлять скрипт при изменениях. У меня такая настройка через n8n обычно занимает 1-2 дня вместе с тестами на реальных заявках.

Частые ошибки при настройке нескольких CRM на одном сайте

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

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

Третья: контактные данные клиентов временно складывают во внешние облачные таблицы «для проверки», забывая, что персональные данные физлиц из РФ по 152-ФЗ нужно хранить на серверах внутри страны. Я держу такие промежуточные логи только на своих серверах в России, без исключений.

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

Можно ли в Тильде привязать разные CRM к разным формам без единого кода?

Частично да. Для форм, у которых нужная CRM есть в списке встроенных интеграций Тильды (AmoCRM, Bitrix24, retailCRM и ещё несколько), это настраивается через панель управления за 15-20 минут на форму. Если CRM самописная или список форм постоянно растёт, без скрипта-роутера или n8n уже не обойтись.

Сколько стоит настройка маршрутизации форм по нескольким CRM на Тильде

Простая доработка типа переименования полей или добавления скрытого идентификатора формы стоит от 3 000 ₽. Комплексная интеграция с несколькими CRM, эквайрингом или сторонними сервисами, включая написание и тестирование скрипта-роутера, стоит от 40 000 ₽ в зависимости от количества форм и систем, куда нужно завести данные.

Что делать, если Тильда поменяла структуру вебхука после обновления

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

Как быть, если одна форма должна попадать сразу в CRM и в Telegram

В роутере это решается без проблем: для нужной формы вызываются сразу два запроса, один в API CRM, второй в Telegram-бота через aiogram или прямой вызов Bot API. Если используете n8n, там просто добавляется вторая ветка после ноды Switch для той же формы, без изменения остальной логики.