Почему контроль сроков важнее количества заявок

Для клиента существует только одна заявка – его собственная.  Пользователя не интересует, сколько обращений обработала компания за неделю или месяц. Он оценивает сервис по гораздо более простому критерию: насколько быстро удалось решить конкретно его проблему.

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

Например, разработчик мобильных и онлайн-игр Big Fish Games сосредоточился на сокращении времени ожидания клиентов. После внедрения новых подходов к обслуживанию компании удалось уменьшить среднее время ожидания на 16% и одновременно повысить производительность сотрудников более чем на 5%.

Еще один пример – компания BrightDesk. После анализа работы поддержки выяснилось, что проблема заключается не в количестве обработанных обращений, а в скорости реакции на запросы пользователей. После пересмотра процессов обслуживания среднее время первого ответа удалось сократить с 12 часов до 4,8 часа, а уровень удовлетворенности клиентов вырос с 74% до 92%.

Эти кейсы показывает важную закономерность. Улучшение клиентского опыта произошло не потому, что сотрудники начали закрывать больше заявок. Ключевую роль сыграло сокращение времени ожидания и более быстрое решение проблем пользователей.

Закрытая заявка и решенная проблема – далеко не всегда одно и то же. Например, сотрудник может дать формальный ответ, перевести обращение на другой отдел, запросить дополнительную информацию или предложить временное решение. В системе заявка будет обработана, показатели по количеству обращений улучшатся, но клиенту, возможно, придется обращаться повторно.

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

Например, при одинаковом количестве обращений время первой реакции может начать расти уже сегодня, а падение CSAT станет заметным позже. Сроки первыми фиксируют изменения в системе.

Компания J.D. Power в одном из своих исследований сравнила пять ключевых показателей работы службы поддержки – вежливость и знания сотрудника, скорость общения, внимание к клиенту и своевременность решения вопроса. Именно последний показатель оказался самым значимым для клиентов.

Количество заявок показывает уже нагрузку за прошлые периоды. Сроки позволяют увидеть, что система начинает «не успевать». Например рост времени реакции сигнализирует о будущих просрочках, увеличение бэклога показывает накопление проблем, падение SLA предупреждает о системной перегрузке и т.д.

По срокам можно понять на каком участке процесса возникает задержка: при назначении исполнителя, согласовании, ожидании информации или непосредственно при выполнении. Это помогает искать конкретную причину, а не просто фиксировать факт просрочки.

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

Даже если заявки в итоге закрываются, увеличение времени до первого ответа (MTTA) – один из самых ранних сигналов перегрузки. Для бизнеса это критично тем, что клиентский опыт ухудшается еще до того, как заявка окажется в работе. Клиент изначально не видит движения по своей заявке и воспринимает сервис как медленный, даже если финально задача будет закрыта в срок. В результате растет давление на поддержку: появляются повторные уточнения и дублирующие обращения.

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

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

Если клиент снова обращается по уже закрытой заявке, значит, вопрос не был решён полностью с первого раза. В системе это можно отследить по повторно открытым заявкам, новым обращениям того же клиента и связанным тикетам. Для бизнеса это означает рост нагрузки на сотрудников, а также увеличение очереди и срока рассмотрения заявок.

Сначала нужно выгрузить ключевые метрики: SLA, время первого ответа, MTTR и долю просроченных заявок. Анализировать нужно минимум 2–3 периода, чтобы увидеть динамику, а не разовые колебания. Важно сравнивать периоды с похожей нагрузкой, иначе выводы будут искажены, например, из-за сезонности.

Далее заявки нужно разложить по категориям, типам и каналам поступления. Задача – выявить сегменты, где чаще всего растет время обработки или появляются просрочки. Обычно проблема сосредоточена не во всем сервисе, а в отдельных типах обращений. Также полезно посмотреть разрез по исполнителям.

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

После анализа приоритетов нужно оценить, как распределяется нагрузка между типами заявок. Важно понять, решение каких заявок фактически занимают больше всего времени и ресурсов, и не смешиваются ли они с простыми задачами в одном потоке. Если сложные заявки обрабатываются наравне с быстрыми, это неизбежно увеличивает сроки по всему сервису.

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