Помочь применить это руководство?Спросить команду DripTell
Клиент пишет: «Проблема все еще не решена». В истории видно три ответа сотрудников, две внутренние заметки, смену статуса и автоматическое подтверждение. Если назвать все семь событий касаниями, отчет будет выглядеть точным, но не опишет клиентский опыт.
Полезная метрика считает содержательные ответы человека, которые видел клиент, от начала одной проблемы до ее настоящего решения. Она исключает автоматизацию и внутреннюю работу, связывает повторное открытие с исходной проблемой и сама по себе не превращается в рейтинг сотрудников.
Начните с определения события
Слово «касание» слишком многозначно. Одна система считает любое обновление заявки, другая только публичные ответы, третья смешивает сообщения клиента и сотрудника. Актуальное руководство Microsoft по времени работы над случаем отделяет активную работу, включая общение, исследование, сотрудничество и заметки, от полного времени до решения. Описание Active Conversation также показывает действия по случаю и клиенту в одной ленте. Поэтому не каждое зарегистрированное событие является ответом, который видел клиент.
До расчета напишите короткий контракт события. Считайте человеческий ответ, если он дает новую информацию, запрашивает действительно нужные данные, подтверждает согласованное действие или объясняет проверенное решение. Шаблонное «мы разбираемся» увеличивает число ответов, но может не двигать проблему. Не удаляйте такие события задним числом. Отмечайте их отдельно как ответы без прогресса.
| Событие | Считать касанием | Где хранить еще |
|---|---|---|
| Публичный ответ с полезной информацией | Да | Цель ответа |
| Необходимый вопрос клиенту | Да | Запрошенные данные |
| Автоматическое подтверждение | Нет | Объем автоматизации |
| Внутренняя заметка или статус | Нет | Внутренняя работа |
| Передача или переназначение | Нет | Владение и передача |
| Ответ клиента | Нет | Усилие клиента |
Это не обесценивает внутреннюю работу. Она отвечает на другой вопрос, поэтому ее нужно измерять отдельно от того, что получил клиент.
Соберите когорту завершенных проблем
Знаменателем должны быть уникальные проблемы с одинаковым окном наблюдения, а не все заявки, закрытые за неделю. Формируйте когорту по дате поступления и следите за каждой проблемой до подтвержденного решения или конца заявленного окна. Если клиент возвращается с той же причиной, добавьте новые ответы к исходной проблеме. Так раннее закрытие не улучшит отчет.
- Публичный ответ человекаСчитайте ответ, когда сотрудник дает полезную информацию или задает необходимый вопрос клиенту.
- Стабильная проблемаСохраняйте одну сущность проблемы между каналами, передачами и повторными открытиями.
- Проверенное решениеБерите проблемы, которые остались решенными в течение окна подтверждения.
- Сопоставимый сегментСравнивайте похожие тип, сложность, канал и обещание сервиса.
- Защита результатаЧитайте касания вместе с повторами, временем решения и усилием клиента.
Базовый расчет прост: квалифицируемые человеческие ответы делятся на уникальные решенные проблемы. Покажите также медиану и распределение. Среднее три может скрывать большую группу с одним ответом и меньшую группу, застрявшую на десяти. Именно длинный хвост часто показывает плохую форму приема, нехватку полномочий, дефект продукта или слабую передачу.
Читайте показатель рядом с решением при первом контакте, но не смешивайте их. Первая метрика спрашивает, решен ли вопрос одним контактом. Вторая показывает, сколько обменов потребовалось остальным. Если одна проблема теряется между каналами, сначала исправьте идентичность в общем входящем ящике.
Сравнивайте действительно похожую работу
Сброс пароля и поврежденная посылка не должны иметь одну цель. Простой вопрос нельзя сравнивать с расследованием, где нужны финансы, поставщик и эксперт по продукту. Начните со стабильного типа проблемы, затем добавьте только признаки, реально меняющие работу: канал, сложность случая, язык или обязательное согласование.
Не создавайте микросегменты без решения. Практический тест прост: приведет ли группа к иному действию? Если в счетах много ответов из-за отсутствующих данных на входе, это полезный вывод. Если сотрудник получает больше сложных эскалаций, сегмент объясняет, почему личное сравнение будет несправедливым.
Сначала смотрите распределение по команде и типу проблемы, а не по людям. Метрика безопаснее как сигнал процесса. Внимательный сотрудник может получить обращение после нескольких слабых ответов. Нельзя приписывать ему весь предыдущий обмен только потому, что он решил проблему.
Найдите причину лишнего ответа
Возьмите настоящие диалоги из длинного хвоста и прочитайте по порядку. Назначьте одну главную причину каждому лишнему обмену, чтобы обзор дал конкретную работу.
Частые причины — неполные данные на входе, первый ответ мимо вопроса, нехватка полномочий, неразрешенная зависимость, передача без контекста или статусное сообщение без владельца следующего решения. Некоторые дополнительные ответы правильны: проверка безопасности, обязательное подтверждение или подробное объяснение могут предотвратить вред и повторный контакт.
Сопоставьте число с временем решения. Много ответов в коротком продуктивном расследовании отличается от того же числа за десять дней молчания. Проверьте долю повторных открытий. Если касаний стало меньше, а повторных открытий больше, работа просто ушла за границу отчета.
Усилие клиента тоже важно. Повторные просьбы прислать номер заказа, снимок экрана или данные личности создают труд, даже если число ответов сотрудника выглядит нормально. Читайте показатель вместе с наблюдаемым усилием клиента, чтобы не переносить нагрузку наружу.
Используйте число для изменения процесса
Дайте каждому циклу обзора одного владельца и одно изменение. Исправьте форму приема для одного типа вопроса, добавьте полномочие, замените неясный шаблон или улучшите заметку передачи. Затем сравните тот же сегмент при том же определении.
Храните версию контракта события рядом с результатом. Если новая платформа иначе считает статусы, тренд изменится без изменения операции. Видимое определение ценнее длинного графика на подвижном основании.
Цель — не минимальное число ответов. Цель — меньше лишних обменов при полном ответе и устойчивом решении.
Часто задаваемые вопросы
Что считать касанием поддержки?
Считайте содержательный ответ человека, видимый клиенту. Автоматические подтверждения, внутренние заметки, статусы, передачи и сообщения клиента храните в отдельных метриках.
Начинать ли новый счет при повторном открытии?
Обычно нет. Если в согласованное окно вернулась та же проблема, держите последующие ответы вместе с ней. Новая проблема получает новую сущность.
Можно ли ранжировать сотрудников по числу касаний?
Само по себе число для этого небезопасно. Сложность, передачи, унаследованные ответы, полномочия и поведение клиента меняют результат. Сначала используйте его для поиска трения в процессе.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники