Email Me Daynotes Gang

Help Desk Management Last week, I briefly mentioned my style of help-desk management. Several people have since asked me for more details; so, following up on last week, here's Help Desk Management.

If you ask the average geek who works in the computer industry what the least-favorite part of their job is, chances are they'll say Helpdesk or User Support. If you ask the average office worker what they're least favorite part of working with computers is, they'll most likely answer "Dealing with the Helpdesk." There are of course exceptions; some IT people love providing user support, and some companies (coincidently, the same as those staffed by support-loving IT people <G>) have easy, well-run Helpdesks.

Why do the IT people hate helpdesk duties so much? Most of them spend their spare time tinkering with computers in their off-hours, troubleshooting problems or just having fun tweaking the machine a little more, so why do they dislike doing much the same thing at the office?

The answer is, solving problems for yourself is much easier than solving problems for someone else. The stereotypical "clueless computer user" seems to lurk behind every corner, complaining of broken cupholders and referring to software through obsure interpretations of the icon they use to start it - "that pen thing" (Microsoft Word 6.0), "that key software" (Access) and, my personal favorite, "the little e" - Internet Explorer. (I've often wondered what will happen with this if Linux ever really takes hold of business desktops... how many variations of "the little bird" will we hear?) Systems Administrators are rewarded for fast, efficient service, after all, and it's a little tough to do that when the user in question can't clearly articulate the problem. Users, on the other hand, know exactly what the problem is - they just don't use the same terms or viewpoint as the IT people. IT people see the computer as a whole, made up of the hardware, the operating system, and the applications; the user sees just Word, Excel, Internet Explorer, and Outlook.

(This next bit was covered last week, in somewhat less detail; if you're familiar with normal helpdesk operations, skip a few paragraphs.)

Traditional helpdesk systems don't help this much; the way they generally work is with the trouble ticket system. Tickets are opened by the user through a variety of methods - phoning the helpdesk is the most common, although email and web-based forms are gaining popularity. The best of these traditional methods is the web-based form, as it creates a permanent, traceable record of the ticket; phone calls may be recorded, but that's clumsy, and notes of the call can be easily lost or miss important information. Regardless of the method, the ticket usually consists of the user's name, the date and time, a description of the problem, and some measure of the severity. Often, the ticket also has a "category", which could be as general as "Software", "Hardware", "Network", or "User Question", or it may be as detailed as "Word", "Internet Explorer" and "The Cup Holder" - err, I mean, "CD-ROM Drive".

The ticket next goes to a "first level helpdesk" person, or in smaller companies, directly to the systems administrator. From there, one of several things may happen:

1. The helpdesk technician/administrator reads the ticket, doesn't understand or care about the problem, and closes the ticket as "user error"
2. The helpdesk technician/administrator reads the ticket, decides they don't know the solution, and assigns it to another administrator - who closes it as "user error"
3. The problem is a simple, common problem (e.g., the hard disk has become too fragmented) and needs only a simple fix (e.g., running diskeeper or some other disk defragmentation program), so the administrator closes the ticket and makes a mental note to defragment the hard drive - after lunch.
4. According to the results of a secret lottery, the winning ticket is forwarded to the one administrator who knows what they're doing. They fix the problem promptly, and after communicating with the user to ensure that all is well, close the ticket with a complete description of the resolution and a smiley - :) - before going on to continue their work on world hunger.

OK, those are a little (or a lot) extreme - but those of you reading this from your Sales, Administration, HR, Finance, or Marketing cubical are laughing right now. That's the way it feels, right? Well, here's how it sometimes appears to some administrators:

1. The user installs unauthorized software on their machine, crashing Windows. Opens trouble ticket every 10 minutes until an administrator rebuilds the box.
2. The user moves their machine without telling anyone, plugging the network cable into an inactive jack. Opens trouble ticket claiming Outlook is broken because it can't find the mail server.
3. The user, believing they are an IT expert because they have a Compaq at home, "fixes" their machine and those of everyone in the department. Opens trouble ticket complaining that the network is down and no one can log in.
4. The one intelligent user in the company opens a clear, concise trouble ticket explaining the symptoms, and offering to make themselves available whenever the administrator is free to show them what they're doing to cause the problem - so long as they can fit it in before their press conference on their new cure for cancer.

Again, pretty extreme - but I see some administrators out there nodding vigorously and giggling.

This is roughly how the basic process is supposed to work:

The helpdesk technician reads the ticket, and makes a judgement call on the severity of the ticket. Heor she will do one of the following:

a. Forward the ticket to a more experienced administrator, or the administrator assigned to the problem area

The more senior administrator makes much the same determination:
1. He/she may forward it on to another, more senior administrator if it seems to be a very serious problem

These are the issues like "Server A is running out of disk space, requiring either a restructuring of the disk partitioning on that server or expansion of the drive capacity" and "There is insufficient bandwidth to accomodate current usage". Problems that often result in weeks or months of work often begin as a result of a single user complaint - unfortunately, no one seems to remember to tell the user that, causing them to think the problem was ignored.

2. "Remand" the problem back to the first-level helpdesk
3. Resolve the issue and close the ticket.

b. Resolve the problem himself, if it's a minor problem

This simply requires the administrator to include the date, time, and method of the problem resolution, then close the ticket, which usually automatically notifies the user of the problem resolution and forwards a copy of the administrator's notes on the issue.

c. Close the ticket as user error and either educate the user on the problem

Large companies frequently have separate departments solely for the purpose of training their users on the proper use of computers and software used by the company; this same department is often tasked with "refresher training" in cases where the user has forgotten the training, or where the user never received training on a certain topic.

d. Either close the ticket for lack of information or request more information/clarification from the user.

These are the "my cupholder is broken" problems, where the user is speaking from their perspective, which is incomprehensible to the administrators. This is frustrating for both the administrators and the users; the administrators because they know there's a problem, but nothing about how to go about fixing it, and the user because they feel the administrators just don't care about the problem.

Clearly, the problem is one of communication; the users provide information the helpdesk people feel is inadequate, inaccurate, or confusing, and the users feel the administrators aren't doing anything to solve the problem.

The method I like to use is not drastically different, and it doesn't solve the whole problem. There's a strong notion to simply say "users are users and admins are admins and ne'er the twain shall meet", but when I get in that mode, I start thinking things like "do not meddle in the affairs of sysadmins, for they are quick to anger and lack subtlety." You don't want me to start thinking like that again. <G>

What I do is add another step to the process. When the administrators make a change to the ticket, the ticket is automatically sent to the user; this helps because the user can see that the administrators really did see the ticket, they really did read it, and at the very least, they're thinking about it. The administrators have to actually do things to the ticket, because they know that if they don't, the user will notice the lack of response on the ticket and resubmit it and/or complain to the manager of the administrator.

In addition to that, the only person with the ability to close ticket is the user who opened it. That step makes it impossible for an issue to be closed until and unless the user agrees the problem has been resolved. This is very unpopular with administrators.

They do have a point, too. They point out, correctly, that users do not have the knowledge and experience to judge the problem; it may be too small an issue to deal with, particularly in an overloaded support department. It may be that the user simply doesn't understand the problem and is complaining about proper behavior - in other words, their computer is supposed to exhibit the behavior they're objecting to, and there is simply nothing that can be done directly about the problem. Some users (fortunately a rather small proportion) simply can't manage to be happy with their computers; they may be afraid of them, or just not like them, but whatever the issue, they always have a problem.

The best solution that I've ever found is to make those two changes I just listed, and to keep communications open. The first of the two process changes is now becoming a standard part of many trouble ticket systems; I learned it from a commercial product, PVCS Tracker, which is unfortunately otherwise terrible, and I see that many other commercial trouble-ticket applications are also including similar processes, at least as options. Very few, though, include the second modification.

As for communications... well, that takes a lot of time, and a lot of patience. One excellent way is to hold an open brown-bag lunch meeting with the IT department once a week or twice a month; either a directed format, such as "this week we'll go over some of the things we're planning for next year, and explain what's going on when you send an email" or a wide-open Q&A format. Send an email to the entire organization, publishing the time and the place, and be there ready to go. Eat lunch early, administrators, because you won't have time to eat unless you tag-team the meeting. Make sure you have a whiteboard available. Cover everything at least briefly, but cover the things that really interest the users in detail; you can skim the part about upgrading the backup system as an example of why everyone is extra-busy, but what they really care about is the upgrade to Windows 2000, because it means changes to their computer. Create a trouble-ticket category for "User Questions", which is for general questions rather than problem reports; another, in some ways better solution is to create an internal-only newsgroup or messageboard for the same purpose.

The users will feel happier almost immediately, and happy users are good users, administrators. At first it will seem like a lot of work, but after a few weeks, you'll notice that you have a lot more time; you may have fewer trouble tickets being opened, or you may have more, but overall, the tickets will be easier to understand, clearer, and more concise.

Users, learn what your administrators like in a trouble ticket. Explain to them as clearly as possible what the problem is, including not only what you see as the problem ("my email doesn't work") as well as what you're doing that the problem interferes with (Clicking the desktop icon results in the error message "outlook.exe" is not found. Check the path and filename...") Don't send the trouble ticket and then go get a cup of coffee, try to be available so that you can show the administrator the problem if necessary.

That's about it. Two small changes to the process, and a lot of communication; they'll go a long way to solving the problems you're having with desktop support. Let's all work to make sure dealing with the financial department is everyone's biggest problem next year... <G>