Интеграция Bizon365 и amoCRM: как передавать зрителей вебинара, а не только заказы
Большинство онлайн-школ узнаёт правду об интеграции Bizon365 и amoCRM в момент, когда менеджер начинает обзванивать «зарегистрировавшихся» — и половина из них на вебинар вообще не заходила. Карточки создались, задачи поставились, отдел продаж тратит часы на людей, которые не открыли ссылку. Причина простая: в CRM ушла регистрация, а не участие. Это разные данные, и стандартная интеграция между ними не различает.
Прямая официальная интеграция Bizon365 с amoCRM существует, но решает другую задачу. Она рассчитана на Бизон.Кассу и передаёт в CRM созданные и оплаченные заказы. Факт того, что человек смотрел вебинар 50 минут или ушёл на третьей, она не передаёт в принципе. Поэтому «зрители вебинара → amoCRM» — это не настройка по инструкции, а интеграционный проект, который кто-то должен собрать и поддерживать.
Дальше — что технически отдаёт Bizon365, что готова принять amoCRM, какая схема единственно рабочая и где на этом регулярно сливают деньги.
Почему «готовой» интеграции зрителей вебинара нет
Bizon365 даёт два технических входа, и ни один из них не называется «интеграция со зрителями». Первый — webhook страницы регистрации. Второй — API v2.0 с авторизацией через заголовок X-Token. Официальная статья самого Bizon365 про amoCRM это и подтверждает: прямая связка работает с Кассой и заказами, а для остальных данных нужен либо специальный webhook регистрации, либо API — и помощь программиста.
Отсюда первая развилка, на которой ошибаются чаще всего.
Регистрация — это намерение. Участие — это поведение. Если в CRM попадает только намерение, отдел продаж работает вслепую и обзванивает аудиторию, которая до вебинара даже не дошла.
Webhook регистрации отправляется после подтверждения e-mail, а если подтверждение отключено — сразу при добавлении подписчика. В нём приходит email, username, phone, webinarTime, UTM-метки, url_marker, url_param, secret и uid. Чего в нём нет — времени входа, времени выхода, длительности и статуса просмотра. То есть webhook регистрации физически не знает, смотрел человек вебинар или нет. Он срабатывает за дни до эфира.
Считается доставленным webhook при ответе сервера HTTP 200. На не-200 Bizon365 повторяет доставку, а после серии подряд идущих ошибок может webhook отключить. Эту деталь стоит держать в голове: эндпоинт, который падает в 500 на кривом payload, рискует молча потерять весь поток регистраций.
Что реально отдаёт Bizon365: регистрация против участия
Фактическое участие лежит не в webhook, а в отчётах по зрителям вебинара через API. Там доступны timeStart, timeEnd, time, visit, stream, sessionid и, главное, status с четырьмя задокументированными значениями:
1— посетил вебинар;2— попал на вебинар поздно;3— ушёл раньше;4— открыл и не смотрел.
Вот это и есть данные, ради которых интеграция вообще имеет смысл. status=1 плюс time больше 1800 секунд — горячий лид, который досмотрел оффер. status=4 — человек, на которого менеджеру звонить бессмысленно. Без этих полей оба попадают в воронку одинаковыми, и вся сегментация ломается на старте.
Связать регистрацию и участие позволяет поле uid: Bizon365 публикует его как внутренний идентификатор подписчика, по которому подписчик со страницы регистрации сопоставляется со зрителем из отчёта. Это технический ключ для дедупликации — надёжнее, чем матчинг по e-mail или телефону, которые человек на регистрации и на вебинаре может ввести по-разному.
Зритель, который смотрел вебинар 50 минут, и человек, который открыл вкладку и закрыл, в наивной интеграции выглядят одинаково. На этом теряется самый дорогой сегмент аудитории.
Что принимает amoCRM и где её лимиты ломают наивную интеграцию
Со стороны amoCRM всё решается штатным REST API v4 через OAuth 2.0. Поиск контакта — GET /api/v4/contacts с параметром query. Создание — POST /api/v4/contacts и POST /api/v4/leads. Для кейса «контакт + сделка одним пакетом» удобнее всего POST /api/v4/leads/complex. Задачи менеджеру — POST /api/v4/tasks.
Два момента ломают интеграцию, собранную «в лоб».
Первый — лимиты. amoCRM держит планку 7 запросов в секунду на интеграцию и 50 на весь аккаунт. На превышении прилетает HTTP 429, на повторных нарушениях — 403 с блокировкой. Посчитаем на живом примере. Вебинар на 500 регистраций, на каждую — поиск дубля плюс создание, это около 1000 запросов. При лимите 7 в секунду чистое время — больше двух минут, и это в идеале. Если слать всё параллельно без очереди и backoff, аккаунт упрётся в 429, а затем рискует получить 403.
Второй — контроль дублей. Он в amoCRM есть, настраивается по воронкам, но работает не так, как многие думают.
amoCRM не склеивает дубли сама. Метод leads/complex учитывает уже существующие карточки и правила контроля дублей, но не дедуплицирует то, что вы прислали в одном пакете. Повторный webhook без поиска на вашей стороне всё равно плодит сущности.
Плюс к этому токены. Access token в amoCRM живёт 86 400 секунд — сутки. Refresh token живёт 3 месяца и обменивается ровно один раз: получили новый — обязаны его сохранить, иначе доступ теряется и нужна повторная авторизация. Интеграция, которая не умеет аккуратно крутить refresh-токен, тихо умирает через сутки, и узнают об этом обычно по пустой воронке после очередного вебинара.
Двухфазная модель — единственная схема, которая работает
Раз регистрация и участие приходят из разных источников и в разное время, склеить их в один момент невозможно. Рабочая схема всегда двухфазная.
Фаза 1, момент регистрации. Webhook Bizon365 прилетает на ваш эндпоинт. Вы нормализуете данные, ищете контакт в amoCRM по e-mail и телефону, при отсутствии — создаёте контакт и черновую сделку через leads/complex. Сохраняете uid как технический ключ синхронизации.
Фаза 2, через 10–30 минут после эфира. Планировщик дёргает API отчётов Bizon365, забирает status, timeStart, timeEnd, time и по uid дописывает их в уже существующую сделку. Тем, кто подходит под правило (status=1 и time>1800 — досмотрел; status=3 и time>900 — ушёл с середины), ставит менеджеру задачу.
Между фазами обязательны три вещи, без которых поток рассыпается на первом же сбое: таблица идемпотентности по uid или ключу email + webinarTime + room, экспоненциальный backoff на 429 и 5xx, и dead-letter для 400/422, которые в ретрае чинить бессмысленно. Отдельная reconciliation-задача по расписанию добирает то, что webhook потерял — а он теряет, как только эндпоинт хоть раз ответил не-200.
Где на этой интеграции теряют деньги
Три ошибки повторяются почти на каждом самостоятельном внедрении.
Ошибка 1. Регистрацию принимают за участие. Последствие — менеджеры обзванивают тех, кто не пришёл. Цифры: при доходимости вебинара около 40% из 500 регистраций реальных зрителей примерно 200, а 300 — не зашли. Если всем 300 ставится задача «позвонить», и на каждую попытку уходит 5 минут, это 25 часов менеджерского времени, слитого на один вебинар. На потоке из четырёх вебинаров в месяц — сотня часов в никуда.
Ошибка 2. Полагаются только на контроль дублей amoCRM. Последствие — дубли карточек, двойные звонки, грязная база, по которой невозможно считать конверсию. Цифры: при повторных регистрациях и параллельных сеансах база легко обрастает десятками дублей за поток, а ручная чистка — это снова часы аналитика и риск удалить не то.
Ошибка 3. Не делают сверку участия после вебинара. Последствие — горячий сегмент не отделён от холодного, и самые конверсионные лиды получают ту же обработку, что и случайные. Цифры: значимую часть эфира досматривает обычно 10–25% зрителей, и именно они конвертируют в разы лучше остальных. Без status и time выделить их нельзя, а значит и приоритизировать обзвон нечем.
Общий знаменатель у всех трёх — попытка сэкономить на второй фазе. Без неё интеграция выглядит работающей ровно до первого разбора, почему продажи с вебинаров не растут.
Варианты реализации и сколько каждый стоит
| Вариант | Время | Трудозатраты | Что закрывает |
|---|---|---|---|
| Прямой webhook → amoCRM API | 1–3 дня | 8–20 ч | только регистрацию |
| Middleware / serverless + сверка | 3–7 дней | 24–60 ч | регистрацию и участие |
| Make / Zapier / Pabbly | 0,5–2 дня | 4–16 ч | базовый поток, сложная логика разрастается |
| n8n self-hosted | 2–5 дней | 16–40 ч | гибко, но инфраструктура на вас |
| CSV экспорт/импорт | 0,5–1 день | 2–8 ч | разовая историческая загрузка |
Поверх трудозатрат идут подписки. Bizon365 за вебинары берёт от 3 у.е. за место, со страницами регистрации — 4 у.е. за место, плюс 14 дней бесплатного доступа. amoCRM — 599 / 1199 / 1699 ₽ за пользователя в месяц, причём управление webhooks через API доступно только на расширенном и профессиональном тарифах. У Zapier вебхуки тоже живут не в бесплатном плане, а от Professional за $19.99 в месяц; Make перешёл на оплату кредитами за действия.
Посчитаем стоимость самостоятельной сборки. Production-схема с двумя фазами — это 24–60 часов. По рынку фриланса при ставке от 2000 ₽/час выходит 48 000–120 000 ₽ единоразово, и это без поддержки: кручение refresh-токенов, мониторинг 429, адаптация под изменения API GetCourse и Bizon365 — отдельная регулярная работа, про которую на старте обычно забывают.
iPaaS вроде Make или n8n стартует быстрее и дешевле, но логика «регистрация → подождать эфир → забрать участие → поставить задачу» в визуальном сценарии разрастается до неуправляемого состояния. Для одного вебинара в квартал это терпимо. Для потока — превращается в источник тихих сбоев, которые никто не мониторит.
Что выбрать
Если поток маленький и нужен только факт «зарегистрировался» — хватит прямого webhook на amoCRM API, 8–20 часов работы, и закрыли вопрос. Если задача разовая, а в команде есть сильный разработчик — n8n self-hosted даёт контроль над данными и стоимостью.
Если же вебинары — это канал продаж, и важны время участия, статус зрителя, повторы и автоматизация follow-up, остаётся ровно два честных пути. Первый — собрать и поддерживать middleware самим: 24–60 часов на старте плюс постоянная поддержка токенов, ретраев и сверки. Второй — взять готового дирижёра, который уже делает обе фазы.
Vakas-tools закрывает ровно эту связку: единая база клиентов с историей, автоматический разбор отчётов Bizon365 с сегментацией зрителей по статусу и времени просмотра, собственный движок сценариев «если-то» для постановки задач в amoCRM и мониторинг сбоев вместо тихо отключённого webhook. Готовые связки можно посмотреть отдельно: передача участников вебинара Bizon365 в amoCRM, а если регистрации собираются в GetCourse — Bizon365 и GetCourse. Именно пара GetCourse + Bizon365 + amoCRM + Tilda проработана глубже всего, потому что на ней чаще всего и спотыкаются.
Выбор между «собрать самим» и «взять готовое» сводится к одному вопросу: готовы ли вы держать у себя человека, который раз в три месяца чинит протухший refresh-токен и разбирает, почему после вебинара воронка снова пустая. Если нет — вторую фазу проще не строить, а подключить. Собрать связку Bizon365 и amoCRM в Vakas-tools можно без программиста и поддерживать без отдельного человека в штате.





