What the best knowledge base software has in common
Every support team owns a question. Not a hundred of them, one, the question that arrives so often the team keeps private jokes about the thing. How do I reset my password. Where has my invoice gone. Why is the export sitting empty. Go and ask around your own team, somebody will name yours inside of five seconds flat, and if you ask them next how many times they have typed that same answer out with their own two hands, well. Watch their face do something complicated.
A knowledge base is the decision to stop the typing. You write the answer once, properly this time, with the screenshots in and the steps numbered and the patience that the eleventh typing never once gets, and you give it a permanent address to live at. From that day on the customer finds it on their own, your team sends it across in one line, and the answer stays the very same answer no matter who is on shift or how their day has been treating them. Which sounds like a small thing and turns out to be the whole thing, really, because the rushed Friday version of the answer and the careful Tuesday version stop existing altogether. One version remains, the good one.
And the best knowledge base software, we say this while selling one, is mostly not about the software at all. It is about how short the distance is between answering a question well and publishing that answer somewhere. Articles do not get written inside some separate documentation project the team remembers once a quarter, they get written in the thirty seconds after somebody answers the real question really nicely and thinks to themselves, hang on, this one is a keeper. Which is the entire reason ours lives inside the helpdesk its self, and not in a separate tool with a separate login that your team will not be opening twice.
Building a knowledge base out of answers you already wrote
Most teams go at a fresh knowledge base like it was a book that needed writing. Somebody schedules a documentation sprint, blocks a week out, draws up a table of contents with forty planned articles sitting inside of it, and the whole affair dies somewhere near article six. Because writing forty articles about imagined questions is miserable work, and nobody can say whether even one of the forty will ever get read by a living soul.
The honest way around is embarrassingly cheap. Open the inbox, look back over last month, and count up which questions arrived more than three times. That list right there, and it usually runs seven or eight items long rather than forty, that is your table of contents, voted for by your actual customers with their actual emails. And the articles are half written already, mind you. Somewhere in those old threads sits the best answer anyone on your team ever gave, the one with the clear steps and the right screenshot attached, and building a knowledge base is mostly the job of finding those answers and putting a roof over their heads.
- How do I get on the guest wifi
- How do I reset my password
- Why does the printer say offline
After that it grows the lazy way, which happens to be the only way that lasts. Somebody answers a new question well, somebody thinks, that took a while and it will surely come back, and the answer becomes an article, and so on it goes, month after month. No sprints, no committee, no documentation manager holding a spreadsheet over anybody. One and all on the team can spot a keeper when they write one, and a knowledge base grown one keeper at a time stays true to what customers genuinely ask, because every last article in it exists on account of a real email that came in one day and could not be answered with a link.
Knowledge base articles people actually read, and the ones they skip
Fair is fair, plenty of knowledge bases get built and then get roundly ignored, the customer glances at the article, does not fancy the look of it, and emails anyway, so you went and paid for the writing and for the ticket both. Nearly always the articles were written wrong, and wrong has a shape to it you can learn to steer around.
Name the article the way the customer asks the question, word for word if you can bear to. Your customer is not out there searching for Configuring Export Parameters, they are asking why is my export empty, and the article wearing the customer's own words on it is the one that gets found and gets trusted. This one hurts a little on the inside, engineers especially want the tidy title, but the tidy title answers nobody at all, and you are not writing for your own selves over here.
Keep one article to one question, however tempting the merging looks. The moment an article answers three related questions it answers none of the three quickly, and a customer made to scroll through somebody else's problem to reach their own gives up early, funnily enough, and lands in your inbox all the same. Better three short articles each earning their keep than one long article that reads like the manual nobody asked for.
And write the steps like you are on the phone with a patient friend. First this, then this, then you should be seeing that. Say what the screen looks like when things go right, so the reader knows they are winning as they go along. Leave the marketing voice out of it altogether, nobody wants hearing that the export feature is powerful and flexible while their own export sits there empty, they want step two and nothing else, and the article that respects that much is the one that goes on quietly closing tickets for years without anybody once thanking it.
Customer self service, and where it honestly stops
The pitch for customer self service nearly writes its self, customers get their answers at midnight, the team stops retyping, the queue thins out, everybody wins all round, or so it gets told. And the pitch is true as far as it travels. We have watched the repeat questions go quiet once the articles went up, and it is a genuinely lovely thing to watch happening to an inbox.
But a knowledge base does not replace your support, and any vendor letting you believe otherwise is selling you a disappointment on a delay, no two ways about it. Some customers will not read an article at any price, they want a person and they will write to one, and that is fine, that is what the inbox is there for. The self service knowledge base earns its keep by soaking up the repeated questions, the reset-my-password tier of things, so the humans get their hours back for the questions that deserve a human. The odd ones, the angry ones, the ones arriving with three screenshots and a deadline attached to them. Deflection is the wrong dream to be sold. Redirection is the honest one, the cheap questions to the articles, the expensive questions to the people.
While we are being honest, the usual disclosures, said quickly since the shared inbox page carries the long version of them. The $0 workspace runs with supporting ads, a little Maxdesk branding on the outbound email, and a rolling 3 month window on your conversation history, where nothing gets deleted, the older mail simply waits behind the $20 or the $99 upgrade. And email is the one channel we ship, no live chat, no phone, no portal, no roadmap hints either, so if your self-service dream ends in a chat bubble on the website, we are the wrong product for you, and you deserve hearing that from us now rather than later on.
Internal knowledge base or external, and which one this is
Two quite different animals go about wearing the knowledge base name, and they are worth a minute of untangling, because an external knowledge base faces your customers, the password resets and the invoice questions, public answers to public questions. An internal knowledge base faces your own team instead, the runbooks and the tribal knowledge, how we do refunds around here, what exactly was promised to that one big account back in March, the things a new hire otherwise spends six months absorbing by interrupting busy people.
Ours is the first kind, plainly said. The Maxdesk knowledge base is there for your customers' questions, and we will not go dressing it up as some all-purpose company wiki, because that is not the job it was built to do. What we would say, though, is that a decent helpdesk already holds far more of your internal knowledge than teams tend to expect. The internal notes sit inside each conversation, right next to the customer's own words, so the reasoning behind every odd decision stays findable years later. And the canned templates are your house answers, written down and agreed on, which covers most of what a support runbook ever really contains. A new hire reading back through the resolved conversations with the notes still attached learns the real how-we-do-things faster than any wiki was ever going to teach them, to be honest with you.
If what you truly need is a heavyweight internal wiki for the whole company, the engineering docs and the HR policies and the lot, then buy one of those, they are a category of their own and pretending otherwise would only waste your money. For the support team's knowledge, the customer-facing half living in articles and the team-facing half living in notes and templates, the helpdesk carries it already.
How to pick knowledge base solutions without a committee
Choosing software for knowledge base work has a way of growing its self a committee. A requirements document appears, then a scoring matrix with the weighted columns, and three months on there are opinions enough for one and all but still not one published article, and the inbox kept right on filling the whole while. The committee, mind you, is mostly a way of putting the work off while looking busy about it. The repeated questions are known already. The answers exist already, sitting in your sent mail. The only genuinely open question is whether anybody is going to publish them.
So run the cheap test instead of the committee, take whichever tool you fancy, ours would be lovely but the test works anywhere at all, and publish your five most repeated questions as articles this very week. Not forty. Five. Then keep two eyes on it for a month. Do customers land on them. Do the repeat emails for those five start thinning out. Does the team start sending links across instead of retyping the same answers. If yes, carry on publishing one keeper at a time and the thing compounds quietly on its own. If nothing moves at all, far better to learn that on five articles than on a documentation sprint and a whole procurement cycle.
And price the test at the team you expect to be next year while you are at it, since knowledge base solutions do love a per-seat price tag, and a seat tax sitting on the very tool that was meant to save typing is a strange bargain to be signing. In Maxdesk the knowledge base rides along on every plan, the $0 workspace included, unlimited agents and the lot, and pointing your support address at it takes about 60 seconds. Five articles, one month, your own repeated questions. The queue will tell you the answer long before any scoring matrix gets around to it.
