"- Hello, tech support. Have you tried to turn it off and on?"
During the development of their projects, most IT companies sooner or later face the problem of its support and maintenance. High competition in the information technology market requires high-quality provision of this service, since the availability and availability of the online store, the relevance of its content is a guarantee that the visitor will not choose a competitor, but will cooperate with you. In this article, we consider the method of support within the abcp project, as well as the difficulties encountered and the ways to solve them.
The main specificity of support for abcp clients is that their sales depend on the quality of support and, consequently, profit. Most often, those who use the online store on our platform, previously traded in kiosks, stores, in the car market. There are those who already had a resource on the Internet, but they did not manage to maintain it on their own. A certain segment is occupied by large companies that are ready to outsource the whole site. Time and constant technical progress also dictate their own rules: those who did not have an online store, are forced to have it (since they appear from competitors), besides this is a tool to reduce costs, since independent support takes a lot of time and takes a lot of money. In most cases, the questions and problems that have arisen are formed by the client “on the spot” and must be resolved quickly and efficiently. The main topics of calls to technical support: incorrect price on the site, problems with placing an order, problems with updating the supplier’s price list, problems with filling the site with content, downloading and checking information about spare parts in product groups (oils, tires, wheels), etc. .
Currently, the system has more than eight hundred clients of the platform, and the positive dynamics is traced monthly (see chart below). With the constant growth of users of the platform, support should be fast and of high quality; therefore, it is important to optimize the methods of its rendering.
')
It all started very simply. Before forming a full-fledged support department, each employee helped the users of the platform by telephone or by mail. At that time, only a few people worked for the company, so everyone had to deal with all the incoming work. The growing number of customers has led to the fact that it has become impossible to combine development and support. The moment when it was necessary to determine the choice of the registration system requests, has come. Of course, the main selection criteria were cost, or rather its absence, and the ability to freely modify the code. In development, Mantis was already used as a bug tracker, so it was decided to quickly (and therefore cheaply) adapt it to the processing of tasks from clients. We have built in the form of sending a request to the control panel of the site, that is, given the opportunity to briefly outline the essence of the request, to correspond with the employee, to see the status of the ticket, and so on.
Returning to the selected bug tracker, it is worth noting that the basic version of Mantis has been supplemented by a lot of chips that are actively used to this day. Most of them (additional buttons, links to go to customer information, etc.) allowed us to optimize the transitions between interfaces, thereby speeding up the processing of requests. The most useful development was the embedding of the form for sending a ticket to the administrative control panel of the site.
Clients now have a “Technical support” section, in which the possibilities of creating a new request / ticket in support, keeping correspondence in existing requests, and tracking active tickets became available. An example of the form for sending a request is shown below
The new request form is as simple as possible. As a recommendation, the basic rules of filling are additionally indicated. Also, the user of the platform should briefly state the request so that the support staff can reproduce the error / situation and give a quick response. If necessary, it is possible to attach a file. The form was simple, understandable, and users began to use it in large quantities. After registration, the ticket is displayed in the interface from support staff, and they process the request. When processing occurs dialogue / correspondence with the client. Each comment is specifically duplicated to the mail of the user of the platform and to the group of the support department.
With the help of Mantis, the client can track ticket statuses, change processing priority, see the executor, the actual execution time. If he liked the solution of a particular task, there is an opportunity to put a “Like” mark. All these additions allow you to track the number of received, resolved requests. Inside the department, on the basis of this data, a summary of the employees is collected, which gives an understanding of the effectiveness of the work and the volumes performed by each employee. Such reports help the manager to make decisions about the appointment of material bonuses.
The figure below shows the working interface of the support staff.
Each element of the presented interface allows, without unnecessary movements and clicks, to see an increase in ticket priority, a public comment by a client or a hidden comment from an employee, a list of employees tracking a ticket, and so on.
When working with people, the human factor plays an important role. Some customers are friendly and understanding, others are unfriendly and always unhappy. From this support can not escape. The more users became, the more there were attempts to give some kind of subjective assessment of the work of the entire support service. We began to be reproached with the fact that support “works poorly”, “little requests are processed”, etc ... In order to reduce the degree of dissatisfaction and show the quality of work, we began to display task statistics in the client interface: percentage and number of completed and unfulfilled (outstanding) requests for the last year. That is, we clearly show each of the users what percentage and quantity were processed, and what not. Of course, there are much more processed tickets. It cools a little the heat of those who complain that they did not pay enough attention to him, did not fulfill the request, and so on. All requests are stored, not archived anywhere, not deleted. Everyone can see the entire history of communication with support and view the early treatment. Configure alerts for events that are critical for the user of the platform: approaching the threshold of the service limit, a message about the need to replenish the balance to avoid a stop list, a report on the absence of search results for the online vendor, news about platform innovations, reports on the results of the update of the warehouse and so on .
To improve the quality of support, employees in the bug tracker see counters counting tickets in which a support response is expected. Emails arrive to notify which customer needs to be answered. We have tried to make the interface and the support service as a whole as simple and fast as possible.
The functionality of the platform was constantly expanded, new modules and settings were added. Each employee locally on the specific request found out from the developer the subtleties of the implementation, answered the client, closed the request. When a similar request was received by another employee after a while, the scheme was repeated, since no one remembered that an identical request had been previously processed. Support faced the problem of communication within the department. We constantly spent time on meetings with each other, on consultations with developers, who always cursed that they were distracted.
It was necessary to rebuild the scheme of distribution of requests and communication with other departments. We also use it now. A simplified interaction scheme is presented below (without detailing the work of other departments).
The request from the client can come in the form of a call or request through Mantis. During a call, we always check if there is an active ticket. If not, please create one in order to transfer all communications to it. This happens in 85% of cases. (The remaining 10 - calls for transfer to other employees, 5% - simple and quick consultations by phone no more than 2-3 minutes). In fact, any appeal is transformed into a ticket. They can be typical and non-standard. Typical directly assigned support staff. Non-standard head of support takes to clarify the details, TZ, etc. In addition, each comment for each request is available to read in the mail to all staff. Thus, everyone is aware of what requests and how a colleague decides. This scheme allows the manager to always be aware of all the tickets, employees - to know what is happening in the requests from colleagues. This helps to avoid duplicates, intersections of questions in queries, contextually improve the level of knowledge.
Of course, there are such requests / errors that require developer intervention to correct / develop. In this case, the support officer examines the problem, reproduces it, and writes an additional (hidden from the client) information algorithm for obtaining an error for the development department. Then the task is returned to the support manager. He once again checks the situation and, in the event of a platform error, passes the task to the development department. Next, a decision maker is assigned and the request is processed. The important point is that all issues with developers are solved through the support manager, that is, the developer is distracted a minimum number of times. The time spent on consultations is debited from clients, if there was no mistake on our part.
In the process of work, it was understood that the ratio of the number of clients to the support resources spent on them is incommensurable. This has become a problem. The number of hours spent on support through the bug tracker was not taken into account. We conducted training for the functionality personally for EVERY new user of the platform using telephone communication and TeamViewer. Such training on average took about two hours for one new client. Moreover, such an individual approach led to the fact that the clients didn’t want to set up anything on their own, called the simplest questions and created tickets. There is an urgent need to change the support process.
The following changes were implemented:
The result was not long in coming. We got a huge savings in department resources. The very first graph in the article shows the approximate number of tickets received per year. After the implemented automation, switching to webinars and other measures, the requests were received much less. This trend is connected precisely with the optimization of many processes.
Each of the above changes in work has borne fruit. Limiting the number of hours of support included in the tariff plans greatly influenced the flow of tickets sent. Customers began to turn to documentation, video tutorials, attend webinars. No one wanted to “rest against the limit”, exceed it and additionally pay for work on providing technical support.
I would like to take a closer look at the choice of the online learning system, since after its implementation, the most resources were freed up. We chose from many offers on the webinar market, and the choice fell on the product “Gotowebinar” from Citrix.
The main selection criteria:
The summary table shows the software products that were considered when searching for the best.
Finding the right product was very difficult. In each of the products reviewed, there were some pitfalls: a limited number of hours of recording, inadequate pricing policy with the criteria we needed, the terrible quality of image rendering.
Of course, the criteria in the table when choosing such a system may be different, but our choice was justified. There are no problems with the connection of clients, the video is recorded qualitatively, stored locally. Recorded voice leading, as well as participants of the webinar.
There are still a lot of improvements ahead, but at the moment we can safely say that all the steps described above have led to the establishment of the most stable and optimal interaction with customers, improved the quality of support provided, and evenly distributed department resources.
PS Some statistics at the moment:
The main specificity of support for abcp clients is that their sales depend on the quality of support and, consequently, profit. Most often, those who use the online store on our platform, previously traded in kiosks, stores, in the car market. There are those who already had a resource on the Internet, but they did not manage to maintain it on their own. A certain segment is occupied by large companies that are ready to outsource the whole site. Time and constant technical progress also dictate their own rules: those who did not have an online store, are forced to have it (since they appear from competitors), besides this is a tool to reduce costs, since independent support takes a lot of time and takes a lot of money. In most cases, the questions and problems that have arisen are formed by the client “on the spot” and must be resolved quickly and efficiently. The main topics of calls to technical support: incorrect price on the site, problems with placing an order, problems with updating the supplier’s price list, problems with filling the site with content, downloading and checking information about spare parts in product groups (oils, tires, wheels), etc. .
Currently, the system has more than eight hundred clients of the platform, and the positive dynamics is traced monthly (see chart below). With the constant growth of users of the platform, support should be fast and of high quality; therefore, it is important to optimize the methods of its rendering.
')
Formation of technical support methodology
It all started very simply. Before forming a full-fledged support department, each employee helped the users of the platform by telephone or by mail. At that time, only a few people worked for the company, so everyone had to deal with all the incoming work. The growing number of customers has led to the fact that it has become impossible to combine development and support. The moment when it was necessary to determine the choice of the registration system requests, has come. Of course, the main selection criteria were cost, or rather its absence, and the ability to freely modify the code. In development, Mantis was already used as a bug tracker, so it was decided to quickly (and therefore cheaply) adapt it to the processing of tasks from clients. We have built in the form of sending a request to the control panel of the site, that is, given the opportunity to briefly outline the essence of the request, to correspond with the employee, to see the status of the ticket, and so on.
Returning to the selected bug tracker, it is worth noting that the basic version of Mantis has been supplemented by a lot of chips that are actively used to this day. Most of them (additional buttons, links to go to customer information, etc.) allowed us to optimize the transitions between interfaces, thereby speeding up the processing of requests. The most useful development was the embedding of the form for sending a ticket to the administrative control panel of the site.
Clients now have a “Technical support” section, in which the possibilities of creating a new request / ticket in support, keeping correspondence in existing requests, and tracking active tickets became available. An example of the form for sending a request is shown below
The new request form is as simple as possible. As a recommendation, the basic rules of filling are additionally indicated. Also, the user of the platform should briefly state the request so that the support staff can reproduce the error / situation and give a quick response. If necessary, it is possible to attach a file. The form was simple, understandable, and users began to use it in large quantities. After registration, the ticket is displayed in the interface from support staff, and they process the request. When processing occurs dialogue / correspondence with the client. Each comment is specifically duplicated to the mail of the user of the platform and to the group of the support department.
With the help of Mantis, the client can track ticket statuses, change processing priority, see the executor, the actual execution time. If he liked the solution of a particular task, there is an opportunity to put a “Like” mark. All these additions allow you to track the number of received, resolved requests. Inside the department, on the basis of this data, a summary of the employees is collected, which gives an understanding of the effectiveness of the work and the volumes performed by each employee. Such reports help the manager to make decisions about the appointment of material bonuses.
The figure below shows the working interface of the support staff.
Each element of the presented interface allows, without unnecessary movements and clicks, to see an increase in ticket priority, a public comment by a client or a hidden comment from an employee, a list of employees tracking a ticket, and so on.
When working with people, the human factor plays an important role. Some customers are friendly and understanding, others are unfriendly and always unhappy. From this support can not escape. The more users became, the more there were attempts to give some kind of subjective assessment of the work of the entire support service. We began to be reproached with the fact that support “works poorly”, “little requests are processed”, etc ... In order to reduce the degree of dissatisfaction and show the quality of work, we began to display task statistics in the client interface: percentage and number of completed and unfulfilled (outstanding) requests for the last year. That is, we clearly show each of the users what percentage and quantity were processed, and what not. Of course, there are much more processed tickets. It cools a little the heat of those who complain that they did not pay enough attention to him, did not fulfill the request, and so on. All requests are stored, not archived anywhere, not deleted. Everyone can see the entire history of communication with support and view the early treatment. Configure alerts for events that are critical for the user of the platform: approaching the threshold of the service limit, a message about the need to replenish the balance to avoid a stop list, a report on the absence of search results for the online vendor, news about platform innovations, reports on the results of the update of the warehouse and so on .
To improve the quality of support, employees in the bug tracker see counters counting tickets in which a support response is expected. Emails arrive to notify which customer needs to be answered. We have tried to make the interface and the support service as a whole as simple and fast as possible.
The order of distribution of client requests
The functionality of the platform was constantly expanded, new modules and settings were added. Each employee locally on the specific request found out from the developer the subtleties of the implementation, answered the client, closed the request. When a similar request was received by another employee after a while, the scheme was repeated, since no one remembered that an identical request had been previously processed. Support faced the problem of communication within the department. We constantly spent time on meetings with each other, on consultations with developers, who always cursed that they were distracted.
It was necessary to rebuild the scheme of distribution of requests and communication with other departments. We also use it now. A simplified interaction scheme is presented below (without detailing the work of other departments).
The request from the client can come in the form of a call or request through Mantis. During a call, we always check if there is an active ticket. If not, please create one in order to transfer all communications to it. This happens in 85% of cases. (The remaining 10 - calls for transfer to other employees, 5% - simple and quick consultations by phone no more than 2-3 minutes). In fact, any appeal is transformed into a ticket. They can be typical and non-standard. Typical directly assigned support staff. Non-standard head of support takes to clarify the details, TZ, etc. In addition, each comment for each request is available to read in the mail to all staff. Thus, everyone is aware of what requests and how a colleague decides. This scheme allows the manager to always be aware of all the tickets, employees - to know what is happening in the requests from colleagues. This helps to avoid duplicates, intersections of questions in queries, contextually improve the level of knowledge.
Of course, there are such requests / errors that require developer intervention to correct / develop. In this case, the support officer examines the problem, reproduces it, and writes an additional (hidden from the client) information algorithm for obtaining an error for the development department. Then the task is returned to the support manager. He once again checks the situation and, in the event of a platform error, passes the task to the development department. Next, a decision maker is assigned and the request is processed. The important point is that all issues with developers are solved through the support manager, that is, the developer is distracted a minimum number of times. The time spent on consultations is debited from clients, if there was no mistake on our part.
In the process of work, it was understood that the ratio of the number of clients to the support resources spent on them is incommensurable. This has become a problem. The number of hours spent on support through the bug tracker was not taken into account. We conducted training for the functionality personally for EVERY new user of the platform using telephone communication and TeamViewer. Such training on average took about two hours for one new client. Moreover, such an individual approach led to the fact that the clients didn’t want to set up anything on their own, called the simplest questions and created tickets. There is an urgent need to change the support process.
The following changes were implemented:
- Interactive training using webinars every 2 weeks for everyone.
- The number of hours of support has become limited, depending on the selected tariff when connecting.
- Work manuals for clients have been expanded and streamlined.
- Part of the platform modules was automated, so that the client could perform the setup without the support.
The result was not long in coming. We got a huge savings in department resources. The very first graph in the article shows the approximate number of tickets received per year. After the implemented automation, switching to webinars and other measures, the requests were received much less. This trend is connected precisely with the optimization of many processes.
Each of the above changes in work has borne fruit. Limiting the number of hours of support included in the tariff plans greatly influenced the flow of tickets sent. Customers began to turn to documentation, video tutorials, attend webinars. No one wanted to “rest against the limit”, exceed it and additionally pay for work on providing technical support.
Interactive learning
I would like to take a closer look at the choice of the online learning system, since after its implementation, the most resources were freed up. We chose from many offers on the webinar market, and the choice fell on the product “Gotowebinar” from Citrix.
The main selection criteria:
- image rendering quality;
- high-quality feedback (possibility of dialogue with the connected voice and in correspondence);
- a large number of simultaneously connected listeners;
- cost of using the service;
- the ability to record a webinar.
The summary table shows the software products that were considered when searching for the best.
| webinar.ru | Gotowebinar.com | wiziq.com | webex.com | imind.ru | |
| Image Rendering Quality | the good | great | bad | bad | bad |
| Qualitative feedback | present | present | ? | ? | ? |
| A large number of simultaneously connected listeners | up to 500 people at the same time | up to 100 people at a time | ? | up to 100 participants | up to 1000 participants |
| The cost of using the service | $ 100 per month | ? | |||
| The ability to record a webinar | Yes | Yes | ? | Yes | ? |
Finding the right product was very difficult. In each of the products reviewed, there were some pitfalls: a limited number of hours of recording, inadequate pricing policy with the criteria we needed, the terrible quality of image rendering.
Of course, the criteria in the table when choosing such a system may be different, but our choice was justified. There are no problems with the connection of clients, the video is recorded qualitatively, stored locally. Recorded voice leading, as well as participants of the webinar.
There are still a lot of improvements ahead, but at the moment we can safely say that all the steps described above have led to the establishment of the most stable and optimal interaction with customers, improved the quality of support provided, and evenly distributed department resources.
PS Some statistics at the moment:
- On the day comes from 40 to 90 tickets from customers.
- The support department includes 4 employees and a manager.
- On a weekday receives about 30 calls for support.
- One employee can process about 300 tickets per month
- Over the entire lifetime of the platform, about 66,000 tickets were processed.
- For the full year of 2010, 3620 tickets from 65 customers were received and processed
- For the full year 2014 - 17192 from 821 customers
- Consultations - 70% of the total mass
- Errors - 15% of the total mass
- Requests for the desired, but not doable - 15%
Source: https://habr.com/ru/post/252683/
All Articles