TTR

TTR (Time to Resolution, время до решения) - это метрика клиентского сервиса, измеряющая общее время от момента создания обращения клиентом до момента, когда проблема считается полностью решённой, а обращение - закрытым. В отличие от FRT, которая измеряет только скорость первого ответа, TTR охватывает весь жизненный цикл обращения, включая ожидание, переписку, передачу между отделами и финальное решение.

Почему TTR важен

• Комплексная оценка опыта: TTR отражает реальный опыт клиента - как быстро он получил решение своей проблемы, а не просто уведомление о том, что его вопрос принят.

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

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

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

• Исполнение SLA: TTR - ключевой показатель для контроля соблюдения соглашений об уровне обслуживания (SLA). Если в SLA прописано, что проблема должна быть решена за 24 часа, TTR не должен превышать этот порог.

Как рассчитывается TTR

В теории расчёт прост:

TTR = (Время закрытия обращения - Время создания обращения)

Однако на практике есть нюансы, зависящие от настроек системы поддержки:

• Учитывать ли нерабочее время? Многие системы предлагают фильтры "только рабочее время" (для оценки эффективности команды) и "календарное время" (для оценки реального ожидания клиента). Оба показателя имеют ценность.

• Что считать "решением"? Если обращение закрыто автоматически по тайм-ауту, но проблема не решена, его не следует учитывать в статистике как успешно решённое.

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

Факторы, влияющие на TTR

• Сложность проблемы: очевидно, что технические сбои или нестандартные ситуации требуют больше времени.

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

• Скорость ответов клиента: если клиент отвечает медленно, TTR увеличивается.

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

• Время года: в периоды распродаж или праздников нагрузка на поддержку растёт, и TTR может временно увеличиваться.

Как улучшить TTR

• Анализ причин задержек: изучите обращения с самым большим TTR и определите, на каком этапе возникают проблемы. Это потребует ручного анализа, но даст самую ценную информацию.

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

• Автоматизация и самообслуживание: создание базы знаний и чат-бота, способного решать типовые проблемы без участия человека, может кардинально сократить TTR для простых запросов.

• Улучшение коммуникации с клиентом: если решение требует времени, обязательно информируйте клиента о статусе обработки, чтобы снизить его тревожность.

• Обучение операторов: чем компетентнее специалисты первой линии, тем реже требуется эскалация, и тем ниже TTR.

TTR и другие метрики

• TTR vs FRT: FRT измеряет скорость первого ответа, TTR - скорость полного решения. Обе метрики важны и должны отслеживаться параллельно. Быстрый первый ответ, за которым следует долгое решение, - это плохой опыт.

• TTR vs AHT: AHT измеряет чистое время обработки оператором, TTR - общее календарное время решения. AHT - внутренняя метрика эффективности, TTR - внешняя, ориентированная на клиента.

• TTR vs FCR: высокий FCR (решение с первого контакта) автоматически ведёт к низкому TTR, так как проблема решается сразу, без повторных обращений.

Связанные термины

• FCR
• FRT
• AHT
• SLA
• NPS
• CSAT
• Чат-боты
• База знаний