Статья CX Network: PRR - метрика, которая нужна всем ИИ-ориентированным CX-командам
По мере развития ИИ-агентов традиционных метрик клиентского опыта становится недостаточно - раньше во многих сценариях результат можно было оценить в момент завершения обращения: клиент получил ответ, вопрос закрыт, повторного обращения нет - значит, проблема решена.
Но ИИ-агенты теперь не только отвечают на вопросы, а совершают действия от имени клиента, поэтому ошибка может проявиться уже после завершения диалога, но в самой системе поддержки обращение будет выглядеть как успешно решённое. Поэтому возникает необходимость измерять не только факт решения, но и устойчивость этого решения после завершения контакта.
CX Network предлагают новую метрику: Post-Resolution Rework Rate - процент клиентских взаимодействий, решённых ИИ, которые позже потребовали корректирующих действий со стороны клиента, сотрудника или операционной команды. Проще говоря - доля повторной работы после решения обращения.
Главная проблема существующих метрик - они фиксируют результат в определённой точке клиентского пути, а не конечный исход ситуации. Но отсутствие повторного обращения ещё не означает отсутствие повторной работы.
Основные принципы работы метрики
🟢 Оценивать нужно не закрытие обращения, а конечный результат - для каждого клиентского сценария необходимо определить, что именно означает "проблема действительно решена"
🟢 Использовать окно наблюдения - нельзя оценивать устойчивость решения сразу после завершения диалога. Для разных сценариев нужен разный период, в течение которого может проявиться ошибка. Поэтому в расчёт PRR должны попадать только те обращения, для которых этот период уже завершился
🟢 Отслеживать события после первоначального решения - нужно связать первоначальное обращение с последующими действиями в других системах: повторными обращениями, корректировками сотрудников, платежами, заказами, операционными процессами и так далее. При этом новое обращение не может автоматически рассматриваться как независимое от предыдущего
🟢 Фиксировать причину повторной работы - сам процент PRR показывает масштаб проблемы, но не объясняет её. Поэтому необходимо дополнительно фиксировать и классифицировать причины
🟢 Рассматривать PRR вместе с другими показателями - PRR не заменяет автоматизацию, FCR или повторные контакты. Она дополняет их показателем надёжности и устойчивости решения. Например, рост автоматизации сам по себе не обязательно означает улучшение: если вместе с ним растёт PRR, компания просто переносит работу из первой линии в последующие процессы
Источник
➖➖➖
Клиентский опыт и качество Linkedin | Telegram | VK
По мере развития ИИ-агентов традиционных метрик клиентского опыта становится недостаточно - раньше во многих сценариях результат можно было оценить в момент завершения обращения: клиент получил ответ, вопрос закрыт, повторного обращения нет - значит, проблема решена.
Но ИИ-агенты теперь не только отвечают на вопросы, а совершают действия от имени клиента, поэтому ошибка может проявиться уже после завершения диалога, но в самой системе поддержки обращение будет выглядеть как успешно решённое. Поэтому возникает необходимость измерять не только факт решения, но и устойчивость этого решения после завершения контакта.
CX Network предлагают новую метрику: Post-Resolution Rework Rate - процент клиентских взаимодействий, решённых ИИ, которые позже потребовали корректирующих действий со стороны клиента, сотрудника или операционной команды. Проще говоря - доля повторной работы после решения обращения.
Формула: PRR = (кейсы, решённые ИИ, потребовавшие корректирующих действий ÷ кейсы, решённые ИИ, которые завершили период наблюдения) × 100
Главная проблема существующих метрик - они фиксируют результат в определённой точке клиентского пути, а не конечный исход ситуации. Но отсутствие повторного обращения ещё не означает отсутствие повторной работы.
Основные принципы работы метрики
🟢 Оценивать нужно не закрытие обращения, а конечный результат - для каждого клиентского сценария необходимо определить, что именно означает "проблема действительно решена"
🟢 Использовать окно наблюдения - нельзя оценивать устойчивость решения сразу после завершения диалога. Для разных сценариев нужен разный период, в течение которого может проявиться ошибка. Поэтому в расчёт PRR должны попадать только те обращения, для которых этот период уже завершился
🟢 Отслеживать события после первоначального решения - нужно связать первоначальное обращение с последующими действиями в других системах: повторными обращениями, корректировками сотрудников, платежами, заказами, операционными процессами и так далее. При этом новое обращение не может автоматически рассматриваться как независимое от предыдущего
🟢 Фиксировать причину повторной работы - сам процент PRR показывает масштаб проблемы, но не объясняет её. Поэтому необходимо дополнительно фиксировать и классифицировать причины
🟢 Рассматривать PRR вместе с другими показателями - PRR не заменяет автоматизацию, FCR или повторные контакты. Она дополняет их показателем надёжности и устойчивости решения. Например, рост автоматизации сам по себе не обязательно означает улучшение: если вместе с ним растёт PRR, компания просто переносит работу из первой линии в последующие процессы
Источник
➖➖➖
Клиентский опыт и качество Linkedin | Telegram | VK