Как оценить качество заявок из чат-бота
Пример расчёта (условные цифры): если из 200 начатых диалогов 50 заканчиваются подтверждённой заявкой, доля составляет 25%. Сначала проверьте, что все события посчитаны по одному правилу. На БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ можно согласовать события и проверить расчёт на вашем потоке.
Результат, который нужен по теме «качество заявки»
Бот собирает много контактов без задачи и срока покупки. Разделите ошибку сбора данных и реальное изменение поведения. Для этого понадобятся идентификатор, время и подтверждённый результат.
Сначала разделите задачи пользователей. В одном канале человек может искать ответ, в другом сразу оформлять заявку. Сравнение общего процента без сегментов покажет состав аудитории, а не качество бота.
Качество заявки видно в том, может ли менеджер продолжить разговор и есть ли задача, срок и исходный контекст. Сохраняйте причины отклонения, чтобы исправлять вопросы бота, а не просто собирать больше контактов.
Оценку заявки дайте менеджеру по понятным критериям: задача клиента, срок, достаточность контакта и следующий шаг. Записывайте причины отклонения. Они покажут, какой вопрос бота даёт лишние контакты без потребности.
Сведения берите из источника «CRM и критерии квалификации». Сверьте события с карточкой результата и не переносите отсутствующее событие из другого канала по предположению.
Вопрос к вам: какая доля событий отчёта подтверждается рабочей записью?
Лайфхак: отметьте на графике даты изменений сценария и источников трафика. Это поможет не принять технический сдвиг за результат.
Какие данные и решения подготовить
Опишите момент возникновения каждого события и правило его повторения. Отдельно храните начало, полезный ответ, передачу человеку и подтверждённую заявку.
Отдельно посмотрите случай «лид созревает позже первого диалога». Покажите его влияние на формулу и размер выборки вместо тихого удаления записей.
Сравните отчёт с карточками результата и несколькими исходными диалогами. Особенно проверьте случаи, где бот назвал вопрос закрытым, а человек вернулся вскоре с той же проблемой.
Пересчитайте небольшой набор вручную. Каждое расхождение между выборкой и отчётом классифицируйте до изменения сценария.
Перед тестом назначьте владельца исходных сведений и владельца текста бота. Когда правило меняется, оба проверяют одну и ту же цепочку: что введено, что сохранилось, кто получил задачу и каким сообщением она завершилась. Дата обновления без ответственного не защищает от старого ответа.
Два способа обработать запрос
Вручную. Ручной просмотр помогает понять, почему человек остановился или повторил вопрос. Его плюс - контекст. Главный риск - сделать общий вывод по слишком малой выборке.
Автоматический отчёт. Автоматический подсчёт позволяет видеть динамику по каналам и сегментам. Его сильная сторона - повторяемость, риск - пропущенные или задвоенные события.
Используйте отчёт как указатель для редактора сценария. Не переносите вывод по нескольким разговорам на весь поток без подсчёта доли.
Как запустить сценарий по шагам
Шаг 1. Определить полезные поля
Определите событие, единицу счёта и знаменатель. Проверьте правило на нескольких исходных диалогах.
Шаг 2. Передавать исходный контекст
Свяжите события с одной сессией и проверьте переходы между каналами. Потерянную связь не достраивайте предположением.
Шаг 3. Фиксировать оценку менеджера
Прочитайте примеры из сегмента с аномалией. Проверьте, совпадает ли код события с реальным действием человека.
Шаг 4. Анализировать причины отклонения
Сохраните формулу расчёта рядом с выводом. Повторите проверку после обновления событийной схемы.
Сравните автоматический расчёт с ручным на примерах «лид созревает позже первого диалога». Расхождения оформите как задачи владельцу данных, а не как произвольную поправку к отчёту.
Таблица проверки результата для «качество заявки»
Для этой задачи контролируйте показатель «доля заявок принятых менеджером». Зафиксируйте его определение, период и источник до запуска. Дополните его временем до результата и числом случаев, которые пришлось исправлять вручную. Иначе отчёт может объявить успехом отправку сообщения, за которой не было нужного действия.
Пример расчёта (условные цифры): если 50 из 200 диалогов достигли результата, это 25%. При десяти повторных записях сначала пересчитайте знаменатель. Это оценка для проверки процесса, а не обещание эффекта внедрения.
Если формула изменилась, пометьте разрыв ряда и пересчитайте контрольную выборку. Иначе сравнение месяцев станет ложным.
Вопрос к вам: сколько строк отчёта совпало с ручной проверкой исходного диалога?
Лайфхак: храните три проверочных случая рядом с описанием сценария. После каждого изменения прогоняйте их заново и добавляйте новый случай, если обнаружили повторяющуюся ошибку.
Что ещё связано
Сценарий опирается на качество исходных данных и понятную передачу исключений. В A3bot можно собрать маршрут вокруг вашей рабочей системы. Стоимость обсуждаем после разбора задачи.
Заметка эксперта
У задачи «качество заявки» есть проверяемое завершение. Бот полезен, когда он приближает к этому завершению и не скрывает задержку или ошибку. Начните с небольшого потока, подтвердите итог в основной системе и только затем расширяйте сценарий.
Напишите, какой процесс хотите автоматизировать: A3bot