Consolidate product catalogs across applications

Benefits and challenges for a telecom service provider


With massive advancements on the technology front, the telecom industry is making major changes in how offerings are presented to end users. Attractive packaging, and the ability to reduce time to market, have become critical for any telecom service provider (TSP). Competition between operators is fierce. With the same offerings available in different flavors, it's important that the TSP:

  • Has a product catalog framework that's flexible enough to make a differentiated offering with minimum time and effort.
  • Supports the needs of the different operational support system (OSS)/business support systems (BSS) applications in the ecosystem.

A product catalog (PC) is a framework that transforms the selling view of an offering to its associated billing and network view, per predefined business rules and network element rules. It also hides the complexity of the billing view, which caters to the complex pricing structure of the offering, from the subscriber and customer service representative (CSR). The catalog is a set of RDBMS tables that, in conjunction with core COTS product structure, controls the different aspects of an offering in terms of its constituents, applicability, pricing, and interrelationship with the various services being offered.

Figure 1 shows how different applications use their respective catalogs to derive the rules for their own processing.

Figure 1. Typical deployment architecture with multiple PCs

The ultimate dream for any TSP is a single centralized catalog that could cater to all the applications in their ecosystem. A single catalog would eliminate the need for synchronization between catalogs of different applications whenever new products, plans, value added services (VAS) or promotions are introduced. It would also reduce manual synchronization errors and revenue leakage. However, in most cases, operators live with multiple PCs residing within individual applications.

In this article, explore:

  • Different approaches for product catalog implementation, specifically in a retail environment.
  • The advantages of consolidating multiple PCs into fewer, more manageable groups.
  • Things to consider when building a framework for consolidation of different catalogs.
  • Challenges and possible remedies in the quest for integration of consolidated PCs.

Examples help explain the different aspects you should consider when consolidating the PC.

Key concepts and terms

This section explains some of the key concepts and terms related to PCs.

The offering that's sold to the subscriber. Products are available in different ways:
  • Basic Product Offering

    The sale is not dependent upon the sale of any other product offering. Typically, the purchase of a basic product offering is how customers can acquire a subscription to the operator's telecom network.

  • Optional Product Offering

    The sale is dependent upon the sale of the basic product offering but is optional. Typically used to specify product offerings that will provide customers with enhancements to their subscriptions.

  • Bundled Product Offering

    A grouping of product offerings, sometimes offered at a discount.

Applications refer to the PC to identify products that are available for sale. Depending on the product type and its attributes, different applications can retrieve the required data for order entry, decomposition, provisioning, or pricing.

Service instance (SI)
An entity that actually hosts the subscription. The SI is assigned to an account that is the billing entity. An account can have one or more service instances; each would have the specific services (bill plans, VAS, and promotions) attached to it.
Base plan
Any subscription has a price attached to it, and the price could vary depending on geography, season, promotion period, usage, or market segment. The PC can help in arriving at the appropriate base plan, and can subsequently be used by the billing or payment system to give the correct invoice to the customer.
Promotions or top-ups
Promotions are bundled offers specially designed by the marketing teams to attract customers. In conjunction with the bill plan, they can help tailor specific offerings. Types of promotions, or top-ups, include:
  • Bill Plan Dependent Promotion

    Applicability of these promotions is governed by the bill plan that's assigned to the SI.

  • Generic Promotion

    The typical user-selectable promotions that do not have any dependency on other components.

  • Restricted Promotion

    The special promotions that are not available for normal subscription. Senior agents, or supervisors, could have access to restricted promotions that may be used for retention.

  • Account Level Promotion

    Are not bill plan dependent, but are applicable to the account. If an account has multiple promotions, then all the SIs in this account would be able to enjoy the promotion once attached at the account level.

Value added services
Additional services offered by the service provider that generally have a charging, rating, or discount component (used by the billing applications). They might also involve a provisioning component (used for provisioning the network elements). Bill Itemization is an example of a VAS that requires no network component.
Service activation fee
The charge associated with any service. It should be specified in the catalog to calculate the applicable charges for making the service available.
Miscellaneous charges
Includes components such as service activation fee, premium number charges, safe custody, check bouncing, and so on. Miscellaneous charges can have the following categories:
  • Order type charges, with rates applicable for different equipment changes.
  • SI level charges, such as call tracing.
  • Account level charges, such as a check bouncing.
Product hierarchy
A hierarchical view of the offering that includes the plan, VAS, and promotions and their relationship. Typically the order entry module refers to this aspect of the catalog to build the offering.

Figure 2. Hierarchical structure of a product

Fulfillment rules
The order fulfillment system needs to validate, transform, and convert the order to the desired output view using the externalized business rules. These decomposition rules are again derived from the PC, and may also provide inputs to trigger workflows for order orchestration.

Product catalog deployment options

This section explores different deployment options for PCs: distributed, hybrid, and centralized.

Distributed product catalog

A distributed PC implies that the catalog resides in each application separately. Thus, in the BS stack, CRM, OFS, Billing, Self Care, and so on will all have their own PC for reference, and would have the relevant data as required by itself.

Distributed PC pros and cons
  • For individual applications, it's simple to administer the catalog since the structure is simple and specific only to the application.
  • For any new offering, the support team will have to configure in multiple places.
  • Missing configuration at any application will lead to rejection, revenue leakage, or wrong service configuration.
Figure 3. Example of distributed PC

Hybrid product catalog

With a hybrid PC, you would have a few applications using a single PC while some other applications may have their own PC. With this option, there will be more than one PC in the ecosystem.

Hybrid PC pros and cons
  • This is a step toward the centralized PC. There are fewer catalogs to configure, so it's more efficient than the completely distributed option.
  • You still need to be careful not to miss any of the configurations, which would lead to rejection, revenue leakage, or customer dissatisfaction.
  • Need for "manual" verification of product information, and consistency across catalogs.
Figure 4. Example of hybrid PC

The hybrid PC is more prevalent mainly because most deployments are a combination of COTS and non–COTS working on multiple technologies, and requiring data in different formats. With applications becoming more open, convergence of service types, and prepaid and post-paid services, there is a definite impetus towards embracing the hybrid approach for PC consolidation.

Centralized product catalog

A centralized application implies that there is one PC in the entire ecosystem. All applications connect to this PC for their relevant needs.

Centralized PC pros and cons
  • This is the ultimate goal, or dream, of the operator. It allows centralized management.
  • Can reduce the time to market, since all configurations are to be done centrally at one place.
  • Reduces chance of errors, as no efforts are required for synchronization between catalogs.
  • Reduces training requirements for configuration team.
  • The effort for achieving a single unified PC can be challenging. It might require organizations to modify their internal processes to support this kind of standardization.
Figure 5. Example of centralized PC

The PC acts as a central rule repository. The framework itself needs to provide the required interfaces so different applications can access relevant sections of the catalog using the EAI bus, or through point-to-point connectivity, and can deliver their respective functions.

The PC admin console hides the underlying complexity of the catalog, and provides a user friendly view of the catalogs for efficient management. The centralized configuration team can easily use this interface for new product launches, or for modification of the existing rules.

Dimensions of the product catalog

The key elements of the PC are the dimensions. They provide immense flexibility for the marketing and sales teams to devise unique offerings targeting specific segments. Dimensions can also provide hooks that can help expand the catalog to account for new attributes added in the future.

The PC should address the needs of different applications, so it is important that the different dimensions are defined appropriately. You want services to be suitably tailored to address the right segment using a combination of the dimensions, or elements, of the PC. In this section, learn about the different dimensions that are used specifically for customizing offerings for retail. They should be part of the PC framework.


The rating dimension caters to the rating needs of the operator. Aspects that can be addressed include: charges for services based on geography, usage volume, service type, age on network, and even time of the day. The rating dimension may also cater to discounts that can be applied on individual components.


The billing dimension is for providing the inputs to the billing system. The tariff hierarchy, including tax rules, can be derived by this section of the catalog.


Certain offerings from a service provider involve hardware components to be leased or sold. In the retail business there is customer premise equipment (CPE), or even handsets, which are sold as part of the deal. The pricing for these need to be considered, and can reside in the PC.

Bill plan eligibility

Bill plan eligibility rules drive which bill plan a customer can select based on predefined eligibility criteria.

Parameter Description
Geography Geography name
Product Product type or service type
Customer Segment Customer segment
Age on Network Number of days that the SI has been active
Customer Group Grouping or classification of customers into a company or a group of companies
Order type Indicates whether the rule is to be applicable for a New order or a Change order or for both
Effective start date Only those bill plans that lie between effective start date and effective end date are displayed
Effective end date Only those bill plans that lie between effective start date and effective end date are displayed
Retention flag for bill plans Only users with specific responsibilities can access bill plans with retention bill plan flag 'Y'
Bill plan status Status has values Active and Inactive. Only bill plans with Active status are displayed.

Promotion eligibility

Promotion eligibility rules drive which top-ups a customer can select based on predefined eligibility criteria. Promotions are generally multi-selectable. This dimension can work over and above the bill plan eligibility dimension.

Parameter Description
Geography Geography name
Bill Plan Bill plan
Product Product type or service type
Customer Segment Customer segment
Age on Network Number of days that the SI has been active
Customer Group Grouping or classification of customers into a company or a group of companies
Order Type Indicates whether the rule is to be applicable for a New order or a Change order or for both
Effective start date Only those promotions that lie between effective start date and effective end date are displayed
Effective end date Only those promotions that lie between effective start date and effective end date are displayed
Retention flag for promotions Only users with specific responsibilities can access promotions with retention bill plan flag 'Y'
Promotion status Status has values Active and Inactive. Only promotions with Active status are displayed.
Bill plan mandatory flag Promotions that are mandatory with a bill plan

Promotion exclusivity

In this dimension, promotions are grouped by the type of promotion, and only a single promotion can be attached to a customer. Promotion exclusivity can be across bill plan dependent and bill plan independent promotions.

Parameter Description
Promotion Group Promotion group name

VAS selection

VAS selection can be varied based on geography, product, and customer segment.

Parameter Description
Geography Geography name
Geography Type Instead of geography, geography type and geography name are future parameters on which bill plans may depend
Geography Name Instead of geography, geography type and geography name are future parameters on which bill plans may depend
Product Product type or service type
Customer Segment Certain VAS are automatically selected for specific customer segments
Bill plan Certain VAS are not applicable with certain bill plans. Certain VAS are mandatory for a bill plan.

VAS compatibility

The VAS compatibility dimension can control the applicability of one VAS with respect to another one.

Parameter VAS1 Parameter VAS2
Add National roaming Delete International roaming
Add International roaming Delete National roaming
Add Fax & data Delete Fax
Add Fax & data Delete Data
Add Fax Delete Fax & data
Add Data Delete Fax & data

VAS charging

This dimension is for controlling the charge that gets associated with a particular VAS. Different charging can be built based on customer segment, customer group, and bill plan.

Parameter Name Parameters
Customer segment Certain VAS charges are applicable only for specific customer segments.
Customer group Grouping or classification of customers into a company or a group of companies.
Bill plan Another parameter on which the filtering of VAS charges depends.
Order Type Indicates whether the rule is to be applicable for a New order or a Change order or for both.

VAS network parameter

The VAS network parameter dimension helps control the network parameters required to activate VAS on the network. Network parameters could either be operator specific or subscriber dependent. For example, a closed user group generally uses a network parameter. Similarly, a GPRS service normally uses a standard operator URL, but a particular corporation might request its own URL for all its employees.


Certain bill plans, promotions, and VAS will be available only to a select group of users. Typically these are applicable to Retention agents who would have the power to override a rule and provide some service combination that's not normally available to users.

Parameter Name Restriction
Retention Bill plans Certain bill plans are available only to a select group of users (access is governed by role/responsibility assigned to the user).
Retention Promotions Certain promotions are available only to a select group of users (access is governed by role/responsibility assigned to the user).
Restricted VAS Certain VAS are identified as restricted. These are always restricted regardless of the geography. For example, CLIR is a restricted VAS.


Discounts can be offered periodically based on loyalty promotions or bonus promotions to attract the subscribers. These can be configured in the catalog and can be used by the billing or rating system for the invoice generation.

Miscellaneous charges

The miscellaneous charges dimension is designed to provide the required flexibility to address the many types of miscellaneous charges that can be levied to the service. This also includes the framework for waiver that is applicable on these miscellaneous services. Typical examples are service activation fee and premium number charges.

Charge Name Parameters
Service Activation Fee Service activation fee will depend on:
  • Customer segment
  • Geography
  • Customer group
  • Bill plan
  • Product or service type
Premium Number Charges Depends only on the type of premium number and geography.
Number Change Charges Depends on the geography. If a rebate has to be given against the standard value, the agent will have to manually enter a discount amount.
Equipment Change Charge Depends on the geography. If a rebate has to be given against the standard value, the agent will have to manually enter a discount amount.


The barring dimension is for the service barring needs of the operator. Barring can also be applicable at different levels, with the following categories:

  • SI level barring: For restricting certain services available to the subscriber.
  • Service level barring: A subscriber generally gets certain services by default (for example, in a mobile environment SMS or CLIP are given by default). Barring of these services is controlled here.
  • Product based barring: Options available at the product level. For example, you can have data card without voice.

Consolidating the product catalog

This section outlines the steps you can take to consolidate the PC. Figure 6 shows a flow diagram of the steps.

Figure 6. Flow diagram of steps for consolidation

The table below shows the eight major steps in consolidating a PC.

Consolidation of PCs
Step Activity Description
1 Create PC framework Take this step jointly with the PC designers, application architects, and business team so you address all key aspects (technical requirements of individual applications as well as business needs) while building the framework.
2 Create PC template Create the template, which is the actual input sheet, so that various users can provide data in a format that's required by the framework. This should cover all the attributes that govern the service delivery, and should also address the interdependencies.
3 Upload product (staging area) Upload the PC template (with inputs from business needs) to a staging area. The various products with their end to end flow, with respect to the different applications, are verified.
4 Validate PC (staging area) Validate the PC template against the existing application data, along with the revised data received by marketing and sales teams. When populated with data, the PC template should be checked for consistency with the data from the downstream applications.

Finalize the PC template after successful data handling capabilities are proven.

5 Exception Handling Handle exceptions by either:
  • Modifying the PC in accordance with additional uniform business rules for additional products not considered before, or
  • Carry relevant data standardization to accommodate new products within the existing template.
6 Validate customer data Re-verify and check customer data, typically from the billing system, for consistency with the final PC template.

If other exceptions arise due to the complete data, handle as in Step 5 above.

7 Consolidate PC (staging area) Do final validation of the consolidated PC, with a fixed set of business rules for each of the products, for the entire customer data.
8 Finalize PC Enter finalized business data for all products sold, per the rules defined in the PC, and carry out their corresponding mapping for access from different applications.

Challenges in consolidating a product catalog

This section discusses the four major challenges in consolidating a PC, as shown in Figure 7.

Figure 7. Consolidation challenges

Creating a PC framework

For any enterprise, creating a PC framework is the starting point for consolidation. In this phase, the PC designers and solution architects get input, and evaluate information related to: pricing, product hierarchy, product interdependency rules (business or network), provisioning rules, order decomposition rules, and other related aspects. All the dimensions must be considered when finalizing the structure. Wherever possible, try to bring the diverse application requirements into a common structure.

Once the various attributes are identified, it's important to decide which application will be the master of that data and which application will be a user. It's also important to account for certain additional attributes that could be place holders for future consideration (and used for further refining of a particular service selection).

The example in the table below lists applications that are commonly available with any telecom service provider, with attributes where the application is likely to be a master. This is just an example; specific implementations may reflect a different relationship.

Application master
PC Components CRM OFSBillingSelf CareBIProvisioning
Product Owner User User User User User
Base plan Owner User User User
Pricing User Owner User
Dimensions Owner User User
Decomposition rules Owner User User
Orchestration rules Owner User User
Order entry rules Owner User User
Product / VAS compatibility rules Owner
Discount /Exclusivity rules Owner
Business eligibility rules Owner

Different applications work on different technologies and have different integration requirements. To access the PC, the two commonly used interface methods are Web services or database link. Architects should consider the creation of Web services for exposing the relevant data to a specific application, since different applications would have different requirements for accessing the catalog.

Configuring catalog data

Once the basic PC framework is created, the next step is to get data from various application owners to fill in data specific to their application in the framework. This is an intensive exercise that might require tweaking of processes to arrive at standardized processes and rules across the enterprise. However, it's an important step that helps in PC consolidation and brings the enterprise onto the same level.

This activity requires leading roles from multiple teams, including application architects, PC designers, and business owners. Individual users or business/process owners may get totally overwhelmed if they're exposed to the final PC and the data that's required. It is advised that the architects share the requirements in steps and, when the various pieces are available, consolidate them. The consolidated PC can then be shared with the owners for review.

As an example, you could create a workbook catering to different aspects of a PC for the retail segment. Each aspect would capture the different dimensions, as follows.

  • List of plans, promotions, VAS
  • Bill plan eligibility rules
  • Promotion eligibility rules
  • Profile rules
  • Product Item compatibility rules
  • Provisioning rules
  • Exceptions/overrides
  • Master data

Figure 8 shows an example.

Figure 8. Template for consolidating PC data

Once the above data is received, architects can analyze it and massage the data appropriately so it can then be used to integrate the final PC.

Standardizing customer data

The PC is created with inputs from various business, application, and process owners. It is important that the existing subscriber base follows the new consolidated PC.

Most existing subscriptions would likely follow the newly created PC rules, but some customers might have undergone changes as a result of data consolidation in the catalog. Such data, which does not follow the catalog rules, needs to be cleansed and standardized.

Standardizing also provides an opportunity for the operator to completely sanitize the customer data, and to help migrate the application to the newly consolidated PC. Common things you should consider during data standardization are:

  • Duplicate components (bill plan, VAS, or promotional) need to be deleted.
  • Confirm that each SI has one bill plan.
  • Standardized network provisioning package is available to all users in the geography.
  • Standardization of components across the geographies.
  • Services with incorrect product type need to be corrected.

    For example, a voice product could be offered through mobile service or a fixed line. Though the plan name may be the same, the correct plan needs to be configured.

  • Violation of promotion exclusivity rule should be corrected.
  • Violation of VAS compatibility rules.
  • Any a la carte or user discretionary discount and unit credits to be corrected.
  • Unused or inactive products, or dead contract components, to be removed from the subscriptions.
  • Verification whether the correct mandatory products are attached to the SI, according to the bill plan.
  • Removal of any product that does not exist in the PC but is attached to the SI.
  • Verification of alignment of activation fee and deposits per the PC.
  • Verification that the correct components are attached at the account level and the SI level.
  • Components used by very few customers can be sunsetted and the subscriber moved to similar existing service components. The goal is to optimize the PC data and eliminate those components that are seldom used.

Administering the catalog

Administration of the PC in a consolidated environment has several challenges. All applications depend on the consolidated catalog data, so an error in rule building or a mismatch between the catalogs can lead to revenue loss or customer dissatisfaction.

It is imperative that the rule is first added or changed on the staging area, and that it is tested completely before moving into production. The offerings must have a start date and end date. There should be enough flexibility to control the product transition from design, to test, to the 'live' stage, and finally to obsolescence. Consider aspects such as control of visibility of the offering to limited users or testers while the product is in the design and testing stages.

The catalog administrative interface should provide a user friendly UI to upload data. It should also have the ability to validate rules and avoid duplicate or conflicting rules.

Data synchronization in a multi-catalog environment, where two or more catalogs need to be updated with similar data at the same time, is an important aspect. You want the various applications to remain in sync with respect to the offering that's being added or modified.


TSPs have many applications, and handling multiple catalogs incurs a lot of overhead for maintenance, data configuration, and synchronization. A single, organization-wide, central unified PC would be ideal. A major stumbling block is the presence of applications that include COTS, non-COTS, and legacy situations. However, worldwide operators have started consolidating the PCs so there are fewer entities to manage and administer.

Operators have been successful in consolidating the catalogs for the customer-facing applications, such as customer self-service portals, the CRM systems, and the order management applications. There's a separate catalog for back-end applications like billing, rating, and provisioning systems. PC deployment is more visible as a hybrid between a completely distributed catalog deployment versus a single centralized one.

The benefits of PC consolidation are immense; long term, it would help TSPs to streamline their own business processes and improve operational efficiency. Training needs would be reduced drastically, since you'd need to focus on only one PC. The need for manual synchronization and data updating is reduced, leading to fewer human errors. In the highly competitive telecom environment, where service differentiation is key, consolidating PCs is a winning proposition for the operations and configuration teams. The business team can focus on the flexibility of the catalog framework, and produce innovative service offerings for subscribers with minimum time and effort.

Consolidation of PCs is a major step that is evolving. In addition to accounting for consolidation of voice, data, and video services in the same catalog, future PC designs might cater to the different flavors of convergence of prepaid/postpaid or retail services and enterprise services.


The authors would like to thank Ranjan Giri, Senior Managing Consultant, IBM Global Business Services, India for his valuable input that improved this article.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=Information Management
ArticleTitle=Consolidate product catalogs across applications