The L2C–Assurance Bridge
Last updated 14 Oct 2026
At a glance
What Lead-to-Cash writes is what assurance correlates against. Product, service and resource inventory records, linked resource to service to product to customer, are the shared data both sides act on. The bridge also runs back: assurance signals become credits, upgrade orders and proactive notifications.
The picture
Fulfilment writes ↓
The shared record
Assurance reads ↑
Written by: Lead to order: CRM
Customer and account
CRM
Read for: Proactive notification, retention
Written by: COM at order completion
Product instance + SLA terms
SLM / product inventory · TMF637
Read for: Customer impact, SLA monitoring
Written by: SOM during decomposition
CFS and RFS instances
Service inventory · TMF638
Read for: Service impact, quality scoring
Written by: ROM and activation
Resources and topology
Resource inventory · TMF639
Read for: Alarm correlation, root cause (TMF642 alarm lands here)
Intact: an alarm on a resource is walked up to services, products, SLA terms and named customers.
How it works
Every L2C output has an assurance consumer
| L2C output | Assurance consumer | If missing or wrong |
|---|---|---|
| Product instances in SLM / product inventory | Customer impact analysis | All faults treated equally, whatever the commercial value |
| CFS instances in service inventory | Fault correlation to services | Alarms stay isolated, with no service view |
| RFS-to-resource links in resource inventory | Root cause analysis | Diagnosis becomes manual; restore times rise |
| SLA terms from the order or contract | SLA monitoring | Breaches found when the customer escalates |
| CFS-to-RFS decomposition | Service quality scoring | Monitoring stays resource-only |
| Customer-product-service linkage | Proactive notification | Communication is reactive only |
Five things L2C must get right
- Catalog-driven decomposition. Orders decompose product → CFS → RFS → resource by catalog rules. Ad-hoc provisioning breaks the topology assurance relies on.
- Inventory population. Every fulfilled service creates accurate SLM, service and resource records, with the relationships between them.
- SLA propagation. SLA terms set at order time reach assurance systems as data. Terms held only in CRM or a contract document cannot be measured automatically.
- Topology accuracy. Service-to-resource mappings match the real network. A CFS that claims resources it does not use produces false positives and missed impact.
- Lifecycle consistency. Modifications and cessations update all three inventories together. Stale records are worse than none, because they create false confidence.
Assurance feeds back
| Assurance signal | L2C action |
|---|---|
| SLA breach confirmed | Billing credit raised automatically |
| Recurring breaches on one customer | Upgrade or migration offer |
| High fault density on one resource | Capacity upgrade or technology refresh order |
| Repeat complaints | Retention action in CRM |
| Network event affecting many customers | Proactive notification through CRM channels |
| Performance trends | Input to capacity planning and investment |
Two modes on the same data
In eTOM, Fulfilment and Assurance are parallel verticals across the same horizontal layers. At the customer layer both act on the customer, account and product portfolio; at service management, on service instances and topology; at resource management, on physical and logical resources; at supplier/partner, on agreements and escalation paths. When both sides share inventories and catalog models the bridge is structural. When they do not, each handoff needs manual translation, and the records diverge.
A simple test: when a customer calls about poor service, can the agent see in real time whether a known network issue affects that customer? If not, the bridge is broken somewhere along the chain in the picture.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product instance (what the customer has) | SLM / product inventory | — | Fault management, ITSM, CRM | TMF637 |
| SLA terms for a product instance | SLM or contract management, depending on estate | — | SLA management | Often split; where it lives decides whether it can be measured |
| CFS and RFS instances and their links | Service inventory | — | Fault management | TMF638. Written by SOM. |
| Resources and topology | Resource inventory | — | Fault management, CMDB | TMF639. Written by ROM and activation, reconciled with discovery. |
| Alarms | Fault management / alarm platform | — | ITSM | TMF642 |
| Incidents and trouble tickets | ITSM platform | Service desk, CRM | — | TMF621 |
| SLA credits | Billing | — | SLA management, CRM | Raised from a confirmed breach |
In practice
Billing truth, service truth and network truth frequently diverge in real estates. Billing knows what is charged, service inventory knows what was designed, and the network knows what is actually configured. The bridge only holds if these are reconciled on a schedule; without that, assurance correlates against records that no longer describe the network.
Historical services often lack clean product lineage, especially where legacy CRM or order systems modelled products differently from the current catalog. Many programmes link new services properly and leave the installed base unlinked, intending to clean it up later. In practice the clean-up is rarely funded once the new stack is live, so the gap persists. It is safer to plan the back-fill, or the migration that removes the need for it, as part of the programme.
The feedback loop is where operational maturity shows. Automatic credits and proactive notifications depend on every link in the chain being present; most estates achieve them for some product lines before others.
The trade-off
What it solves
Treating the inventories as shared data, written once by fulfilment and read by assurance, removes manual translation between delivery and operations and makes customer impact computable.
What it does not solve
- It does not fix the installed base, which was provisioned outside the current models.
- It does not keep records true when the network is changed outside the order flow.
- It does not decide where SLA terms are mastered; that still has to be designed.
What it adds
- Fulfilment carries the cost of data quality that mainly benefits assurance, so ownership of that cost needs agreeing.
- Modify and cease flows must update three inventories together, or the chain breaks silently.
- Continuous reconciliation between billing, inventory and network discovery.
Architecture decision
Where should SLA terms be mastered so assurance can measure them?
On the product instance in SLM / product inventory
Choose when SLAs follow standard tiers defined in the product catalog
In contract or SLA management, linked to the product instance
Choose when SLAs are negotiated per enterprise contract and vary from the catalog tiers
Breaks if SLA terms stay only in a contract document or CRM note with no link to the product instance: monitoring cannot find them, and breaches are found by the customer.
Takeaways
Key Takeaways
- What L2C writes is what assurance correlates against; the handoff is structural, not optional.
- Assurance walks the chain resource → service → product → customer; a missing link stops it.
- Decomposition, inventory population, SLA propagation, topology accuracy and lifecycle consistency all have to hold.
- Assurance feeds back into L2C through credits, upgrade orders, retention and proactive notification.
- The installed base is usually the weakest part of the bridge and needs its own plan.
Check yourself
A customer ceased one site last month, but a fault on that site’s old access port still raises an incident against them. What failed?Show answerHide
Lifecycle consistency: the cease did not update all three inventories together, so the stale service and resource links are still being correlated.
Gold SLA customers are being given the same priority as everyone else, although impact analysis identifies them correctly. Where is the break?Show answerHide
SLA propagation. The customer link exists, but the SLA terms are not available to assurance as data; they likely sit only in a contract or CRM record.