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

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

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

Среднее время ожидания
Для входящих звонков важно отслеживать время, которое клиент проводит в очереди до соединения.
Длинное время ожидания может вызывать недовольство клиентов и приводить к потере звонков.

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

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

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

Сегментация по сентименту
Современные нейронные сети умеют анализировать эмоциональную окраску разговора. Речь клиента в разговоре с менеджером можно разделить на 3 типа по эмоциональному окрасу: позитивная, негативная или нейтральная.
Тем самым выделить звонки, которые стоит проверить (с негативным окрасом), или сопоставить с конверсией, чтобы понять, почему при позитивном окрасе конверсия не была достигнута, что менеджер не дожал.

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

#advice

Всем привет! 👋

Опубликовал на своем сайте небольшую статью на тему «Как ускорить дашборд?».

Если кратко, то:
➖ Оптимизируйте SQL-запросы
➖ Откажитесь от представлений
➖ Добавьте индексы и партиции
➖ Подготовьте витрины данных
➖ Перейдите на аналитическую БД
➖ Увеличьте ресурсы БД и сервера
➖ Уменьшите период фильтрации
➖ Упростите дашборд

Получается, что ускорение дашборда - это в основном работа не с самим дашбордом, а с базой данных.
Подробнее читайте на моем сайте.

#material

📊 Дашборд для дашбордов – бывает и такое. В своей практике я часто создаю дополнительный дашборд для контроля качества данных и метрик основных дашбордов.

На такой дашборд обычно выводятся графики и таблицы, которые показывают:
➖ пропуски в поступающих из внешнего источника данных
➖ динамику изменения кол-ва строк в таблицах базы для поиска аномалий
➖ таким же образом пропуски и аномалии в наиболее важных расчетных метриках
➖ инциденты в этапах сбора и подготовки данных (например, кол-во задач по экспорту, которые завершились успешно или неудачно)
➖ время, которое затрачивается скриптами и коннекторами на экспорт/импорт данных
➖ статистику использования дашбордов пользователями, если ее позволяет собрать BI-система (Google Looker, например, позволяет подключить GA, как к сайту)

Такой дашборд поможет отслеживать динамику изменения в качестве собираемых данных и в надежности процессов по сбору и обработке (ETL).

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

✔️ Если нужна моя помощь в мониторинге качества данных, пишите через сайт или в лс!

#useful

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

Есть несколько самых частых проблем, о которых говорят бизнес-пользователи дашбордов:
➖ «Похоже, что данные на дашборде не верные, но нет возможности узнать из-за технических вопросов или бизнес-проблем».
➖ «Цифры, которые мы видим в одном дашборде, не совпадают с цифрами в другом» или что часто встречается мне: «не совпадают с тем, что мы посчитали в экселе»
➖ «Данные за нужный период отсутствуют».
➖ «Метрика рассчитывается неверно» или «у нас другое определение этой метрики и методика ее расчета» (например, «Выручка», «Активные клиенты» и т.п.).

Чтобы показать решения этих проблем, автор разделяет работу с данными на слои:
1️⃣ Слой сырых данных – это все, что касается получения данных из внешних источников, их преобразования и хранения (ETL-процессы, пайплайны, БД и т.д.).
2️⃣ Слой обработки данных – на этом слое поступившие данные обрабатываются и сохраняются в витрины данных (специальные таблички для использования в дашбордах).
3️⃣ Слой метрик – здесь идет работа над созданием бизнес-метрик.
4️⃣ Контекстный слой – на этом слое фокусировка происходит на том, как пользователь данных взаимодействует с данными.

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

На 3-м слое контролируется соответствие формул расчета метрик документации, создаются мониторинг и алерты по бизнес-метрикам, проводится обучение пользователей правильному пониманию метрик.

На 4-м слое стандартизуют создание дашбордов, проводят обучение пользователей правильному пониманию и использованию того, что выведено на дашборд.

Хороший подход для компаний с развитой командой аналитиков!

#material

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

И вот почему:
➖ Во-первых, цифры могут быть недостоверными, устаревшими или не полными. Перед тем, как делать выводы, стоит перепроверить показатели сравнением с другим источником или старыми периодами в дашборде. Особенно, если вы заметили сильное отклонение в метриках.
➖ Во-вторых, далеко не всегда на дашборде отображаются нужные метрики или достаточное кол-во метрик, по которым можно принимать решение. Предположим, вы развиваете партнерскую программу, и для оценки вывели на дашборд метрики «Кол-во рефералов по партнеру», «Сумма вознаграждения партнера», «Выручка с реферала». Казалось бы, по этим тремя метрикам можно оценить и эффективность партнерской программы в целом и каждого партнера в отдельности. Но если каждый реферал может стать партнером, то это в корне меняет ситуацию, и нужны метрики, которые покажут наличие и выручку рефералов 2-го и т.д. уровней.
➖ Дашборд может не показывать влияние внешних и внутренних факторов. Упали продажи, трафик и т.д. – нужно понимание, идет ли влияние общей тенденции или сезонности на рынке. Изменились процессы, структура в компании – это тоже может отразиться на метриках.
➖ Дашборды зачастую не учитывают человеческий фактор, который играет существенную роль в бизнесе. При чем, как внутри компании, так и вне ее (поведение потребителей, реакция местных властей и т.д.).
Стоит хотя бы вспомнить ситуацию с Xsolla, когда только на основе данных модели машинного обучения были уволены около 100 человек. Все ради сохранения роста в 40% в год. По данным Bloomberg в 2021 году у нее была выручка 100 млн дол. Интересно, помогло ли...

#advice

Всем привет! 👋

Часто в компаниях вместе с аналитиками (или вместо них) дашборды создают или правят менеджеры, руководители или владельцы компании. В целом это понятно – кто же, как не руководитель отдела продаж знает все про свое дело: знает какие показатели ему нужно контролировать, в каком разрезе, как выводить на дашборд, и сделает это быстрее, чем напишет ТЗ для аналитика.

В небольших компаниях это оправдано и экономически выгодно. Но в компаниях, где есть свой аналитик, а также большое количество потребителей дашбордов, это может привести к проблемам. И вот почему:
➖ Во-первых, менеджер или руководитель не учитывает технические аспекты: построенный самостоятельно дашборд может сильно грузить базу данных, потреблять лишние платные ресурсы или тормозить работу других дашбордов.
➖ Во-вторых, он может использовать не те данные или не верно составить формулу расчетной метрики. Например, посчитать выручку, взяв один параметр из таблицы и не учесть наличие другого параметра, который влияет в некоторых случаях.
➖ В-третьих, используя общие датасеты (в Яндекс Даталенсе датасет описывает набор данных и его структуру), менеджер может изменить формулу ранее созданной метрики. При этом не факт, что он вспомнит, в чьих дашбордах еще используется эта метрика. Тем самым, у других пользователей данные на дашборде могут существенно исказиться.

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

#useful