Three-letter service quality

“In the old world, we spent 30% of our time creating good service and 70% of the time talking about it. In the modern world, it's the other way around. ”- Jeff Bezos, CEO, Amazon

“ This is the most terrible service in the world! Give me back my money immediately! ”- every technical support engineer at least once, but heard this from the user. But what to say, the most dissatisfied are most often expressed: “ I hung on the phone for 27 minutes ,” “ My problem cannot be solved for the fourth day !”. Those who have never worked in support judge the quality of the service provided by their personal experience. And how are we judged about it, those who answer calls and solve problems? How to determine whether you provide good service to your users?
')
In fact, there is no need to reinvent the wheel - everything has long been invented before us. It is enough to refer to key performance indicators (KPI / kpi) and numbers. The numbers are a language that everyone understands, be it a new engineer who is set goals or a top manager who needs to be convinced about the need to expand staff.



There are many metrics, hundreds of books and articles on how to use them and what to do with them. I want to tell only about those that are used in our team and as practice has shown, they fulfill their purpose. And I will not give you crazy graphics and scientific studies, but just tell a few interesting life stories.

I'll start from the beginning. When I came to work at Parallels, we already had about 5 million users of Parallels Desktop for Mac worldwide. The assets included the first line of support at the outsource, the second line in Moscow and the shift schedule 24/7. There were a lot of teams, work too. I came just during the next major release. It so happened that all the coaches in India were trained by our supporters. I was given to read the rules of work and instructions for products and "landing" immediately thrown into the night shift.



First of all, as a diligent student, I studied all the metrics (and then there were more than 20 of them!), Seemed to understand and safely forgot until a new engineer came to me, whom I was assigned to teach. There was an absolute confusion in my head - which metric is responsible for what? What is considered? And most importantly - how can I influence what? Of course, in the end, I figured it all out, but, becoming a team leader, the first thing I did was remove half of the metrics from my goals, leaving only the most important ones.

I do not have any support diplomas or specialized courses. In an asset modest staff and resources. All that I have learned and learn comes through practice and my own mistakes.

Further I will tell about our main metrics. Some of them are also targets for engineers in the team. I will try to express everything extremely briefly, without crazy graphs and unnecessary "water." If something is not clear, ask in the comments.

Incoming volume or number of hits

How to measure? Count the number of created applications for a specified period of time.
Why is this important to us? Allows you to predict the incoming volume of applications and prepare - to hire more engineers on time and train them.

I remember when I just came in support, on releases we were “flooded”, in the literal sense of the word. And if someone from the experienced suddenly became ill, then they had to work 6 shifts in a row in order to at least somehow scatter the applications. It so happened that the delay in the response reached two weeks. We called the users, and they said: “ You know, I’ve just put it all over again, you have been answering too long .”

Due to the fact that we have data on the number of incoming applications for several years, we have learned how to properly allocate resources and plan. Now almost all releases occur so calmly and unnoticed that we have never dreamed before.

For 2016, we recorded the minimum number of requests per day - 1 application (October 9) and the maximum number - 52 applications (March 16). Surprisingly, even on the January holidays, we receive an average of 8-12 applications per day and there was not a single day without requests.

IRT - initial response time or the processing time of new applications

How to measure? We take the total response time to new applications and divide by the number of created applications for a certain period of time.

Why is this important to us? No one likes it when they have to wait a long time for a response from technical support. On average, the user waits for a response in social media resources within an hour, and to his email request within 24 hours. And here the auto-answers are not taken into account: “your application has been created”, only a normal adequate answer with information on the problem.

Somehow I even conducted an experiment: I made an application to 5 different companies and waited for an answer. Two letters arrived immediately with an auto answer that they would contact me within 24 hours; Half an hour later, they answered me from company # 3 and provided a solution, # 4 answered on average about 7 hours, and the last letter remained unanswered. Surprisingly, after the promise to contact me, companies # 1 and # 2 were lost for a long time: one answer came a couple of days later, and the other a week later.

When we first started providing support to corporate clients, we had no idea how quickly we respond. What really should be SLA for us to perform them? We tracked the dynamics of the IRT for 3 months, took into account all sorts of components, including the “human factor” and releases, and now we know our deadlines for sure and are trying to exceed them.

FCR - first contact resolution or number of applications resolved by one answer

How to measure? In Parallels, it was always customary to keep track of the number of interactions within a single application and count applications that were resolved in the first response. Although, judging by the latest trends and discussions, this is not entirely true, because the user can return to a new application, but with a clarifying question? Many companies "follow" the user within 7 days from the moment of contacting the support. If the user came once and did not call again after the decision received - excellent, this is FCR.

Why is this important to us? If engineers decide an application from the first answer, this is an indicator of the team’s technical "prokhochennost" Also, by tracking the questions in the tickets resolved from the first answer, you can understand which articles in the knowledge base you really need to write and which information to add to the product documentation.

We have FCR very different depending on the support line and product. For example, in the second line of support for individuals, FCR coincides with the first line of support for corporate clients. The reason is simple - in large companies there are admins who have already carried out the initial analysis and problems and came only when they could not solve it themselves.

TTR - time to resolution or time decision applications

How to measure? We take the total time from the moment of creating applications to the moment when problems are solved and divide by the number of created applications for a given period of time.

Why is this important to us? The faster the application is solved, the more satisfied the user is.
What if the engineer on the shift can not solve the problem? What if you need to engage development, QA, or even marketing? It turns out that how effectively and correctly the processes in your company are built depends on how quickly a regular user will get the result for which he came. And you need to build them so that everything is quick and clear, and it is easy to track exactly where the application “stuck”. For example, we have changed the scheme three times in 1.5 years, how applications are “escalated” further, there are clear instructions to whom to write and where to call in certain situations, and, most importantly, what information should be provided.

And again an example from life (not about technical support, but about service and very indicative). Last week I went to the post office for stamps and stood in the queue for a good 27 minutes, and when I went to the window, it turned out that the stamps in this window were over and I needed another one, the second. In the second window there was nobody and had to wait silently again. Another 9 minutes, I'm already late for work, and then Svetlana appears. For 2 minutes, Svetlana told me everything I needed to know about the stamps, explained how the 37 and 35 stamps are different and offered to take the postcards immediately to her window, because they had already pulled out the mail for sending from the box. I did not regret waiting for Svetlana. How quickly she resolved my request canceled out the painful waiting time and I was very pleased with the service.

QA - quality assurance or quality of the application

How to measure? The completed applications of the engineer are selectively checked and a mark is set, the average mark for a given period of time is taken.

Why is this important to us? Because with quantity and quick answers we do not want to lose quality.

It is difficult to evaluate the work of others, especially if there are many applications, and there is a lot of information in each application. Plus, the assessment can be subjective, because everyone thinks differently. In order to have a certain objectivity, we have developed a special form containing several main blocks, by which the application is evaluated. The QA manager (by the way, necessarily - the engineer in the past) only exposes “yes / no”, and the final score is considered automatically.

We also have rules by which we can challenge the assessment. It turns out that something like mediation - there are two interested parties, each of whom expresses his point of view, and an independent expert, who expresses objectivity.

And of course, CSAT - customer satisfaction or customer satisfaction , about which I will not talk in detail, but not because it doesn’t matter, but because they always talk about it the most, and certainly everyone knows about it. For us, this is one of the most important metrics, because the most important thing is for the user to be happy, isn't it? We always make out “bad” reviews, and we are proud of the good ones.

I highly recommend that engineers create their own “ piggy bank of happiness ” - collect all the good and keep it in order to sometimes re-read and understand why you are here and that everything is not in vain. Examples from a personal piggy bank (spelling and punctuation preserved):




Of course, we also have secondary metrics. There are numbers that we get once a year for some special cases. But there are situations in which we try to move away from metrics. They can show in which direction to look, but they will not tell the whole story. People always stand behind the numbers, and people make mistakes, think differently, and in general they sometimes perceive KPI as a demotivator. Whether you enter, throw out or just follow the metrics - always be sure to pronounce everything with the team and superiors.



So, in the end, what should be the KPIs and how to determine whether you need them or not? I believe that metrics is a good and proven tool. But it needs clear and detailed instructions. Peter Drucker , one of the most influential theorists of management in the 20th century, also said that only what can be measured can be managed. Take the time, figure it out yourself and explain to everyone in your team why, why, and how.

Be guided by the basic principles :

• The metrics selected must meet your company's global goal. If you want your tech support to be known as the most responsive, then measure the reaction time / processing time of the new application
• Corresponding figures to reality - in order not to look at a picture from one angle, you need several supporting metrics. Expand the viewing angle, add certain numbers and check: right? If not, then the support metrics are incorrect.
• Your team should have an impact on metrics. As an example, even the number of incoming applications, you can somehow influence. From the simplest - if you see that all users come to you with the same question, then write an article about this in your KB knowledge base. Trite? Then get the task to the program manager FR to make the product more convenient.
• everyone in the team must understand what his goals are now and how to reach them. Discuss them periodically. We try to do this once a week or a month to monitor progress.

And finally, the numbers tell the truth. Yes, yes, even when it hurts. It really hurts. Be prepared for this too.



ZY The topic of KPI turned out to be so interesting that we discussed it at a recent meeting for managers and specialists of SupNet technical support. Under the link reports from a meeting. By the way, if you want to take part in the next meeting, like our Facebook page and follow the news.