An Example KB Quality System

This is the final post in the series about Knowledge Base content and design, and follows on from my earlier post on the subject. The earlier post expanded the quality system, this post will give an example for WidgetCo. Hopefully this will help bring all of the previous posts together!

WidgetCo Knowledge Base Quality System

Editor’s Brief

Editor: George Ritchie
Catalog Name: Desktop KB
Catalog Accepted Formats: HTML, PDF
Audience: Service Desk Staff, 2nd Line Support Technicians
Catalog Description: Contains both Incident Resolution and How-To documents for Desktop-based computers running XP and Vista.
Examples of subjects that can be covered:
Subjects covered might include resolution of common display driver problems
Troubleshoot VPN connection problems
How-To roll out a laptop from one of our ghosted images
Resetting a user password
 

Routine tasks for the Editor

Weekly: Check for new Document suggestions. These will either be emailed suggestions to you, or Incident resolved in the last week and flagged with ‘KB suggestion’. From these, produce a list of candidate new documents. Describe the document with either an Incident reference number, or a paragraph describing the subject.

Weekly: Check for document feedback through our feedback mechanisms. Make sure each respondent receives an acknowledgement where contact details are provided.

Monthly: Review the topics (search terms) that have been submitted to the Knowledge Base Engine. Look for topics that are not covered (or adequately covered) and use this to produce a list of candidate new documents.

Monthly: Send an email to all potential users giving a title and link to each new document created.

Yearly: Each document should have a ‘Review Tag’ at the bottom – for example, REVIEW2007. This is the point at which the document is to be reviewed. As reviews are performed just once a year, this kind of tag will work fine. Simply use the Knowledge Base search facility to locate documents tagged REVIEW2007, review the content, and then update the tag to say REVIEW2008 – and so on. Reviews should check documents for accuracy and relevance.

Procedures for adding a new Document

Prior to creating the document:
Check that the document is not already included in the Catalog, or any other possible Catalog. Have the document peer-reviewed by a member of the 3rd line support team if required.
Ensure that the document is accurate and on topic.
 

Reporting and KPIs

A monthly report should be submitted to the Service Delivery Manager detailing:
The number of documents created that month
Number of queries performed in total by consumers that month
Summary of user feedback
Any other issues affecting search relevance
 

Categories: