As was mentioned last time, a product catalog is a critical component for companies wanting to apply the multichannel/omnichannel sales approach – to sell on more than one sales channel. To do that effectively, they need a single source of truth about their offer. A product catalog is exactly that single source of truth – delivering consistent (but not necessarily identical) information on the products on offer, their characteristics, delivery terms and prices to all the sales channels. Last time, we focused on FinTech, today we’ll look at the application of a product catalog in some other sectors. The general rule here is the same as for e-shops and banks – a product catalog makes possible the management of the offer in one place and its consistent and quick availability on all sales channels. But each sector has its specifics, which we are going to deal with today.
The primary specificity of telecommunications operators is that their products require activation and configuration in many technological systems. If you look at operator websites, you will find they compete with each other by offering a variety of packages. Most of them include a wide range of products, from land lines and mobile tariffs to data and TV channels. When you buy a telecommunication package in an e-shop of such an operator, it is necessary to inform a number of internal systems on the correct settings of parameters for you. Thus a telecommunications operator’s product catalog must not only retain information on the product offer but also the configuration of what the purchase of a given product means and how to communicate its purchase to the other systems.
In addition to a wide use of packages and the need to retain the configurations of the offered products for other systems, telecommunications operators also have a third specificity – much more than anyone else they care about acceptable product combinations. In their offer they strictly control which products are mutually compatible and which are not, which means and devices may be used together, or what infrastructure (and also connection parameters) are available at a given location.
Packaging is a general concept, which we have already mentioned before. It refers to the ability of a product catalog to create new products by compiling the existing ones. The new product is given its own name, image and is included in the offer. The customer may still purchase the original basic products (unless intentionally withdrawn from the offer) or chose to buy the entire package. What is it good for? Firstly, with a package we usually solve the customer’s entire problem and spare them the effort of thinking. In this way we increase the probability that they actually will make a purchase. Secondly, in a package we can add additional useful products they would not think of. Thereby we increase the volume of sales. Thus we can sell more and more often.
The pricing of packages is also an interesting topic. Fixed packages are the simplest – let’s throw concrete products on a pile and attach some fixed price to the whole of it. A flexi package is a more complex alternative – we only need to define options and limits for customers so that they can compile a package of their own choice The price is calculated based on a formula (not necessarily a simple summation). A special category is marketing packages. These are not available on offer as a separate product but rather as a relationship of products that says “if in addition to the selected product you buy this particular item, you will get a discount”. When to use a particular type of package is now entirely up to the opinion of the product manager.
Energy companies supply our homes and workplaces with electricity and gas. The actual calculation of these commodities is a rather complex process, taking into account the prices of various market components, currency exchange rates, temperature fluctuations during the year, and consumption time series (load profiles – LP). The price of commodities is largely determined by the market regulators and the purchase price on the European market. When an energy company wants to distinguish itself from its competitors by features other than just a lower price, it needs to offer some “added value”. This may involve, for instance, supplementary services such as the installation of a device or boiler inspections. Or some considerably more expensive energy components replacing (fully or partially) the supplied commodities – heat pumps, solar panels, or batteries to store the produced electricity. Also offered are virtual batteries, when you can have the produced energy “stored” (for a fee, of course) with the operator – which is no longer a component, but a service. A combination of various commodity tariffs, technological components and supplementary services is, naturally, an ideal environment for the use of product packages the price of which is calculated according to a given formula from the individual parts.
As for the above-mentioned solar panels, their installation is not an easy task which a customer is able to design by himself. So energy companies must offer not only components, but also the design of the entire project. Each project must on the one hand take into account the specific situation of a client (each roof is different), on the other hand, must not place excessive time demands for specialists (that would be expensive). The solution lies in configurators – software containing pre-defined component configurations and allowing for the addition, removal, or change of individual components. And of course, the recalculation of prices after each change. A large project cannot be designed like that – this requires a specialist who draws the project on a canvas and considers all the details. But it is possible to create a self-service platform for hundreds of owners of small houses, who will be able in this way to design their individual solutions – similar to each other but with minor differences. Needless to say that behind such a configurator there is typically a product catalog, maintaining for the configurator all usable components as well as pre-defined default configurations.
Speaking of energy, one must also mention price comparison engines. Their function is very similar to the insurance and other financial product comparison engines mentioned in the last part. They retain information on the offers on the market, obtain information from clients on their specific situation, and select from the available supplier price lists several tariffs most suitable for a particular client. The requirements of comparison engines in the energy sector are very similar to those in finance – it is necessary to maintain information on complex products, flexibly change the structure and the order of the input form questions, and asses the suitability of a product for a specific customer. The main difference from financial product comparison engines is the complexity of the entire process of the transfer of energy supplies to another supplier. The process is defined by law and involves not only the customer and the new supplier, but also the regulator and the original supplier. Usable for the management of such a process is another part of a product catalog – the sales workflow. But that’s another story for another time.
A considerable part of what has been said about energy companies also applies to manufacturers. Of course, it is not about the sale of commodities. The similarity lies in the sale of technological components, which can be sold individually or in larger units. Let’s take, for example, a car maker. A car maker tries to attract clients by allowing them to customize their car. This again is a job for a configurator. In it we can select the engine, the colour, the wheels, the equipment, and miscellaneous accessories. With any change, the price is recalculated right away (and it does not necessarily have to be a simple sum of the prices of the components). We may use ready-made configurations and make additions to them (or sometimes do the opposite). To that end, the configurator needs to know the links between components, thus it only enables us to add and remove items to the extent that the resultant combination makes sense. Similarly, a configurator may automatically offer for each used component the list of their alternatives. The fact that a certain component requires, is incompatible with, or is an alternative to another component is expressed in the product catalog with configurable links among the individual products and constitutes an important part of the product model.
The second aspect of manufacturing firms is wholesale. Growing numbers of purchasers optimise purchase prices by purchasing from several suppliers and choosing the lowest price. If the supply side is large, purchasers cannot rely on humans to do all the work in selecting the ideal suppliers. This has to run automatically. But for a purchaser to be able to automate the selection process, the supplier must automatically supply information on its offer, prices and availability. The supplier must update this information frequently (daily) and quickly deliver it to customers so that they are willing to make purchases.
Moreover, manufacturing firms may use a product catalog not only for sales but also for purchasing. When our subcontractors are already sending us information about their offers, where else should we import such information than the product catalog? Subsequently, we can compare the offers and select the most suitable ones.
This concludes the list of situations where a product catalog can be used to make work easier for people (at least for now). Starting next time, we will focus on the specific attributes of a product catalog and their solutions. We will have look at why WisePorter is referred to as a “smart” product catalog. We will get back to the basic characteristics of a catalog (speed, scalability, flexibility, integration) and see in what manner these can be achieved. And if there are any questions, objections, opinions or comments from our readers, we will gladly take time to respond to them.
About the WisePorter team:
Lenka Michalská is one of the founders of the WisePorter team. Currently, her primary focus is on business architecture – she looks for the best way to integrate WisePorter into customers’ existing infrastructure.
Lenka has over ten years of experience in product management and pricing policy. She successfully completed many projects in many diverse sectors – from finance, insurance and telecommunications, over energy and e-commerce to pharmacy. Thanks to her experience, she can tell what works in which situations and what does not. She applies her expertise to find the optimum architecture for each client so that each project brings as much flexibility to their business as possible, while taking into account existing systems as well as the time and funds available.