A customer selecting a telecom plan may see one simple product.
Behind that product can be a surprisingly large set of definitions.
There may be a monthly subscription, included data, voice allowances, optional add-ons, promotional conditions, charging rules, provisioning requirements, taxes, and effective dates.
CRM needs to know what the customer has selected.
Billing needs to know what should be charged.
Provisioning needs to know what services should be activated.
But none of these systems should independently define what the operator actually sells.
That responsibility belongs to the product catalog.
A well-designed product catalog creates a shared commercial definition that can be referenced by CRM, billing, charging, provisioning, and other parts of the telecom platform.
Without one, product definitions gradually get duplicated across systems, and keeping those definitions synchronized becomes an operational problem.
A Telecom Product Is More Than a Price
It is tempting to define a telecom product as a name and a price.
For example:
Unlimited Data Plan — $40/month
But that description is not enough for a platform.
The system may also need to understand the plan's data policy, included services, activation requirements, billing frequency, eligibility conditions, associated charging rules, and availability period.
The product therefore represents a commercial concept that other systems consume.
The price is only one attribute.
This distinction becomes important as soon as an operator starts offering multiple plans and add-ons.
CRM Should Not Become the Product Database
CRM systems are primarily concerned with customers and their relationships with the operator.
They need to know which product a subscriber selected.
They may also manage customer lifecycle activities, sales interactions, orders, and account information.
But there is a difference between storing a customer's selected product and defining the product itself.
If CRM becomes the primary place where product definitions are maintained, other systems may eventually create their own versions.
Billing creates its own interpretation.
Provisioning creates another.
Charging maintains another set of mappings.
The result is duplicated commercial logic.
A product catalog provides a shared reference instead.
CRM can say:
This subscriber selected Product X.
The catalog defines what Product X means.
Billing Should Consume Product Definitions
Billing has a different responsibility.
It needs to determine what financial charges should be produced for a customer's subscribed products and usage.
That requires information about recurring charges, one-time charges, discounts, billing periods, and other financial rules.
But billing should not need to independently redefine every commercial product.
It should be able to consume the relevant product and pricing information from a controlled catalog.
This creates a cleaner separation.
The catalog defines the commercial offering.
Rating determines how usage is valued.
Billing produces the financial result.
That separation becomes increasingly useful as the number of products grows.
Product and Service Are Not Always the Same Thing
Telecom architecture often becomes confusing because commercial products and technical services can be mixed together.
A customer might purchase a mobile plan.
The underlying network may require several technical services to support that plan.
The commercial product is what the customer buys.
The technical services describe what the platform or network needs to deliver.
These concepts are related, but they are not necessarily identical.
A product catalog can provide the mapping between them.
That allows the operator to change technical implementation without necessarily changing the commercial product presented to customers.
This separation becomes particularly useful when the same commercial offering can be delivered through different underlying infrastructure.
Product Catalogs Become More Important With MVNO Growth
A small MVNO may have only a handful of plans.
Product management can initially appear simple.
As the business grows, the catalog can expand to include different customer segments, data bundles, international options, roaming packages, add-ons, promotions, enterprise offerings, and connected-device services.
Each new product creates additional relationships between commercial configuration and operational systems.
Without a centralized product model, complexity spreads.
One team updates CRM.
Another updates billing.
Another modifies provisioning.
Someone else changes charging configuration.
The operator then needs to ensure that every system agrees.
A product catalog reduces that synchronization problem by giving those systems a common commercial reference.
Versioning Matters
Products change over time.
An operator may increase a plan's allowance.
Change its price.
Introduce a new eligibility rule.
Remove an add-on.
Modify the relationship between a product and an underlying service.
These changes should not automatically rewrite history.
A subscriber who purchased a product under an earlier definition may need to remain associated with that version until the applicable business rules say otherwise.
This is why product catalogs need versioning and effective dates.
The platform should be able to distinguish between:
What this product means now
and
What this product meant when the subscriber selected it.
That historical distinction also connects directly to rating and billing.
Effective Dates Prevent Configuration Ambiguity
Consider a plan whose monthly price changes on July 1.
A subscriber signs up on June 28.
Another signs up on July 2.
The catalog needs to represent when each version becomes effective.
The same principle applies to add-ons, promotions, eligibility rules, and service mappings.
Without effective dating, downstream systems may have to infer which configuration applies based on their own local state.
That creates opportunities for inconsistent behaviour.
A centralized product model can provide a common answer.
Product Changes Need a Lifecycle
Creating a product is only one part of product management.
Products can move through different lifecycle stages.
A new product may be configured before it becomes available.
An existing product may stop accepting new subscriptions while remaining active for existing customers.
Eventually, it may be retired completely.
These states matter to different systems in different ways.
A sales channel should not necessarily offer a product that is no longer available for new subscriptions.
Billing may still need to recognize the product for existing subscribers.
Provisioning may continue supporting customers who already have the service.
The product lifecycle therefore needs to be represented independently from simple availability.
Promotions Should Reference Products
Promotions become easier to manage when they are associated with clearly defined products.
Instead of embedding promotional logic independently into multiple systems, the platform can define which products or product versions a promotion applies to.
This also makes commercial configuration easier to reason about.
A promotion can have eligibility conditions and an effective period without changing the fundamental identity of the product.
That distinction is useful because promotions often change faster than the underlying product.
The catalog becomes the place where these relationships can be represented without turning every downstream service into a product-management system.
Product Catalog and Rating Need a Clear Relationship
The product catalog defines the commercial offering.
The rating engine determines how usage should be valued according to the applicable commercial rules.
These responsibilities should remain connected but separate.
A product may reference a charging configuration.
That configuration can define how included usage, thresholds, overages, or other chargeable events should be handled.
When the product changes, the appropriate rating configuration can change with it.
This creates a controlled relationship:
Product → Commercial rules → Rating configuration
Rather than forcing the rating engine to independently understand every customer-facing product.
Provisioning Also Depends on the Catalog
The same principle applies to provisioning.
A customer buying a product may trigger several technical actions.
For example, the selected product could require a particular service configuration to become active.
Provisioning needs to know what technical state corresponds to the commercial product.
A product catalog can provide that relationship.
This allows the order or subscription process to start with a commercial product and translate it into the technical actions required downstream.
The catalog therefore becomes a bridge between commercial intent and operational implementation.
A Shared Catalog Reduces Configuration Drift
Configuration drift occurs when different systems gradually develop different interpretations of the same product.
CRM may show one allowance.
Billing may calculate another.
Provisioning may activate a different service configuration.
The customer sees one plan.
The platform internally has three definitions.
These inconsistencies can be difficult to detect until they produce a customer-impacting problem.
A shared catalog does not eliminate all integration failures.
It does provide a common source for product definitions and relationships, reducing the number of places where commercial information needs to be independently maintained.
Product Catalogs Should Not Become Monoliths
There is another architectural risk.
Once a catalog becomes central, there is a temptation to put every piece of business logic inside it.
That can make the catalog difficult to maintain.
The catalog should primarily define products and their relationships.
Rating should handle usage valuation.
Billing should handle financial processing.
CRM should manage customer relationships.
Provisioning should manage technical activation.
A good architecture keeps these responsibilities connected through clear contracts rather than collapsing them into one system.
The Catalog Becomes a Commercial Contract
The deeper value of a product catalog is consistency.
When an MVNO launches a product, multiple systems need to understand the same commercial intent.
The catalog provides a common definition.
CRM can reference it when customers subscribe.
Ordering can use it to create the appropriate subscription.
Provisioning can map it to technical services.
Rating can apply the relevant charging rules.
Billing can use the applicable financial configuration.
Analytics can understand what product the customer actually owns.
This makes the catalog more than an administrative database.
It becomes a commercial contract between different parts of the telecom platform.
Final Thoughts
CRM, billing, charging, and provisioning all depend on product information, but they have different responsibilities.
When each system creates its own interpretation of a telecom product, configuration drift becomes increasingly difficult to avoid.
A product catalog provides a shared commercial definition.
It can represent products, versions, pricing relationships, effective dates, promotions, eligibility, and mappings to technical services without forcing every downstream system to become a product-management platform.
For a growing MVNO, this separation becomes increasingly valuable.
The architecture can then follow a straightforward principle:
The catalog defines what is sold. CRM manages who bought it. Provisioning delivers it. Rating values its usage. Billing accounts for it.
When those boundaries remain clear, adding a new product does not have to mean rewriting the entire telecom stack.
Top comments (0)