The last frontier: how the second line of technical support in retail works
In the field of retail, any technical failure is a big stress for the store employees and direct business losses due to interrupted business processes. In one of the past materials, we found out how problems are solved by experts of the first line of support for service companies involved in supporting the trade infrastructure.
This time, Vyacheslav Shambazov, the head of Pilot's technical support service, spoke about the second support line, which engineers deal with the most complex and critical technical incidents.
')
How does the second support line differ from the first
The first line of support classifies customer requests and tries to solve the problem on its own. If this is not possible in a short time (5-15 minutes) or additional competencies are required, the incident is transferred to the second support line. Its employees have deeper technical skills, which allows them to quickly deal with emerging issues.
Be sure to re-verify the information that the engineer of the second line is passed by the staff of the first. This does not mean that the user who is faced with a problem and is under stress is asked the same questions again. Additional details are being clarified from him that will help to quickly find out the essence of the malfunction.
Example: if there are errors in the database, the first-line support staff may not have the competence of database administrators (DBA), therefore, during the dialogue with the user, they may not ask important questions specific to a particular database. They just find out the details of the incident, and the second line employees are already asking deeper questions about the instances and the services and error codes running on the right machine.
No matter how well-established the work of the first line of support, there are always incidents that it cannot solve. As a result, they get to the second-line engineers. As time passes, a retrospective analysis of incoming applications is always done — this is done with the goal of writing instructions or automation scripts that in the future will allow the helpdesk staff on the first line to solve such tasks on their own.
Retrospective analysis can not be done too often (for example, once a day) due to the nature of the interaction of different services within the same service department. Such communications are always regulated, so second-line support engineers cannot force first-line employees to get acquainted with new instructions every day and understand the work of scripts. This work has its own cycles - we have this month. This approach allows you to allocate resources to correct problems, create descriptions and implement the resulting documents and tools in the work of the first line of support.
How it works in practice
Since the engineers of the second support line are always less than the helpdesk staff on the first line, the applications received from them are not executed online. When transferring to the second line, the application is queued for processing - usually it takes 30-45 minutes.
When enqueued, the urgency and criticality of the application is analyzed - if the store faces a serious problem, then no one will force buyers and staff to wait 40 minutes for a decision, and work on the incident will begin immediately. In contracts between retailers and service companies, a certain level of SLA is always prescribed for urgent tasks. Thus, if the company separately indicated that problems of a certain type would cause serious damage to the business, such applications will be processed by engineers outside the general queue.
Consider a few real-life examples of second-line support.
The service company received a call from the store cashier, at the checkout of which the printer stopped printing checks. In this case, the first line of support should follow standard procedures for checking the cash block elements - for example, clarify whether the printer is out of paper, check the tape is not jammed, all necessary indicators are burning on the device - suddenly, say, someone accidentally foot pulled the wire out of the socket.
After that, the user is asked to perform test operations — for example, print a cash report to check the equipment’s performance without breaking new goods. If the problem is not solved, the support staff can try to connect to the cash register remotely and conduct additional diagnostics on the health of important services and drivers of the operating system.
If the incident was not resolved, an application is created for the second support line. This ticket contains all information about problems, and also describes the actions taken by the first line to correct the problem.
Starting to solve the problem, second-line engineers check all previously collected data as part of the incident’s work and can study the knowledge base with descriptions of similar failures. Unlike the first-line support staff, these specialists have access to incident statistics for all customers and have deeper knowledge in technical areas. When an incident arrives, they are able to find a solution to it in a regulated time, even if such situations have not previously occurred and are not documented.
In our check printing example, the engineer may find that updates have been installed on the operating system, causing conflicts with print services, or there have been changes in domain policies that led to changes in the access rights of users of the operating system. Or, for example, in a printer, as a result of a voltage surge, the control program microcode deteriorated and now it is required to “flash” it again.
After finding a problem, the easiest way to solve it is to restore the image of the system from the standard. If for some reason there are no reference samples - this may be at the stage of a pilot implementation of technologies - then you have to deal with making the necessary settings manually.
In our practice, such situations are quite rare, since one of the priorities of the service in retail is the speed of recovery. And the fastest way to solve problems is to restore the system from the standard.
Another example of connecting a second line to processing applications is work on complex issues in advance. For example, a point of sale applies for discrepancies in cash records. The first line, accepting it, classifies this application by type and urgency, and also, in accordance with the type of application, transfers it to the appropriate group of second-line support engineers. At the same time, depending on the type of application, specialists of the first line of support collect primary information about the object specified in the application. These can be either installed software versions, configuration files, event logs or operating system settings, computer address or name, models and amount of peripheral equipment.
The second line, having received a similar application, can, without being distracted by simple questions about the object, proceed to the solution of the application itself, that is, in our example, this is to eliminate the detected discrepancies in the reports. This operation may take quite a long time and may be due to many different factors with which the second-line engineers are well acquainted and have the necessary competencies.
Another example of connecting second-line engineers to solving applications that cannot be resolved at the first-line support level is often server hardware failures. It requires significant competences for maintenance, and failures in its operation are not always expressed in the explicit failure of the server hardware components. Therefore, the application is transferred to the second line of technical support and its specialists are trying to eliminate the incident. It can be expressed in violation of the thermal mode of server operation, failure of individual elements (memory malfunction, bad sectors on hard drives, failure of cache memory batteries), disruption of server software (DBMS, ERP, BI) or errors in interaction with other systems external to this server.
Conclusion: why retailers do not serve the infrastructure themselves
Service companies have extensive experience with the technologies used in the retail sector (for example, our company is 25 years old - and knowledge has accumulated decently). Our engineers faced a significant number of incidents that occurred in infrastructures of various sizes and types. All this contributes to the acquisition of diverse experience in solving real problems.
Nothing prevents retailers from developing their own IT departments, but working with technologies is not the business of such companies, their task is to sell products.
In addition, technology outsourcers have the ability to adapt to the peaks of business activity when the most problems may arise - if the retailer sells Apple gadgets, then in the fall and spring after the release of new devices, there will always be an influx of customers in its stores and, as a result, more trade failures infrastructure. Forces of its own IT professionals to solve all the problems may not be enough, and hiring more people is not profitable for the business.
And we, for example, as a service company, can assign additional employees to work during such peaks, and even form special teams of engineers working on the tasks of a specific customer. It is much more profitable for a business than to spend forces and resources on developing non-core IT competencies.
Other materials on the topic:
Source: https://habr.com/ru/post/335784/
All Articles