Implementing a Help Desk at a Small Liberal Arts College Copyright 1992 ACM 0-89791-546-1/92/0011/0037. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. This article was reprinted with the permission of ACM in the Fall 1993 issue of CAUSE/EFFFECT Magazine. For further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; telephone 303-449-4430; email -- info@cause.colorado.edu IMPLEMENTING A HELP DESK AT A SMALL LIBERAL ARTS COLLEGE by Bev Actis ABSTRACT: Because financial resources for implementing a help desk at Kenyon College were very limited, every aspect of planning the service had to be considered from a strict cost-benefit standpoint. What resulted was a low-budget "home-grown" facility with a highly effective operation. This article relates the Kenyon experience, offering a practical model that others with limited resources might follow. In the past five years Kenyon College has taken a giant leap into the computer age. Its computing facilities have been transformed from a small VAX system, with little more than 100 users, to a complete campus network of 2,400 users with access from hundreds of terminals and microcomputers located throughout the campus. Because of this rapid expansion in equipment and services, Information & Computing Services (ICS) at Kenyon established a help desk in August of 1991 to handle the increasing number of requests for services.[1] Our help desk is primarily a phone-based facility, where anyone on campus may call one phone number for help with computing problems or requests. Planning for the help desk facility began in early 1991, with its implementation scheduled for the beginning of the next academic year in August. We gathered information on other help desk operations and used it in drafting our own set of guidelines. These guidelines included objectives, costs, support, physical setup, equipment and software needs, staffing and training, operating procedures, call tracking and phone management, marketing, credibility, and evaluation. We began to realize, as the help desk developed, that this in-depth planning phase was crucial to its ultimate success. This article covers our approach to planning and implementing the help desk and how that approach was modified during our first year of operation. We hope it will offer a practical model for other colleges who may be considering a help desk but have limited resources to begin. Mission and goals The very first step in implementing any service such as a help desk is to articulate its mission and the goals by which it intends to accomplish that mission. The help desk (called the ICS HelpLine) was established to support academic and administrative customers in using Kenyon's computing resources more efficiently. It was also meant to serve an educational role by helping those customers learn more about their computing environment, while at the same time helping them solve their computer problems. To accomplish this, the following goals were set: 1. Respond to customer requests for help in an organized manner by developing a referral system to route those requests to the most appropriate ICS staff member. 2. Develop a call-tracking system to monitor help desk activities so that ICS could troubleshoot computing problems more effectively, target areas needing better training and documentation, and evaluate our performance. 3. Develop our awareness of the help desk's role as educator as well as problem-solver when consulting with customers. Budgeting With those goals in mind, the next step was to figure out how the new help desk facility could be funded. Our department head supported the help desk idea, but money was very limited. Each expense had to be weighed very carefully, so we decided to begin as simply and inexpensively as possible. The following resources were considered essential for the help desk to function successfully: 1. A large desktop area with space enough to hold the equipment for running a help desk. The equipment and software would be duplicates of the most common setups on campus so that computing problems could be more easily diagnosed. For our setup, this included the following equipment: a DEC terminal; a DOS microcomputer with hard drive equipped with supported software packages (both systems to be connected to the campus network); an attached Epson dot-matrix printer; and an accessible system-queued HP laser printer. 2. A call-tracking system for recording call information on computer problems. A commercial package would have cost about $1,500, so we decided to create our own with existing database software. 3. Documentation for software and hardware supported by ICS. Much of it was collected from other offices of the department; only a small amount had to be purchased. 4. A separate phone line for the help desk. An answering machine was purchased to handle phone calls after hours or when the help desk analyst was unavailable. A headset and long phone cord were items that were considered essential for the help desk analyst's comfort. 5. Initial training expenses. We decided to spend $800 for a help desk management seminar because we felt we could benefit from the hard-won experience of other help desks and save ourselves from costly mistakes; it was money well spent. Another $500 was designated for training the new help desk analyst in interpersonal and problem- solving skills. 6. Salary expenses. The College would not approve a new position for a help desk analyst, but upgrading the department's secretary/operator position solved the problem. An upgrade in an existing position, rather than a newly created position, also reduced the amount of additional money needed for the analyst's salary. Scope of support Regarding the issue of support, answers to the following questions had to be decided: For what areas of support would ICS be responsible? Who in ICS would provide that support, and how? When would support be provided? Once we decided on these answers, we had to communicate them to our customers so they would understand what they could expect from us. * What would ICS support? A list was made of all ICS-supported hardware and software products and services. This support list also included: software installations and upgrades; hardware installations, maintenance, and repairs; training in the use of software and hardware; advice on hardware and software purchases, etc. * Who in ICS would provide that support? All ICS staff members were expected to provide support in their own areas of expertise when calls were referred to them by the help desk. * How would ICS provide support? Our help desk facility was primarily a phone-based operation. When walk-ins sought help, they had to understand that they would have to wait for the analyst to handle incoming calls first. This policy had to be set, since there was only one person to handle the phone. * When would support be provided? At first the help desk was available only during regular office hours, but the hours were later extended to 10:00 p.m. when a night operator who became proficient in handling students' computing problems assumed help desk duties. The answering machine recorded calls when no one was available. Physical setup Where would the help desk be located? It was set up in an open office reception area, making it easily available to walk-through traffic, but that was a mistake. It should have been more remote, since the help desk analyst had difficulty listening to phone calls because of other distractions. There was actually no other place to relocate, so the help desk area was rearranged so that it was better sheltered from general traffic. Walk-in customers were directed to student computing assistants in the nearby terminal room. If they needed further assistance, the computing assistant could then call the help desk. That way the analyst could handle requests by phone in an orderly manner. There had to be space near the help desk for reference materials. All the documentation for supported hardware and software was located to make it easily accessible to the analyst. Included were vendor manuals, locally written documentation, periodicals, etc. An important reference resource was the file drawer of miscellaneous articles, tips, and hints on various computer-related topics that had been collected over time. This information was organized under the same computer topics that were used for the call-tracking system, making it easy to find when consulting with a caller. Staffing Since approval for a new help desk analyst position was impossible, we had to become very creative. The job description of ICS's secretary/operator (whose duties already included answering simple computing questions) was upgraded to those required for running a help desk. We couldn't offer a salary increase immediately, but planned to appeal during the coming year to Kenyon's senior staff governing board for a reclassification of the position from clerical to administrative status, with an appropriate salary increase. As the value of the help desk to the campus became evident during the first year of operation, we were sure that senior staff would be willing to approve the reclassification. A member of the ICS staff was assigned to work closely with the new analyst as her mentor, to help her learn the technical skills necessary. We found that the mentor relationship was the best way to provide the emotional, as well as technical, support needed to carry the analyst through her initial period of apprenticeship. Although a strong technical background is desirable in an analyst, it is not essential. Our first help desk analyst had been a secretary, proficient in WordPerfect, but not experienced in other computing areas. However, she was good at problem-solving, could learn quickly, and was not intimidated by the rapidly changing computing environment. Most importantly, analysts must have "people" skills, since they are the key to the successful operation of a help desk. They should be good listeners and have a calm, patient manner, able to see things from the customer's perspective. They must handle stress and unpredictable situations well, having to deal continuously with frustrated callers and perplexing problems. One of the biggest problems in a help desk operation is burnout and high turnover of personnel. The nature of the job involves a great deal of pressure--trying to solve difficult problems "on stage," handling irate and often panicky customers, constantly redirecting attention from one caller's problem to another with little opportunity for uninterrupted thought. At the end of a busy day one can become exhausted from having to "switch gears" so often. Frequent and regular stress relief planned into the weekly routine is absolutely essential to prevent burnout. Varied tasks, such as writing documentation, making house calls to perform routine equipment maintenance, scheduling time to learn about new hardware and software products, etc., can help to relieve the pressure of the relentless phone. Ideally, even a small help desk should have two persons, each handling the phone for half the day and doing other user support tasks the other half. We learned this the hard way. Since we were struggling to get even one person to operate the help desk, it was difficult to plan time for her to be away from the phone. After some time, we realized we had to schedule regular "off-the-phone time" or we would lose her. If it is not possible to hire two half-time analysts, then limiting help desk hours each day in order to give the person a break from the phone to do other things for a couple of hours is the only solution. With the recent hiring of a second analyst, we have noticed they are both able to cope better with the stresses of the job. Training The analyst needs preliminary formal training in customer service skills, problem-solving techniques, call-handling skills, and dealing with difficult people. Most seminars of this nature are inexpensive one-day workshops under $100. Since we had upgraded a secretarial position, the new analyst did not have a strong technical background, except for expertise in WordPerfect, the College-supported word processing package. On-the-job training was the basic means of teaching her the required skills. Some of this training included the following: 1. Designated study times during the week to learn new software products. Both vendor manuals and locally-written documentation were used as training materials. 2. "Conferenced" referral calls. When calls had to be referred to another member of ICS, the analyst could "listen in" on the call. In this way, she learned not only how to solve the problem at hand, but also something about phone skills from the other staff member. 3. Cross training with other ICS staff members (especially the mentor). The analyst scheduled meetings with other staff members to learn about their areas of expertise so that she could better answer questions about those areas. Marketing the idea to ICS staff Marketing the idea of the help desk to our own staff was extremely important to get their acceptance. First of all, the ICS department head had to be convinced of the value of a formal help desk facility. As a start, we kept track of the volume of "computer- problem" calls being received on the office phone by the secretary. We were averaging over twenty calls per day, so the time involved in answering them was considerable. We succeeded in convincing our department head that the help desk could: * not only save ICS time in answering questions, but also provide a central feedback point for measuring the department's effectiveness; * identify patterns of computing problems more easily because of its organized monitoring of caller's problems; * also be a means of protecting the College's computing investment by educating the callers in using their computing resources more efficiently. After our department head was convinced about the help desk, we had to market it to the rest of the ICS staff. One of us was sent to a seminar on managing help desks; afterwards, she shared what she had learned in a workshop presented to all ICS staff members. There were several other meetings in which the idea of the help desk was discussed, including its impact on ICS, as well as the College community. Since the staff would have to work so closely together on the problems addressed to the help desk, all would be required to understand and support its philosophy and operating procedures. Without this close cooperation, the help desk could not have succeeded. Once the help desk was begun, we had to show the staff how it could save them time and improve the department's troubleshooting abilities. Monthly activity reports were sent to them, summarizing the volume and kinds of problems the help desk had handled, with descriptions of the most common ones and how they were solved. The report always included the percentage of problems handled by the analyst alone. This percentage eventually stabilized at about 80-85 percent--an impressive figure that convinced the staff of the help desk's effectiveness in buffering them from many calls. Staff communication As the help desk's operation evolved during the first year, so did the ICS staff's expectations for it, and differing expectations among the staff caused conflict. Some staff members resented being interrupted, expecting the analyst to handle more complex questions than she was capable of. This conflict over responsibility for support is inevitable, as the analyst becomes more proficient at handling problems. And it has to be discussed openly and resolved, or the effectiveness and credibility of the help desk will be eroded. Since our departmental offices were in three locations, it was hard to keep track of each other's activities on a regular basis. The analyst had to be kept informed about what was happening in each area so that she could answer questions accurately. After several instances of giving out outdated or inaccurate information, she devised a system of getting daily e-mail updates from each department head to inform her of any important developments. Because the help desk had become a central feedback point, the analyst occasionally had to report problems within ICS itself to the department. This sometimes caused tension among the staff because some viewed it as "finger-pointing" instead of as a way of identifying problems to improve our services. But it is the nature of the job, to pinpoint areas needing improvement, and it is important to deal with these issues openly among the staff. Marketing the help desk to the customer Once plans were made for setting up the help desk, campus users had to be informed about its services. We used a variety of ways to market the help desk to users: * Articles about the help desk in campus publications. Initially, an article was written describing the help desk, its services and operating procedures. Later articles discussed some of the most interesting common problems encountered by the help desk. * An online bulletin board. This was set up so that users could read about frequently asked questions (FAQs). * User group meetings. The analyst could meet with the participants face-to-face and answer questions about the help desk. * Follow-up calls to customers. These calls made the customers feel that we were really concerned about helping them solve their problems. * A brochure listing the services of the help desk. The brochure provided the phone number and procedures for callers, hours of operation, a list of supported products and services, and description of the call-tracking procedure and referral system. Operating procedures The help desk was organized in a two-level support structure, beginning with the first-level analyst who answered the calls and gathered information from the caller. The analyst resolved the problem if knowledgeable about the topic, or referred it to an appropriate "specialist" at the second level. Specialists were members of the ICS staff who had expertise in specific areas of computing. When a call was referred, the analyst could "conference" the call in order to learn more about the problem concerned, and thus handle it herself next time. If the specialists were unable to resolve the problem, they would contact the appropriate hardware or software vendor for help. Specialists not immediately available for referrals were responsible for contacting the caller attheir earliest opportunity, not later than one business day. When the problem was resolved, the specialist was supposed to notify the help desk analyst. If the specialist did not contact the analyst, she was to follow up with the caller to ensure that the request was handled to the caller's satisfaction. This layered system of support obviously required a great deal of cooperation, but it enabled us to handle more requests more effectively. The key to this support system was the referral sheet. It was simply a list of all the specific areas of computing supported by the help desk, with the corresponding names of ICS staff members knowledgeable in each area. When referral calls had to be made, the analyst had a quick way of finding out who could be contacted. In this way, all ICS staff shared in the user support load. It was up to the discretion of the analyst to determine the need for referral, and then distribute the referrals as evenly as possible so that no one received an excessive number of them. Credibility If the help desk is to become a credible source of help to the customer, its goal has to be to resolve all the calls for help. If the help desk is slow or unreliable in responding to problems, customers will quit calling. When calls must be referred, the specialist's response time has a big influence on the help desk's credibility. An urgent problem demands a prompt response, and the help desk analyst must be persistent in following through until a problem is resolved. Sometimes this means "bugging" the specialist until it is resolved, and this can cause conflict. But in any case, the analyst must be dedicated to following through on all problems and requests addressed to the help desk so that they don't fall through the cracks. Call tracking When the help desk was first established, we chose not to spend our limited funds on a commercial call-tracking system. Instead, we devised a simple one of our own with existing software. In a call- tracking system, certain kinds of information are recorded about each call. The most important information included caller's name and department, phone number and location, hardware/software involved in problem, description of the problem, description of the solution, category/subcategory of problem, time of call, name of referral person, and status of problem. Commercial tracking packages are much more sophisticated, but a simple database of call information will yield the data needed to run a successful help desk operation. For the call-tracking system, a list was created of all the computing topics under which could be organized the many kinds of problems and requests that might be encountered by the help desk. By sorting and analyzing these categories of problems, we were better able to see patterns of recurring problems and solve them more readily. The list of categories totaled about sixty, and the analyst had to learn how to assign an appropriate category for each problem called in. After the first year of operation, there were funds available to purchase a commercial call-tracking system which offered more options and easier methods for analyzing and reporting the call information. We are presently testing several other software packages for use on a Novell network. Some of the features we are looking for in a call- tracking system are: 1. A multi-user system. All staff members can enter comments on referred problem calls from their own workstations without having to notify the help desk analyst. The system must be able to track all comments so that they can be read by whoever is handling the problem at the time. 2. E-mail capability from within the call-tracking system. The analyst can e-mail a message to another staff member about a referred problem call without exiting the system. 3. Look-up feature. Staff members can do keyword searches on the system's database, especially the field that contains a description of the problem. The user can easily find other similar problems and their solutions. 4. An SQL-based system. This allows access to other College databases. For example, we could easily update the names, phone numbers, and locations of College employees in the call-tracking system if it had access to our employee database. Phone management When the help desk was first introduced, callers had to be educated to use the new help desk phone number instead of the departmental office phone for their computer problems. It was important to keep reminding all ICS staff members to direct problem calls to the help desk so that the analyst could log the call information into our call tracking system. Also, by taking calls first, the analyst could buffer other ICS staff from needless interruptions for questions she could handle. Even with a separate phone line for incoming calls, our phone system was a weak link in the help desk operation. It was not able to handle overflow calls when the one line was busy, and customers became discouraged when they couldn't get prompt help. The answering machine has greatly alleviated the problem. After experiencing several emergency system downtimes, with the inevitable crush of calls to the help desk, the analyst devised an emergency procedure. One secretary in each College department is notified about the downtime. S/he then notifies members of the department. When the systems are up and running again, the secretaries are again notified. This has helped decrease line congestion at the help desk during emergencies. Evaluation Evaluating the performance of the help desk seems to work best using a mixture of formal and informal methods. A more formal way to get feedback is to send out a customer survey on the help desk's performance twice a year to all users. Informal methods include random calls to customers to ask questions about the help desk, follow-up calls after service, and user group meetings. Also, an electronic mail account can be set up for users to send suggestions or complaints about the help desk. Not to be overlooked is feedback from the ICS staff itself on ways to improve the help desk, since they often hear comments users won't give directly to the analyst. Conclusion The help desk's central position in our campus computing community can be compared to the potbelly stove in the general store of an earlier era. The potbelly stove was the central meeting place of the community, where news and information were passed back and forth. The help desk functions in a similar way. It distributes information and gets feedback by feeling the pulse of the computing community and learning about what is working well and what is not. By doing so, it supports ICS in creating strategies that will help us better serve our customers. ======================================================================== Footnote: 1 Kenyon College, located in Gambier, Ohio, is a small liberal arts college with 1,450 undergraduates, 130 faculty, and 250 staff. The Information & Computing Services department staff of twenty-two FTE supports both academic and administrative computing. ================================================================= Bev Actis is employed as a user services specialist in Information & Computing Services at Kenyon College. She was responsible for planning a campus computing help desk and managing it during its first year of operation. More recently, she has been involved in developing Kenyon's campus-wide information system, KCINFO. Once it is operational, she will provide training and support to KCINFO's information providers. ************************************************************************