Bell Canada Launches Self-Serve Network as a Service

Bell Canada announced on 10 September the Bell On-Demand Network, which it describes as the country's first network-as-a-service platform aligned with the 7 customer experience attributes defined by Mplify, the industry body formerly known as MEF: on-demand, observable, manageable, programmable, secure, modular and flexible. TelecomTV carried the announcement in its 10 September roundup. The platform runs on Bell's fibre network with Cisco 8000 Series Secure Routers underneath, and the operator's description is that business customers can, through a single self-serve platform, "autonomously order, activate, manage and scale connectivity". The first product is On-Demand Internet, available in Ontario and Québec wherever Bell has deployed fibre, with additional networking, security, cloud connectivity and automation capabilities to follow. Bell's CTO Mark McDonald said customers "can now provision, scale and adjust their network in real time, getting the exact bandwidth and services they need, the moment they need them". No price, no provisioning time, no API documentation and no customer figure were published.

The customer configures, the operator does not pre-package

I have argued for some time that the natural end state of differentiated connectivity is slicing as a service: a platform through which third parties discover, configure, reserve and consume network resources on demand, because enterprise CIOs know their connectivity needs better than the operator does and are used to configuring cloud services rather than selecting from a catalogue. Bell's launch is that model applied to fixed access, and it is worth noting what is different from the 3 mobile launches of the past 3 weeks. EE sells a priority lane as a tariff, Vodafone sells a predefined quality profile through an API, and Telstra sells a slice for 1 application chosen by the operator. In each of those the operator decides what the product is and the customer decides whether to buy it. In Bell's description the customer decides the bandwidth and the timing, and the operator's role is to make the change when asked. That is the inversion the slicing-as-a-service argument depends on, and Bell states it as the product rather than as a roadmap.

Fixed first, because bandwidth on fibre is a reservation

It is not an accident that the self-serve model arrives on fibre before it arrives on mobile. When Vodafone launched quality on demand I wrote that a priority is not a reservation: a mobile profile improves the customer's place in the queue on a congested cell but does not guarantee what comes out of it, and the profile parameters were not published. On a dedicated fibre access line a bandwidth change is a reservation. The capacity exists, the router policy is deterministic, and the operator can honour the customer's chosen figure without a proof-of-value engine to check whether it did. That is why Bell can let the customer set the number and why the mobile operators cannot yet. It is also why the interesting part of Bell's roadmap is the part that is not launched: cloud connectivity and security are where the customer's requirement starts to depend on a second network and a second party, and the on-demand model will be tested at the first boundary it has to cross. Mplify's 7 attributes describe the customer's experience inside 1 provider's platform. They do not describe what happens when the customer's agent asks 2 providers for the same thing.

Programmable is the attribute that matters

Of the 7 attributes, 6 describe a good portal. The seventh, programmable, is the one that decides whether this is a self-serve web page or a network resource that a customer's own systems can consume. Bell's announcement describes a platform, not an API, and does not say whether the ordering, scaling and observability functions are exposed to the customer's software or only to a person logged into a portal. The distinction is the one I drew at DTW Ignite: the APIs that ship are the ones that ask the network a question, and the ones that ask it to change its behaviour on a third party's instruction are harder. On-Demand Internet is the second kind, in the easiest domain. If it is programmable in the Mplify sense, a customer's cloud automation or an enterprise agent can scale the access line up before a backup window and down after it without a human on either side, and Bell has built a resource the customer's software can reason about. If it is a portal, Bell has built a better ordering experience. The announcement does not say which, and it is the first thing a CIO evaluating it should ask.

What has not been published

No price relative to a standard business fibre contract, no provisioning time for a bandwidth change, no statement of whether the platform is API-accessible or portal-only, no minimum term or change frequency, no customer count and no date for the cloud connectivity and security capabilities. 4 things to watch. First, published API documentation, which is the test of the programmable attribute. Second, the price of a bandwidth change against the price of a permanent upgrade, because the on-demand model only pays for the customer if variable capacity is priced below fixed capacity over the period it is used. Third, whether Bell extends the same self-serve model to its mobile network, where it would need 5G standalone slicing and a service level of the kind Telstra attached to its slice. Fourth, whether the cloud connectivity capability, when it arrives, lets the customer configure the far end as well as the access line, which is the first crossing of an administrative boundary and the point at which slicing as a service stops being a single-operator product.

Agentic AI Could Raise Telco Opex by 30%

Two reports published on 10 September describe the same balance sheet from opposite ends. Bain & Company, as reported by Telecoms.com's Mary Lennighan, warns that operators could see operating costs rise by around 30% without any gain in productivity or growth if agentic AI is bolted onto legacy operating models. The consultancy describes an emerging agentic operating model in which traditional costs account for 70% to 80% of an operator's total and AI costs for 20% to 30%, with the risk that the legacy 70% to 80% never goes away. The same morning, TelecomTV's James Pearce published a second cut of the AI-Native Telco Index, the 276-page evaluation of 56 operators based on published material from January to June 2026, and found that 20 of the 56 frame their AI strategy primarily around revenue, 28 balance revenue and efficiency, and only 6 are primarily focused on efficiency. TelecomTV names the 6 as KPN, Proximus, Spark New Zealand, BT Group, Comcast and Rogers. It also notes, in the same article, that across all 56 operators cost savings remain the most clearly measured AI-related financial impact.

A new cost layer on top of the old one

Bain's argument is about arithmetic rather than technology. Model prices have fallen almost 10 times in the past year, according to the report, but token usage is rising faster as staff find new uses in network operations and customer care. At roughly half the token price, a 4.5 times increase in usage doubles the bill. The recommendation is to measure the cost of a business outcome, a resolved customer issue or a closed network incident, rather than the cost per token, and to hold someone accountable for model drift and token spend. AT&T is the worked example: it redesigned its orchestration so that large supervising agents delegate to smaller specialised models, which by AT&T's own account cut costs by up to 90% while tripling throughput. Bain's 3 cost traps are the token bill, the dual operating model in which human teams keep running the process while AI performs isolated tasks at the edges, and the low-risk demonstration that improves efficiency at the margin without touching the P&L. Internal chatbots, call summaries and copilots are named in the third category. This is the cost side of the 3 money flows I set out in July, when I argued that cost avoidance and revenue must be separated before an operator can say what AI is worth to it. Bain adds the point that cost avoidance is not automatic either: the avoided cost has to be removed from the organisation, and a process that is augmented rather than replaced removes nothing.

Revenue is the stated priority, savings are the measured one

The Index finding runs the other way. When I covered the first edition of the Index on 7 September the observation was that none of its 4 dimensions was financial. The second cut is TelecomTV's answer, and it is a useful one, because it reads the same public record for money rather than for capability. Of the 20 revenue-first operators, 11 are Tier 2 operators with annual revenues between $2 billion and $10 billion, 11 are in Asia and 4 in the Middle East, which TelecomTV reads as evidence that the shift toward AI revenue is not being led from Europe or North America. The examples with numbers attached are few. Bell Canada reported around C$700 million of AI-powered revenue in 2025, up 60%, and targets around C$2 billion a year by 2028. SK Telecom's AI datacentre business grew 92.5% year on year to 136.2 billion won in the second quarter, with AI B2B and B2C services at 61.3 billion won, up 24.5%. Indosat Ooredoo Hutchison reports sovereign AI cloud income separately, $28 million in 2025 with guidance of $60 million in 2026, and its Zankore joint venture with Nvidia, Nokia and Ooredoo raised $3.1 billion in debt this week to build 200 MW of GPU capacity by early 2027. On the efficiency side, KPN targets around €100 million a year in operating cost savings by 2030, Proximus folds AI into a €180 million efficiency programme, and Spark credits its churn model with reducing customer loss by up to 30%. TelecomTV also cites GSMA Intelligence's finding that only 35% of telco AI initiatives include a revenue objective. Read together, the picture is that revenue is what operators now say, savings are what they can measure, and 2 of the 3 operators publishing AI revenue lines, SK Telecom and Indosat, are selling compute or cloud capacity, which is the first of the 4 credible revenue lines in the July post and the one that looks least like a telecom service. Bell has not said what its C$700 million comprises.

The number the business case is missing

Put the 2 reports side by side and the missing figure is obvious. The Index counts operators that talk about revenue and reports the revenue lines that exist. Bain estimates the cost that agentic AI adds and warns that the legacy cost may stay. Neither report, and no operator in the Index, publishes both halves for the same company: AI-attributed revenue, AI-attributed savings actually removed from the cost base, and the AI compute and token cost that Bain says will make up 20% to 30% of the operating model. Bell's C$700 million is a revenue figure with no cost of sale attached to it in public. SK Telecom's AI datacentre revenue is real, but it is a hosting business whose margin is set by power and GPU depreciation, not by the network. KPN's €100 million is a 2030 target. Bain's own preferred use cases, autonomous network incident resolution and proactive churn prevention, are the workflows where the operator has to redesign the process end to end and retire what it replaces, and they are also the workflows where the data has to be fit for an agent to act on. Deutsche Telekom's Ahmed Hafez told the AI-Native Telco Forum on 8 September that DT's network data "is not ready" for machines and that data quality demands will start appearing in supplier RFQs, which is a cost that precedes any saving. Bain's framing is the right one for the report I am completing on autonomous networks: cost per resolved incident, before and after, with the platform, compute and data cost inside the denominator. That is the number that converts a proof into a P&L entry, and it is the number no one in the Index has yet published.

What has not been published

No operator has published AI revenue, AI savings and AI operating cost for the same period. Bell has not disclosed the composition of its C$700 million or the margin on it. AT&T's 90% cost reduction is its own account, relayed by Bain, with no base figure. The Bain report itself is available from Bain; the figures here are as reported by Telecoms.com. 4 things to watch. First, whether any of the 20 revenue-first operators reports AI compute or token spend alongside AI revenue in a quarterly filing, since that would be the first complete line item. Second, whether a legacy cost is visibly retired and attributed to agentic automation, in headcount, systems or supplier spend, rather than a saving being projected. Third, the on-demand recording of the AI-Native Telco Forum session on closing the attribution gap between deployment and financial outcomes, with Deutsche Telekom, Everpure and TM Forum, which TelecomTV says will be posted within days. Fourth, whether the 2027 edition of the Index adds a financial dimension and, if it does, whether it measures cost of outcome the way Bain proposes.