Как измерять спрос вызванный сбоями клиентского сервиса

Спрос, вызванный сбоем, — это обращение клиента, которого не было бы, если бы предыдущая часть сервиса сработала как обещано. Чтобы измерить его, возьмите репрезентативную выборку входящих обращений и для каждого спросите, осталось бы оно необходимым при правильном выполнении прежней работы и своевременном информировании. Затем покажите долю таких обращений и долю времени, затраченного на них.

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

Определение правительства Шотландии 2026 года описывает failure demand как предотвратимую или созданную системой потребность, возникающую после отсутствующего, недостаточного или неэффективного вмешательства. В клиентском сервисе это может быть погоня за обещанным обновлением, повтор сведений после неудачной передачи, возврат к слишком рано закрытой проблеме или вопрос о действии, которое так и не состоялось.

Начните с обращения которого не должно было быть

Используйте один проверочный вопрос во всех разборах.

Осталось бы это обращение необходимым, если бы компания правильно выполнила прежнюю работу и ясно информировала клиента?

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

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

Такое различие не дает превратить показатель в способ обвинять клиентов за то, что они обратились за помощью.

Отмечайте причину а не только сам контакт

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

• Недостаток политики или полномочий
• Причина не установлена

Потребность клиента храните отдельно от причины. Вопрос о доставке — потребность. Неотправленное уведомление — причина. Это помогает увидеть, когда один слабый контроль создает несколько видов обращений.

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

Соберите выборку которую можно защитить

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

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

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

Повторно открытые обращения, новые сообщения, смена канала и фразы вроде «есть новости» полезны для поиска кандидатов, но не являются доказательством. В актуальном руководстве Zendesk по отчетности поддержки предлагается рассматривать возвраты, несколько запросов одного клиента, возраст, приоритет и категорию обращения. Надежный разбор связывает эти сигналы с той же потребностью и прежним событием сервиса.

Измеряйте долю контактов и долю работы

Показывайте как минимум два числа.

Доля обращений из-за сбоя равна числу классифицированных обращений из-за сбоя, деленному на все подходящие входящие обращения.

Доля работы из-за сбоя равна времени обработки таких обращений, деленному на время обработки всех подходящих обращений.

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

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

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

Свяжите путь клиента до автоматизации метки

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

Общий inbox DripTell может объединить историю поддерживаемых каналов, владельца, заметки, статус и следующее действие. Эти данные помогают увидеть последовательность, но не заменяют проверку и не решают, имел ли клиент право обратиться.

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

Используйте показатель чтобы устранить причину

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

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

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

Чтобы связать доказательства в вашем сервисе, свяжитесь с DripTell.

Часто задаваемые вопросы

Чем спрос при сбое отличается от повторного обращения

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

Любая проверка статуса считается сбоем

Нет. Она относится к нему, когда компания пропустила обещанное обновление или оставила ожидания неясными. Сначала проверьте обещание и контекст.

Какого размера должна быть выборка

Она должна покрывать каждый важный канал, причину, язык и период работы. Увеличивайте ее, пока классификация крупных причин не станет стабильной, и публикуйте размер и неопределенность.

Подходит ли этот показатель для оценки сотрудника

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