The Centralized Product Catalog: Nice Dream, But Not a Reality
Michelle L. Hankins
05/01/2005
Often, when it comes to product catalogs, there are two schools of thought: centralize to a single product catalog, or accept and deal with the several that already exist. In theory, a centralized product catalog might greatly simplify things for providers. However, some contend that this is a dream and unlikely to become reality—particularly for many cable operators, which are rushing to add new services yet trying to segment bundles and pricing schemes by the regions they serve.
Multiple systems, multiple platforms, acquired systems and acquired customers—these make up the world that most providers live in, PwC principal Joe Atkinson explains, and they are the cause of many revenue assurance issues, most of which can be traced back to the product catalog.
Increasingly, operators are demanding more flexibility in their product catalogs in an effort to become more competitive, says Curt Champion, senior director of product marketing at Convergys. They want to create more geographic-specific or convergent offerings, but doing so ultimately makes the product catalog more complex to manage.
Offering bundles, managing promotions and discounts, and facilitating flow-through provisioning are all complex requirements that demand more of the product catalog. While providers do not want the product catalog to be a source of revenue leakage, often that is the case.
Catalog Size
When you consider the sheer number of products that providers must manage, it is not surprising that revenue leakage occurs. Ian Houvet, managing director and co-founder of Boxfusion, which develops software to help providers manage the product catalog, says he knows of one company that has 1,000 products in its customer relationship management (CRM) system and an additional 23,000 in its billing system. "I don't think that's too uncommon," Houvet says, adding that he has even heard that one U.S. provider grapples with 5 million different billing codes.
Operators are forever creating new products and offerings in response to the marketplace. It is easy for their product catalogs to grow out of control. Houvet notes that products not only build up over time but also result from mergers and acquisitions of other providers. With each merger comes a new set of products in new product catalogs. Many product catalogs contain dated products and older offerings with only a few subscribers. Each instance of a product creates an opportunity for error based on maintenance and updates alone.
When it comes to scaling down the product catalog, providers "are too scared to touch anything and to remove it," Houvet says.
"It's rare that you have the opportunity to build a product catalog from scratch," Atkinson explains. "As a result, you have a lot of embedded errors." Even if a provider can get its catalog in fairly good condition, continuing to maintain it well is difficult, as is cleaning it up in the event of a merger or acquisition.
The key is to keep the catalog simple with the fewest offerings possible.
The Data Master
As Atkinson sees it, providers can choose from two strategies to manage their product catalogs: First, a provider may have a centralized product catalog, but with systems that own certain business functions, such as billing or CRM. Second, a provider may have multiple catalogs with distinct and separate products, and integrate the multiple catalogs to the best of its ability.
But the age-old question still remains: Which system should own the product catalog?
BusinessEdge Solutions partner Sharad Kumar explains that each provider has at least three main instances of the product catalog: at the point of sale or online in CRM, in provisioning and in billing. Each system has been designed to own the product catalog.
Because everything that can be ordered within a product catalog has to be billed and rated for, Convergys' Champion believes, "the master product catalog should be owned by the billing system."
While Champion says it is easier to have one product catalog, he notes that in some cases it makes sense to replicate product data at the point of service. He believes, however, that the best scenario is one in which the point solutions still read the master catalog from billing, but supplement it on the non-master end with additional capabilities such as customer analytics.
The more often a provider duplicates the product catalog to create a subset version, the more chance for errors.
In the case of mergers and acquisitions, these new catalogs may have similar product instances that will be joined into existing catalogs. In this process of consolidating and integrating the two catalogs, mistakes will undoubtedly be made.
Managing the product catalog is more about understanding how it serves the entire business, according to Kent Steffen, chief executive officer at Telution. Looking at it this way allows each product catalog to own its piece of the process while allowing the provider to manage the product catalog within a unified, overarching context.
"You want one logical concept of a product catalog," Steffen says.
It's not about which one is going to be the master, he says, but rather how a provider manages the multiple product catalogs. "You will have multiple product catalogs, but you need to be able to manage them in a consistent way," Steffen explains.
Information Synchronization
Indeed, synchronizing information between the various product catalogs is considered extremely difficult. The difficulty comes when a provider tries to synchronize the business rules within a product catalog. For example, a provider may want to replicate in all the product catalogs that remote call forwarding is available in certain geographies. Most systems require that the provider go to a screen on each individual system and establish these rules manually.
In addition, the product identification code may vary from catalog to catalog. When a provider tries to push new product information out to other systems, the identification may not register or synchronize with existing products to replicate any changes.
"It certainly gets difficult," Kumar says, "but that's the reality."
Houvet at Boxfusion says that there has been no real standardized way to manage multiple product catalogs. Providers have so many product catalogs but there is "no industrialized piece in the middle to ensure that any changes are correlated," he says. Typically, a change to one product impacts product listings in catalogs in other systems.
Houvet, who previously worked for a systems integration firm, co-founded Boxfusion to develop software serving as a "product hub." The idea behind this software is that when a change is made, the tool synchronizes the product data across the enterprise regardless of the system in which it may lie. Simply, the tool aims to create a centralized point of visibility so the provider can see all existing products and which ones it might be able to reuse.
Often there is no one database of record, Houvet explains. Instead, each system that contains a product catalog deals with different flavors and ways of using this information. Billing, for example, includes the rating rules, which have no business being in the CRM system. Likewise, CRM has information that billing does not need.
The challenge with synchronizing these various catalogs is that integration is not only costly, but sometime difficult because of the systems themselves. "Some of the vendors are still not letting you talk to them as easily as some of the others are," says Infozech Software CEO Ankur Lal.
The Process Problem
As much as managing the product catalog presents technology challenges, providers also struggle with the process for recording and maintaining data in the product catalog.
Kumar stresses that providers must "have a very robust, very defined product launch process. … A lot of providers do not have good processes in place."
"It's not only a technical problem, it's a process issue," Houvet says. Often, a marketing department will create a new product idea and set a product launch date without realizing the complexity behind it. Boxfusion has developed a software tool to walk people through new product introduction. The goal is to reduce the time to market but also ensure that new products are deployed correctly so there is no order fallout. "Often a product is launched, but the systems in the background aren't ready," Houvet says.
Julie Unruh, senior director of revenue assurance at Charter Communications, says that it is critical to ensure that whatever rate increases marketing implements are locked into the billing system. If a product is not updated in the billing system, then it might have been rerated, and this could cause revenue leakage. "It's absolutely essential that marketing and billing are on the same page," she says.
Unruh cautions that sometimes the easiest way to implement a product may not be the best long-term plan for the company. For example, in selling a bundle of services, the price for the bundle is often not simply the sum of the à la carte services in the bundle. A provider could charge a special package rate designed specifically for the bundle, or simply apply a percentage discount rate. Applying the discount rate is easier, but may not be the wisest option for long-term product planning within the catalog.
Masking the Complexity
Telution's Steffen sees managing the product catalog as more about offer management and product management. A provider would do well to be able to give only the information to the CSR that the CSR would need to help a particular customer.
"To make the front-end catalog look like the back end, from a customer experience point of view, is not optimal," Houvet contends. On the back end, the product catalog is extremely complex, and this complexity will likely do little to help the customer. The provider needs to focus on the customer's lifestyle and selecting a product that suits this lifestyle, not running through a complex menu of possible services that the customer might choose.
Most cable companies have a large billing system in place, yet these operators may have several different implementations of that billing system supporting various regions, notes Kumar at BusinessEdge.
At the same time, many providers are giving more self-ordering capabilities to customers online. "This is where the struggle is," Kumar explains. The online system has to tie into the various regional systems to present the regional product offerings.
He says this is where "rules driven mapping" versus synchronization comes in. "Replication is not really an option" in the online scenario, he says, since the provider would not want to push out 800 different regional product offerings to the Web.
In rules-driven mapping, if a customer selects a high-speed data product online, the customer's geography would be captured (perhaps by ZIP code), and rules in the back end would obtain the correct regional service code.
Some cable companies are really struggling with this, according to Kumar. They face customers who cancel orders in the middle of an online transaction simply because the ordering process is too complex. He says many operators are moving toward a wizard approach with a shopping cart.
Managing Regional Offerings
At many cable operators, the same fundamental product may be defined completely differently in various product catalogs for the different regions the operator serves. A product in one region may be priced one way to respond to particular competitive pressure; yet the same product could be priced another way in another region. Eventually a product could be designed and priced differently many times, which ultimately becomes an issue of data integrity and maintenance.
If a product is defined 10 different ways, revenue leakage can occur when it is time for product updates. For example, say 10 instances of a product exist within a catalog and the price for the product increases, but because of poor processes the increase is only reflected in four of the product instances. The company would be leaking revenue from the instances that were not updated properly.
Promotions and Discounts
Competition to gain customers is fierce. "Pretty much everyone is giving 3 months or 6 months or, in some cases, one year discounts or subsidized service, in order to get these customers up and running," Atkinson explains. The incentives add to the complexity of the product catalog, because accounts with these discounts must be monitored to make sure the discounts are turned off at the specified time.
If the system cannot self-manage the expiration date, customers can continue to get a discounted rate, causing leakage. In addition, if promotions and discounts are not defined accurately in the product catalog, or if the operator makes a user error when entering the data, promotions might not end when they should.
Likewise, if a product has a specific expiration date that is not conveyed in systems for billing, customer relationship management or online ordering, or if the expiration date is incorrectly translated to any of these systems, the discounted pricing could be applied even after it has expired.
Some other issues that providers grapple with: How does a CSR know whether a customer is eligible for a promotion or service offered only in certain geographic areas? How does the CSR know whether the customer has the equipment in place, or that the provider's network will support the services the customer wants to order?
Many cable operators, for example, are rolling out digital voice service. In certain regions, they may need to compete with other operators who have also rolled out voice service and will undoubtedly offer promotions and discounts. How does a provider accurately, through a CSR or an online interface, ensure that the product conveyed to the customer in a promotional campaign is actually available, based on where the customer is located?
Often, promotions are offered to new customers only. It can be a challenge to synchronize the product information with the billing or CRM information to determine whether a customer is new and thus eligible for the discount.
Kumar says most product catalogs contain configuration tools that allow the provider to define the start or expiration data of a product. The trouble, however, comes in trying to convey this information to a billing or CRM system so that an expired product is not even presented to the customer.
Provisioning
How the product catalog ties in to provisioning is a key factor, and coordinating those elements is not an insignificant undertaking. Kumar says that "what's provisioned, what's sold and what's billed for are not always in synch."
Customers might be obtaining services for which they are not paying. Sometimes, in provisioning a bundle, customers might end up with more services than they ordered, yet they are paying for a lesser package, or a customer might become dissatisfied when the ordered bundle is not provisioned. Often, this can happen if the customer interface is not set up to guide the CSR or the customer online correctly, to qualify the new subscriber for the bundle. A CRM system needs to have tight controls so that a CSR cannot create incorrect service packages or combinations. Champion at Convergys says some systems do not have these controls and allow CSRs to manually enter in services, even though they may no longer be a valid entry.
Leakage can also occur when a customer changes packages and some services are not cut off, or services may be over-provisioned.
Dealing with Convergence and Bundling
Bundled bills are now common, but what if a customer cancels one service within a bundle? How is that bundle decomposed? What happens to the price of services when the bundle is separated and sold as individual services, and how does the provider create a process to reassign the appropriate product codes to this account?
A customer may drop one product that is the very service qualifying them for the discount in the bundle—a common problem, Champion says. When a provider is trying to create a bundle from products managed by multiple billing systems with multiple product catalogs, decomposition becomes even more complicated.
Convergence puts even more demands on managing the product catalog. Champion says providers will struggle with ways to insert convergent operations into their process to manage ordering and qualifying customers on the front end. If a provider is seeking to sell both wireless and wireline voice services, the two qualify customers for product eligibility very differently, and this can become a problem. Likewise, qualification for video and high-speed data is worlds apart from wireless qualification.
In addition, Champion notes, if a customer has a universal number service, this will need to touch the physical plant for both wireline and wireless. It gets even trickier if these are billed by two different platforms, especially if they are tied to a bundle.
In particular, "Cable companies are facing new products and services, and they may not have operational experience with those," Atkinson says.
Most companies are unable to provide a full bundle of triple or quadruple play services, such as cable companies adopting the MVNO route. The RBOCS are partnering with satellite companies in an attempt to offer video. But how will the provider obtain product information about its partner's services? How will the provider marry this product information with its own to form a bundle? How does the price of that bundle change if one service within the bundle is canceled, and how does this get relayed back to the partner's systems when it happens?
Partner Catalogs
With partnerships, knowing whether services actually have been provisioned—and provisioned correctly—is critical.
"The provisioning piece is really complicated," Atkinson says. He suggests limiting the list of partner products offered to a very short list replicated in the provider's own billing system, so that the provider can do the accounting and billing for the customers using partner-supplied products.
He believes product catalog integration with partner companies may make sense for cable companies looking to become MVNOs. To be competitive in a wireless market, a provider will need the same responsiveness for pricing and promoting new products as other wireless carriers have. They will need a robust product capability as a wireless provider. "I think that's operationally still a challenge," Atkinson says.
Another partner issue is that wireless operators have so many different channels for selling their services, and they may have different product catalogs for each of these points of sale. Kumar at BusinessEdge says that often, many of these product catalogs at the partner's point of sale are customized with a partial set of products.
Auditing the Product Catalog
Resolving pervasive catalog problems doesn't come easy. Providers may have to go through several billing cycles to investigate issues and fix them. This chore ultimately could translate into lost revenue, since orders could fall out, be delayed or, worse, be provisioned and not billed for.
A periodic audit, however, is critical for cleansing the product catalog of outdated offerings that are still available to consumers. These would include packages that are no longer valid, as well as pricing schemes that were offered in a specific area but have since expired. Champion believes an initial audit is critical. "It really does pay for itself," he says.
The Eternal Question
Certainly, from a control and management perspective, a centralized product catalog may be desired in the sense that it simplifies product management and gives providers a possible edge in responding to rapid market changes and needs.
However, "that's not really a reality in our world. … I've never seen it happen," Kumar says. "I frankly have not seen a nirvana solution." Providers have just too many systems that contain their own product catalog version and requirements. There are still too many product silos.
Convergys' Champion says an ideal scenario would look something like this: A provider has a process in place to ensure that the product catalog is up to date. It presents a limited product view, via the CSR or online, that directly suits the subscribers' needs. Then this information is married with data about the physical plant, to determine where the customer connects to it and to verify that he or she can even be serviced. For example, can a cable customer obtain VoIP, or has the plant not yet been upgraded to support this? Is the customer eligible for various product features?
PwC's Atkinson says that what many providers are doing today is "effectively a wrap-around strategy," in which the customer interface is a single point that transfers information back to the functional service silos. The technology entrusted to the CSR is essentially an overlay to other systems that support provisioning and the view of the product catalog. But when it comes to the technology and process flow, Atkinson says, "most companies are still struggling with how to get this right."
So, one or many? "I think that debate just continues to rage on," he says.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article