Подключение Tilda к RetailCRM: заявки и сделки автоматом

Ты уже платишь за рекламу, трафик на сайт идёт, формы на Tilda заполняются. Но между моментом, когда человек нажал «Отправить», и моментом, когда менеджер реально начал с ним работать, — ручной труд, копипаст и потери. Этот гайд — практический маршрут от «заявка упала на почту» до «менеджер получил задачу в RetailCRM автоматически». Никакой теории: только то, что мы сами настраивали десятки раз для реальных магазинов и сервисных бизнесов.

Вы понимаете, что именно сломано в текущей схеме

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

Конкретно рвётся цепочка в трёх местах. Первое — задержка: менеджер проверяет почту раз в 30–60 минут, а скорость первого контакта напрямую влияет на конверсию. По нашей практике, звонок в первые 5 минут после заявки даёт конверсию в 3–5 раз выше, чем звонок через час. Второе — ручной ввод: человек копирует имя, телефон, комментарий. Опечатки, пропущенные поля, «потом занесу» — это не проблема конкретного менеджера, это архитектура, которая делает ошибку неизбежной. Третье — потеря контекста: UTM-метки, страница, с которой пришёл лид, скрытые поля формы — всё это просто не попадает в CRM, потому что менеджер переносит только то, что видит.

У наших клиентов часто оказывается, что 10–15% заявок вообще не доходят до CRM — они просто теряются в почте или дублируются. Это не ощущение, это видно при первом же аудите: сравниваем количество отправок формы в Tilda Analytics и количество сделок в CRM за тот же период. Разрыв почти всегда есть.

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

Вы выбрали способ подключения под свою ситуацию

Есть три реальных пути. Каждый подходит под разные ситуации, и у каждого есть честные ограничения.

Вариант 1 — нативный вебхук Tilda → RetailCRM напрямую. Tilda умеет отправлять данные формы на любой URL по HTTP POST. RetailCRM принимает такие запросы через встроенный обработчик. Настройка занимает 1–2 часа, не требует сторонних сервисов и ничего не стоит дополнительно. Подходит, если у тебя одна-две формы, простая структура данных и не нужна сложная логика. Ограничение: никакой трансформации данных «на лету» — что Tilda отправила, то и пришло.

Вариант 2 — через прослойку Make или n8n. Между Tilda и RetailCRM встаёт сервис автоматизации, который принимает вебхук, обрабатывает данные и уже в нужном формате передаёт в CRM. Это даёт гибкость: можно обогащать данные, маршрутизировать по воронкам, добавлять условия. Make стоит от $9/месяц, n8n можно поднять самостоятельно. Подходит, когда нужен маппинг UTM, несколько воронок или дополнительная логика. На нашей практике — это самый частый выбор для бизнесов с 50+ заявками в месяц.

Вариант 3 — готовые коннекторы. Есть несколько платных сервисов, которые предлагают визуальную настройку связки Tilda–RetailCRM. Быстро, без кода, но ты зависишь от третьего сервиса, платишь абонентку, и гибкость ограничена тем, что предусмотрел разработчик коннектора. Подходит, если нужно запустить за день и нет технического ресурса вообще.

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

Вебхук настроен и заявка дошла до CRM

Разберём базовую связку по шагам — нативный вебхук без прослоек.

Шаг 1 — получи URL вебхука в RetailCRM. Зайди в настройки: Администрирование → Интеграции → Веб-хуки. Создай новый вебхук, выбери событие «Создание заказа» или «Создание клиента» — зависит от того, что ты хочешь создавать при входящей заявке. Система выдаст тебе URL вида https://твой-домен.retailcrm.ru/api/v5/... с токеном. Скопируй его.

Шаг 2 — пропиши URL в Tilda. Открой нужную форму в редакторе Tilda, перейди в настройки формы (иконка шестерёнки), найди раздел «После отправки» → «Вебхук». Вставь URL из RetailCRM. Сохрани и опубликуй страницу — важно именно опубликовать, иначе изменения не применятся.

Шаг 3 — проверь, что данные пришли. Отправь тестовую заявку с формы (используй реальные данные, не «test test»). В RetailCRM зайди в Администрирование → Логи → Входящие вебхуки — там должна появиться запись с телом запроса. Если записи нет — вебхук не отправился, смотри настройки формы. Если запись есть, но заявка не создалась — смотри на код ответа и сообщение об ошибке.

У клиентов чаще всего ошибка в кодировке кириллицы: поля с именем или комментарием приходят в виде кракозябр. Причина — Tilda иногда отправляет данные в кодировке, отличной от UTF-8, особенно если форма старая. Решается либо пересозданием формы, либо обработкой на стороне прослойки. Если видишь в логах «%D0%98%D0%B2%D0%B0%D0%BD» вместо «Иван» — это оно.

Заявка превращается в сделку с нужными полями, а не в мусор

Дефолтный вебхук от Tilda передаёт «плоскую» структуру: все поля формы приходят как строки без типизации. RetailCRM ожидает данные в определённом формате — имя клиента в одном поле, телефон в другом, заказ отдельно. Если просто подключить вебхук напрямую, заявка создастся, но половина данных окажется либо не в тех полях, либо вообще потеряется.

Что маппить в первую очередь:

• Телефон — убедись, что поле типа «Телефон» в Tilda передаётся в поле phone клиента в RetailCRM, а не в комментарий к заказу.
• Имя — аналогично, должно попасть в firstName или lastName, а не в произвольное текстовое поле.
• UTM-метки — по умолчанию не передаются вообще. Нужно добавить в форму Tilda скрытые поля (utm_source, utm_medium, utm_campaign) с автозаполнением из URL, и прописать их маппинг в RetailCRM в раздел «Источник заказа».
• Страница или продукт — если у тебя несколько лендингов, добавь скрытое поле с названием страницы. Это позволит в CRM сразу видеть, с какого оффера пришёл лид.

На нашей практике, без правильного маппинга UTM бизнес через 2–3 месяца не может ответить на вопрос «какая рекламная кампания даёт продажи» — данные есть в рекламных кабинетах, но не связаны с реальными сделками в CRM. Это делает сквозную аналитику невозможной. Подробнее о том, как мы выстраиваем интеграции CRM под аналитику, читай на странице интеграций RetailCRM, а варианты подключения самой Тильды — в каталоге интеграций Tilda.

Если используешь прослойку (Make или n8n), маппинг настраивается визуально: перетаскиваешь поля из входящего запроса в нужные поля API RetailCRM. Это занимает 30–60 минут, но даёт полный контроль над тем, что куда попадает.

Менеджер получает задачу, а не просто запись в базе

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

В RetailCRM есть встроенный механизм триггеров (Администрирование → Триггеры). При создании нового заказа можно автоматически: назначить ответственного менеджера по правилу (например, по источнику или по очереди), поставить задачу «Позвонить в течение 15 минут» с дедлайном, перевести заказ в нужный статус воронки, отправить уведомление в Telegram или на почту менеджера.

У наших клиентов часто оказывается, что без этого шага интеграция даёт +10% к порядку, но не к продажам. Менеджер видит новую запись в общем списке — но среди 20 других записей она не выделяется, дедлайна нет, приоритет непонятен. Задача с дедлайном — это другая история: она красная, она мигает, её нельзя не заметить.

Настройка триггера занимает 20–30 минут. Минимальный рабочий вариант для 2026 года: новый заказ → назначить ответственного → создать задачу «Первый контакт» с дедлайном +15 минут → уведомление в мессенджер. Это не автоматизация ради автоматизации — это разница между конверсией 8% и 15% на одном и том же трафике.

Вы знаете, что интеграция работает, а не «должна работать»

Интеграция — это не «настроил и забыл». Это живая связь между двумя системами, каждая из которых обновляется. И если что-то сломалось, ты хочешь узнать об этом через 5 минут, а не через две недели.

Минимальный набор проверок после запуска:

1. Тестовая заявка в день запуска — отправь с реальными данными, проверь что в RetailCRM создался заказ с правильными полями, назначен ответственный, поставлена задача.
2. Лог вебхуков раз в неделю первый месяц — Администрирование → Логи. Смотри на ошибки и коды ответов. Норма — код 200. Всё остальное требует внимания.
3. Алерт на пустоту — если у тебя обычно 5+ заявок в день, а за 4 часа не пришло ни одной, это повод проверить интеграцию, а не радоваться тишине. Можно настроить простое уведомление через Make: если за X часов нет новых заказов — слать алерт в Telegram.

Классическая ситуация из нашей практики: Tilda выпустила обновление редактора, клиент пересохранил форму — и вебхук слетел или начал слать поля с другими именами. Никто не заметил 12 дней. За это время потеряли около 40 заявок. После этого случая мы всегда рекомендуем настраивать алерт на отсутствие новых заказов — это занимает 15 минут и спасает от таких ситуаций.

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

FAQ

Можно ли подключить Tilda к RetailCRM без программиста?

Базовую связку через вебхук — да, самостоятельно за 1–2 часа по этому гайду. Но как только нужен маппинг UTM-меток, несколько форм с разной логикой или условная маршрутизация по воронкам — без технического человека начинаются потери данных. Не потому что сложно, а потому что ошибки в таких настройках не видны сразу — они тихо съедают данные неделями.

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

Чаще всего две причины: поля в форме Tilda названы иначе, чем ожидает RetailCRM, или используются кастомные поля без явного маппинга. Диагностика простая — открой лог входящего вебхука в RetailCRM и посмотри на сырое тело запроса. Там будут видны все ключи и значения, которые реально пришли. Сравни с тем, что должно было прийти.

UTM-метки с рекламы попадают в RetailCRM автоматически?

Нет, не по умолчанию. Tilda умеет передавать UTM в скрытых полях формы — но эти поля нужно явно добавить в форму и настроить автозаполнение из параметров URL. После этого нужно прописать маппинг на стороне RetailCRM или в прослойке. Без этого шага сквозная аналитика «реклама → продажа» невозможна.

Что делать, если у нас несколько форм на разных страницах Tilda?

Каждая форма настраивается отдельно — вебхук прописывается на уровне конкретной формы, не всего сайта. При 5 и более формах удобно вести простой реестр: форма → страница → источник → ответственный в CRM → статус воронки. Это экономит время при отладке и помогает не запутаться при обновлениях.

Сколько времени занимает полноценная настройка интеграции?

Базовая связка «заявка → сделка» — 2–4 часа самостоятельно, если следовать гайду. Полноценная интеграция с UTM, несколькими воронками, автозадачами, алертами и тестированием — реально 1–2 рабочих дня с опытом. Без опыта — дольше, потому что большая часть времени уходит на отладку маппинга и поиск ошибок в логах.

Что дальше

По этому гайду можно собрать рабочую интеграцию самостоятельно — и это честно. Базовая связка «форма → заявка → задача менеджеру» собирается за несколько часов и уже даёт результат: нет потерь, нет ручного переноса, менеджер реагирует быстро.

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

Можно начать с консультации — просто расскажи, как устроена твоя текущая схема и что хочешь получить на выходе. Смотри, что мы умеем, на странице интеграции RetailCRM — там же можно оставить заявку. А если магазин в RetailCRM ещё не настроен, начни с гайда по настройке RetailCRM с нуля.