Как связать Senler и Битрикс24: не просто передать заявку, а собрать маршрут клиента

Заявка из Senler может попасть в Битрикс24 за несколько минут. Но рабочая интеграция Senler и Битрикс24 начинается не с кнопки «подключить», а с вопроса: какое именно событие в боте должно стать сигналом для CRM?

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

Senler - это сервис для рассылок, подписок и чат-ботов во ВКонтакте. Битрикс24 - CRM, где отдел продаж ведёт лиды, контакты, сделки, задачи и историю общения. Связка нужна, когда человек взаимодействует с ботом или рассылкой в Senler, а бизнес хочет увидеть его в CRM: с телефоном, UTM-метками, ответами из бота и понятной стадией обработки.

Плохая связка выглядит так: «каждый новый подписчик → новый лид в CRM».

Хорошая связка выглядит иначе: «нужное событие в боте → проверка дубля → обновление контакта или создание сделки → передача UTM и ответов → постановка задачи менеджеру → обратный сценарий в Senler по стадии сделки».

Разница большая. В первом случае CRM быстро превращается в склад дублей. Во втором, появляется управляемый маршрут клиента от первого касания до продажи.

Что на самом деле нужно передавать из Senler в Битрикс24

У онлайн-школ, экспертов и проектов с трафиком из ВК обычно есть несколько микроворонок. Например:

1. Реклама ведёт в подписку Senler.
2. Бот выдаёт материал: чек-лист, тест, запись вебинара, мини-урок.
3. Человек отвечает на вопросы или оставляет телефон.
4. Менеджер должен получить заявку в Битрикс24.
5. После звонка сделка переходит на новую стадию.
6. Senler запускает дожим: напоминание, кейс, оффер, сообщение для тех, кто не купил.

Ошибка начинается там, где в CRM передают всех подписчиков подряд. В рассылке может быть 300 новых подписчиков за день, но реальных заявок на разговор 20. Если все 300 попадут в Битрикс24 как лиды, отдел продаж быстро перестанет доверять CRM.

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

Интеграция Senler и Битрикс24 должна начинаться не с передачи данных, а с выбора точки захвата. Если событие выбрано неправильно, CRM получает шум вместо лидов.

Тут полезно держать в голове техническую деталь. Senler обычно отдаёт наружу событие одного типа по сути «пришла регистрация/подписка», а различия «дошёл до шага», «нажал кнопку», «ответил так-то» выражаются не отдельными типами событий, а условиями по переменным и полям подписчика. Поэтому на практике «выбрать событие» почти всегда означает «поймать регистрацию и навесить на неё условие», а не найти отдельный готовый триггер под каждый клик.

Для маркетолога это вопрос аналитики. Для руководителя продаж вопрос нагрузки на менеджеров. Для техспеца вопрос архитектуры сценария.

Что создавать в Битрикс24: лид, контакт или сделку

В Битрикс24 можно создать лид, контакт, сделку, задачу, дело или обновить уже существующую карточку. Универсального ответа нет, потому что структура зависит от процесса продаж.

Для простой воронки чаще подходит лид. Например, человек из Senler оставил телефон на консультацию, но ещё непонятно, кто он, какой курс ему нужен и готов ли он покупать. Лид удобен как входящая заявка: менеджер обработал, квалифицировал, дальше конвертировал в контакт и сделку.

Для повторных касаний лучше использовать контакт + сделку. Если человек уже есть в базе, новая заявка из Senler не должна создавать второго Ивана Петрова. Правильнее найти существующий контакт по телефону или email, обновить поля и создать новую сделку в нужной воронке.

Для онлайн-школ часто работает такая логика:

Событие из Senler	Что делать в Битрикс24
Новая подписка на лид-магнит	Не всегда создавать лид. Иногда достаточно сохранить в сегмент или передать в аналитику
Пользователь оставил телефон	Создать лид или контакт + сделку
Пользователь выбрал интересующий курс	Записать курс в пользовательское поле сделки
Пользователь пришёл с конкретной рекламы	Передать UTM в поля лида/сделки
Пользователь повторно запросил консультацию	Найти контакт и создать новую сделку, а не дубль контакта

У CRM-интеграторов здесь появляется главный вопрос: что считать уникальным идентификатором. Телефон? Email? У одного и того же человека может быть новый телефон, другой email или несколько подписок, поэтому схема «ищем только по телефону» иногда ломается, надёжнее искать сразу по нескольким полям. С VK ID есть отдельный нюанс: в Битрикс24 нет нативного поля под него и нет поиска по нему «из коробки». Чтобы использовать VK ID как ключ, его заводят отдельным пользовательским полем и ищут уже по этому полю.

Карта данных: что из Senler куда класть в Битрикс24

Карта данных нужна до настройки. Без неё связка обычно запускается «на глаз»: имя положили в имя, телефон в телефон, остальное куда-нибудь в комментарий. Через месяц оказывается, что UTM не участвуют в отчётах, ответы из бота не видны менеджеру, а источник заявки называется одинаково для всех.

Минимальная карта может выглядеть так:

Данные из Senler	Куда передавать в Битрикс24	Зачем
Имя подписчика	Имя контакта или лида	Чтобы менеджер видел нормальную карточку
Телефон	Телефон контакта/лида	Основной ключ для звонка и поиска дублей
Email	Email контакта/лида	Дополнительный ключ и канал связи
VK ID / ссылка на профиль	Пользовательское поле	Чтобы связать CRM-карточку с подписчиком Senler
Группа подписчиков	Пользовательское поле или комментарий	Чтобы понимать, из какой микроворонки пришёл человек
Ответ в боте	Комментарий, поле сделки или дело	Чтобы менеджер видел контекст
Интересующий продукт	Поле сделки	Чтобы не спрашивать повторно
UTM Source / Medium / Campaign / Content / Term	Отдельные UTM-поля	Чтобы считать рекламу и связки
Дата и событие захвата	Комментарий или поле	Чтобы видеть, почему заявка попала в CRM

Самый плохой вариант, складывать всё в один комментарий: «Заявка из Senler, курс: дизайн, utm_source=vk, ответ=хочу консультацию». Читать можно, анализировать сложно.

Лучше заранее создать отдельные пользовательские поля: Источник, Кампания, Группа Senler, Ответ в боте, Интерес, VK ID, Событие Senler. Тогда через месяц можно не просто смотреть сделки, а понимать, какая микроворонка дала продажи.

Пример расчёта. ВК-реклама привела 500 подписчиков в Senler. Из них 80 дошли до шага «хочу консультацию», 35 оставили телефон, 20 дозвонились, 6 купили. Если в Битрикс24 передали только факт «заявка из Senler», вы видите 35 лидов. Если передали UTM, группу, шаг бота и ответ, вы видите, какая реклама дала не подписчиков, а покупки.

Это разные уровни управления.

Дубли: почему они появляются сразу после запуска

Дубли почти неизбежны, если интеграция создаёт новую запись при каждом событии.

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

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

Рабочая логика выглядит так:

1. Получили событие из Senler.
2. Проверили телефон, email, VK ID.
3. Нашли существующий контакт или лид.
4. Обновили поля, если данные новые.
5. Создали сделку только там, где это нужно.
6. Записали событие в историю.
7. Не отправили повторно то, что уже было обработано.

Идемпотентность - сложное слово, но смысл простой: одно и то же событие не должно создавать результат дважды. Если вебхук пришёл повторно, по ID события система видит, что оно уже обработано, и не плодит вторую сделку. Полностью железобетонной такая защита не бывает: два почти одновременных запроса теоретически могут проскочить оба, поэтому к проверке по ID добавляют контроль и возможность позже подчистить дубль. Но в типичном случае «Senler повторил вебхук» дубль не появляется.

Хорошая интеграция не просто создаёт лид. Она сначала спрашивает: «Мы уже знаем этого человека?» и только потом решает, создать, обновить или пропустить.

Для маленькой базы это кажется лишним. Но на 5 000–10 000 подписчиков дубли уже становятся настоящей проблемой. Один день неправильной настройки может дать десятки лишних лидов, а разбирать их вручную будет дороже, чем сразу настроить поиск и обновление.

Где теряются деньги

Самая дорогая ошибка передавать в Битрикс24 не то событие. Допустим, таргетолог ведёт трафик во ВКонтакте по 80 рублей за подписчика. За неделю пришло 700 подписчиков, расход 56 000 рублей. Если в CRM ушли все подписки, менеджеры получили 700 «лидов». Реально тёплых обращений было 60. Остальное шум.

Вторая ошибка потерять UTM. Реклама может идти из трёх кампаний: вебинар, лид-магнит, консультация. Без UTM все заявки выглядят одинаково: «Senler». Вы можете отключить не ту кампанию или продолжить лить бюджет туда, где есть подписки, но нет оплат.

Третья ошибка не контролировать сбои. Вебхук перестал работать в пятницу вечером. За выходные бот собрал 40 телефонов, но в CRM попало 12. Если средняя конверсия в оплату — 15%, а средний чек — 25 000 рублей, то потерянные 28 заявок могут стоить до 105 000 рублей потенциальной выручки:

28 заявок × 15% × 25 000 ₽ = 105 000 ₽.

Да, это не гарантированная выручка. Но это хороший способ увидеть цену «мелкого технического сбоя».

Способы связать Senler и Битрикс24

Есть четыре основных подхода. Они не равнозначны.

Способ	Когда подходит	Плюсы	Ограничения
Вебхуки и API вручную	Есть техспец или разработчик	Максимальная гибкость, можно написать свою логику	Нужно самим поддерживать код, логи, повторы, безопасность
Универсальные коннекторы	Нужен быстрый старт и простой сценарий	Быстро, без разработки, удобно для типовых задач	Сложные маршруты, дубли и сбои часто требуют дополнительной настройки
Кастомная разработка	Нестандартная логика, много условий, несколько систем	Можно собрать всё под бизнес-процесс	Дороже, дольше, зависит от разработчика
Платформенный подход	Нужны правила, история, сегментация, обратные сценарии и контроль	Можно управлять маршрутом клиента, а не одной передачей данных	Требует сначала описать сценарии и точки захвата

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

Универсальный коннектор удобен, когда задача простая: «получили телефон → создали лид». Для первого теста этого может хватить. Но когда появляются условия вроде «если человек уже есть в CRM, обновить контакт, если сделка открыта, не создавать новую, если стадия изменилась, перевести в группу дожима», простая связка начинает превращаться в цепочку костылей.

Кастом через API даёт максимум свободы. Техспец может на чистом PHP принять вебхук Senler, проверить контакт в Битрикс24, обновить нужные поля, создать сделку и записать лог. Но вместе со свободой появляются обязанности: хранить токены, обрабатывать ошибки, делать повторную отправку, следить за лимитами, проверять, что ничего не отвалилось после обновления.

Платформенный подход нужен там, где Senler и Битрикс24 не единственная связка. Например, в онлайн-школе есть Senler, Битрикс24, вебинарная площадка, платёжная система, SMS, email, таблицы и LMS. В этом случае задача уже не «передать подписчика», а собрать маршрут клиента между сервисами.

Именно здесь логично смотреть в сторону Vakas-tools (Вакас-тулз): не как на ещё один коннектор, а как на управляющий слой для сценариев. Например, через сценарий связки Senler → Битрикс24 можно строить маршрут по правилам: принять событие, проверить условия, передать данные в CRM, учитывать дубли, выстраивать обратные сценарии и видеть, где что пошло не так.

Real-time или по интервалу: когда задержка имеет значение

Не все способы передают данные мгновенно. Вебхук срабатывает в момент события - это real-time. Часть универсальных коннекторов работает по опросу: раз в 1, 5 или 10 минут сервис проверяет, появились ли новые данные, и только потом передаёт их.

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

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

Обратные сценарии из Битрикс24 в Senler

Передача из Senler в Битрикс24 только половина маршрута. Продажи не заканчиваются на создании лида.

Допустим, менеджер перевёл сделку в стадию «Не дозвонились». Что дальше? Можно вручную писать человеку во ВКонтакте. Можно поставить задачу менеджеру. А можно завернуть это в обратный сценарий: добавить подписчика в нужную группу Senler и подписать его на бота, который отправит мягкое напоминание.

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

Примеры обратных сценариев:

1. стадия «Не дозвонились» → добавить в группу Senler и запустить ветку с напоминанием;
2. стадия «Думает» → подписать на бота, который пришлёт кейс или отзыв;
3. стадия «Счёт отправлен» → запустить ветку с дедлайном оплаты;
4. стадия «Оплачено» → исключить из продающего дожима;
5. стадия «Отказ» → перевести в долгий прогрев;
6. стадия «Купил курс» → добавить в группу клиентов или onboarding-воронку.

И ещё один честный момент, про запуск. Битрикс24 умеет отдавать событие о смене стадии наружу, и поймать его можно. Но это не готовый тумблер «стадия изменилась → сделай то-то»: реакция собирается из условий и маршрутов, и это более новый, ещё дозревающий слой, чем прямая передача из Senler в CRM. Поэтому обратные сценарии честнее обещать как «можно построить», а не как «работает из коробки в один клик».

Здесь нельзя мыслить только передачей заявки. Senler остаётся каналом коммуникации после того, как лид попал в CRM. Битрикс24 показывает статус продаж, а Senler помогает реагировать на этот статус сообщениями и сегментами.

Надёжность: что делать, если связка сломалась

Рабочая интеграция должна отвечать на три вопроса:

1. Событие из Senler было отправлено?
2. Битрикс24 его принял?
3. Что именно было создано или обновлено?

Без логов это превращается в гадание. Менеджер говорит: «Заявки нет». Маркетолог говорит: «Лиды были». Техспец смотрит вебхук и не понимает, на каком шаге всё оборвалось.

На рынке полно инструкций о том, как соединить Senler и Битрикс24 за пять минут, и почти нет о том, как сделать связку, которая переживёт сбой вечером в пятницу.

Нужен журнал событий. Минимальный набор:

Что фиксировать	Зачем
Время события	Понять, когда произошёл сбой
ID подписчика / VK ID	Найти человека
Тип события	Понять, что запустило передачу
Данные запроса	Проверить, что реально ушло
Ответ Битрикс24	Понять, приняла ли CRM данные
ID созданной сущности	Быстро открыть лид/контакт/сделку
Ошибка	Понять, что исправлять
Статус повторной отправки	Не потерять событие

Переигрывание событий - отдельная тема. Если вебхук упал, недостаточно включить его обратно. Нужно понять, какие события не дошли, и отправить их повторно без дублей. Для этого и нужна история: не просто «ошибка была», а «вот 17 событий, которые не попали в CRM, их можно безопасно переотправить».

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

Как выбрать подход под свою ситуацию

Один сценарий, одна форма, один менеджер, можно начать с простого коннектора или вебхука. Например: «человек оставил телефон в Senler → создали лид в Битрикс24». Для проверки гипотезы этого достаточно.

Три микроворонки, несколько продуктов, разные менеджеры, UTM, вебинары, оплаты и дожим, простая связка быстро станет узким местом. Там уже нужны правила: если пришёл из кампании А в одну воронку, если выбрал продукт Б, другому менеджеру, если контакт существует, обновить, если сделка открыта, не создавать новую.

Команда с сильным техспецом может сделать кастом через API. Это нормальный путь, если есть ресурс поддерживать код. Но если бизнес не хочет каждый сбой превращать в ручное расследование, лучше сразу думать не только о передаче данных, но и о мониторинге, истории и повторной обработке.

Если задачу можно описать одной фразой, хватит коннектора. Если фраза разворачивается в маршрут с условиями, ужен сценарий.

«Передать телефон из Senler в Битрикс24» - это одна фраза. «Передать, проверить дубль, записать UTM, создать сделку в нужной воронке, запустить дожим при смене стадии и при этом видеть сбои» - это уже маршрут. И коннектор на таком маршруте рано или поздно начинает обрастать костылями.

Что проверить перед запуском

Перед настройкой лучше пройти короткий чек-лист:

1. какое событие в Senler запускает передачу;
2. какие поля обязательны для CRM;
3. что делать, если телефона нет;
4. где хранить VK ID;
5. куда писать UTM;
6. что считать дублем;
7. создавать лид или контакт + сделку;
8. что делать при повторной заявке;
9. какие стадии Битрикс24 должны запускать обратные сценарии;
10. где смотреть ошибки;
11. кто отвечает за сбой;
12. можно ли переотправить недоставленные события.

Этот чек-лист экономит больше времени, чем кажется. Ошибка в одном пункте может дать сотни лишних лидов, потерянные UTM или дожим по тем, кто уже оплатил.

Проверить это на одном рабочем маршруте можно через сценарий связки Senler → Битрикс24: в Vakas-tools (Вакас-тулз) есть 14 дней триала, чтобы передать заявку, настроить поля, проверить дубли и посмотреть, как события проходят от бота до CRM.

И тогда видно главное. Связка Senler и Битрикс24 ценна не в день, когда первый лид появился в CRM. Ценность приходит через месяц, когда лиды не теряются, менеджеры не разгребают дубли, маркетолог видит, какая реклама дала продажи, а дожим уходит по реальному статусу сделки, а не по ощущению.