Vast numbers of new applications, content and services are increasingly available and being consumed digitally, regardless of provider origin, network technology, device or location. Customers expect them to be available to buy everywhere, supported on every device, and connected to everything in the home, across their transport and at the office. How does a service provider master what’s next in the fast-changing digital economy?
There is broad recognition and agreement in our industry that a product catalog-driven approach to creating and delivering products is crucial for service providers to succeed in this new environment. Product catalogs help determine the types of products a service provider can sell, to whom they can sell, for how much and under what terms. It also allows providers to quickly define new products or adjust existing ones, and respond to new offerings from competitors.
But the term “product catalog” is being used quite loosely to describe a set of capabilities that don’t always reach the robust requirements service providers have for end-to-end product management.
Let’s look back at the four stages in the evolution of the product catalog to understand why there are so many definitions:
Stage 1: The Excel spreadsheet. Ten years ago, many operators described their products in a variety of spreadsheets, presentations and documents before converting these products into rate codes for their various billing systems; for example, product 10101 consisted of a bundle of voice, broadband and three free email addresses. Even a slight variation of the product, such as increasing the number of emails to five, caused the creation of a new product and rate code. Many providers had tens of thousands of different products in the market—many with just slight variations—all hidden behind cryptic rate codes.
Stage 2: Systems databases. The spreadsheet approach evolved into a database approach, where each of the OSS/BSS components in the stack—such as order capture, order management, and provisioning systems—had their own embedded catalog. The problem here is one of integration: each time a change was required or a new product introduced, the information needed to be manually entered across each individual catalog. Many providers remain in this stage today.
Stage 3: Enterprise-wide catalog. Enterprise-wide product catalogs emerged and architecturally are intended to be the master of all the other catalogs. Providers use this catalog to create their product definitions and offers. Gradual integration to the other embedded catalogs occurring over time, provides the result that some of the product information can be automatically distributed to the embedded catalogs. But this comes at a fairly high integration cost: integration that must be maintained as the various systems go through upgrades and changes. It’s costly and brittle, and breaks easily even with small changes.
Stage 4: Product Catalog ‘2.0’. Where are we headed? The concept is simple —we need to have a single master enterprise-wide product catalog that external systems rely on and these external systems need to be re-architected to eliminate their own embedded catalogs. Instead of an order management system interacting with its own proprietary catalog it will use well-defined real-time APIs to perform tasks like product decomposition by interrogating the master product catalog. The result is a dramatic reduction in the integration tax and a similar reduction in synchronization issues. Product Catalog 2.0 is a truly integrated catalog-driven approach.
Reducing Order Fallout
An integrated product catalog-driven approach can also help providers reduce their order fallout significantly.
Order fallout occurs when an order fails during processing. This could happen for a number of reasons, such as when a phone that is purchased is not available with a specific plan the customer requested or a when a service that was ordered ends up not being available for the customer’s address. The issue might even require a truck roll, which is very expensive for providers. Our customer research has shown that up to 30 percent of orders fail when an integrated product catalog is not implemented.
Why is there so much order fallout without a catalog-driven approach? There are five main types of systems involved in fulfilling a given order – quoting, order capture, order management, provisioning and inventory. Without a product catalog that these systems look to for their understanding of products and product attributes, you have operational chaos. Even something as simple as an address is difficult to normalize as some systems have a single field, some have different fields for street number and street name, some have free-form fields and others drop downs for state, and so on. Integration between systems for order creation and decomposition was historically very manual and error prone.
With an integrated product catalog changes are introduced into the catalog and the five fulfillment systems pick up those changes automatically so that the participating systems are always in sync. Synched systems mean a streamlined ordering process, ensuring accurate and concise orders all the way from quoting to provisioning.
An integrated product catalog sits at the center of the provider’s idea-to-install process, consolidating different practices and products into a unified catalog. A product catalog-driven approach helps different stakeholders throughout the organization, such as product managers, sales and marketing, work from the same playbook, ensuing a smooth process end to end, and reducing order fallout – even for brand new products – down to less than 1%.
With a Product Catalog 2.0 – the new, truly integrated Product Catalog – service providers can define and bring new products to market quickly, cut costs and reduce order fallout. It’s a true differentiator for service providers that are ready to move their business to the next level.