Я люблю цифры. Просматривать коллекции статистических данных и извлекать из них выводы — мое любимое занятие. Наряду с просмотром бейсбола, возиться с программным обеспечением медиацентра и удивляться, как моя собака может спать по 20 часов в сутки. За три года работы в команде поддержки я привык полагаться на цифры, чтобы рассчитать эффективность работы и определить, где нам нужно расставить приоритеты. Статистика, которую мы получаем, помогает нам понять, насколько хорошо мы удовлетворяем потребности наших пользователей, и показывает нам, где искать пути решения существующих и потенциальных проблем. Однако такое понимание нашей службы поддержки клиентов не проходит бесследно. Мы можем собирать всевозможные данные — от отслеживания количества обращений в службу поддержки до отчетов о тенденциях развития тематики, но конечной целью является то, чтобы наши клиенты были довольны. Признаться, эта цель — понятие туманное, и получить представление о ней непросто. Но путем проб и ошибок, новых и старых статистических данных мы убедились, что находимся на правильном пути. Когда вы будете изучать данные службы поддержки в своей компании или организации, мы надеемся, что полученные нами знания помогут вам в использовании статистических данных. В этой главе представлен обзор некоторых наиболее распространенных показателей поддержки, используемых службами поддержки клиентов. В ней не только подробно описывается значение этих цифр, что они собой представляют и что говорят о качестве поддержки, которую получают пользователи, но и раскрываются подводные камни, связанные с этими показателями.
ТРАНСПОРТИРОВКА И ХРАНЕНИЕ
База всех компаний в категории: ОКВЭД 49.50.21 — ТРАНСПОРТИРОВАНИЕ ПО ТРУБОПРОВОДАМ ГАЗА
ОБЩЕСТВЕННАЯ БЕЗОПАСНОСТЬ
Объем
Всего разговоров
Общее количество разговоров или общее количество билетов (в зависимости от приложения службы поддержки) — это подсчет всех новых запросов на поддержку, поступивших за определенный период времени. Каждый новый запрос, включая последующие ответы, считается одним разговором. В зависимости от приложения, которое вы используете для поддержки, разговоры могут также называться тикетами или случаями.
Хороший. Общее количество разговоров позволяет оценить весь объем поддержки. Отслеживание этого показателя с течением времени может помочь понять, когда следует нанять нового сотрудника в команду поддержки, а также дать макроуровневое представление о тенденциях развития поддержки. Более значительный рост с течением времени может означать сочетание нескольких факторов. Некоторые из них хороши, например, рост пользовательской базы; другие не так хороши, например, увеличение количества проблем или ошибок в продукте.
Плохой. Общее количество разговоров может быть шумным показателем в зависимости от того, как вы используете свою службу поддержки. Между элементами, на которые не нужно отвечать (например, автоответчики), или письмами, которые не предназначены для службы поддержки (например, письма из списка рассылки), это может сделать подсчет менее надежным. Например, мы направляем все упоминания в Twitter в наш почтовый ящик поддержки, даже те, которые не требуют никаких действий, и каждое из них учитывается как разговор. Поскольку твиты завышают наши цифры, мы должны воспринимать Total Conversations с долей соли.
Всего ответов
Total Replies подсчитывает каждый ответ, отправленный за определенный промежуток времени. В отличие от Total Conversations, который игнорирует количество ответов в данной теме, Total Replies суммирует каждый раз, когда сообщение отправляется пользователю.
Хороший. Общее количество ответов поможет вам получить представление о том, сколько усилий прилагает ваша служба поддержки. Если общее количество разговоров вводит в заблуждение, если в каждом разговоре много или мало ответов, то общее количество ответов отражает этот объем с большей последовательностью.
Плохой. Общее количество ответов не отражает эффективность работы службы поддержки. Если вам постоянно требуется пять ответов на вопросы, на которые можно ответить за три, общее количество ответов будет высоким, даже если пользователи получают худший опыт.
Общий объем по часам или рабочим часам
Общий объем можно разделить на временные интервалы, что поможет вам оценить нагрузку на службу поддержки за определенный период. Сегментирование выбранной вами метрики объема (Total Conversations или Total Replies) по времени суток поможет вам лучше понять пики и долины вашего объема.
Хороший. Понимание объема работы в зависимости от времени суток может помочь оптимизировать график работы группы поддержки, обеспечивая помощь клиентам без переизбытка персонала.
Плохой. В зависимости от целей вашей службы поддержки, понимание объема по времени суток или рабочим часам может быть бесполезным. Например, если ваша команда придерживается строго определенных часов работы службы поддержки, то точная информация о том, когда запросы на поддержку поступают в нерабочее время, может быть не столь важна.
Время отклика
Среднее время отклика
Среднее время ответа — это среднее время, необходимое для ответа на запросы поддержки за определенный период времени, например, за дни, недели или месяцы. Обычно это значение представлено в виде часов и минут, например, «Среднее время ответа на этой неделе составило 2 часа 22 минуты».
Хороший. Среднее время отклика может быть полезно для получения общего представления о том, насколько быстро команда поддержки реагирует на объем получаемой информации.
Плохой. Поскольку вы усредняете показатели, среднее время ответа может быть непропорционально сильно затронуто отклонениями. Например, если поступило пять обращений, на четыре из них ответили за 15 минут, а пятое заняло 24 часа, среднее время ответа составит 5 часов. Это число все еще имеет определенную пользу, но оно не является лучшим показателем общей отзывчивости команды.
Время до первого ответа
Время до первого ответа — это время, которое требуется службе поддержки для ответа на первоначальный запрос. Никакие ответы, кроме первого, не учитываются в этой метрике.
Хороший. Время до первого ответа может быть полезно для понимания того, получают ли пользователи быстрый первоначальный ответ. Поскольку это место первого контакта, убедиться в том, что пользователь получает своевременный ответ, жизненно важно.
Плохой. Как и среднее время ответа, отклонения могут исказить значение показателя времени до первого ответа. Еще хуже то, что превращение времени до первого ответа в важную метрику может потенциально стимулировать неправильное поведение. От автоответчиков «Мы получили ваше письмо!» до поспешных писем «Мы изучаем проблему!», время первого ответа может быть оптимизировано без реальной помощи пользователям.
Диапазоны времени отклика
Полосы времени ответа показывают процент объема ответов службы поддержки в определенном временном диапазоне. Например, 50% писем отвечают в течение часа или 99% писем отвечают в течение двух дней.
Хороший. Полосы времени отклика помогают наилучшим образом отразить опыт поддержки для всех пользователей, поскольку эти полосы не будут искажены небольшим количеством выбросов или исключений. Вы также можете отслеживать движение по этим диапазонам, чтобы понять, является ли улучшение в одном из них простым заимствованием у соседа или значительной разницей для данной группы пользователей. В Zapier мы отслеживаем три больших диапазона: «Немедленные ответы» (менее 1 часа), «Ответы в тот же день» (менее 6 часов) и «Ответы в течение 24 часов» (менее 24 часов). Для примера, допустим, в гипотетической компании 30% пользователей получают ответы в течение 1 часа, 80% — в течение 5 часов, а 95% — в течение 24 часов. Если число 30% увеличится, то, увидев, как сильно изменились другие группы, можно понять, были ли эти новые «пользователи, получающие ответы в течение 1 часа» теми, кто раньше получал ответы в течение 5 часов, в течение 24 часов или даже более 24 часов.
Плохой. Как и в случае с суммарными ответами, быстрая, но неэффективная служба поддержки может предоставлять пользователям меньший опыт, чем указано в диапазонах времени ответа. С другой стороны, если у вашей команды есть определенные часы работы службы поддержки, которые четко доведены до сведения пользователей, диапазоны времени ответа могут занижать качество обслуживания пользователей, если эти диапазоны включают в расчеты нерабочие часы.
Счастье
Net Promoter Score
Net Promoter Score (NPS) — это опрос, в котором пользователя просят ответить на вопросы по шкале 1-10. Часто этот опрос проводится после завершения работы службы поддержки, иногда через несколько дней.
Хороший. NPS может дать команде поддержки как подробные показатели самочувствия пользователей, так и сводную информацию о том, как все пользователи оценивают полученную ими поддержку.
Плохой. У некоторых пользователей опросы NPS могут ассоциироваться с прошлым опытом, когда заполнение анкеты было неосознанным и поэтому не имело значения. В результате такие пользователи могут отвечать не так честно, как они бы ответили в противном случае. Аналогичным образом, разработка опроса для получения правильных вопросов (как по содержанию, так и по длине) может быть непростой задачей. (Если вам нужны рекомендации, см. наше руководство по разработке опросов).
Рейтинги счастья In-Signature
Вместо более подробного NPS в каждый ответ можно включить возможность оценить полученную поддержку. Часто это более короткий/маленький опрос. Например, в Zapier мы включаем простой вопрос «Как я справился?» с тремя вариантами ответа:
- Ура
- OK
- Бу
Хороший. Размещение рейтинга счастья в подписи к электронному письму способствует получению более оперативной, наглядной обратной связи. Поскольку клиенты могут оценивать каждый ответ, а не только разговор в целом, скорее всего, будет собрано больше данных, а также появится возможность улучшить опыт пользователя, понимая, что он чувствует еще до завершения взаимодействия.
Плохой. Несмотря на то, что непосредственная, визуальная обратная связь может помочь понять эмоциональное состояние пользователя, она не всегда пригодна для действий. Негативные отзывы могут быть вызваны разочарованием по поводу функциональности, которой нет (и не будет) в вашем продукте, а не качеством поддержки, которую они получили. Эмили Чапман написала о том, как команда Trello избегает этого подводного камня, используя эти оценки для установления связи с клиентами на человеческом уровне.
Тенденции развития продукции
Данные этикетки/метки
Многие приложения для службы поддержки предлагают возможность отмечать разговоры. Если у вас есть теги для разных областей вашего продукта или разных категорий проблем пользователей, можно просмотреть и сравнить количество разговоров (или ответов) по этим тегам.
Хороший. Изучая данные тегов, служба поддержки может лучше понять, какие области продукта вызывают наибольшее количество обращений в службу поддержки, или какие проблемы наиболее часто возникают у службы поддержки. Это может помочь определить приоритетность усовершенствования продукта, исправления ошибок, добавления или улучшения документации, а также вдохновить на создание полезных видеороликов и вебинаров.
Плохой. В зависимости от продукта и конкретных используемых тегов и меток может быть сложно получить действительно полезные данные. Если теги и категории слишком широкие, то информация не будет столь действенной; если они слишком детализированы, то может стать трудно определить приоритеты в тех областях, которые необходимо улучшить. Если сами теги не поддерживаются тщательно, это может привести к возникновению целого ряда других проблем, включая случаи, когда существуют похожие, но не идентичные теги, а старые теги не удаляются, что приводит к путанице.
Итоги
Независимо от того, какие показатели вы используете для отслеживания эффективности работы службы поддержки и оценки качества обслуживания ваших клиентов, на этом пути есть свои подводные камни. Не существует ни одной цифры, которая скажет вам все, что нужно знать, поэтому отслеживание нескольких наиболее важных для вашей компании статистических данных поможет вам получить полную картину, не поддаваясь информационной перегрузке.