Which Is Usually True Of Small Service Desks?

I have recently been investigating provocative and heretical ideas. Amid them are the very hard questions concerning radical service provider reorganization. I take constitute that some of the reasons why service desks accept been valuable contributions to service provider organizations are possibly no longer justified. I would like to start a discussion around this question: Do nosotros actually demand service desks?

Using a service desk is a compromise. On the one manus, information technology provides a centralized way of tracking and advancing work on support requests from users. Information technology provides a node for gathering and institutionalizing certain types of knowledge about services and how to support them. Information technology requires emotional intelligence skills that are not e'er cultivated among people managing technologies. And it provides a localized interface, with appropriate linguistic and cultural knowledge, to back up users from many dissimilar backgrounds.

These uses and benefits come at a toll. Before I describe that cost, let me first distinguish between the role of the service desk equally described above, and the role of the service desk agent equally the last, internal, line of support for many types of issues. These latter issues are typically concerned with supporting the user workplace, using the various private productivity tools and and then forth. For instance, in many organizations if a user has a support requirement for spreadsheet software, the service desk-bound agent is the expert in the surface area. Either the service desk resolves the upshot on its own or escalates information technology to an external party. In this part, the service desk-bound is just like any other squad, having its own special knowledge, tools and support responsibilities. The just 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 simply concerns the role of registering support requests, classifying them, assigning them, tracking them, cleaning up the records after resolution, getting user feedback and endmost the requests. Practise nosotros demand to pay this price in social club to accept the benefits of a service desk? Let's examine each aspect of the administrative role to run into if there might exist a different way of working that obviates the demand for a service desk-bound.

Service desk every bit single bespeak of contact

Users should non demand to know about the internal structure of a service provider in order to get support from that organization. A service desk-bound provides a unmarried indicate of contact for the users, who need just know how to get in touch with the service desk to access any blazon of back up required.

This sounds reasonable if every user has the correct to contact the service provider direct for support. I believe that a far superior way of working is to crave users to showtime contact not the service provider, but a role within the user'south own organization. That part would derive its responsibility from the possessor of the business process that is using the provider'south service. For example, an accountant might encounter an error while using accounting software. The offset line of support for the accountant should be someone in the finance department, not someone from the organization providing the bookkeeping software. Nosotros might call back of this office as a superuser. Why should nosotros prefer this approach?

A large chunk of support requests really have nothing to do with the supporting service, per se. Instead, they business organisation 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 administrative 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 showtime contact a superuser. Why? Because the knowledge of support issues should be held past the people requiring the support. If a light goes out in my habitation, do I immediately call the electrical utility for support? Of class not. First, I bank check for a burned out bulb. Next, I bank check for a blown fuse or tripped excursion breaker. If I still cannot solve the problem, I might look around the neighborhood to run into if the neighbors also accept the same problem. Only and then, practise I telephone call an external provider for back up. Past keeping the first line of support close to dwelling, I gain the knowledge and skills I demand for the vast majority of elementary fixes, applied rapidly and effectively. In addition, I know for myself how reliable the service is and which components tend to accept problems. I practice not depend on the service provider to provide me with support statistics, statistics that often don't seem quite right. Witness the age-onetime disharmonize between the level of availability reported by the provider and the levels seen by the users.

Furthermore, many types of support are finer addressed via workarounds. There are fundamentally ii 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 client uses the provider's service. For the beginning case, the customer organization is much better positioned to determine the workaround than any service provider. For the second case, the knowledge well-nigh the workaround could be divide between the provider and the customer. And fifty-fifty if the workaround needs to be devised by the service provider, the user really only needs to get that support the first fourth dimension that blazon of incident occurs. If it recurs, the users are improve off if they already know the workaround themselves, or get the workaround from colleagues in their own arrangement (so long as that workaround remains valid, of grade).

Finally, past assigning the start 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 become support from the service provider. Even more than importantly, the superuser should know specifically how to contact the relevant support team at the service provider without having to slow down the back up process and increase the administrative brunt by going through a service desk.

That last exclamation needs some qualification. If a superuser is responsible for supporting accountants in his or her own organization, that superuser volition know how accountancy is supported past the service provider. She will know what the tools are, the service levels, the people specifically involved in managing the accounting service. Only, you might say, how does the superuser know if the result concerns an application, a database, a service, a network segment, a load balancer, or whatever other component of the service system? The respond, of form, is that they do non have this knowledge. Simply neither does the typical service desk-bound agent! The user organization could make precisely the same escalation as the service desk-bound, thereby cutting out the heart-man. What'south more, in that location 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 instance, an accountant superuser would not demand to know how to escalate an consequence that concerns a human resource service.

I might add that a service provider system structured according to the services information technology provides, rather than according to the technologies on which those services depend, would simplify even more the back up procedure. Suppose a unmarried squad 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 merely have to know how to contact that squad, which is a de facto single bespeak of contact for its customers. I take examined the benefits of structuring an organization this way in my presentation Cross-functionality, Kanban and service blueprint.

Service desk as a source of cognition

You lot 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 cognition in supporting all the other customers. I fully agree with this. Only I disagree that it is the role of the service desk to manage the cognition 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 cognition relative to that awarding. The service desk-bound should not practise this work in its place.

The ability to share that knowledge with the customers of the service provided past the application remains of import. We do need to have the correct tools in identify. Simply we do not need to accept the service desk as an intermediate conveyor of that noesis.

Service desk-bound every bit tracker of back up

I include under this rubric all the bug 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 non deny that many organizations accept difficulties in performing their work quickly and effectively. But using a service desk-bound to rail 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 oftentimes, support personnel are put in the impossible situation of having to work on many unlike bug at the same time. Having a service desk agent nudgering them every xxx minutes is extremely annoying and distracting. It might be amend to accept only a single service desk agent calling for periodic updates, equally compared to a situation when any user could disturb a support person with complaints and questions.

Fortunately, there are alternating 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 piece of work items. Using a Kanban lath makes progress on the work fully transparent and automatic, thereby eliminating whatsoever demand for the control and command proxy role that some would assign to the service desk.

Service desk-bound to assure quality

Many organizations, when using the typical ticketing systems for managing support, have a standing consequence 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 fourth dimension, the service desk-bound might assign some form of closure lawmaking to the ticket.

I take no complaint if the service desk wishes to work in this mode regarding the work items it handles on its ain. But I would adopt 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 take argued elsewhere (eastward.m., A New Architecture for Information technology Service Management Tools, A Manifesto for Service Management Tools) that the commonly used architecture of service direction support tools is archaic, at all-time, and is itself a cause of many of the difficulties in using those tools. The time is long past that we demand to cease haranguing support personnel for failing to employ these tools as required. We demand to commencement providing them with advisable tools.

The service desk and emotional intelligence

Support conversation — Fig. 1: Emotional intelligence is often defective in a support situation.

I used to work at a company where the IT back up personnel would regularly return to the It office and complain well-nigh how stupid the users were. Those support people might have had a redeeming feature, if only they were technically competent. Be that equally it may, they did not accept the skills needed to support people.

The emotional intelligence required to bargain with people seeking support is often in short supply. Indeed, that aforementioned intelligence might become a long fashion toward improving how technical teams interact. But the key issue is that respectful mindfulness is an attribute needed for the support role, whether information technology be provided past a service provider's service desk-bound amanuensis or by a superuser at a customer's organization. The presence of these special skills for supporting users might make a qualified service desk-bound meliorate than an engineer who is more at ease with a auto than with an irate user. Just those same skills would demand to be present no matter who provides the first line of support to end users.

The service desk and cultural differences

The service desk, exist information technology local, centralized or other, is often justified past the need to support users with unlike cultural baggage and unlike languages. I used to work for an organization that was nowadays, so it was said, in 188 of the 184 countries of the world. We were painfully aware of the demand to communicate in many unlike tongues with people of many different mentalities.

Isn't it much simpler for the people providing the kickoff line of support interface betwixt the service provider and the user to be parts of the same organisation as the users? There is no advantage in trying to centralize the burden for finding people with the right languages on a service desk-bound organization.

Let's rethink the provider organization

We have identified four options for organizing back up:

Worst - any user can contact any support team. — Fig. 2: Worst – whatsoever user can contact whatever support squad.

Better - Service desk as single point of contact — Fig. 3: Improve – Service desk-bound as single point of contact for users and for back up teams.

Fig. two shows the worst example for most organizations. Fig. iii shows an improvement over Fig. 1, by virtue of a service desk-bound as single betoken of contact. Fig. 4 shows an boosted comeback, by eliminating the service desk equally a single indicate of failure. Fig. five shows the simplest, most robust and most efficient structure that is fully aligned to the services and the customers of those services. I exercise 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 equally a transitional phase to superusers without a service desk.

Even better - Each customer has its own superusers, who contact support teams. — Fig. 4: Even better – Each client has its ain superusers, who contact support teams. Back up teams may also escalate to other support teams

Best - Cross-functional support teams are aligned with customers and contacted by superusers. — Fig. 5: Best – Cross-functional support teams are aligned with customers and contacted by superusers.

Rather than bold that the internal, administrative service desk-bound 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 fourth dimension, if new ways of managing work, new tools, new ways of understanding support brand those assumptions outdated? If we were to exercise a lean assay of the support activity, would not the service desk administrative activities be flagged as non-value adding?

Let's kickoff to measure objectively if using a service desk is really the best approach. Just because a service desk might be amend than what we did in the past does not mean we cannot continue to brand major improvements in supporting our services. Allow's not fall into the trap of the doddering one-time general who plans for the side by side state of war based on the results of the terminal war.

I will follow up on this concept in future posts, where we will see how using superusers and cross-functional support teams allows u.s.a. to improve how we prioritize and resolve incidents in a more rational mode.

Summary

Do we really need service desks?

Article Proper name

Exercise we actually need service desks?

Description

Nosotros should rethink the demand for service desks and retest the assumptions underlying the justifications for service desks.

Author

Robert S. Falkowitz

Publisher Proper name

Concentric Circle Consulting

Publisher Logo