Last updated on Oct 1, 2020
Plenty of companies would like to be the one you end up choosing to help build your business. When it comes to customer service and user support, it can seem like the options are absolutely limitless.
In that vast ecosystem, even one specific niche like product documentation can still have overwhelming choices. That’s why it’s important to break down feature lists and see exactly how each one stacks up next to the other.
It turns out that the very best product documentation tools are specialized and built to do just one thing well instead of being integrated parts of a larger help desk system. In this article, you’ll see what features make the best knowledge base platforms deserving of their top spot.
It’s easy to just sit down, open up Word, and start writing documentation. After all, you know the product and how to use it, and so what you write is going to be clear, accurate, and helpful, right?
You’re not wrong!
But think about how people are going to access that documentation.
If you have this on a static webpage that gets updated and refreshed every so often, then you force users to search through manually for everything that they need answered. The same goes for a PDF hosted on your site – it might look nice if you laid it out well, but it’s likely to cause headaches to people trying to get their questions answered in a hurry.
And what happens if you make a mistake when editing and want to revert back to something you had before – or what happens if you need to give some people access to one version and others access to another?
Those questions are all answered with the words “knowledge base.”
Document360 is just one of the many solutions out there for organizing your documentation knowledge into a clear and coherent knowledge base.
Everything from the page editor to the analytics dashboard has been designed by knowledge base experts to make it as efficient as possible to write, proofread, review, and publish your articles – then update them after the fact!
Below you’ll find some of the must-have features that users and writers greatly appreciate in their knowledge bases.
Does your current knowledge management platform check all of these boxes?
Let’s do a deep dive into the key flagship features of knowledge management systems and why they’re important for your business.
Most software companies are developing fast. New features come down through the pipeline constantly, and with software as a service, your users may not even notice the majority of the bug fixes and new functionalities that become available with each new iteration.
Over time, though, the difference between the last version of the documentation and the current version of the product starts to become more and more apparent, leading eventually to moments of confusion when customers check the documentation but can’t find the right information they need.
And besides, what if your support and documentation team is comprised of more than a few people? They’ll all have input on your documentation articles, as they should, but it can be hard to keep track of who contributed what.
That’s why editing an already-published article doesn’t just remove the old version. It saves it and marks the new one as “version 2,” so that you can go back to the first version at any time as well as see who was responsible for pushing out the new update.
After new versions of each article are published, you might find that you want to compare them and see the differences. This can be tedious if you’re not using a knowledge management platform – imagine opening up a bunch of different Word documents or Google Docs windows and looking line by line through each one!
As you can see in the screenshot above, the changes between any two article versions are highlighted in contrasting colors so you can see at a glance what changed and who made the changes.
Finally, all of this can apply to the macro level as well when you roll out an entirely new version of the whole knowledge base. Say you’re working on a Version 2.0 release for your main project with a lot of UI changes. You’ll want to create an entirely new Version 2.0 knowledge base as well, since you’ll inevitably have people still using Version 1.0 and looking for legacy support for a few more months (or years…).
Project-level versioning supports tags such as “beta” or “deprecated” as well, giving you fine-grained control over what the users see when they head to the knowledge base.
Knowledge bases live and die with their searches. Although some users are content to scroll through the article organization section and look at the categories to drill down and find what they need for their own queries, most people will make a beeline toward the search bar.
The search bar should use fuzzy matching and intelligent prediction to guess at exactly what your users want to see when they type in a specific keyword. That means if they’ve spelled something wrong or entered something similar to what’s actually in the knowledge base, they’ll still get the answers as if they did everything just right.
It’s also instant. Your programmers might remember from their Algorithms classes that search algorithms are actually quite complicated to do correctly. And yet many development teams have done amazing work to get rapid and accurate search results across hundreds of possible articles, scaling up beautifully with the complexity of your product.
By the way, here’s a helpful tip to make sure your articles are really leading your customers to the right places: add useful tags and titles to each article. The search algorithm looks through the full text of each knowledge base article, but also at the additional tags assigned to them and the text in the title.
So if your article is about adding images to a page, you might consider tagging it with “photo” or “illustration” or “screenshot” so that the algorithm will pick the article up for these search queries as well.
Analytics go hand-in-hand with search, since search is the main way users are going to interact with your knowledge base.
That gives you a treasure trove of information on what they’re actually getting out of your customer service knowledge base project.
For instance, one of the best search metrics is the number of entered queries that returned zero results.
This should be quite a low number, ideally! However, it’s normal to have a couple entries there, since people are going to enter random keystrokes by mistake or do something else unrelated to the knowledge base’s general function – mistakes happen.
You should look through that list relatively frequently in any case, though, because if you see things that would make useful article subjects, the fact that someone actually searched for them in the past is reason enough to spend time writing that article.
You’ll also get the standard set of metrics such as number of visitors per time period and number of searches per visitor.
That second one is another metric to pay attention to. If your average user is performing two searches, then it means tons of people are searching two or even three times before finding the article that they actually came for – which means they’re not finding it as quickly as they could be.
Finally, at the bottom of every article is a place for people to rate and review how helpful the article really was to them. All the knowledge base best practices in the world won’t help if you don’t have an idea of how useful your content is to your users.
Normally, people skip over rating helpful articles, which is normal because once their problem is solved, they can just move on to whatever they were doing in the first place. The bad articles, by contrast, are the ones that get the ratings in the first place. Some platforms go a little bit further and give the users an option to write a comment and be a little more verbose about what was wrong with the experience.
This is absolute gold to your customer service team since it tells you directly what you have to improve to make your users happier with the documentation you’ve provided.
When you have a lot of knowledge to manage, it can seem like quite enough of a task to just put it into words in the first place. But your product never stops getting new features and bug fixes. Eventually, some of those are going to break the flow of your knowledge base articles with dead links or outdated screenshots.
That’s fine! It’s supposed to happen, and it means that your documentation team isn’t going to sit around twiddling their thumbs all day.
Your team should aim to be updating your knowledge base articles and performing whole-project audits on a regular basis – once a quarter or three times a year, something like that.
And so aside from the ratings going into the analytics portion of your viewable metrics, you’ll also need to keep track of the age of your articles. Or rather, you would if your platform didn’t do it for you automatically.
At a glance, you can find out the oldest articles in your knowledge base and mark them for review or update. You can even integrate with email or Slack and send out periodic reminders to update certain articles that might be particularly important to keep current.
One quick tip – don’t get hung up on article age. Some things really do never change, and so user engagement and the other usage metrics can end up being way more important than pure article age or time since last edit. Be sure to take everything into account during your audits so you’re not reinventing the wheel.
From the get-go, you have the option to set your knowledge base to public or private mode. A private knowledge base prevents the competition from knowing the inner workings of your software and also prevents any sensitive data from being shared with people who don’t need to see it.
This works well for companies with an internal knowledge base, where you share company policies, forms and procedures with your employees internally – there’s no reason why a customer would need this information, so it stays private.
But the benefits of having a public knowledge base are manifold. As we all know, search engines work on content and interaction. So if you have more content on your website and more users are interacting with that content, your website will be ranked higher than other competing sites.
This means your knowledge base articles will appear in searches even by people who aren’t yet your customers – and that means they’ll drive more traffic to your site. They’ll also be more likely to go to your site over hitting some competitor’s paid answers on Quora. After all, if you have authoritative answers on your site, it means people will want to come to you.
Some platforms allow you to generate an XML sitemap of all your knowledge base articles, which can then be submitted to Google as a way to improve your SEO rankings.
You can also take advantage of the regular old content editor to easily add hyperlinks to other articles as well as to external sources. Adding more hyperlinks (on the order of about 2-3 per 1,000 words) is a good sign for search engine crawlers.
Finally, it’s easy to share your knowledge base articles via social media – after all, they’re simply URLs on your own website. It’s a good idea to share them from time to time on Twitter, LinkedIn, and Facebook as responses to people who have questions about your product.
When you’re working with an external knowledge base, you don’t necessarily need all of your customers to see all of your articles.
Suppose, for instance, that you’ve got a Premium and a Free tier. You want to support both of them without pushing upsells constantly to the Free tier, but the Free tier does have reduced functionality requiring some workarounds that you detail in your articles.
If your Premium users see these, they might get confused and wonder what’s going on with their own functionality.
That kind of discrepancy multiplied by dozens of feature differences makes it a no-brainer to set up restrictions on your articles based on several different criteria. These can include IP ranges, domains, and even arbitrary groupings created by your admins.
And when you’re creating your knowledge base, you can leverage exactly the same settings to make sure that your users are only seeing the information most relevant to them and not anything that could cause confusion or frustration in the company.
Collaboration is pretty much the opposite of access restrictions, but it fits here when describing how teams can interact with knowledge bases as groups of people organized by a common goal. Team members can get assigned certain roles such as “draft writer” and “admin” and then know clearly what their individual responsibilities are.
And as you develop your knowledge base, you’ll want everyone to collaborate on the articles. Remember, a technical writer is going to have different ideas about what’s important to communicate compared with an engineer or a sales lead. They can all access the knowledge base and add comments, and your users in the backend can read these comments and who made them off of a dashboard, ready to file away for later reference.
When you’re writing a novel, you should probably use a word processor. When you’re writing math equations you should probably use Latex.
And when you’re writing a knowledge base you should probably use the knowledge base article editor.
It’s got all the basic word processing features you should expect, like adding links, styling text, and formatting paragraphs around your images.
You can also attach images, videos, code snippets, and even whole files. For example, you can add a screenshot of a particular process or embed a short video of that process being done – and this lets you get your ideas across even faster than they would have before.
Scrolling through big blocks of text isn’t anybody’s idea of a good time, either. That’s why the editor allows you to add callouts and quotes as well, giving your reader an at-a-glance look at the most important points of your article.
And are you a seasoned web content writer? You’re probably used to Markdown, a pseudo-formatting language using brackets and pound signs to mark headers, bold text, italics and more. Many editors allow you to switch between Markdown and WYSIWYG editing modes at the tap of a switch.
Plus, editing can be a bit monotonous as you go through article after article on a similar topic – even more so if you’re updating something after a feature change to your main product. That’s why you should also be able to perform bulk tagging, moving and publishing functions on whole groups of articles at one time.
If you head over to any knowledge base website right now, you’ll see the whole thing done, naturally, in their own color scheme.
That’s all well and good, but what if your product goes with a totally opposite interface color scheme? That would be quite the color clash!
Of course, a standard feature is the ability to customize the look and feel of your knowledge base. Most people end up integrating it into their main sites in a totally invisible way.
This gives your site authority and makes you appear as experts on your product documentation – which of course you are. We’re happy to take off our branding when we integrate with your website!
If you know a little HTML and/or CSS, you can make it look like you built the whole knowledge base from scratch at the same time as the rest of your website. If you’re not as comfortable editing at that level, no worries! You can get help from the support team, follow a tutorial, or complete all the editing in a WYSIWYG editor.
Every feature we’ve discussed so far is present and marvellously implemented in Document360.
That’s why it’s been highly recognized by Capterra and other ranking platforms as one of the most consistently high-quality knowledge base platforms out there.
One little-known thing about Document360 is that it regularly hosts expert content writers, technical writers and product documentation specialists to a podcast called Knowledgebase Ninjas to discuss the importance of documentation to a business and a product’s life cycle.
These podcast episodes are available on the Document360 blog as well as on Spotify. A quick glance through will show you some pretty amazing insights from big names in the industry, all free to anyone who happens to pass by.
The Resources tab on the Document360 menu page is full of stuff like this to help you and your team produce the documentation you can. After all, the best tools in the world can’t do much if the users aren’t trained in the theory behind how to use them.
With great resources like these, your team will be creating better articles faster and more efficiently than ever before.
And one more thing – Document360 comes at a lower price point than many of its other competitors.
Pricing starts at $49 per month for two editor accounts, with just $5 per user per month if you want to add more editors.
As you move up the price range, your allowed user accounts grow rapidly along with additional features such as a private internal knowledge base, review reminders, API access, IP restriction and more.
There’s no commitment required, as you can try out all features with a 14-day free trial, right now. Since everything is cloud-based these days, you can be up and running in moments with your very first articles on Document360 – and you can find out the many benefits for yourself.