An IT knowledge base that keeps runbooks where work happens

Knowledge-base content is typed as FAQ, How-To or Troubleshooting, and the split mirrors how a service desk actually consumes documentation. An FAQ answers the quick question that does not deserve a ticket — password-policy rules, how to request software. A How-To walks a user or a junior agent through a procedure step by step. A Troubleshooting article captures a diagnosis: the symptom, the cause and the fix for a known fault.

Typing matters at retrieval time. An agent mid-incident filters straight to Troubleshooting; a new joiner browsing setup guides filters to How-To. Combined with categories and free-form tags — an article can carry several, such as a product name plus the affected platform — the same document turns up under every search that should find it, instead of living wherever its author happened to file it.

Search itself runs across the title, the body and the category with substring matching, so a fragment remembered from the error dialog is usually enough to land on the right document. On a desk where the median lookup happens under time pressure, "find it from half a phrase" is the difference between a knowledge base that gets used and one that gets bypassed for a colleague on chat.

The cheapest ticket is the one an existing article deflects, and the second cheapest is the one an agent closes from a written fix instead of re-diagnosing. The working loop is short: when a ticket surfaces something new, the resolving technician writes it up — as a draft first if it needs review, since unpublished articles are never served to members — then publishes it into the shared library.

The knowledge base also pairs deliberately with Problem Management. A confirmed known error keeps its workaround and permanent-fix fields in the known-error database; the knowledge base is where the human-readable write-up lives, phrased for whoever hits the symptom next. One is the engineering record, the other the answer at the desk.

Because articles are organisation-scoped, the library can be candid. Internal runbooks can name servers, vendors and escalation contacts, because no other tenant can ever read them.

Documentation rots when nobody measures whether it is used. Every article tracks two counters: opening it increments its view count, and readers can mark it helpful. Between them you get a practical health signal for the whole library — which articles the desk actually leans on, which are read but not trusted, and which nobody opens at all.

That turns knowledge-base maintenance from a vague good intention into a short periodic review: promote and polish the high-view, high-helpful articles, rework the ones with views but few helpful marks (people are finding them and bouncing), and retire the ones with neither. A smaller library the desk trusts beats a large one it has learned to skip.

The counters also give new articles a fair start. A write-up published after a one-off incident earns its place — or does not — on observed use rather than on the author's seniority, and the review that prunes stale content works from the same numbers everyone can see in the article list.