Telecom-приложение: почему оно не продаёт и что с этим делать

Frequency как корневая метрика

Любой коммерческий контекст сводится к одной цифре. Сколько раз в месяц клиент открывает приложение оператора. По наблюдениям рынка, среднее значение — 2-4 раза в месяц. Это меньше чем у банковского приложения (8-15), значительно меньше чем у мессенджера или социальной сети (30-100+), и меньше чем у e-commerce приложения активного пользователя (5-10).

С такой frequency приложение оператора не может работать как самодостаточный канал продаж. Окно показа предложения — узкое. Клиент открывает приложение когда у него конкретная задача (оплатить, посмотреть остаток, проверить детализацию), решает её, закрывает. Любая попытка добавить продажу к этому моменту воспринимается как помеха.

Эту реальность нельзя обойти маркетингом. Можно либо принять frequency и работать в её ограничениях, либо изменить frequency через добавление новой функциональности с собственной частотой использования. Второе сложнее и дороже, но возможно.

Четыре причины низкой frequency

Причина первая — целевое использование. Telecom-приложение исторически создавалось для service tasks: проверить баланс, оплатить, посмотреть тариф. Это редкие операции. Платёж — раз в месяц. Проверка баланса — несколько раз в месяц. Тариф меняют 1-2 раза в год. Эти задачи не дают больше чем 2-4 открытий в месяц.

Причина вторая — отсутствие push-причин для возврата. Push-уведомления в большинстве telco-приложений — это «у вас осталось X гигабайт» или «оплатите счёт». Это служебные сообщения, не вовлекающие. Пользователь открывает приложение по своей инициативе, не по поводу.

Причина третья — UX заточен под service. Главный экран показывает остаток, тариф, последний платёж. Это отличный service UX и плохой commercial UX. Клиент не находит в первом экране причин делать что-то новое или пробовать новый продукт.

Причина четвёртая — отсутствие relevance. Когда оператор показывает один и тот же баннер всем клиентам («новый тариф для всех»), клиент учится игнорировать промо-блок. Через несколько месяцев он не видит баннер даже если там что-то релевантное.

Если все четыре причины не адресованы, любая инвестиция в monetization приложения даст marginal результат.

Что нужно чтобы приложение начало продавать

Первое — расширение целевого использования. Приложение должно решать больше задач чем service. Кандидатов несколько. Bill payments hub: оплата ЖКХ, налогов, страхования, детских кружков. Это категория с frequency 2-4 раза в месяц на пользователя, и она привязывает к приложению независимо от telecom-задач. Loyalty: накопление баллов от партнёрских покупок с возможностью тратить в приложении. Family connectivity manager: управление семейным аккаунтом, контроль детей, родительские настройки. Все эти функции добавляют frequency без агрессивного маркетинга.

Второе — push relevance. Уведомление должно отвечать на конкретное событие конкретного пользователя в момент когда оно ценно. Не «у нас новый тариф», а «вы потратили на роуминг в Турции 250 000 сум в этом месяце, у нас есть пакет дешевле». Не «оплатите счёт», а «ваш счёт меньше обычного на 30%, можем разобраться». Это требует event-driven архитектуры (см. 002 about around-core layer).

Третье — main screen, который показывает next best action, не статичный service-блок. Один блок, релевантный текущему контексту пользователя. Не три баннера, не четыре карусели — один блок, на котором имеет смысл нажать. Это дисциплина UI которая часто проигрывает желанию «дать клиенту больше выбора».

Четвёртое — measurement и iteration. Каждое предложение должно измеряться: показ → клик → конверсия → revenue. Без этого измерения impossible понять что работает. Большинство telco-приложений показывают предложения без измерения per-offer экономики. В результате никто не знает какие офферы зарабатывают, какие убыточны.

Что не сработает

Полный redesign приложения. Большинство redesign-проектов в telecom — это перепаковка существующего service-UX в современный визуал. Frequency не меняется. Conversion не меняется. Меняется только perception от старого приложения к новому, и это perception эффект уходит за 2-3 месяца.

Покупка готовой offer engine платформы без operating model. Платформа без правил, событий и владельца — это средство без управления. Платформа с операционной моделью — это сильный продукт. Разница не в платформе, разница в operating model.

Push-кампании с большим объёмом. Увеличение объёма push-уведомлений увеличивает долю отписок, а не конверсию. Конверсия per push снижается с ростом объёма. Optimal frequency push в telecom — 2-4 в месяц на пользователя при условии relevance. Больше — opt-out растёт.

Гонка за «фичами как у банка». Скопировать функциональность банковского приложения не получается, потому что у banking app другая базовая ситуация: клиент уже там по необходимости (платежи), у банка есть право на push о финансах, и unit-economics строится на keep-balance, не на impressions. Telecom не может стать банковским приложением, и не должен пытаться.

Конкретный пример: bill payments hub

Это самая результативная функциональность которая часто делается telco-приложениями плохо. Возьмём её отдельно.

Что должно работать в bill payments hub. Оплата ЖКХ (электричество, газ, вода) с памятью провайдера и счётов прошлых периодов. Оплата налогов через интеграцию с Soliq. Оплата интернета и кабельного TV если они от других провайдеров. Оплата детских кружков, частных школ, кружков. Оплата страховок (ОСАГО, медицинская). Все это — категории с регулярной frequency.

Что обычно делается плохо. Payment занимает 7-12 нажатий вместо 2-3. Память провайдеров и счётов отсутствует — каждый платёж как первый. Нет автоплатежей. Нет уведомлений о новом счёте от связанного провайдера. UX оплаты ЖКХ хуже чем у Click или Payme — то есть оператор предлагает функциональность, которая у конкурентов реализована качественнее.

Что меняется при правильной реализации. Frequency растёт с 2-4 до 6-10 в месяц на активного пользователя. Это уже близко к банковскому приложению. App становится утилитой для финансовых задач, не только для telecom. После этого relevance push становится возможным потому что есть контекст: что пользователь оплачивает, какие у него регулярные расходы, какие категории ему интересны.

Bill payments hub окупается за счёт payment fees от провайдеров услуг (низкий take rate), partnerships, и косвенно — увеличения retention через увеличение switching cost. Если клиент привязал ЖКХ к telco-app, ему сложнее уйти к другому оператору не из-за номера, а из-за привычки.

Когда тема telco-app monetization не приоритет

Если основная ценность приложения сейчас — service для clients (показ остатка, оплата своего счёта), и команда обслуживания делает это плохо — сначала service до уровня индустрии, потом monetization.

Если frequency меньше 2 в месяц и команда не понимает почему — сначала диагностика frequency, потом инвестиции. Иначе все usability и monetization инвестиции уйдут на нерабочую базу.

Если у оператора сильная dealer network и клиенты предпочитают офлайн-покупки — telco-app не главный канал продаж, и инвестиции в его monetization не дадут такой ROI как улучшение dealer experience.

Если регуляторика по push и обработке персональных данных не оформлена — push-кампании в режиме «сначала запустим, потом разберёмся» создают регуляторный риск выше выгод.

Если компания не готова к 12-18 месяцам инвестиций в bill payments hub до того как frequency значимо вырастет — лучше оставить приложение как есть и развивать другие каналы.

Что включить в roadmap на 2026

Первый квартал. Аудит frequency и conversion текущего приложения. Без цифр любые предложения будут спорными. Конкретно — измерить количество открытий приложения per active user в месяц по сегментам, conversion на текущих предложениях, top reasons для открытия и закрытия приложения без действий.

Второй квартал. Pilot одной новой категории — bill payments hub для одного типа платежей (например, ЖКХ) или family account для одного сегмента. Цель пилота — измерить frequency lift и retention impact.

Третий квартал. Развитие выбранной категории. Добавление 2-3 связанных сценариев. Push-уведомления на event-basis. Measurement per offer.

Четвёртый квартал. Решение о масштабировании или закрытии. Если frequency не выросла на >50%, гипотеза не сработала. Если выросла — масштабировать на следующие категории.

Это roadmap не про красивое приложение. Это roadmap про увеличение frequency как фундамента для дальнейшей монетизации. Без frequency ничего не работает. С frequency возможно почти всё.

Что может сделать SamaraliSoft

Telecom App Monetization Audit — это диагностика frequency и conversion текущего приложения с разбивкой по сегментам. Анализ четырёх причин низкой frequency специфично для оператора. Подбор 1-2 функций для pilot которые могут увеличить frequency. Дизайн measurement framework чтобы pilot принимал решения на цифрах, не на perception. И roadmap из 4 кварталов с измеримыми checkpoints.

Внутренние ссылки

• /insights/telecom-subscriber-intelligence-operating-model/ — operating model вокруг данных
• /architecture/telecom-around-core-architecture/ — слой роста вокруг BSS/OSS
• /insights/telecom-growth-after-connectivity/ — где деньги после connectivity
• /use-cases/telecom-churn-war-room-mnp/ — удержание в эпоху MNP

Источники

• Digital Government Portal — состояние digital infrastructure UZ
• UzTelecom — пример telco-app в УЗ
• ЦБ РУ — статистика payment systems и cards
• UzDaily — рынок телекома 24,873 млрд сум