"- Hello, tech support. Have you tried turning it off and on?"
During the development of their projects, most IT companies sooner or later face the problem of its support and support. High competition in the information technology market requires the 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 work with you. In this article, we will consider the support methodology inside the abcp project, as well as the difficulties encountered and ways to solve them.
The main specifics of abcp customer support is that their sales and, consequently, profit depend on the quality of support. Most often, those who use the online store on our platform have previously traded in stalls, stores, and car markets. There are those who already had a resource on the Internet, but they could not support it on their own. A certain segment is occupied by large companies that are ready to outsource the whole site. Time and constant technological progress also dictate their own rules: those who did not have an online store are forced to have one (since competitors have them), in addition, this is a tool to reduce costs, since self-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 effectively. The main topics of technical support calls: 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. .
At the moment, the system has more than eight hundred clients of the platform, and positive dynamics are monitored monthly (see graph below). Given the constant growth of platform users, support should be fast and of high quality, so it is important to optimize its delivery methods.
It all started very simply. Prior to the formation of a full-fledged support department, each employee helped users of the platform by telephone or by mail. At that time, only a few people worked in the company, so everyone had to deal with all the incoming work. The growth in the number of customers has made it impossible to combine development and support. The moment when it was necessary to decide on the choice of the registration system of requests came. The main selection criteria, of course, were the 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 embedded the request sending form in the site control panel, that is, we have made it possible to summarize the essence of the request,
Returning to the selected bug tracker, it is worth noting that the basic version of Mantis has been supplemented with many chips that are actively used to this day. Most of them (additional buttons, links to go to customer information, etc.) made it possible to optimize transitions between interfaces, thereby speeding up the processing of requests. The most useful improvement was the embedding of the form for sending a ticket to the administrative control panel of the site.
Customers 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 have become available. An example of a request submission form is given below.
The new request form is as simple as possible. As a recommendation, the basic filling rules are additionally indicated. Also, the platform user should summarize the request so that the support staff can reproduce the error / situation and give a quick response. If necessary, you can attach the file. The form was simple, clear, and users began to use it in large quantities. After registration, the ticket is displayed in the interface of the support staff, and they process the request. During processing, there is a dialogue / correspondence with the client. Each comment is specially duplicated to the mail of the platform user and to the support department group.
With Mantis, the client can track ticket statuses, change processing priority, see the artist, the actual lead time. If he liked the solution of a particular problem, there is an opportunity to put a mark “Like”. All these additions allow you to track the number of received, resolved requests. Inside the department, based on these data, aggregated information on employees is collected, which gives an understanding of the work efficiency and the volumes performed by each employee. These summaries help the manager make decisions about the assignment of material bonuses.
The figure below shows the working interface of a support employee.
Each element of the presented interface allows you to see an increase in the priority of a ticket, a public comment by a client or a hidden comment by an employee, a list of employees tracking a ticket, and so on, without unnecessary movements and clicks.
When working with people, the human factor plays an important role. Some clients are friendly and understanding, others are unfriendly and always dissatisfied. There is no escape from this support. The more users became, the more attempts were made to give some kind of subjective assessment of the work of the entire support service. We began to be blamed for the fact that support “works poorly”, “handles requests a little”, 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 failed (unresolved) requests for the last year. That is, we clearly show each of the users what percentage and quantity has been processed, and which is not. Of course, there are much more processed tickets. It slightly cools the fervor 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 early calls. Alerts have been set up for events critical for the platform user: approaching the service limit threshold, a message about the need to replenish the balance in order to avoid falling into the stop list, a report on the lack of search results for an online provider, news on platform innovations, reports on warehouse update results 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. Letters are sent to the mail informing about which of the clients needs to be answered. We tried to make the interface and, in general, the support service as simple and fast as possible.
The functionality of the platform was constantly expanding, new modules and settings were added. Each employee locally on a specific request found out from the developer the details of the implementation, responded to the client, closed the request. When a similar request was received after another time by another employee, the scheme was repeated, since no one remembered that an identical request had previously been processed. Support faced a communication problem within the department. We constantly spent time on meetings among ourselves, on consultations with developers who always swore that they were distracting.
I had to slightly restructure the distribution scheme of requests and communication with other departments. We use it now. A simplified interaction scheme is presented below (without detailing the work of other departments).
A request from a 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 it is not there, please create it to transfer all communications to it. This happens in 85% of cases. (The remaining 10 are calls to transfer to other employees, 5% are simple and quick phone consultations for no more than 2-3 minutes). In fact, any appeal is transformed into a ticket. They can be typical and non-standard. Typical support staff directly appoint themselves. Support manager picks up non-standard ones to find out details, technical specifications, etc. Moreover, each comment on each request is available for reading in the mail to all employees. Thus, everyone is aware of what requests and how a colleague decides. Such a scheme allows the manager to always be aware of all the tickets, employees - to know what happens in requests from colleagues. This helps to avoid duplicates, intersections of questions in queries, and contextually increase the level of knowledge.
Of course, there are such requests / errors that require the intervention of developers to correct / develop. In this case, the support employee analyzes the problem, reproduces it and writes in the additional information (hidden from the client) the algorithm for receiving the error for the development department. Next, the task is returned to the support manager. He once again checks the situation and, in case of a platform error, transfers the task to the development department. Next, the person responsible for the decision is appointed and the request is processed. An important point is that all issues with developers are resolved 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, it became clear that the ratio of the number of customers 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 functional training personally for EVERY newly arrived platform user 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 clients themselves did not want to configure anything, they called and created tickets on the simplest issues. There is an urgent need to change the support process.
The following changes were introduced:
The result was not long in coming. We have received tremendous savings in the resources of the department. On the very first chart, the article shows the approximate number of tickets received per year. After the implemented automation, the transition to webinars and other measures, there were already significantly fewer requests. This trend is precisely in the optimization of many processes.
Each of the above changes in work has borne fruit. The limitation of the number of support hours included in the tariff plans greatly affected the flow of tickets sent. Clients began to turn more to documentation, video tutorials, attend webinars. No one wanted to “run into the limit”, exceed it and pay extra for technical support.
I would like to take a closer look at the choice of an interactive learning system, since after its implementation the most resources were freed. We chose from many offers in 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 in the search for the best.
Finding the right product was very difficult. In each of the products examined there were some pitfalls: a limited number of hours of recording, inadequate pricing policy with the criteria we needed, and the terrible quality of image rendering.
Of course, the criteria indicated in the table when choosing such a system may be different, but our choice has paid off. There are no connection problems with clients, the video is recorded in high quality, saved locally. The voice of the presenter, as well as the participants in the webinar, is recorded.
There are still many 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 scheme for interacting with customers, allowed us to improve the quality of support and evenly distribute the resources of the department.
PS Some statistics at the moment:
The main specifics of abcp customer support is that their sales and, consequently, profit depend on the quality of support. Most often, those who use the online store on our platform have previously traded in stalls, stores, and car markets. There are those who already had a resource on the Internet, but they could not support it on their own. A certain segment is occupied by large companies that are ready to outsource the whole site. Time and constant technological progress also dictate their own rules: those who did not have an online store are forced to have one (since competitors have them), in addition, this is a tool to reduce costs, since self-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 effectively. The main topics of technical support calls: 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. .
At the moment, the system has more than eight hundred clients of the platform, and positive dynamics are monitored monthly (see graph below). Given the constant growth of platform users, support should be fast and of high quality, so it is important to optimize its delivery methods.
Formation of technical support methodology
It all started very simply. Prior to the formation of a full-fledged support department, each employee helped users of the platform by telephone or by mail. At that time, only a few people worked in the company, so everyone had to deal with all the incoming work. The growth in the number of customers has made it impossible to combine development and support. The moment when it was necessary to decide on the choice of the registration system of requests came. The main selection criteria, of course, were the 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 embedded the request sending form in the site control panel, that is, we have made it possible to summarize the essence of the request,
Returning to the selected bug tracker, it is worth noting that the basic version of Mantis has been supplemented with many chips that are actively used to this day. Most of them (additional buttons, links to go to customer information, etc.) made it possible to optimize transitions between interfaces, thereby speeding up the processing of requests. The most useful improvement was the embedding of the form for sending a ticket to the administrative control panel of the site.
Customers 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 have become available. An example of a request submission form is given below.
The new request form is as simple as possible. As a recommendation, the basic filling rules are additionally indicated. Also, the platform user should summarize the request so that the support staff can reproduce the error / situation and give a quick response. If necessary, you can attach the file. The form was simple, clear, and users began to use it in large quantities. After registration, the ticket is displayed in the interface of the support staff, and they process the request. During processing, there is a dialogue / correspondence with the client. Each comment is specially duplicated to the mail of the platform user and to the support department group.
With Mantis, the client can track ticket statuses, change processing priority, see the artist, the actual lead time. If he liked the solution of a particular problem, there is an opportunity to put a mark “Like”. All these additions allow you to track the number of received, resolved requests. Inside the department, based on these data, aggregated information on employees is collected, which gives an understanding of the work efficiency and the volumes performed by each employee. These summaries help the manager make decisions about the assignment of material bonuses.
The figure below shows the working interface of a support employee.
Each element of the presented interface allows you to see an increase in the priority of a ticket, a public comment by a client or a hidden comment by an employee, a list of employees tracking a ticket, and so on, without unnecessary movements and clicks.
When working with people, the human factor plays an important role. Some clients are friendly and understanding, others are unfriendly and always dissatisfied. There is no escape from this support. The more users became, the more attempts were made to give some kind of subjective assessment of the work of the entire support service. We began to be blamed for the fact that support “works poorly”, “handles requests a little”, 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 failed (unresolved) requests for the last year. That is, we clearly show each of the users what percentage and quantity has been processed, and which is not. Of course, there are much more processed tickets. It slightly cools the fervor 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 early calls. Alerts have been set up for events critical for the platform user: approaching the service limit threshold, a message about the need to replenish the balance in order to avoid falling into the stop list, a report on the lack of search results for an online provider, news on platform innovations, reports on warehouse update results 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. Letters are sent to the mail informing about which of the clients needs to be answered. We tried to make the interface and, in general, the support service as simple and fast as possible.
Client Request Distribution Order
The functionality of the platform was constantly expanding, new modules and settings were added. Each employee locally on a specific request found out from the developer the details of the implementation, responded to the client, closed the request. When a similar request was received after another time by another employee, the scheme was repeated, since no one remembered that an identical request had previously been processed. Support faced a communication problem within the department. We constantly spent time on meetings among ourselves, on consultations with developers who always swore that they were distracting.
I had to slightly restructure the distribution scheme of requests and communication with other departments. We use it now. A simplified interaction scheme is presented below (without detailing the work of other departments).
A request from a 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 it is not there, please create it to transfer all communications to it. This happens in 85% of cases. (The remaining 10 are calls to transfer to other employees, 5% are simple and quick phone consultations for no more than 2-3 minutes). In fact, any appeal is transformed into a ticket. They can be typical and non-standard. Typical support staff directly appoint themselves. Support manager picks up non-standard ones to find out details, technical specifications, etc. Moreover, each comment on each request is available for reading in the mail to all employees. Thus, everyone is aware of what requests and how a colleague decides. Such a scheme allows the manager to always be aware of all the tickets, employees - to know what happens in requests from colleagues. This helps to avoid duplicates, intersections of questions in queries, and contextually increase the level of knowledge.
Of course, there are such requests / errors that require the intervention of developers to correct / develop. In this case, the support employee analyzes the problem, reproduces it and writes in the additional information (hidden from the client) the algorithm for receiving the error for the development department. Next, the task is returned to the support manager. He once again checks the situation and, in case of a platform error, transfers the task to the development department. Next, the person responsible for the decision is appointed and the request is processed. An important point is that all issues with developers are resolved 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, it became clear that the ratio of the number of customers 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 functional training personally for EVERY newly arrived platform user 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 clients themselves did not want to configure anything, they called and created tickets on the simplest issues. There is an urgent need to change the support process.
The following changes were introduced:
- Interactive training through webinars every 2 weeks for everyone.
- The number of hours of support has become limited, depending on the tariff chosen when connecting.
- Work manuals for customers have been expanded and streamlined.
- Automated part of the platform modules so that the client can configure itself without the participation of support.
The result was not long in coming. We have received tremendous savings in the resources of the department. On the very first chart, the article shows the approximate number of tickets received per year. After the implemented automation, the transition to webinars and other measures, there were already significantly fewer requests. This trend is precisely in the optimization of many processes.
Each of the above changes in work has borne fruit. The limitation of the number of support hours included in the tariff plans greatly affected the flow of tickets sent. Clients began to turn more to documentation, video tutorials, attend webinars. No one wanted to “run into the limit”, exceed it and pay extra for technical support.
Online learning
I would like to take a closer look at the choice of an interactive learning system, since after its implementation the most resources were freed. We chose from many offers in the webinar market, and the choice fell on the product “Gotowebinar” from Citrix.
The main selection criteria:
- image rendering quality;
- high-quality feedback (the possibility of dialogue with the connected voice and in correspondence);
- a large number of simultaneously connected listeners;
- the cost of using the service;
- the ability to record a webinar.
The summary table shows the software products that were considered in the search for the best.
| webinar.ru | Gotowebinar.com | wiziq.com | webex.com | imind.ru | |
| Image Rendering Quality | good | great | bad | bad | bad |
| Quality feedback | is present | is present | ? | ? | ? |
| A large number of simultaneously connected listeners | up to 500 people at a time | up to 100 people at a time | ? | up to 100 participants | up to 1000 participants |
| Cost of using the service | 100 $ per month | ? | |||
| Webinar recording feature | Yes | Yes | ? | Yes | ? |
Finding the right product was very difficult. In each of the products examined there were some pitfalls: a limited number of hours of recording, inadequate pricing policy with the criteria we needed, and the terrible quality of image rendering.
Of course, the criteria indicated in the table when choosing such a system may be different, but our choice has paid off. There are no connection problems with clients, the video is recorded in high quality, saved locally. The voice of the presenter, as well as the participants in the webinar, is recorded.
There are still many 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 scheme for interacting with customers, allowed us to improve the quality of support and evenly distribute the resources of the department.
PS Some statistics at the moment:
- From 40 to 90 tickets are received from clients per day.
- The support department includes 4 employees and a manager.
- On a weekday, about 30 support calls are received.
- One employee can process about 300 tickets per month
- Over the entire existence of the platform, about 66,000 tickets were processed.
- For the full year 2010, 3,620 tickets from 65 clients were received and processed.
- For the full 2014 - 17192 from 821 clients
- Consultations - 70% of the total mass
- Errors - 15% of the total mass
- Requests for desired but not feasible - 15%