Knowledge Base

Customers ask how to reset an account, while staff ask how to handle an exception. A knowledge base stores answers so people need not ask the same person every time, and search, clear titles and useful steps make it usable.

Common content includes frequently asked questions, troubleshooting steps, policies and process guides, but a list of files in a folder is not automatically a useful knowledge base because readers must be able to find and understand the right answer. Atlassian describes knowledge base articles as how-to guides and FAQs that customers and support staff can reference, and it distinguishes external and internal audiences in its own service-management documentation.

An external knowledge base can answer product questions before a customer opens a support ticket, while an internal base may hold procedures and sensitive details unsuitable for public view. A fictional software company publishes an account-recovery guide that tells customers how to use the approved recovery flow but keeps internal fraud checks in a restricted staff article, because mixing both in one public page could expose controls.

Write articles around real questions, since 'Why did my invoice change?' is easier to find than a vague title such as 'Billing update 14', and use customers' language rather than only internal labels. A useful article states when it applies, gives steps in order and includes a next route when the steps fail, because a page that says 'contact support' without explaining common fixes may not solve the problem.

Put the action and key warning near the top, add detail where needed, and split unrelated problems into separate articles with clear links. Ownership matters, so assign someone to review an article when a policy, product screen or process changes, because a prominent but outdated answer can create more work than no article at all.

ServiceNow's documentation illustrates article ownership and review controls, especially for sensitive or regulated information, though these are features in one platform and not a universal obligation to use that software. A fictional retailer changes its returns window and staff update the customer page, internal exception guide and chatbot source, since if only one is revised, customers may receive conflicting replies.

A knowledge base may connect to a support portal or search engine, where search terms, categories and links from relevant pages help people reach the answer, and search results should not send users to retired instructions. Feedback can reveal gaps, as repeated searches with no useful result or repeated tickets after article views may point to unclear content, though those signals need interpretation and not a claim that every article view avoided a ticket.

Measure outcomes carefully, because article views show demand while feedback, successful task completion and support patterns better indicate usefulness, and a lower ticket count may reflect many things besides the knowledge base. Internal articles can support onboarding, since a new employee can follow a checked process rather than rely solely on a colleague's memory, although complex judgment may require training and a person to ask, and an article should link to a source of truth for policy-sensitive details because duplicate copies of a pricing rule can drift apart.

Access should match the content, since publishing is a disclosure decision and not simply a formatting step, and chatbots can retrieve knowledge base content but do not make inaccurate articles correct, so test answers, provide a route to a human for uncertain cases and review what the bot may expose to each audience. Retirement is part of maintenance, so redirect or archive the guide of a closed feature and point readers to the replacement; a knowledge base is not a substitute for a responsible team, and it works when questions shape the content, access is controlled and owners keep answers current.