SLM Installed Base

Why SLM — not just Product Inventory — is the single runtime truth of what each customer has, how it bridges COM, SOM, and billing, and what breaks when it is missing or misused.

What Is Subscription Lifecycle Management?

Subscription Lifecycle Management (SLM) is the capability that maintains the single runtime truth of what each customer currently has — their active product instances, their configuration, their lifecycle state, and their relationship to billing and service delivery. In TM Forum terms, SLM is underpinned by Product Inventory (TMF637), but the concept extends beyond a simple inventory: it encompasses the full lifecycle of a subscription from creation through modification, suspension, and eventual termination.

The term "Product Inventory" can be misleading. It suggests a passive datastore — a list of things. SLM reframes this as an active, lifecycle-aware capability that answers the most fundamental question in any telco operation: "What does this customer have right now, and in what state?"

Subscription Lifecycle Management (SLM)

The OSS capability responsible for maintaining the authoritative runtime record of what each customer currently has — their active product instances, configuration, lifecycle state, and service-layer associations. SLM is the system of record for Product Instances (TMF637) and serves as the single source of truth that SOM, billing, service assurance, and customer care systems depend on.

Why SLM Matters End-to-End

SLM bridges what was ordered (COM), what was delivered (SOM/ROM), and what is being charged (Billing). Without it, these truths diverge.

COM — reads SLM to calculate the delta between current and desired state for modify/cease orders
SOM — service inventory references the parent product instance held in SLM
Billing — reads SLM as the authoritative source of active subscriptions and pricing
Customer Care — relies on SLM to show agents what the customer currently has
Assurance — correlates network faults to affected customers via SLM

SLM and Billing: The Critical Dependency

The relationship between SLM and billing is arguably the most critical integration in the entire BSS stack. Billing does not independently decide what to charge — it reads from SLM to determine which product instances are active, what their price plans are, when they were activated, and what configuration options were selected.

How Billing Reads SLM

Order Completes in COM

COM

COM receives confirmation from SOM that all service order items are fulfilled. COM transitions the product order to "completed" state.

COM Writes to SLM

COM → SLM

COM creates or updates the product instance in SLM (TMF637). The instance state is set to "active" with the effective date, selected characteristics, and price plan references.

SLM Emits Lifecycle Event

SLM

SLM publishes a product instance lifecycle event (e.g., ProductInventoryStateChangeEvent via TMF637) notifying all subscribers that a new active subscription exists.

Billing Activates Charging

Billing

Billing receives the event (or queries SLM), reads the product instance details — price plan, billing account, start date, characteristics — and activates the corresponding billing items. The customer is now being charged.

What Happens When SLM and Billing Disagree

When SLM and billing are out of sync, one of two things happens: customers are billed for services they no longer have (revenue integrity issue and regulatory risk), or customers are not billed for active services (revenue leakage). Both are common in legacy environments where billing was treated as the product inventory. The only reliable fix is to establish SLM as the single source of truth and make billing a consumer of SLM events.

SLM Anti-Patterns

Using Billing or CRM as SLM

When billing or CRM is the only system that knows what the customer has, you lose catalog linkage, lifecycle states, and the ability to calculate modify-order deltas. Replacing that system becomes an existential risk to the entire BSS stack. SLM must be an independent, TMF637-compliant capability.

Section 3.12 Key Takeaways

SLM is the capability that maintains the single runtime truth of what each customer has — underpinned by Product Inventory (TMF637)
SLM answers the most important question in telco operations: "What does this customer have right now, and in what state?"
Billing depends on SLM as its source of truth for active subscriptions, pricing, and revenue recognition
COM and SOM jointly contribute to SLM: COM manages the commercial lifecycle, SOM manages service delivery
Product instance lifecycle states (created → active → suspended → pending disconnect → terminated) govern all downstream behaviour
SLM is not a single system but an orchestrated capability spanning COM, SOM, and billing
Using billing or CRM as SLM is a common anti-pattern that creates tight coupling and makes system replacement extremely risky
Disconnected inventories (product, service, resource) without cross-references make impact analysis and assurance impossible