SLM Installed Base
Last updated 12 Oct 2026
At a glance
Subscription Lifecycle Management (SLM) keeps the runtime truth of what each customer has right now: active product instances, their configuration and their lifecycle state. It is underpinned by Product Inventory (TMF637), and COM, billing, care and assurance all depend on it. When it is missing, what was ordered, delivered and billed drift apart.
The picture
SLM activation flow: from channel order through COM and SOM to billing
How it works
More than a list of products
"Product Inventory" sounds like a passive store. SLM is the same record treated as an active, lifecycle-aware capability that answers one question: what does this customer have right now, and in what state? It covers the subscription from creation through modification and suspension to termination.
Lifecycle states such as created, active, suspended, pending disconnect and terminated govern what every downstream system does: whether billing charges, whether care can sell a change, whether assurance treats a fault as customer-affecting.
Who depends on it
| System | What it uses SLM for |
|---|---|
| COM | Reads the current instance to compute the delta for modify and cease orders; writes the result on completion |
| SOM / Service Inventory | Service instances reference the parent product instance held in SLM |
| Billing | The authoritative list of active subscriptions, price plans, start dates and options |
| Customer care | What the customer has, shown to the agent |
| Assurance | Correlating a network fault to the customers it affects |
How billing starts charging
Order completes
COMSOM confirms every service order item is fulfilled; COM moves the product order to completed.
COM writes to SLM
TMF637The product instance is created or updated as active, with effective date, chosen characteristics and price plan references.
SLM publishes an event
SLMA product state-change event tells every subscriber that a subscription is now active.
Billing activates charging
BillingBilling takes the event (or queries SLM), reads price plan, billing account, start date and characteristics, and activates the billing items.
Billing does not decide on its own what to charge. It consumes SLM. The same pattern runs for modify (instance updated, charges re-rated from the effective date) and cease (instance terminated, charging stops, final bill).
A capability, not one box
COM manages the commercial lifecycle, SOM manages service delivery, and billing consumes the result. SLM is where those meet, so it behaves as an orchestrated capability across them even when one product hosts the Product Inventory. Its value depends on the links: product instance to service instances below and to billing items alongside. Inventories without those cross-references cannot support impact analysis or assurance.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product instance (subscription) | SLM / Product Inventory | CRM / self-service | Product Catalog | TMF637. Created and changed only through completed orders. |
| Product instance lifecycle state | SLM / Product Inventory | COM (triggers changes) | — | Active, suspended, terminated and so on drive billing and care behaviour. |
| Billing items and charges | Billing | — | SLM / Product Inventory | Derived from the active product instance, not decided independently. |
| Service instance | Service Inventory | SOM | SLM / Product Inventory | TMF638. References its parent product instance. |
In practice
Establishing SLM means migrating the installed base into it, and the installed base rarely has clean product lineage. Subscriptions sold years ago may map to offerings that no longer exist, and billing, service and network records for the same customer often disagree. Reconciliation is a programme of its own, and it has to decide which source wins for each field.
Until that is done, modify and cease orders for migrated customers are the first place the gaps show.
The trade-off
What it solves
It gives the estate one runtime answer to "what does this customer have", which billing, care, COM and assurance can all consume instead of keeping their own copies.
What it does not solve
- Historical data. Subscriptions created outside the model must still be reconciled and migrated.
- Service and network truth. SLM records the product; service and resource inventories record what delivers it.
- Billing defects in rating and charging once the right subscription is known.
What it adds
- Every consumer must move from its own copy to SLM events, one integration at a time.
- Lifecycle states must mean the same thing to COM, billing and care.
- A reconciliation process between SLM, billing and service inventory that never fully goes away.
Architecture decision
Which system holds subscription truth during the transformation?
A dedicated Product Inventory, with billing as a consumer
Choose when billing is to be replaced or decoupled, several BSS systems need the same subscription view, and the installed base can be migrated.
Billing stays the record for now
Choose when billing is stable and staying, there is a single product line, and there is a dated plan to move the record out before billing is touched.
Breaks if New orders write to SLM while existing customers stay only in billing. Two partial truths exist, and every modify order has to guess which one to trust.
Takeaways
Key Takeaways
- SLM is the runtime truth of what each customer has, underpinned by Product Inventory (TMF637)
- Billing should consume SLM, not decide independently what is active
- COM writes SLM on completion and reads it for modify and cease orders
- Lifecycle states in SLM drive what billing, care and assurance do
- Using billing or CRM as the inventory couples everything to it and makes replacement risky
Check yourself
A customer cancelled broadband three months ago and is still being charged. Where do you look first?Show answerHide
At the product instance in SLM. If it is still active, the cease order did not complete or did not write back. If it is terminated, billing did not consume the event, or billing is acting as its own inventory.
Why is a modify order for a customer migrated from a legacy stack more likely to fall out than one for a new customer?Show answerHide
COM computes the delta from the current product instance. Migrated customers often have incomplete or wrongly mapped instances, so the delta is wrong or cannot be computed.