Все статьи
Практика поддержки5 сентября 20268 мин

Три метрики поддержки, которые легко подделать

Число закрытых, средняя оценка, время решения — что каждая из них скрывает.

КD
Команда DeskAI
Делаем платформу поддержки клиентов и пишем о том, что видим в работе служб поддержки.

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

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

Проблема не в самих метриках. Число закрытых, оценка и время решения нужны. Плохо, когда каждая из них остаётся одна, без проверки. Тогда она показывает не качество поддержки, а умение команды двигать статусы.

Закрытых стало больше, но это не значит, что вопросов стало меньше

Число закрытых обращений приятно смотреть в конце дня. Было 180 открытых, стало 40. Смена не зря сидела. Очередь разобрали. Руководителю есть что показать владельцу.

Но «закрыто» — это не всегда «решено». Иногда это «оператор ответил и убрал из очереди». Иногда — «клиент молчит два часа». Иногда — «мы передали в другой отдел и больше не держим у себя». В отчёте все эти случаи выглядят одинаково.

Самый простой способ улучшить эту метрику — закрывать раньше. Клиент спросил про возврат, оператор отправил инструкцию и нажал «закрыть». Через семь минут клиент пишет: «Я это уже сделал, денег нет». Формально первое обращение закрыто. По факту вопрос продолжился.

Второй способ — дробить одну проблему на несколько обращений. Клиент написал в почту, потом в Telegram, потом в чат на сайте. Если каналы не связаны, команда закрывает три тикета. В отчёте получается три единицы работы, хотя у клиента была одна история: «мне не помогли с заказом».

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

Поэтому число закрытых стоит смотреть рядом с тем, что возвращается:

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

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

Что скрывает метрика, если смотреть на неё одну

Средняя оценка держится, пока недовольные молчат

Средняя оценка поддержки выглядит честно: клиент сам поставил балл. Не руководитель придумал, не оператор отчитался. Кажется, что здесь сложно мухлевать.

На практике оценка сильно зависит от того, кого вы вообще попросили оценить ответ.

Оператор может отправлять просьбу об оценке только после приятных диалогов. Клиент поблагодарил — «оцените, пожалуйста». Клиент злится — лучше не трогать. Формально никто не подделал балл. Но выборка уже перекошена.

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

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

Средняя оценка скрывает три вещи.

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

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

Третья — распределение. Среднее 4,2 может получиться из ровных четвёрок. А может — из половины пятёрок и половины троек с единицами по сложным темам. Для руководителя это разные картины: в первой поддержка стабильна, во второй часть клиентов проваливается.

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

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

Время решения легко сократить на бумаге

Время решения кажется самой деловой метрикой. Клиент пришёл, команда решила, таймер остановился. Чем меньше время, тем лучше.

Но таймер редко знает, что произошло на самом деле.

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

В отчёте это может быть быстрым решением, если обращение закрыли днём. Для клиента это нерешённая проблема, растянутая на сутки.

Метрику можно улучшить несколькими привычками:

  • закрывать после инструкции, не дожидаясь результата;
  • переводить обращение в «ожидаем клиента», даже когда ждёт команда;
  • просить клиента создать новое обращение, если проблема вернулась;
  • делить один длинный случай на несколько коротких;
  • считать решением передачу в другой отдел.

Иногда это не хитрость, а следствие процесса. Например, оператор действительно не может держать обращение открытым неделю, пока бухгалтерия проверяет платёж. Очередь забьётся, человек потеряет контроль над новыми вопросами. Значит, нужно честно разделить статусы: где клиент ждёт от нас, где мы ждём от клиента, где вопрос ушёл в внутреннюю работу.

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

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

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

Метрика становится честнее, когда у неё есть пара

Одна метрика почти всегда провоцирует перекос. Закрытые давят на скорость. Оценка давит на приятность. Время решения давит на раннее закрытие. Все три по отдельности можно улучшить так, что клиенту станет хуже.

Пара нужна не для красоты отчёта, а как защита от неправильного поведения.

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

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

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

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

Например:

  • закрыто за день;
  • вернулось после закрытия;
  • средняя оценка и сколько клиентов её поставили;
  • время решения по основным темам;
  • старые открытые обращения, которые никто не двигает.

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

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

Попробуйте на своих обращениях

Чат на сайте, почта, Telegram и MAX — в одной ленте. Ассистент отвечает по вашей базе знаний: сам в чате, черновиком оператору в остальных каналах.

14 дней бесплатно · без обязательств · поможем с подключением

Три метрики поддержки, которые легко подделать · DeskAI