Запуск MVNO: типичные ошибки и что их стоит

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

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

1. Считать срок только по технической части

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

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

2. Выбирать модель под бюджет

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

Цена: повторный проект через год вместо развития продукта. Разбор моделей — в статье о выборе между Full и Light.

3. Брать платформу, которая закрывает одну модель

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

Цена: миграция расчетного контура. В проекте ВТБ Мобайл такой перенос занял пять месяцев — и это при хорошо подготовленном проекте.

4. Не закладывать интеграции с собственными системами

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

Цена: самый частый источник сдвига графика. В запуске Альфа-Мобайл интеграция с инструментами банка и его процедурами верификации была отдельным направлением работ.

5. Оставлять регуляторные требования на потом

Перенос номера, выгрузки в СОРМ и Финмониторинг, требования к идентификации абонента — каждое означает доработку биллинга и личного кабинета. Они не отменяются и не откладываются.

Цена: доработка в момент, когда команда занята запуском. В миграции ВТБ Мобайл три регуляторных требования закрывались одновременно с переносом базы, и это планировалось заранее.

6. Экономить на расчетном контуре

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

Цена: тариф выходит неделями вместо дней, а ошибки в расчетах превращаются в обращения в поддержку и в недополученную выручку. Состав контура — на странице решения для MVNO.

7. Не проверять, кому принадлежит платформа

Крупные российские BSS-вендоры принадлежат операторам связи. Для виртуального оператора это означает, что расчетная платформа находится в руках компании, которая одновременно продает ему трафик.

Цена: ослабленная переговорная позиция. Условия по трафику пересматриваются регулярно, и возможность сменить хост — аргумент в этих переговорах.

8. Не договариваться о выходе

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

Цена: отдельный проект по извлечению собственных данных.

Чек-лист перед стартом

• Целевая модель MVNO выбрана под продукт и зафиксирована.
• Платформа закрывает все четыре модели, переход не требует ее замены.
• Юридическая дорожка начата: переговоры с хостом, подготовка к лицензированию.
• Перечислены системы компании, с которыми нужна стыковка, и назначены ответственные с ее стороны.
• Регуляторные требования включены в план работ, а не в список «после запуска».
• Посчитана бизнес-модель: целевой ARPU, структура трафика, точка безубыточности.
• В договоре с вендором зафиксирован порядок выгрузки данных.

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