Implementing an electronic helpdesk

This article is from the February 2003 issue of Update.

Context

The LLRS is a partially converged service; IT support staff are based in the library but technical staff responsible for IT infrastructure are based in a separate department called Information Systems Services (ISS). On the Preston campus, users can gain help in three different ways: a (face-to-face) helpdesk on the first floor of the library; a telephone helpline; and an email helpline. There is also a reception and a Registration and Printer Support Desk but these are managed and staffed separately.

The helpdesks support all library enquiries, and IT enquiries for core software (e.g. Microsoft Office, email, internet) and networked PCs. They are staffed on a rota basis during core hours by 29 user support staff, who are a mixture of library and IT specialists. Most staff work on either telephone or face-to-face desks because of the different skills and knowledge required. Although this setup seems to work best, a combination of a large pool of staff and separate teams makes consistency and sharing of information difficult. Similarly, while we have a close and positive working relationship with ISS, there are challenges in terms of project management, such as the inevitable differences in priorities and practices between two separately managed departments.

Before the introduction of EHD, all enquiries to the telephone and email helpdesks were logged to a basic level. Enquiries at the face-to-face helpdesk were not logged at all (except during Sconul statistics weeks!).

Objectives

An electronic helpdesk is simply a piece of software used for recording and monitoring enquiries — the same software used by companies who have a customer helpline. We anticipated the benefits of a helpdesk system would be:

• standardisation of procedures;
• improved recording of enquiries on all helpdesks, making it easier to trace previous and continuing enquiries, particularly when escalating problems between the library and ISS;
• identification of problem areas and skills requirement of users and helpdesk staff;
• production of management statistics;
• ability to maintain and monitor service standards for response and resolution; potential for ‘self-help’ for users via access to a knowledge base;
• staffing levels and deployment;and, ultimately,
• improved customer service and information.

Getting started

A working group was set up, drawn from helpdesk and ISS staff, to oversee the whole selection process, from researching the product market to the eventual purchase of a helpdesk system.

Before buying any software you need to define your requirements and it’s easier to do this if you have a look at a few systems first. Very few libraries have an electronic helpdesk and there were even fewer when we started out. However, lots of computing services have them so check with your own first. Sara Eyres’s survey for Ucisa lists universities and the systems they use.1

Things to consider when looking at helpdesk software include:

How easy is it to import a user database? This might be your library system or your institution’s student record system or some other source. Can you bulk delete users? Remember, universities have a high user turnover each year. Can you have a dynamic link to your user database to avoid importing data?

How does the system cope with large numbers of users? Does this affect performance?

• All databases use a ‘primary key’ (or unique identifier) to identify a user, e.g. user ID. This enables all information on each user to be linked together within the database. What are you going to use? Are there restrictions on what you can use and, if so, how will this affect your plans? For example, we had intended to use the barcode number on the user’s library card but our chosen helpdesk system will only allow us to use their user ID. Luckily our user database allows us this flexibility. Does yours?
• How easy is it to customise, e.g. add new fields, change field titles? Helpdesk software is written for the corporate call centre market and you will probably want to use your own terminology. It is tempting to buy a cheaper off-the-shelf product, but will you soon be irritated by its limitations?
• Licences. How many helpdesk staff can be logged on at the same time? How many licences will you need? Many suppliers will make you buy licences in ‘blocks’ rather than individually. Are the licences concurrent or are they restricted to named individuals? For us, the former was essential because we have a large pool of staff on the helpdesk rota; having to buy an individual licence for every member of staff would have been prohibitively expensive. If you opt for concurrent licences, don’t forget to allow a ‘float’ (or extra licences) for helpdesk staff logging on after their session to follow up enquiries. One database used to have a time delay of an hour after logging out before another user could take up that licence: make sure you read the small print.
• Hot topics. Is there a quick way to log common enquiries, e.g. Is this book in stock? Where are the toilets?

Perhaps most important of all, it is essential that you involve your technical staff at all stages.

The tender process

The invitation to tender lays out all the relevant background of your institution/library, and lists all your essential and desirable requirements. Be sure to give detailed technical specifications of any systems or software with which the helpdesk system will need to interact. Your finance department might have a standard template to get you started. There are also courses on how to write tenders; some have been advertised on lis-link.

The next task is to advertise. We had difficulty getting companies to respond despite faxing the advert to our favourites. Was it simply too much effort? With hindsight, we should have got specific contact names and followed up with phone calls.

When it comes to product presentations be aware that most companies are not used to dealing with HE and will make little effort to adapt their terminology. They will also try to sell you as many modules as possible whether you need them or not. Be absolutely clear what you are getting for your money: it is amazing how many features in the demonstration are not included in the cost.

Get everything in writing. During presentations we were assured the software was compatible with a barcode reader: after purchasing the system, this proved not to be the case. Finally, beware the response ‘can be configured’ — they leave off the ‘at great expense’.

Implementation

The implementation team should be drawn from all relevant staff, such as helpdesk teams, to give balance and a sense of ownership. And, importantly, the project leader needs either to be seconded to the project or released from duties, or you should accept that the process will take longer. In any case, the project will always take more time than you think: ours was dogged with unforseen technical difficulties.

Most suppliers will provide a consultant to set up and install the software for you. Expect to pay at least £600 per day plus expenses (travel and accommodation). Consultants should provide a written report of all the work done, any configuration, any outstanding tasks, etc. Keep a note of the hours worked — you don’t want to be charged a whole day if they left at lunchtime. It might even be worth agreeing an expenses limit: one company tried to charge more than £300 for a flight from London to the North.

It is helpful to have made as many decisions and done as much preparation as possible before the consultant arrives. Some things you might want to consider are:

• Fields. What do you want to include on the call (enquiry) screen? Think of the way the user interacts with your helpdesks. What information would help you solve an enquiry? Name, department, file server? Think of the reports/statistics you would like and this will help determine the fields, e.g. if you want to know what percentage of users who come to the helpdesk are part-time, you will need a field to record this.
• User database. You need to have some way of recording who came to your service points. How you do this will depend on how detailed you want your management statistics to be. Are you going to import all users (a large percentage of whom might never contact your helpdesk). This way all your user information is to hand, and you can create detailed usage statistics. Or will you just include staff, and have dummy IDs for students (an option chosen by at least one university)? Or are you going to input each user as they come to the helpdesk (time-consuming)?
• Call categories. We started off by looking at our current enquiries and arranging them into groups (e.g. Electronic Resources, Software, Library, User). How broad or specific should categories be? It’s best to strike a balance so it’s quick for staff to log enquiries but detailed enough to provide meaningful statistics. What about ‘other’ enquiries? We had intended to avoid ‘other’ at all costs but in the end it proved to be a pressure valve for staff in the first few weeks of going live. The trick is to organise your categories so you still get interesting data from ‘other’ enquiries.

One thing we would wholeheartedly recommend is to have a mirror of your live database, licence permitting. We have found it invaluable for trying out new fields and for training, because you don’t compromise the integrity of the live data and use up valuable licences.

Finally, don’t forget practical things. Will you need an extra PC to run the helpdesk system? Are there enough power sockets and network points? How long does it take to get them installed?

Going live

We opted for a phased rollout starting on the telephone helpdesk and moving out to other service points a month later. This gave us the opportunity to test the system in anger and to iron out procedural and technical problems. All staff received one-to-two training which talked them through the main features, logging calls, retrieving calls, etc. At the end they were given a quiz and time to practise logging calls. Extensive in-house documentation was provided, ranging from explanations of the different functions to call category indexes and charts.

On each ‘going live’ week, a member of the implementation team sat with all helpdesk staff for at least their first session. Some staff needed two or three sessions before they felt confident enough to go solo.

It was chaotic, and call categorisation was erratic at best, but both have improved immeasurably. One key to smooth running is to get the user’s ID as soon as possible, and fill in the screen as you go; there is no time to do it all at the end.

We expected negative comments, particularly on the face-to-face desk, because of increased waiting times and because some users might be reluctant to lose anonymity by handing over their library card. However, feedback has mostly been positive. Users particularly appreciate being given a call number if their enquiry needs following up or if they need to come back to speak to someone else. It gives a kind of reassurance that their problems are being dealt with.

In fact the whole process has highlighted basic customer care skills, such as the need to acknowledge the queue while completing the writing up of a call.

Progress so far

The EHD has had an enthusiastic response from helpdesk staff, particularly on the telephone team. There are now more teams interested in coming on board from other sections in the LLRS and increased interest in using other functions of the system such as inventory.

Statistics already show the differences in traffic and category of enquiries at each desk. There are definite peaks and troughs in traffic on the face-to-face helpdesk but the telephones (which take predominantly staff enquiries) remain more constant. The telephones also take a greater proportion of IT enquiries compared to face-to-face, which is more evenly spread.

We are looking at using these statistics to target staff resources. For example, at the moment, the helpdesks are open all hours with a full service; it might be possible to target busy periods, reduce staffing, review the grade of staff on each desk, etc.

Last year also saw the introduction of student IT helpers. The general feeling was that they had taken pressure off the face-to-face helpdesk and this has now been confirmed by statistics. It’s not possible to include their work in the EHD yet but we will be looking at this.

Another advantage has been the ability to track the progress of a call, keeping ourselves and the user informed. Looking at the call categories of a frequent caller might reveal a need for user training, but it also helps us build up a picture of the problem behind the symptoms, particularly if PC-related.

Finally, the EHD has made it possible to monitor the impact of new initiatives on our service, e.g. the decision to deliver the student satisfaction survey solely on WebCT. We have also used it to identify frequently asked questions and to determine what should be given prominence in the redesign of our web pages.

Future plans

The EHD is constantly evolving. We still have a long way to go in the project, including a rollout to our other campuses. We also have plans to build up a searchable knowledge base for our users and give them the ability to log and check the progress of their own calls. This will be particularly useful now the LLRS is moving even further towards self-service and extended opening hours.

On the telephones, we would like to invest in some call management software. We already operate a ‘hunter’ group to distribute calls evenly to each phone but would like more sophisticated software which can queue users, delay ringing so staff have time to finish writing up a call, and display missed calls, how many users are queuing, etc.

Call centres are a growing industry. Indeed, UCLan has just launched a Postgraduate Diploma in Contact Centre Management, and the LLRS is taking part in research on how call centre technology might be used in a university-wide setting. We’ve barely touched the surface of our helpdesk software but look forward to exploring its potential.

Reference

1 There is a ucisa-helpdesk list on JISCmail (www.ucisa.ac.uk/groups/tlig/asg/docs.htm).

Julie Hitchen is an Information Officer and Electronic Helpdesk Project Leader at the University of Central Lancashire