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

Источник: https://fw-t.ru/articles/mvno-virtualnyj-operator-primery-oshibki-zapusk
Опубликовано: 2020-05-30 · Обновлено: 2026-09-14

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

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

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

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

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

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

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

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

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

**Цена:** повторный проект через год вместо развития продукта. Разбор моделей — в статье [о выборе между Full и Light](/articles/full-i-light-mvno-kakuyu-model-vybrat).

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

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

**Цена:** миграция расчетного контура. В проекте [ВТБ Мобайл](/cases/vtb-mobile) такой перенос занял пять месяцев — и это при хорошо подготовленном проекте.

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

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

**Цена:** самый частый источник сдвига графика. В запуске [Альфа-Мобайл](/cases/alfa-mobile-mvno) интеграция с инструментами банка и его процедурами верификации была отдельным направлением работ.

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

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

**Цена:** доработка в момент, когда команда занята запуском. В миграции [ВТБ Мобайл](/cases/vtb-mobile) три регуляторных требования закрывались одновременно с переносом базы, и это планировалось заранее.

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

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

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

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

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

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

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

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

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

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

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

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

## Вопросы и ответы

**Сколько занимает запуск, если считать честно?**

По подтвержденным проектам от пяти до десяти месяцев на техническую часть: шесть у Т-Мобайл в модели Full, десять у Альфа-Мобайл в модели Medium, пять на миграцию действующего ВТБ Мобайл. Договор с хост-оператором и лицензия идут параллельно и в этот срок не входят — их стоит закладывать отдельно и начинать раньше.

**С какой модели начинать?**

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

**Что чаще всего сдвигает график?**

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

**Почему важно, кому принадлежит платформа?**

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