Кнопка «Войти» за миллионы: когда бизнесу правда нужна своя ВКС
Привет, я — Антон Фокин, CEO Qtim. Пользователь оплатил урок, открыл расписание и нажал «Войти». Через секунду он рассчитывает увидеть преподавателя. Искать ссылку в чате и вспоминать аккаунт 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, МИС или личным кабинетом?
- Мешают ли ограничения внешнего сервиса менять основной сценарий?
Считать ответы механически не стоит. Один критичный пункт — например, доступ к оплаченной услуге или возврат данных в продукт — может перевесить несколько нейтральных.
Если сбой во встрече ломает оплаченную услугу или оставляет сервис без нужных данных, ВКС нужно проектировать как часть продукта.
Когда встреча остается второстепенной и ничего не меняет в сервисе после звонка, готового инструмента достаточно.
Если видеовстреча уже определяет, получил ли клиент услугу, можем разобрать архитектуру: где хватит интеграции с готовым сервисом и что потребуется для собственной ВКС.