Automation in Telecom: Big Promises, Hard Realities

Automation in telecom has long been positioned as a technology challenge, but its slow progress is rarely caused by missing APIs or immature platforms. The real constraint lies deeper, in legacy processes, fragmented data, and decades of accumulated exceptions that were never designed for scale or interoperability.

While APIs and AI are essential enablers, they cannot compensate for poorly defined products, inconsistent data models, or manual decision logic embedded across organizations. As a result, many automation initiatives deliver visibility rather than velocity, and pilots rather than transformation.

The operators and service providers that make meaningful progress are those that treat automation as a structural change: simplifying processes, standardizing data, and aligning operating models before layering in APIs and AI. Only then does automation move from promise to performance, and only then can AI act as a true multiplier rather than a cosmetic overlay.

Context

Automation has been a recurring theme in telecom for well over a decade. APIs, orchestration layers, self-service portals, and zero-touch provisioning have long promised to transform the industry into a modern, software-driven ecosystem.

On paper, telecom should already operate this way. In reality, progress has been uneven.

The challenge is not ambition. It is execution, and more specifically, legacy. Most telecom operators are not working in greenfield environments. They are operating complex stacks built over decades, shaped by mergers, regional differences, and incremental fixes rather than end-to-end design.

Processes were built for manual handovers, data models were never intended for external exposure, and product catalogs evolved through exception rather than standardization.

As a result, automation has advanced faster in narrative than in outcomes. APIs exist in many environments, but they often sit on top of brittle foundations. Instead of removing friction, automation frequently shifts it downstream, creating new failure points rather than eliminating old ones.

This gap between promise and reality now defines much of the automation discussion in telecom.

Analysis

The core issue is not the availability of APIs or AI capabilities. It is the condition of the processes and data they depend on.

Automating inefficient, inconsistent, or poorly governed processes does not create efficiency. It accelerates complexity. This is why “API availability” alone rarely delivers meaningful automation benefits.

The real breakthrough comes earlier.

When processes are aligned, simplified, and agreed, and when data models are clean, structured, and standardized, automation becomes possible at scale. At that point, APIs stop being technical interfaces and start functioning as true business enablers:

• Higher data quality across ordering, assurance, and billing
• Faster and more predictable processes with fewer exceptions
• Improved customer experience through transparency and consistency

Once this foundation is in place, AI becomes the next multiplier rather than a risk factor. Clean data and standardized processes allow AI to be applied safely and effectively, enhancing efficiency, improving decision-making, and extending automation beyond what rule-based systems can deliver.

This is also where agentic AI becomes relevant. Rather than attempting to automate entire value chains end-to-end, agentic AI can be deployed at specific pain points, resolving order fallouts, interpreting incomplete service data, guiding complex support journeys, and orchestrating next-best actions across assurance, billing, and support.

Because agentic AI operates within well-defined boundaries, it improves outcomes without introducing uncontrolled risk.

Wholesale environments benefit first because of scale and repetition. Enterprise markets follow closely, driven by Network as a Service expectations, where network services are expected to behave like cloud services: on-demand, transparent, integrated, and consumable directly through customer systems.

Capvion perspective

At Capvion, we view automation not as a technology initiative, but as an operating model transformation.

The recurring blockers are well known: non-standard product definitions, fragmented data structures, manual exception handling embedded deep in processes, and organizational silos between wholesale, enterprise, and IT teams. Without addressing these fundamentals, automation initiatives tend to stall at pilot stage or deliver only incremental gains.

This is precisely where industry collaboration becomes decisive.

Organizations such as Mplify play a critical role in turning automation from a local optimization into an ecosystem capability. Mplify’s recent work has increasingly focused on making automation practical between carriers, not just within them.

A key area of progress is API standardization for carrier-to-carrier interaction, most notably through LSO Sonata APIs. Sonata defines standardized, interoperable APIs for ordering, inventory, assurance, and billing between service providers. The goal is not simply API availability, but consistent service semantics and data models that reduce interpretation, exception handling, and bilateral customization.

Recent Mplify publications and updates reinforce this shift in focus:

• Emphasis on API conformance over API count, recognizing that inconsistent implementations undermine automation
• Stronger alignment between LSO (Lifecycle Service Orchestration) APIs and commercial service models, bridging the gap between technical interfaces and real products
• Clear positioning of APIs as part of a NaaS operating model, not standalone integration tools

In parallel, Mplify has sharpened its focus on Network as a Service standards, defining how connectivity products can be exposed, consumed, and managed consistently across providers. This includes not just ordering APIs, but lifecycle events, assurance visibility, and change management, areas where automation typically breaks down.

The common thread across these initiatives is pragmatic realism. Automation does not fail because APIs are missing. It fails because the underlying processes and data are not aligned. Mplify’s work increasingly acknowledges this by coupling APIs with service definitions, process models, and conformance frameworks.

From our perspective, this is exactly the direction the industry needs. Automation scales only when carriers agree on what a service is, how it behaves, and how exceptions are handled, before exposing it through an API.

Automation succeeds when process and data lead, and technology follows, not the other way around.

Conclusion

The telecom industry does not suffer from a lack of ideas. It suffers from decades of accumulated complexity.

APIs, automation, and AI deliver real value only when they are approached as:

• Process transformation initiatives
• Data discipline exercises
• Cross-industry collaboration efforts

Not as isolated technology projects.

When automation is grounded in clean data, simplified processes, and shared standards, efficiency gains become structural rather than incremental. And only then does customer experience begin to match the ambition of Network as a Service.

That is where automation moves from promise to performance, and where lasting value is created.