On the second front line: our experience in developing technical support

Surely almost everyone has a couple of favorite stories about communicating with the support of companies, whose products or services we use every day. In many cases, we are annoyed by the long wait for a response and its superficial content, and problems, in turn, rarely find a quick and effective solution. The root of these problems usually lies in the organization of support processes.

A business that provides support and maintenance of its product or service should consider how to do it as efficiently and conveniently as possible. To this end, many companies form a multi-level support system, in which all communication with the client is assumed by a technically incompetent specialist. In this scheme, for any support agent, a minimal set of knowledge in technical areas is sufficient - if necessary, he will be able to redirect the application to the necessary “techie” to continue working on a specific problem (these are the specifics of the so-called “call centers”). When moving to another level, the process, as a rule, slows down significantly or even stops. In addition, the fragmentation of support is not very useful in terms of cost optimization and organizational management: more “bureaucracy” is introduced into the overall structure, the quality of the service as a whole falls, and costs increase.

Below we describe how to cope with the situation in Wrike.

The battalions are asking for a second front.

The support of the company Wrike, in which I work, initially used a multi-level structure a la “call center” - more complex technical requests were transferred directly to the developers, while handling all the problematic issues and bugs fell on the shoulders of the QA department. Wrike testers possessed the necessary technical knowledge and competencies, but could not engage in dialogue with the client (all correspondence was conducted by support specialists), and also had no idea what was going on at the support level.
')
Until a certain time, such an organization was justifying itself, but soon the scale of the company's business grew substantially. Grew client base, and, consequently, the cumulative number of calls to support. In addition, with the development of the product, the depth and complexity of many issues has increased.

Testing engineers no longer cope with the increased load (in this case, their work on launching and testing releases was superimposed) and did not have time to process all applications with high quality. The situation was aggravated by communication problems - both sides (support agents and engineers) sometimes found difficulty in understanding, literally in “different languages”. Clients, in turn, only suffered from this - in the process of establishing internal communication, their requests sometimes wandered from one instance to another and back, and the decision itself did not move. If we present the process in a simplified scheme, it looked like this:

At this point, we faced the question: how to modify the process and structure of processing technical requests and, without losing focus on the consumer, add to the quality and speed of problem solving?

Tier 2: between support and QA

The solution was found in the creation of a structural unit in support, responsible for technical issues and escalation of problems to engineers - Tier 2 - that is, “second-level teams” (hereinafter T2). The idea was that experienced support agents, after going through a certain set of training sessions, would try to reach a new level in solving technical problems. In other words, the new team was supposed to be a "special unit" of support, which would have a special technical role. The main advantage of this idea was the departure from the fragmentation of the service - Tier 2 consisted of experienced agents of the "first level", who were still at the forefront and actively helped colleagues with processing client requests, but at the same time most of the time was devoted to requests and problems technical, engineering character.

How did our structure and process change? If earlier it could take several days to figure out the components of a customer’s problem and correctly transfer it to development (QA engineers took time to process the request, almost always there were returns in support, details clarified, etc.), now the whole process took much less time, processing and transfer took 1-2 hours. In addition, the load on both sides was reduced - support and QA.

If the support agent saw a technical issue that falls within the competence of T2, he found out the necessary minimum details and transferred them to the “specialists” from his department. T2-agents took on additional communication with the client and closed the case, exhaustively answering questions. At the same time, the time interval was set for processing all "incoming" requests. Thus, the client had a feeling of satisfaction from fast and high-quality service. The technical issues also included the most complex topics - working with the Wrike API, setting up integrations with services such as Salesforce, and SAML SSO configuration.

If the “case smelled of a bug” (or the question required the intervention of engineers), the T2 agent helped his colleague at the forefront to collect the necessary information for testers (or did it himself), and then through contact with QA and transferring the necessary details he was convinced that the task is taken into development. In other words, T2 oversaw all the bugs and technical problems coming from customers, and was aware of the details of the development process. In addition, the “second level” agents received all the necessary debugging information directly from the engineers, which allowed them to gain experience in solving some problems without escalating to the development department.

Interestingly, from a formal point of view, the overall structure of the process of escalations has not ceased to be multi-layered, and rather has only become more complicated - after all, we added another link to the common chain. In fact, such a move just allowed to simplify the system and configure it for maximum efficiency. Since T2 agents worked directly with clients, most of the technical issues did not leave the support level, and the residual “problem” part reached the development department in a “ready-to-use” form. This was the fundamental difference between the Wrike Support structure “before” and “after” the reform.

In a short time we managed to achieve the construction of a whole system of escalations of complex issues and bugs, reducing the processing time for new problems to 24 hours. The new scheme is presented below.

Performance metrics

Now the main thing - as we realized that the new scheme is working successfully. Despite the fact that no hard metrics were originally provided for, a number of factors indicated success.

1. The metric "Number of returns" is extremely reduced.

The number of returns from T2 was a key metric that allowed us to conclude that the program “got accustomed” and gave its results in terms of the quality of maintenance. “Return” was considered an escalation in T2, which contained incomplete or contradictory information. Under the old system, such an escalation would return with comments from engineers (as a rule, incomplete or technically confusing), and the Support agent would lose the time to re-process it.

With the new scheme, the request did not reach the engineers and was supplied with a detailed comment (and, if necessary, an explanation personally) from agent T2, which allowed the first level agent to understand his mistake or to get the missing information from the client necessary to solve the problem. The high number of returns at the initial stage spoke about the problems with the quality of handling technical issues and bugs. During the adaptation of the new structure, T2 agents have managed to inculcate a “culture” of escalations that would not cause questions to the engineers, as evidenced by a drop in the level of returns to almost zero. The graph shows the dynamics of the percentage of returns returning (from the total number of escalations) from T2 since the introduction of the new system. During the 7 months of the new process, we managed to reduce the average returns from 25% to 2% -3% (see chart below).



2. Significantly reduced time for processing customer requests. Previously, the response from engineers took 24-48 hours, now - 1 hour for T2 processing, the working day - for processing by engineers.

3. The quality and speed of servicing technical issues has increased, in particular with regard to working with API and SSO.

4. QA-department has unloaded its schedule and was able to focus on testing issues.

5. Support agents received assistance in solving technical problems, which allowed them to send more forces to non-technical competencies and increased the speed of processing requests.

6. The support team has another career growth vector.

What was required for the introduction of T2

1. Training of five first-level agents on technical issues (training on API, SSO, Salesforce topics).

2. Introduction of necessary changes on the technical side to ensure the continuity of the process of escalating bugs and problems in the development (this item is worthy of a separate article).

Let's sum up

• The introduction of an additional structure within the support did not lead to its separation and excessive “bureaucratization”, but only strengthened certain competencies, making the team more technically-oriented as a whole.
• It turned out to be easier than they thought.
• This did not require additional costs (except for the allocation of a small resource for training).

The idea of ​​creating a technically-directed unit in support is far from new - many companies successfully implemented it before Wrike. In each case, their own combinations and implementation options are possible - it all depends on the specific structure and desired results. The main thing in this case - an understanding of the need for necessary changes. In the case of products such as Wrike, customer desires and feedback ultimately determine the appearance and essence of the product, so it is very important for us that communication with the customer is always clearly established, especially on the technical side. And of course, it is important to remember that support in general is the face of the business, and how it will look depends only on us.