Coworkers discussing something

Knowledge base creation process explained

Knowledge base creation process from A to Z - what you need to know before tackling the project that will make the lives of your customer service team easier. 

Reading Time13 min

Customer experience is among the building blocks of business success. 

Providing your clients or customers with exactly the product or service they need is not enough to remain relevant in a highly competitive business environment.  

To truly ensure the long-term satisfaction of your customers or your client’s customers, you have to continually provide them support and nurture that relationship. Simply put, the customers need to get the information precisely when they need it. 

And who’s on the frontline making it happen? Well, you highly-efficient goal-oriented customer service team, of course. To aid them in providing stellar customer service, they need the right tools, but also a reliable source of information. This is where a knowledge base comes in - a comprehensive repository about a product or service, (or a topic, in some cases) which is constantly kept up-to-date.

And how does one concoct a knowledge base? As with any endeavor one tackles, preparation is half the work done; after that comes the actual creation of the repository, and then, of course, publishing and polishing it based on feedback.

But let’s not get ahead of ourselves - let’s first break down the process.

The ABC of knowledge base creation

As the topic/product/service that the knowledge base covers can be quite diverse, there is not much sense in getting into too much detail so this blog will be succinct.

On to the first stop: preparation.

Preparation

Audience

Who are you making this repository for? 

Is it for the customer service team or the customers themselves? For the purpose of this blog, we will focus on repositories for the customer service team since knowledge base repositories for customers as well as FAQs can be easily written based on the one made for the customer service team.

While we are at it, it doesn’t hurt to point to the difference between a FAQ and a knowledge base: FAQ is a more modest repository of answered questions, usually placed on a webpage, while a knowledge base is a more extensive collection of information.

Goal

What is the goal of this repository? 

In this case, the goal is for your client’s or your customer service team to have all info at their fingertips. It often happens that the customer’s questions repeat and so do the responses. Re-typing the same responses over and over again will exhaust even the most patient customer service agent, as our own resilient customer service team can confirm. 

Having a repository of answers ready saves time as most of the team’s agents start making their own “cheat sheets” with responses. It also allows agents to spend more time, if necessary, analyzing the problem as well as personalizing the response to avoid sounding like a bot. In a world where we value individualism, personal touch in communication can go a long way.

Source

What or who is your source of information? 

There’s a really big difference between creating a knowledge base on top of the real questions of customers and only on top of products features and requirements.

If your product/service is in its early stages, it’s only natural you don’t have an abundance of feedback from the customers. However, it’s wise to provide your customer service team with a source of information from the very beginning as that will be the basis which will, later on, be re-shaped, based on queries. As far as the knowledge base creation process goes, the challenge in this regard is putting yourself in the shoes of the customer. It’s necessary to know the product/service inside and out as well as for whom they are intended to be able to anticipate their questions.

In case you are not creating a knowledge base from scratch but building it based on the questions customers asked, it’s more likely that there will be fewer changes to the repository later on. The challenging part from this perspective is organizing the communication flow with the customer service team in order to accumulate feedback and assess what should be included.

Structure 

How will you structure the repository?

The structure can depend on a couple of factors such as the needs of the team and the choice of the platform the knowledge base will be accessed from.

Some knowledge base repositories have a relatively simple structure. The main topics always come first (e.g. main features of the product/service or the most frequent issues that customers have encountered). Then the sub-topics and questions are formed around it as you dive into the project deeper.

However, the knowledge base’s structure can be far more complex due to the nature of the client’s business (e.g. fintech) as the customer service team might require additional instructions about what response to use in which situation. This goes hand in hand with the platform the team will be using to access the knowledge base because, at times, the platform’s form dictates the structure. 

Platform

What is the platform via which the knowledge base will be accessed?

By and large, this depends on the client. Some find Google Docs enough as it allows collaboration and limits editing permissions effortlessly by simply changing their roles (i.e. Viewer, Commenter, Editor). This ensures that the customer service team doesn’t accidentally change the content of the knowledge base but still allows them to make suggestions. Luckily, there are plenty of platforms that would be a great choice for hosting a knowledge base.

Tone

How and what does your client’s brand communicate?

Taking into account the client’s brand and adjusting the knowledge base to their tone of voice is of immense importance. Some companies keep their communication with customers strictly formal, while others allow for the tone of communication to be a bit more relaxed (but still respectful, of course). 

For example, the communication around our product, Roango, is quite specific. To understand just how, we will just give a few details about the platform and its unique features: increased privacy for talents looking for a job; the matching process that facilitates companies in finding the right candidates; company culture fit that enables both the talent and the company to be satisfied with the match. Naturally, the agents' communication needs to reflect that, and so does their responses repository - straightforward and transparent answers need to disrupt the mundane candidate-company discourse. 

Another thing to keep in mind is the choice of words, a.k.a the wording. Depending on the client’s industry and business, there’s maybe an inclination to use a specific word, to make sure it resonates with the brand and the product itself. 

Team

Will the knowledge base be written by one person or a team?

Well, it depends on the “size” of the project and of course, how many people you have at your disposal. Of course, it goes without saying that the people creating the knowledge base need to possess specific skills: they need to be resourceful, proactive, good communicators, well-organized, and above all else, skilled prioritizers.

If it’s a team, their collaboration needs to be impeccable, and their planning, performance tracking, and results evaluation up to par. They should take into account the client’s brand, the needs of customers, and the customer support team, establish a rapport with the client and the CS team, and provide time estimations all the while having the established standards of content quality in mind. Barrage’s team has sprouted from our customer service team - this means that they have first-hand knowledge of the needs of agents as well as a sound understanding of the manner in which customers think.

Approval 

Who does the team ask for content approval?

It might be a Product Owner, one of the C-roles, or anyone the client appoints - whoever it is, establishing an approval process flow is paramount to the quality of the repository. Setting the flow at the onset of the process saves everyone from an excess of unnecessary correspondence and a whole lot of misunderstanding. 

Execution and publishing

After the preparation is outlined, then we get to the execution, that is, the tough grind: applying all of the above-mentioned steps and writing and rewriting, followed by some more arduous writing and rewriting. 

While on the topic of writing, one of the unexpected situations we encountered was due to search preferences. Namely, the knowledge base team had to re-enter the heading numbering by hand because otherwise, the “numbers” people from the customer service team couldn’t find what they needed. In the case of extensive repositories such as a knowledge base, that task might sound time-consuming or redundant but user experience (in this case, the customer service team) is a fundamental element of the creation process.  

Search preferences shaped another segment of a knowledge base repository we created for one of our clients. We compiled feedback from the customer service team to learn more about their search habits (e.g. what keywords or exact phrases they use, how they go about the page tree, etc.). As a result of the feedback, we realized that we need to change the labels.

Once the knowledge base team gets the approval, the content can be published and it becomes available for the customer service team to use.

The work never stops

As mentioned at the beginning, the work on a knowledge base never really stops - except perhaps when the product or service go out of use. A knowledge base is a mighty tool in the hands of a capable customer service team and it needs to be continuously groomed.

In order to analyze, revise, and improve the knowledge base’s content, usually, feedback sessions are carried out with the customer service team members to collect useful data for the improvement of the structure, content comprehension, and overall efficiency.

Knowledge base undoubtedly saves time when it comes to responding and new agent training as well. However, as significant and beneficial this repository is, without the human component, those are just words on (a digital) paper. It’s crucial that the customer service team is well-acquainted with the topic and that they personalize their responses in order to provide exceptional service.  

So, are all these activities worth it? If you value your customers and wish to maintain or gain a competitive advantage, the answer is YES.

If you still haven’t provided your customer service team with this all-powerful tool, what are waiting for?

Your take on the subject

They say knowledge has power only if you pass it on - we hope our blog post gave you valuable insight.

If you want to share your opinion or learn more about knowledge base repositories we create for our clients, feel free to contact us. We'd love to hear what you have to say!