A knowledge base is an organised library of help articles on your website, the answers to your customers' usual questions written down properly in the one place, so a person can go and find what they need on their own instead of writing in and waiting on a reply. That is the definition and it will do. But nobody actually meets the idea through a definition, people meet it late on some Tuesday evening, answering the same delivery question for the ninth time in a month and feeling their own patience going thin. That is the version this page tells.
We at Maxdesk watch all of this from a strange seat, we should say so upfront. We build helpdesk software, a knowledge base ships inside of it on every plan including the $0 one, so naturally we would tell you the thing is worth having. But the seat also means we sit looking at support inboxes the whole day long, and a good share of what lands in them, honestly, is the very same handful of questions arriving over and over, on account of nobody ever having written the answers down anywhere a customer could reach them. So this page walks the whole subject through in plain words. What a knowledge base is, what ends up inside one, how it differs from a FAQ page and from knowledge management, what one looks like for different sorts of business, and the part where we tell you what it will never do for you, because somebody should.
What is a knowledge base, in plain words
Picture a small shop that sells handmade furniture. The owner answers email in the evenings, and the email hardly changes from one week to the next. How long does delivery take. Can I return it if the colour looks wrong in my room. Do you ship to Ireland. She has typed the delivery answer so many times her thumbs could do it without her, and one Saturday she finally goes and puts the answers up on the website, each question with its answer sitting under it, a page or two, nothing fancy about any of it. What she built that Saturday is a knowledge base. Nobody handed her a certificate for it, mind you, but that is the entire thing, the questions your customers keep on asking, answered once, properly, somewhere they can find them without having to ask you.
The name is the off-putting part, to be honest with you. Knowledge base sounds like something that comes with a project manager attached, and you will hear the very same furniture called a help center, a support hub, docs, a self-service portal, depending on which tool you happen to be standing inside at the time. Every one of those names means the thing our shop owner built on her Saturday. Articles that answer questions, gathered up where people can browse them, and some way of searching through the pile once the pile has grown.
And the reason the idea gets so much fuss is that it works in both directions at the very same time. The customer with the Ireland question gets her answer at two in the morning, no form to fill, no waiting for shop hours to come back around. And the owner gets her evenings back a piece at a time, because every question the pages answer properly is an email that never gets written at all, and the mail that does still arrive is the real mail, the odd cases, the ones that genuinely needed her. Neither half works alone, mind you. Articles nobody can find help nobody, and an empty inbox was never the aim anyway, the aim was an inbox with only the true questions left inside of it.
What goes inside a knowledge base, article by article
Watch any team write their first ten articles and roughly the same mixture falls out, without anyone planning it that way. A few how-to pieces come first, the step by step kind, change your password, set up your account, connect this thing to that one. Then a couple of pieces that start from something going wrong instead of from a task, the payment failed, the email never arrived, it will not sync. Somewhere in the middle a getting-started guide turns up for the brand new customer, the first day walked through in order. And the rest of it comes out as policy, delivery times, refunds, billing dates, the answers that never change and still get asked for every single day. Some teams tuck a small FAQ section in there as well, for the one-line answers that never earned a whole page of their own, and there is nothing wrong with that at all.
The habit that decides whether any of it gets read is a small one. One article, one question. A customer arrives carrying exactly one problem, why was I charged twice, and if the article makes them wade through two other subjects on the way to their own, they stop reading and they write in, and now the article has gone and cost you time instead of saving it. So keep each piece short and pointed, and let the collection do the covering between them.
What stays out matters just as much. A person opening a help article has already bought from you, they came in carrying a problem, and an article that pauses to sell them something on the way through reads terribly, so the marketing stays out. Roadmap promises stay out too, an article should describe what the product does today and then stop. And the articles nobody asked for, the ones written because the team was proud of some feature, those quietly cost you as well, since every extra page is one more thing standing between a searching customer and the page they actually came for.
Knowledge base vs FAQ page vs knowledge management, untangled
The FAQ page is the small cousin here, and for plenty of businesses it is honestly enough. One page, a dozen or two short answers on it, a link sitting down in the footer. Our furniture owner is at this stage, and she should stay at it for a good long while yet. The move happens on the day an answer stops fitting, when explaining something properly starts wanting numbered steps and a screenshot or three, or when the page has grown so long that visitors take to hunting through it with the browser search. At that point each answer wants a page of its own, with proper search sitting over the top of the lot, and the FAQ page has quietly grown its self up into a knowledge base without anyone announcing it.
Knowledge management comes at you from the opposite end, from the conference stage. It means the whole practice of how a company holds onto what its people know, so the knowing does not walk out the door with every resignation, and consultants write long books about it, frameworks and all. A knowledge base is one shelf inside that much bigger cupboard, the customer-facing shelf. If what you typed into the search box was what is a knowledge base, odds run good that you wanted the shelf, and this page has stayed on the shelf on purpose.
One more name while we are at the untangling. A help center is the very same thing as a customer-facing knowledge base, different vendors settled on different words years back and both words survived, no two ways about it. So when one tool you are weighing offers a help center and the other offers a knowledge base, you are not comparing two features, you are reading two labels stuck on the one feature.
What is an internal knowledge base, and which kind do you mean
Somewhere inside your own team the very same story is running, only facing inward. The newest hire asks how refunds get processed, a colleague explains it over lunch, and the explanation lives nowhere except inside that colleague's head, so next quarter the next new hire asks the very same thing all over again. An internal knowledge base is the writing down of those answers, the onboarding steps, how the refund actually goes, who to ring when the courier loses a box, and it sits behind a login where no customer will ever see it. Same shape as everything above, one question one article. Only the reader has changed.
So which kind do you mean, then. If a search brought you here, most likely the customer-facing kind, that is the one attached to support teams and helpdesk software and the one this guide keeps describing. But it is worth knowing the two kinds exist, because funnily enough they get built for the identical reason. Somebody, somewhere, got tired of repeating an answer that should have been written down a long while ago, and finally went and wrote it.
How do you build a knowledge base without making a project of it
Whatever else you do, do not start from a blank page and a brainstorm. Teams that sit down to imagine every question a customer might ever ask come out the other side with sixty articles, a stalled project, and a guilty document going by the name of knowledge base plan v3, and most of the sixty answer questions no customer has once asked in real life. Your support inbox already made the real list for you. Go and open the sent folder, look back over the last month or two, count which answers your team typed out most often, and take ten. That is the whole first table of contents, chosen by paying customers instead of by a meeting, and ten articles is a weekend of writing, mind you, not a quarter of anyone's year.
On the writing its self we will keep short, since the habit matters more than the craft over here. The reply your best person already sends is the article, near enough, the same words in the same order, that reply has been field-tested a hundred times before today. And the title should be the question the way the customer says it, how do I get a refund, not Refund Policy Overview, because the customer searches with their own words and never with yours.
The part everyone skips is the keeping. An article showing last year's screenshots is worse than no article at all, the customer follows it, the steps come apart under their fingers, and they land in your inbox twice as cross as they started, since your own website went and wasted their evening first. So the base needs an owner, one actual name. The tidiest habit we know ties the updating to change its self, the week a feature ships different is the very same week its article gets reread. And past that, the inbox keeps feeding you. When some new question turns up for the third time inside a fortnight, that question has volunteered its self as the next article, and the base grows one page at a time, sideways, the way the furniture owner's did.
Knowledge base examples, four shapes worth copying
Asking to see knowledge base examples is fair. Everyone wants a look at one before building one. The part worth copying is the shape of the thing though, so here are the four shapes we keep on seeing, described plainly, and you can hold your own business up against whichever sits nearest.
An online shop ends up with short articles and a lot of policy. Where is my order, what does delivery cost, how do returns work, is there a bigger size of this. Three or four sentences answer most of them, the order-tracking article does the heaviest lifting all year round, and come January the returns page gets read more than everything else in there put together.
A software product goes the deep way instead. A getting-started section that takes the first hour gently, how-to pieces for each feature, and then a troubleshooting wing that starts from the exact error messages, in the product's own wording, so a person staring at an error can search for the very text sitting in front of them. Screenshots turn up on every second step in this shape, and the one-question-one-article habit matters here most of all, because the questions run technical and a wandering article loses a technical reader fast.
A services business, an agency, an accountant, a clinic, needs less than it thinks it does. Ten or fifteen articles about the process rather than any product. What happens once I sign, what will you need from me, when do we speak, how does the billing go. New clients do most of their writing-in during the first fortnight, and this little base exists to make that fortnight a quieter one, that is honestly the whole of its job.
And the internal shape, the team-facing one, hardly looks like a website at all. How we do refunds, what to say when a customer asks for the manager, how the holiday calendar works, who owns which system. Nobody outside will ever see this one, and you can tell whether it is working by watching the newest hire. If week one has them asking around for half of what the previous hire needed, the pages are doing their work.
What a knowledge base will not do, said before you build one
The limits usually introduce themselves around month three, so let us do the introductions now instead. A customer writes in about a charge that should not be on their invoice. No article can take that one. It needs a person, with access to the account and some judgement to go along with it, and it always will, the strange questions and the angry ones and the account-specific ones all stay human work. What the base takes off your people is the repeats, and it takes them wholesale, which is exactly what frees somebody up to sit properly with the invoice question instead of racing through it between twenty smaller ones.
It will not stay true on its own either. The product moves, the prices move, and the pages sit there calmly describing the world of eight months ago unless somebody owns the keeping of them, we said it above and we are saying it again on purpose, going stale is the commonest death these things die. And no tool goes and writes the thing for you, ours included. The tools store, organise, search. The answers still have to come out of your own team's heads, which is fair enough, when you think about whose heads the customers were trying to reach in the first place.
Do you need knowledge base software for the whole of it
You can begin with no software at all, fair is fair, and our furniture owner did exactly that. A handful of plain pages, linked from the footer, the answers written properly on them, that already counts and it already works. Dedicated knowledge base software starts mattering a little later. The articles outgrow what a footer menu can hold, the pile starts wanting real search on top of it. And mostly it matters once you want the articles living right next to the support inbox, so an agent answering an email can send the right article across in one line instead of typing the answer out fresh again, and so the questions still arriving can show you which article wants writing next. That closeness between the inbox and the articles, plainly said, is the part worth paying attention to when you go comparing tools.
Ours comes included, and we would rather say so plainly than pretend this page had no interest in the matter. Every Maxdesk plan carries a knowledge base inside the helpdesk, the $0 plan along with the rest. Customers go and find articles on their own, agents send them straight out of the queue, and since no plan of ours charges per agent, the whole team writes and sends without the bill moving an inch. The free workspace does show supporting ads, and outbound email carries a small Maxdesk name on it, better you hear that over here than discover it later. Starting takes about 60 seconds. And if the definition was all you came for today, take it and go with our blessing. Write your ten answers down somewhere your customers can actually find them, and you have a knowledge base, whichever tool it ends up living inside.