Помочь применить это руководство?Спросить команду DripTell
Считайте обращение переведенным в самообслуживание только тогда, когда клиент выполнил задачу без помощи сотрудника, а результат сохранился в течение разумного периода наблюдения. Завершение чата ботом, молчание клиента или отсутствие созданной заявки еще не доказывают решение проблемы.
Это различие важно, потому что показатель deflection может объединять разные события. В действующем справочнике Intercom в него входят успешные решения, уход клиента до ответа и уход после негативной реакции. Панель Microsoft также относит к deflection разговоры, которые бот решил либо пользователь покинул до решения. А панель Google показывает решение, плановую передачу, эскалацию и уход отдельно.
Каждое определение может быть полезно для конкретной системы. Ошибка начинается тогда, когда любую закончившуюся автоматическую сессию выдают за решенную задачу клиента.
| Область | Что проверить |
|---|---|
| Сначала определите результат клиента | Начинайте с задачи, а не с канала. Клиент хочет проверить заказ, перенести встречу, получить счет или понять правило возврата. |
| Разделяйте пять конечных состояний | Одна доля скрывает разницу между полезной автоматизацией и отказом клиента продолжать. Сохраняйте как минимум пять исходов: |
| Дайте результату время подтвердиться | Выбирайте период наблюдения по намерению. Ответ о часах работы можно проверить за день. Возврату денег может понадобиться семь дней или событие платежа. |
| Используйте один знаменатель | Знаменателем должны быть допустимые попытки самообслуживания. Проверенный коэффициент решения равен сумме подтвержденных и наблюдаемых решений, разделенной на число таких попыток. |
Сначала определите результат клиента
Начинайте с задачи, а не с канала. Клиент хочет проверить заказ, перенести встречу, получить счет или понять правило возврата. Для каждого намерения опишите, что означает завершение и какое событие это подтверждает.
Просмотр статьи или ответ бота не равны завершению. Для вопроса о заказе доказательством может быть показ актуального статуса и отсутствие повторного вопроса о том же заказе в следующие два дня. Для переноса встречи нужна реально обновленная запись, а не только сообщение с предложением времени.
Заранее определите допустимые попытки. Исключите спам, дубли, исходящие уведомления, периоды сбоя и действия, которые по правилам обязан выполнять человек. Публикуйте этот охват рядом с показателем, чтобы знаменатель не менялся незаметно.
Разделяйте пять конечных состояний
Одна доля скрывает разницу между полезной автоматизацией и отказом клиента продолжать. Сохраняйте как минимум пять исходов:
- Подтвержденное решение, когда клиент сообщает об успехе или нужная операция завершается.
- Наблюдаемое решение, когда поведение подтверждает результат и в заданном окне нет повторного контакта с тем же намерением.
- Уместная передача, когда автоматизация распознает ограничение и безопасно передает контекст.
- Уход, когда клиент покидает диалог до известного решения или безопасной передачи.
- Ошибка, когда ответ неверен, действие ломается или клиент возвращается с той же задачей.
Уместная передача не является самообслуживанием, но и не равна провалу. Например, для сброса пароля может требоваться проверка личности сотрудником. Если наказывать такую передачу, бот будет продолжать разговор там, где безопаснее остановиться.
Дайте результату время подтвердиться
Выбирайте период наблюдения по намерению. Ответ о часах работы можно проверить за день. Возврату денег может понадобиться семь дней или событие платежа. Изменение аккаунта стоит считать завершенным после подтверждения, что новая настройка сохранилась.
Единого честного окна не существует. Слишком короткое завышает успех до появления повторных контактов, слишком длинное связывает несвязанные разговоры. Документируйте правило для каждого главного намерения, проверяйте его на реальных историях и не меняйте во время сравнения периодов.
В документе ServiceNow об измерении самообслуживания приведен конкретный вариант с отсутствием заявки в течение суток и дополнительными сигналами вовлеченности или оценки. Смысл примера не в универсальности суток, а в явном правиле наблюдения.
Используйте один знаменатель
Знаменателем должны быть допустимые попытки самообслуживания. Проверенный коэффициент решения равен сумме подтвержденных и наблюдаемых решений, разделенной на число таких попыток.
Представим 1000 попыток. Из них 430 закончились подтвержденным решением, 270 наблюдаемым решением без повторного контакта, 140 уместной передачей, 90 уходом, а 70 ошибкой или повторным обращением. Определение, которое включает уход, может показать 79 процентов. Проверенный результат самообслуживания составляет 70 процентов. Рядом покажите 14 процентов передач, 9 процентов уходов и 7 процентов ошибок.
Это условный пример, а не отраслевой ориентир. Он нужен, чтобы классификацию можно было понять и воспроизвести.
Сопоставляйте показатель с признаками неудачи
Не оптимизируйте одну итоговую цифру. Смотрите на повторный контакт по той же задаче, переход в другой канал, повторное открытие, передачу сотруднику, исправление ответа, усилие клиента и завершение реальной операции. Разбивайте результаты по намерению, языку, точке входа и версии автоматизации.
Рост deflection вместе с повторными обращениями обычно означает, что измерение вознаграждает молчание. Снижение показателя при более быстрой передаче и меньшем числе возвратов может быть настоящим улучшением. Справочник Microsoft по бизнес метрикам разделяет самообслуживание и решение при первом контакте, включая возврат клиента в течение семи дней. Эти метрики отвечают на разные вопросы.
Читайте и выборку диалогов. События сообщают о завершении сессии, а текст показывает неясный ответ, смену вопроса или зацикливание.
Сохраняйте связанную историю клиента
Честное измерение трудно построить, если веб чат, сообщение WhatsApp и последующая заявка выглядят как три разных клиента. Где позволяют согласие и правила, используйте устойчивый ключ клиента и намерения. Храните версию автоматизации, доказательство результата, причину передачи, владельца и последующий контакт.
Связанная история, владелец, статус, заметки и следующее действие в общем ящике DripTell помогают увидеть возвращение клиента через другой поддерживаемый канал. Ящик не решает, закрыта ли задача. Он сохраняет данные для обоснованного решения.
Начните с пяти самых частых намерений. Для каждого определите завершение, допустимость, период наблюдения и безопасную передачу. Пересчитайте последние четыре недели и исправьте путь с наибольшим разрывом между видимым deflection и проверенным решением. Чтобы сопоставить метод с вашей операцией, обсудите ее с DripTell.
Часто задаваемые вопросы
Какой показатель deflection считается хорошим
Универсального значения нет, потому что задачи, правила допустимости и окна наблюдения различаются. Полезный показатель воспроизводим, не считает уход решением и улучшается без роста повторных контактов и усилий клиента.
Считается ли уход клиента успешным переводом
Он может входить в специальную метрику платформы, но не должен считаться проверенным решением без других надежных доказательств выполнения задачи.
Как выбрать период наблюдения
Свяжите его с задачей. Для мгновенной информации подойдет короткий срок, а для возврата, доставки или изменения аккаунта нужен более долгий период либо событие завершения. Опубликуйте правило и применяйте его последовательно.
Должна ли безопасная передача снижать результат
Она снижает долю самообслуживания, поскольку понадобился сотрудник, но ее следует отделять от ошибки. Быстрая передача с полным контекстом может быть лучшим исходом для клиента.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники