Telecom super app: strategy, or a museum of buttons?
The super app idea is appealing to boards. Twenty-four months after launch, most telecom super apps turn out to be museums of buttons — many features, low frequency of use, weak conversion into adjacent products.
Discuss Your ChallengeA near-universal aspiration
Most operators in the region have at some point in the past five years articulated the ambition to build a super app — a single application that handles tariff management, payments, device purchases, content, financial services, lifestyle services and partner offers in one place.
The aspiration is understandable. Successful super apps in Asia — WeChat, Alipay, Grab, GoJek — show that consolidation across services produces non-linear value for both the user and the platform. Operators see themselves fitting that pattern.
The reality is far from the aspiration. Most apps that telcos label as super apps, on closer inspection, look like this:
- a long list of features that nobody uses,
- a small share of monthly active users compared to the total subscriber base,
- weak conversion into adjacent products,
- diminishing returns on each new feature,
- operations complexity growing faster than revenue.
That is the museum of buttons. The features exist in the catalogue; the visitors at each one are few.
Six markers of a real super app
First — a high-frequency anchor service. The user opens the app multiple times a day for a compelling primary reason. Without that frequency, secondary services never get exposure.
Second — network effects across services. Using one service increases the utility of another. Without cross-service synergy, a super app is just a bundle of apps under one shell.
Third — shared identity and trust. The user does not re-authenticate for each service or re-enter data. Transitions are frictionless.
Fourth — a single payment layer. Payment details are entered once and used across every service. Not separate transactions in each service with their own setup.
Fifth — a coherent UX. All services follow the same design language. The user feels that this is one product, not a federation.
Sixth — operational coherence. Support handles questions across services without re-routing. Behind the scenes, teams coordinate.
If fewer than five of these six are present, what you have is a collection of features in one container, not a super app.
What usually gets in the way
Frequency is fundamentally low. The core scenarios in a telecom app — pay a bill, check balance, change a package — happen 2-4 times a month. That is the lowest-frequency baseline category. A super app requires daily frequency, and connectivity alone does not get you there.
Network effects across services are weak. Adding a loyalty program to the operator app does not necessarily drive more adoption of fintech features. Services remain siloed.
Identity is fragmented. Different services may require different levels of verification. The user hits friction at every transition.
Multiple payment systems. If services connect to different billers and partners, the payment flow fragments into multiple separate transactions.
Inconsistent UX. Different teams build different services. Visual and navigational inconsistency disorients users.
Operations are not coordinated. Support, billing and marketing work on their services separately. The end-to-end customer experience does not come together.
What it takes for the aspiration not to become a museum
A high-frequency anchor service. If the core scenario of the app already produces several uses per day for most customers, the foundation exists. If not, the super app aspiration is premature — the anchor has to be built first.
Unified identity and payment. One customer profile, one payment method. The internal architecture supports it.
Cross-service value. Each new service adds value to the others, not just to the feature count.
A single product vision. One product owner across services, not a federation of teams each with their own piece.
Operational coherence. The customer journey is visible across services. Incidents escalate without losing context.
The build horizon for a mature super app is 3-5 years. It is not a project, it is a transformation of the product and operations model.
A realistic assessment for an operator in Uzbekistan
Most operators in Uzbekistan today have an app used 2-4 times a month by the average customer. That is not a foundation for a super app. Without a substantial increase in frequency, the build will turn into a museum.
The path to a super app looks like this:
Years 1-2 — building frequency. Re-design of the app’s core: a hub for all bill payments, family number management, transaction history with usable analytics. The goal is to lift frequency to weekly or higher. This is the critical foundation.
Years 3-4 — adding adjacent services with cross-service value. Each new service strengthens the anchor rather than existing in isolation.
Year 5 onward — a mature super app. Multiple integrated services, consistent UX, operational coherence.
Skipping these stages leads to the museum.
When the super app aspiration is not realistic
If a significant share of the customer base uses feature phones or has minimal mobile internet, the super app cannot become the channel for everyone.
If there is no clarity on why the app’s frequency is low, any improvement is going in blind.
If budget and board patience are constrained, the 5+ year horizon needs to be real rather than declarative.
If internal product capability is weak. A super app is a major product effort, not an addition to existing duties.
If the country already has established super apps from banks or technology platforms, the operator is entering occupied ground and has to answer honestly what makes it different.
Discussion points for the committee
What is the real app open frequency among key customer segments? Without this number, super app discussions are unfounded.
What is the realistic path to a high-frequency anchor service? What product changes lead there?
Is the board ready to commit financially, organisationally and patiently to a five-year horizon?
Beyond the anchor, which services bring the most cross-service value?
Is C-level prepared to admit the current app is not a super app if data shows the museum pattern?
How SamaraliSoft can help
Super App Reality Check — an honest assessment of current frequency, network effects and coherence in the operator’s app. A decision on whether the path to a super app is viable or whether the museum risk is too high. A phased plan with real checkpoints. If the super app is not justified, an alternative strategy for getting maximum value out of the app in its current role.
Related reading
- /en/insights/telecom-app-monetization/ — frequency and app monetisation
- /en/insights/telecom-wallet-trap/ — when wallet is a trap
- /en/insights/telecom-mpesa-lessons/ — lessons from M-Pesa
- /en/insights/telecom-telco-marketplace/ — marketplace
Sources
What else is worth exploring
Topics from the same area we usually explore together
CRM
Not an off-the-shelf CRM, but a properly built customer management contour — from first contact to loyalty.
→SolutionBI
Analytics is not pretty charts on the wall. It's the answer to 'why?' before the problem becomes a loss.
→SolutionContact Center
The contact center is not a phone station — it's the point where a client decides: stay with you or leave. The question is how it's built…
→SolutionIntegrations
Integrations are invisible but critical. When they work — systems talk. When they don't — data is lost and people copy from window to…
→I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.
Discuss applying this →Ready to discuss your challenge?
Tell me what's not working or what needs to be built. First conversation — no obligations.
Usually respond within a few hours