Время решения заявки: что считать и с какого момента

Кратко

Время решения (TTR, time to resolution) — промежуток от регистрации обращения до момента, когда решение предложено и принято, за вычетом пауз, в которые поддержка ждала ответа клиента. Считают в рабочих часах и по медиане. Показатель бессмыслен в отрыве от доли возвратов: быстрое закрытие, после которого человек вернулся, дороже медленного, после которого он не вернулся.

Три разных «времени решения»

Под одним названием в разных системах живут три разные величины, и споры о том, «почему у нас 6 часов, а у них 2», чаще всего именно об этом.

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

Рабочее время до закрытия. То же, но с вычетом нерабочих часов. Уже пригодно к жизни, но всё ещё наказывает поддержку за молчание клиента: заявка, по которой три дня ждали скриншот, выглядит как трёхдневная работа.

Чистое время работы. Рабочие часы минус паузы в статусе «ждём клиента». Единственная величина, по которой можно судить о самой службе. Она же самая трудная: чтобы её считать, статус «ждём ответа» должен реально ставиться, а не быть кнопкой, о которой все забыли.

Практическое правило: обещать клиенту разумно в рабочих часах, спрашивать с команды — в чистом времени, а разницу между ними держать на виду. Именно эта разница показывает, сколько поддержка стоит из-за нехватки информации в первом сообщении.

Где ставится точка «решено»

Второй источник расхождений — момент окончания.

Рабочая схема — две последние строки вместе: закрываем по подтверждению клиента, а если он молчит N дней после отправленного решения, закрываем автоматически, но с уведомлением, а не молча. Срок молчания в 3 рабочих дня — разумная отправная точка: короче — люди не успевают вернуться из отпуска, длиннее — очередь наполняется мёртвыми заявками.

Разумные нормы

Ниже ориентиры в рабочих часах, привязанные к приоритету, а не к каналу. Это норма для старта, а не замер.

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

Почему время решения нельзя смотреть одно

Время решения — показатель, который улучшается закрытием. Любое закрытие его улучшает, независимо от того, решена ли проблема.

Три способа получить прекрасное время решения, не решая ничего:

• Закрывать и заводить заново. Заявка закрыта за 2 часа, через минуту создана новая «по тому же вопросу». Счётчик обнулён, человек ждёт по-прежнему.
• Дробить одно обращение на пять. Каждая часть решается быстро, сумма ожидания не меняется.
• Закрывать без ответа. Исходящих ноль, время решения минимальное.

Поэтому минимальная связка — три числа:

• медиана времени решения;
• доля возвратов: тот же контакт с тем же вопросом в течение 7 дней (тревожно выше 15 %);
• число обращений, закрытых при нуле исходящих сообщений (тревожно при любом значении выше нуля).

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

Частая ошибка: один срок решения на всё

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

Лечится тремя вещами, именно в этом порядке:

• Привязать срок к приоритету. Один срок на всё — это или нереальный срок для сложных случаев, или издевательски мягкий для критичных.
• Включить уведомление до истечения срока, а не после. Предупреждение за 30 минут спасает обращение; отчёт о просрочке только фиксирует потерю.
• Завести отчёт «без движения дольше суток». Самый честный список в любой службе: в нём ровно то, что все обходят стороной.

Как проверить за полчаса

• Выгрузите закрытые обращения за 30 дней: регистрация, закрытие, приоритет, исполнитель, число исходящих.
• Посчитайте медиану и 90-й процентиль. Если второе больше первого впятеро — найдите эти обращения и посмотрите, что у них общего. Это и есть класс, который служба не умеет решать.
• Сравните календарное и рабочее время. Разница больше чем вдвое — значит, вы обещаете клиенту одно, а измеряете другое.
• Найдите пары обращений от одного контакта, закрытых и созданных в пределах часа. Это перезаводы, и их время решения в отчёт попадать не должно.
• Проверьте, сколько обращений закрыто с нулём исходящих. Пока их не ноль, все предыдущие числа недостоверны.

Связанные статьи

• Что такое SLA в технической поддержке простыми словами
• Что такое время первого ответа и какая норма считается разумной
• Что такое FCR: решение с первого обращения и как его считать
• Статусы заявок