Skip to main content
BSS/OSS Academy
T2R — post-fulfilment

Trouble-to-Resolve

The runtime phase that keeps a live service live. Trouble-to-Resolve runs per incident rather than per order: an alarm, a threshold breach or a customer-reported fault arrives, is correlated to an affected service, assessed against what was committed at sale, worked and closed.

Clock
Runtime
Unit of work
Per incident
Cadence
Minutes to hours
Produces
A restored service

Where the chain closes

The chain closes here. Chronic-fault patterns and take-up data are the only honest inputs to the next Concept-to-Market cycle — which is why the chain is a loop, not a line.

Correlation is an inventory lookup, not an act of intelligence. Mapping a failing port to the customers it affects needs a resource record that links to a service instance that links to a subscribed product. Where Lead-to-Cash never wrote that chain — the service was activated outside the catalog-driven path, or migrated in without lineage — the alarm attaches to nothing, and the fault is discovered when the customer calls.

T2R also holds the only operational evidence about the products C2M designed: which fail repeatedly, which are never taken up, and which service-level commitments the resources beneath them cannot in fact meet.

Modules in this phase

Foundations and the reference modules — TMF Open APIs, frameworks, architecture patterns and the vendor landscape — apply across all three phases, so they are not listed under any one of them.

Back to the start

T2R closes the loop. Chronic-fault patterns and take-up data go back into Concept-to-Market as the evidence for the next design-time cycle.

Start again: C2M — Concept-to-Market