KPI службы поддержки: 12 метрик, которые стоит измерять

Принципы выбора KPI

Прежде чем выбирать конкретные метрики, стоит зафиксировать три правила:

1. 5–8 KPI — оптимум. Больше 10 показателей руководитель не удерживает в голове, а команда не может сфокусироваться на всём сразу.
2. Баланс скорости, качества и стоимости. Оптимизация одной оси без контроля двух других всегда даёт перекос: быстро и дёшево — но плохо; быстро и качественно — но дорого и т.д.
3. Метрика должна быть действенной. Если измерение ничего не меняет в работе — показатель не нужен.

Метрики скорости

1. FRT — First Response Time (время первой реакции)

Формула: время от создания заявки до первого ответа оператора пользователю.

Зачем: главный показатель воспринимаемого качества. Пользователь может ждать решения часами, но если реакция быстрая — ощущение, что «ими занимаются», снимает половину раздражения.

Бенчмарки: для массовой B2C-поддержки — 5–30 минут; для корпоративной IT — 15–60 минут; для критичных инцидентов — до 5–10 минут. Считается в рабочем календаре, с учётом приоритета.

2. TTR / MTTR — Time to Resolve (время решения)

Формула: среднее время от создания заявки до её закрытия. MTTR (Mean Time to Resolve) — усреднённое значение за период.

Зачем: ключевой показатель пропускной способности и сложности обращений.

Нюансы: считать обязательно с учётом пауз SLA и только в рабочее время. Без этих поправок цифра будет завышена в разы и бесполезна для сравнения. Подробнее о паузах — в статье о SLA.

3. SLA Compliance (соответствие SLA)

Формула: (заявки, закрытые в срок / всего закрытых заявок) × 100%.

Зачем: главный договорной показатель. Если SLA — часть договора с бизнесом или клиентами, именно по нему оценивают выполнение обязательств.

Бенчмарки: 90–95% — норма для корпоративной поддержки, 95–99% — для премиальной. Значение выше 99% часто означает, что SLA слишком мягкий.

4. Backlog — объём очереди

Формула: количество открытых заявок на момент времени.

Зачем: рабочий оперативный показатель. Рост backlog — предупреждение о недостаточной пропускной способности.

Разбивка: полезно отдельно смотреть backlog по приоритетам, по командам и по возрасту (сколько заявок висит более 2 дней, более недели).

Метрики качества

5. FCR — First Contact Resolution (решение с первого обращения)

Формула: (заявки, решённые без эскалации и без повторных обращений в течение 7 дней / всего закрытых) × 100%.

Зачем: показатель компетентности первой линии и качества базы знаний.

Бенчмарки: 60–75% для корпоративной IT, 70–85% для B2C. Подробно про L1 и FCR — в статье о линиях поддержки.

6. Reopen Rate — частота переоткрытия

Формула: (заявки, возвращённые в работу после закрытия / всего закрытых) × 100%.

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

Бенчмарки: до 5% — норма, 5–10% — повод разбираться, выше 10% — сигнал о системной проблеме в процессе закрытия.

7. CSAT — Customer Satisfaction Score

Формула: средняя оценка от пользователей после закрытия заявки (обычно шкала 1–5).

Зачем: прямая обратная связь о восприятии качества. Нельзя «обмануть» цифрами — пользователи ставят свои оценки.

Нюансы: включайте опрос не во все заявки, а в выборку 20–30%. Опросы в 100% случаев снижают response rate и раздражают. Важнее тенденция, чем абсолютное значение.

8. NPS — Net Promoter Score (для внешних клиентов)

Формула: % «промоутеров» (оценка 9–10) минус % «критиков» (оценка 0–6).

Зачем: стратегический показатель для B2B и B2C клиентов, отражающий готовность рекомендовать сервис.

Бенчмарки: выше 50 — отлично, 30–50 — хорошо, 0–30 — средне, ниже 0 — проблема. Для внутренней корпоративной поддержки чаще используют CSAT.

Метрики эффективности и стоимости

9. Cost per Ticket — стоимость обращения

Формула: (общие затраты на поддержку за период / количество закрытых заявок).

Зачем: понимание юнит-экономики поддержки. Помогает обосновать инвестиции в автоматизацию и базу знаний.

Бенчмарки: сильно зависят от рынка. Для корпоративной IT в России — ориентир 200–800 руб. за обращение. Снижение обычно достигается за счёт самообслуживания и роста FCR.

10. Tickets per Agent — нагрузка на оператора

Формула: количество закрытых заявок на оператора за период.

Зачем: планирование штата, выявление перегруза и недогруза.

Бенчмарки: 15–30 заявок в день на L1-оператора (типовые обращения), 5–12 на L2 (сложные случаи). Сильные отклонения от средних — повод посмотреть детально: возможно, один оператор берёт сложные заявки, а другой — «лёгкие».

11. Self-Service Resolution Rate

Формула: (обращения, закрытые через базу знаний без оператора / общее количество обращений) × 100%.

Зачем: мера зрелости самообслуживания. Каждый процент перевода обращений в self-service — прямая экономия.

Бенчмарки: 10–20% — хорошо для внутренней поддержки, 30–50% — отлично для массовой B2C. Для расчёта нужна аналитика просмотров статей базы знаний.

12. Escalation Rate — доля эскалаций

Формула: (заявки, эскалированные с L1 на L2 / всего поступивших на L1) × 100%.

Зачем: показатель распределения нагрузки между линиями.

Бенчмарки: 25–40% — норма, меньше 20% — возможно, L1 перегружается сложными задачами, выше 50% — значит L1 не решает типовые обращения самостоятельно (диспетчерский режим).

Как собрать дашборд

Не все 12 метрик нужны одновременно. Практический минимум для руководителя поддержки:

Дополнительно — для финдира и CIO: Cost per Ticket и Tickets per Agent ежеквартально. Подробнее про встроенную аналитику в нашей системе — в разделе возможностей.

Как связать KPI с процессами

Сам по себе набор цифр не улучшает работу. Метрики дают эффект, когда каждый показатель связан с конкретным процессом и владельцем. Типовая матрица ответственности:

Без владельца метрики она превращается в отчёт «для галочки». С владельцем — становится инструментом непрерывного улучшения.

Пять типовых ошибок при работе с KPI

1. KPI на операторов без учёта сложности заявок. Оценивать оператора только по MTTR — значит мотивировать закрывать простые заявки и избегать сложных. Правильнее — комбинация скорости, FCR и CSAT.
2. Один общий MTTR для всех типов. Смешивать в одной метрике инциденты и сервисные запросы — бессмысленно: у них разная природа и ожидаемая длительность. Считайте раздельно.
3. Привязка премии к одной метрике. Операторы начнут оптимизировать именно её, иногда в ущерб остальным. Например, привязка к закрытию заявок за сутки приводит к массовому закрытию «для статистики» с комментарием «сообщите, если не поможет».
4. Сравнение команд без учёта контекста. Команда Exchange и команда сетевиков физически имеют разный тип заявок, разные SLA и разную сложность. Сравнение в лоб мотивирует на манипуляции, а не на качество.
5. KPI раз в квартал. Если метрики обновляются раз в три месяца, корректирующие действия запаздывают. Минимум — ежемесячный обзор, по оперативным метрикам — ежедневный.

Вывод

Хороший KPI-набор службы поддержки балансирует скорость (FRT, MTTR, Backlog), качество (FCR, Reopen Rate, CSAT) и эффективность (Cost per Ticket, Tickets per Agent). Начните с 5–7 показателей, наладьте регулярный обзор, и только когда базовые процессы стабильны — добавляйте более тонкие метрики.

И помните: метрика — это не цель. Цель — качественная поддержка пользователей. Если метрика начинает диктовать поведение, которое вредит пользователям, её надо менять.