Dr. Neil McBride

De Montfort University, Leicester LE1 9BH

Centre for IT Service Management Research

44 116 207 8500

Ivor Perry

De Montfort University, Leicester LE1 9BH
Centre for IT Service Management Research

44 116 207 8500

Michael Sainsbury

De Montfort University, Leicester LE1 9BH

44 116 207 8500






The paper sets out to assess both the importance of the helpdesk as an arm of IS/IT service delivery, and to examine, through a case study, the effectiveness of call prioritisation. The research finds that call prioritisation is used more as a reactive and controlling procedure, than as a proactive and enabling process. It concludes that helpdesks are ideally placed to add value to the serviced delivery of IS/IT, but will need a number of enhancements, in both technology and organisational structure and culture.

Keywords; helpdesk, call prioritisation, workflow, service, call life cycle.



The role of the IT helpdesk within organisations is becoming increasingly important. It provides the key interface between users and IT professionals and is the hub of IT services activity. The support of existing information systems and the introduction of new information systems may be managed and monitored from the help desk. Indeed IT help desks may have a strategic role in the take-up and management of information systems (Marcella and Middleton, 1996). Critically, internal helpdesks will be the link to external maintenance providers. The speed and accuracy of diagnosis, together with the identification of the supplier (there may be a number of service suppliers) and the time-to-contact, will all be integral parts of any mission-critical system.

In service terms, the helpdesk should be the beating heart of IS / IT systems. Just as the customer contact centre is the point where the external customer touches the organisation and its products or services, so the helpdesk is where the internal customers – the users – touch the IT services which enable all those products to be delivered to external customers.

Information flows which support the control of an IT department will centre on the output of the help desk support systems, which in turn may link with the software configuration management systems, procurement support systems and IT asset management systems. The information flow may extend as far as system development support systems, systems development project management systems and reuse management systems. We would suggest then, that the help desk is in fact critical to the success of IT service delivery and systems development within any large organisation.

Although effective management of the IT help desk and its links with users, developers, administrators and technical support staff is key to a successful IT service function, its status, both professionally and academically has tended to be low. While, textbooks and technical reports abound (Bruton, 1997; Thomas and Steele, 1996, Czegel, 1998), IT help desks have not been the focus of a significant amount of information systems research (Marcella and Middleton, 1996). IT help desks may have a significant role in the successful embedding of information systems within organisations and hence deserve more attention from the information systems research community.

This paper examines the specific issue of call prioritisation within IT help desks, using a case study to illustrate the issues involved. Using the analysis of a sample of a call log, together with interviews with IT help desk staff, an analysis of the use of a call prioritisation system is presented. The shortcomings of the system are discussed and a model for a more objective prioritisation system is developed.




The traditional role of the IT help desk is in providing technical IT solutions for non-technical users. The problems will concern both hardware and software. User interaction may start with the help desk when hardware and software is installed at the user's desk. The help desk will support and manage the installation process, help the user get started on the company's network and support application training. The IT help desk exists to support users both reactively and proactively, thus increasing business productivity (Bruton, 1997). The help desk has also traditionally focussed on reactive support, receiving requests for help, filtering requests and allocating technical resources to resolving problems arising out of the requests. However, IT help desks may be moving towards a more proactive role, becoming the 'human face' of IT, servicing requests for new systems, arranging user training, monitoring business benefits of delivered information systems and negotiating and evaluating service level agreements. They also provide the interface between the users within the organisation and the technology suppliers and outsourcers. In addition, as an interfacing function, the IT help desk has a significant operational role in crossing the business/IT gap which is so prevalent in large organisations (Peppard, 2001).

Telephone-based contact has traditionally been the prime channel for problem communication and resolution, although increasingly communication with the IT help desk has been through e-mail (Hahn, 1998). E-mail provides a means of regular mass communication with all company users, broadcasting news of problems, new services, planned downtime and company-wide advice concerning, for example, viruses. Advice resulting from a call may be provided over the phone, electronically or by a visit of a member of the technical support team.

In addition to providing advice and support for users, another motivation for developing and maintaining the IT help desk is to protect IT staff from users. In a small IT environment, it is easy for users to directly contact application programmers to talk about problems arising from application they have worked on. Indeed, good user - developer relationships develop and the service is perceived to be of a high quality. As the number of users and the size of the IT installation increases, developers find themselves spending more time on the telephone than writing and maintaining the computer systems. In this situation, the help desk provides a buffer between the developer and the users, and enables management to keep control of the workload and keep developers focussed on the development of computer systems. However, such formalisation of IT support access for the users can result in a user perception of lost quality and increased bureaucracy.

Help desks themselves suffer from a number of difficulties. They are often poorly resourced (Bruton, 1997), particularly since their status is low and management commitment, both within IT and at the top of the company may be limited. This lack of resources may lead to a situation where the IT helpdesk is so swamped with problems that it is working purely reactively and does not have the time or resources to develop the proactive problem management strategies which would eventually reduce its workload.

In addition a predominantly technical focus on machines and technical problems means that little attention is given to developing a customer focus and pursuing business benefits. IT help desks also struggle with the constant pressure and pace of technological innovation. Upgrades of software and hardware, the introduction of new business applications and the invasion of external Internet-based information systems into the internal company environment put added pressure on a generally stretched IT support department.

These problems give rise to the overriding problem of the allocation of scarce resources, a problem which is endemic to all aspects of IT services and development and is particularly apparent in the management of IT help desks. The next section concentrates on call prioritisation and overviews motivation for call prioritisation and mechanisms of call prioritisation.



A call prioritisation system determines the speed with which the call is dealt with and resolved. Its prime purpose should be to maximise scarce resources. We will show, however, that in practice, it is used to ration those resources. The difference between the two will be seen as reaction versus proactivity, of control versus creativity, of organisational defence rather than organisational growth.

In practice, most helpdesks experience peaks and troughs of activity. Regardless of the size of the helpdesk, peaks of activities will result in there sometimes being more outstanding calls than there are staff to deal with them. Many helpdesks have a permanent waiting lists for support. Thus decisions must be made concerning the significance of calls, who should deal with them, in which order calls are allocated and whether some are actually resolved at all.

A similar situation exists in health care where the demand for healthcare constantly out strips resources. Decisions must be taken by gatekeepers, who may be general practitioners, consultants or even managers, as to who receives the healthcare and who gets priority. Waiting lists provide a prime mechanism for rationing routine or elective treatment. In the case of, for example, transplants, waiting lists arise due to the scarcity of transplant organs. Patients are evaluated on the basis of their medical condition, weighted by their time on the waiting list (Tynan, 2000). First on, first-off waiting lists, while fair and democratic are impractical for help desks (Bruton, 1997). However, degrees of prioritisation may be applied using pre-set maximum waiting thresholds, but other methods are needed which involve choice and selection, whether by an expert of by the consumer. In accident and emergency departments of hospitals, triage involves the assessment of the patients and the deferring of patients who are in a stable state in preference to those more seriously ill. Here the prime criterion is clinical severity. In an emergency situation, such as an earthquake or fire, treatment may rationed according to role and perceived value, so rescue workers are treated first in order to return them to effective work. Similarly in the battlefield, commanders may be treated first because of their critical role, or those less severely wounded are treated first in order to return them to the battlefield. In each case, prioritisation decisions are being made which are complex and not purely clinical. These decisions are being made by experts or those is power who made have a variety of motivations both explicit and hidden.

Alternatively, the users of a service may make their own prioritisation choices. In the case of Oregon State, a Health Services Commission made choices through surveys of a thousand Oregonians concerning some 1600 treatments for particular conditions (Rai, 1997). This survey gave the administrators a view of how the public rated the impairments arising from conditions. Benefits could be calculated and a cost-effectiveness measures obtained. This lead to the ranking of 709 treatment / condition pairs. The practicality of such an exercise for help desk problems may be limited by the effort of surveying and analysing users' views of IT problems. Alternatively, if users are left to determine their own assessment of the severity of their IT problems, perception issues may come into play. One users minor inconvenience may be another user's debilitating problem as a result of the user's level of stress, the nature of the job being done and simply how the user feels at the time. Indeed it may be difficult for users to make the decision to delay obtaining solutions to their problem on the premise that other might have worse problems.

Most help desks operate a prioritisation system, whether formal or informal, whereby a help desk call is assigned a category, usually by personnel on the help desk. This category carries with it an expected timescale for resolution. For example, the Computer Services helpdesk at Imperial College, London uses the following categories (Imperial College, 2001):


Critical 4 hours

Urgent 2 working days

Important 5 working days

Minor 20 working days.

The assignment of that category will be influenced by a number of factors including the effect on the organisation's customers, the technical severity, the role and perhaps status of the user (or the person the user is acting for), the size of the effect of the problem in terms of the number of users affected or overall effect on the business and the nature of the work. For example, the help desk at Purdue University North Central operates on five categories of priority, each linked to a type of activity (Purdue, 2000):

Priority 1: Student Computer Labs While Class is in Session. This would include items causing a computer or printer to be unusable during class time.

Response Time: Immediate and called in to the technician by radio.

Priority 2: Faculty Classroom Support and Time Sensitive Essential Business.

Faculty classroom support involves correcting difficulties the faculty may encounter with currently installed student lab software and lab printing services. Critical business functions essential to the business of the university. Examples include bursar customer support, advisors unable to schedule students, or financial aid unable to record transactions.

Response Time: Within one day.

Priority 3: Non-Routine Required Work. Most help desk calls fall under this priority. Items included in Priority 3 are general software and hardware problems.

Response Time: 1-5 working days

Priority 4: Regular Routine Work. This priority is reserved for things such as planned system upgrades, back ups of network hardware, and the creation of accounts on our servers.
Response Time: 1-5 working days

Priority 5: Special Purpose Events, Software and System Upgrades.Special Purpose events are things such as setting up special computers for presentations or demonstrations or setting up computers for a one time event. Software and/or system upgrades include installation of new hardware or software.
Response Time:
1-2 weeks for special purpose events; two to three months for software and system upgrades.


The definition of the help desk call categories, the definition of response times and actions associated with them and the construction of service level agreements provides the first point of management intervention. However, once the categories have been defined, further intervention and interpretation is possible. There may be ambiguity and hence room for interpretation over what category is initially allocated to a call. This may not be purely objective, but may involve perceptions of the importance of the user, the solvability of the problem and the current active workload. Furthermore, once an initial priority has been allocated, there is an opportunity for escalation or de-escalation. For example, at Purdue University some Priority 2 calls are elevated to Priority 1 to ensure corrections or repairs are completed before the class begins and Priority 3 calls may be escalated to Priority 2 if the problem starts to interfere with an essential business function. Escalation and de-escalation decisions may not necessarily be made purely on technical grounds.




This study focuses on the help desk operations of one company which one of the authors had detailed knowledge of through a work placement. A detailed understanding of the workings of the help desk and the call prioritisation system was obtained. The call prioritisation system remained unchanged over a period of two years. Analysis was conducted by sampling calls and interviewing help desk staff.

Firstly data for all calls over a given week was sampled an examined quantitatively to see if there were any relationships between call priorities and call types. However, such a sample only identified the final classification of the call, which may differ from the initial classification as a result of escalation or de-escalation. Therefore some calls were analysed in depth, looking at their history and progression and reviewing them with help desk staff. This call log data was extracted from the Royal Blue Helpdesk System and formatted using Crystal Reports Version 4.5.1. Secondly, interviews were held with two of the five help desk analysts at the company to obtain insights into the usage and interpretation of the call prioritisation system.


Energy Technologies is concerned with innovation in energy and fuel delivery sector. Its headquarters houses a research and development centre with some 650 employees. The site also contains the company's head office and substantial conferencing facilities.

The help desk, situated in the IT Services department provides IT support for the employees at headquarters and a further 250 employees at satellite sites across the UK. Some employees use a remote dial-in connection to work from home or remote offices.

The network supports 900 PCs running Windows NT and 30 Unix server.

The help desk operates throughout core working hours with 5 staff, dealing with around 65 calls a day. Eighty-five percent of the calls are resolved by the help desk team. The remainder are passed on to other teams in IT Services. During a two year period of involvement with the help desk there was always a queue of outstanding work.

Users may report problems by telephone, email, paper forms or in person. Calls are logged on the Royalblue helpdesk for Windows system, using the callers extension number as a key. A brief description of the problem is entered and the call is given a priority assignment. Calls appear on the workload list in the system and escalate automatically as time elapses, Closed calls are logged in the database and can be reviewed if necessary.


The prioritisation system at Energy Technologies involves five categories:

Category A. Urgent, Highest Priority. Problem stopping staff from working which is dealt with immediately, if possible. Examples include PCs not powering up, and users unable to log on to the network.

Category B. Important. Standard priority assigned to most calls passing through the help desk system.

Category C. Non-Urgent. Calls deemed non-urgent. This category includes calls concerning non-standard software, software evaluations or calls not directly related to the user's work.

Category I. Incident. Disruptive problems affecting many users. Examples include loss of part of network and the presence of a computer virus. These calls are monitored by higher management and the IT department is set targets to reduce the number of calls with this category.

Category P. Pending. Calls on hold. The call may be waiting a part or service from a supplier, or the user cannot be contacted.

While staff may change the priority of calls, and additional automatic call escalation system operates within the helpdesk system whereby the system changes the colour of the call and moves it up the list of open calls. Table 1 list the call escalation values for Energy Technologies, showing the elapsed time in minutes for a call to be escalated depending on its priority.


Escalation 1

(Turns green)

Escalation 2

(Turns yellow)


(Turns red)

Breach 2

(remains red)



























Table 1: Priority Escalation Sequences

6.1. Helpdesk call life cycle

The following out lines the process by which a cal to the help desk is resolves and closed:


6.2 Escalation and De-escalation Strategies

Within this call life cycle, the analysts first contact with a call is when it appears in his worklist. It was clear from the interviews that almost all calls are allocated to Priority B when they arrive at the help desk. The few calls may be judged as A priority by the help desk administrator. These calls are acted on immediately by a help desk analyst, according to a rota system. A priority calls are rare: none appeared at all in the week's call log entries which were analysed as part of this research. When reviewing a workload list, the analysts tended to focus on the description of the problem and ignore the priority.

Analysts suggested in interviews that calls tended to remain a B priority if the call was simple and could be closed quickly. Calls were de-escalated from B to C if:

When there was a very busy period, analysts would contact users to explain that they would get back to them when there was less of a workload and then reduce the priority to C.

As noted, the helpdesk system itself escalates calls by changing the call's colour on the workload screen after a defined time interval. Analysts never escalated a call's priority.

Aggregate Data extracted from the RoyalBlue help desk only indicate the priority of the call when it was closed. While initial priority of each call could be obtained from a detailed printout of call details, this was only done for a small sample of calls. Since almost all calls are logged as Priority B, the priority of the call when closed was of more significance in studying the use of the call priorisation system.

Only 41.1% of closed calls were of Priority B. This suggested a high level of call priority changing, or de-escalation. Indeed, 45.5% of calls in the week-long sample had been de-escalated to Priority C and 12.9% to Priority P. Contingency tables were constructed comparing call priority classification with type of user group generating the call and type of problem. More calls from the Science and Engineering department were de-escalated (64.2%) than from administration (41.6%). It could be that there was a greater complexity to Science and Engineering calls that was causing greater de-escalation by analysts. Analysis of the effect of the type of problem on final call classification (Table 2) shows significant differences for different problem types.

Problem Type

Priority C

Priority B

Priority P

PC Software




Windows NT




PC Hardware








Outlook (Email)
















Table 2. Final Call Classifications for different types of call (Percentages of total number of calls for a given problem type. Total number of calls analysed: 207)


7.1. Call prioritisation as a tool for workflow control

The first question to be asked of any call prioritisation system is: what is its purpose? In this case, it does not seem that the assignment of a priority reflects the importance of the call since a majority of calls, even from directorate secretaries, are assigned priority B. The call priority system is not being used as a way of determining which call to process next. Analysts assess call priority from reading the description of the problem. The evidence of this study suggests that it is being used by the analysts as a mechanism for controlling workflow.

The prime means of communication concerning calls with the analyst is the worklist that is constantly present on the analyst's screen. This shows calls arriving, the status of calls and shows which calls are escalating through the traffic light system and going from green to yellow to red. Significant importance may be attached by analysts to call escalation and indeed effort is put into avoiding call escalation, particularly avoiding escalation of calls to red. Controlling the colours on the worklist becomes the driving force behind call prioritisation and workload control. The motivational focus of the analyst is then on strategies for manipulating the worklist in order to keep it as green as possible. This is achieved by taking every opportunity to reduce the priority of a call such that the time interval before escalation is increased. Hence call priorities are reduced once the user has been contacted, once the call has been passed to another group and even to reflect the perception that the call will be difficulty to resolve. Here, the control of workflow is subject to the symbolic representation on the worklist screen and the meaning attached to it by the workers. The symbols may be entirely arbitrary, but the constant presence of the worklist and the meaning attached to them by the analysts confers power on the helpdesk system to control workload and direct workflow. The final priority of a call when it is closed may reflect the difficulty of resolution. Calls that can be quickly resolved, such as those dealing with passwords, are more likely to remain at priority B.

7.2. Criteria for Call Prioritisation

This case study illustrates how call priority allocations may not reflect any inherent characteristics of the call being serviced. The call priority is not directly dependent on the nature of the problem. Final call priorities reflect more the ease of solving the problem than the importance of the call itself. Easy to solve calls may not provide the best business benefits.

Call priority systems should relate the priority to the call characteristics. The allocated priority should reflect and to some degree be a measure of the cost of not answering the call. Call priority should reflect characteristics such as:


Business role of user and affect on ability to work;

Types of business process affected;

Perceived business benefits of resolving the call.

However, such characteristics are difficult to determine, even by the users themselves. For example, a call may be logged by control engineers in charge of critical real time systems. They may perceive the problem as a minor PC fault which may turn out to be a critical application error which leads to significant system outage. Since the control engineers are not aware of the complexities of the IT they are using, they may not realise the significance of what looks like a minor problem. A call from such a critical service area of the business would never be allowed to de-escalate. Immediate action would be required which, if it involved other teams or suppliers, would require the maintenance of a high call priority by other teams and suppliers. A call from control engineers would not be put on priority P because parts were required. The critical call priority would be cascaded to suppliers who would be expected to take immediate action in accordance with service level agreements. Call priorities based on the technical impact of the problem may be defined by IT, but this may not address the business context of the call.

In the helpdesk we have studied, prioritising is being understood in terms of time-to-respond, not time-to-fix. Yet the major issue for the business is likely to be time-to-fix. As the business users’ expectations and reactions were outside the scope of this study, this observation has to remain one for future research. However, the study does show that the helpdesk is concentrating on the presenting problem, not the associations which that problem may have (in terms, say, of knock-on effects). Nor does the presenting problem approach show the history, or audit trail, of this piece of equipment or reported problem. While all systems’ acquisition must be a question of trade-offs between cost and functionality, there is a case for examining the use of extensive audit trails or history repositories. In this way, an incoming call or email could be rapidly analysed, as a part of the categorisation process, against previous similar problems and against problems from that part of the organisation or that part of the system. Together with information on the Service Level Agreements with outside suppliers, this could provide an estimate of time-to-fix which would then give a more accurate, business – facing prioritisation. For the more complex or extended problems, it would also form the basis of an activity plan which could be monitored. Further, it would give the in-house service consumers their own data against which to measure the data provided by external service agents as part of ongoing SLA reviews.

We would suggest that call prioritisation should be a business judgement rather than an IT judgement. Since when a call is logged, the technical nature of the problem is not known, judgement should be made on the business effect of the problem. The technical difficulty of the call or the nature of the technology associated with it may not be as important as the service it affects. Calls should be associated with the business service affected, and within that service, the business process affected. Furthermore, since one call may involve several technical domains (network, multiple applications, hardware), relating the call to the business service and the business process removes any dependence on identifying which technical domain is the most significant.

Such an approach to call prioritisation calls for the development of a catalogue of business services which identify their benefits (including for example revenue and importance to the customer) and details the workflows and processes involved in those services. The actual links between IT services and these services and processes would be explicitly stated so that it was clear how the IT service and system impacted on the business services and processes. This business service catalogue may provide the basis for developing a set of call priorities that can be entered into the helpdesk system, or incorporated into an expert system.

Just as the use of audit trails or history repositories is likely to add a cost overhead to these systems, so the inclusion of expert systems for decisioning, or workflow engines for enacting the business rules, may substantially increase the start-up cost of helpdesk systems. On the other hand, large companies in particular may be able to make significant savings; for example they may protect themselves against critical failures with less investment in duplicate systems for contingency or disaster recovery; further, they may be able to manage the relationship with external maintenance providers with more speed and accuracy and at possibly less cost.

If the IT and hence the call can be allocated to specific elements of workflow which enable the delivery of services, then a clear priority can be allocated to a call which reflects its business value. IT help desk call prioritisation is an area which needs further research and development. New call prioritisation approaches are needed which, when supported by appropriate systems, can be tested in the field. These call prioritisation systems must reflect the integration between information systems and the business services and enable the IT help desk to fulfil an increasingly important role in organisations.



BRUTON, N. (1997) How to Manage the IT Help Desk. Digital Press.

CZEGEL,B. (1998) Running and effective helpdesk. Wiley.

THOMAS,A.H and STEELE, R.M. (1996) The virtual help desk: Strategic Management Center. Thomas Computer Press USA.

HAHN,K. (1998) Qualitative investigation of an e-mail mediated help service. Internet Research 8(2) 123 - 135.

Imperial College (2001) The CCS Help Desk Service Accessed 13/11/2001

MARCELLA,R. and MIDDLETON, I. (1996) The role of the help desk in the strategic management of information systems. OCLC Systems and Services 12 (4) 4 - 19.

Purdue University North Central (2000) Help Desk Terms of Service Accessed 21/11/2001

PEPPARD, J. (2001) Bridging the gap between the IS organisation and the rest of the business: plotting a route. Information Systems Journal 11(3) 249 - 270

RAI, A.R (1997) Rationing through choice: a new approach to cost-effectiveness analysis in healthcare. Accessed 21/11/2001

TYNAN, A (2000) Waiting lists for healthcare in developed countries - initiatives for long-term management. Accessed 21/11/2001