TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Cardimon, Craig asked for advice on: "Organizing a Knowledge Base"
___________________________
I did one job documenting problem resolution information for a Help Desk
serving several telemarketing Call Centers. The first thing we did was to
review the last 6 months' worth of call reports to get an idea of what range
of problems they handled, and what kinds of frequencies and impacts
different problems had on service. Problems ranged from forgotten passwords
to the failure of a long-distance connection to a calling center in another
state. Once we had a list of the different types of things they handled, we
assigned priorities from 1 to 4. A forgotten password was a 1. (It affected
only one user.). The line failure was a 4, because it took out service for
everyone in the remote center.
Next we correlated the information they already had about various problems
with the list. Then I quizzed them about what questions had to be asked to
determine what the problem really was. (Several problems presented similar
symptoms, and users' vague descriptions didn't narrow it down.) We needed
questions to help the customer service staff make a "differential
diagnosis".
The information was organized by problem categories, and each write-up
started with a description of the problem, followed by the list of questions
to define each case. The steps for solving the problem followed the
questions, starting with the closest and simplest actions (such as making
sure everything was plugged in and turned on) through increasing difficult,
complex, or expensive steps (such as having AT&T run a diagnostic on the
long distance line --free if the line was down, costly if it wasn't), until
a satisfactory solution was reached.
I suggest you start by doing an audit of what kinds of service calls they
get and what they already have in the existing knowledge base, and go from
there. HTH, and good luck.
Margaret Cekis, Johns Creek GA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
New! Doc-to-Help 2013 features the industry's first HTML5 editor for authoring.
