«В старом мире, мы тратили 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 менеджер (кстати, обязательно – инженер в прошлом) только выставляет «да/нет», а финальный балл считается автоматически.
Еще у нас есть правила, по которым можно оспорить поставленную оценку. Получается, что-то вроде медиации — есть две заинтересованные стороны, каждый из которых выражает свою точку зрения, и независимый эксперт, который выражает объективность.
Ну и конечно, CSAT – customer satisfaction или удовлетворенность клиента, про который я не буду рассказывать подробно, но не потому что «не важно», а потому что про него всегда говорят больше всего и уж точно все знают. Для нас — это одна из самых главных метрик, ведь самое важное, чтобы пользователь был счастлив, не так ли? Мы всегда разбираем «плохие» отзывы, а хорошими гордимся.
Очень рекомендую инженерам создавать свою «копилку счастья» — собирать всё хорошее и хранить у себя, чтобы иногда перечитывать и понимать, для чего вы здесь и что всё не зря. Примеры из личной копилки (орфография и пунктуация сохранены):
Конечно, у нас есть и второстепенные метрики. Есть цифры, которые мы достаём раз в год для каких-то особых случаев. Но есть и ситуации, в которых мы стараемся уходить от метрик. Они могут показать, в каком направлении смотреть, но они не расскажут всю историю. За цифрами всегда стоят люди, а люди совершают ошибки, думают по-разному, да и вообще иногда воспринимают KPI как демотиватор. Вводите ли вы, выбрасываете ли или просто следуете метрикам — всегда обязательно проговаривайте всё с командой и начальством.
Так, в итоге, какими же должны быть КПЭ и как определить, нужны они вам или нет? Я считаю, что метрики — это хороший и проверенный инструмент. Но для него нужна четкая и подробная инструкция. Ещё Питер Друкер, один из самых влиятельных теоретиков менеджмента XX века, говорил, что управлять можно только тем, что можно измерить. Не жалейте времени, разберитесь сами и объясните каждому в своей команде, зачем, для чего и как.
Руководствуйтесь базовыми принципами:
- выбранные метрики должны отвечать глобальной цели вашей компании. Если вы хотите, чтобы вашу техподдержку знали, как самую отзывчивую, то и измеряйте время реакции/время обработки новой заявки
- полученные цифры соотносите с реальностью - чтобы не смотреть на картину под одним углом вам нужно несколько опорных метрик. Расширяйте угол обзора, добавляйте те или иные цифры и проверяйте: правда? Если нет, значит, выбрали опорные метрики неверно
- ваша команда должна иметь влияние на метрики. Как пример, даже на количество входящих заявок вы можете так или иначе повлиять. Из самого простого — если видите, что все пользователи приходят к вам с одним и тем же вопросом, то напишите об этом статью в вашу базу знаний КБ. Банально? Тогда заведите задачу FR програм-менеджеруPMу, чтобы сделать продукт более удобным
- каждый в команде должен понимать, какие у него сейчас цели и как к ним прийти. Обсуждайте их периодически. Мы это стараемся делать раз в неделю или в месяц, чтобы следить за прогрессом
Ну и последнее, цифры говорят правду. Да-да, даже когда это больно. Совсем больно. Будьте готовы и к этому.
З.Ы. Тема КПЭ оказалась настолько интересной, что мы обсудили ее на недавнем митапе для руководителей и специалистов техподдержки SupNet. По ссылке доклады со встречи. Кстати, если хотите принять участие в очередном митапе лайкайте нашу страничку в Facebook и следите за новостями.
Автор: Parallels
