Ответ на практический кейс про метрики для саппорта
Классно сформулировал ответ Aleksey:
1. Time to react
2. Time to resolve
3. Количество итераций «вопрос-ответ» с клиентом
Time to react отвечает за то, насколько долго клиент висит без ответа. Если проблема важная, то это время хорошо бы минимизировать. Поэтому, кстати, часто «автомат» уже пытается вас как-то категоризировать и отправить в нужную очередь в зависимости от срочности. Для измерения подойдет пара медиана+95th процентиль - первая отечает за среднее по обращениям, а вторая - за "здоровье" 95% "лучших" звонков.
Time to resolve отвечает за решение проблемы. Можно опять измерять медиану+процентиль и требовать, чтобы второй был, скажем, меньше 1 часа.
Еще одна важная метрика (балансирующая, кстати) - retries. Если количество повторных открытий высокое, значит "решение" было не таким уж решением.
Классно, что многие из вас упомянули NPS score, но я бы с ним был осторожен, потому что отдел поддержки не всегда в ответе за проблемы, которые они помогают решать. Например, если из-за ошибки сервиса доставки покупателям под Новый Год пришли не те покупки, NPS жестко скакнет вниз, хотя это не вина саппорта. Так что всегда пытайтесь выбирать метрики, которые полностью под вашим контролем.
Это был customer facing продукт. В одном из следующих кейсов разберем метрики здоровья backend-сервиса.
#productdo_кейс
Классно сформулировал ответ Aleksey:
1. Time to react
2. Time to resolve
3. Количество итераций «вопрос-ответ» с клиентом
Time to react отвечает за то, насколько долго клиент висит без ответа. Если проблема важная, то это время хорошо бы минимизировать. Поэтому, кстати, часто «автомат» уже пытается вас как-то категоризировать и отправить в нужную очередь в зависимости от срочности. Для измерения подойдет пара медиана+95th процентиль - первая отечает за среднее по обращениям, а вторая - за "здоровье" 95% "лучших" звонков.
Time to resolve отвечает за решение проблемы. Можно опять измерять медиану+процентиль и требовать, чтобы второй был, скажем, меньше 1 часа.
Еще одна важная метрика (балансирующая, кстати) - retries. Если количество повторных открытий высокое, значит "решение" было не таким уж решением.
Классно, что многие из вас упомянули NPS score, но я бы с ним был осторожен, потому что отдел поддержки не всегда в ответе за проблемы, которые они помогают решать. Например, если из-за ошибки сервиса доставки покупателям под Новый Год пришли не те покупки, NPS жестко скакнет вниз, хотя это не вина саппорта. Так что всегда пытайтесь выбирать метрики, которые полностью под вашим контролем.
Это был customer facing продукт. В одном из следующих кейсов разберем метрики здоровья backend-сервиса.
#productdo_кейс