Already live in the product
Running in production today: the IT knowledge base as part of the ITSM suite.
/itsmBuilt around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
What teams can do here
How it works
A worked example
Say a distributed 80-person consultancy burns two desk hours a week on the same VPN-client error. A technician writes it up once as a Troubleshooting article — the steps to clear the cached profile — tags it "vpn" and "onboarding", and publishes it. The next time the error appears, the on-shift agent searches "vpn", the article surfaces, and the fix takes four minutes instead of forty. Over the following month its view count climbs past thirty and agents keep marking it helpful, so it stands as the trusted answer rather than being re-diagnosed from scratch on every shift.
Three article types, because the desk asks three kinds of questions
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.
From resolved ticket to reusable answer
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.
Usage signals keep the library honest
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.
Frequently asked questions
What types of articles can we store?
How do people find the right article?
Do known errors live in the knowledge base?
Can we tell which articles are useful?
Can we draft an article before publishing it?
Is our knowledge base visible to other tenants?
See also: Incident management · Problem management · Blog: What is a helpdesk? · Blog: Open-source ticketing systems · Helpdesk & ticketing
Explore connected offerings
Solve each problem once, then publish the answer
Typed, tagged, organisation-private articles with full-text search and view/helpful counters — a self-pruning library that shows you exactly which docs the desk relies on.