Knowledge Base

When every question went to a person, the problem was that the same questions kept coming back. Sofia, who handles support at Pagedeck, sorted one week of incoming requests — thirty of them — and found that twenty were repeats of four questions: how to invite someone outside the company, how to change a payment method, how to restore a deleted document, and what each permission level is actually allowed to do.

Writing the same answer twenty times is bad on its own, but the structural problem is worse. In that model, twice the users means twice the questions and twice the support headcount. Cost grows in lockstep with customers, so the better the product does, the heavier support gets.

It wasn't good from the customer's side either. Someone who can't find the invite button writes in and then waits hours for a reply. A three-minute answer costs them half a day, and whatever they were trying to do stays stopped the whole time. At night or on a weekend it stretches to the next business day, and the question was never hard in the first place.

A knowledge base moves the answer out of a person and into a document. Written once, it costs the same whether ten people read it or ten thousand, and nobody waits. As long as a human answers the repeating questions, that time gets spent again every single time.

The articles fall into five groups, arranged in the order a customer runs into them.

1. Getting started — the path a new signup takes through their first loop: create a team, invite people, make one document. One article covers the whole lap.
2. Feature guides — the help documents that explain how to use one feature. This is the largest group, and it grows with every release.
3. Troubleshooting — articles people find by symptom, like "my document won't save." This is the entrance for people who don't know the feature's name, so the title uses the symptom verbatim rather than the name of the system that produced it.
4. Policy — pricing, billing, contracts, security questionnaires. Questions that aren't about a feature at all. A good share of what sales used to field moves here.
5. Change history — what changed and when. When someone writes in because a screen looks different, this is the page to point at.

The container around the articles matters as much as the articles. The search box at the top is the real entrance; the category tree is the fallback for people whose search came back empty. Each article ends with a "was this helpful" control, and the articles collecting "no" become the list of what to rewrite.

The shape of a single article is worth fixing too. Titles use the words a customer would type, the body is a numbered procedure, and screenshots go wherever the interface is ambiguous. "Invite someone outside your company" beats "Collaborator permission management" as a title, because only people who already understand the feature would search the second phrase.

Three groups usually write. Support agents turn the questions they keep receiving into articles, the product side writes usage guides timed to each release, and past a certain size someone works on documentation full time. The material isn't invented: a support ticket is one logged request, and reading back through them shows how often each question arrived. The most frequent ones get written first.

There are two audiences, and teams tend to remember only one. Customers read it from outside, and support agents read it from inside. Agents paste article links into replies, and those links end up inside macros — the saved response templates agents use for common answers. So a well-stocked knowledge base speeds up the answers humans still write. More requests finish at the first level, which means fewer get escalated in a tiered support structure.

Search engines bring a third kind of reader. Someone who isn't a customer yet searches for something like "share a document with someone outside my team" and lands on a help article, which makes the knowledge base a first introduction to the product. That's the argument against putting it behind a login.

The harder job is keeping it from going stale. When the interface changes, the screenshots and the steps become wrong together, so updating the related articles belongs on the release checklist alongside the code change. A screenshot of a screen that no longer exists is the part customers notice first.

"Do we have an article on this? I'd rather just send the link."

Answering with a document instead of writing the same reply again.

"Let's publish the help article before this feature goes out."

Shipping without one means every question about it comes to a person.

"Searching for 'invite' returns nothing."

The article exists, but its title doesn't match the words customers use.

Every quarter at Pagedeck, Sofia pulls the top ten question types and hands them to Mia. The ones a document can answer become knowledge base articles; the ones where needing a document is itself strange become candidates for a product fix. When "I can't find the invite button" came in first two quarters running, the team moved the button instead of writing an article.

As the library grew, replies increasingly became a link plus a sentence, and new agents could handle more on their own. Nobody built separate training material — the knowledge base does that job.

It's tempting to treat volume as the goal, because article count is the number you can see. But to a customer, an article that doesn't surface in search is identical to an article that doesn't exist. Titles written in internal product vocabulary are only findable by people who already know that vocabulary, and everyone else writes in without ever learning the page was there. A knowledge base with two hundred articles and no drop in tickets is usually in exactly this state.

The second mistake is treating it as write-once. Documentation looks like an accumulating asset, but part of it turns false the moment the product changes. If a procedure went from five steps to three and the article still lists five, the customer hunts for a button that isn't there and writes in anyway. That ticket takes longer to resolve than if no article had existed at all, because the agent first has to work out which of the wrong steps the customer already performed.