Setup a Self-Help Portal

Ever wonder why people are always so frustrated when they call the Helpdesk? Even in an environment where the Helpdesk continually does everything absolutely right and the problem usually addressed immediately at the 1^st level, tensions are typically still rather high on most calls. Even in such an ideal support environment, users still are hesitant to call the Helpdesk. When you ask why there is such hesitation to call, People have courteously created a number of excuses:

• "I didn't want to bother them with my small problem"
• "I didn't have time to work on it"
• "I am too busy"

Niceties aside, the real reason why people don't like to call a Helpdesk/Service Desk is people don't like admitting "they need help". Across many cultures, it is viewed as a sign of weakness and no amount of pleading with your user community is going to remove decades of cultural habituation.
What we really need is a means that users can get help themselves so there is no feeling that they are admitting weakness. This won't replace the need for a traditional support infrastructure, but can dramatically improve relations with the end-user community. What we are talking about is a "Self-Help Portal" or a "Tech Tips Page" and there are a number of specialized systems in the Industry; many of which are packaged as a part of Helpdesk systems themselves. It is also very easy to create your own using tools like WSS. Before we jump right into creating it, we need to discuss a few key points, so that we can design the system to be most effective in your environment.

Page Design/Organization

There are really 2 main approaches I have seen most organizations choose when setting up such a solution: Hierarchical List and Freeform Wiki.
A hierarchical list is a structure where you define a strict hierarchy of all articles with a certain number of levels, for example: Area, Sub-area, article leading to a hierarchy like Collaboration->Email->Email limits. This rigid structure makes keeping all of the articles linked together a simple, straightforward process, but can be rather limiting as some topics you may ideally only need 2 levels, others 4, etc.
In a Freeform Wiki, there is no imposed structure. A final article can happen at point in the structure, very similar to Wikipedia. This freeform structure is ideal for content, but then forces the administrators of the system to provide all of the connecting articles necessary to keep a navigable information tree.
Both structures have advantages and disadvantages. A hierarchical approach is far easier to setup and therefore quicker to deploy than a Wiki-based structure. However, if you can manage the additional overhead of creating and maintaining the pages necessary to tie all of the contents together, a Wiki-based format will likely provide a useful structure for far longer than a strictly hierarchical one.

Author Pool

Take a serious look at your organization and try to allow as many people as possible to author content. If you have individuals from the end-user community that can provide content, count your blessings. If you are in a spot where you think you have such a community, but aren't 100% sure; air on the side of giving them access. If you use SharePoint for the engine, you always have the option of turning on content approval for all the articles. The more people you have providing content for the system, the fewer items any individual has to author and in the long run, the more useful the system will be. This is definitely one of those endeavors where a multitude of viewpoints is a very good thing.

Content is King

Ultimately, the quality of the content you provide, both in terms of topics needed and accuracy of the information, will determine the ultimate success or failure of such a system. To get a good target of where to start, dig through your last few months of support requests looking for your most common requests. Once you identify the common items the support group is being asked to answer, start with creating articles for those items. Where possible, keep the text to a minimum and use either screenshots or video captures to tell your message. SnagIt or Camtasia Studio can prove invaluable for these tasks. Also don't be afraid you use vendor-provided materials such as flash animations, training video, etc. Just try to avoid including the entire product manual as a single article, after all would you to read the entire manual to get an answer to one of your questions? Include a keyword field in your article structure and try to include as many keywords as you think are appropriate for each item. These will come in handy when it comes to article searching.

Search is Key

Regardless of whether you chose to implement a hierarchical or Wiki-based structure for your solution, there will be individuals in the organization that would not think to look for a piece of information where it ultimately got filed. For these people and frankly for the bulk of your user community, having a good search index will be key to finding information. Think about it, Google isn't the #1 most visited site on the planet for nothing.
Assuming that you are using SharePoint as the engine to drive your solution, make sure you setup a separate search scope that includes just your reference materials. Also put a search box for that scope in a very visible place somewhere on the main page to your solution. Also, make your site very easy to navigate to such as a direct link off your Intranet.

Cautiously refer to your solution during Support Responses

Once you have the system up and running, you need to avoid the temptation of simply responding to a user support request with a link to an article describing the solution they need. This is a surefire way to quickly have an unhappy customer. Think about it. How would you feel if you called into a help line for one of your vendors only to have them say that "section 2 of the product manual" has the answer you need?
What you can and should do is answer their question the same way you would if the system wasn't there (other than possibly using the articles to cut and paste key details). Once you have the question answered/problem solved, put a line in at the end of the conversation pointing out that the help system is there even when you are not and may have the answers to their problems. Then and only then can you include a link to the individual article potentially as evidence that the answers are there.