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

Воронка и анализ разговоров отвечают на разные управленческие вопросы. Я понял это спустя год с лишним после спора с опытным РОПом.

В ноябре 2026 года я вернулся к переписке с опытным руководителем продаж, которая состоялась в августе 2025-го. Он спрашивал, зачем анализировать весь массив звонков, если по CRM (системе для ведения клиентов и сделок) уже видно, какие сделки требуют внимания. А я тогда объяснял преимущества автоматизации и полного охвата.

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

Для него отправной точкой была воронка

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

1. сначала смотрит воронку и показатели,
2. находит отклонение,
3. затем выбирает сделки,
4. открывает историю,
5. слушает нужные звонки.

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

У такого подхода есть понятная логика: не нужно слушать всё подряд, если руководитель уже знает, какие сделки требуют внимания.

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

Сейчас я понимаю, что на эти вопросы нельзя ответить одной фразой «ИИ проверит больше разговоров». Для своего управленческого вопроса собеседник уже использовал конкретный метод, и его нужно было рассматривать всерьёз.

А я рассказывал об охвате и автоматизации

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

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

Представим, что конверсия на одном из этапов снизилась. РОП уже заметил проблему, отобрал нужные сделки, прослушал звонки и проверяет несколько объяснений. Чем ему поможет дополнительный сервис? Может, позволит проверить более широкий массив или найти повторение признака. А может, его нынешнего способа вполне достаточно.

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

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

Две точки входа в анализ продаж

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

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

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

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

Статус «Неинтересно» не всегда объясняет разговор

Допустим, сделку закрыли в CRM со статусом «Неинтересно». Для отчёта это полезный результат: его можно учесть в конверсии, сравнить периоды и менеджеров.

Но что именно произошло в разговоре?
Клиент прямо сказал, что предложение ему не подходит?
Назвал бюджет или срок?
Менеджер выяснил потребность?
Уточнил возражение?
Договорился вернуться к вопросу позже?

Статус и ответы на эти вопросы - не одно и то же. Если в CRM сохранены подробные комментарии, запись или расшифровка, ответы могут быть уже там. Если нет, понадобится доступ к содержанию контакта.

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

Не стоит смешивать факты с объяснениями. В этом условном примере слова клиента «пока нет бюджета» можно зафиксировать как содержание разговора. А вот утверждение «сделка потеряна именно из-за бюджета» уже требует проверки контекста. Система распознавания и оценки разговоров тоже может ошибаться.

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

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

В моём ответе 2025 года была ещё одна идея: система обнаруживает отклонение и сама создаёт задачу менеджеру. Тогда это казалось почти очевидным способом освободить руководителя от ручного контроля.

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

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

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

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

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

Когда оба подхода нужны одновременно

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

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

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

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

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

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

Что я спросил бы теперь

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

Я предложил бы проверить 3 вещи:

1. Какой конкретный ответ нужен?
   Где возникло отклонение в продажах, что клиент говорил в разговоре или как часто менеджеры выполняют заданный критерий?

2. Какие данные позволят это установить?
   Достаточно ли истории CRM, нужна ли запись, выборка разговоров или сопоставление обоих источников?

3. Что изменится после проверки?
   Есть ли решение, которое руководитель сможет обоснованно принять, либо сначала потребуется дополнительное наблюдение?

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

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