«В старом мире, мы тратили 30% нашего времени на создание хорошего сервиса и 70% времени на то, чтобы рассказать о нём. В современном мире всё наоборот» — Джефф Безос, CEO, Amazon

Это самый ужасный сервис на свете! Верните мне мои деньги немедленно!” — каждый инженер техподдержки хотя бы раз, но слышал такое от пользователя. Да что и говорить, чаще всего высказываются самые недовольные: “Я 27 минут висел на телефоне", “Мою проблему не могут решить уже четвертый день!”. Те, кто никогда не работал в саппорте судят о качестве предоставляемого сервиса по своему личному опыту. А как о нем судим мы, те, кто отвечает на звонки и решает проблемы? Как определить, хороший ли сервис вы предоставляете своим пользователям?

На самом деле тут не нужно изобретать велосипед — всё уже давно придумали до нас. Достаточно обратиться к ключевым показателям эффективности (КПЭ/kpi) и цифрам. Цифры - язык, понятный всем, будь то новый инженер, которому ставят цели или топ-менеджер, которого нужно убедить о необходимости расширения штата.



Существует множество метрик, сотни книг и статей, о том, как их применять и что с ними делать. Я же хочу рассказать лишь о тех, которые используются в нашей команде и как показала практика, они выполняют свое назначение. Причем я не буду приводить тут безумные графики и научные исследования, а просто расскажу несколько любопытных историй из жизни.

Начну с самого начала. Когда я пришла работать в Parallels, у нас уже было порядка 5 млн пользователей Parallels Desktop for Mac по всему миру. В активе значились первая линия поддержки на аутсорсе, вторая линия в Москве и посменный график 24/7. Команд было много, работы тоже. Я пришла как раз во время очередного мажорного релиза. Так получилось, что все тренеры были в Индии на обучении наших саппортеров. Мне дали почитать правила работы и инструкции по продуктам и «десантом» выбросили сразу в ночные смены. 



Первым делом, как прилежная ученица я изучила все метрики (а тогда их было больше 20!), вроде бы разобралась и благополучно забыла до тех пор, пока следом за мной не пришел новый инженер, которого мне поручили учить. В голове была абсолютная путаница — какая метрика за что отвечает? Как что считается? А самое главное — как я могу на что повлиять? Конечно, в итоге я во всем разобралась, но, став тимлидом, первым делом я убрала из целей половину метрик, оставив только самые главные.

У меня нет никаких саппортерских дипломов или пройденных специализированных курсов. В активе скромный штат и ресурсы. Все чему я научилась и учусь, приходит через практику и собственные ошибки. 

Далее я расскажу про наши основные метрики. Некоторые из них являются еще и целями для инженеров в команде. Постараюсь излагать все предельно кратко, без сумасшедших графиков и лишней «воды». Если что-то непонятно, спрашивайте в комментариях. 

Incoming volume или количество обращений


Как измерять? Считать количество созданных заявок за заданный промежуток времени.
Почему это важно для нас? Позволяет предсказать входящий объем заявок и подготовиться — нанять вовремя больше инженеров и обучить их.

Помню, когда я только пришла в поддержку, на релизах нас «заваливало», в буквальном смысле этого слова. А если кто-то из опытных вдруг еще и заболевал, то приходилось работать по 6 смен подряд, чтобы хоть как-то раскидать заявки. Бывало так, что задержка в ответе доходила до двух недель. Мы звонили пользователям, а они говорили: «Знаете, я уже просто всё заново поставил, слишком уж долго вы отвечали».

Благодаря тому, что у нас есть данные о количество входящих заявок за несколько лет, мы научились правильно распределять ресурсы, планировать. Сейчас почти все релизы происходят настолько спокойно и незаметно, что раньше нам и не снилось. 

За 2016 год мы зафиксировали минимальное количество обращений в день — 1 заявка (9 октября) и максимальное количество — 52 заявки (16 марта). Что удивительно, даже в январские праздники нам прилетает в среднем по 8-12 заявок в день и не было ни одного дня без обращений.

IRT — initial response time или время обработки новых заявок


Как измерять? Берем суммарное время реакции на новые заявки и делим на количество созданных заявок за определенный промежуток времени.

Почему это важно для нас? Никто не любит, когда ответа от техподдержки приходится ждать долго. В среднем, пользователь ждет ответа в social media ресурсах в течение часа, а на свой email запрос в течение 24 часов. И здесь не берутся в расчет автоответы: “ваша заявка создана”, только нормальный адекватный ответ с информацией по проблеме. 

Я как-то даже проводила эксперимент: завела заявку в 5 разных компаний и ждала ответа. Два письма прилетело сразу же с автоответом, что со мной свяжутся в течение 24 часов; через полчаса мне ответили из компании #3 и предоставили решение, #4 отвечали в среднем порядка 7 часов, а последнее письмо так и осталось без ответа. Удивительно то, что после обещания связаться со мной, компании #1 и #2 потерялись надолго: один ответ пришел спустя пару дней, а другой через неделю.

Когда мы только начали предоставлять поддержку корпоративным клиентам, мы понятия не имели, как быстро мы отвечаем. Какие на самом деле должны быть SLA, чтобы мы их выполняли? Мы отслеживали динамику IRT в течение 3 месяцев, учли всевозможные составляющие, в том числе “человеческий фактор” и релизы, и теперь точно знаем свои сроки и стремимся их перевыполнить.



FCR — first contact resolution или число заявок, решенных одним ответом


Как измерять? В Parallels всегда было принято отслеживать количество интеракций в рамках одной заявки и считать заявки, решенные в первом же ответе. Хотя, судя по последним течениям и обсуждениям, это не совсем верно, ведь пользователь может вернуться и в новую заявку, но с уточняющим вопросом? Многие компании «следят» за пользователем в течение 7 дней с момента обращения в саппорт. Если пользователь пришел один раз и больше не звонил после полученного решения — отлично, это FCR.

Почему это важно для нас? Если инженеры решают заявку с первого ответа — это показатель технической «прокаченности» команды. Также, отслеживая вопросы в тикетах, решенных с первого ответа, можно понять, какие статьи в базу знаний очень нужно написать, а какую инфо добавить в документацию по продукту. 

У нас FCR очень разный в зависимости от линии поддержки и продукта. Так, например, во второй линии поддержки для физических лиц FCR совпадает с первой линией поддержки для корпоративных клиентов. Тут причина простая — в больших компаниях есть свои админы, которые уже провели изначальный анализ и проблемы и пришли только тогда, когда сами не смогли решить.

TTR — time to resolution или время решения заявки


Как измерять? Берем общее время с момента создания заявок до момента, когда проблемы решены и делим на количество созданных заявок за данный промежуток времени.

Почему это важно для нас? Чем быстрее решена заявка — тем довольнее пользователь. 
А что если инженер на смене не может сам решить проблему? Что если нужно задействовать разработку, QA или даже маркетинг? Получается, что от того, насколько эффективно и правильно построены процессы в вашей компании зависит, как быстро обычный пользователь получит результат, за которым пришел. А строить их нужно так, чтобы всё было быстро и четко, и легко отследить, где именно заявка «застряла». Мы, например, за 1.5 года три раза сменили схему, как заявки эскалируются «дальше», есть четкие инструкции, кому писать и куда звонить при тех или иных ситуациях, и, главное, какую информацию необходимо при этом предоставить.

И опять пример из жизни (не про техподдержку, но про сервис и очень показательный). На прошлой неделе я ходила на почту за марками и простояла в очереди добрых 27 минут, а когда подошла к окошку, оказалось, что марки именно в этом окне закончились и мне нужно в другое, во второе. Во втором окне никого не было и пришлось молча ждать снова. Еще 9 минут, я уже опаздываю на работу и тут появляется Светлана. За 2 минуты Светлана рассказала мне всё, что мне нужно знать о марках, объяснила, чем отличаются марки за 37 и 35 и предложила взять открытки сразу же к себе в окошко, потому что из ящика сегодняшнюю почту на отправку уже вытащили. Я не пожалела, что ждала Светлану. То, как быстро она решила мой запрос перечеркнуло томительное время ожидания и я осталась очень довольна сервисом.



QA — quality assurance или качество выполнения заявки


Как измерять? Выборочно проверяются выполненные заявки инженера и выставляется оценка, берется средняя оценка за заданный промежуток времени.

Почему это важно для нас? Потому что с количеством и быстрыми ответами мы не хотим терять качество.

Оценивать работу других — сложно, тем более, если заявок много, а в каждой заявке много инфы. Плюс еще оценка может быть субъективной, ведь каждый думает по-разному. Для того, чтобы была некая объективность, мы разработали специальную форму, содержащую несколько основных блоков, по которым оценивается заявка. QA менеджер (кстати, обязательно – инженер в прошлом) только выставляет «да/нет», а финальный балл считается автоматически. 

Еще у нас есть правила, по которым можно оспорить поставленную оценку. Получается, что-то вроде медиации — есть две заинтересованные стороны, каждый из которых выражает свою точку зрения, и независимый эксперт, который выражает объективность.

Ну и конечно, CSATcustomer satisfaction или удовлетворенность клиента, про который я не буду рассказывать подробно, но не потому что «не важно», а потому что про него всегда говорят больше всего и уж точно все знают. Для нас — это одна из самых главных метрик, ведь самое важное, чтобы пользователь был счастлив, не так ли? Мы всегда разбираем «плохие» отзывы, а хорошими гордимся.

Очень рекомендую инженерам создавать свою «копилку счастья» — собирать всё хорошее и хранить у себя, чтобы иногда перечитывать и понимать, для чего вы здесь и что всё не зря. Примеры из личной копилки (орфография и пунктуация сохранены):




Конечно, у нас есть и второстепенные метрики. Есть цифры, которые мы достаём раз в год для каких-то особых случаев. Но есть и ситуации, в которых мы стараемся уходить от метрик. Они могут показать, в каком направлении смотреть, но они не расскажут всю историю. За цифрами всегда стоят люди, а люди совершают ошибки, думают по-разному, да и вообще иногда воспринимают KPI как демотиватор. Вводите ли вы, выбрасываете ли или просто следуете метрикам — всегда обязательно проговаривайте всё с командой и начальством. 



Так, в итоге, какими же должны быть КПЭ и как определить, нужны они вам или нет? Я считаю, что метрики — это хороший и проверенный инструмент. Но для него нужна четкая и подробная инструкция. Ещё Питер Друкер, один из самых влиятельных теоретиков менеджмента XX века, говорил, что управлять можно только тем, что можно измерить. Не жалейте времени, разберитесь сами и объясните каждому в своей команде, зачем, для чего и как.

Руководствуйтесь базовыми принципами:

  • выбранные метрики должны отвечать глобальной цели вашей компании. Если вы хотите, чтобы вашу техподдержку знали, как самую отзывчивую, то и измеряйте время реакции/время обработки новой заявки
  • полученные цифры соотносите с реальностью - чтобы не смотреть на картину под одним углом вам нужно несколько опорных метрик. Расширяйте угол обзора, добавляйте те или иные цифры и проверяйте: правда? Если нет, значит, выбрали опорные метрики неверно
  • ваша команда должна иметь влияние на метрики. Как пример, даже на количество входящих заявок вы можете так или иначе повлиять. Из самого простого — если видите, что все пользователи приходят к вам с одним и тем же вопросом, то напишите об этом статью в вашу базу знаний КБ. Банально? Тогда заведите задачу FR програм-менеджеруPMу, чтобы сделать продукт более удобным
  • каждый в команде должен понимать, какие у него сейчас цели и как к ним прийти. Обсуждайте их периодически. Мы это стараемся делать раз в неделю или в месяц, чтобы следить за прогрессом

Ну и последнее, цифры говорят правду. Да-да, даже когда это больно. Совсем больно. Будьте готовы и к этому.



З.Ы. Тема КПЭ оказалась настолько интересной, что мы обсудили ее на недавнем митапе для руководителей и специалистов техподдержки SupNet. По ссылке доклады со встречи. Кстати, если хотите принять участие в очередном митапе лайкайте нашу страничку в Facebook и следите за новостями. 
Поделиться с друзьями
-->

Комментарии (14)


  1. mistik_max
    22.02.2017 13:20
    +1

    Очень полезная и интересная статья, для любой компании где есть служба тех-поддержки) я бы с удовольствием включил ссылку на эту статью в качестве обучающего материала для сотрудников и руководителей такого отдела)


  1. mademax
    22.02.2017 13:20
    +13

    Спасибо, почитал


  1. RadioAgent
    22.02.2017 14:10
    +2

    Если инженеры решают заявку с первого ответа — это показатель технической «прокаченности» команды. Также, отслеживая вопросы в тикетах, решенных с первого ответа, можно понять, какие статьи в базу знаний очень нужно написать, а какую инфо добавить в документацию по продукту.


    Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
    или другой пример, вопрос был закрыт одним ответом, но этот вопрос совершенно уникальный и необходимости создавать какой-то материал нет смысла, т.к. есть более часто спрашиваемые и неописанные сущности.

    Вопросы problem management и knoledge management мне не дают спать уже давно :) И я был бы очень признателен, если бы Вы поделились опытом и примерами.

    Еще некоторые мысли и вопросы:
    Интересная у вас метрика — QA. Подумаю на досуге. Мы делаем то же самое, но не ставим оценки. И, вероятно, зря, интегральной картины и динамики -то нет.
    Но с другой стороны, динамику и интегральную картину мы получаем для оценки качества все из того же FCR, Количества сообщений в рамках одного запроса и CSAT.

    Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность. Если только нужны для контроля новичков.

    Потому что менеджер может оценить качество ответа по каким-то своим или стандартным критериям. А вот удовлетворенность пользователя в итоге совершенно не совпадет с оценкой менеджера. А что такое качество обслуживания? Мне кажется это зависит от целей. У техподдержки цель можно сформулировать — удовлетворенность от услуги или от продукта, как следствие, повышение ценности услуги или продукта для клиента. Некое конкретное качество или абстрактное качество не представляет ценности само по себе, т.к. нет прямой связи с целью предоставления услуги. Как мне кажется.

    И главный вопрос, как, ну КАК считать все эти метрики :( Я умею пользоваться экселькой, но пользователи не хотят и не желают создавать новые тикеты для новых проблем. А очень часто отвечают на старые реквесты. В результате чего ни FCR, ни TTR посчитать корректно в автоматическом режиме не получается :(

    Единственный выход, который вижу — запрещать воскрешать обращения, если повторного обращения нет более какого-то количества времени.

    Спасибо за интересную статью! И успехов в делах :)


    1. YuliaSinyanskaya
      22.02.2017 14:36
      +1

      Большое спасибо за вопросы!

      Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.

      Здесь речь о том, случае, когда инфо еще не содержится в гайде или КБ. Например, к вам приходит 10 человек с похожим запросом и все эти запросы решаются одним ответом — проще тогда опубликовать статью, сэкономить время себе и пользователям.

      или другой пример, вопрос был закрыт одним ответом, но этот вопрос совершенно уникальный и необходимости создавать какой-то материал нет смысла, т.к. есть более часто спрашиваемые и неописанные сущности.

      Для таких ситуаций мы создаем черновики статей. и если вопрос встретился еще раз у другого пользователя — публикуем.

      Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность.

      Пользователь оценивает с точки зрения понравилось/не понравилось, коллеги же оценивают с точки зрения «правильности». Смотрят на ход мыслей, как можно было бы по-другому и быстрее решить проблему. Это как работа над ошибками в школе :) цель данной оценки — повысить знания инженера.

      Потому что менеджер может оценить качество ответа по каким-то своим или стандартным критериям. А вот удовлетворенность пользователя в итоге совершенно не совпадет с оценкой менеджера. А что такое качество обслуживания? Мне кажется это зависит от целей. У техподдержки цель можно сформулировать — удовлетворенность от услуги или от продукта, как следствие, повышение ценности услуги или продукта для клиента. Некое конкретное качество или абстрактное качество не представляет ценности само по себе, т.к. нет прямой связи с целью предоставления услуги. Как мне кажется.

      Согласна :)

      Единственный выход, который вижу — запрещать воскрешать обращения, если повторного обращения нет более какого-то количества времени.

      Мы ограничиваем возможность «воскрешать» заявку после 14 дней. То есть пользователь пришел, мы ему помогли, у него есть две недели всё проверить и вернуться к нам.

      И главный вопрос, как, ну КАК считать все эти метрики :(

      Действительно, очень важный вопрос :) Тут уже всё зависит от системы, которую вы используете. Современные трекеры (или тикетницы, как их еще называют) уже имеют встроенную систему сбора и хранения данных. Мы много лет назад взяли RT и адаптировали под себя, свои цели и нужды.


    1. ggo
      25.02.2017 19:11

      Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.

      Наличие документации совершенно не означает, что вопросов не будет.
      Если вопросы задаются, даже при наличии документации, это значит:
      — документацию почему-то не могут найти. нужно придумать, как сделать ее легко доступной.
      — либо документация неполна, неточна, и прочее не. нужно ее исправить, актуализировать.
      — либо документация описана так, что понимается не так, как должна. нужно переформулировать, перефразировать, по другому структурировать.
      — либо функционал устроен так, что вводит в заблуждение. надо переделать функционал.

      Т.е. в идеале FCR показывает, что что-то решается очевидным способом, но почему-то это неочевидно с первого раза.


  1. erlyvideo
    22.02.2017 17:41
    +1

    Юля, спасибо за пост.


  1. Ugrum
    22.02.2017 18:09
    +1

    Перечитал раз пять, особенно агитки/иллюстрации, их наверное раз шесть.
    Спасибо за


  1. erlyvideo
    22.02.2017 19:38
    +1

    > Если инженеры решают заявку с первого ответа — это показатель технической «прокаченности» команды.

    а нет ли здесь недоработанности продукта? Иначе говоря, если проблема настолько простая, что её можно решить одним ответом, то не означает ли это что в продукте есть какой-то известный баг или недочет, который стоит исправить и тогда этот класс проблем уйдет?


    1. YuliaSinyanskaya
      22.02.2017 23:55
      +1

      спасибо за уточнение. именно здесь я имею в виду нестандартные вопросы, чаще всего связанные с конфигурацией продукта. если инженер обладает достаточными знаниями и тестировал всевозможные конфигурации, он может решить такую заявку одним ответом. ну или протестировать в лабе и дать ответ — что опять же говорит о том, что он понимает, о чем речь и может предоставить решение без доп вопросов и долгих переписок.


      1. erlyvideo
        23.02.2017 00:26
        +1

        понял. Ну, мы помельче, так что сам факт наличия подобных ответов мы стараемся воспринимать как проблему в софте.

        Например, у нас очень долгое время были проблемы с тем, как объяснить людям, в какой файл положить лицензионный ключ. Ответ как раз с первого раза. Потом просто переделали лаунчер (софт то серверный, интерактива нет) и всё стало хорошо.


  1. floodforlife
    22.02.2017 23:41
    +1

    А почему для IRT и TTR вы считаете среднее, а не медианное значение?


    1. YuliaSinyanskaya
      22.02.2017 23:59

      у нас получается нормальное распределение, практически нет выбросов (слишком больших или слишком малых значений), поэтому чаще всего среднее значение совпадает с медианой


  1. deathlenin
    23.02.2017 19:52
    +2

    Спасибо за статью!
    В своё время, работая в техподдержке, правда для голосовых ответов, замеряли аналогичные показатели.
    Однако у нас был ещё один показатель, о котором тут нет речи, а именно повторное обращение с той же темой. Он позволял быстро оценить качество работы каждого инженера(второй линии).


  1. Wild_ButcheR
    03.03.2017 10:00

    Грамотно выстроенные линии, отстроенные тулзы «под себя» и квалифицированный персонал — все просто.