Сбор заявок с квизов в CRM: как не терять лиды

Квиз собирает контакты, но если заявка падает только на почту менеджера или зависает в личном кабинете конструктора, отдел продаж узнаёт о клиенте на следующий день - а то и не узнаёт вовсе. Сбор заявок с квизов в CRM - это не галочка «интеграция подключена» в настройках сервиса, а конкретная техническая цепочка: вебхук с квиза, обработчик на сервере, поля карточки сделки, ответственный менеджер и уведомление, которое реально дойдёт. За последние пару лет я настраивал такие связки для интернет-магазинов и услуговых сайтов на Tilda и WordPress, и примерно в половине случаев заказчик приходил уже после того, как терял заявки месяц-два подряд - просто никто не проверял, доходят ли они до CRM в принципе.

Почему заявки из квиза не долетают до CRM

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

Конструктор квиза отправляет данные только на email, а письма падают в спам или теряются при смене почтового домена.
Встроенная интеграция с CRM подключена, но настроена на тестовую воронку или устаревший API-ключ, который отозвали полгода назад.
Вебхук отправляется один раз без повторных попыток - если CRM в момент отправки была недоступна 3-5 секунд, заявка просто исчезает.
UTM-метки и ответы на вопросы квиза не прокидываются в карточку сделки, и менеджер видит голый телефон без контекста, зачем человек оставил заявку.
Поля квиза и поля CRM не совпадают по типу - телефон приходит с плюсом, а в CRM ждут его без плюса, и запись не создаётся из-за ошибки валидации.

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

Как устроена передача данных из квиза в CRM технически

Схема всегда одна, независимо от того, на чём собран квиз - Marquiz, Envybox, Testograf или самописная форма на Tilda:

Пользователь отвечает на вопросы и отправляет форму.
Квиз формирует JSON с ответами, контактами и метаданными страницы и отправляет POST-запрос на указанный URL вебхука.
Обработчик на вашей стороне (это может быть serverless-функция, скрипт на сервере или нода в n8n) принимает запрос, валидирует и нормализует поля.
Обработчик обращается к API CRM - создаёт контакт и сделку, привязывает ответственного, проставляет источник и UTM.
Опционально - дублирует уведомление в Telegram или мессенджер, чтобы менеджер увидел заявку сразу, а не когда откроет CRM.

Типичный payload от квиза выглядит примерно так:

{
  "name": "Ирина",
  "phone": "+79261234567",
  "answers": {
    "Какой бюджет?": "от 100 000 ₽",
    "Когда нужен результат?": "в течение месяца"
  },
  "utm_source": "vk",
  "utm_campaign": "quiz_leadgen",
  "page_url": "https://example.ru/quiz"
}

Задача обработчика - превратить это в понятную карточку сделки: имя и телефон в стандартные поля, ответы на вопросы - в отдельное текстовое поле или тело задачи для менеджера, UTM - в поле источника, чтобы в отчётах по рекламе не было прочерков.

Сравнение способов подключения квиза к CRM

На практике есть четыре рабочих варианта, и выбор зависит от того, сколько у вас источников трафика и насколько нестандартные поля нужно передавать.

Способ	Скорость настройки	Гибкость полей	Риски
Встроенная интеграция конструктора (Marquiz, Envybox)	15-30 минут	Низкая - только стандартный набор	Молчаливые сбои при смене API CRM
Zapier / Make	1-2 часа	Средняя	Лимиты бесплатного тарифа, задержки до минуты
n8n на своём сервере	3-6 часов	Высокая - любая логика и условия	Нужен сервер и человек, который его поддерживает
Кастомный вебхук-обработчик	1-2 дня	Максимальная	Требует разработки и тестирования

Встроенную интеграцию я оставляю, когда у клиента один квиз, одна воронка и нет задачи собирать нестандартные ответы. Как только появляется второй квиз, несколько источников трафика или нужно считать конверсию по вопросам - перехожу на n8n или отдельный обработчик, потому что там можно логировать каждый запрос и видеть, где заявка потерялась.

Бесплатный материал

🎁 Полезный скрипт в подарок

Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.

Получить в Telegram →

Без спама. Отписка в 1 клик.

Интеграция квиза на Tilda с amoCRM и Bitrix24 через вебхуки

Tilda-квизы (в том числе встроенный блок T‑Quiz) отправляют данные формы через свой webhook-механизм в разделе «Формы» - это отдельная настройка от блока с зашитыми интеграциями, и именно её чаще всего забывают проверить после переноса сайта на новый домен. URL вебхука указывается один раз в настройках формы, но если конструктор квиза меняет способ подписи запроса или структуру JSON после обновления, старый обработчик перестаёт понимать данные - и заявки продолжают «уходить», просто в CRM ничего не появляется.

Для Tilda я обычно пишу отдельный скрипт-прослойку: он принимает вебхук, приводит номер телефона к единому формату, ищет дубли по телефону за последние 24 часа (чтобы повторный клик по квизу не плодил вторые сделки) и уже потом создаёт лид в amoCRM или Bitrix24 через их REST API. Готовые примеры таких обработчиков для Tilda я собираю в библиотеке скриптов - часть логики оттуда закрывает 70% типовых кейсов без переписывания с нуля.

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

Что передавать в карточку сделки, кроме имени и телефона

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

все ответы на вопросы квиза одним текстовым блоком в примечании к сделке;
UTM-метки в отдельные поля источника, а не единой строкой;
URL страницы, с которой пришла заявка, если квизов на сайте несколько;
время прохождения квиза - если человек ответил за 20 секунд, не читая вопросов, это часто боты или случайные клики, и такие лиды стоит помечать отдельно.

Резервный канал: дублирование заявок в Telegram через aiogram-бота

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

async def notify_manager(lead: dict, deal_url: str):
    text = (
        f"Новая заявка с квизаn"
        f"Имя: {lead['name']}n"
        f"Телефон: {lead['phone']}n"
        f"Сделка: {deal_url}"
    )
    await bot.send_message(chat_id=MANAGERS_CHAT_ID, text=text)

Это не замена CRM, а страховка на случай, если API CRM временно недоступен или сделка ушла не в ту воронку - сообщение в чате всё равно останется, и заявку можно будет найти вручную. Разработка такого бота с интеграцией в существующую цепочку обычно стоит от 30 000 ₽.

Автоматизация в n8n: сценарии и типичные ошибки

Когда квизов несколько или нужно вести условную логику («если бюджет выше 200 000 ₽ - ставить сделку в приоритетную воронку и назначать старшего менеджера»), я собираю цепочку в n8n на своём сервере, а не на облачном тарифе стороннего сервиса. Стандартный сценарий: Webhook-нода принимает запрос от квиза → Switch-нода разводит лиды по условиям → HTTP Request-ноды создают сделку в CRM и отправляют уведомление в Telegram → Error Trigger ловит сбои и пишет их в отдельный лог-канал.

Ошибки, которые я регулярно исправляю в чужих сценариях:

нет обработки ошибок API CRM - если сервис на секунду недоступен, workflow просто падает молча, и заявка теряется без следа;
нет проверки на дубли - один и тот же человек, прошедший квиз дважды, создаёт две сделки, и статистика конверсии искажается;
нет логирования входящих запросов - когда клиент говорит «я оставлял заявку, а мне не перезвонили», проверить это нечем;
вебхук квиза указывает напрямую на продакшн-CRM без тестового окружения, и любая правка сценария рискует сломать боевой поток лидов.

Настройка такой цепочки в n8n с обработкой ошибок и дедупликацией стоит от 25 000 ₽ - и это разумная страховка, если стоимость привлечения одного лида с квиза выше пары тысяч рублей: одна потерянная заявка из десяти уже съедает часть бюджета на рекламу.

Чек-лист: как убедиться, что заявки с квиза не теряются

Раз в неделю сверяйте число завершённых прохождений квиза (в статистике конструктора) с числом новых сделок в CRM.
Проверьте, что вебхук настроен на актуальный URL после любого переноса сайта или смены домена.
Убедитесь, что обработчик логирует входящие запросы отдельно от факта создания сделки - так видно, где именно рвётся цепочка.
Настройте повторную отправку (retry) хотя бы на 2-3 попытки при недоступности API CRM.
Не храните контакты клиентов из квиза в зарубежных облачных таблицах - под персональные данные нужен сервер, физически размещённый в РФ, это требование 152-ФЗ, а не рекомендация для перестраховки.
Раз в месяц отправляйте тестовую заявку и проверяйте весь путь вручную - от кнопки в квизе до уведомления менеджеру.

Связка сервисов без программистов

Автоматизация / n8n

от 25 000 ₽

Подробнее →

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

Можно ли обойтись встроенной интеграцией квиза без отдельного вебхук-обработчика?

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

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

Большинство CRM позволяют создавать пользовательские поля через админку или API - под ответы квиза я обычно завожу текстовое поле в карточке сделки или примечание, куда попадает весь блок вопросов и ответов одним текстом. Это проще, чем заводить отдельное поле под каждый вопрос квиза, особенно если вопросы периодически меняются.

Можно ли хранить заявки с квиза в Google Таблицах для отчётности?

Для черновой аналитики без персональных данных - да, но телефоны, имена и другие контакты клиентов нужно хранить на сервере, размещённом в России, это требование локализации персональных данных по 152-ФЗ. Иностранные облачные таблицы для хранения контактов клиентов использовать не стоит - только для агрегированных цифр без привязки к конкретному человеку.

Сколько стоит настроить передачу заявок с квизов в CRM?

Зависит от сложности: простая доработка вебхука для Tilda-квиза - от 3 000 ₽, комплексная интеграция с CRM, эквайрингом и внешними сервисами - от 40 000 ₽, автоматизация сценария в n8n с обработкой ошибок и дедупликацией - от 25 000 ₽, дублирующий Telegram-бот - от 30 000 ₽. Итоговая цена складывается из того, сколько источников и условий нужно свести в одну цепочку.