First-response time vs resolution time: чем отличаются и какой важнее

Определения и формулы

First-response time (FRT) — время от создания заявки до первого ответа оператора. Считается так:

FRT = (timestamp первого ответа оператора) − (timestamp создания заявки)

«Первый ответ» — это любая активность оператора, видимая пользователю: коммент, изменение статуса с уведомлением, запрос уточнения. Внутренние пометки операторов не считаются.

Resolution time (TTR — time-to-resolution) — время от создания до решения. Считается так:

TTR = (timestamp перехода в Completed) − (timestamp создания заявки)

Принципиально важный нюанс: в зрелых helpdesk-системах из TTR исключается время, проведённое в статусах ожидания пользователя (Waiting User, Postponed). Это правильно — нечестно мерить «решение» когда мяч на стороне пользователя.

В TIQQET SLA-таймер автоматически ставится на паузу при переводе в Waiting User или Postponed, и снимается с паузы при возвращении в работу. Это даёт «чистое» время работы оператора без шума от пользовательских задержек.

Какая метрика важнее для UX

Для пользовательского восприятия — однозначно FRT. Исследования удовлетворённости показывают, что 80% жалоб связаны с фразой «никто не ответил», а не с фразой «не решили». Пользователь готов ждать решения дольше, если знает, что заявку взяли в работу.

Самая частая ошибка операторов: молча работать над сложной задачей 3 часа и потом написать «готово». Для пользователя эти 3 часа — чёрный ящик: «обо мне забыли». Лучше: ответить через 5 минут «принял в работу, ожидаемое время — 3 часа» и потом через 3 часа сказать «готово». Та же длительность, но субъективно — небо и земля.

Для бизнеса важнее TTR — он напрямую отвечает на вопрос «как быстро снимаются блокеры». Бухгалтер не может выгрузить отчёт 4 часа — это потеря 4 человеко-часов работы. Производство стоит из-за поломки принтера 2 часа — это конкретные деньги.

Поэтому в SLA обычно прописывают обе метрики, и за каждую отвечают отдельно. FRT — это про коммуникацию (можно делегировать роботу-боту «принял в работу»). TTR — это про реальную работу.

Какие целевые значения считаются нормой

Эталонные значения зависят от типа поддержки (внутренняя корпоративная vs внешняя для клиентов) и приоритета. Сводная таблица по индустрии:

Эти значения — отправная точка. Их можно и нужно адаптировать под бизнес. Например, если ваша операционка кончается в 18:00, нет смысла обещать решение за 4 часа на критическом инциденте, заведённом в 17:30 — реалистично будет 4 рабочих часа, что попадёт на утро следующего дня.

Признак нездорового SLA: больше 20% заявок просрочены. Это либо приоритеты завышены, либо команда недоштатована, либо процессы дырявые. Лечится не «поднажмём», а пересмотром одного из этих трёх.

Типичные ошибки в учёте

Три классические ошибки:

1. Считают TTR без вычета пауз. Заявка два дня лежала на стороне пользователя — но «время решения» включает эти два дня. Метрики ухудшаются необъяснимо, команда демотивирована. Лечится включением пауз SLA на статусы Waiting User / Postponed.
2. Считают FRT по любым изменениям заявки. Оператор изменил приоритет (внутренний шаг) — счётчик FRT остановился. Пользователь ничего не увидел. Правильно: FRT останавливается только по событиям, которые УВИДЕЛ пользователь (комментарий, смена статуса с уведомлением).
3. Не различают «решено» и «закрыто». Решено — это момент перехода в Completed. Закрыто — это после подтверждения пользователем (обычно через 3-5 дней автоматически или по согласию). TTR должен считаться до Completed, не до Closed. Иначе метрика искусственно растягивается на «срок ожидания подтверждения».

Как улучшать каждую метрику

FRT снижается через:

• Авто-ответы — бот в момент создания пишет «принято в работу, заявке присвоен номер #12345, ожидаемое время реакции — 1 час». Это уже минус 80% жалоб «никто не ответил».
• Перераспределение нагрузки — у одного оператора 47 открытых заявок, у второго 3. Round-robin или skill-based routing уравняет нагрузку.
• Триаж первой линией — выделить 1-2 человека, чья работа — реагировать на новые заявки в течение 5 минут (хотя бы установить приоритет и команду).

TTR снижается через:

• База знаний — типовые проблемы решаются по готовым скриптам, не изобретая каждый раз.
• Эскалация по таймауту — если первая линия не справилась за 2 часа, заявка автоматически уходит ко 2-й линии. Не лежит мёртвым грузом.
• Self-service для типовых заявок — пользователь сам сбрасывает себе пароль через портал, не отвлекая оператора.