Время до решения (Resolution Time)
Resolution Time — одна из ключевых метрик зрелой поддержки. Она сложнее в подсчёте, чем FRT, но честнее отражает реальную пользу для клиента.
Как считать
- От момента поступления тикета до момента «решено» (статус Closed/Resolved).
- Часто считают по рабочему времени, чтобы не смешивать ночи и выходные.
- Полезно смотреть отдельно медиану и 90-й перцентиль.
Что важно
- Закрытие тикета должно быть честным: если клиент снова возвращается с тем же вопросом, это не «решено».
- Полезно отдельно отслеживать reopen rate — долю переоткрытых тикетов.
- Большие значения по перцентилю часто маскируют скрытые проблемы: ждут разработчика, не настроена эскалация.
Когда применять и когда нет
Применять
- Как одна из основных метрик качества поддержки
- В разрезе по типу обращения: «оплата», «технические ошибки», «настройка»
- В SLA-договорах с корпоративными клиентами
Не применять
- В креативных каналах, где «решение» определить сложно: социальные сети, форумы сообщества
Примеры применения
Команда поддержки видела хороший FRT — 12 минут. Но клиенты жаловались, что вопросы тянутся неделями. Когда добавили время до решения, выяснилось: медиана — 2 дня, а 90-й перцентиль — 11 дней. Большая часть «тянущихся» тикетов уходила в разработку и зависала. После настройки автоматической эскалации и SLA на инженерную команду 90-й перцентиль упал до 3 дней.
Часто задаваемые вопросы
Время первого ответа важно для ощущения «нас услышали», время до решения — для реальной пользы. В зрелой поддержке смотрят оба и не путают их. На уровне SLA для клиентов чаще обещают именно время первого ответа, на уровне внутреннего качества — отслеживают полное время решения.
Чаще всего исключают периоды «ждём клиента» из расчёта времени до решения, чтобы не штрафовать поддержку за задержки на стороне клиента. Главное — единое правило и его явное описание в политике, чтобы не было споров о цифрах.