Service Strategy in ITIL Applied to Service Provider Portfolios

ITIL's Service Strategy discipline exists to answer a specific question: what services should an organization offer, to whom, and through what operational model. That question is the right lens for evaluating OSS portfolio decisions at service providers, because the answer a provider gives determines what its operations must be capable of doing every day, at scale, without exception. ITIL 4 remains the most widely used service management framework in use today, building on decades of prior service management practice while replacing rigid process hierarchies with a more flexible, holistic operating model. The industry's own trajectory supports why this matters now: ITSM is moving from a ticket-management function toward a function of strategy defined by AI, governance automation, and automation at scale, and Service Strategy is the part of the framework where that shift originates. Applied to an OSS portfolio, Service Strategy becomes the organizing logic behind consolidation decisions: which capabilities the OSS must support, which service lines justify the operational investment, and which operational model can actually carry out what the strategy promises.

The reason this framework belongs in an OSS conversation, rather than staying confined to help desks and change management boards, is that a portfolio decision and an operational capability are the same decision viewed from two angles. A provider cannot decide to offer a service without also deciding, whether deliberately or by default, how that service will be qualified, designed, provisioned, activated, and assured. Service Strategy forces that second decision into the open instead of letting it emerge as an accident of whatever systems happen to be in place. That is the discipline's real value for a service provider sitting on a fragmented OSS stack and asking which services it can credibly keep selling.

Using Service Strategy to define portfolio and operational commitments

A service provider applying Service Strategy does not get to treat the choice of which services to offer as separate from the choice of what its operations must reliably do. For FTTH, dedicated internet access, and Carrier Ethernet, those operational commitments are specific, measurable, and unforgiving. A decision to offer fiber-to-the-home service is a market decision, but it is equally a commitment to a workflow: address qualification, network design, provisioning, activation, and ongoing assurance all have to execute predictably at scale, for every subscriber, every time.

Dedicated internet access and Carrier Ethernet raise the operational bar further. These service lines require multi-layer orchestration, dynamic provisioning, automated fault detection, and real-time performance monitoring across network segments that are rarely homogeneous. Service Strategy, applied honestly, forces a provider to ask how many systems have to hand off to one another to get from a serviceable address to a billed subscriber, and who owns the seams between them. Answering that question with specific system owners and handoff points is what makes the strategy executable.

Zero-touch provisioning is the clearest expression of what Service Strategy demands for high-volume service lines. In a zero-touch model, a subscriber's service activates automatically the moment a device powers on and connects to the network, with no manual configuration step anywhere in the sequence. Installation completion itself triggers provisioning, verifies bandwidth, and initiates billing as a single automated flow. That is what "executing on the strategy" looks like at the level of an individual truck roll: not a policy decision made in a boardroom, but a sequence of systems acting in concert, in seconds, without a human closing the loop by hand.

Fragmented OSS stacks and the failure to execute Service Strategy

Fragmentation does not make Service Strategy harder to carry out. It makes the operational model the strategy requires impossible to build. When qualification, design, provisioning, and activation live in separate tools with separate data models, there is no single place where "a subscriber's service" exists as one coherent object moving through a lifecycle. There are instead several partial, disconnected records of that subscriber, each owned by a different system, each updated on its own schedule.

Most CLEC OSS stacks arrived at this state gradually, one purchase at a time. Best-of-breed procurement meant integration was always deferred to a later phase that rarely arrived with the urgency the original purchase did. Each tool brought its own data model, and the seams between those models were never actually resolved, only bridged with point-to-point integrations that made the fragility worse with every change. A new product launch, a modified provisioning rule, or a routine service change then triggers cascading updates across every connected system, each one a chance for the record to drift further from the truth of what the network is actually doing.

A widely discussed cautionary case in the UK fiber market illustrates where this kind of fragmentation leads: a fiber operator whose provisioning and activation processes could not keep pace with its build targets found that operational execution, not demand or capital, was the constraint on its strategy. Operational execution is where service strategies succeed or fail, regardless of how sound the underlying market logic is.

The same structural problem blocks the AI ambitions now shaping the industry. AI self-optimization and closed-loop automation depend on continuous access to real-time telemetry and the ability to act across domains without waiting on a human to reconcile conflicting records. Fragmented systems block this at the architectural level: no amount of configuration tuning fixes a data model that was never unified to begin with. Research from the World Economic Forum and TM Forum points to 2025 and 2026 as the period when AI pilots give way to autonomous networks becoming an operational priority, and that shift depends on an OSS architecture able to support it.

Requirements for an OSS platform to support Service Strategy decisions

An OSS platform capable of executing a service strategy needs a single, unified data model spanning the full service delivery lifecycle, not a tighter set of integrations stitched between legacy tools. Qualification, design, provisioning, and activation have to share one representation of the network and the service. That means one source of truth that every workflow reads from and writes to, rather than synchronized copies scattered across systems that each believe their own version is correct.

Ericsson's analysis of AI-native operator strategy describes a parallel requirement at the network level: intelligence has to be embedded across RAN, Core, Transport, and OSS/BSS rather than bolted on as an isolated AI layer sitting above everything else. That kind of embedding is only possible once the underlying data model is unified, because an AI system reasoning about RAN performance and an AI system reasoning about provisioning status need to be working from the same facts about the same subscriber and the same circuit.

Carrier Ethernet and other enterprise-grade services raise the stakes further. The unified model has to support dynamic provisioning, automated fault detection, and real-time performance monitoring across network segments that differ in vendor, generation, and topology. These requirements multiply the cost of any fragmentation in the data model, because an enterprise customer's service commitments depend on fault detection and performance monitoring agreeing with each other in real time, not reconciling after the fact.

Unified data also changes what it means to launch a new service line. When every workflow runs against the same model, adding a service does not require integrating a new tool into an already brittle stack. It requires configuring a new service definition within a structure that is already governed and already coherent. That difference, between a new integration project and a new configuration task, is what makes a service portfolio decision something an operations team can commit to delivering rather than something it has to hope will work.

Governed AI as the missing requirement in OSS modernization plans

A unified data model is necessary, but it is not sufficient on its own. An AI layer placed on top of that model without governance is ungoverned automation, and ungoverned automation acting on live service delivery is a liability. An agent that can provision a circuit can also misprovision one, at the same speed and the same scale, unless something constrains what it is permitted to do and records what it actually did.

McKinsey's "The State of AI in 2025" report describes agentic AI, defined as autonomous agents operating within defined boundaries, as a high-value tool that must be governed rigorously. The guardrails that govern it cannot be generic controls borrowed from some other domain. They have to be purpose-built for the operational context of service delivery, where a wrong action has a physical and billable consequence within minutes.

What telcos need is an intent-based orchestration layer: a deterministic, model-driven framework that defines what AI agents are permitted to do and keeps their actions predictable, auditable, and aligned with operational intent even as the system's intelligence and flexibility increase. The principle that resolves the governance question is straightforward to state and hard to build: AI agents have to operate on the same APIs, the same audit logs, and the same permission structures as human operators, rather than through a separate automation layer with its own access model and its own accountability rules. An action taken by an AI agent should be traceable in exactly the same way an action taken by a technician would be.

Optinet, built as an AI-native operations platform for FTTH and Carrier Ethernet providers, is one example of a platform designed around that principle from the outset. It consolidates qualification, design, provisioning, and activation onto a single data model, which removes the cascading update requirements and the architectural seams that fragmented systems create, and gives any AI acting within that model the same governed access and audit trail a human operator would have. It is one option among a field of providers approaching OSS modernization, and its relevance here is structural: the architecture described above is not hypothetical, it is already being built.

Treating OSS as a strategic platform rather than a back-office function

Service providers that build their OSS as a strategic, AI-ready platform, rather than a collection of back-office tools, can execute on portfolio decisions that fragmented operators cannot attempt. When the data model is unified and the AI operating on it is governed, the operational outcomes change in kind, not just in degree: turn-up time drops from days to hours, provisioning errors fall sharply, and launching a new service line stops requiring a new integration project.

HCLTech's 2026 telecom trends analysis frames the competitive stakes directly: AI-native telecom produces networks that think, learn, and heal themselves, and operators that fail to build that foundation will find their OSS constraining their service portfolio. The ITIL Service Strategy lens explains why that outcome is not optional for providers competing on service quality. A service portfolio depends on the operational model that can execute it, and that operational model depends on the OSS platform supporting it. A platform that cannot support governed AI across a unified data model is not a neutral starting point for a provider's strategy, it is the ceiling on what that strategy can ever become.

For CLECs, fiber operators, and carrier-grade service providers currently modernizing their stacks, the implication is concrete: OSS consolidation is the strategic decision that determines which services the organization can credibly offer, and to whom it can credibly offer them.