I have recently been investigating provocative and heretical ideas. Among them are the very hard questions concerning radical service provider reorganization. I have found that some of the reasons why service desks have been valuable contributions to service provider organizations are perhaps no longer justified. I would like to start a discussion around this question: Do we really need service desks?
Using a service desk is a compromise. On the one hand, it provides a centralized way of tracking and advancing work on support requests from users. It provides a node for gathering and institutionalizing certain types of knowledge about services and how to support them. It requires emotional intelligence skills that are not always cultivated among people managing technologies. And it provides a localized interface, with appropriate linguistic and cultural knowledge, to support users from many different backgrounds.
These uses and benefits come at a cost. Before I describe that cost, let me first distinguish between the role of the service desk as described above, and the role of the service desk agent as the final, internal, line of support for many types of issues. These latter issues are typically concerned with supporting the user workplace, using the various individual productivity tools and so forth. For example, in many organizations if a user has a support requirement for spreadsheet software, the service desk agent is the expert in the area. Either the service desk resolves the issue on its own or escalates it to an external party. In this role, the service desk is just like any other team, having its own special knowledge, tools and support responsibilities. The only difference is that the service desk also plays an administrative role regarding all support requests that pass through it.
I underline this quite evident duality in the service desk because the following discussion only concerns the administrative role. That is, the following analysis only concerns the role of registering support requests, classifying them, assigning them, tracking them, cleaning up the records after resolution, getting user feedback and closing the requests. Do we need to pay this price in order to have the benefits of a service desk? Let’s examine each aspect of the administrative role to see if there might be a different way of working that obviates the need for a service desk.
Service desk as single point of contact
Users should not need to know about the internal structure of a service provider in order to get support from that organization. A service desk provides a single point of contact for the users, who need only know how to get in touch with the service desk to access any type of support required.
This sounds reasonable if every user has the right to contact the service provider directly for support. I believe that a far superior way of working is to require users to first contact not the service provider, but a role within the user’s own organization. That role would derive its responsibility from the owner of the business process that is using the provider’s service. For example, an accountant might encounter an error while using accounting software. The first line of support for the accountant should be someone in the finance department, not someone from the organization providing the accounting software. We might think of this role as a superuser. Why should we prefer this approach?
A large chunk of support requests really have nothing to do with the supporting service, per se. Instead, they concern how to use that service in the context of a business process. In such cases, the business process owner is a much better source of authoritative information than the software or service provider.
If the support request really concerns the software (or other aspects of the service), it still makes sense for the users to first contact a superuser. Why? Because the knowledge of support issues should be held by the people requiring the support. If a light goes out in my home, do I immediately call the electrical utility for support? Of course not. First, I check for a burned out bulb. Next, I check for a blown fuse or tripped circuit breaker. If I still cannot solve the problem, I might look around the neighborhood to see if the neighbors also have the same problem. Only then, do I call an external provider for support. By keeping the first line of support close to home, I gain the knowledge and skills I need for the vast majority of simple fixes, applied rapidly and effectively. In addition, I know for myself how reliable the service is and which components tend to have problems. I do not depend on the service provider to provide me with support statistics, statistics that often don’t seem quite right. Witness the age-old conflict between the level of availability reported by the provider and the levels seen by the users.
Furthermore, many types of support are effectively addressed via workarounds. There are fundamentally two types of workarounds: the ones that involve temporarily changing the customer’s business methods and the ones that involve changing the way in which the customer uses the provider’s service. For the first case, the customer organization is much better positioned to determine the workaround than any service provider. For the second case, the knowledge about the workaround could be split between the provider and the customer. And even if the workaround needs to be devised by the service provider, the user really only needs to get that support the first time that type of incident occurs. If it recurs, the users are better off if they already know the workaround themselves, or get the workaround from colleagues in their own organization (so long as that workaround remains valid, of course).
Finally, by assigning the first line of support to the users’ organization, rather than to the service provider’s organization, the issue of providing a single point of contact becomes much less important. Only the superuser role needs to know how to get support from the service provider. Even more importantly, the superuser should know specifically how to contact the relevant support team at the service provider without having to slow down the support process and increase the administrative burden by going through a service desk.
That last assertion needs some qualification. If a superuser is responsible for supporting accountants in his or her own organization, that superuser will know how accountancy is supported by the service provider. She will know what the tools are, the service levels, the people specifically involved in managing the accounting service. But, you might say, how does the superuser know if the issue concerns an application, a database, a service, a network segment, a load balancer, or any other component of the service system? The answer, of course, is that they do not have this knowledge. But neither does the typical service desk agent! The user organization could make precisely the same escalation as the service desk, thereby cutting out the middle-man. What’s more, there would be less risk of mis-assignment, because the superuser would need to know only a very few support teams at the service provider, whereas the service desk agent needs to know the entire provider structure (at the very least, at the 2nd level of support). For example, an accountant superuser would not need to know how to escalate an issue that concerns a human resources service.
I might add that a service provider organization structured according to the services it provides, rather than according to the technologies on which those services depend, would simplify even more the support process. Suppose a single team at the service provider were responsible for all aspects of financial services, whether it concerns applications, databases, servers or any other required components. The superuser for the accountants would only have to know how to contact that team, which is a de facto single point of contact for its customers. I have examined the benefits of structuring an organization this way in my presentation Cross-functionality, Kanban and service design.
Service desk as a source of knowledge
You might argue that a service desk has the benefit of handling support needs for all customers. It is therefore able to extract knowledge from supporting one customer and apply that knowledge in supporting all the other customers. I fully agree with this. But I disagree that it is the role of the service desk to manage the knowledge that is proper to other support teams. For example, there might be a certain type of recurring incident in a certain application. The team responsible for that application needs to identify, record, manage and maintain the knowledge relative to that application. The service desk should not do this work in its place.
The ability to share that knowledge with the customers of the service provided by the application remains important. We do need to have the right tools in place. But we do not need to have the service desk as an intermediate conveyor of that knowledge.
Service desk as tracker of support
I include under this rubric all the issues concerned with ensuring that user support moves forward on a timely basis and respects all the service level engagements between the service provider and the customers.
I do not deny that many organizations have difficulties in performing their work quickly and effectively. But using a service desk to track and to hound service support personnel who do not do their work on time is very ineffective. It hides, rather than solves, the issues underlying inadequate performance. Very frequently, support personnel are put in the impossible situation of having to work on many different issues at the same time. Having a service desk agent nudgering them every 30 minutes is extremely annoying and distracting. It might be better to have only a single service desk agent calling for periodic updates, as compared to a situation when any user could disturb a support person with complaints and questions.
Fortunately, there are alternate approaches to organizing work that allows us to dispense with such tracking. Working according to a Kanban approach provides full visibility of all work in progress. The Kanban approach is already heavily focused on identifying and managing blocked work items. Using a Kanban board makes progress on the work fully transparent and automatic, thereby eliminating any need for the command and control proxy role that some would assign to the service desk.
Service desk to assure quality
Many organizations, when using the typical ticketing systems for managing support, have a continuing issue with the quality of the information recorded in the tickets. In some organizations, the service desk is assigned the role of reviewing tickets after the issue is resolved, correcting errors and reformatting the information in a more understandable format. At the same time, the service desk might assign some form of closure code to the ticket.
I have no complaint if the service desk wishes to work in this way regarding the work items it handles on its own. But I would prefer to look at the underlying causes of the need for such review and correction, rather than institutionalize the practice of allowing poor data collection that is corrected in a second, wasteful, step.
I have argued elsewhere (e.g., A New Architecture for IT Service Management Tools, A Manifesto for Service Management Tools) that the commonly used architecture of service management support tools is primitive, at best, and is itself a cause of many of the difficulties in using those tools. The time is long past that we need to stop haranguing support personnel for failing to use these tools as required. We need to start providing them with appropriate tools.
The service desk and emotional intelligence
I used to work at a company where the IT support personnel would regularly return to the IT office and complain about how stupid the users were. Those support people might have had a redeeming feature, if only they were technically competent. Be that as it may, they did not have the skills needed to support people.
The emotional intelligence required to deal with people seeking support is often in short supply. Indeed, that same intelligence might go a long way toward improving how technical teams interact. But the key issue is that respectful mindfulness is an attribute needed for the support role, whether it be provided by a service provider’s service desk agent or by a superuser at a customer’s organization. The presence of these special skills for supporting users might make a qualified service desk better than an engineer who is more at ease with a machine than with an irate user. But those same skills would need to be present no matter who provides the first line of support to end users.
The service desk and cultural differences
The service desk, be it local, centralized or other, is often justified by the need to support users with different cultural baggage and different languages. I used to work for an organization that was present, so it was said, in 188 of the 184 countries of the world. We were painfully aware of the need to communicate in many different tongues with people of many different mentalities.
Isn’t it much simpler for the people providing the first line of support interface between the service provider and the user to be parts of the same organization as the users? There is no advantage in trying to centralize the burden for finding people with the right languages on a service desk organization.
Let’s rethink the provider organization
We have identified four options for organizing support:
Fig. 2 shows the worst case for most organizations. Fig. 3 shows an improvement over Fig. 1, by virtue of a service desk as single point of contact. Fig. 4 shows an additional improvement, by eliminating the service desk as a single point of failure. Fig. 5 shows the simplest, most robust and most efficient structure that is fully aligned to the services and the customers of those services. I do not show a variant with both superusers and service desks. Such a structure is probably superior to a service desk without superusers and could be used as a transitional phase to superusers without a service desk.
Rather than assuming that the internal, administrative service desk that I have been describing is an eternal and immutable best practice, should we not scrutinize the assumptions underlying that wisdom? Should we not examine, from time to time, if new ways of managing work, new tools, new ways of understanding support make those assumptions outdated? If we were to do a lean analysis of the support activity, would not the service desk administrative activities be flagged as non-value adding?
Let’s start to measure objectively if using a service desk is really the best approach. Just because a service desk might be better than what we did in the past does not mean we cannot continue to make major improvements in supporting our services. Let’s not fall into the trap of the doddering old general who plans for the next war based on the results of the last war.
I will follow up on this concept in future posts, where we will see how using superusers and cross-functional support teams allows us to improve how we prioritize and resolve incidents in a more rational way.