Your software is great – as long as people use it correctly.
Unfortunately, users always end up doing something the developers didn’t foresee. Maybe there’s a bug with the platform that they load your app on, or maybe it’s something as simple as expecting a keyboard shortcut where there is none.
That’s where support comes in.
Support as a concept and as execution forms a major part of running a business. Having the right customer service docs available and the right people to guide your customers to solutions is extremely valuable.
Traditionally, the training process for a customer support agent has been a long learning curve as they have to be supplied with scripts and protocols for all the common questions, plus be equipped to seek out solutions for the uncommon ones.
The advent of knowledge bases has added another factor in this calculation. Now, software companies around the globe are relying on knowledge bases to supplement their support agents in the effort to provide timely and helpful assistance to their users.
In this article, you’ll see some of the major reasons why an internal customer support knowledge base can be a game-changer in the long term for your company’s support needs.
External and Internal Knowledge Bases
If you’ve heard about knowledge bases before, you’ve probably gotten familiar with external knowledge bases. After all, these are the ones that you see all around the web. The only way you would have first-hand knowledge of an internal knowledge base is if you were part of a customer service team that was already using one!
The differences can be summarized in six main points.
External Knowledge Bases
First, external knowledge bases are designed for customers. The base concept is that customers will search for answers to their problems and find quick articles containing solutions.
They’re built around articles organized into categories of support questions that users come up with. For example, a PDF design suite might have sections on “Security,” “Print Formatting,” and “Fonts.” Each of those would in turn have a handful of targeted articles fitting that theme, like “Protecting the document with a password,” and “Levels of Access.”
Each article is designed to be only a couple of hundred words in length, focused on brevity for max efficiency. Nobody wants to scroll past pages and pages of verbose content about the vision of the design team or the history of the company – but that kind of stuff really did use to appear in documentation!
This is all in order to take the load off the support team. Knowledge bases were developed because there was a severe shortage of users who were actually reading the confusing and hard-to-access documentation supplied with most programs. That meant that the customer support agents were constantly having to answer the same questions, like “where is the save button” and “how can I undo?”
Not only was that soul-crushing for the people behind the phone lines, it was increasing wait times for people with tougher questions. By clearing out the question queue to an extent, it helped save on customer service costs and make everyone happier.
And that included users, because users like to help themselves. A user who manages to solve their own problems, even if after looking at the documentation, is a user who feels accomplished about their own abilities.
People aren’t going to write reviews online saying how happy they were that they fixed whatever was going wrong, but they’re also not going to write angry reviews about how tough the software is to use. Keeping the majority of the customer base pleased with their own abilities is a major plus for any company.
It also makes people more likely to recommend the software to others, leading to a domino effect of positive outcomes across the whole company.
Clearly, external knowledge bases have their advantages. What then of internal ones?
Internal Knowledge Bases
In contrast to external ones, internal knowledge bases are designed for support agents. That means from the get-go, they’re aimed at people who already have a strong knowledge of the product itself and want to use that knowledge to help others out.
In essence, they’re not necessarily going to have to go into detail about the features of the software from a user standpoint. There’s no reason to have an article like “getting started installing the software” when everyone on the support team uses it every day.
Instead, the internal knowledge base is a reference for how to resolve issues. It kind of crosses over here into a company handbook, because it should include policies and procedures for dealing with customers as they have questions about the software.
Think of it like this: starting with a blank slate, an agent answers a question using their expertise. Then they write down how they answered that question and move on to the next one. Later on, they’re bound to come across that same question again.
Obviously, they’ll refer to their notes to recall exactly how they did it. The internal knowledge base thus acts as a reminder for the best way to handle a case, and it can be edited and improved over time.
Expand that concept to an entire team of agents all working on the same type of editing, and it’s easy to see how the group knowledge of an expert support team can be codified and used in a positive way.
This leads to the last point, which is that agents help themselves. A new person getting trained is likely to have to come to more experienced agents and ask similar questions over and over. It doesn’t matter how bright they are – there’s a lot to learn with any software platform.
Constantly asking co-workers for advice, though, is less than perfectly efficient. Each time an engineer is working on a project and they get asked about a particular feature, that’s a chunk of lost time answering the question plus lost time as they get back into the groove of programming.
Let’s go a little deeper into the advantages of using a knowledge base as a robust internal training tool.
A Knowledge Base as a Support Training Tool
First, we can map out the training process of a new help desk agent without a dynamic knowledge base to help them along.
We can assume that they’re hired with a general knowledge of that type of software and the issues that are likely to arise when using it – maybe they’re moving to support from a different team or they’re totally new to the company.
Either way, they’ll have to start out by reading through the documentation, but if it’s just a PDF or a static site, it’s easy for one’s attention to wander somewhere between, oh, pages 20 and 200. It’s only natural that they won’t remember everything on the first go-round.
Then they’ll have to start sitting in on a few live chats and support calls, taking notes as they go and then hopefully organizing them and revising them over time. In practice, though, how often do you really look back at notes you took during a training meeting?
It’s much easier, though less efficient, to keep asking other people about the best way to handle a particular type of support call, or to ask for a quick sanity check on an email before sending it off.
That’s the rub, really – this kind of training has worked out fine for tons of companies.
It’s just that an internal knowledge base can make it better.
Training someone with a knowledge base as the central point of reference goes so much smoother because they now have that security of an official, authoritative central point of expertise.
Instead of being told to just “read the docs,” new team members can be given a hypothetical scenario or a typical problem and look it up in the knowledge base to see what the best protocol for answering it is. Just like users are satisfied when they can answer their own questions, new employees are satisfied when they can come up with the correct protocols on their own.
New team members are also often worried about doing the wrong thing, so putting that fear to rest with robust training documentation is a great advantage for getting people comfortable with the internal best practices.
Finally, adding articles and revising other articles is training in itself. Even after the first couple of support calls, there might be new things that they can add to the knowledge base to let people know what they thought of a particular solution.
For example, if they tried one script on a user and it didn’t work at all, it should be easy to add a note saying as much and explaining what was finally done in the end to solve the ticket.
They’ll also naturally have edits and revisions to make to other articles, especially if new product updates come out that change the support answers.
As a bonus, internal knowledge bases can also be used to share information about different company policies like sick pay, health insurance, or vacations. By law, employees are required to receive packets of information each year about their insurance policies, but who really reads those? They get stuffed into a bottom drawer and forgotten.
But things like benefits are often embarrassing or uncomfortable to talk about with management, which can lead to a vicious cycle of employees not knowing about their benefits, not using them, and assuming that they’re bad benefits to begin with.
Employee benefits go unused all the time!
However, with just a handful of employee benefit pages on the knowledge base, perhaps in a separate section that doesn’t pop up in searches for product features, employees will be more aware of and more appreciative of their benefits packages, leading to higher morale in the company.
Features for Internal Knowledge Bases
So when you’re looking for an internal knowledge base solution, you should have a couple of key features in mind.
Does the search bar do everything?
The search bar is the cornerstone of a strong knowledge base experience, seeing as it’s the first thing everyone sees when they open up the start page.
It should ideally be able to perform fuzzy matching so that a search for a keyword should return relevant results. It should search through the full text of each article, the title, and the tags. Articles should be returned in an order with some real thought behind it, not just “most matches” or “most popular article first.”
At Document360, the user can selectively disable certain articles from showing up in the search results. This is useful when some big changes have just been made and you want to prevent people from seeing the old solutions until new or updated ones can be written.
Layout and User Experience
The layout should fit well with your company branding. Even if customers aren’t seeing it, employees themselves might think it’s a bit jarring to see a totally different color scheme or logo on the internal support page. That screams “third-party solution.”
It should be easy for anyone to create new pages that look exactly the same when published as to when envisioned. At Document360, you can go code-free, there’s no reason for a tech support specialist to have to wrestle with HTML and CSS in order to write up a single article. At the same time, the editor offers granular control if necessary.
Versioning and Localization
When big changes come out of the dev team, in a perfect world they’d be announced well in advance and the support team would draft up some guidelines for how they should respond to user questions on the new features. That way, when the updates are launched, the support team just switches to the already-prepared version of the knowledge base without missing a beat.
Versioning also allows for rollbacks to previous states, such as if someone makes a mistake and erases a bunch of pages by accident. In cases like that, an ounce of prevention is really worth a pound of cure.
And what about guides in other languages? Your company may have multilingual support requiring guidelines of their own when dealing with customers from their part of the globe. It should be easy to clone a knowledge base, get it translated, and have it set up with every support office in every country. Document360 can support over 10+ languages making your knowledge base highly usable.
You don’t need every user to be able to edit every page. In the example earlier, there’s no need for anybody but HR to add new information about benefits, but there’s also no need for HR to be able to edit help desk articles.
This can prevent accidental changes from being made to the wrong areas of the knowledge base, and it can also prevent “ambitious” people from changing documentation outside their areas of expertise because they think they know best.
At Document360 you can stack content in a tree view structure and store up to six subcategories.
Ability to Brainstorm
Collaboration is tremendously important when a team is coming up with procedures for helping out the users. Each page should be able to have comments visible to all with suggestions about the page – different from actually editing the page directly.
In Document360, for instance, it doesn’t matter what access level the users have. You can still see a comment feed of discussion by everyone involved, letting you know what people all across the organization think of the page and the proposed changes.
Although analytics is an impressive selling point for external knowledge bases, they’re just as important with internal knowledge bases. The same metrics even apply: pages that are viewed more should be audited more frequently, and pages that are viewed less should be revamped so they’re providing the most actionable suggestions possible.
At Document360, for internal Knowledge base you can get helpful insights from team analytics even at individual level, who contributed what and when and how their contributions are performing. This will keep knowledge sharing competitive and motivating for the team.
The “page voting” feature, where readers vote pages as “helpful” or “unhelpful,” can also be surprisingly revealing. The votes are anonymous, so you may find that people give more honest feedback than you expect.
The only metric that might not matter as much is the “age of article.” For example, writing that “mail deliveries should be placed on the counter next to the break room” might be a long-standing company policy existing long before the knowledge base was ever built. Don’t fix what isn’t broken!
Optimizing Your Internal Knowledge Base
But speaking of fixing and improving, it’s important to go over some of the best practices for writing and auditing your posts, just so that they’re kept in top shape.
Even though we’re talking about an internally-facing knowledge base, poor writing will still reflect badly on your company as a whole. New hires won’t be impressed by sloppy typos in the guidelines – after all, it’s some of the first stuff they see!
The simpler the guidelines can be made, the more they’ll be appreciated. New hires and old hands alike hate trying to wade through complex and intricate writing just to figure out how to run reports. This is one place where fewer words pretty much directly correlate with efficient policies, so definitely try to keep the word count down as much as you can.
You may be tempted to add lots of screenshots or even screen recordings. However, do keep in mind that static images take more time to recreate once they age out of usefulness. Text posts can simply be edited in a matter of seconds, but it can take a little bit to get to the right screen for your screenshot, crop it, and embed it correctly in the post body.
And of course, there’s no use in keeping outdated knowledge.
Every quarter or so, make sure that you audit your internal knowledge base for correctness and simplicity.
That means going through all the posts (use the metrics as a guide for what to start with) and make sure the links all work, the screenshots are all up to date, and the support processes outlined are what everyone’s still agreed upon.
You should also try to invite people from several different departments to weigh in and contribute their expertise.
Specifically ask for feedback about what to improve, and push this point so your coworkers know you’re treating their opinions seriously.
Even if you work for a very small company, your coworkers are definitely going to have their own unique ideas about what information is important to note down. Everybody has their own tips and tricks accumulated over the time they’ve been with the company, and so even having one more pair of eyes on the articles can be critical for hunting down errors and optimizing content.
Using Document360 as an Internal Knowledge Base
Document360 has some great features that make it ideal for use in your company as an internal knowledge base.
First of all, all the functionality we’ve alluded to so far in this article is present in Document360. You’ve got your versioning, user hierarchy, advanced analytics, and more.
It’s also beautifully designed and fully customizable to the rest of your website’s functionality. From the ground up, it was envisioned as a user-friendly knowledge management platform in which each control is intuitive.
And the best part is, you can get started in minutes with a free trial, since it’s all hosted on Document360’s secure servers. There’s nothing you need to migrate over to your environment – just start creating articles and keep going.
Even before you sign up, you’ll gain access to the documentation (itself hosted on Document360 as an example of ideal documentation writing best practices.
For instance, you can find out how to best use the tagging feature to tag multiple articles all in the same topic category. Then it’s easy to move groups of articles, hide them temporarily, or even delete them outright if they’ve become outdated.
The best way to figure out what the best feature set is for your particular needs is to just start using a knowledge base software and see how you like it!
With Document360, you can get started right away and see how easy it is to get used to the intuitive user interface. If you have suggestions for the design team, send them over – and if not, enjoy the experience of setting up your first internal knowledge base!