ITSM for a Large Telco: Platforms, Architecture and Seamless Automation of Operations

1. The response layer is where autonomy stalls

At 00:17 on 18 September 2025, a contractor working for an Australian mobile operator locked a firewall gateway as the first step of a planned upgrade, and within half an hour alerts were raised. The method of procedure did not divert emergency-call traffic first, and the alerts were assumed to be artefacts of the upgrade. Over the following thirteen hours roughly 455 of 605 attempts to reach the national emergency number from four states and territories failed. The independent review commissioned afterwards counted around ten separate mistakes and summarised them as “processes not followed, incorrect procedures selected, inadequate checks, controls avoided, and alerts given insufficient attention” (Schott review, December 2025). In July 2026 the regulator took the operator to court alleging 1,005 contraventions of its emergency-call obligations (ACMA, July 2026).

The detection worked; the response did not. The signal existed within minutes, and the review also found that a call centre failed to escalate early reports from customers (AAP, July 2026). What was missing was the machinery that turns a signal into an owned incident with the right priority, links it to the change that was running, puts it in front of somebody with the authority to stop the change, and refuses to let the situation close until the service is verifiably back. Two years earlier a UK regulator had reached a similar conclusion about a 999 platform failure, finding among other things that the operator had no adequate procedure to assess the severity of the incident (Ofcom, July 2024). In the February 2024 nationwide outage of the largest US mobile operator, the regulator noted that public-safety users of the dedicated first-responder network were not notified until about three hours after the outage began (FCC, July 2024). None of these failures was about a missing dashboard. All were failures of the layer that sits between seeing and acting.

That layer is block 03, RESPOND, in the reference architecture we used to compare network discovery, inventory and observability platforms. There we described five operational blocks — observe, understand, respond, act, verify and learn — and four shared layers. This article zooms into the third block, and in particular into the platform that usually anchors it: IT service management (ITSM), the system of record for incidents, problems, changes and the commitments attached to them. It covers which platforms matter for a large operator, how they should be wired into observability, OSS/BSS, inventory, AIOps and orchestration, and how deep their automation and integration capabilities really go.

The thesis is simple to state and hard to execute: in a large telco, the ITSM platform should be the governance, accountability and traceability plane of operations, not a substitute for OSS, observability, inventory, correlation or orchestration. It is the place where a situation acquires an owner, a priority, a commitment, an audit trail and a closure criterion. Several suites now sell components of the other blocks too, and some of those components are good. They should still be evaluated as separate capabilities, against separate requirements, and not bought as one indivisible answer.

The second half of the thesis is about autonomy. The TM Forum autonomous networks framework, which we explained in our guide to the autonomous networks journey, scores autonomy flow by flow and task by task: intent, awareness, analysis, decision and execution. In most operators the analysis and execution tasks are improving fastest, because AIOps engines and orchestrators are being bought for exactly that. The decision task — who selects the action, under which policy, with which approval, and who answers for the outcome — is where flows stall at Level 2 or Level 3. That task lives largely in the RESPOND block. An operator that automates detection and remediation but leaves the response layer as a queue of tickets has built a fast car with a manual gearbox.

We go deep on five platforms and mention the rest in passing. ServiceNow, BMC Helix, PagerDuty, Atlassian Jira Service Management and OpenText cover the realistic shortlist for the system of record and the live response in a large operator, and together they illustrate every architectural choice that matters. For each, the analysis concentrates on what the user of this article most needs to know: what the platform can automate, how it integrates, what it claims for agentic AI, and what it contributes, concretely, to climbing the autonomy levels.

A note on method. Capabilities are taken from official documentation, product pages and vendor announcements available in October 2026, each linked. Fit assessments are editorial analysis by TelcoCrux, not test results or certified scores. Coverage always depends on edition, modules, deployment model and contract; anything described here should be verified in the operator’s own environment before it is relied on.

2. Why a telco cannot select ITSM like an ordinary enterprise

An ordinary enterprise uses ITSM to manage laptops, business applications, access requests, internal changes and service-desk incidents. A telco does all of that too, but it also runs commercial services whose quality depends on a massive, shared and constantly changing infrastructure. A transport failure can degrade dozens of enterprise and consumer services at once; a planned intervention can remove redundancy from hundreds of elements; and a small fault on one resource can produce a large impact on a handful of high-value customers.

Six structural differences

Six differences change what the ITSM layer has to do. None of them is exotic, but together they explain why a platform that excels at corporate service management can still fail as the backbone of network operations:

• Scale and volume: millions of resources and alarms, where hundreds of events may share one cause. The ITSM layer must receive situations, not raw events, or it will collapse under its own records.
• Technological heterogeneity: fixed access, mobile radio, transport, IP, core, cloud, applications, devices and equipment from many manufacturers, each with its own management system and its own notion of a fault.
• Hierarchy of impact: a technical fault has to be translated into affected resources, services, products, customers, service level agreements (SLAs) and experience. Priority comes from that translation, not from the severity field of the alarm.
• Many centres and many suppliers: the network operations centre (NOC), the security operations centre (SOC), IT, the enterprise desk, customer care, field service, contractors, wholesale partners and equipment vendors rarely use the same tool.
• Constant change: configuration, maintenance, expansion, software upgrades, virtualisation and automation change the network every day. Most major outages of the last five years were triggered by a planned change, as our analysis of network change management documented case by case.
• Critical continuity: closing a ticket is not the goal. Restoring the service, and proving it is restored, is the goal — and for emergency calls, a legal obligation.

The consequence for evaluation is that incident, problem, change and request management are necessary but not sufficient. A telco evaluation must also cover service assurance integration, operational change governance, dependency modelling, multi-organisation processes, application programming interfaces (APIs), security and controlled automation. The vendor demonstration that shines on employee self-service has not yet demonstrated anything about the network.

Three objects that must never be confused

The most expensive modelling mistake in telco operations is to treat every signal as a ticket. There are three distinct objects, each with its own life cycle, and the TM Forum Open API programme gives each one its own interface:

Object	What it is	Cardinality	TM Forum Open API
Alarm or event	A technical observation that a condition exists on a resource; not necessarily a service incident	Many per problem	TMF642 Alarm Management; TMF688 Event Management
Service problem	An actual or potential impairment of a service, linked to its underlying resources and to the customers who consume it	One per cause and impact scope	TMF656 Service Problem Management
Ticket or incident record	The governed record of work, ownership, decisions, escalation and evidence; customer-facing or internal	One master per scope, with derived tasks	TMF621 Trouble Ticket; TMF724 Incident Management

The separation matters for the data model and for interoperability. When forty alarms become forty tickets, the operation pays three times: in duplicated work, in conflicting priorities and in metrics that measure ticket throughput instead of service restoration. When the alarm, the service problem and the record are separate, each system can be master of its own object, and the identifiers that link them become the thread that holds the incident together. The same logic extends to the service and resource inventories (TMF638 and TMF639), which the record references but should not copy.

3. Zooming into RESPOND: three capabilities and their interfaces

Block 03 turns a diagnosed situation into managed work: one incident, one owner, one record, the right teams and the right suppliers. In the reference architecture it has three capabilities, numbered as in our earlier analysis so that the two articles can be read together.

03.1 Event intelligence

Event intelligence receives alerts from every engine, monitor and domain and makes them manageable. It deduplicates, suppresses alerts that are expected or downstream of a known incident, reduces noise, groups related alerts into one incident candidate, enriches the candidate with service, customer, owner, change, runbook and history, prioritises by impact rather than by monitor severity, and routes it to the team that owns the affected service. This is alert-management AIOps: statistical and behavioural intelligence over whatever topology it is given. It is not causal root cause analysis, which belongs to block 02 and reasons over a dependency model such as the graph-based network digital twin.

03.2 Incident response

Incident response runs the live minutes: owner, on-call rotation, page, bridge, escalation, stakeholder communication and coordination across teams and suppliers. Its value is speed and consistency under pressure. The response platform does not have to be the master ITSM system, and in many operators it should not be: it is optimised for the first hour, while the ITSM platform is optimised for the authoritative life cycle, the service levels, the relationships with problems and changes, and the reporting.

03.3 ITSM and the master record

The master incident record is the one artefact every block, team and supplier must agree on. It holds the unique identifier that every other system mirrors, the state and the service-level clocks, the relationships between events, problems and changes, the actions taken and their results, the verification evidence and the closure code. It is the system of record for governance, and the anchor for problem management, change management and, increasingly, for the audit trail of what automated agents proposed and executed.

The interfaces that decide whether the block works

The quality of RESPOND is decided less by any one capability than by its interfaces. Each arrow in the zoom diagram is a contract, and each contract needs an owner:

Interface	What crosses it	Failure when it is weak
02 Understand → 03.1	Correlated situations with probable cause, confidence and impact scope	Raw alarms reach the queue; forty tickets for one fault
07 Network and service context → 03	Service, customer, commitment and owner of the affected resources	Priority set by monitor severity; the wrong team is paged
03.1 → 03.2	Incident candidate, enriched and routed	The responder spends the first hour rebuilding context
03.2 ↔ 03.3	Identifier, state, priority, assignment, timeline	Two systems, two truths; a ticket closed in one and open in the other
03.3 ↔ change management	Recent and planned changes on the affected scope; emergency changes	The change that caused the outage is discovered after the outage
03 → 04 Act	Authorised action with scope, identity and stop criteria	Automation without accountability, or accountability without automation
05 Verify → 03.3	Independent evidence that the service recovered	Tickets closed on the engineer’s word; reopened incidents
08 Agentic AI ↔ 03	Summaries, hypotheses, drafted communications, proposed actions	Agents that act outside the record, or a record no agent can read
09 Governance → 03	Policies: who may decide what, autonomously, under which conditions	Every action escalates to a human, or none does
03 ↔ BSS/CRM	Customer impact, estimated restoration, case linkage	Customer care learns about the outage from customers

What belongs inside the ITSM platform and what stays outside

The cleanest architectures declare, object by object, which system leads and how the ITSM platform relates to it. The table below expresses a recommended default, not a universal rule. Some operators keep an OSS trouble-ticketing system as master for certain customer-facing incidents; what matters is to declare the authority of each object and forbid rival masters for the same scope.

Capability	System that usually leads	Relationship with ITSM
Telemetry and alarms	Observability and OSS fault management	Evidence and events referenced by the record
Correlation and root cause	AIOps and causal correlation engines	Probable cause, confidence and grouping attached to the record
Resource inventory	OSS technical inventory	Federated references, not copies
Service inventory and catalogue	OSS service inventory; commercial catalogue in BSS	Service identity, SLA, customer and dependencies
Major incident and formal escalation	ITSM declared as master	Owner, priority, state, evidence and coordination
Domain-specialist work	Domain tools or derived tickets	Two-way link to the master case
Change management	ITSM for governance; orchestrators and CI/CD for execution	Risk, policy, approval and result
Technical automation	Orchestrators, controllers, runbook engines, agents	Authorised command and auditable result
Customer communication	CRM, BSS or customer service management	Impact, estimated restoration, consistent state
Recovery verification	Observability and active service tests	Evidence for recovery and closure

The CMDB question deserves one more sentence because it is where most telco ITSM programmes overspend. The CMDB needs enough of the service model to route, prioritise and assess change risk. It does not need every port, every logical interface and every radio parameter, and trying to load them creates a second inventory that is always out of date. Federation — references to the OSS inventory, resolved on demand — is cheaper and more accurate than replication. The same principle runs through our analysis of the real-time data layer for assurance: the stream and the inventory are the source; the record points to them.

4. What “seamless” automation actually means

Seamless does not mean “without humans” in every circumstance. It means that work flows without artificial interruptions, without losing information, and without forcing people or systems to reconstruct context at each handover. In a traditional operation each handover opens a queue. In a seamless one, every stage shares the same operational thread.

Eight continuities, each verifiable

Seamless operation can be specified as eight continuities, and each one can be tested in a proof of concept:

• Continuity of context: the correlated identifier, the service, the dependencies, the customer, the priority, the evidence and the history travel with the incident.
• Continuity of state: every participant sees the current state; no ticket is closed in one tool and open indefinitely in another.
• Continuity of responsibility: there is always one owner of the recovery, however many domains and suppliers are involved.
• Continuity of decision: policies determine what may run automatically and when authorisation is needed, and the decision is recorded.
• Continuity of execution: runbooks receive the context and return structured results; they do not start from zero after each escalation.
• Continuity of verification: the loop closes only when an independent measurement shows recovery.
• Continuity of audit: every change, every agent proposal and every technical action is linked to the case and to its executor, human or machine.
• Continuity of learning: outcomes feed problem management, the knowledge base and the review of automations.

The end-to-end cycle and its integration contracts

The full cycle runs detection, correlation, identification of the affected service, decision, master incident, action plan, execution, verification, closure and learning. Each step may live in a different technology. That is acceptable, provided the contracts between them are robust. The minimum set of integration properties is short and non-negotiable:

• Events published once and consumed without duplication, with deduplication keys owned by the producer.
• Idempotent APIs, so that a retried “create incident” does not create two incidents.
• Persistent identifiers that every system stores and returns.
• Versioned schemas, so that a field added by one vendor upgrade does not break five integrations.
• Retries, compensation and dead-letter handling, so that a failed call is visible and recoverable.
• Distributed tracing across the flow, so that the time from alarm to verified restoration can be measured end to end.
• Explicit master-data rules stating which platform owns which field, and who wins when two disagree.

A practical example shows the difference. Probes detect latency and packet loss on several enterprise customers. The correlation engine groups the symptoms and points to a change made forty minutes earlier in a transport domain. The inventory translates the affected resource into circuits, virtual private networks (VPNs), contracted services and customers. A policy engine checks whether a pre-approved rollback exists and whether the confidence of the diagnosis is above the threshold for automatic execution. The ITSM platform holds the master incident, the owner, the actions and the customer communication. The orchestrator executes the approved rollback. The observability platform runs a post-action test, and only then does the incident move to “restored”. In a traditional operation, each of those transfers opens a queue. In the seamless model, all of them update one record.

5. Climbing the TM Forum levels: what RESPOND must do at each one

Autonomy is not a property of a platform; it is a property of an operational flow. The TM Forum scale runs from Level 0 (manual operations) to Level 5 (full autonomy), and its evaluation methodology scores each flow across five task dimensions — intent, awareness, analysis, decision and execution (TM Forum IG1252). An operator can hold Level 3 in radio fault handling and Level 1 in enterprise service restoration at the same time. The industry is still low on the curve: in TM Forum’s 2026 survey of 80 operators, 21% placed themselves at Level 3 or above, while 81% target Level 4 or higher by 2030 and 40 level validations had been awarded to 17 companies (Light Reading, 2026; TelecomsTechNews, August 2026). The useful question is therefore not “which ITSM is Level 4?” but “which task in which flow is still performed by a human, and what would the RESPOND block have to do to change that?”.

What the respond layer looks like at each level

The table translates the generic levels into the behaviour of the response layer. It is our interpretation of the framework for block 03, intended as a practical checklist rather than an official TM Forum mapping:

Level	Event intelligence (03.1)	Incident response (03.2)	ITSM and record (03.3)	Typical human role
L0 Manual	Operators watch consoles; tickets typed by hand	Phone trees and email	Ticket as a log written after the fact	Does everything
L1 Assisted	Static filters and deduplication; scripted ticket creation	Static on-call schedules and paging	Templates, categories, SLA clocks	Decides and executes every step
L2 Partial	Rule-based grouping and enrichment; auto-created incidents from correlated events	Automatic routing by service; scripted diagnostics attached	Record linked to CMDB and changes; automated assignment	Analyses and decides; system executes simple fixed responses
L3 Conditional	Learned grouping, impact-based priority, change correlation	Response plays launched automatically; supplier engagement through APIs	Pre-approved actions executed under policy; verification before closure	Approves significant actions; handles exceptions
L4 High	Situations arrive already explained: cause, confidence, impact	Agents coordinate diagnosis and mitigation across domains under one policy	Record as the audit spine of autonomous loops; humans review by exception	Sets intent and policy; supervises outcomes
L5 Full	Self-adapting	Self-coordinating across all domains	Self-governing within business intent	Defines business objectives

Why the decision task is the bottleneck

Awareness and execution are the easier engineering problems; analysis is improving quickly; decision is where most flows stall. Telemetry pipelines and orchestrators are mature product categories. Causal correlation is maturing. But the decision — select an action, check it against policy, obtain approval or waive it under a pre-authorisation, record it and answer for it — requires the response layer to hold policies, risk context and accountability in machine-readable form. A ticketing system that only stores free text cannot do that, however much AI is added to summarise the free text.

Three capabilities of the ITSM layer move the decision task up the scale:

• Machine-readable pre-authorisation. Standard changes and pre-approved remediation catalogues that a policy engine or agent can invoke without a human, inside explicit limits of scope, frequency and blast radius.
• Risk context at decision time. Change history, service exposure, customer commitments, concurrent changes and freeze windows available through APIs, so that the decision can be computed rather than discussed.
• Accountability for machine actors. Agents and automations registered as actors with identities, permissions and audit trails, so that “the system decided” is as traceable as “the engineer decided”.

Indicators that show the climb

The framework’s hierarchy of key business, effectiveness and capability indicators applies directly to RESPOND. Five measures should appear on any respond-layer dashboard, each measured per flow:

• Event-to-incident compression ratio: events received per incident created, together with the share of incidents later found to be duplicates.
• Time to recognise impact: from first symptom to an incident with service and customer impact attached.
• Share of incidents with automated diagnostics attached before a human opens them.
• Share of incidents resolved by pre-authorised automation, with independent verification — the operations automation rate for the flow.
• Mean time to restore, measured from detection to verified restoration, not to ticket closure, plus the reopen rate.

None of these is a ticket-throughput metric, and that is the point. Automating the handover of a ticket that should never have existed is very modest progress.

6. The operating model: who decides, who executes, who answers

Automating without decision rights only accelerates confusion. Before any platform is configured, the operating model has to say who owns what. The roles below are the minimum for a large operator; they are developed further in our analysis of the NOC/SOC operating model with AI agents.

Role	Main responsibility	What must not happen
End-to-end service and process owner	Availability, SLA, indicators, priorities and improvement	Each domain optimises its own indicators at the expense of the end-to-end service
NOC and service assurance	Detection, diagnosis, coordination of recovery and validation	A technical alarm treated as an independent incident without context
SOC and security	Security policy, threat analysis and coordination of security incidents	A network remediation that bypasses security controls
Domain teams	Technical knowledge, constraints, specialist execution and verification	A domain closes its task without checking end-to-end recovery
ITSM and incident governance	Master record, SLA, traceability, escalation, communication and formal decisions	Duplicate master tickets or contradictory states
Orchestration and automation	Execution of authorised runbooks, error handling and rollback	Actions without identity, permissions, evidence or stop criteria
Architecture and data	API contracts, capability catalogue, federated inventory and data quality	Each integration creates its own inconsistent copy of the truth

The master incident may live in the ITSM platform while an incident-response tool coordinates on-call and collaboration and an AIOps engine keeps its own technical case. That is normal. The architecture must establish one canonical governance incident, with correlated identifiers and synchronisation rules. It does not have to forbid derived tickets in other tools; it has to forbid rival masters.

7. The market map: five platforms in depth, the rest in passing

The respond-layer market has two sub-layers, and most vendors sit mainly in one of them. Event intelligence and incident response (03.1 and 03.2) are served by specialists such as PagerDuty and by the operations modules of the large suites. The system of record (03.3) is served by the ITSM platforms. A few vendors cover both, which is their structural advantage and their structural risk.

Why these five

The five platforms analysed in depth were chosen because together they cover every realistic architectural choice for a large operator:

• ServiceNow — the broadest platform, with telecom-specific modules for service operations and customer service, and the most extensive agentic-AI programme.
• BMC Helix — deep ITSM heritage, a large installed base in operators through Remedy, and an operations-to-incident flow that also works with third-party ITSM.
• PagerDuty — the specialist of the live response: event orchestration, on-call, incident response and runbook automation, synchronised with any master.
• Jira Service Management — the engineering-led platform, strongest where incidents are tied to code, releases and SRE teams.
• OpenText — service management combined with AIOps, network operations management and automation, with genuine on-premises and air-gapped options.

The rest, in passing

Other platforms are relevant in specific contexts and should be known, but they rarely decide the architecture of a large operator’s network response:

Platform	Where it fits	Note for a telco buyer
xMatters	Incident alerting and response workflows	Part of Everbridge since 2021 (xMatters; Help Net Security), not of ServiceNow, despite labels seen in some market maps
Opsgenie	Alerting and on-call	End of sale June 2025, shut down 5 April 2027; migrate to JSM or elsewhere (Atlassian)
Splunk On-Call	Alerting and on-call in Splunk estates	Under Cisco; no end-of-life announced (Splunk)
incident.io, Rootly, FireHydrant	Modern incident response for engineering teams	FireHydrant agreed to be acquired by Freshworks in December 2025 (Freshworks)
Broadcom CA Service Management	Installed base continuity	Still developed, release 17.4 in 2023 (Broadcom); keep-or-replace is an economic question
Xurrent (formerly 4me)	Multi-provider service management	Rebranded in 2024; positioned on bringing external providers together (Xurrent)
Ivanti Neurons for ITSM	Corporate IT, assets, endpoints	Cherwell, its legacy product, reaches end of life on 31 December 2026 (InvGate)
ManageEngine ServiceDesk Plus	Corporate IT, cost-sensitive units	Zia agents with a no-code studio in 2026 (ManageEngine)
Freshservice, HaloITSM, Matrix42, EasyVista	Business units, corporate IT, specific countries	EasyVista took majority control of OTRS in December 2024 (Business Wire)
HCLTech (former HPE telecom assets)	OSS fault management and trouble-ticket liaison with ITSM	HCLTech completed the purchase of HPE Communications Technology Group assets in December 2024 (Silicon UK)

The last row deserves a word because it describes a pattern, not a vendor. Many operators run network fault management on OSS platforms such as TeMIP and connect it to the ITSM through a trouble-ticket liaison: a component that creates incidents from alarms, associates and dissociates alarms with incidents, and keeps alarm and incident states synchronised in both directions. The documented TeMIP–Service Manager liaison does exactly this, over the OSS/J trouble-ticket standard (integration catalogue). Whatever ITSM is chosen, that liaison — or its modern TMF642-to-TMF621 equivalent — is one of the most important integrations in the estate, and it is often the oldest.

How each deep dive is structured

Each platform is analysed with the same structure, so that the five can be compared: positioning and corporate context; ITSM core and data model; automation; integration; agentic AI and the Model Context Protocol (MCP); contribution to each autonomy task dimension; and fit and risks for a large telco. All of them are evaluated against the same reality: the operator already has OSS, inventories, correlation engines and orchestrators, and the respond layer must work with them.

8. ServiceNow: the transversal platform with a telecom layer

ServiceNow is the default reference in large-enterprise ITSM and the vendor with the broadest telecom-specific catalogue. ServiceNow states that it was the only vendor named a Leader in Gartner’s 2025 Magic Quadrant for AI Applications in IT Service Management (ServiceNow, September 2025). Its subscription revenue grew 24.5% year on year to $3.88 billion in the second quarter of 2026, and it reported that its AI products had crossed $1 billion in annual contract value (ServiceNow Q2 2026 results). Scale buys investment; it also buys pricing power, which matters for a five-year cost model.

Release cadence and current state

The current generally available release family in October 2026 is Australia, with Brazil in early availability and expected to reach general availability around November 2026 (ServiceNow release notes). The previous families were Yokohama and Zurich. Two releases a year is fast for a telco estate with hundreds of integrations, and every evaluation should include the regression-testing effort of keeping up.

Telecommunications Service Operations Management (TSOM)

TSOM is ServiceNow’s answer to the network side of the respond layer. Its Australia documentation describes it as collecting, correlating and prioritising events across access, transport and core domains using standard APIs (ServiceNow TSOM documentation). It is assembled from several components:

• Standardised alarm ingestion through a TMF642 Alarm Management application, receiving notifications over publish-subscribe channels or Kafka.
• Event Management for correlation, suppression and prioritisation, with Metric Intelligence for anomaly detection and Health Log Analytics for logs.
• Service Impact Analysis, which propagates impact through the CMDB’s service relationships.
• A telecom-aware CMDB populated by Discovery and Service Graph Connectors, extending the Common Service Data Model (CSDM) with telecom models such as SD-WAN and private mobile networks.
• Two modules: Telecom Visibility (impact traceability and the telecom data model) and Telecom Assurance (alert and performance management).
• Shipped connectors to a small set of domain systems, including Nokia Altiplano for fixed access, private mobile networks and several SD-WAN controllers.

Telecommunications Service Management (TSM), the customer-facing counterpart, links customer cases and proactive notifications to the same network incidents. Operators such as Telia adopted TSM for incident and service management several years ago (Business Wire, 2021). This is the part of the proposal that is genuinely distinctive: one data model from alarm to service to customer case, on one platform, so that customer care sees the incident at the same time as the NOC.

What TSOM is not is equally important. It is not a complete OSS stack of discovery, performance, fault management, inventory, testing and network control. The number of shipped domain connectors is modest compared with the dozens of element managers in a large operator, and the CMDB still needs a federation strategy for the live network inventory. TSOM should be evaluated as event intelligence and impact analysis on top of the operator’s assurance stack, not as a replacement for it.

TM Forum Open APIs: what is actually listed

ServiceNow documents fifteen TM Forum Open APIs for its telecom, media and technology products (ServiceNow TMF API reference). For the respond layer the relevant ones are:

• TMF642 Alarm Management and TMF688 Event for TSOM.
• TMF621 Trouble Ticket for proactive service experience workflows.
• TMF639 Resource Inventory for the network inventory application.
• TMF646 Appointment and TMF697 Work Order for field service.

Two APIs that matter for the three-object model are not on the list: TMF656 Service Problem Management and TMF638 Service Inventory, and the page makes no claim of TM Forum conformance certification. Neither absence is disqualifying, because integrations can be built on the platform, but they should be priced as integration work rather than assumed as product.

ITSM core and change

The ITSM core — incident, major incident, problem, change, request, knowledge and service-level management — is mature and is not where ServiceNow needs to prove itself. For a telco, the change capabilities deserve particular attention. Conflict detection checks changes against schedules, blackout windows and other changes on the same configuration items, and the change success score, based on a team’s history of changes, is available with ITSM Professional (ServiceNow documentation). Generative explanations of change risk were added through Now Assist. These are exactly the risk-context capabilities that the decision task needs at Level 3, provided that the CMDB knows which services depend on the changed resources.

Automation and integration

ServiceNow’s automation stack has three layers, and an architecture team should decide which one each use case belongs to:

• Flow Designer and Integration Hub: low-code flows and prebuilt “spokes” that call external systems, plus playbooks that guide responders step by step. This is where incident enrichment, assignment, notifications, standard changes and calls to orchestrators are built.
• Workflow Data Fabric and RaptorDB: the data layer that lets workflows use external data without copying it, and a high-performance database positioned for mixed transactional and analytical workloads (Avasant, May 2026). For a telco, this is the platform’s answer to the federation problem; it should be tested against the operator’s real inventory volumes.
• Action Fabric: the agentic integration layer, comprising an MCP server through which external agents can use ServiceNow tools, MCP clients through which ServiceNow agents call external tools, and support for the Agent2Agent (A2A) protocol as client or server (ServiceNow community, June 2026).

One governance detail matters for regulated operators: according to the same ServiceNow article, AI Control Tower and its gateway govern MCP traffic in both directions but not A2A traffic. If the operator’s architecture relies on agent-to-agent coordination across platforms, the audit and policy controls for that traffic must come from somewhere else.

Agentic AI

ServiceNow’s AI programme moves quickly and renames often. At its May 2026 conference it presented Otto, a single AI experience combining Now Assist with Moveworks, which it acquired in December 2025 (Business Wire); role-scoped “AI Specialists”, with an L1 IT service desk specialist generally available; and extensions to AI Control Tower that can pause, redirect or terminate agent actions in real time (Avasant, May 2026). The company reported that agentic deployments grew ninefold in nine months. In 2026 it also completed the acquisitions of Veza for identity security and Armis for asset and exposure management, the latter for $7.75 billion (TelcoNews), and acquired Traceloop for observability of AI agents (The Register).

For a telco, the relevant question is not how many agents exist but which ones act on the network, under which identity and policy. AI Agent Orchestrator coordinates multiple agents inside the platform; AI Control Tower adds inventory, monitoring and controls over them. Both are useful for Level 3 and Level 4 flows, provided that network actions are still executed by the operator’s orchestrators, under the operator’s policies, with the master record as the audit spine.

Public telco evidence

The most concrete public evidence comes from BT Group, which in 2024 extended ServiceNow service management to all its business units and piloted generative AI for telecom service management with 300 agents, reporting a 55% reduction in case-summary time and a target to improve mean time to resolve by a third (CMSWire, June 2024). A partner case describes an unnamed US multinational operator in which ServiceNow tickets are generated automatically from detected anomalies, with mean time to resolve down about 50% and mean time to acknowledge down about 80% (HCLTech case study). We found no public TSOM-specific operator case with measured results; buyers should ask for references running TSOM at scale.

What ServiceNow contributes to the autonomy levels

Task dimension	Contribution	Level it enables
Awareness	TMF642 alarm ingestion, event management, metric intelligence	L2, and L3 with good CMDB coverage
Analysis	Correlation over CMDB relationships, service impact analysis, AI summaries	L2 to L3; causal depth depends on the service model
Decision	Change risk, conflict detection, standard changes, AI Control Tower	L3; L4 if policies and pre-authorisation are machine-readable
Execution	Flows, spokes, playbooks; MCP and A2A to external tools and orchestrators	L3 through external orchestrators
Intent	No native network-intent handling; TMF921 not listed	—

Fit for a large telco

ServiceNow belongs on the shortlist of any large operator seeking a unified service-management model across IT, network and customer operations, with strong end-to-end processes and the capacity to invest in permanent architecture, product and governance teams. Its principal risks are commercial and architectural rather than functional: the breadth of the platform makes it easy to expand scope module by module, each with its own licence, and a CMDB loaded with network detail it cannot keep current. The evaluation should insist on a module-and-licence map in which every capability has a cost and an owner, and on a federation design for inventory before any TSOM rollout.

9. BMC Helix: ITSM heritage and an operations-to-incident flow

BMC Helix is the natural candidate for operators with a Remedy or BMC history, and its operations-to-incident automation is unusual in one useful respect: it also works when the ITSM platform belongs to another vendor. That makes it relevant both as a full-block option and as an AIOps layer in front of someone else’s master record.

Corporate context

BMC announced in October 2024 that it would split into two independent companies, and BMC Helix — covering digital service and operations management — now operates as a separate company under the same owner, KKR, with its own domain and with Ali Siddiqui as chief executive (BMC, October 2024; BMC Helix leadership). Documentation has moved to a new domain as well. For buyers, the split means a more focused vendor with a smaller revenue base than its former parent, and contracts should be checked for assignment and continuity clauses.

Proactive Service Resolution: the core of the automation story

Proactive Service Resolution (PSR) automatically creates incidents or trouble tickets from events and situations raised in Helix Operations Management and AIOps, keeps them updated as the events change, and closes them when the events clear (BMC Helix documentation). Four details from the documentation matter for a telco design:

• Third-party ITSM: PSR works with Helix ITSM or with other ITSM platforms, including ServiceNow, which is documented with configuration notes for recent ServiceNow releases (BMC Helix documentation).
• One ITSM per tenant: PSR supports a single ITSM system per tenant, which constrains operators that run different masters for IT and network.
• Incident noise reduction: one consolidated incident per machine-learning situation, with a wait of up to two minutes for correlation before the incident is created — a deliberate trade-off between speed and duplicates that should be tuned per flow.
• Connector limits: situation-based noise reduction is not supported with the on-premises ServiceNow connector.

PSR is the documented embodiment of the 02 → 03.1 → 03.3 interface described in section 3. Its value is not that it creates tickets — every platform does — but that it ties the incident’s life cycle to the situation’s life cycle, so that the record reflects the evidence rather than the operator’s memory.

AIOps agents and HelixGPT

BMC documents a set of AI agents for Helix AIOps: Situation Analyzer, Best Action Recommender, Best Action Planner, Postmortem Analyzer, Log Analyzer, Change Risk Advisor and Vulnerability Resolver, plus a HelixGPT assistant in Microsoft Teams (BMC Helix documentation). The names map neatly onto the task dimensions: analysis (situation, log, postmortem), decision (best action, change risk) and planning of execution.

The 26.3 release of HelixGPT, documented in October 2026, added an MCP server exposing HelixGPT tools to external agents, an MCP client that validates external servers before use, and A2A interoperability with Google Gemini, Microsoft Copilot Studio or custom agents — all in controlled availability rather than general availability (BMC Helix release notes). The direction is the right one; the maturity is behind ServiceNow’s and PagerDuty’s generally available MCP servers, and a buyer should test it as an early capability.

Integration

BMC Helix iPaaS, powered by Jitterbit, is the integration platform, with prebuilt templates for third-party tools through Multi-Cloud Broker; the older Helix Integration Service reached end of life in December 2025 (BMC Helix documentation). Operators with integrations built on the retired service have migration work to plan. Multi-Cloud Broker also handles ticket brokering with external providers’ tools, which is relevant for supplier coordination.

Public telco evidence

BMC Helix publishes several telco cases with numbers, which is more than most vendors in this article:

• Vodafone Idea (India): Helix ITSM in the cloud since January 2023 for more than 16,000 users, with tickets down 20%, 38% of work orders automated and a 92% reduction in mean time to resolve on those automated orders (BMC Helix case study). AIOps is described as planned, so the results come from ITSM automation alone.
• TalkTalk (UK): migration from Remedy to Helix ITSM SaaS in 18 weeks for 2,000 employees, handling around 250 changes a week, with Helix Discovery adopted (BMC Helix case study).
• TPG Telecom (Australia): one service-management platform across IT, mobile and fixed network teams and seven brands, integrated with Jira through the Helix API (BMC Helix case study).
• Vodafone: BMC cites a 37% reduction in emails to the service desk and improved resolution on more than 20,000 incidents a day, without a percentage for the latter (BMC event page).

The Vodafone Idea figure is instructive precisely because it is narrow. A 92% reduction in resolution time on the automated share of work orders is what automation of well-defined, repetitive work looks like; it does not imply anything about network incidents. The TalkTalk case shows that a Remedy migration can be fast when the scope is disciplined.

What BMC Helix contributes to the autonomy levels

Task dimension	Contribution	Level it enables
Awareness	Operations Management event ingestion and situations	L2 to L3
Analysis	Situation, log and postmortem agents; Discovery-based service models	L3 where the service model is current
Decision	Best Action Recommender and Planner, Change Risk Advisor; ITSM change governance	L3
Execution	Intelligent Automation and PSR; external orchestration through iPaaS	L3 for incident life cycle; network actions through orchestrators
Intent	None directly	—

Fit for a large telco

BMC Helix belongs on the shortlist of large operations with mature ITIL processes or a BMC installed base, and as an AIOps-to-incident layer where the master record is elsewhere. The main risk of a modernisation is to reproduce in the new platform every exception accumulated in the old one; the TalkTalk timeline is evidence that the opposite is possible. The evaluation should compare three paths explicitly — modernise, redesign, replace — and price the integration migration from the retired integration service.

10. PagerDuty: the specialist of the live minutes

PagerDuty is not an ITSM platform, and it does not try to be one. It belongs in this shortlist because, in many large operators, the live response — event intelligence (03.1), on-call and incident response (03.2) and the first technical actions (04) — runs better on a specialist than on the system of record. The right question is not “PagerDuty or ServiceNow?” but “which part of the respond layer should a specialist run, and how is it synchronised with the master record?”.

Positioning and corporate context

PagerDuty is a listed company with annual recurring revenue of about $501 million and 15,506 paying customers at the end of July 2026, and growth that has flattened to under 1% year on year (PagerDuty Q2 FY27 results). The same release names John DiLullo as chief executive, succeeding Jennifer Tejada, and records costs related to a shareholder cooperation agreement. Flat growth and net revenue retention of 98% matter to a buyer in two ways: pricing power is limited, which helps negotiation, and consolidation in the category is possible, which argues for strong exit and data-portability clauses.

Event intelligence: what AIOps actually does

PagerDuty’s AIOps is an add-on priced by event volume rather than per user, and is called Signal Intelligence in the newer Reliability Platform plans (PagerDuty documentation). Its documented functions map almost one to one onto capability 03.1:

• Event Orchestration at service and global level: rules that route, transform, enrich, suppress and set priority on incoming events, with dynamic routing to services and dynamic escalation policies. Global orchestration and dynamic routing require AIOps.
• Noise reduction: intelligent (machine-learning), content-based, unified and time-based alert grouping, auto-pause of transient alerts and suppression rules.
• Triage context: Past Incidents, Related Incidents, Outlier Incident, Probable Origin and Recent Changes, which correlates change events from CI/CD and change tools with the incident.
• Scale: the Events API limit can be raised on request from 120 to 10,000 events per minute per integration key — a parameter worth testing explicitly during a telco mass-incident simulation.

PagerDuty states that AIOps “filters out up to 98% of noise”, and a financial-services customer reports an average of 58% noise reduction, with some services around 86% (PagerDuty AIOps). These are vendor figures; the customer figure is more useful because it shows the spread between services. In a telco, the spread will be larger still: grouping works well on application alerts with consistent payloads and less well on multi-vendor network alarms unless they are normalised and enriched with topology upstream.

The limit is structural, not a defect. PagerDuty groups what it receives, learns from what responders do and correlates with change events, but it does not hold a causal model of the network. Probable Origin is a statistical hint, not a topological root cause. Feed it situations from the correlation engine of block 02, and it becomes an excellent router and noise filter; feed it raw alarms from forty element managers, and it will reduce them, but it cannot explain them.

Incident response

The incident-response capability is the most mature part of the platform and the main reason operators buy it. On-call schedules, escalation policies, urgency rules, incident workflows that trigger actions on conditions (create a bridge, notify stakeholders, add responders, update status pages), status pages, stakeholder notifications and post-incident reviews are standard functions. For a large operator the features that matter most are service-aware routing, dynamic escalation by impact, and the ability to orchestrate many teams — including suppliers with their own PagerDuty accounts or with email and webhook interfaces — around one incident.

Automation: Runbook Automation and Automation Actions

Runbook Automation, which descends from the open-source Rundeck project PagerDuty acquired, runs diagnostics, remediation and operational tasks as SaaS or self-hosted, including on-premises and air-gapped deployments (PagerDuty automation). Three characteristics make it relevant to telco networks:

• Runners inside the network: the Enterprise Runner and self-hosted runners sit in segmented networks or virtual private clouds and execute jobs locally, so the SaaS control plane never needs inbound access to network management systems.
• Automation Actions: an add-on that lets responders, or incident workflows, launch Runbook Automation jobs or runner scripts from inside an incident, with output written back to the incident timeline (Rundeck documentation).
• Job definitions as code: jobs with options, access control and logging, which can call Ansible, scripts, APIs or controllers. This fits the “automated diagnostics first” pattern well: the first ten minutes of evidence collection are automated before a human opens the incident.

What it is not is a network orchestrator. Runbook Automation executes tasks; it does not model network services, compute intent or manage transactional configuration across domains. In a telco architecture it sits beside the domain orchestrators of block 04, triggering them through APIs, not replacing them.

Agentic AI and MCP

In its Fall 2025 release, PagerDuty announced an SRE Agent and an Insights Agent in early access, and a Scribe Agent (call and chat transcription and summaries) and a Shift Agent (on-call schedule conflicts) as generally available, together with a generally available remote Model Context Protocol (MCP) server (PagerDuty, October 2025). The MCP server works in both directions with third-party agents and had more than 250 customers within two months, according to the company. Its later results refer to upgrades of an “autonomous SRE agent”, but we could not confirm the general-availability date of every agent, and buyers should verify the status of each in their region and plan.

The MCP server is the more important announcement for architecture. It means an operator’s own agents — built on any framework — can read incident context and act on PagerDuty through a standard interface, and PagerDuty’s agents can call tools outside it. That fits the agentic layer (08) of the reference architecture, where the operator should keep control of its own operational knowledge rather than renting it from each platform.

Integration with the master record

PagerDuty lists more than 750 platform integrations (PagerDuty integrations). For this article only three matter: the two-way ServiceNow integration (incident creation, reassignment, resolution, status updates, impacted business services and custom fields, according to its support documentation, which requires a Business plan or higher), the Jira integrations, and the generic webhooks and REST API used for BMC Helix and in-house systems. The test in a proof of concept is not whether the integration exists but how it behaves under load and conflict: two state changes within a second, a reassignment in both tools, a resolution in one tool when the other is unavailable.

What PagerDuty contributes to the autonomy levels

Task dimension	Contribution	Level it enables
Awareness	Event ingestion and orchestration at scale; change events	L2
Analysis	Grouping, related and past incidents, probable origin (statistical)	L2 to L3, with causal input from block 02
Decision	Incident workflows and conditional automation; policy lives elsewhere	L3 if pre-authorisation is held in the ITSM platform
Execution	Runbook Automation with runners inside the network	L3 for diagnostics and low-risk remediation
Intent	None directly	—

Fit for a large telco

PagerDuty fits best as the live-response layer in front of an ITSM master, in IT, cloud and digital platforms and increasingly in network operations centres that already receive correlated situations. Its main risks are licence sprawl across add-ons (AIOps, Automation Actions, Runbook Automation, agents, status pages), synchronisation conflicts with the master record, and the temptation to let it become a second master. Its main advantage is that it is very good at the first hour, and it can be replaced without migrating the system of record.

11. Jira Service Management: the engineering-led service platform

Atlassian’s Jira Service Management (JSM) earns its place where incidents are connected to code, deployments, platform teams and site reliability engineering (SRE) practice. For a telco, that means the IT, cloud and digital-product estate — and the growing software layer of the network itself, from cloud-native network functions to OSS and BSS microservices, which we described in our analysis of the software engineering behind modern OSS/BSS.

Packaging and deployment: three facts that change the decision

Three recent changes alter the evaluation and should be known before any shortlist is drawn up:

• Service Collection: since October 2025 Atlassian sells JSM together with Customer Service Management, Assets and Rovo agents as one product at JSM’s price points and editions, with 50,000 Assets objects included in Premium and 500,000 in Enterprise (Eficode summary of the announcement).
• Data Center retirement: Atlassian ended sales of Data Center to new customers on 30 March 2026, will end sales to existing customers on 30 March 2028 and will end the product on 28 March 2029 (Atlassian, September 2025). For an operator that needs on-premises deployment for sovereignty or network-security reasons, JSM is now a cloud-only decision.
• Opsgenie shutdown: Opsgenie stopped being sold on 4 June 2025 and will be shut down on 5 April 2027, when unmigrated data will be deleted; its alerting and on-call features now live in JSM (Atlassian licensing). Opsgenie should not appear in any new architecture, and operators that still run it have a fixed migration deadline.

ITSM core and Assets

JSM provides incident, problem, change and request management on Jira work items, with SLA clocks, queues, portals and knowledge through Confluence. Assets is its configuration database: a flexible object schema in which services, components, network elements and customers can be modelled. That flexibility is an advantage for software teams and a burden for a telco network model, because nothing in Assets represents a customer-facing service, a resource-facing service or a transport path until the operator designs it. Operators should plan Assets as a federated index of OSS inventory references, not as a network inventory.

Automation: rules, steps and limits

JSM automation is rule based — trigger, conditions, actions, branches — and since 2025 is metered in automation steps rather than rule runs: each trigger, condition, action, branch or loop executed counts as a step, pooled at organisation level, with 3,000 steps per user in Standard, 6,500 in Premium and 9,500 in Enterprise, and Rovo-powered steps billed separately in Rovo credits (Atlassian support). For a telco, the implication is concrete: a mass incident that triggers enrichment, linking and notification rules on thousands of alerts consumes steps very quickly, so automation volumes should be modelled against the worst week of the year, not an average one.

Deployment gating is JSM’s most distinctive change capability. In Premium, change requests can gate deployments from CI/CD pipelines, holding a release until the change is approved and recording the deployment against the change (Atlassian support). Atlassian’s documentation names Bitbucket and Jenkins and lists further CI/CD tools elsewhere, so the supported set should be confirmed for the operator’s own pipelines. For cloud-native network functions released through GitOps, this is exactly the governance hook that ties the change record to the release.

AIOps, Rovo agents and MCP

Atlassian markets AIOps “powered by Rovo”: AI alert grouping, AI post-incident reviews and AI risk assessment of changes, plus an operations agent in early access that pulls in observability data (Atlassian AIOps). Its headline figures — 90% less alert noise and 85% faster resolution — are reported by early adopters and are vendor figures. Alert grouping requires Rovo to be activated and, according to Atlassian’s documentation, does not run on instances using customer-managed encryption keys, which is relevant for regulated operators.

The Rovo MCP server became generally available in February 2026 (Atlassian, February 2026), and its public repository lists JSM tools, which work only with API-token authentication enabled by an administrator (Atlassian MCP server). As with PagerDuty, the significance is that operator-built agents can read and write service records through a standard protocol.

What JSM contributes to the autonomy levels

Task dimension	Contribution	Level it enables
Awareness	Integrated alerting and on-call; observability integrations	L2
Analysis	AI alert grouping; links between incidents, changes and deployments	L2 to L3 in software domains
Decision	Change approval and AI risk assessment; deployment gating	L3 for software release decisions
Execution	Automation rules and webhooks; execution delegated to CI/CD and external tools	L2 to L3
Intent	None directly	—

Fit for a large telco

JSM fits the digital, IT and cloud-platform domains of an operator, and the engineering teams that build network software. It can be the master of incidents for those domains, synchronised with the corporate ITSM for anything that crosses into network services. Its use as the single ITSM backbone of an entire network operation would require the operator to build the telco service model, multi-organisation processes and mass-incident behaviour itself, and to accept a cloud-only deployment. That is possible, but it should be decided on evidence from the three use cases of section 16, not assumed.

12. OpenText: service management with operations, network management and on-premises options

OpenText — which absorbed the Micro Focus portfolio, including the former SMAX, Operations Bridge, Network Operations Management and Universal CMDB — is the candidate that combines service management, AIOps, network fault and configuration management and automation from one vendor, with genuine on-premises and air-gapped deployment. For operators where sovereignty, security classification or regulation rules out multi-tenant SaaS for the respond layer, that combination is rare.

Corporate context

OpenText reported fiscal 2026 revenue of $5.25 billion, up 1.5%, and lists IT operations management (ITOM) among its core revenue categories (OpenText Q4 FY26 results). It appointed Ayman Antoun as chief executive from April 2026 (OpenText). Its recent divestitures — eDOCS and Vertica in 2026, application modernisation earlier — were outside ITOM, but its annual report states that an end-to-end enterprise assessment launched in the fourth quarter of fiscal 2026 may lead to further divestitures and restructuring (OpenText 10-K, FY2026). For a buyer with a ten-year horizon, roadmap and continuity commitments should therefore be contractual, not assumed.

Service Management

OpenText Service Management covers ITSM, enterprise service management and IT asset management on one platform, with a native CMDB, codeless configuration, AI-generated change risk scores and the Aviator AI assistant, which runs on a private language model by default (OpenText Service Management). OpenText describes Aviator as enabling “agentic decision-making with autonomous actions or human in the loop oversight”, and states that on-premises Aviator can run fully air-gapped. Deployment options include SaaS in private or public cloud and on-premises.

AI Operations Management, Network Operations Management and discovery

The operations side is where OpenText’s proposal differs from the pure ITSM vendors:

• AI Operations Management (formerly Operations Bridge) correlates events against service models, which OpenText says cuts event volume by 30% to 95%, provides a diagnostic AI agent, and offers “thousands of predefined remediation tasks under policy guardrails” and more than 1,000 integrations, including ServiceNow, Jira, Splunk and Dynatrace (OpenText AI Operations Management). It names Türk Telekom as a reference, monitoring more than 30 technologies with 49% fewer service outages — a vendor-published figure.
• Network Operations Management covers network fault, performance, configuration and compliance, with support for more than 3,500 device types from over 250 vendors and documented scale of 80,000 monitored devices (OpenText NOM). In an operator it is most relevant for IP, enterprise and data-centre networks rather than radio or optical domains, which keep their own element managers.
• Universal Discovery and CMDB provides agentless, agent-based and change-driven discovery and is positioned to enrich an existing CMDB, with ServiceNow and BMC Helix integrations (OpenText UD/CMDB).
• Automation Center, the evolution of Operations Orchestration, provides workflows and integration with Terraform and Ansible, with AI-generated workflow code (OpenText Automation Center).

What OpenText contributes to the autonomy levels

Task dimension	Contribution	Level it enables
Awareness	AI Operations Management and NOM event, performance and configuration data	L2 to L3 for IT and IP domains
Analysis	Correlation against service models; diagnostic agent	L3 where service models are current
Decision	Change risk scores; policy guardrails on remediation	L3
Execution	Predefined remediation tasks; Automation Center with Ansible and Terraform	L3
Intent	None directly	—

Fit for a large telco

OpenText deserves evaluation where hybrid or on-premises deployment is a hard requirement, where the operator already runs Micro Focus heritage components, or where the value lies in linking AIOps, network operations and service management in one estate. The risk is to buy suite names rather than a proven end-to-end chain: the evaluation must identify the exact products and versions, and test the full flow from event to verified closure in the operator’s own infrastructure.

13. Side by side: automation and integration depth

The table compares the five platforms on the capabilities that decide seamless automation. Labels describe coverage as documented by each vendor in October 2026, not quality: Native means included in the core or a standard module; Module means a separately licensed component; Integration means delivered by connecting an external system; Limited means documented with notable constraints. Every cell should be verified against the edition and contract under evaluation.

Capability	ServiceNow	BMC Helix	PagerDuty	Jira Service Management	OpenText
Master record (03.3): incident, problem, change	Native	Native	Integration (syncs with master)	Native	Native
Event intelligence (03.1)	Module (Event Management, TSOM)	Module (Operations Management, AIOps)	Module (AIOps / Signal Intelligence)	Native AI alert grouping (Rovo required)	Module (AI Operations Management)
Live response and on-call (03.2)	Native, with incident communications	Native	Native, core strength	Native (from Opsgenie)	Native
Telecom data model and network events	Module (TSOM, TSM)	Integration	Integration	Integration (build in Assets)	Module (NOM for IP networks)
TM Forum Open APIs documented	TMF642, 688, 621, 639 and others; not 656 or 638	Not documented as a product feature	Not documented	Not documented	Not documented
Events to incident life-cycle sync	Native	Native (PSR), also to ServiceNow	Native, two-way to ServiceNow	Native for alerts	Native
Change risk and conflict detection	Native (risk, conflicts, success score)	Native, plus Change Risk Advisor agent	Change events correlation only	AI risk assessment; deployment gating	AI change risk scores
Technical execution engine	Flows and spokes; external orchestrators	Intelligent Automation; external orchestrators	Runbook Automation with runners in the network	Rules and webhooks; external CI/CD	Automation Center; remediation tasks
MCP server for external agents	Generally available	Controlled availability	Generally available	Generally available (API token for JSM)	Not documented
Agent-to-agent (A2A)	Client and server	Controlled availability	Not documented	Not documented	Not documented
Governance of AI agents	AI Control Tower (MCP, not A2A)	Agent Studio guardrails	Not documented	Rovo administration	Aviator policy and human-in-the-loop
On-premises deployment	Available, with constraints	Available (Remedy heritage)	Runbook Automation self-hosted; core is SaaS	No (Data Center ends 2029)	Available, including air-gapped
Automation metering risk	Licence per module and AI consumption	Licence per module	Add-ons and event volume	Automation steps and Rovo credits	Licence per module

Five observations from the comparison

The table supports five conclusions that should shape any shortlist:

• Only ServiceNow documents a telecom event model built on TM Forum APIs as a product, and even it omits the service problem and service inventory APIs. For every other platform, the telco model is integration work.
• PagerDuty and BMC Helix are the only two that document event-to-incident automation into a competitor’s ITSM. That makes them natural partners for a ServiceNow master, and natural overlaps with ServiceNow’s own event management.
• Execution is never the ITSM platform’s own job in a network. Every platform delegates network actions to orchestrators, controllers or CI/CD; the differences are in how well they pass context and receive structured results.
• Agentic interoperability has arrived, at different maturity levels. Generally available MCP servers at ServiceNow, PagerDuty and Atlassian mean an operator’s own agents can work across platforms; the governance of that traffic is uneven and must be designed centrally.
• Deployment model narrows the field quickly. An on-premises requirement removes Jira Service Management, constrains PagerDuty to its self-hosted automation, and favours OpenText and BMC Helix.

14. Five ways to assemble the respond layer

The decision with the largest long-term consequence is not the choice of product but the choice of assembly. Five patterns cover almost every large operator we see, and each one has a characteristic strength and failure mode.

Assembly A: single suite

ITSM, event management, telecom modules, automation and agents from one vendor, typically ServiceNow or BMC Helix. Advantages: one data model, fewer connectors, one commercial counterpart, a single audit trail. Risks: dependency, cost of extension module by module, and lack of depth in specific domains. Best for operators with a strong platform team, a willingness to standardise processes, and a clear federation design for network inventory.

Assembly B: suite plus live-response specialist

A suite as the master record and change authority, with PagerDuty running event orchestration, on-call, response and first-line runbook automation, synchronised in both directions. Advantages: the best tool for the first hour without migrating the master. Risks: duplicated event intelligence licences, synchronisation conflicts, and the slow drift of the specialist into a second master. The synchronisation contract — which system owns which field, and who wins a conflict — must be written before integration begins.

Assembly C: AIOps layer in front of another vendor’s ITSM

BMC Helix Operations Management and Proactive Service Resolution, or OpenText AI Operations Management, creating and maintaining incidents in a ServiceNow or in-house master. Advantages: reuse of an existing operations investment and a documented event-to-incident life cycle. Risks: two vendors’ correlation logic and service models, which must agree on what a service is. This is the assembly most often found in brownfield operators, usually by accident rather than design.

Assembly D: engineering domain platform federated to a corporate master

Jira Service Management, often with PagerDuty, as the master for digital, IT and cloud-native platform teams, federated with the corporate ITSM for anything that crosses into network or customer services. Advantages: engineering teams work in their own toolchain, with deployment gating tied to change. Risks: two masters if the boundary is vague; the federation rule must say which incidents are promoted to the corporate record and when.

Assembly E: operator-owned trouble ticketing as master

The operator keeps an in-house or OSS trouble-ticketing system as master for network and customer incidents, and synchronises the commercial platforms to it through TMF621 and TMF642. Advantages: continuity of a system that already encodes the operator’s processes, and full control of the data. Risks: the operator becomes a software vendor to itself, with the engineering, SRE, security and lifecycle obligations that implies. As we argued in our earlier analysis, keeping an internal master and synchronising modern platforms to it is better than running two masters — provided identifiers, states and relationships can be mirrored.

Comparing the assemblies

Assembly	Time to value	Integration effort	Dependency	Typical fit
A Single suite	Medium	Low inside, high to OSS	High	Operators standardising on one platform
B Suite plus specialist	Fast for response	Medium (sync contract)	Medium	NOCs that need a better first hour now
C AIOps in front of another ITSM	Medium	Medium to high	Medium	Brownfield estates with existing AIOps
D Engineering platform federated	Fast in digital domains	Medium (promotion rules)	Low to medium	Digital and cloud-native platform teams
E Operator-owned master	Slow	High, permanent	Low	Operators with strong software capability

The standards that hold the assemblies together

Whichever assembly is chosen, the integration contracts should be expressed in standard objects wherever possible. TM Forum’s Open APIs provide them, at uneven maturity on the public repositories in October 2026:

API	Object	Public version
TMF642	Alarm management	v5.0.1
TMF656	Service problem management	v5.1.0
TMF621	Trouble ticket	v5.0.1
TMF724	Incident management (ITIL life cycle)	v4.0.0
TMF655	Change management	v4.0.0
TMF638 / TMF639	Service and resource inventory	v5.0.0
TMF640	Service activation and configuration	v4.0.0
TMF697 / TMF646	Work order and appointment (field)	v4.0.0
TMF921	Intent management	v5.0.0

Two points stand out. TMF724 Incident Management exists and has been adopted by at least one large operator’s systems (TM Forum conformance report), and it is being aligned with IETF work on network incidents (IETF liaison), but its public version is still v4. And none of the five ITSM vendors documents TMF724 or TMF656 as a product interface. In practice, the master-record contract is usually TMF621 plus the vendor’s own API, which is acceptable as long as the semantics — states, roles, exceptions, timing — are agreed explicitly. API conformance alone does not deliver seamless operation, and it certainly does not certify autonomy.

On the architecture side, TM Forum’s Level 4 target architecture (IG1251C) and its agent architecture (IG1251D) describe how autonomous domains, a knowledge and intelligence platform and agents fit across business, service and resource layers (TM Forum IG1251C; IG1251D). ETSI’s Zero-touch network and Service Management work covers the reference architecture and closed-loop automation across domains and management layers (ETSI GS ZSM 002; GS ZSM 009-1). And the process side moved in 2026: PeopleCert launched ITIL (Version 5) in January, as an evolution of ITIL 4 with guidance for AI and cloud operations (PeopleCert). None of these documents chooses a platform; all of them assume that the respond layer exposes its decisions and records to machines.

15. Governed automation: from scripts to closed loops

The platforms differ in how they automate; the governance the operator needs does not. Whatever the combination, the respond layer moves through four stages of automation, and each stage needs a specific set of controls before the next is attempted. They map onto the TM Forum levels of section 5, and they echo the guardrails we set out in the blueprint for autonomous operations.

Stage 1: assistance and productivity

The system classifies, summarises, proposes probable causes, suggests runbooks and completes evidence. Every platform in this article now does this with generative AI. It is useful, it shortens the first hour, and it changes nothing about who decides. Its main risk is confident summaries of wrong context, which is why the record must keep links to the evidence, not only the summary.

Stage 2: supervised automation

The system groups alerts, enriches incidents, assigns teams, opens bridges, requests authorisations and prepares changes. Humans keep every decision that carries risk. This is where most of the measurable value of the respond layer is captured today: fewer incidents, faster engagement of the right owner, diagnostics already attached when the engineer opens the record.

Stage 3: autonomous execution of low-risk actions

For well-understood conditions, the system runs a check, restarts a non-critical process, corrects a permitted parameter or executes a pre-authorised rollback, verifies a measurable result and escalates on uncertainty. This is where ITSM governance becomes machine-readable: the action is a standard change or a catalogued remediation, the authorisation is a policy, the evidence lands on the record automatically, and closure depends on verification.

Stage 4: coordinated closed loops across domains

A service crosses several domains, and specialised agents and orchestrators cooperate under one service policy without executing incompatible actions. This stage needs a coordinator or arbitration mechanism to prevent contradictory loops, concurrent changes on shared resources, and local decisions that make the global result worse. The ITSM record is the natural place to hold the lock: one active remediation per scope, visible to every loop. Distinguishing local domain loops (radio self-healing, for instance) from end-to-end coordination matters here: not every local loop should pass through a central change board, but every local loop needs declared limits, conflict rules and an escalation path.

Autonomy is granted per action, not per platform

Autonomy is granted by use case, action, scope and context, never as a generic permission over the network. A policy can authorise low-impact restarts, require approval for mass changes, and block any action during a major incident or when the confidence of the diagnosis is below a threshold. Written as a policy object, it looks like this:

policy: transport-link-flap-remediation
scope:
  service_class: [enterprise-vpn, mobile-backhaul]
  max_elements_per_action: 1
  max_actions_per_hour: 3
preconditions:
  diagnosis_confidence: ">= 0.85"
  no_active_major_incident_on_scope: true
  no_change_in_progress_on_scope: true
  outside_change_freeze: true
action:
  catalogue_item: STD-CHG-0142 # pre-approved standard change
  runbook: link-dampening-and-reroute
  identity: svc-respond-automation # least-privilege service account
verification:
  test: active-probe-latency-loss
  window_minutes: 15
  success: "loss < 0.1% and p95_latency within SLA"
on_failure: rollback, reopen, page service owner
audit: attach_to_master_record

The format does not matter; the content does. The policy names the scope, the preconditions, the pre-approved change, the identity, the verification and the failure path. Every platform in this article can store some of this; none of them, on its own, enforces all of it across the other systems. That enforcement is an architectural responsibility.

The minimum control set

Before any action runs without a human, the operator should be able to show each of these controls working:

• Service identities with least privilege, separate per automation, never a shared all-powerful credential inside an agent.
• Segregation of duties between whoever writes an automation, whoever approves it and whoever runs it.
• Dynamic approvals that tighten during major incidents, freezes and peak periods.
• Dry-run or simulation where the target system supports it.
• An inventory of permitted actions, versioned, with an owner for each.
• Thresholds and rate limits on scope and frequency.
• A kill switch that stops all automated actions on a scope, tested regularly.
• Compensation and rollback defined before the action, not after.
• Evidence written to the master record for every proposal and every execution.
• Independent verification by a system other than the one that executed the action.

16. Three end-to-end use cases that should decide the purchase

A platform that shines in a self-service demonstration but cannot run these three journeys with real systems has not yet shown that it can govern a large telco. Each case should be executed by every finalist with realistic load, representative integrations and deliberately injected failures.

Case 1: a mass incident caused by a network change

Situation: thousands of alarms, degradation across several services, several operations contractors involved.

• Sequence to test: correlation → affected service and customers → association with the change → major incident → rollback policy → execution → service tests → customer update → post-incident review.
• Failure injection: duplicated events from two monitors; the change record created twenty minutes late; a contractor’s tool that does not acknowledge.
• Indicators: time to recognise impact, duplicate incidents avoided, mean time to restore, share of recoveries independently verified, number of human interventions required.

Case 2: intermittent degradation of enterprise connectivity

Situation: the customer experiences poor quality but no element is fully down.

• Sequence to test: probes, metrics, history and dependencies → probable-cause diagnosis → decision on action → technical task and customer communication → validation of the experience.
• Failure injection: inconsistent inventory data for the customer’s circuit; the customer opens a case in parallel through the enterprise portal.
• Indicators: time to isolate, complaints avoided, recurrence, service quality after the action, SLA compliance.

Case 3: a planned change with multi-domain risk

Situation: an upgrade in a critical window touches shared resources.

• Sequence to test: change scope → computation of exposed services → calendar and concurrency conflicts → approval policy → digital method of procedure → step-by-step execution → verification → rollback if it fails.
• Failure injection: authorisation denied mid-window; rollback fails on one element; an unrelated incident opens on the same scope during the change.
• Indicators: change failure rate, unavailability attributed to change, successful reversals, share of automated changes with complete evidence.

What the evaluation team should ask to see

For each case the finalist should hand over evidence, not slides: end-to-end traces with timestamps per step, the full record history, the synchronisation log between platforms, the identities that executed each action, and the behaviour when an API was down. Fault injection should include at least duplicated events, a failed API, inconsistent inventory, a denied authorisation and a failed rollback. Vendors that decline fault injection are telling the operator something important.

17. A selection matrix built for a telco

We do not assign numerical scores to vendors without a comparable test. We can set out the criteria that should carry most weight, as a starting point to adapt to each operator:

Dimension	Indicative weight	Evaluation question
OSS, inventory and API integration	20%	Does it relate alarms, services, resources, changes and customers without duplicating masters?
Seamless automation and closed loops	20%	Does it orchestrate and verify with policies, audit, rollback and exceptions?
ITSM governance, incidents and changes	15%	Does it manage end-to-end accountability and major incidents with control?
Multi-technology and multi-organisation scale	15%	Does it handle mass events and many suppliers without degrading the flows?
Open architecture and reversibility	10%	Can components be replaced, data extracted and runbooks reused elsewhere?
Security, resilience and compliance	10%	Segregation, traceability, continuity, and controls over agents?
Five-year total cost of ownership	5%	Licences, modules, AI consumption, APIs, integration, administration and exit?
Ecosystem, support and evolution	5%	Demonstrated support and integrations in the target telco environment?
Total	100%

Two adjustments make the matrix honest. First, score the combination, not the product: if the shortlist is “ServiceNow alone” against “BMC Helix plus PagerDuty”, the matrix must compare the assemblies. Second, weight five-year cost more heavily when AI features are priced by consumption, because consumption pricing turns a successful automation programme into a growing bill.

Contract clauses that protect the architecture

The contract is part of the architecture. The following clauses are worth negotiating before signature, while the operator still has leverage:

• API access and limits: documented rate limits for integration and automation traffic, with headroom for mass incidents.
• Data export: complete, scheduled export of records, relationships, attachments and audit logs in open formats.
• AI terms: what is included, how consumption is metered, where models run, whether operator data trains anything, and how agent actions are logged.
• Availability and continuity: service levels for the platform itself, and a tested degraded mode for major incidents when the platform is unavailable.
• Version continuity: notice periods for deprecations, especially for APIs and integration components.
• Reversibility: exit assistance, and portability of workflows and runbooks where technically possible.

18. Implementation roadmap, mapped to the autonomy levels

The roadmap below is sequenced by dependency, not by vendor milestones. Each phase has an exit criterion expressed in the respond-layer indicators of section 5.

Phase 0: diagnosis and target model

Identify the flows with the greatest service impact; map responsibilities, duplicate records, data quality and decisions. Declare the master incident, the canonical objects and the change policies. Score the current level per flow honestly, using the IG1252 task dimensions. Exit criterion: one written master-data map signed by operations, IT and architecture.

Phase 1: governance and visibility (towards L2)

Normalise major incidents, priorities, SLAs, changes and escalations, and build the end-to-end dashboard. Connect two or three relevant observability and inventory sources first, not twenty. Exit criterion: one master record per incident for the selected flows, with identifiers mirrored in every connected system.

Phase 2: context and correlation (L2 to L3)

Reconcile events, dependencies, changes and services; build enrichment pipelines, cause and impact relationships and deduplication. Measure precision and make sure the system does not create more work than it removes. Exit criterion: event-to-incident compression and duplicate rate measured weekly, with impact attached at creation for the majority of incidents in scope.

Phase 3: safe automation (L3)

Digitise methods of procedure and runbooks, version them, validate them. Automate frequent low-risk actions with rollback and independent verification, and keep humans on sensitive decisions. Exit criterion: a published catalogue of pre-authorised actions, each with its policy, identity and verification, and a measured automation rate per flow.

Phase 4: cross-domain closed loops (towards L4)

Coordinate network, IT and experience loops; formalise policies of autonomy, conflict and supervision; move from technical events to service objectives and intents. Exit criterion: at least one flow assessed at Level 4 for the decision and execution dimensions, with humans supervising outcomes rather than approving actions.

Results should be measured primarily in availability, customer impact, incidents avoided, field dispatches avoided, mean time to detect and restore, failed changes, share of actions resolved without intervention, recurrence and operating-cost efficiency. The development and lifecycle side of this — how automations and agents are built, tested and released — is covered in our analysis of the agentic development model for NOC and SOC.

19. Conclusion: a service operating system, not a bigger ticketing tool

The public evidence on measurable results points in one direction: the largest gains come from autonomous-network and AIOps programmes, not from ITSM tools on their own. Deutsche Telekom reports handling major network events in about a minute instead of hours with its radio guardian agent; China Mobile reports average repair time for network faults and complaints down 30% in its Level 4 programme (TelecomLead, October 2026). The ITSM cases with numbers — Vodafone Idea, BT, the unnamed US operator — show strong results on narrower scopes. The lesson is not that ITSM matters less; it is that ITSM delivers when it is the governance spine of those programmes, and very little when it is a separate queue beside them.

Five positions worth taking

• Name one master record per scope before choosing any platform. Rival masters cost more than any licence.
• Buy the respond layer as three capabilities. Event intelligence, live response and the system of record can come from one vendor or three, but they must be specified, tested and owned separately.
• Move the decision task, not only the analysis. Machine-readable pre-authorisation, risk context at decision time and accountability for machine actors are what take a flow from Level 2 to Level 3 and beyond.
• Federate the network; do not copy it. The CMDB references the OSS inventory; it does not become a second one.
• Keep operational knowledge and agents portable. Generally available MCP servers make it possible for the operator’s own agents to work across platforms; the governance of those agents belongs to the operator.

Where each platform fits

ServiceNow and BMC Helix start as strong candidates for governing high-complexity processes; ServiceNow has the broadest telecom-specific catalogue and agentic programme, BMC Helix the most useful event-to-incident flow across vendors. PagerDuty is the specialist to beat for the live minutes in front of any master. Jira Service Management is particularly valuable where IT, cloud and software development converge, and less so as the backbone of a whole network operation. OpenText is competitive where on-premises deployment and an integrated operations chain matter more than breadth. Broadcom, Ivanti, Xurrent, ManageEngine and the others have roles that should be judged on the operator’s own economics.

No selection will be right if the ITSM is chosen in isolation from operations automation. The winning architecture is the one that connects observability, impact understanding, inventory, governance, orchestration and verification robustly, without creating an artificial data monopoly or an unnecessary commercial dependency. The real question is not “which ITSM has the most AI?” but “which architecture restores the service best, coordinates the whole operation, and increases autonomy without losing control?”.

A concrete next step

Take the last three major incidents, map each one against the ten interfaces of section 3 and the eight continuities of section 4, and mark every point where a human had to rebuild context, decide without policy or close without evidence. That map is the requirements document for the respond layer, and the honest baseline for the autonomy level of each flow.

Related TelcoCrux analysis

• Network discovery, inventory and observability compared — the full five-block reference architecture this article zooms into.
• The autonomous networks journey — the TM Forum levels, the task dimensions and the cases at Level 4.
• Network change management with automation, AI and digital twins — why most major outages start with a change, and how to govern it.
• The autonomous operations blueprint — data, closed loops, agents and guardrails.
• The NOC/SOC operating model with AI agents — decision rights and roles in an AI-assisted operation.

---

At TelcoCrux, we help operators and the technology companies that sell to them design the respond layer of their operations: master-record and integration architecture, ITSM and incident-response platform selection, proof-of-concept design with fault injection, and the policies that let automation climb the TM Forum autonomy levels without losing control. See how we work and who is behind TelcoCrux, or write to info@telcocrux.com if you want an independent review of your ITSM and operations automation architecture.