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.
This is a great article, and it has me thinking. I agree that it has it’s merits, however this would require a lot of work with the customer and support organizations to remodel the services provided. To get them to agree, there would need to be some metrics captured and presented showing how this will improve either the level of support, timeliness of resolution, or reduce the cost of support as the customer will be taking on some of the “traditional” support organizations work.
I think you are perfectly correct, Don. The key thing is the metrics, having some objective means of assessing different approaches. And getting people to think about new approaches.
Two comments.
First, this reminded me of some academic research that I came across not so long ago. You could summarize it as
– Poor IT skills cause significant productivity losses
– Managers don’t know or don’t care about their staff’s IT skills
– Staff don’t know where to get help and learn more from co-workers than the service desk
The researchers are Van Deursen and Van Dijk at Twente University in the Netherlands and here are some of their findings:
6-10% productivity loss is caused by IT, of which half by poor use
47% of managers have no insight into their staff’s IT skills
41% of managers consider their staff’s IT skills insufficient
35% of managers do not invest in formal improvement of IT skills
48% of staff take no initiative to improve IT skills, say managers
71% of staff are not monitored for adequate IT skills
25% of staff say their IT skills are insufficient
61% of staff are uncertain that IT help is available
59% of staff get help from co-workers
44% of staff learn more from co-workers than the service desk
While this doesn’t solve any problems, it gives valuable insight into the status quo, the need for a business case for improvement, and finally the preconceived ideas and therefore resistance that may be encountered.
My second comment, albeit straying slightly from the service desk, is because the super user is usually reactive, I like to promote the concept of a super duper user, who keeps a proactive eye on how users are using the systems or, put in an economic perspective, how they are realizing value from the investments in I&T. Because that’s what users are there for, to realize value. The IT function only creates potential value.
Hi Robert,
you are right in environments without Superusers should think of adding them to their support mix. What do I mean with “support mix”? If you take a closer look at the support chains of different companies, you find a lot of different concepts. Service Desk as a single point of contact is very common, but other teams, scope, etc. is still very different.
There are companies focussing on Superusers, Key Users for example because they are spread into hell a lot of small offices around the world, means a proximity service contract is very cost intensive. Ther typical examples are as you mention, companies with a strong IT integration e.g. logistics.
You mentioned some of the advantages of superusers, let me add some known disadvantages of superusers.
– They tend to define their own scope of support, some of them develop into 100% support employees, other focus on their individual field of business referring 95% of the cases to the Service Desk
– Handover e.g. in vacation times can create issues
– Some of them tend to not log quick fixes, which causes unfixed root-causes
– Super users usually have higher salaries than service desk agents, not handing over simple requests causes losses in efficiency
Best Regards
Werner
@Marc, when the study shows that:
47% of managers have no insight into their staff’s IT skills
41% of managers consider their staff’s IT skills insufficient
is it saying that among the 47% without insight that 41% nonetheless consider the skills insufficient; or is it saying that 41% of the remaining 53% (who have some insight) consider it insufficient?
Be that as it may, there will always be a gap between what users can achieve using IT services and the intentions and expectations of the providers and consumers. For me, the question is how to address that gap most effectively and efficiently.
@Mark, regarding your second comment, I fully agree that the customer needs to be proactive and needs to have its own continual improvement initiatives in place. The superuser certainly would have a lot of input to give to those initiatives, and might also play both a support and an improvement role.
Hi Robert
I see Super User (SU) as an additional element in the support model rather than a replacement of another i.e. the service desk. This seems to be a well-known and established concept.
I am with Werner about pros and cons of SUs.
And I am with you in that having Service Desk take care of all user issues instead of filtering them through a near-business layer of SUs, is a less than optimal solution.
First step should be to implement the SU concept in order to unload some appropriate work from the Service Desk. I would see this as a kind of pre-ITIL level of request and incident management i.e. done within the business line before even hitting IT (through Service Desk).
Some risks I see/have seen with SU concept:
– commitment by the Business organization: SU concept requires some investment as per below points
– missing formal role profile for SUs: need training and a time budget for their SU role
– unclear organization and management of SU: need some coordination between the SUs in different locations, business units etc. Suggest some matrix organization between their normal management line and a dedicated SU organization. The following points relate to such SU organization:
– logging of requests (or incidents?) by SU to be agreed: can imagine models with and without logging. Knowledge collection and maintenance within the SU population will be influenced by decision either way.
– documentation of common issues and solutions to be agreed: would easily be based on logging of requests, again influencing Knowledge management
– high end user (and hence SU) turnover threatens level of Knowledge in the SU organization
– direct contact to the technical support organization (another old topic of course): need to agree some “quality criteria” for the callers (SUs) in order to prevent flooding of the tech.organization with “unqualified calls” which would again have a cost impact then.
Great article indeed,
Challenges I see is the maturity level of the company and the ‘resistance’ or ‘willingness to do more’ of the Business.
But yes, this is for sure a more efficient model going in the direction of ‘flow’ and ‘agile’ much more then the ‘traditional’ ITIL f.ex approaches.
Another challenge is how to handle the superusers request going directly to the support teams (figure 4&5) The point here is ‘disruption’ of project work carried out, so may cause other inefficiencies. Definition off urgency vs importance comes to my mind….
Robert, you have provided quite a powerful argument for this model for supporting application software. Many service desk calls relate to end user devices, networking, and other infrastructure aspects that might not be so well served by business focussed super-users.
@Stuart – I think we need to split the cases between support for devices at the users’ workplaces and support for other types of devices, such as active nodes on a network. I agree with you that superusers are not likely to be of much help in resolving the latter cases.Then again, end users do not interact with such devices, so the diagnosis and resolution is best left to the technical people. I suppose there may be some cases where the first line of support resolves such issues as network failures, but I have never worked with such a company myself. Nevertheless, I think you are pointing out the need to tune the support model according to the distribution of skills in the organization.
As for the former case, where end users can detect by themselves device issues (such as personal computing device issues), this is precisely the sort of case to which I was referring when I said we need to distinguish the administrative work of a service desk from the sorts of support that is normally resolved at the first line of support, without escalation. I fully agree that this sort of support stills needs to be provided, whether it is provided by a dedicated workplace support team, or by people in cross-functional teams. The question is whether a pragmatic exception should be made wherein any user with such an issue could contact the service provider directly, without going through a superuser. I think there is room for such exceptions and would not like to insist on a dogmatic application of the SPOC principle.
Hi Robert,
I see the same need of having role(s) like superuser sitting on business side, that might be a first contact point for end-users. They can help others in business organization not only in case of issues with business process, but also IT related stuff. This depends on level of knowledge that IT and business are willing and can share. This needs to be aligned. This approach shifts the work from IT to business. More specifically, superusers can do what 1st line support does, 1st line can take then activities from the 2nd line and so on…
Regardless to the above, there are some potential issues and risks we must be aware. The first I see, is the responsibility boundary of the supersusers. I can image some IT organizations would try to push out as much work as possible, which might harm the business quite hard. The second thing, what if that superuser left the business organization? Who will make sure proper knowledge transfer, skill transfer is done? Does it mean we should involve superusers also in other IT(IL)processes, especially in Knowledge Management?
I’m interested to see other opinions.
Kind regards,
Jakub
I think you are right on the money, Jakub.
Regarding “…some IT organizations would try to push out as much work as possible, which might harm the business quite hard”: the motivation for this change must not be to get your customers to do your work for you.
Regarding “…what if that superuser left the business organization? Who will make sure proper knowledge transfer, skill transfer is done?”: that’s true for any role in any organization, which is why we need to think in terms of “roles”, not in terms of individuals with jobs. It also depends highly on how an organization embodies its knowledge. We all know the problem of tacit knowledge lodged only in peoples’ minds.
Regarding “Does it mean we should involve superusers also in other IT(IL)processes, especially in Knowledge Management?”: For sure, yes. But this is already very common. For example, when the manufacturer/editor or a product sends out bulletins about known errors in its product, this is shared knowledge management. There is also an argument in favor of cross-entity change management (which, by the way, is exactly what ITIL recommends). For example, if a change on the supplier side might invalidate a workaround devised on the customer side, it would be better to identify the issue before the change is implemented.
Robert great article. It makes us all think on the effectiveness and efficiency of the Service Desk function. Same applies to all comments so far made. Super User concept has been well proven. It has locally turned into a big relief for the Service Desks and increase user satisfaction. Though I have the impression your paper and the responses very much focuses on internal IT. From an external service providers perspective the Service Desk is the entry point for all customer concerns. The bulk of the workload comprises of Service Requests rather than incidents. The Service Desk peers with the Service Desks of the customer and the SD of other outsourcing partners of the same customer. Giving up this function is rather unthinkable in that kind of environment. What I would undoubtly agree on is that there is agreat deal of inefficiency and room for improvement
Your comments are very astute, Rainer. One can imagine an internal service provider without a service desk (whether you think it a good idea or not). But it is more difficult to imagine an external service provider without a centralized way of receiving support requests from customers, because we do not like to make our internal structure visible to external customers. And yet, many of the external service providers I use simply have no service desk at all. If I need support, I express my issue on a forum and hope that someone can answer me. And if something is really going wrong in the service, the provider seems to be able to figure it out without depending on users to inform it of the issue. All this makes me wonder if service desks, such as they exist today, are either great luxuries with which we can easily dispense, or if they are signs of service systems that are so poorly conceived that they simply cannot be used without that additional layer of support.
I think that most organizations have some kind of super user organization in place, officially or not. The problem with super users is that their availability is often poor. One of my customers studied their SU organization and the results showed that there was a wide variety in the way people acted in the role. Some spent 100% of their time in it and some only 1%.
I have been advocating a different solution. MPOC is multiple point of contact and the idea is to direct people to the right contact person via the support portal. The persons may sit in one SD or in several.
The use of self help and social media is also very important. Phone call should be the last resort.
I agree with your analysis, Aale, so long as we remember that you are speaking of a current reality rather than a desirable future. If it were part of the avowed and contractual mission of someone to support users in his or her own organization, then we wouldn’t be talking about this activity as if it were purely voluntary and optional. We wouldn’t say that a service desk is a bad idea because some agents don’t work very hard.
In short, I think your point leads us in the direction of having a completely informal type of support among colleagues, support that never really appears in anyone’s record of support needs, and formal support provided by a member of your own organization, following all the good practices that we expect any support agent to follow.
Last, I would like to remade the question: What kind of Service Desk we really need (according with customers features)?
Robert,
If service desk administrative activities can be flagged as non-value adding, then why not simply quit them without losing all the benefits from the service desk structure?
To answer your question “Do we really need service desks?”: yes we do, just like we do need super users.
Your way of defending a general mind shift only relates to very specific situations, where support organizations are set up along the lines of the services they provide – with all the well-known inefficiencies of those silo-type organizations…. Your highest-ranked figure 5 clearly shows that there are only support requests between a user and one specific support team.
EQ is known to be far less available among 2nd and 3rd line techies as among trained and selected service desk staff.
A service desk can focus on many knowledge and administration related issues because of their volume. A super user cannot – unless he actually is a service desk employee.
2nd and 3rd line specialists hate administration. I do not believe you could ever get them to the same job as is done by the service desk.
A service desk acts as a buffer for impatient users. It improves the efficiency for all 2nd and 3rd line experts and allows them the opportunity to continue with their work without constant interruptions. The Theory of Constraints clearly illustrates this.
Service desk staff can be trained in interdisciplinary knowledge, super users normally cannot. This is the typical Economy of Scope benefit that a service desk has, compared to the super user.
If users are depending on super users, these should always be available – given the fact that these users depend upon the availability of IT for their business. The services desk offers the Economy of Scale benefit for just that, a super user organization could only *try* to do the same….
All in all, I think your plea does not hold for the large majority of cases. It may illustrate a benefit for some specific silo’d organization types, but they pay the price for it.
Note: I am absolutely not against super users. They are an essential role in my view on setting up service organizations. But your entire analysis relates to ‘organizing the work’ and I firmly believe that **organizing is optimizing**, so the ‘best structure’ will always depend highly on local conditions.
Super users will most likely find their place in all organizations, just like service desks. Saying that one of both should be preferred above the other is a statement that I cannot subscribe to.
Jan, your remark about service desk acting as a buffer is precisely the sort of reasoning that led me – perhaps too rashly – to cast doubt on the added value of a service desk. The value of a buffer in front of a capacity constrained resource is well understand. The disadvantage of the service desk is that is forces the existence of that buffer whether the people who do the real work are capacity constrained or not.
What is important is not my opinion or your opinion, but objective facts that support one view or the other. I hope that by raising my question, we can start to get those objective measurements, instead of relying on the force of opinion and on statements like, “it is well known that…”
Robert,
I appreciate a challenging statement! Please continue writing blogs like these 😉
If your issue is that workload distribution is not managed well by means of a service desk, then you could simply automate this, and have the service desk staff concentrate on the beneficial elements of their work. Just have a look at products that support the theory of constraints in managing support calls, and you’ll solve most of the issue. Tools like that can easily be combined with help desk tools and deliver great results.
These tools are normally used in disciplines outside of IT. We’ve actually done the first application of such a tool in an ITSM environment the Netherlands some time ago, with great results. The showcase was then visited by other organizations, and demand for this tool is growing fast.
So you see, again, you can hold on to the beneficial contribution of a service desk, remove practical obstacles if they do not function well enough, and combine this with a super user structure, to get an optimal result….
I do, in fact, have some underlying issues which I will address in more detail in another posting. I had not been thinking of workload distribution. though. Your intuition in citing the theory of constraints is partially correct, though, insofar as I am looking at ways to optimize the overall flow of work. The particular issues I will address in the future are not those of constraints, but rather issues of prioritization, customer alignment and flow. Thanks in advance for your patience.
In my opinion, the proposed model is only fundamentally distributing and embedding service desk function across and within business units (BU).
While it unarguably has the advantages of closeness to users and possibly, deep knowledge of BU applications, some questions arise
a. Will using Super User (SU) resource as the first points of contact for BU incidents resolution represent the best utilization of the resource? As in my experience, SU’s are usually highly experienced members of the BU.
b. Can the SU resource be available to resolve incidents at all time, given his/her other responsibilities, holiday and other planned & unplanned absence?
c. Who will this resource be accountable to, BU or IT?
Seyi, you might be right about super users being highly experienced. I would think that sharing their knowledge and experience with their colleagues would be an excellent investment.
I will make another analogy to an area I know well, tertiary education.
The most important point for the customer is the quality of communication established, from a person to a person.
The relationship is bijective, the teacher learns as much of the student that the student learn from the teacher (that is the hope of the teacher).
In this context, it is preferable to have the structure 1 to 1:
A teacher A student
Given the economic reality, we often get:
A teacher 200 students
or
1 student <- 1/200 of a teacher?
Of course the understanding ratio depends largely on the quality of the teacher:
– Hyper teacher, expert in his field
70% comprehension
– Beginner teacher, release in an amphitheater
30-45% comprehension
To return to the area we are concerned, the IT support.
Classical vision
1 user Service Desk
2 Service Desk Support team
3 Support team Expert team
Logically, at each level of interaction, there is a possibility that the information transmitted is wrong, incomplete or completely unrelated to the problem.
The proposal of Robert:
1 user superuser
(all other interactions are hidden for the client)
Two factors are not taken into account in these models:
– Documentation (RTFM)
– Collective intelligence (Google Is Your Friend)
Ideally, the process is:
– The user fails to do something and needs help
(he has already read the manual and already searched Google)
=> We have to go there (virtually)
or real for the VIP
=> The problem is discovered
(which rarely corresponds to the initial request for IT point of vue)
=> The solution found (RTFM, Google Is Your Friend, maturity in the field, experience, 2nd and 3rd level support)
==> the client is happy (the most important part of the process)
This solution is already implemented in Apple Store with process of Genius Bar, very impressive service (and probably the most efficient service I got in my life).
As I am very optimistic, this is the method I try to practice:
– Be a superuser
– Always work as a Team of superusers (to avoid human SPOF), minimum 2 superusers
– Document, continually update the documentation with the new experiences
– Avoid going in circles (user => Klein bottle or Möbius strip)
[Service team 1 -> Service team 2 -> Service team 3 -> Service team 1]
– Sometimes admit that there is no solution (which immediately leads to the passage from the expert status to the village idiot).
– 2nd degree, teach how to become superuser
This method almost works, because I work in an academic environment, where everyone there thinks and finds solutions.
Laurent, I think you correctly point out that support solutions need to be tuned to the culture of the organization. There are a lot of organizations such as the one of which you are thinking, where IT provides essentially what we might call technical services, such as data transport and routing. The use to which the customer puts that service is entirely his or her own responsibility, and therefore the support needs to be largely of a self-service nature. Of course, IT will need to provide support if there is an issue with the technical services that it does provide.
All very well to talk about the super-user assisting with IT – however when the super-user is working on IT problems who is doing the job of the super-user??? In this day of cost-saving there is LESS resources as it is, and now you are suggesting to reduce even further the resources in the business undertaking the business activities.
The predominant issue with the service desk as described in your article is that the processes, skills, tools and culture have not been implemented effectively or in alignment with business objectives. If a service desk is implemented with a strategy and business insight it works perfectly well.
David, I do not think I am suggesting that at all. I am not proposing that super users, such as they currently exist in organizations, take on more and more support tasks, in addition to whatever other work they might have. If the administrative function of provider service desks were moved to the customers, then clearly the customer would have to reorganize its personnel differently, not just tell everyone to work more.
Nor is my point that organizations are ineffectively implementing service desks. Some are and some aren’t. I will develop in a subsequent posting the underlying issues of why it is better to move the administrative support function to the customer.
Great article. How different is the SU than a Business Relationship Manager? I think this is the same structure, only that the BRM would be in the IT side of the organization. I see a limitation of the SU being embedded in the Business: they would not have a portfolio view of the organization. This can lead to silos, and not leveraging solutions that might already be available, For example, if a Finance SU identifies a need for a database solution, how do we capture the fact that HR also has a similar need? Does this model assume that the Finance and HR SU will be consulting with each other regularly?
BRM’s under the service provider umbrella will be in a better position to prevent silos and leverage existing solutions. Thoughts?
I don’t see that support personnel belonging to a customer organization would necessarily lack a portfolio view of the services being used by the customer. That would depend on how the customer organization defines those roles and encourages and develops the breadth of knowledge of its personnel. I would not expect them to have a portfolio view of individual service provider’s offerings. They would need to know the specific services being used. If, however, any given issue goes beyond those services, this would be a question for the service provider to resolve, not for the customer.
As for the relationship between providing support and managing the relationship with third parties, as well as specifying and buying services and tools, I suppose that depends entirely on the size and complexity of the organization. If it is large, with distinct people playing these various roles, then clearly they need to be in communication with each other. But, as far as the support role itself is concerned, I think it can be performed very nicely without also having to manage the overall supplier relationship and specify and buy new products.