In a previous blog post, Towards Self-Adaptive Service Desk Systems, I identified three basic service desk configurations for the practical management of service requests and incidents. In this article, you will find an overview and further details about these service desk configurations, including recommendations on how to work effectively with them in EriZone. I also describe a fourth configuration, that is often implemented in combination with the other three. As in my other blogs, I don’t focus on large enterprises, which are able to implement the processes proposed by the ITIL library in full detail, but rather on small to medium-size companies with an (IT-) service team ranging from 10 to 50 employees, most of them not working exclusively in service request and incident management.
The four configurations that I will detail in the following are:
I anticipate that often there isn’t a single “best” configuration that will fit your needs. The four configurations can be used as building blocks for a practical and lightweight 2-level support process that is tailored to your organization. In the following I describe them in a concise, structured and comparable way, and highlight some functionalities of EriZone that are useful for each configuration. To help you select the best service desk configuration, we have identified various key properties that an organization should have to be appropriate for a specific configuration, including the average complexity of requests, the number and experience of staff members in the 1st and 2nd level support teams, and the completeness of the documentation.
Here, the aim is to have a skilled 1st level support with a target of 70, 80 or 90% resolution. The second level experts need to help only few times to resolve the remaining complex requests and critical incidents, while keeping the 1st level staff in the loop for communication with the customer.
This configuration is convenient if your organization has:
@Important operations in EriZone:
In this configuration, those tickets not resolved by the 1st level are split to the second level, i.e. a child ticket is created in an experts queue. This child ticket is not visible to the customer, and the experts will only be able to write internal notes, while the service desk staff manages all communication and is responsible for closing the customer ticket.
Here, the aim is to have a 1st level staff that manages the initial contact with the customer, but resolves only the simplest requests and incidents, while dispatching a large number to the second level.
This is convenient if your organization has:
@Important operations in EriZone:
In this configuration, the tickets that need to reach expert support can be split as in the previous configuration. Since this leads to an additional workload for the 1st level support team, a valid option is to move the tickets to expert queues that are configured to allow customer interaction. In this way, responsibility for the ticket is passed on to experts, and thus this choice needs to be agreed among the teams.
Call this one 1st or 2nd level support as you prefer: “1st” probably being the proper one, but “2nd” sounding much better to the experts that give the service.
Here, you have no dedicated 1st level service desk staff. Ideally, requests are automatically dispatched to the right group of experts after classification.
This is convenient if your organization has:
@Important operations in EriZone:
In this configuration the service desk agents themselves are the experts, so they principally need to just ask their colleagues if help is needed. In EriZone, you write Notes to your peers or pass them Ownership of the ticket. They will immediately get notified by email and can also simply reply by email to give an internal response that is not seen by the customer.
In rare cases it might also be necessary to manually move a ticket to another queue, i.e. a different group of experts. However in this case, a re-classification of the ticket would be more correct. If the automated dispatcher moves tickets to the wrong queue, the designated service manager should be contacted to review the dispatching rules.
In such a service desk configuration, you should encourage customers to open tickets via the web interface. If this is not possible, ticket acceptance and classification can be done as a team (acceptable with a small number of tickets) or by a dedicated telephone operator.
Here you have a number of small service desk teams situated in different company locations, branch offices, affiliates etc., as well as a single, centralized expert team for 2nd level support. The on-site service desk communicates with the customer, bridging language and time zone gaps when 2nd level support is needed. This is often the case with IT support in multinational companies.
This is convenient if your organization has:
@Important operations in EriZone:
In this configuration, most of the tickets can be automatically assigned to the local service desks, by using the ticket requestor‘s company or department location (usually from LDAP data) or by using dedicated email addresses. This is a standard feature of the EriZone Dispatcher.
Tickets are split to the centralized 2nd level support. In this way, 1st level support remains the interface to the customer. This is of particular importance with different languages or time zones.
This of course is not an exhaustive list of service desk configurations. Often, the implemented configuration is a mixture of two or more configurations, to meet at best the needs of the organization. Moreover, in this article I did not mention the inclusion of external 3rd level support. So stay tuned for my next blog posts on this topic. If you want to pass on any remarks and suggestions, or to share your experience, please leave a comment below!