Туроператор: лиды с сайта и лендингов в CRM с UTM-метками и без дублей

Почему сквозная аналитика считала неверно и при чём тут тариф CRM?

В конце 2024 года клиент пришёл к нам со словами (здесь и дальше цитаты в переводе с украинского): «нам сказали, что лидов много, а аналитика неверная». Причина оказалась в тарифе: сквозная аналитика на нём работает только до определённого числа записей CRM (лидов, сделок, контактов и компаний вместе), а база туроператора этот предел превысила.

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

Как заявки с сайта на PrestaShop попадают в CRM лидом с UTM-метками?

До июня 2025 года заявки с основного сайта приходили на почту, и менеджер заводил их в CRM вручную. Метки терялись, а лиды в отчётах уходили в «другой трафик».

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

• без меток — SEO;
• utm_source facebook — таргетированная реклама;
• utm_source google — контекст; органику от контекста отдельный бизнес-процесс отличает по utm_medium (cpc или organic);
• звонок из телефонии Binotel получает источник, только если менеджер подтвердил сайт.

Как склеить несколько обращений одного человека за день в один лид?

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

• новый лид запускает исходящий вебхук onCrmLeadAdd;
• скрипт ищет совпадения среди лидов за текущие сутки, с 00:00;
• данные нового лида и его дела (звонки, письма, чаты) переносит в первый найденный лид;
• дубль удаляет.

Как видеть лиды отдельно по каждому лендингу и добавлять новые лендинги?

Кроме основного сайта, туроператор ведёт лендинги под отдельные направления и даты. Заявки с них клиент передавал в CRM своими силами, но посчитать лиды с конкретного сайта не мог. В июле 2025 года мы добавили в лиды поле «Источник (сайт)», которое бизнес-процесс заполняет по адресу сайта в названии лида. Лиды и сделки теперь фильтруются по сайту, источнику трафика, периоду и туру.

В 2026 году клиент начал каждую неделю запускать лендинги, сделанные с помощью ИИ. Их формы отправляли заявки в Formspree, а не в CRM. Мы настроили вебхук Formspree на наш обработчик, а в августе 2026 года переписали его на Windmill. Обработчик создаёт лид с именем, телефоном, сайтом и UTM-метками, сам добавляет новый лендинг в список «Источник (сайт)» и находит адрес в любом поле формы. Проверка на живом портале прошла без дублей, существующие значения списка не изменились. Клиенту на каждый новый лендинг остаётся два шага: скрытое поле с адресом сайта в форме и адрес обработчика в Formspree.

Что ещё мы настроили в CRM туроператора?

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

Это было сервисное сопровождение: пакеты часов под конкретные запросы, без большого проекта внедрения. С декабря 2024 по август 2026 года на него ушло около 60 часов работы наших специалистов.