For the convenience of the reader, I will divide this article into several semantic parts.
In the first, we will talk about the basic elements of the TP - staffing, application lifecycle, prioritization.
In the second part, we will touch on the issues of maintaining the knowledge of technical support engineers at a given level.
In the third and final part, we'll talk about how to make all of the above work.
I'll talk about motivation, in particular, non-financial, and also give a couple of tips for organizing corporate rewards and punishments.
Support Basics
To organize the work of technical support, you need to answer a few simple questions:
Support for one product (service) is required or we are talking about multi-product support, i.e. support for several completely different products?
What SLA is required for technical support calls?
Do I need to provide 24/7 support?
The first
Single-product support requires a minimum number of specialists. For example, if you expect about ten requests per shift, you can try to shift support to a specialized engineer.
Multi-product support requires either dedicated product specialists or separation of call traffic by complexity, resulting in multiple support lines.
We took the path of dividing engineers according to their knowledge and competencies into three components: the first, additional and second lines of technical support.
Second
The tighter the SLA, the more resources the company will need to comply with it. These are a variety of resources: qualified engineers, information systems, equipment, regulatory documents, and more. Consider the state issue. To meet the SLA requirements, the staff must be proportional to the average number of calls to technical support, taking into account the time and quality standards.
Based on the above, the staff of our engineers is as follows: IT technical support
first line - 10 people;
additional line - 4 people;
the second line - 5 people.
Third
24/7 technical support is not cheap. High-quality execution of this service in 24x7x365 mode will require at least 5 engineers, and this is in the simplest case, i.e. in case of single-product support. If you need to organize round-the-clock support, feel free to multiply the costs by 5. But, first of all, think about whether you really need it (whether you can get by with a self-service portal, etc.). If you still need it - is it possible to outsource it.
Technical support employee of the Miran data center at the workplace
What are all these people doing
The task of the first line engineers is to quickly and efficiently process the client's request. To process means to correctly classify and send to work.
After processing, the engineer of the first line either decides the request on his own, if it is from the section “make it quickly, here and now,” or transfers the request to another line, if it is “long-playing” or it is about “faults”.
The task of the additional line engineers is to work with orders that take more than one day to complete.
The task of the second line engineers is to eliminate faults as quickly as possible and solve complex requests “here and now”.
Engineers work modes
First line: Schedule - 2/2, 12-hour shifts from 08:00 to 20:00.
Additional line: schedule - five days, 8-hour shifts from 08:00 and 12:00.
Second line: schedule - 2/2, 12-hour shifts from 08:00 and 20:00.
Engineer shift schedules are maintained using Google Calendar.
Workplace of a technical support employee
Life cycle and status of applications in TP
The easiest way to trace the life cycle of an application is according to this scheme:
Application life cycle in technical support
I will explain each of the points separately.
Any request received from an external source acquires the new status . The task of the first line engineer is to initially process the received application and transfer it to the contractor.
The open status is assigned to an application when a specialist is busy with a solution.
If the ticket has been identified as spam, it gets the deleted status .
If the ticket is not spam, but also does not contain an essential request to technical support, it is assigned the rejected status .
The resolved status is assigned to the application after solving the problem / problem in the opinion of the contractor.
The stalled status means that the work on the application is temporarily suspended at the initiative of the client or in agreement with him.
The close d status is assigned after the client considers that his task has been successfully completed.
Typification of applications
The type of application is the most important criterion. It determines the reaction speed and time to fix the problem indicated in the ticket. In Miran, according to ITIL, requests are divided into the following types. I list them in order of importance:
Incidents
Incidents include equipment malfunctions and malfunctions, as well as any other events that lead to a significant deterioration in the quality of services. Orders of this type are executed in order of priority and take precedence over other types of orders. Only incidents can be prioritized for processing.
Examples of incidents: service unavailability, hardware failure.
RFS - Service Request A
customer has a service need within the service provided. The request is not related to a failure or failure in the IT infrastructure. It is executed immediately in the order of the general queue in the absence of priority applications.
Example: request to restart the server.
RFC - Request for Change
Request to change the composition and / or volume of services provided to the client. The processing time is determined by the management of the company individually in agreement with the client.
Examples: request to switch equipment.
RFI - Request for Information
Service information has been requested, including electricity consumption reports, service reports, and more. It is executed immediately in the order of the general queue in the absence of priority applications.
The priority of the application, which affects the speed of reaction and decision, is calculated based on the information received from the client, taking into account a number of internal rules and orders. There are two priorities: initial and final. The initial priority is set according to the client and determines the speed of the incident processing. The final priority is set by the engineer after completion of the work and reflects the actual level of degradation of services. Often these priorities are not equal.
Priorities are allocated as follows:
the functioning of the network segment is disrupted (the communication node is inaccessible, the reference switch is out of order) - 40;
significant degradation of several services provided to the client - 30;
significant degradation of one of the services provided to the client - 20;
degradation of services, which does not have a significant impact on their essence - 10;
there is no impact on client services - 0.
I think this can smoothly finish the analysis of the theory. The timing of responses to incidents and requests, escalation levels, financial motivation and other information that is more or less standard for other companies will remain behind the scenes. Let's move on to more interesting things.
No comments:
Post a Comment