Помочь применить это руководство?Спросить команду DripTell
Доля повторно открытых обращений должна отвечать на понятный вопрос: как часто работа, которую команда сочла решённой, возвращалась, потому что клиенту всё ещё была нужна помощь? Показатель не должен поощрять быстрый выбор статуса, наказывать сложные случаи или терять клиента, который вернулся через другой канал.
Честный метод начинает с одной группы решённых обращений, даёт каждому одинаковое окно наблюдения и считает долю случаев, которые клиенты вернули в активную работу. Каждый случай входит в основной показатель один раз. Дополнительные циклы, внутренние исправления и новая переписка о той же проблеме остаются отдельными сигналами.
Сначала определите событие
Практическое системное определение означает возвращение решённого обращения в активное состояние. Для операционной работы нужно добавить причину и инициатора изменения.
- Выберите группуОбъедините случаи по дате первого подтверждённого решения.
- Задайте окноДайте каждому случаю одинаковый срок наблюдения после решения.
- Определите событиеУкажите действие клиента, которое возвращает решённый случай в работу.
- Считайте случаиУчитывайте один затронутый случай один раз, даже если он возвращался многократно.
- Сохраните повторный контактПоказывайте возврат той же проблемы в новом диалоге или канале рядом с показателем.
Ответ клиента о том, что исправление не сработало, является доказательством качества решения. Исправление ошибочно выбранного статуса сотрудником является шумом процесса. Краткая реактивация при синхронизации является системным событием. Разнесите эти события по отдельным полям до расчёта.
Определение должно соответствовать правилам закрытия обращений. Если решено означает только нажатие кнопки, показатель описывает работу со статусами, а не устойчивость результата.
Используйте одну группу в числителе и знаменателе
Возьмите обращения, которые впервые достигли подтверждённого решения в фиксированный период. Наблюдайте за каждым одинаковое время. Числитель содержит уникальные случаи, возвращённые клиентом в окно. Знаменатель содержит все подходящие решённые случаи той же группы.

Например, команда решила 800 обращений за неделю, а 64 из них клиенты вернули в пределах окна. Показатель равен 64, делённым на 800, то есть 8 процентов. Если один случай возвращался трижды, в основном числителе он остаётся одним случаем. Дополнительные циклы показывают тяжесть проблемы.
Не делите возвраты текущего месяца на решения текущего месяца. Часть возвратов относится к старым решениям, а новые ещё не прошли полное окно. Такой расчёт меняется вместе с календарём, даже если качество не изменилось.

Возьмите одну группу решённых обращений, классифицируйте возвраты, считайте каждый случай один раз и изучайте причины.
Отделяйте возврат клиента от шума процесса
| Событие после решения | Основной показатель | Отдельное доказательство |
|---|---|---|
| Клиент возвращает тот же случай из-за нерешённой проблемы | Включить один раз | Время и причина возврата |
| Клиент возвращает один случай несколько раз | Включить один раз | Число дополнительных циклов |
| Сотрудник исправляет ошибочный статус | Исключить | Исправление процесса |
| Автоматизация реактивирует случай при обновлении | Исключить | Системное событие |
| Клиент создаёт новый диалог о той же проблеме | Исключить из строгого показателя | Повторный контакт |
| Клиент задаёт новый вопрос в старом диалоге | Исключить | Новая категория вопроса |
Microsoft показывает практический сценарий, где входящее письмо по решённому случаю снова активирует существующую запись до создания новой. Связь личности клиента и случая определяет, увидит ли отчёт реальный возврат или спрячет его в новой записи.
Держите повторный контакт рядом
Строгий показатель может выглядеть отлично, пока клиенты повторяют запрос в другом месте. Человек начинает в WhatsApp, возвращается в Instagram или создаёт новую форму. Поэтому возвраты нужно смотреть рядом с проверками решения при первом контакте.
Используйте устойчивый идентификатор клиента, категорию проблемы и окно для поиска вероятных повторов. Не смешивайте сомнительные совпадения с основным показателем. Покажите отдельное число и прочитайте выборку. Сохраняйте и полное время решения, чтобы первый статус не стирал ожидание после возврата.
Изучите картину до оценки сотрудника
Рост показателя является поводом для исследования, а не доказательством небрежности. Начните с разделения данных по типу проблемы, каналу, продукту, роли автоматизации, владельцу закрытия и времени до возврата.
Затем прочитайте диалоги. Причиной может быть пробел в базе знаний, недостаток прав, внешняя зависимость, неверный автоматический ответ или слишком раннее правило закрытия. Карточка качества поддержки помогает проверять доказательства одинаково. Не ранжируйте людей до стабилизации состава случаев и классификации событий.
Превратите разбор в одно изменение
Зафиксируйте созревшую группу, проверьте события, изучите крупнейшую причину и назначьте одно изменение с владельцем. В следующих сопоставимых группах смотрите возвраты, повторные контакты, полное время решения и отзывы клиентов.
Общий командный inbox может хранить историю, назначение, заметки и статус. Записи делают расчёт возможным, но определение подтверждённого результата остаётся управленческим решением. Начните с одной реальной очереди и частого типа проблемы в рамках разбора процесса поддержки, прежде чем вводить общую цель.
Часто задаваемые вопросы
Что такое доля повторно открытых обращений
Это доля подходящих решённых случаев, которые клиенты вернули в активную работу в заданное окно. Вместе с результатом укажите событие, группу, окно и исключения.
Нужно ли считать несколько возвратов одного случая
В основном показателе нет. Учитывайте случай один раз, а дополнительные циклы показывайте отдельно как признак устойчивости проблемы.
Как выбрать окно наблюдения
Оно должно быть достаточно долгим, чтобы понять, удержалось ли решение для данного типа проблемы. После выбора используйте одно окно для сравниваемых случаев.
Можно ли оценивать сотрудников по этому показателю
Не отдельно от других данных. На возвраты влияют сложность, маршрутизация, права, дефекты продукта, информация, автоматизация и правила закрытия. Сначала используйте его как сигнал качества процесса.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники



