Метрики полезности ассистента сотрудников без пустого DAU

Почему DAU не показывает пользу

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

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

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

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

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

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

DAU можно оставить как фоновую метрику. Главные цифры должны отвечать на другой вопрос: помог ли ассистент довести рабочую задачу до конца с меньшим числом действий и правок.

Что считать полезным действием

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

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

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

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

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

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

Если вызовы модели идут через API-шлюз вроде RU LLM, проще связать запрос модели с событием в рабочей системе. Тогда видно, где сотрудник просто прочитал ответ, а где дошел до результата. Из таких связок и строятся нормальные метрики, а не из пустого счетчика открытых чатов.

Как считать принятие ассистента сотрудниками

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

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

Формула простая:

Принятие за неделю =
сотрудники с хотя бы 1 решенной задачей через ассистента /
сотрудники с реальным доступом

Допустим, у вас 120 сотрудников с рабочим доступом. За неделю 46 человек решили через ассистента хотя бы одну задачу: подготовили ответ клиенту, нашли нужный регламент или собрали черновик письма. Значит, недельное принятие равно 38%.

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

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

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

Если вы используете RU LLM, такую метрику удобно собирать по логам запросов и тегам сценариев. Тогда вы видите не просто факт обращения, а рабочий контекст: кто использовал ассистента, в какой команде и для какой задачи.

Как измерять долю правок

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

Для этого нужно хранить две версии: исходный ответ ассистента и финальный вариант, который ушел клиенту, в CRM или во внутреннюю систему. Без пары "было -> стало" метрика быстро превращается в догадки.

Что считать правкой

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

Базовый расчет простой: выберите единицу сравнения, посчитайте, сколько единиц изменил сотрудник, и разделите это число на общий объем черновика. На выходе получите долю правок в процентах.

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

На практике разница видна сразу. Если менеджер поддержки поменял восемь слов из 120, и все правки касались вежливости, ассистент сработал хорошо. Если он исправил всего два поля из 15, но одно из них было "сумма лимита", это уже серьезная ошибка.

Как читать цифры

Среднее значение почти всегда сглаживает картину. Лучше показывать медиану и распределение. Например, у половины ответов правок меньше 10%, у 30% - от 10% до 30%, у 20% - больше 30%. Такой срез сразу показывает, где ассистент пишет почти готовый черновик, а где сотрудники делают половину работы заново.

Сравнивайте эту метрику по сценариям, отделам и моделям. В продажах допустима одна доля правок, в юридических ответах совсем другая. Одна модель может хорошо писать письма, но плохо заполнять поля в заявке. Если запросы идут через RU LLM, удобно связывать request_id, выбранную модель и финальный результат сотрудника, чтобы строить такие срезы без ручной сверки.

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

Как фиксировать завершение задачи

Завершение задачи считают не по ответу ассистента, а по действию в рабочей системе. Если сотрудник попросил написать письмо, финал наступает, когда он отправил письмо. Если он оформлял заявку, финалом будет новая запись в CRM, Service Desk или другой системе. Для отчета финалом будет сохраненный документ с нужным статусом, а не просто открытый черновик.

Эта метрика ближе всего к реальной пользе. Она показывает, довел ли ассистент человека до результата, а не просто удержал его в чате на пару минут.

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

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

Формула тоже простая: доля завершенных задач равна числу сессий с финальным событием, деленному на число сессий, где пользователь начал задачу с ассистентом. Если 200 сотрудников открыли сценарий "ответ клиенту", а 118 потом реально отправили ответ в том же окне, completion rate равен 59%.

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

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

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

Что говорят повторные обращения

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

Быстрый повтор чаще всего говорит о сбое. Когда человек через пять минут снова задает почти тот же вопрос по той же заявке, он не получил рабочий ответ. Часто это выглядит так: оператор спросил, как провести возврат, получил общий текст, попробовал выполнить действие и тут же вернулся с тем же вопросом, только в другой формулировке.

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

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

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

Хорошая практика, привязывать повторы к теме: номеру тикета, клиентскому кейсу, договору или внутренней заявке. Если запросы идут через инфраструктуру с аудит-трейлами, такие цепочки проще собирать без ручной разметки.

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

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

Пример на одной рабочей задаче

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

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

Теперь посмотрим на долю правок. Допустим, ассистент выдал 200 слов, а менеджер переписал около 100. Это высокая доля правок, примерно 50%. Такой ответ сэкономил время только частично. Если же сотрудник поменял имя клиента, дату и одну фразу про срок поставки, доля правок низкая, и черновик попал ближе к задаче.

Повторное обращение видно не хуже. Менеджер отправил первый запрос, прочитал ответ и через три минуты снова пишет почти то же самое: "Сделай еще раз, но без общих фраз". Это повтор по той же задаче. Его стоит помечать отдельно, потому что с первого раза ассистент не снял потребность.

Как это выглядит в цифрах

Для такой цепочки достаточно четырех метрик:

• завершение задачи = 1, если письмо ушло клиенту после одной сессии;
• доля правок = объем измененного текста / объем черновика ассистента;
• повторное обращение = 1, если сотрудник вернулся с тем же вопросом в коротком окне времени;
• принятие = доля сотрудников команды, которые используют этот сценарий каждую неделю.

Например, в команде 20 менеджеров. На первой неделе ассистентом для писем о задержке пользуются 7 человек. Через месяц уже 14. Принятие растет с 35% до 70%. Если при этом средняя доля правок падает с 45% до 18%, а повторные обращения случаются реже, вы видите реальную пользу, а не просто движение в интерфейсе.

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

Где метрики ломаются

Самая частая ошибка проста: команда считает использованием любое открытие чата. Это шум. Сотрудник мог кликнуть случайно, открыть окно из любопытства или зайти проверить, работает ли ассистент.

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

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

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

С долей правок ошибка похожая. Одна норма для всех задач не работает. Черновик письма почти всегда редактируют, и это нормально. Готовый ответ на типовой вопрос или SQL-запрос должны требовать меньше правок. Если сравнивать их одной линейкой, метрика начнет врать.

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

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

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

Если этого не сделать, цифры будут аккуратными только на слайде. В работе они быстро рассыплются.

Короткий чек-лист перед запуском

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

Перед запуском проверьте пять вещей.

1. Для каждого сценария задайте явный старт и явный финал. Если сотрудник просит составить ответ клиенту, стартом будет первый запрос, а финалом - отправленный ответ или сохраненный черновик с нужным статусом.
2. Свяжите ответ ассистента с действием в продукте. Один лог с текстом ответа бесполезен, если вы не видите, что сотрудник сделал потом.
3. Разведите тестовые и боевые сессии. Иначе несколько дней внутренней проверки сломают картину по принятию и по доле правок.
4. Разложите цифры по срезам: команды, сценарии, модели, права доступа. Общая цифра почти всегда скрывает проблему.
5. Назначьте одного владельца обзора метрик. Кто-то должен раз в неделю открывать дашборд, разбирать скачки и задавать неудобные вопросы.

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

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

Что сделать дальше

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

Так у вас появится нормальная точка сравнения. Иначе цифры быстро превратятся в набор красивых чисел без смысла. Рост использования сам по себе ничего не говорит, если задача все еще закрывается долго или люди переписывают ответ почти с нуля.

Дальше нужен простой план. Подключите события еще до выхода в прод: принят ли ответ целиком, сколько текста сотрудник исправил, завершил ли он задачу, вернулся ли к ней повторно. Заранее зафиксируйте пороги успеха. Например, принятие выше 40%, доля правок ниже 30%, повторные обращения не растут, время до завершения падает хотя бы на 15%. Отдельно договоритесь, что считать сигналом проблемы: резкий рост ручных правок, высокий процент повторов по одной категории или хорошее принятие при слабом завершении задачи. И до масштабирования проверьте логи, аудит-трейлы и хранение данных в РФ, а не после первого инцидента.

Если у команды несколько моделей, разные провайдеры и жесткие требования по данным, удобнее сразу строить такие замеры на одном контуре. В этом месте RU LLM может быть полезен как единый OpenAI-совместимый шлюз: он упрощает сбор логов, связывание запросов с рабочими событиями и хранение данных внутри РФ. Сами метрики он не заменяет, но считать их и сравнивать сценарии становится заметно проще.

Хороший первый результат выглядит довольно скучно, и это нормально: один сценарий, несколько событий, ясные пороги. Зато уже через две-три недели видно, где ассистент реально экономит время, а где его еще нужно доработать или ограничить.