Download full articleThis blog focuses on an aspect of selecting an ITSM tool that is often overlooked: the overworked, overstressed, and often underappreciated Service Desk Agents. Having created more Service Desks than I care to count in sites across the globe, I find that many organizations fail to consult the people who will be using the tool at the sharp end. Often, an organization will employ an outside consultancy to implement an ITSM transformation. A great deal of criticism is directed at the existing ITSM tool, and what will transform the Service Desk’s performance is a bright, shiny new tool. What isn’t considered is that the team implementing the new tool is more than likely to have an agreement with an existing ITSM tool provider and will only recommend that tool.
Cue the implementation of a new tool with a new interface, new processes, and new knowledge management that looks very cool and modern. Management is over the moon. This time it will be different, this time it will really work.
No one has consulted the Service Desk Agents who are lumbered with learning a new tool, getting to grips with a completely new interface, missing key functionality, while also transferring the essential knowledge from the old Knowledge Management System (KMS) to the new one.
Service Desk management is often thought of as a simple task, answering the calls, recording the tickets and passing them to the appropriate second-level team. If only it were that simple.
The modern Global Enterprise-Wide Service Desk (GEWSD) works 24*7, in multiple time zones and languages, across many, often virtualized sites. Let us consider a few things that are often ignored by those implementing the tool and project managers trying to control the consultants.
Shift management – How will the Service Desk managers schedule the Service Desk agents? Integration of shift patterns is key to ensuring that the Service Desk is adequately managed during peak times. This should be integrated with the Automatic Call Distributor (ACD). This system ensures that incoming calls are routed to the next available agent based on predefined rules, such as availability, skill set or priority. In today’s GEWSD, where the Service desk is globally distributed and virtually located, this is a key component to optimize the efficiency and effectiveness of the customer service. It is no good if Joe’s phone rings in New York at 2:30 am when he is sleeping, instead of Jurgen’s in Esbach, where it is 8:30 am.
Time zone management – How will unresolved issues, be they incidents or problems, be handed off across time zones? How will Joe know the most important tickets that Jurgen dealt with in Frankfurt?
UX management – How will the interface differ across languages? Too many times, I have seen overly complex initial recording screens that have far too many fields on them that are mistranslated. Worse, many defaults that are never changed clutter the screen, absorbing unnecessary attention from the Service Desk Agent. Another issue is that defaults are nothing but, meaning the Service Desk Agents must change them to the correct ones, wasting more time. You don’t want Joe worrying about what the fields Vorfall & Wissen mean. Simplicity is key; the fewer fields, the better. One must only have the essential ones.
Computer Telephony Integration – Often there isn’t any! A Service Desk Agent in a GEWSD should be able to pick up the telephone, and the ITSM automatically commences creating a ticket, pre-filled with the details of the user calling from the Global address list. You don’t want Joe & Jurgen wasting time asking a stressed user for their details before they can start resolving the incident.
History management – once the Service desk agent answers the call and the ticket is pre-filled, the tool should display all current and possibly all closed incidents and service requests for the user who is calling. Too often, time is wasted by Joe having to track down the existing ticket that the user created with Jurgen several hours ago.
More often than not, a user is calling about a Service Request. Many legacy tools were created before ITIL strictly separated Service Request Management from Incident Management in 2007. They then poorly implemented the Service Request Management and only as an afterthought considered creating a Service Catalogue. These flawed processes should be a warning to any prospective buyer. Separating Service Requests from Incidents and then optimizing and automating the management of these service requests is key to an effective and efficient Service Desk. As an example, the creation of users is still a manual process in many organizations, which, when we know that this whole process can be automated, is a waste of precious resources. Tools that allow for the creation of automated processes enable the Service Desk Agents to focus on dealing with Incidents, improving the first-time call fix rate and achieving greater job satisfaction, which in turn results in lower turnover rates in the Service Desk. Joe and Jurgen, being well-trained Service Desk Agents, don’t want to spend half their time transferring a user’s details for an account order from one system to another.
More articles have been written about Knowledge Management than there have been successful implementations of Knowledge Management in Service Desks. The Service Knowledge Management Systems (SKMS) allow for faster resolution times, consistency in support and preserve organization knowledge that then goes on to improve the speed of training new Service Desk Agents.
However, the creation and management of SKMS hit the common pitfalls. Often, management, rather than Service Desk Agents, try to define the objectives of the SKMS, without realizing that the Seven Principles for managing knowledge have a major effect on the population and maintenance of the SKMS.
Knowledge can only be volunteered, it cannot be conscripted. Thus, the simpler it is to enter and read items in the SKMS, the more likely Service Desk agents will update it and use it. An over-complicated SKMS is just as bad as an over-complicated Incident ticket interface. Joe and Jurgen will not enter new knowledge or look for knowledge if the UX is so bad that it is not worth the effort.
The unsung heroes of ITSM — the service desk agents, the Joes and Jurgens of this world—deserve tools that empower, not impede. Shiny interfaces and fancy features mean little without practical functionality and thoughtful implementation. Consult the agents, understand their needs and prioritize user experience over superficial appeal. A seamless ITSM tool can reduce stress, improve efficiency, and ultimately increase job satisfaction. In the end, investing in those who hold your service desk together isn’t just humane — it’s smart business. After all, happy agents make for happier end-users, and isn’t that the ultimate goal?