Trouble-to-Resolve Flow

What Is Trouble-to-Resolve?

The Trouble-to-Resolve (T2R) process is the second most critical end-to-end flow in a telco, sitting alongside Lead-to-Cash as a core operational capability. While L2C focuses on selling and delivering services, T2R focuses on maintaining service quality and resolving issues when things go wrong.

T2R encompasses the entire assurance lifecycle: detecting a problem (proactively or via customer report), diagnosing its root cause, resolving it, and confirming resolution with the customer. In eTOM terms, T2R traverses the Assurance vertical across CRM, SM&O, and RM&O horizontal layers.

Proactive vs Reactive Assurance

Assurance processes can be triggered in two fundamentally different ways. Understanding this distinction is critical because it determines the starting point of the T2R flow and which systems initiate the process.

The Complete T2R Flow

The Trouble-to-Resolve flow consists of six major stages, whether triggered reactively by a customer or proactively by network monitoring. Each stage has clear system ownership and eTOM process mappings.

Stage 1: Detection and Reporting

The T2R flow begins when an issue is first identified. In the reactive path, this happens when a customer contacts the service desk. In the proactive path, this happens when network monitoring detects an alarm or performance degradation. The key challenge at this stage is capturing enough information to enable efficient diagnosis.

Stage 2: Trouble Ticket Management

The Trouble Ticket is the central tracking entity for the entire T2R process. It links the reported problem to the affected customer, services, and resources. It tracks the lifecycle from creation through diagnosis, resolution, and closure. In TM Forum terms, the Trouble Ticket is defined by TMF621 (Trouble Ticket API).

Stage 3: Diagnosis & Root Cause Analysis

Diagnosis is the most technically complex stage of T2R. It requires traversing from the customer-visible symptom down through the service and resource layers to identify the root cause. This traversal relies heavily on the topology information stored in Service Inventory and Resource Inventory.

Stage 4: Resolution & Service Restoration

Once the root cause is identified, the resolution stage executes the fix. The nature of the resolution depends on the root cause — it may be a remote configuration change, a software patch, a hardware replacement, or a field visit. The goal is always to restore the affected service(s) to their agreed quality levels as quickly as possible.

Stage 5-6: Verification and Closure

After the fix is applied, verification confirms that the service has been restored. This may involve automated service tests (TMF653 Service Test Management), performance metric checks, and customer confirmation. Only after successful verification should the trouble ticket be moved to "resolved" status.

Closure adds the final resolution details, captures metrics (mean time to detect, mean time to resolve), and updates knowledge bases for future diagnosis. In many implementations, the ticket moves to "resolved" first, giving the customer a window to confirm or reopen, before automatically closing after a defined period.

1. Apply the fix (remote or field)
2. Run automated service test to verify restoration
3. Update trouble ticket status to "resolved"
4. Notify the customer of resolution
5. Wait for customer confirmation window (e.g., 48 hours)
6. Auto-close the ticket if no reopening
7. Capture MTTD, MTTR, and resolution category for reporting

eTOM Level 2 Process Map for T2R

TM Forum API Touchpoints for T2R

SLA Management and Key Metrics

T2R performance is measured by a set of well-defined metrics. These metrics drive SLA compliance, operational improvement, and regulatory reporting. Every T2R implementation must capture them.

The Critical Dependency on Inventory

The T2R process is only as good as the inventory data it relies on. If the Service Inventory does not accurately reflect which CFS instances a customer has, diagnosis will fail. If the Resource Inventory does not accurately reflect the network topology, root cause analysis will be impossible.

You cannot assure what you cannot inventory. If you do not know what services a customer has and what resources support them, your assurance process is guesswork.