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