In February, we at Kaspersky Lab held a large meetup called the Healthy Technique Knowledge Base. Five of our colleagues from different companies who are engaged in knowledge management and manage the work with technical documentation and web content, talked about how it works for them.
Here in the post is a brief squeeze of the air in seven key theses. If you are interested in listening to a more detailed discussion and arguments of the participants, watch the recording of the meetup Here or in the widget below. And you can also freely communicate with the participants of the broadcast in this chat.
- Before creating a Knowledge Base, you need to determine whether it is really needed and what problems it will solve. Perhaps, in your particular case, it will be possible to get by with a stub of paper and a conditional Google doc and save the company a lot of money and man-hours. Moreover, spontaneous Knowledge Bases are like shooting stars: they may be able to live brightly, but only their life will be very short. So leave all sorts of “there is no goal, there is only a way” to the samurai and budget cutters.
- Since all the knowledge bases of healthy technical writings live on the web, it is necessary to develop the knowledge base as a web resource. Invest in search and SEO, use web analytics, collect feedback from users through a form, etc. Moreover, the site itself is not so important – it can be a website, Confluence, SharePoint, whatever.
- Content for the Knowledge Base is literally lying under your feet. Be like a hamster, drag everything and everywhere into the hole: from answers in chats, drafts, personal notes, meeting minutes to copy-paste of a conditional article on Habré (for example, ours))).
- An internal Knowledge Base may be part of the company’s knowledge management, but the Knowledge Base is not the same as knowledge management. In short, the presence of a knowledge base does not cover the entire layer of knowledge management. But still, the knowledge base can be used as part of it during onboarding, for training employees, for exchanging experience, and that’s all.
- For the Knowledge Base to take off and not fall, it must have support from the company’s management. Well, in order for the knowledge base to work, and not just “be there,” it must be promoted.
Getting support is easy. First, you fix all the game that happens in a company without a Knowledge Base. Secondly, you communicate with those who suffer from this game in order to paint all these horrors more terrible. Thirdly, for each problem you come up with how the knowledge base will help solve it. Fourth – go sell the idea to the authorities. PROFIT!
And to promote the knowledge base, write digests, conduct interviews, involve people from various departments and show the benefits they will receive. Then these people will tell their other colleagues about you. Give active users a case of beer with gifts, merch, in general, all kinds of goodies. How is it “no one here likes beer ?!”
- FAQ is great, but not always necessary. If the FAQ has a clear and specific purpose, and it is based on an analysis of the problems that users most often have, and in addition it is SEO-optimized, then this is the coolest rejection tool. But if this is just a trendy page, almost like in the previous paragraph, “well, everyone has it, so I need it too”, then get ready to clone yourself: most likely, there will be little use, but the resources for updating and supporting it will come from somewhere – something to take.
- The key performance indicators of the KB are visits, CSAT and deviation rate. In some cases, the bounce rate is also useful, which will help analyze the behavior and activity of visitors. However, the Knowledge Base will not have fake KPIs – each metric will show something useful. But still, some metrics may differ depending on the tasks facing the knowledge base. But those that we cited above are reinforced concrete.
Do not miss our next events. Register, and we will remind you about the meetup and send you a link to connect before starting.