Метрики и KPI техподдержки: как измерить эффективность сервиса

Техподдержка редко выглядит как подразделение, которое напрямую влияет на деньги компании. Обычно её воспринимают как что-то «операционное»: заявки приходят, инженеры работают, диспетчеры распределяют выезды, клиенты иногда жалуются — значит, всё как у всех.
Проблема в том, что без цифр невозможно понять, сервис справляется или просто держится «на героизме» сотрудников.
Пока заявок мало, многие процессы действительно работают почти вручную:

инженер помнит всё «в голове»;
диспетчер знает клиентов по именам;
срочные проблемы решаются звонком;
просрочки гасятся переработками.

Но когда сервисная компания растёт, такой подход начинает ломаться.
Заявок становится больше. Инженеров — тоже. Клиенты хотят быстрее реакции. Появляются SLA, штрафы, отчёты, повторные обращения и претензии в духе: «Мы оставили заявку ещё утром. Почему никто не ответил?»
И вот здесь почти у всех начинается одна и та же проблема: руководитель чувствует, что поддержка работает плохо, но не понимает — где именно.
Может, инженеры слишком долго решают заявки? Или диспетчеры не успевают распределять обращения? Или клиенты недовольны качеством ремонта? Или проблема вообще не в скорости, а в коммуникации?
Без метрик техподдержки ответы на эти вопросы превращаются в догадки.
Именно поэтому KPI техподдержки нужны не только большим корпорациям или кол-центрам. Они нужны любой сервисной компании, которая хочет:

контролировать качество сервиса;
понимать загрузку команды;
соблюдать SLA;
снижать отток клиентов;
масштабировать поддержку без хаоса.

Причём набор метрик для B2C и B2B будет разным.
В B2C клиент ждёт мгновенной реакции. Если ему не ответили в чате за 10 минут — он просто уйдёт к конкуренту.
В B2B всё сложнее. Здесь клиент оценивает не только скорость, но и:

соблюдение SLA;
прозрачность работы;
качество коммуникации;
компетентность инженеров;
способность подрядчика держать сервис под контролем.

Поэтому одна и та же метрика в разных сегментах может означать совершенно разные вещи.
Например:

для B2C время первого ответа влияет на эмоции клиента;
для B2B — на соблюдение договорных обязательств.

В этой статье разберём:

какие метрики службы поддержки действительно важны;
как считать KPI техподдержки;
какие показатели критичны для B2C, а какие — для B2B;
почему компании часто собирают данные, но не получают от них пользы;
и как не превратить KPI в бессмысленный набор цифр.

Зачем измерять эффективность техподдержки
Когда в сервисной компании начинаются проблемы, они почти никогда не выглядят как «у нас плохие KPI».
Обычно всё начинается с симптомов:

инженеры постоянно перегружены;
клиенты жалуются на долгие ответы;
заявки теряются;
SLA начинают «краснеть»;
сотрудники выгорают;
руководитель всё чаще слышит: «Мы не успеваем».

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

кто должен взять тикет;
где находится объект;
что вообще сломалось;
какие запчасти нужны.

Или другая ситуация.
SLA формально выполняется на 95%, но клиенты всё равно уходят.
На первый взгляд всё хорошо:

сроки соблюдаются;
заявки закрываются;
просрочек немного.

Но если посмотреть глубже, выясняется: клиенту приходится трижды объяснять проблему разным сотрудникам, ждать ответа в нескольких каналах и постоянно напоминать о себе.
То есть формально сервис работает нормально, а фактически клиентский опыт — плохой.
Именно поэтому KPI техподдержки — это не просто «цифры для отчёта». Это инструмент, который помогает понять:

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

Без этого поддержка превращается в чёрный ящик.
Какие бывают метрики техподдержки
Все метрики службы поддержки условно делятся на несколько групп.
1. Временные метрики
Показывают, насколько быстро сервис реагирует и решает проблемы.
Сюда входят:

время первого ответа;
время решения;
среднее время обработки заявки.

Эти показатели особенно важны для B2C, где клиент ждёт почти мгновенной реакции.
Но и в B2B скорость критична. Просто там она измеряется через SLA и приоритеты заявок.
2. Количественные метрики
Показывают объём работы и способность команды справляться с нагрузкой.
Например:

количество заявок;
количество просрочек;
процент соблюдения SLA;
доля заявок, решённых с первого обращения.

Такие KPI службы поддержки помогают понять:

хватает ли ресурсов;
насколько эффективно распределяется нагрузка;
не начинает ли сервис «тонуть» в обращениях.

3. Клиентские метрики
Отвечают на главный вопрос: доволен ли клиент сервисом.
Сюда относятся:

CSAT;
NPS;
CSI;
CES.

Это уже не про внутренние процессы, а про восприятие компании клиентом.
Причём в B2C и B2B эти показатели работают по-разному.
Например:

в B2C CSAT помогает быстро измерять эмоцию после обращения;
в B2B CSI помогает понять, насколько подрядчик соответствует ожиданиям по SLA, коммуникации и компетенциям.

4. Бизнес-метрики
Показывают, как поддержка влияет на деньги компании.
Например:

удержание клиентов;
отток клиентов;
стоимость обработки заявки;
рентабельность обслуживания.

Именно здесь становится видно, почему техподдержка — это не «центр затрат», а полноценная часть бизнеса.
Потому что плохой сервис почти всегда приводит:

к потере клиентов;
штрафам;
снижению продлений;
росту расходов;
репутационным потерям.

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

28 графиков;
десятки таблиц;
сотни показателей;
отчёты, которые никто не читает.

Проблема в том, что большое количество метрик не делает сервис управляемым.
Наоборот — появляется информационный шум.
Команда перестаёт понимать:

какие показатели действительно важны;
что ухудшается;
где нужна реакция;
какие цифры влияют на бизнес.

Поэтому для большинства сервисных компаний лучше начать с 3–5 базовых KPI:

время решения;
SLA Compliance;
CSAT;
количество просроченных заявок;
FCR.

Этого уже достаточно, чтобы увидеть большую часть проблем в поддержке.
А более сложные метрики вроде CSI, CES или Cost Per Ticket обычно появляются позже — когда процессы становятся зрелее.
Временные метрики
Скорость — первое, что замечает клиент.
Он может ничего не понимать в ваших внутренних процессах, не знать, сколько инженеров работает в смене и какие сложности возникли с поставкой запчастей. Но клиент всегда замечает две вещи:

как быстро ему ответили;
как быстро решили проблему.

Именно поэтому временные метрики — основа почти любого KPI техподдержки.
Но здесь есть важный нюанс: быстро — не всегда значит хорошо.
Можно ответить клиенту за две минуты и потом держать заявку открытой три дня. Формально время первого ответа будет идеальным, а удовлетворённость клиентов — низкой.
Поэтому временные метрики всегда нужно смотреть в связке.
Среднее время первого ответа (AFRT)
Это одна из самых базовых метрик техподдержки.
AFRT (Average First Response Time) показывает, сколько времени проходит от создания заявки до первого ответа специалиста.
Проще говоря: клиент оставил обращение — через сколько компания реально вышла на связь.
Почему эта метрика так важна
Когда клиент отправляет заявку и не получает ответа, у него почти сразу появляется тревожность.
Он не знает:

дошла ли заявка;
увидел ли её кто-то;
занимается ли проблемой хоть кто-нибудь.

Особенно это критично в аварийных ситуациях.
Например:

перестала работать касса;
упал интернет;
не открывается СКУД;
отключилось видеонаблюдение;
сломалось оборудование на объекте.

Даже если проблему невозможно решить мгновенно, сам факт быстрого ответа уже снижает напряжение.
Клиент понимает: «Окей, заявку увидели. Работа началась».
Как считать AFRT
Считается метрика просто: от момента регистрации тикета до первого осмысленного ответа сотрудника.
Важно: автоматические сообщения вроде «Ваше обращение принято» обычно не учитываются.
Иначе KPI службы поддержки быстро превращается в фикцию: бот отвечает за секунду, а клиент ждёт инженера полдня.
B2C и B2B: почему ожидания разные
В B2C время первого ответа критично.
Пользователь интернет-магазина, банка или доставки привык к мгновенной коммуникации. Если в чате никто не отвечает 15–20 минут, клиент начинает раздражаться.
Во многих B2C-сервисах нормой уже считается:

ответ в чате — до 1–3 минут;
ответ в мессенджере — до 5–10 минут;
ответ по почте — до часа.

В B2B всё иначе.
Здесь клиент обычно понимает:

заявка может быть сложной;
потребуется диагностика;
иногда нужен выезд инженера;
решение зависит от приоритета инцидента.

Поэтому рамки шире.
Например:

критический инцидент — ответ за 15 минут;
высокий приоритет — до часа;
стандартная заявка — несколько часов.

Но появляется другая проблема: если сроки прописаны в SLA и не соблюдаются — компания рискует получить штраф или потерять контракт.
То есть для B2B AFRT — это уже не просто «скорость реакции», а часть договорных обязательств.
Почему AFRT часто растёт
Когда сервисные компании начинают измерять время первого ответа, почти всегда выясняется: часть заявок лежит без движения гораздо дольше, чем кажется руководителю.
Обычно причины одни и те же:

заявки приходят в разные каналы;
диспетчер вручную распределяет обращения;
инженеры не получают уведомления;
приоритеты определяются хаотично;
сотрудники забывают про тикеты;
часть обращений вообще теряется в мессенджерах.

Особенно часто это происходит в сервисах, где заявки одновременно живут:

в Telegram;
WhatsApp;
почте;
Excel;
личных чатах инженеров.

В итоге клиенту может казаться, что компания его игнорирует, хотя внутри команды просто хаос с маршрутизацией.
Почему AFRT нельзя оценивать отдельно
Одна из самых частых ошибок — делать AFRT главным KPI техподдержки.
Проблема в том, что сотрудники быстро адаптируются к любой системе мотивации.
Если премия зависит только от скорости ответа, начинается игра в «формальные реакции».
Например:

«Заявку получили».
«Передали специалисту».
«Уточняем информацию».

Формально ответ есть. По факту — проблема клиента ещё даже не начали решать.
Поэтому AFRT почти всегда нужно смотреть вместе:

с временем решения;
с CSAT;
с количеством повторных обращений;
с SLA Compliance.

Только тогда метрика начинает показывать реальную эффективность техподдержки, а не скорость отправки шаблонных сообщений.
Среднее время решения (ART / TTR)
Если AFRT показывает, насколько быстро компания отреагировала на заявку, то ART — Average Resolution Time — отвечает уже на главный вопрос: как быстро проблема была реально решена.
Для клиента это обычно важнее любого «мы уже занимаемся вашим обращением».
Потому что можно:

ответить за две минуты;
красиво вести коммуникацию;
отправлять статусы;
соблюдать регламенты.

Но если касса не работает второй день — клиент всё равно будет недоволен.
Именно поэтому время решения — одна из главных метрик техподдержки почти в любом сервисном бизнесе.
Что считается временем решения
ART или TTR (Time To Resolution) измеряет время: от регистрации заявки до полного устранения проблемы.
То есть:

тикет создан;
работа выполнена;
клиент подтвердил решение;
заявка закрыта.

Важно понимать: сюда обычно входит всё время жизни заявки:

ожидание клиента;
согласования;
диагностика;
выезды инженеров;
доставка запчастей;
коммуникация между линиями поддержки.

И именно поэтому ART часто оказывается гораздо выше, чем руководителю кажется «на глаз».
Почему ART — одна из самых болезненных метрик
Потому что она очень быстро показывает реальные проблемы процессов.
Например: компания может считать, что сервис работает быстро.
Но после внедрения help desk выясняется:

часть заявок висит по 3–5 дней без движения;
инженеры забывают переводить тикеты;
клиенты неделями не дают обратную связь;
заявки постоянно перекидываются между сотрудниками;
диспетчеры вручную согласовывают выезды;
запчасти заказываются уже после диагностики.

И всё это напрямую раздувает время решения.
Причём клиенту обычно неинтересно, где именно возникла проблема.
Для него есть простой факт: «Я оставил заявку в понедельник, а проблему решили только в четверг».
Почему низкий ART важен для B2C
В B2C клиент оценивает сервис очень эмоционально.
Если человеку:

не работает интернет;
не открывается приложение;
сломалась кофемашина;
не проходит оплата;
завис терминал.

Он ожидает решение максимально быстро.
Причём часто «быстро» означает:

минуты;
максимум — часы.

Даже если проблема сложная технически, пользователь всё равно сравнивает сервис с лучшими цифровыми компаниями:

банками;
маркетплейсами;
доставками;
крупными онлайн-сервисами.

И если тикет решается долго, резко падают:

CSAT;
NPS;
удержание клиентов.

А ещё растёт количество повторных обращений.
Потому что клиент начинает:

писать повторно;
звонить;
уточнять статус;
эскалировать проблему.

В итоге нагрузка на поддержку становится ещё выше.
Почему в B2B всё сложнее
В B2B-сервисе быстрое решение тоже важно, но здесь уже появляются другие факторы:

SLA;
приоритеты;
регламенты;
доступность оборудования;
графики выездов;
согласования со стороны клиента.

Например, критический инцидент действительно может требовать решения за несколько часов.
Но обычная заявка:

на обслуживание оборудования;
замену камеры;
диагностику;
настройку ПО.

Может спокойно жить несколько дней — и это нормально, если срок укладывается в договор.
Поэтому в B2B важно не просто снижать ART, а управлять им.
Иначе возникает классическая проблема: компания пытается ускорить вообще все заявки подряд, инженеры начинают работать в режиме постоянной аварийки, а качество сервиса падает.
Почему «среднее время» может обманывать
Одна из самых частых ошибок — смотреть только на средний показатель.
Например:

половина заявок решается за час;
половина — за неделю.

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

ART по приоритетам;
ART по типам услуг;
ART по клиентам;
ART по инженерам;
ART по филиалам;
процент заявок, вышедших за SLA.

Только так можно увидеть реальные узкие места.
Почему ART почти всегда растёт вместе с хаосом
Есть очень характерный момент.
Пока сервисная компания маленькая, заявки часто решаются быстро просто потому, что все сотрудники постоянно общаются друг с другом.
Инженер может:

подойти к диспетчеру;
уточнить адрес;
позвонить клиенту;
договориться напрямую;
быстро съездить на объект.

Но когда заявок становится сотни или тысячи, такая модель перестаёт работать.
Появляются:

очереди;
ручные согласования;
потерянные тикеты;
дубли;
конфликты приоритетов;
постоянные переключения между задачами.

И именно в этот момент ART начинает резко расти.
Поэтому время решения — это не просто KPI техподдержки. Это ещё и очень точный индикатор зрелости процессов внутри сервисной компании.
Среднее время обработки заявки (AHT)
Есть типичная ситуация почти в любой сервисной компании.
Инженеры постоянно говорят, что перегружены. Руководитель смотрит на цифры — и не понимает почему.
Заявок вроде не так много. Штат за последний год вырос. А ощущение у команды такое, будто все работают в режиме постоянной аварийки.
Начинают разбираться — и выясняется интересная вещь.
Сам ремонт занимает час. Но ещё:
сорок минут инженер едет до объекта;
двадцать минут ищет контакты клиента;
полчаса ждёт доступ в помещение;
потом вручную заполняет отчёт;
а вечером ещё вспоминает, что забыл закрыть заявку.

И вот уже простая работа растягивается почти на полдня.
Именно это помогает увидеть AHT — Average Handle Time, или среднее время обработки заявки.
Эта метрика показывает не просто «сколько живёт тикет», а сколько времени сотрудники реально тратят на работу.
И тут многие сервисные компании делают неприятное открытие: большая часть времени уходит вообще не на сервис.
А на хаос вокруг него.
Например:

заявки приходят из пяти разных каналов;
инженер не видит историю объекта;
диспетчер вручную распределяет выезды;
документы хранятся в Excel;
клиент каждый раз заново объясняет проблему.

В итоге компания думает, что проблема в людях: «Надо нанимать ещё инженеров».
Хотя проблема — в процессах.
Для B2B это особенно болезненно.
Потому что трудозатраты здесь напрямую превращаются в деньги.
Если инженер тратит на типовую заявку четыре часа вместо одного — сервисная компания начинает терять маржинальность. Особенно в выездном сервисе:
обслуживании ТСБ;
эксплуатации;
HVAC;
телематике;
сервисе оборудования.

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