In a perfect world, a hypothetical technical support call would proceed as follows: At 3:55
p.m. on a Friday afternoon, Tom from the accounts receivable department calls your help desk with a problem. Every time he tries to go into his batch, the system tells him it is in use and he can’t retrieve it. He is the only one who has been working in it, so there should be no problem.
Your technical support staff logs into the help desk system and starts a keyword search. The query returns several results, and on line four, your support staffer sees the entry “Can’t Call Up.”
When he opens this entry, your staff member sees five known reasons why this has happened in the past. Tom is asked a few simple questions, a resolution is made, and Tom is back in business. The problem was quickly solved and your department’s genius reputation is preserved.
A call log entry including the date, time, caller, issue, and solution is made to document the trouble call. Once a week, the call sheets are reviewed with staff to note any odd situations.
In the real world, however, the technical support call often proceeds as follows: At 3:55 p.m. on a Friday afternoon, Tom knows he has a problem accessing his accounts payable batch. Instead of calling IT, he tries and tries to access the batch, to no avail. He goes looking for Elliot in accounts receivable who might know what to do. Elliot is unable to assist.
At 4:25, Tom finally calls IT. Rob, who is working the help desk, is happy to help. The only problem is that, although Rob knows the sales order system quite well, he doesn’t know the financials. Of course, Debbie, who does know the financials, took the day off.
Rob looks into the situation for several minutes but cannot find an exact reason as to why the batch might not be accessible. Finally, now that it is 4:50, Rob calls Debbie on her cell phone and asks for help.
Mindful that Roger, the accounts payable supervisor, is now red-faced and wants the checks printed immediately, Debbie talks Rob through several scenarios. The fourth scenario proves to be the culprit. Rob changes the batch status and Tom continues on.
It is now 5:15. Tom gets the batch posted, prints the checks, the accounts payable supervisor signs them, and they get mailed out. Everything is right in the world again. Come Monday, during the managers’ meeting, Roger recounts the hearsay nightmare of getting a simple batch of checks printed.
In this article, I will give you an overview of how to mine the knowledge base of your staff so that such problems can be solved quickly and efficiently.
Emulate the Borg
In the Star Trek television series, a Federation enemy known as the Borg provides an ideal model for the perfect knowledge base. The Borg’s fearsome power comes from their ability to recall from their collective consciousness all data and assimilated memories of every other Borg. This assimilated information can be recalled almost instantaneously by any individual Borg to provide insight, if not outright answers, to nearly every situation. Ideally, your knowledge base should give your staff a Borg-like power. But to do so, you’ll have to assimilate the collective knowledge of your staff.
Begin the Assimilation
Identifying and collecting the necessary knowledge will require the participation of your entire department. Make sure members of your staff understand that the knowledge base will be beneficial to them. One of the benefits of implementing the knowledge-base approach will be that users will have a defined hierarchy for submitting support requests. This structure and order will permit the IT staff to be more productive.
You can begin the process of harvesting information for your help desk knowledge base by writing scripts to formalize the process of handling routine problems. Formalizing the interactions will help you identify problems, their facts and symptoms, and possible resolutions. When building scripts, presume that your hypothetical knowledge base system will capture whatever information is required. Here is an example script:
IT Help Desk: Help desk. May I help you?
User: This is Mike. My report won’t print.
IT (Tim): Is this a new call?
User (Mike): Yes.
IT (Tim): What is your user ID?
User (Mike): ARMIKEY.
Tim keys in ARMIKEY and presses Enter to get into the issue screen. As the screen opens, Tim keys in “report won’t print” under issue title.
IT (Tim): I’m going to look at the job queue to see if there is anything for you to print.
(Tim uses the Work with User Job [WRKUSRJOB] ARMIKEY command to look for jobs still listed on the system. He sees one job for ARMIKEY that is still in the job queue.)
IT (Tim): Mike, I’ve found the problem. You submitted the job about 20 minutes ago. There are several jobs in the accounts receivable job queue waiting to run. As soon as they finish, yours will run. You are number three out of five jobs waiting. Is there anything else I can do?
User (Mike): Could you bump mine up so it runs faster?
IT (Tim): Without a call from the accounts receivable manager or my boss, I can’t.
User (Mike): OK, that is all I needed. Thanks.
Tim logs the trouble call and resolution by entering the date and time the issue was resolved and writes a brief synopsis of the issue and resolution. Tim also enters keywords and categorization to assist later searches. The system assigns a call number to this issue.
Knowledge Management Products
With the basic scripting process down, you will need to decide what information will be stored when the user calls. You also need to determine how the information can be accessed and who will have access. You’ll have to decide whether to develop your own system from scratch, implement a dedicated help desk system, or adapt a generic knowledge management tool to the task.
There are many dedicated help desk and general knowledge capture/management tools—that I will not discuss individually here—that can assist in monitoring calls and tracking resolutions.
Off-the-shelf software, no matter how brilliantly designed, may not do everything you need it to. Also, you may find yourself on the software company’s tech support line if things do not work as you expect. The distinct advantage, however, is that you can be up and running with this software just a few hours after receiving it.
In-house designed and developed software may be the answer. Not only will it be designed and written to fit your company, it is more easily maintained, as your staff will engineer it. Another advantage is that you can create custom reports for distribution. While off-the-shelf applications generally have several report formats, there are instances in which they provide too much information, causing important issues to be overlooked by the very managers who request them in the first place.
A disadvantage of in-house designed and developed software is that you have to make time to design, code, test, and implement the software. In-house-developed software does not mean there will not be any issues with the application. What it does mean is that you will be able to maintain and support it yourself.
Knowledge Capture Tips
It is a good idea to store user name and ID, department, date, time, topic, issue, priority, resolved by, resolution date, resolution time, and, of course, resolution data for each call. Capturing this information as separate data elements will allow you to create searches, queries, and reports over these key elements. This structure also allows you to develop reports over the knowledge base to track recurring issues, times of the month/year that issues occur or recur, and which user(s) have the same issue(s) over and over. By retaining the user information, you can analyze the issues that occur and recur and provide or suggest training for the user community. This reporting can be used to justify your training budget for the coming year.
Process Changes
Efficiently implementing a technical support knowledge base may require procedural changes. The following suggestions will help you maximize the benefits of a knowledge base approach.
First, assign a phone for all technical support calls to come to. Make sure that all users have been notified to call that number.
Next, schedule resources in your department to monitor the technical support line. If you hire or delegate one person to cover the phone at all times, pick one or two people in
the department who will be on call for one week at a time. Let them decide which one of the two will take the morning shift and which one will take the afternoon shift.
Ensure that all staff members handle problems and data collection in the same fashion, so the knowledge base will be uniformly collected. There are numerous ways to handle the initial trouble call to ensure that knowledge is used and collected. One approach is to have the help desk worker attempt to solve the issue just by using the knowledge base tools. Help desk staff may be able to solve more simple issues, such as printers that won’t print and user profiles that are disabled, until the help desk database is populated with more complex issues.
A second approach is to have the help desk worker enter all of the issue information and then pass the problem directly to a developer or other technical staff member. This approach has the advantage of using staff that may have more knowledge of the system to resolve the issue quickly. The disadvantage is that the technical staff person may already be busy and fail to see the call in the queue, which may delay its resolution.
A third approach is to place all the calls in the queue as they come in. In this manner, the entire support team has the ability to review the queue, check out an issue, and resolve it. If they cannot resolve it, the issue needs to be placed back in the queue. All persons involved with the problem will need to update the knowledge base with their input.
It is important not to prematurely close an open problem. If the solutions have not been tested and signed off by the requestor, it is unresolved, and the knowledge base will contain incomplete or inaccurate information. While you must not let problems flounder on the queue, as professionals, you need to ensure issues are resolved prior to marking them as such and prior to documenting any resolutions in the knowledge base.
Reaping the Benefits
One of the many advantages of implementing a knowledge base is the ability to run queries and reports. Analysis of the reports can help your company address “hidden” problems and make informed decisions. One good use of reports is during managers’ meetings.
Providing attendees with copies of relevant reports can help other mangers identify problems in their own department, including which department is hogging all of the IT support time. Managers may also identify training issues, including the one user who continues having the same problems.
The knowledge base may initially be looked at as a method of tracking IT resources. If utilized properly, it is a tool to improve the company’s effectiveness and efficiency, as it may foster faster problem resolution. And, as we all know, time is money.
LATEST COMMENTS
MC Press Online