Я упростил речевую аналитику до одного экрана. Но этого оказалось мало

Я почти свёл основную работу с речевой аналитикой к одному экрану и сократил запуск до одной встречи. Но после более чем 100 пилотов стало видно: главный барьер для части компаний находится уже не в интерфейсе.

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

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

Команда постепенно именно этим и занималась.

Сейчас основная работа фактически помещается в один экран. На нём видно:

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

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

По смыслу это светофор.
Открыл. Увидел, что всё стабильно. Закрыл.
Или увидел отклонение и провалился глубже.

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

Запуск тоже перестал быть большим проектом

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

Поэтому от речевой аналитики я сначала ожидал похожей сложности.

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

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

И именно после этого стало заметнее третье ограничение.

Понятный отчёт не всегда отвечает на вопрос “что дальше?”

Формально клиент редко говорит:

Я вижу цифры, но не понимаю, что с ними делать.

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

Для меня следующий ход привычен:

1. Я бы посмотрел несколько примеров.
2. Проверил, одинаково ли проявляется отклонение.
3. Сравнил бы сильные и слабые разговоры.
4. Попробовал отделить случайность от повторяющегося сигнала.
5. После этого сформулировал бы вопрос для следующей проверки.

Но такой маршрут возникает не у каждого клиента автоматически.
Раньше внутри меня появлялось сопротивление: “Здесь же всё видно”.
Теперь я считаю эту реакцию ошибочной.

Руководитель не обязан становиться исследователем данных

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

У руководителя продаж может быть совершенно другой рабочий контекст.
Найм.
План.
Клиенты.
Маркетинг.
Сезон.
Деньги.
Операционные вопросы.

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

Это отдельная работа.
Я уже писал об этом раньше в материале «Почему клиент не хочет быть аналитиком». Тогда это был вывод из одного конкретного проекта.

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

Я пытался убрать сложность из интерфейса, а часть сложности оказалась после него

Хорошая речевая аналитика может сократить путь до факта.
Например:
показатель упал -> отклонение связано с двумя сотрудниками -> вот конкретные разговоры -> вот фрагменты, на которых основана оценка.

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

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

Один и тот же сигнал в двух компаниях может означать разное

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

Но что он означает?
В одной компании цель первого звонка - назначить замер.
В другой - квалифицировать клиента.
В третьей - привести человека в салон.
Где-то после разговора менеджер должен согласовать следующий контакт сам.
Где-то следующий этап запускается автоматически и отдельная договорённость не нужна.

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

Поэтому фраза:

Показатель низкий, значит, здесь ваша проблема.

может быть слишком сильной.
Сначала нужен контекст.

Сигнал не равен причине

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

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

Возможные объяснения:

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

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

Но внешний специалист тоже не может просто поставить диагноз

Когда стало понятно, что клиенту может не хватать времени на такую исследовательскую работу, возник простой ответ:

Хорошо. Тогда специалист посмотрит данные и принесёт готовые выводы.

Я попробовал двигаться в эту сторону и быстро увидел обратное ограничение.
Без клиента качественная интерпретация тоже разваливается.

Внешний аналитик может быстрее работать с массивом. Может находить повторения, сравнивать сотрудников, собирать выборки и проверять критерии.

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

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

Если интерпретацию полностью забирает внешний специалист - возникает риск красивого диагноза без достаточного контекста.

Рабочая зона находится между этими крайностями

У клиента есть:

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

У меня и команды есть другое:

• быстрый доступ к большому массиву разговоров;
• повторяемая методика проверки;
• возможность сравнивать периоды и сотрудников;
• поиск конкретных примеров;
• калибровка критериев;
• возможность быстро менять вопрос исследования.

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

Именно эта цепочка сейчас сильнее всего меняет моё понимание продукта.

Это не отменяет ценность платформы

Из предыдущего вывода легко сделать ещё одну ошибку:

Значит, программа не нужна. Нужен хороший консультант.

Я так не думаю.

Без платформы каждый новый вопрос снова превращается в ручное исследование.
Нужно выбирать записи.
Слушать.
Выписывать фрагменты.
Считать повторения.
Сравнивать сотрудников.

Если вопрос изменился, значительную часть работы приходится делать заново.

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

Поэтому вопрос для меня теперь не “продукт или услуга”.
Вопрос другой:

Как соединить скорость технологии и человеческую интерпретацию, не начиная придумывать бизнес за клиента?

Что изменилось в моём понимании речевой аналитики

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

Продукт должен сокращать путь:
от наблюдения -> к вопросу -> к проверке -> к следующему решению.

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

Пока моя рабочая гипотеза выглядит так:

Клиент приносит контекст и управленческий вопрос. Я и команда помогаем быстрее проверить его на фактуре реальных разговоров. Вывод появляется на пересечении этих двух частей.

Это уже заметно отличается от идеи “подключить речевую аналитику и показать отчёт”.

Почему я решил отдельно исследовать рынок

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

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

• аудит звонков;
• внешний контроль качества;
• экспертный разбор;
• аналитическое сопровождение;
• обучение;
• консалтинговые проекты по продажам.

Поэтому следующим шагом я отдельно изучил именно этот слой рынка.
Не “кто лучше расшифровывает речь”.
А:

Кто и за какие деньги берётся превращать результаты анализа в выводы, рекомендации и следующую работу?

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