How VTB came to a single knowledge

    Imagine that you are calling on a question to the bank's call center and get one answer. Then come to the point of sale, but the previously obtained information is irrelevant. To ensure that such discrepancies are guaranteed to be avoided, we decided to leave the existing solution created on the bank in SharePoint, processed all the content, identified data sources and consumers, and repackaged all the necessary information into a new knowledge management system - the same for all departments. In this post we will share our experience.



    Statement of the problem and choice of solution


    To begin with, all the information related to customer service, our products and services, had to be unified. Historically, knowledge was stored in three large knowledge bases created at different times, in fact, in different banks. Moreover, one of the key requirements was the ability to provide different amounts of data - for example, for points of sale and for ATP (call center). In the first case, detailed information is important: when people come to offline departments, they expect to hear all the details on issues of interest. In the second case, on the contrary, brief information is enough - the main thing is that it be provided quickly and clearly.

    The task was complicated by the fact that we had as many as six domestic customers. And, accordingly, different types of requirements. Everyone had different criteria regarding functionality, performance, and support. For example, the presence of SSO, integration with Active Directory, etc. The team’s rapid implementation capabilities were important. We expected that the new system will reduce the service time of 25% of calls to the call center by 5 seconds. It will also reduce training time. Previously, 3% of all working time was spent on this - and when it comes to more than 30,000 employees, considerable expenses are spent.

    In addition, during the project, VTB was at the stage of merging two large banks in its structure, and the clients of the future system were in different subnets, in different segments. All this had to be combined and provided to employees working with the system, end-to-end access, taking into account roles, various levels of access to information, etc. It was necessary to solve many additional infrastructure issues.

    We put all the necessary requirements and criteria into one scoring table. We looked at all the key solutions existing on the market, both Russian and foreign, uploaded portions of our content into them, and evaluated what works. And in the end, we settled on a unified knowledge management system from KMS Lighthouse. With the introduction, we were helped by the DIS Group team, which offers KMS Lighthouse in the Russian market.

    2500 articles in 16 templates for 60 thousand users


    There are two key entities in our new knowledge management system - “template” and “article”. An article is a formalized page with information. The same article looks different for all user role groups (bank employees). Groups are formed depending on the organizational, functional or business affiliation of employees.



    After analyzing the content we have, we realized that we were dealing with 2,500 articles. This sea of ​​information needed to be decomposed into the minimum allowable number of templates. Moreover, the articles were supposed to maintain the flexibility described above. There was a lot of manual work on creating templates, coordination and reconciliation. But in the end, I managed to meet 16 templates - for 2500 articles this is a good level of systematization.

    Work on content


    16 templates are distributed in three groups of content managers. The first group is responsible for the content associated with the call center. The second is for products, services and related information. The third is the content block of the operating unit (DOPB), our back office. In addition, we have a methodological unit that operates at the bank level. Almost all of the bank’s information passes through it, like through a filter, and as a result, only the information that should be placed in the knowledge base remains.

    We discussed more complex division. Thought to introduce the "owners" of the groups responsible for the process and system. We discussed the position of the “chief editor”, who will verify all changes. But in the end, we decided to focus on three groups, since the content is quite clearly divided between them.

    KMS Lighthouse allows you to quickly build several levels of coordination, but we decided not to complicate this system, and at the level of content managers we made two levels - those who write and those who publish. At the last level, those who are responsible for all the content in their group stand out. True, here the question arose of making materials on successful sales to the food division, but so far they decided to leave everything as it is.

    Thus, the knowledge base can be developed without delay. Suppose a food department wants to immediately post information about a new product. Sends a request by mail to the content manager: "Colleagues, we need to post this article here." After posting through feedback mechanisms, refinement is underway: somewhere, information may not be enough, somewhere something is not according to the template. And so on until the unit and the content manager are satisfied. Now we are just introducing the elements necessary for this interaction: notifications, surveys, approval forms. If the article being created covers the spheres of different groups of content managers, then everyone becomes responsible for their own tab.

    A separate application server is allocated for content managers, where you can edit articles or create new ones using existing templates. Here you can pull up the necessary statistics on search queries, the relevance of answers, conversions, etc. Articles can not only be changed, but also optimized - for example, create meta tags to improve the search. You can also improve your search by forcibly adding certain articles to certain queries. This is called “editor’s choice”; when searching, the user sees such materials in a separate column.

    Base Search


    In SharePoint, people are used to the tree structure of presenting information and interacting with tabs. KMS Lighthouse involves the use of a full search. When 60 thousand users work with the system (on average about 1600 at a time), it is worth thinking about load balancing. Now KMS Lighthouse runs on 10 servers. Each deployed two virtual machines. A bunch of 20 virtual machines work. Between them is a bank balancer.



    Search is based on three search engines that index all content. Search indexes are built taking into account incoming requests, their frequency. The relevance of the answers and their position in the output results depend on this. Lighthouse analyzes requests and can present them in the form of 16 different reports, with the help of which content managers work on filling the system.

    Additional features


    All employees working with the system are divided into approximately 35 role groups. Each has access to certain parts of the articles. A user can be in several groups - then he sees the content for all these groups at once.

    Groups are integrated with email and SMS gateways. When working with a bank client, an employee can quickly send him the necessary information - for example, right during a telephone consultation. If, of course, information can be sent; articles about disclosure (and print acceptability) indicate individual attributes. No need to rewrite and copy-paste anything.



    Yandex.Maps are also integrated into the knowledge base, through which employees see how busy certain departments are. Information is updated every half hour. So, having determined in which departments the client can receive this or that service, employees can advise where exactly it is better to address in order to save time.

    KMS Lighthouse is integrated with our front-end system and can be brought directly to its interface as a widget. In it, you can make a quick request and immediately go to the article - as in any search engine.

    This is how our new knowledge base is organized. Now we are finalizing it and expect that not only employees but also VTB customers will appreciate the positive effect of the KMS Lighthouse implementation.



    In conclusion, we want to share our joy. In January, our Business Wikipedia was announced the project of the year according to the Global CIO. We will keep you posted and tell what new we fasten to it and how it helps the work.

    Also popular now: