Proper knowledge base entry

Below is a list of rules that I found for proper knowledge base entry. A Knowledge base must be made up information that is easily searchable and useful. Below is a list of procedures that all technicians should follow when submitting articles entries to the knowledge base. The steps below will provide consistence and easy of use 

1. Write a Solution using step-by-step instructions. Paragraph formatting is unacceptable for sequential procedures, but is acceptable for explanations. Steps must be numbered with periods after the steps and two spaces before description.
2. Start all solutions with a verb. (i.e., Click OK or Reboot your computer)
3. Use “when/then” statements for steps that include conditions. (e.g. When this happens, then do this) the word if can imply that whatever happened isn’t normal and may cause a lack of confidence if the customer is accessing the knowledgebase self-help.
4. In all solutions with an indicator marking the end of the solution. For instance sequential numbering “END” as a part of the solution indicates the last step of the solution. Example:
   1. Click OK
   2. “END”
5. Capitalize letters to emphasize important warnings. (e.g. DO NOT TURN COMPUTER OFF.)
6. Capitalize the word “note” and follow it with a colon. When making a side comment or drawing the professional’s attention to something important, a side note is appropriate. (NOTE: check caps lock key)
7. Use dashes to list examples. Follow dashes with a space.

Several things can cause this:

-          network cord is unplugged

-          dive mapping has been lost

1. Avoid using uncommon abbreviated words. (e.g. printing should not be abbreviated as PRTG.)
2. Use a period at the end of every sentence.
3. Place a space before and after any keyboard character. (e.g., Printing / Printer not Printing/Printer.)
4. Write solutions in a commanding tone. A solution is a procedure and must be written in a language that leaves no ambiguity. Avoid using words like “please” and “should” on the solution. Effective solutions dictate specific steps that are not optional.
5. Write out problem descriptions as statements, not questions. Questions or additional information can be provided in the problem cause section of the solution.
6. Avoid using “you” or “your”. This is unnecessary text for example: “you then click OK” can be just as easily written as “Click OK”.
7. Use consistent verbs when identifying actions. Use the verb “press” when refereeing to the keyboard keys. Use the verb “click” when referring to the mouse functions. Use the verb “select” when referring to the menu options.

Guidelines for knowledgebase entries:

1. One entry per problem and cause. For each cause of a problem there should only be one knowledgebase entry.  For example, there should not be multiple knowledgebase entries resolving the same problem.  If there are multiple causes to a problem, there should be separate knowledgebase entries for each cause outlining the solution.
2. The Title should accurately summarize the article. This will usually be identical or very similar to the “Topic or Question.”
3. The “Topic or Question” field should be a specific problem. For example, “Having problems in Word” does not outline a specific problem to resolve.  “Word crashes when attempting to print.” would be appropriate.
4. The “Content or Answer” field should list the cause of the problem followed by a logical solution.  The first line should “Problem Cause:” followed by the cause below.  After the problem cause there should an empty line followed by “Solution:” with the solution listed below.

Creating a Knowledgebase

I am currently in the process of creating a knowledgebase for my companies Technology department. I am having a difficult time between my vision of the overall process and the vision of my upper management. I feel that we should be planning the knowledgebase for the entire technology department. I believe they seem to think that we should be doing it for just our small subset of the department. The application I administer is used by the entire department for Incident Management (tier 2 support), Change Management, Service Management (tier 1 support), and Configuration Management (inventory). There is a build in knowledgebase module with in the software. The knowledgebase module is directly linked and encompasses each of the modules list before. I want to convey my vision to my management without getting either side frustrated.

Below are a few issues I have and some explanation to why I think my way is the best. I am very open to criticism if you have valid counter points and encourage open conversation why I might or might not be correct.

First, I think that even if we decide to have the knowledgebase only for our subset of the division, it will eventually be discovered by others in our department. I want to start planning for the department as whole instead of being a year into the project and then having to change the way we do things because our user base has quadrupled.

Second, I want to have everything entered in to the knowledgebase. Even the most trivial of task like setting up a network printer. Currently the application works on a submittal process, tier 1 and tier 2 technicians both have the option on close of a ticket to submit the resolution of that ticket to the Knowledgebase approval queue. Once submitted and knowledgebase administrators would determine if the if the solution is a valid knowledgebase article. I feel that to have a good knowledgebase you should have everything recorded at least once in an article. This would then help new technicians with questions they may have about certain technical procedures or help tier 1 support resolve issues that may not have been able to in the past. I do understand that the drawback to submitting everything as apposed to just issues that are more technical in nature is that it creates more work on staff. I feel that the
RIO (return on investment) would out weigh the initial work that you have to put in to have a proper knowledgebase.

Lastly, I think that to truly have a good knowledgebase you will need to have the buy-in of your upper management and clearly written policies that define the scope of what your knowledgebase should accomplish. I feel that in my department as a whole, the upper management is split on how they envision the future of the department. I guess this is the drawback to having a mid-sized computer department that is in charge of supporting a huge user base.