Полезность определяется задачами, которые команда смогла обработать, а не количеством уведомлений.
Разделите этапы
Найденное сообщение проходит проверку, может оказаться подходящей задачей, затем привести к предметному разговору. Сделка появляется ещё позже и зависит от предложения компании. Если всё назвать лидами, невозможно понять, где система работает, а где возникает проблема.
Смотрите на причины потерь
Условный пример: большинство сообщений не подходит по услуге — корректируйте источники и фильтры. Подходящие задачи остаются без проверки — разберите процесс команды. Разговоры начинаются, но предложение не выбирают — изучите условия услуги и обработку. Эти ситуации требуют разных изменений.
Что включить в оценку
При небольшом объёме полезна таблица событий и причин решений. Отсутствие сделки по одному запросу не доказывает бесполезность всего источника.
- Количество найденных сообщений
- Число проверенных подходящих задач
- Предметные обсуждения
- Причины отказа или потери актуальности
- Время команды и расходы по процессу
Как принимать решение
Сравните ожидаемую пользу с затратами на настройку и разбор. Для длинного цикла сделки задайте период наблюдения и не сравнивайте незавершённые задачи с уже закрытыми. Меняйте один элемент процесса за раз, чтобы понимать причину следующего результата.
Выберите результат по рабочему процессу
Полезность определяется проверенными релевантными ситуациями, временем разбора и дальнейшим допустимым продолжением. Количество сигналов показывает объём, но не коммерческий эффект. Заявка возникает на другом этапе.
Отдельно показывайте отклонения, повторы и неизвестный результат. Если команда не успевает проверять сообщения, масштаб источников может ухудшить процесс. Сопоставляйте наблюдения с реальной возможностью отвечать.