Как измерять полезность бота для рабочего процесса

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

Определите рабочий результат одного сценария

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

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

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

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

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

Выберите единицу учёта и границы периода

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

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

Назначьте период и часовой пояс. Для попыток, начатых в конце периода, нужно время на завершение. Иначе последние обращения окажутся «неуспешными» только из-за даты выгрузки. Можно считать группу попыток по дате начала и проверять её исход после согласованного окна наблюдения. Незакрытые к этому моменту случаи показывают отдельно.

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

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

Разведите завершение, помощь и незакрытую задачу

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

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

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

Сложный вопрос, правильно переданный специалисту, может быть хорошим исходом маршрута. Поэтому цель «снизить долю передач любой ценой» опасна для качества. Для случая за пределами возможностей бота полезно проверить сохранность контекста и достижение результата после передачи, а не требовать ответа автоматики.

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

Посчитайте показатели на понятном учебном наборе

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

Предположим, после удаления учебных и технических записей осталось 20 реальных для нашего условного примера попыток одного сценария. К моменту сверки 12 завершены без помощи, 4 завершены с помощью, 3 не завершены и требуют разбора, 1 ещё ожидает исхода. Сумма групп: 12 + 4 + 3 + 1 = 20.

• Доля подтверждённых завершений: (12 + 4) / 20 × 100 = 80%.
• Доля завершений без помощи: 12 / 20 × 100 = 60%.
• Доля завершений с помощью: 4 / 20 × 100 = 20%.
• Доля незавершённых с разбором: 3 / 20 × 100 = 15%.
• Доля ожидающих: 1 / 20 × 100 = 5%.

В этом варианте все доли имеют один знаменатель — 20 начатых попыток выбранной группы. Если требуется доля помощи только среди завершённых, получится 4 / 16 × 100 = 25%. Это другой показатель. Подпись «помощь — 20%» без определения знаменателя оставляет читателю неверный выбор между двумя корректными расчётами.

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

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

Разберите причины остановок и ошибок

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

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

Разделяйте факт и гипотезу. «Нет следующего сообщения» — наблюдение. «Пользователю всё понравилось» — неподтверждённое объяснение. Для уточнения используйте разрешённую обратную связь, наблюдение учебного прохода или разбор безопасного фрагмента истории. Не связывайтесь с клиентом без принятого в компании порядка.

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

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

Сравнивайте версии при одинаковых условиях

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

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

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

Для оценки времени отделяйте длительность ожидания пользователя от активной работы сотрудника. Бот может долго ждать ответа человека, не занимая оператора. Обратная ситуация: короткий диалог может потребовать долгого ручного исправления данных. Сравнивать эти величины одним числом нельзя.

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

Соберите короткий отчёт и назначьте следующее действие

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

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

По результатам выберите одно улучшение и способ его проверки. Например, уточнить непонятное название направления и повторить учебный проход. Не меняйте одновременно весь диалог, правила отбора и формулу отчёта: после этого будет трудно разобраться в источнике разницы.

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

Чек-лист помогает подготовить правила отчёта. Отметки сохраняются в этом браузере; блок не подключается к боту и не измеряет его показатели автоматически.

Вопросы об оценке полезности бота

Можно ли оценивать бота только по числу сообщений

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

Передача сотруднику всегда считается неудачей

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

Какой процент завершений считается хорошим

Универсального значения для любого бота нет. Цель зависит от сложности сценария, ограничений и исходного процесса. Сначала установите свои правила и сравнимую базу, затем обсуждайте целевой результат.

Что показывать, когда обращений мало

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

Нужно ли хранить полные диалоги ради отчёта

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

Что делать, если система пока не фиксирует завершение

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