Bridging the NaaS commercialisation gap: From ambition to reality

Download

Network‑as‑a‑Service (NaaS) refers to the ability for telco operators to deliver programmable, on‑demand connectivity that is customisable to the end-user needs and can evolve in real-time with those needs. NaaS puts the end user in control of the connectivity service they get, rather than the telco that delivers it. NaaS is important to telcos in a context of stagnating revenue because it can provide a route to growth by satisfying as yet untapped enterprise demand for flexible connectivity.

Telcos are well-versed into what their networks need to achieve technically to develop NaaS capabilities (and network exposure, via APIs, plays a significant part in this ability, as do software-defined architectures and a minimum level of network autonomy).

Yet, very few have a clear vision of what the commercial side of NaaS might look like: how to price NaaS. Not only the price point but whether this price should be static or dynamic, i.e. depending on the use case, network congestion, etc). And to some extent who to sell it as well: traditional connectivity is seen as a commodity, very much like water and gas, and the purchasing process within an enterprise is unlikely to involve anyone beyond the procurement team. NaaS on the other end is more likely to be purchased where it is consumed, i.e. by the IT or network teams at enterprises or event large SMEs. Telcos do not necessarily have a good knowledge or understanding of those specific personas, therefore targeting them might not be a trivial exercise.

STL’s recent webinar The future of NaaS and API commercialisation: Bridging the gap between ambition and reality covered some of the hard questions that telcos face when they want to sell NaaS:

1. What does the industry really mean by NaaS?

2. How big a role do APIs play?

3. Which pricing models to adopt, beyond simply based on usage or volume?

4. And crucially, how to ensure that no value is left on the table when selling NaaS?

NaaS has three main characteristics: cloud-native, self-service and commercial flexibility

Despite the term’s prevalence, there is no industry consensus on a definition for NaaS. One interviewee from a recent interview cited that “We don’t use the term NaaS since there are so many different meanings that no one knows what they’re talking about when they use it.” While NaaS refers to slightly different things depending on who you speak to, it usually involves the following key characteristics:

• It is underpinned by cloud-native architectures – This means that connectivity can be spun up or down automatically, as opposed to needing days or more to be delivered/altered.
• The customer is in control – It is the end user who can configure, customise and monitor their services directly (typically via a console type of user interface).
• Flexible consumption and pricing – The customer only pays for what is used, when it is used. The user interface displays clear information about the price of the overall service (which could include connectivity and other services, such as cybersecurity for example).

Based on our recent operator interviews, NaaS is not only seen as the technical foundation for next-generation services (which includes NaaS as a standalone connectivity proposition), but describes the shift that enables the delivery of net-new services such as IoT, hybrid networks and network APIs.

Figure 1: What is Network-as-a-Service? (NaaS)

Source: STL Partners

At the technical level, for telcos to be able to deliver this in a holistic manner, their networks need to be highly programmable end-to-end and tightly interconnected with the applications that are run on them (via APIs): because in fact it will be the application itself that will send its connectivity requirements to the network, rather than the end user.

For instance a robotics application on a highly automated factory floor will have specific bandwidth and latency needs (which may change over time) which requires quality-on-demand from the network. With NaaS, telcos see their offering changing from static (one type of connectivity for all) to dynamic products.

NaaS in the context of STL’s vision of telco platform

NaaS sits alongside non-pure connectivity services, such as edge computing, AI, private networks, IoT, sits in a broader service portfolio, which alongside traditional connectivity (the one size fits all type we mentioned before), should form part of operators’ telco‑as‑a‑platform strategy.

In this model, telcos offer their own services in a programmable and modular way. They are also capable of collaborating with partners to deliver composite services made of different blocks, some provided by the telcos, some by the partners, but purchased as a whole via the telco’s platform (very much like the marketplaces we know in retail, Amazon being the prime example) and delivered as a seamless end-to-end service.

APIs are the connective tissue of this platform, allowing third parties to embed their own propositions into the telcos’ network. Technical excellence alone, however, will not translate into commercial advantage unless it is matched by equally modern billing and CRM system, and an ability by the telcos to mesh with their ecosystem partners.

In our Enterprise Platforms manifesto, we posit that success of the telco-as-a-platform concept depends on the ability for an operator to successfully implement three distinct types of architecture, as the diagram below illustrates:

The structural pillars and mindset of a successful platform strategy

Source: STL Partners

1. Service architecture – where cloud‑native functions are orchestrated on‑demand.

2. Revenue architecture – where the charging models applied are flexible.

3. Ecosystem architecture – characterised by engagement with partners across the entire value chain.

Most operators have invested heavily in the first pillar (i.e. the technical one), but lag behind in the other two. During the research STL conducted in preparation to our webinar, one panellist noted that platforms built for earlier CPaaS initiatives are still being re-used and re-purposed, even though NaaS “has a fundamentally different business model and technical requirements” than the CPaaS offerings (mainly volume-based).

NaaS can encompass a wide array of commercial models: from all‑you‑can‑eat to real‑time pricing

In terms of pricing for NaaS services, and the underlying APIs when these are involved in the delivery of NaaS, our research identified three main models that could shape monetisation over the next five years.

1. Dynamic pricing

Today, tiered subscriptions dominate NaaS and per‑call charges dominate APIs. But dynamic pricing where prices change depending on real‑time demand could be a more appropriate model.

For instance, a flood of QoD requests in a packed stadium could attract a premium for the QoD API, in the same way ride‑hailing apps apply surge pricing. The network’s inherent dynamism should be matched on the balance sheet, unlocking additional margin precisely when resources are scarce.

2. On‑demand everything

Customers no longer accept number of circuits in multi-year contracts as the unit of connectivity. They want services provisioned in minutes, personalised through bandwidth, route or latency parameters, and visible through live dashboards. Contracts, SLAs and billing need to reflect the same flexibility as the “on-demand” services they underpin.

3. Situational value

“One capability equals one price” is a legacy mindset.

The value – and therefore price – of an API varies by context. QoD enabling emergency‑services drones is mission‑critical and can (and should) command a premium. The same API supporting routine video calls is merely nice to have and should be cheaper. Operators should align the pricing model and the price point to the specific situation in which the capability is consumed.

How far have telcos come?

By and large, current platforms to deliver NaaS and NaaS capabilities, such as APIs, still reflect historic models.

They accommodate basic usage‑based charging or flat‑rate subscriptions but struggle with dynamic rates, contextual SLAs or multi‑party revenue splits when partners are involved. Application awareness in the network is limited and SLAs remain uniform.

Without investment in the revenue and ecosystem architectures (pillars two and three), the commercial flexibility promised by NaaS will stall and telcos will leave the proverbial value on the table. So these are our recommendatios for telcos to overcome such limitations:

1. Upgrade revenue systems first, not last: Billing, rating and settlement must handle situational and real‑time models and for this modern BSS systems are necessary investments. We have explored this theme in a previous report Why legacy billing systems restrict telco growth.

2. Design for B2B2X data flows: Share usage and SLA telemetry with partners as easily as capacity

3. real‑time analytics – Demand signals should inform provisioning and pricing decisions.

4. Bundle capabilities, not just products – Encourage uptake of other services across the portfolio rather than maximising a single API’s margin.

5. Align technical and commercial roadmaps – Every new network feature should come hand in hand with a clear consumption model.

6. Resist technical debt from earlier platforms – CPaaS charing models can hard‑wire yesterday’s assumptions into tomorrow’s offers.

7. Invest in customer experience – Real‑time dashboards and usage insights are as important in the overall customer experience as the product that lies underneath.

Conclusion: bridging ambition and reality

The case for NaaS is compelling: programmable networks, flexible consumption and richer partnerships will make telcos more profitable if delivered successfully. But this will not materialise unless commercial innovation keeps pace with technical ambition. By strengthening revenue and ecosystem architectures, telcos stand a real chance of turning the buzz around NaaS into a real sucesss story.