PIM, Part 3: A product catalog for FinTech, banks and comparison engines
Having read the previous two parts you may think that a product catalog (or PIM) is an information system intended specially for e-shops. To think that would be a great mistake. A similar system is necessary also for banks, insurance companies, telecommunication operators, car makers, pharmaceutical and a lot of other businesses. Why? This is what we will have a look at in the next two parts of our blog.
Last time an e-shop was taken as an example. E-shops are simple. All of us are making purchases in e-shops (and apparently we will for a long time …) and we are able to imagine how they work. But in many other fields the benefits of a product catalog are no less important. The reason is a word that currently moves modern business – multichannel. And its bigger brother – omnichannel. Selling through multiple sales channels (all of them in an ideal case). So, what do modern financial institutions do to be able to acquire new clients in such environment?
For a long time, banks were used to the situation that whoever wished to deposit or borrow money would come to their beautiful marble edifices and listen patiently to what they could offer. But more and more customers wish to make their purchases from the comfort of their homes. And the forty-seventh covid lockdown in a row has undermined the resolve of even the most dogged advocates of personal visits. Moreover, the operation of a marble edifice with a lot of people has its costs. In comparison to a bank’s branch office, the operation of a few on-line sales servers is essentially for free.
Having mentioned omnichannel sales, it needs to be added that branch offices and the internet are not at all the only channels through which banks sell their products. Their products are also offered by external agents, comparison engines, call centers, partner organizations, simply one sales channel after another. With a few exceptions all sales channels can sell all products of a bank. Or at least initiate their sale—legislators are desperately behind times and a hand-written signature still is necessary for the purchase of many products.
What more, in the case of complex products (as those of a bank are) customers will as part of their Customer Experience often try out several channels before making a purchase. Firstly, they will study the offer in the warmth of their homes and then come to a branch to ask the last two questions before signing a contract. In such situation the key is to provide them with consistent information in all channels. Because a customer who sees some information on a computer at home, then sees it differently in his or her mobile while on a bus and finally learns something else at the branch office … such customer will go shopping to a more trustworthy company.
Simply put: multichannel = good. Provision of different information through each channel = bad.
Banks know this. That is why they include some form of a product catalog (PIM) in their infrastructure. A catalog ensures that customers will get consistent information through all sales channels. Because all the channels use the same source. Such source is referred to as the SSOT—Single Source of Truth.
Do you wonder what is so complicated about it? That’s because you have not realized how many information systems an ordinary bank has after twenty years of progressive digitization. Hundreds. And that’s the optimistic scenario. Many of them store information indispensable for sales. Sales channels must send requests to each of them. Or … or a bank must introduce a smart product catalog as a SSOT for the provision of product information to all sales channels in a consistent manner. (Please, notice that what is provided is consistent information, not necessarily identical. Each channel may be supplied with diverse information—which sometimes is desirable. But such diversity must be intentional and controlled.)
Do you still find it simple? Then add bank market consolidation into the mix as well. Big banks buy smaller banks, insurance companies, savings banks and consulting houses. Each purchased institution has its own products and maintains its products in its own systems. However, the owners want to sell the products of all the group members. This is why they bought all those other institutions, why they create a group identity—so that they can offer their customers the coverage of all their financial needs under one brand. This is why product packages are created to convince a customer to buy a mortgage, insurance, savings scheme and investments from them. To achieve this each group member must also offer the products of its sister companies. Where will they learn about them? Have a guess.
OK, this was banks. But what about comparison engines for insurance (or loans or other financial products)? Their work is to maintain information on the offer of insurance on the market, obtain information from clients on their situation and then recommend them several options most suitable for them. So, they need a system in which they can maintain information on the available insurance products from different providers. And not only that. They also need to assess this information. A comparison engine must take the information about each individual client, input it in all possible insurance products and assess which options are the best for a particular client. It needs to calculate with reasonable accuracy what specific parameters a given insurance will have for a particular client. (With reasonable accuracy-insurance companies often have specialized insurance calculation systems and comparison engines only try to emulate them in a simplified manner. For the selection of insurance this will do.)
And this is not even the complicated part. To acquire information from a potential client about his or her situation is more complicated than calculate insurance. This often involves sensitive personal data we do not like to disclose. To start the first step asking how many times someone had an STD is not a good recipe for the acquisition of new clients. But when a comparison engine needs to ask a question like that to calculate insurance, which step is the right one? There is no right answer. These settings have to be fine-tuned with time. A comparison engine operator must make constant modifications of the questions given to a client in each step. The input data forms must be easy to configure. We need an environment in which we can save the individual steps of the input form, the questions for each step, the links between the questions and we also need to be able to easily change all of this … Yes, also this configuration can be efficiently managed a in smart product catalog. With regard to the fact that it is in essence a modelling tool, we can use it to easily model, in addition to financial products, forms and their content and subsequently change them as necessary.
To conclude and summarize: A smart product catalog (PIM) is indispensable for multichannel/omnichannel sales. It serves as a single source of truth (SSOT). Banks and financial groups use it for the creation of group identity and the sale of the products of all the group companies. On-line comparison engines need to make flexible adjustments of how the client personal data are obtained through an input form. Based on these data suitable quotes are calculated. Both can be done very effectively in a smart product catalog.
A small clarification at the end: There is a lot of PIM systems which are designed specifically for e-commerce. Naturally e-commerce is an area which currently experiences a rapid growth. But we aren’t going to make an in-depth examination of those systems here and we’ll continue to approach product information management from a wider perspective across sectors. Next time we’ll have a look at the use of a product catalog for the improvement of sales of telecommunication and energy companies, pharmaceutical distributors and the automotive industry.
About the author: DaN Štourač is one of the newest members of the WisePorter team and his responsibility is the relations with new customers. When we decided a few weeks ago to start working on this blog, the fundamental question of “Who should be the one to actually write it” arose. And as the famous Czech universal genius Jára Cimrman would put it, DaN was happy to finally have to admit that the text most comprehensible for the public would be his own. As a newcomer he will not have the tendency to sink into technical details he himself has no knowledge about. The question that is still left unanswered is who will take over the blog next month when DaN has exhausted his limited knowledge. A few candidates will be introduced in the next parts of the blog.
