Written 2004–2008 by Wayne Pollock, Tampa Florida USA. All Rights Reserved.
All organizations have a help desk, whether or not they officially acknowledge it. The help desk is often a virtual place (and defaults to the SA's office or cell phone number) where people expect to receive answers to computer related questions, to report problems, and to request changes in service or tutoring for services. The help desk is often the first contact for new employees, and must be able to answer policy and procedure questions for users in addition to technical information.
The help desk also provides reports to management, who can use the data to track how well various services are working out, what new services might be requested, feedback for policy and procedures, and workload information (to adjust staffing levels and/or SA salaries).
Security is important for a help desk, so confidential information isn't given out without proper authorization and authentication. If not careful, social engineering can be employed to have accounts created or passwords changed. (E.g., the scenario in which imposter gains the trust of some SA, than asks for password or other access.)
Escalation is the process of having an issue moved from the current personnel to another with more experience, and eventually to management.
A common solution in large organizations is to have two (or more) levels or tiers of support. But this can be quite annoying unless handled carefully! Having the lowest level handle routine requests (password resets, software updates, etc.) allows other SAs to specialize in more complex parts of your system: network infrastructure, routing issues, security, email, database, printing, etc. It also allows a cost effective way to expand the help desk support hours (up to 24X7). This first level should be able to handle 80 to 90 percent of all support requests.
Automatic escalation is a very good idea. When a support call has lasted (say) 5 to 15 minutes, the issue gets automatically escalated up to level two support. (E.g., One local Tampa company requires escalation after 9.2 minutes.) To escalate you should say something such as “I don't think I'm helping you fast enough; let me get a more experienced SA to help you, please hold.”
Issues left unresolved for a working day should get escalated up to level two. If not resolved after another day (“resolved” doesn't mean completed), management is informed.
Another form of automatic escalation is when a user is put on hold too long. The call should then be routed to a level two technician. If none are available (say it is after hours), a message should provide email and web alternatives plus voicemail.
The perception of the users/customers is important. (Often SA raises depends on what management hears about them from users.) Always have a friendly and cheerful (but professional) attitude. If possible, have a single point of contact for each user. (This helps enormously in a large organization with several SAs staffing a help desk at once. When the user calls back to add more information it is convenient not to have to explain that “Wayne is already handling this issue, please forward this call”.) Lacking a single point of contact, make sure all help desk staff provide consistent responses.
Have a set routine (called “scripts”) for dealing with support issues and requests, which should include a professional demeanor. Have some training (including “dry-runs”) and mentoring (observing more experienced staff) for new staff. Although running the help desk may be a tiny part of your job, the users will have no idea of your real activities and will assume the help desk is all you do.
Attitude is very important. You can get very unhappy at this job if you have the wrong attitude! Remember that one reason you were hired is to handle certain problems that your users don't want to be bothered to handle themselves, and to answer questions that they don't want to bother remember the answers for.
It is silly to get mad at how “dumb” your users are, or how often they ask the same question, or how they obviously didn't read the manual, or when they ask why you can't just bypass the official policy/procedure “just this once”.
Depending on the local corporate culture, tutoring/training the users may or may not help. But if it might, hold training seminars and offer tutoring services.
At a minimum there should be a (protected) web site with policies, procedures, contact information (phone numbers, IM links, trouble-ticketing system links, and hours that the help desk is staffed), forms, and FAQs (Frequently Asked Questions) that employees can access. (FAQs should be compiled based on experiences at the help desk.) New user documentation can be there too. An unprotected web page should be available for customers to use from the Internet (with a link to the protected page that requires a login). Make sure the main web page (and selected other pages, perhaps in a navbar) have a link to the help desk web site.
Having some instant messaging to the SA on help desk duty is a nice extra. (You can add an icon to web pages if you use Yahoo IM.)
A phone number that can be forwarded to the (cell) phone of the SA on duty is great, provided it includes voice-mail. This is especially useful when the network/web server is down!
Finally, your users should have a clear idea of what support is provided by your help desk. Make sure your staff know the scope (range of services) of the help they are to provide, and refer users elsewhere (say to management) when the request is outside this scope. (This might be called the help desk policy.) Users need to know how long during normal hours and outside of normal hours both routine and non-routine requests might take.
(Adapted from Limoncilli & Hogan, chapter 16)
The greeting should identify you and calm the caller (if necessary). You need to determine what kind of service is being requested and how urgent the request is before proceeding.
If the greeting is a pre-recorded phone message, it should include an accurate current status (“all systems up”, “web server is down”, etc.) and options (“please hold and your call will be answered in the order received”, “press 1 to leave a voice mail message”, ...). Avoid annoying phrases such as I am not available now, or putting jokes in your message. The whole phone message should be very short, 15 seconds or less.
call_handling.pdf found at
The following are recommendations to enhance the perception of a help desk:
It is okay not to know the answer (or even the exact problem). It is not okay to pretend you do know and make a guess.
If this is a performance problem, check logs and run monitoring tools to see what the problem is. Normally a good SA monitors performance routinely and knows well in advance of projected RAM or other resource shortages. Poor performance may not be a resource shortage but a misconfiguration or some other serious problem.
If the problem goes away by itself, log it anyway; a trend may be spotted over time of such intermittent problems.
In the case of poor performance due to a shortage of resources such as RAM or network bandwidth, tuning the systems or re-configuring the application(s) is one possible solution. Increasing the resource (i.e. installing more RAM) is another. The last resort solution for poor performance (that nobody likes) is to lower your level of service — if your customer's needs have outgrown what your organization can provide, there is nothing you can do about it. (Growing the organization is a decision for management and not a SA.)
See what resources are available for testing your solutions, including similar servers you can take off-line and the ability to generate a (simulated) heavy load. Ideally you will have an isolated lab setup with appropriate test hosts and tools, but that might be beyond the budget of most organizations. Then you can try several solutions and see which one might be best in your situation.
Technically, try to pick the solution that requires the least work to setup and maintain, and that will scale up well when your needs increase in the future. Using open standards means more choices for interoperability. Using open software means no licensing fees.
Figuring out exactly how to deploy and configure a new DNS slave server might take some time even for a DNS expert. The proposed solution and implementation schedule should be added to the trouble ticket.
A customer should not have to call the help desk to find out the status of an open trouble ticket. Status updates should be provided when service times exceed the service level agreement (SLA).
Once the issue is resolved, be certain that the customer is satisfied with the resolution.
Staffing levels vary widely! In an academic environment the typical ratio of users to SAs is about 50:1 (at HCC it is closer to 300:1, which causes all sorts of problems). Sometimes in a large organization (say amazon.com) you might have millions to one ratio. Metrics used to calculate staffing levels include: volume of calls to SAs ratio, time to call completion (TCC), and time to problem resolution (TPR).
In a small organization the SAs should take turns staffing the help desk. If someone contacts the off-duty SA directly, have the SA say “I'm in the middle of another issue now, so I can't handle your problem until later. Let me forward your call to name of on-duty SA who I think can help you right away.”
Even if you are the only SA, you should set up a schedule with management approval. Your schedule should include some quiet time when you won't respond to help requests that take longer than one minute to complete. (Except for emergencies of course.) If you don't do this you'll constantly be interrupted and you'll never get your work done. You may find that most help requests come in the morning, so set aside the afternoons for your quiet time and do work in the mornings that you can afford to be interrupted while doing. (Or vice-versa.)
The alternative to decent software is post-it® notes. That doesn't work. One possibility is a PDA but this won't work except in the smallest organizations. For one thing management has no chance to manage the process. Good software can provide “scripts” and search/index facilities to aid less experienced SAs. Logs and reports are other useful features.
The most common type of software is known as a trouble-ticketing system (or service ticketing system) and allows one to enter in support request details, assign SAs, assign priorities, and automatically log details such as user, SA who handled the call, the date and time of the call. Ideally such a system can be tied into the phone system, so these details can be logged automatically rather than having the SA type them in. This can also provide call routing (press one to reset password, press two for an on-going issue, ...) and call escalation.
A really good system has web interfaces where users can request support (IM, email links, FAQs, ...), open a trouble ticket (without using a phone call or IM, that is non-face-to-face support), and track previously opened trouble tickets. The ability to open a ticket is especially useful for users to request new services, or for developers to request enhancements (RFEs) or to report bugs. (See www.bugzilla.org and bugzilla.redhat.com.)
The software should allow SAs to log into the system and see what issues have been assigned to them, and/or to view issues in priority order. It should allow management to obtain useful reports on call volumes, TTC (time to completion), SA workload, the rate of escalation, volume trends, etc. Some software also allows customer satisfaction surveys (that only the management can see).
Other popular features include the ability to schedule system maintenance window tasks (by having each task entered as a separate ticket), and having server/network monitoring tools (such as HP OpenView or IBM Tivoli) have the ability to automatically create and enter trouble tickets.
There is free/open source software available.
Of these Request Tracker
is the most recommended.
However a good commercial package can be very worth-while.
You can find these with a
Google search for trouble ticketing system
and locate scripts with a
Google search for +("Help Desk" OR "Call Center") +scripts +open.