• Сервисы
  • Тарифы
  • Решения
  • Партнерам
  • Блог
  • Полезное
    Сценарии автоматизаций
    Готовые связки сервисов для автоматизации задач и увеличения продаж.
    Кейсы
    Истории решения проблем от наших клиентов при помощи сервиса Vakas-tools.
    Документация
    Текстовые и видео-инструкции сервиса Vakas-tools.
    Заказать настройку
    Доверьте технические настройки нашим специалистам.
    Сообщество
    Задавайте вопросы, делитесь знаниями с другими пользователями Vakas-tools.
    Эксперты
    Найдите эксперта Vakas-tools, который поможет вам настроить и автоматизировать процессы в вашей онлайн-школе.
  • Интеграция Bizon365 и amoCRM: как передавать зрителей вебинара, а не только заказы

    Интеграция 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 можно без программиста и поддерживать без отдельного человека в штате.

    Другие материалы
    Как выбрать SMM-специалиста: кто это, что должен знать и уметь
    Статья
    12 июня 2026
    Как выбрать SMM-специалиста: кто это, что должен знать и уметь
    В условиях того, что каждый второй уверенный пользователь социальных сетей сейчас называет себя SMM-специалистом - выбор настоящего профессионала может оказаться достаточно нелегкой задачей.
    Наталья Александровна
    Наталья Александровна
    Уведомления об оплатах Prodamus в Telegram
    Статья
    12 июня 2026
    Уведомления об оплатах Prodamus в Telegram
    Оплата прошла, но кто должен узнать об этом первым: менеджер, руководитель или техподдержка? Показываем, как связка Prodamus, Telegram и Vakas-tools превращает обычное уведомление об оплате в понятный сценарий работы команды.
     Анастасия Князева
    Анастасия Князева
    Получить сценарии автоматизации на почту
    FindLead Бесплатный парсер клиентов из Telegram-чатов Забрать доступ →