The friction usually starts in the same place.
Not in the network. In the systems that are supposed to turn network investment into revenue.
Broadband operators are building faster than ever. Coverage is expanding. Capacity is growing. But inside the business, the experience often tells a different story.
Orders stall for reasons no one can fully trace. Activations drag even when the network is ready. Product launches that looked straightforward become coordination exercises. Acquisitions close and then the real work begins. Not integration, but archaeology.
Most operators recognize the pattern because they’re living it.
Workarounds harden into standard practice. People fill the gaps that systems can’t. Certain workflows get quietly avoided because everyone knows they’ll break something upstream.
That gap has a price.
Revenue delays because orders don’t complete cleanly. Margin erodes through manual work that automation was supposed to eliminate. Integration timelines stretch past what the deal model assumed.
The problem isn’t strategy.
It’s that the foundation underneath can’t move at the pace the strategy requires.
Built to Last. Not Built to Change.
This isn’t purely a technology problem. It’s structural.
Most OSS/BSS environments were engineered for reliability above all else. They process orders correctly. They bill accurately. They stay up.
They weren’t built for constant product change, serial acquisitions, or digital self-service at scale.
So the systems adapted. Just not cleanly.
Middleware filled gaps. Product definitions duplicated. Pricing logic spread outside the system of record. Exception handling moved to people because the systems couldn’t handle the edge cases.
Each decision made sense in isolation.
Together, they produced an environment that treats change as a threat.
That shows up as slow activations, failed orders, long release cycles, and integration projects that run over plan.
It’s not a talent issue.
The system was built for a pace of business that no longer exists.
Modern SaaS Changes the Equation – If It’s Actually Modern
Not everything sold as modernization addresses this.
Migrating a legacy system to the cloud changes where it runs. It doesn’t change how it behaves. If the product model is fragmented, if integrations are brittle, or if completing an order requires manual intervention, those problems move with it.
Purpose-built SaaS OSS/BSS platforms are different in ways that matter operationally.
Consistent product models allow offers to be configured instead of custom-built. API-first integration reduces the need to reverse-engineer connections. Continuous delivery replaces long release cycles that delay change.
The result is a system that stops working against the business.
Orders complete without manual rescue. New products reach market without a war room. Acquisitions bring customers without importing another layer of operational complexity.
This isn’t a feature upgrade.
It’s a different operating posture.
What This Means for Investors and Operators
The impact becomes clear at the portfolio level.
Each acquisition with a distinct OSS/BSS stack introduces friction. Product definitions don’t align. Billing logic varies. Integration becomes reverse engineering.
Reverse engineering takes time.
Time delays synergies. Delayed synergies move the return.
A standardized SaaS core changes that.
Integration becomes more repeatable. The operational lift per acquisition drops. Growth doesn’t automatically bring proportional complexity with it.
For operators, the math is similar.
Manual workarounds, delayed activations, and slow launches don’t always show up cleanly in one place. But they show up. In headcount. In delayed revenue. In missed windows.
The Bottom Line
Operators aren’t modernizing because legacy systems have stopped working.
They’re modernizing because friction has a cost.
Network expansion creates supply.
The return depends on how efficiently the business converts that into activated service and recognized revenue.
If activations are slow, launches are consistently harder than they should be, and integration projects keep running long, the network is almost certainly not the issue.
The operating model is.
And operating model problems don’t stay contained. They compound.
What starts as localized friction becomes a constraint on how fast the business can move.
That’s when technical debt stops being a line item.
And becomes a strategic limit.
