Introduction
There it is, sitting at the bottom of your projects list, always getting pushed down to a lower and lower priority.
The company wiki.
An internal, regularly-updated and easily-accessible document for all of your company policies and procedures is a true boon to any employee.
People waste tons of time being confused about where to find the right information and asking others how to do simple tasks. It’s not that they’re not thinking critically, it’s that the information nine times out of ten just doesn’t exist.
Having one document to cover this simply solves the problem of information dissemination. The question is, how do you make sure you’re choosing the right format?
The Allure of a Company Wiki
Wikipedia is, at this point, something like a public good. We use it every day practically as an extension of our own brains, and if you have a curious mind, you can get easily drawn into Wikipedia rabbit holes about anything you like.
So when it comes time for you to develop a way to easily update your internal information, a Wiki seems like the obvious solution.
After all, wiki software is open-source and totally free of any hosting charges. It’s also lightweight, and fast on top of that!
Also, everybody already knows how to navigate a wiki. You just search for the page and then follow any links in the page to get to other pages you might be interested in – ideal for a complex procedure that requires a lot of interlocking steps.
Corporate wikis got really popular at the beginning of the 2010s, when cloud storage was taking off and people were realizing the limitations of just having a collection of Word documents for their company policies – that is, assuming that they even had an electronic solution at all. People started crowdsourcing their articles and the explosion in knowledge availability was enjoyed by everyone.
Only later on in the second half of that decade did knowledge bases start coming on to the scene.
And it just so happens that in pretty much every aspect that a wiki shines, a knowledge base shines a little bit brighter.
From The Ground Up
You see, the concept of creating an internal wiki is to provide articles of any length on a wide array of topics. This is great for reading about natural history, science, or famous people, because all of these are general topics that will naturally contain connections to other general topics or more detailed things.
A knowledge base, though, is designed to answer your questions.
Knowledge bases are meant to be like massive question-and-answer databanks, where you can pop in a question and get an answer back faster than calling tech support and with more detail than a live chat.
The classic example is with onboarding a new employee.
On day one, there’s so much to learn that it’s totally overwhelming – they walk through the hallways and see busy people knowing exactly where to find each bit of information they need. It’s estimated to take hundreds of hours for a new hire to gain that kind of ability!
An internal knowledge base speeds that entire process up while simultaneously acting as an inward-facing help center for any employee in the organization who needs to find something out.
It’s not meant to be like a library where you can wander around and browse through anything you like. Knowledge bases are there for the specific situation where an employee isn’t sure about a process and so has to interrupt somebody else to ask – and interruptions can cost a business big time.
There are a lot of different knowledge base companies out there, but they all work the same, more or less. You generally pay a small monthly fee and then get access to an editor and some storage for you to create as many pages as you like, viewable online through a custom URL.
It’s easier than you think to switch over.
Therefore, here are seven different reasons why it’s better to abandon your project of a wiki and go straight to a knowledge base, the best way to solve information problems in your company.
Help customers help themselves instantly with a Knowledge Base!
Book a Demo
Seven Reasons Why An Internal Knowledge Base Beats a Wiki
1. Knowledge bases are much easier to design and edit
Have you ever edited a Wikipedia page? You have to break the flow of text to add tags, and when you want to connect two articles together you have to just hope that nobody changes the other article’s name, lest you end up with a rusty red “dead link.”
To be fair, Wikipedia has actually made good strides in making their Wiki software easy to use for anybody, but opening up the editor is still a bit of a shock since you don’t see the familiar webpage you just clicked on.
With a knowledge base, what you see is what you get. You don’t have to train anybody on how to add or edit pages because the whole thing is extremely intuitive. Anybody can learn to navigate an edit page in seconds flat.
You don’t need to think back to your high school web design class and try to remember how to make tables or callouts in HTML. Those features are already integrated, and they scale any way you like for a laptop, tablet, or phone screen.
Furthermore, you can easily embed videos, audio, and photos – whereas in-line images in a wiki format are no fun for anybody. Depending on the storage that you’ve got selected, you can even embed files directly so that people can easily download the latest PDF or spreadsheet related to whatever it is they’re searching for.
The layout in general is also customizable yet streamlined. All wikis look about the same. Now, there’s definitely a design language for knowledge bases too, but it’s far easier to change the orientation of an individual page and even have differently-designed sections on the same website.
Imagine having color-coded sections for different departments, creating a visual callback that orients your users subconsciously. That’s possible!
2. A knowledge base keeps detailed usage metrics
Any website has access logs, sure. And a wiki is definitely capable of telling you who accessed and edited which pages, complete with timestamps.
But this brings us back again to the design thing. Knowledge bases are designed around capturing and displaying usage metrics. You don’t have to go looking for them: open up the right dashboard and they’re right there in front of you.
It’s easy to pull out information such as which users are accessing articles the most. Obviously, that tells you which users need the most direction or have the hardest time remembering how to complete their tasks. Nothing wrong with that!
There’s a lot more, though. You can also see which of your articles haven’t been looked at in a while, or which ones haven’t been updated in a long time either. Keeping your knowledge base fresh is a whole separate topic – basically, if you don’t have a way to regularly audit and improve your knowledge base articles, you could be the cause of frustration as your users end up finding outdated information on your help center.
Finally, even if you’ve never used it yourself, a knowledge base can invite individual users to rate or comment on the pages’ helpfulness. Often these quick ratings can reveal way more than what a detailed survey would tell you, simply because people are going to be more accurate about their assessments right as they’re using the product (not later on filling out a survey).
Compare that to the process of getting a page evaluated with a wiki – you’d have to dig into a bunch of confusing timestamps to analyze usage through logs, and then try and calculate statistics across all pages that way. If you wanted feedback on how well the articles were answering questions, you’d have to email around a survey and hope people filled it out when they had time!
Furthermore, when you have an idea for an article or you want to mark an article as “needs improvement,” with a wiki you’d have to send out an email or put a big public-facing flag on the page showing it’s under construction. With a knowledge base, though, you can discreetly and internally flag articles with labels and suggestions.
3. A knowledge base is built to deliver quick information
The thing about a wiki article as a format is that it’s best for expanding into a long discussion about a given subject. You know, like an encyclopedia!
However, knowledge base users want speed.
Although you could definitely write tomes of content on each article, it’s just as easy or easier to write quick and to-the-point articles for your staff to read and digest instantaneously. Nobody wants to hunt around inside an article for the particular answer to their question; they want a fast flowchart or list of steps to follow.
Even better, when you open it up to other users to edit, the quick preview of all the existing articles shows them that they should write concisely and effectively.
The hierarchical structure of the knowledge base suits itself to fast information gathering. With a wiki, you have to apply a hierarchy after the fact (like how at the bottom of a Wikipedia page it shows you the category name).
That information is discreetly displayed right at the top of the knowledge base article so that you can quickly navigate around that one particular subject. And at the bottom, you can find an automatically-populated list of related articles!
That’s not even mentioning the fantastic search feature…
4. Knowledge base search is more effective
One of the big advantages of a knowledge base is the so-called real time search. As soon as you start typing, an intelligent algorithm brings up suggestions for the articles that you’re probably interested in reading.
An ordinary Wiki search can only search for article titles – that’s all. That’s why, in all honesty, you’ve probably gone to Google instead of Wikipedia 9 times out of 10 for when you really wanted a Wikipedia article.
Plain wiki search is still unable to handle anything that isn’t the actual thing you want to find in the first place. Again, this is okay (though still not that ideal) for an encyclopedia format, but makes no sense for an internal knowledge base. When you’re searching for a company policy, you shouldn’t have to remember the exact name of the article.
The search algorithm for any knowledge base is more advanced. It searches article titles, article tags, and the full-text of the article itself. It even supports partial fuzzy matching if you misspell a word!
So let’s say you’re writing an article on using the phone system in your office. You title it something that people will want to search for, like “Using the phone system,” then tag using related words like #phone, #call, #telephone, and so on.
Later on, what if you want to reorganize and add a new series of articles, or you switch phone system vendors and need to set the record straight? Instead of having to hunt down each article, just use the search function and call them all up, then edit each as needed.
5. Knowledge bases can stratify your content to different audiences
If you work for a smaller business with only a handful of employees, this might not apply to you. But larger enterprises run into a different problem when creating documents for all the different layers of their organization.
Not everything applies to everyone!
Imagine somebody like a construction company, for instance. They’ve got the workers on the ground, the office staff, and the administration.
Each of those groups of people has their own needs about what kind of information they would want to access from a knowledge base. And each of them probably doesn’t need to know much from the other two worlds. Now imagine that same construction company has one location in Louisville and they decide to open up one more location in Cincinnati.
The relevant information for each group just got more complicated, because now you’re no longer dividing things up by employee status, but also geographical location.
If you had all your policies (such as sick leave, insurance coverage, and important contact information) on a Wiki, you’d end up with a confusing mess of articles called “Overtime Pay (Cincinnati) (Office Operations)” and “Life Insurance (Louisville) (Administration).”
A knowledge base allows you to break up that confusion and clearly delineate which articles can be seen by which employees. Now there’s no reason for anybody to get confused and call up HR asking about a leave policy that doesn’t even apply to them.
Besides, this stratification ends up benefiting the editors of the knowledge base as well!
6. Everybody always has full access to edit the wiki
The whole concept of a wiki is democracy. Sure, there are a couple of spinoffs where you have to be an expert and cite your sources, but on Wikipedia, you can go and write whatever you’d like, and it’s up to the community to check it, improve it, or delete it.
This is something you don’t really want with your internal company documents.
Your shared drive or cloud storage, sure. But we’re talking about things your employees are going to reference such as policies for user data, procedures for adding or removing people to the payroll system, and so on.
In fact, with the model of a knowledge base as a replacement for getting out of your seat and asking an expert, community editing doesn’t make a ton of sense anyway. If you don’t really know what the sick leave policy is, you want to ask an authority, not just have somebody else make something up.
It’s true that you can lock and unlock individual pages on a wiki. That definitely prevents users from messing with data that isn’t theirs.
However, a knowledge base gets much more granular than that. You can set edit or read-only access to apply to different individuals or different groups, and in doing so you can encourage a culture of expertise among the curators of your knowledge base. This can even happen on the IP address level, allowing you to keep track of and restrict usage by individual computers.
Really, people should be encouraged to write and edit articles in their respective areas of expertise. One person alone can’t create a knowledge base that solves problems for everybody in the organization.
One last thing on this point – naturally, all new suggestions and edits can be approved or denied, and it’s easy to roll back to previous versions thanks to robust version control.
7. Wikis have no support
Last but not least, there’s one huge thing that you’re missing out if you opt for setting up a wiki by yourself instead of purchasing a subscription to a knowledge base solution.
What happens if you don’t know how to use it?
When time is money at your workplace, you simply can’t be spending your valuable hours digging through the documentation for how to get a wiki hosted, set up, and maintained consistently.
The difference between setting up software in 2020 and setting it up in 2010 is that you’ve now got ten more years of giants’ shoulders to stand on.
People already did this before, and they’ve made it into an out-of-the-box product that you can simply set up and get running in literal minutes.
A knowledge base like Document360 has a dedicated support line open nearly all hours of the day, a live chat line, a support email, and of course a robust knowledge base of their own. Any problem you run up against, they’ve definitely heard it before.
And on top of that, since you’re subscribing to the service that they offer, they have that much more incentive to keep making the product better and better, continually earning back your business through their new features and fixed bugs.
It’s Long Past Time for an Internal Knowledge Base
One thing to reiterate here as we’re wrapping up is that making a knowledge base with Document360 is easy.
It’s so easy, in fact, that once you write your first article you’ll be amazed at how little time it took. Your job shouldn’t be messing around with strange and archaic editors just to get a simple code block to render correctly on the page. You should be focused on defining an editing workflow and getting users comfortable with the concept of regularly updating your internal knowledge base.
And so the uncomfortable truth here is that you are in fact losing time by continuing to rely on older and less efficient solutions.
Once it’s set up, as mentioned before, you can simply send out a bunch of requests to different members of your team in different departments and ask them to write down some trial posts in their areas of expertise.
After they’ve done that, you just need to develop a general set of style guidelines and make sure the posts all conform to the voice you want your internal knowledge base to take. Approve the posts and your knowledge base is writing itself!
Conclusion
You and the other employees at your company deserve to have the best type of knowledge base available. You’ll find the answers to your questions faster, and you’ll have a better-looking product that clearly speaks with the same design language as the rest of your organization.
Is there really any question at this point about whether you should still be trying to learn to use a wiki?
All you’ve got to do to see how easy it is is book a demo today with Document360, the first name in the knowledge base business.
See for yourself how an internal knowledge base can save you a ton of time and money! Jump out of the past and into the future with Document360.
–