Кнопка «Войти» за миллионы: когда бизнесу правда нужна своя ВКС

Пользователь оплатил урок, открыл расписание и нажал «Войти». Через секунду он рассчитывает увидеть преподавателя. Искать ссылку в чате и вспоминать аккаунт Zoom он не планировал.

Кнопка «Войти» за миллионы — короткое название всей системы вокруг звонка. За ней стоят проверка доступа, нужная комната и данные, которые вернутся в учебную платформу после урока. В этот момент видеосвязь уже управляет частью услуги. Ее нужно проектировать вместе с расписанием, оплатой и личным кабинетом.

Такую задачу мы решали для Онлайн-Школы №1: урок должен был открываться из расписания, а данные до и после занятия — оставаться внутри платформы. На этом проекте хорошо видно, в какой момент внешней ссылки уже мало и видеосвязь приходится встраивать в продукт.

Внешняя ссылка справляется, пока встреч мало

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

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

После оплаты лишняя ссылка ломает путь

Пользователь уже записался, выбрал слот, получил доступ и открыл личный кабинет. Теперь он ждет одну кнопку и понятное продолжение. Новая вкладка прерывает сценарий: приходится снова разбираться со входом и интерфейсом.

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

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

Звонок закончился. Данные остались

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

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

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

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

Чужая ВКС живет по своим правилам

Готовый сервис умеет звонить, записывать и приглашать участников. Бизнес-логику конкретного продукта он не знает. У провайдера свои роли, модель комнат, настройки доступа, события, аналитика и планы развития.

Между внешней ссылкой и разработкой собственной ВКС есть промежуточный вариант: встроить Zoom Meeting SDK или взять платформу вроде Jitsi или LiveKit. Zoom оставляет звонок на стороне провайдера, но показывает его внутри вашего интерфейса. Jitsi и LiveKit можно развернуть на своей инфраструктуре и получить больше контроля.

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

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

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

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

Один клик из расписания: кейс Онлайн-Школы №1

В Онлайн-Школе №1 живые занятия — один из главных процессов. Мы спроектировали собственную ВКС на базе WebRTC и напрямую связали ее с учебной платформой.
Ученик входит в комнату из расписания без дополнительных логинов и паролей. Для учителя сделали отдельное приложение на Electron: в нем можно показывать экран и материалы, работать с доской, следить за поднятыми руками и реакциями. Записи после урока доступны ученику и куратору.

Посещение засчитывается после заданного школой порога — примерно 15–20 минут. Так факт входа в комнату еще не равен факту участия в уроке. ВКС работает по правилам учебного процесса, а данные о занятии остаются в LMS.

На нагрузочных прогонах моделировали несколько одновременных уроков. В параллельных комнатах суммарно было около 100 подключений «ботов-учеников»; сессии оставались стабильными, без падений. Перед релизами отдельно проверяли работу камеры, микрофона и захвата экрана в актуальных браузерах.

Подробно архитектуру, сценарии и тестирование показали в кейсе ВКС для Онлайн-Школы №1.

Своя ВКС дороже на старте. Когда она оправдана

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

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

• Встреча связана с оплатой, расписанием или правами доступа?
• Есть ли разные роли с разными возможностями внутри звонка?
• Нужны ли записи, расшифровки, посещаемость, логи и аналитика в продукте?
• Есть ли требования к тому, где хранятся записи и данные участников?
• Влияет ли качество встречи на возвраты, поддержку, удержание или оценку услуги
• Приходится ли команде регулярно переносить данные между ВКС, CRM, LMS, МИС или личным кабинетом?
• Мешают ли ограничения внешнего сервиса менять основной сценарий?

Считать ответы механически не стоит. Один критичный пункт — например, доступ к оплаченной услуге или возврат данных в продукт — может перевесить несколько нейтральных.

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

Когда встреча остается второстепенной и ничего не меняет в сервисе после звонка, готового инструмента достаточно.

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