Start reviewing the existing/closed ticket/cases to figure out the recurring issues where user can resolve the issue by himself. It will help to prepare the document/knowledge base. If your organization is large enough to warrant it, the management of the knowledge base should be in the hands of a dedicated person. This has many benefits, including allowing time to process new articles and properly retire old articles that are no longer relevant.1. When you learn something new, write it down. Note where you found it, how you fixed it, what the symptoms and error messages were, why it happened, how it can be avoided, and any other useful information. Marshal all your thoughts before writing the article. Ensure that you cover all the steps involved in the fix. Verify that this is the actual fix, not just a coincidence.2. Write articles by running through the process involved, taking screenshots to illustrate the description. Make sure that the article is clear and not too long and that the illustrations are relevant. It might be important to acknowledge the source of both the problem and the fix, in case further research becomes necessary at a later date. Create a template for writing articles, so that all the relevant information is captured and listed in a format that is consistent and easy to follow.3. Make the database searchable. Ensure that the description field contains key information like the error message, the application it occurs in, and any useful extras you came across.4. Check the articles for errors before posting. Sometimes, it's hard to spot your own mistakes. A fresh pair of eyes will notice things you missed. When posted, the article should bear the name of the writer and the date it was posted.5. Check that the article doesn't already exist in a different form. A knowledge base can get overstuffed with duplicates if you aren't careful. If a piece is nearly identical to an existing one, don't discard it. Incorporate any new information into it and credit the writer with an edit.6. If you find an error, note it and get it corrected. Have a quality checking procedure in place. Anyone should be able to submit an article, but it should then go to another person for review, editing, and testing before posting to the live knowledge base.7. Review your articles regularly. Check that the fault has not been rectified by a manufacturer's patch or update and that it hasn't been made irrelevant by progress. For example, you may wish to spring clean all your Windows3.11 and95 articles.8. Make sure that everything is spelled correctly. If you search for, say, system.ini, you won't find articles that contain systm.ini. Emphasize the importance of consistency and the dangers of relying on spell checkers. If you have a full time editor/manager for the knowledge base, that person can ensure that a consistent approach to articles is followed.9. When you post a new article, make sure that the rest of the team knows about it. You could have a page that lists new articles or even an e-mail notification system. Having the knowledge base accessible from your intranet could be useful if you want to make the information available to all the IT crew, even if they're at the user's desk side.10. You might consider making PDF versions of articles covering common issues and e-mailing them to end users. But it's important that any fixes you hand out this way have been thoroughly tested, don't compromise system security, and will be helpful to people. To achieve this, you'll need to have a strict editorial process in place to ensure that there are no faults or potential conflicts in using the material.
