It’s not because the network can’t handle it. It’s because nobody outside the CSP has to ask permission to operate it. The quiet revenue migration to adjacent providers is happening — and operational architecture is the lever that determines whether CSPs ever take that ground back.
By Shawn Ennis•July 28, 2026 • 7 min read
If you spend any time talking to enterprise IT buyers — the people actually deciding where to host the next manufacturing 5G deployment or the next stadium event or the next autonomous vehicle pilot — you start to notice something uncomfortable.
The CSP is rarely in the room.
The conversations are happening between the enterprise IT team and an adjacent provider — a cloud-edge platform, a private 5G integrator, a managed-services partner. The CSP is the connectivity layer underneath the deal, not the partner driving it. The high-margin revenue lives in the orchestration, the operations, and the service guarantees that sit on top of the connectivity. And that’s not where most CSPs are positioned.
This isn’t a fight CSPs lost yesterday. It’s a fight they’ve been losing slowly for five years. And the lever that decides whether they keep losing it is something most operators don’t think of as competitive strategy: the operational stack.
The structural reason CSPs are losing
Adjacent providers — the ones eating CSP edge services — started from a different design assumption. They built their operations stacks for dynamic, ephemeral, API-driven services from day one. When an enterprise customer wants a new service, the adjacent provider can spin it up in seconds, monitor it natively, bill against actual usage, and tear it down when the customer is done. The architecture matches the customer’s expectations.
CSP operations stacks were built differently. They were designed for an era when “a new service” meant signing a multi-year contract, provisioning a circuit, and monitoring it for the next half-decade. That architecture works beautifully for permanent services. It fights itself when asked to handle anything that lives for less than a billing cycle.
An enterprise customer who wants a 5G slice for a four-hour event doesn’t want to sign an MSA. They don’t want a six-week provisioning cycle. They don’t want to call a CSP account team. They want to click a button and get an SLA-backed service for the duration of the event, then walk away. The platforms that can deliver that experience win the business. The platforms that can’t, don’t.
What “operational architecture” actually means here
I want to be specific about what determines the winner because the word “operations” gets used loosely in this conversation. There are five concrete capabilities that separate platforms designed for ephemeral services from platforms that aren’t:
1. API-first service instantiation
An enterprise developer should be able to trigger a service through an API call, get back a contract identifier, and know exactly what they’re paying for. Not a sales call. Not a quote. Not a six-week negotiation. An API call.
2. Per-mission SLA enforcement
The SLA needs to apply to the specific mission, slice, or session — not to a generic service tier. If a stadium concert needs 5 Gbps for four hours, the SLA enforcement engine needs to scope itself to that window. Generic “platinum tier” SLAs don’t work for ephemeral services.
3. Usage-bound billing
The bill needs to fire when the service ends, not at the next monthly cycle. Revenue recognition has to align with the service lifecycle, not the calendar. Otherwise CSPs are stuck running ephemeral services on permanent billing infrastructure — which means either lost revenue or angry customers.
4. Cross-domain operational visibility
When something goes wrong with an enterprise service, the diagnosis can’t span three different teams in three different tools. Network, edge, application, mission — all in one view, correlated in real time. Adjacent providers built this from day one. Legacy CSP stacks don’t have it.
5. Geographic awareness as a first-class concept
Many ephemeral services move geographically — drones, vehicles, mobile events. The topology that supports them changes every minute. If the OSS can’t render that motion in real time, the operator can’t deliver the SLA against it.
The argument operators make against this
Whenever I lay this out to CSP audiences, someone pushes back. The pushback usually takes one of three forms.
“We have partnerships with adjacent providers — we’re not losing them, we’re partnering with them.” The partnership model often means the CSP is the connectivity layer underneath the adjacent provider’s service. That’s a margin position, not a strategic position. The revenue per byte is fine. The revenue per service is going to someone else.
“Enterprises trust telcos more than cloud providers for mission-critical services.” In some markets and some verticals that’s true. In most cases the enterprise IT buyer trusts whichever provider can deliver the service with confidence. Trust follows capability, not legacy brand.
“We’re building the new operations stack ourselves.” Maybe. The execution risk is real. Most major OSS replacement projects across the industry have taken 3-5 years and overrun budgets by significant margins. By the time the new stack is production-grade, the addressable market has consolidated around platforms that already work.
The lever CSPs actually have
I’m not in this paper to declare the war over. CSPs have a structural advantage adjacent providers can’t easily replicate: physical infrastructure ownership, spectrum, and the relationships with enterprise IT departments that come from decades of being the connectivity provider of record. The lever isn’t to compete on the adjacent providers’ turf. The lever is to build the operational architecture that makes the CSP’s connectivity advantage actually monetizable.
That means an OSS that handles ephemeral services natively. Service catalogs that instantiate mission-bound services in seconds. Cross-domain correlation that gives the NOC one view across network, edge, and application. Real-time topology that updates as services move. Billing integration that ties revenue recognition to service lifecycle.
None of this is theoretical. The architecture exists. It’s been demonstrated. It can be deployed in six months with an overlay model that doesn’t require ripping out legacy stacks.
The bottom line: CSPs aren’t losing edge services because the network is wrong. They’re losing because the operations stack was built for a different decade. Fix that and the connectivity advantage becomes a revenue advantage. Don’t fix it, and the connectivity advantage becomes wholesale infrastructure to someone else’s premium product.
What this means for the next 12 months
The 5G slicing window is open right now. The operators that solve the operational gap in the next 12-18 months capture the slicing revenue opportunity. The operators that don’t watch their high-margin edge services continue migrating to platforms that can deliver them today.
It’s a choice — not an inevitability. But the time horizon to make the choice is shrinking every quarter.
The full operational blueprint
How telecoms can build the slice-aware operations needed to compete for edge services revenue.
About the author Shawn Ennis is the Founder & CEO of Rapax and Citus Technologies. With 25+ years in telecom operations, Shawn previously founded Assure1 (acquired by Oracle in 2021), holds 12 patents in telecom OSS/BSS, and hosts the Transformation Leaders Podcast. Connect on LinkedIn.