Анализ звонков в оконной компании: как быстро понять, куда РОПу смотреть в первую очередь

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

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

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

По мере работы я пришёл к другой формулировке ценности. РОПу не нужен ИИ, который уверенно объяснит ему все продажи. Ему нужен инструмент, который из большого массива коммуникаций быстро покажет несколько мест, куда действительно стоит посмотреть.

Разница между этими подходами оказалась принципиальной.

Сначала мы пытались оценивать звонки по скрипту

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

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

Например, что именно считать корректным приветствием?
Нужно ли требовать фамилию менеджера?
Какие вопросы действительно запрещены?
Где ошибка должна снижать оценку, а где лучше оставить рекомендацию?

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

Но дальше появилась более серьёзная проблема.

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

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

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

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

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

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

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

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

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

Среди успешных и проваленных сделок можно ли быстро найти клиентов, на которых стоит обратить внимание?

Это изменило объект исследования.

Мы начинали с вопроса:

Насколько правильно менеджер провёл звонок?

А пришли к другому:

Где среди большого количества коммуникаций есть ситуация, требующая внимания РОПа?

Мы отдельно посмотрели звонки, связанные с проваленными сделками

Для следующей проверки взяли звонки за июнь и июль 2026, привязанные к сделкам в проваленном статусе. Таких звонков получилось 37.
По этой выборке система провела широкий поиск признаков возражений и отметила их в 21 звонке.

Отдельно искали ценовые сигналы вроде «дорого» или «не то, на что рассчитывал». Такие сигналы были отмечены в 14% этой выборки.
На первый взгляд схема уже похожа на готовую управленческую аналитику: проваленная сделка -> найдено возражение -> определяем причину -> меняем работу менеджеров.

Но переход от второго элемента к третьему здесь не доказан. Статус сделки говорит, чем она закончилась в CRM. Звонок показывает, что происходило в конкретный момент коммуникации.

А причина проигрыша может находиться между этими двумя точками.

Высокий процент найденных возражений ещё ничего не объясняет

В другом промежуточном отчёте по 222 звонкам система отметила наличие возражения в 64% разговоров.
Сигнал «дорого» был отмечен в 9%.

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

Что именно здесь является значимым сигналом и что с ним делать?

Процент сам по себе этого ответа не даёт. Поэтому я бы не начинал управленческий разбор с вопроса:

В скольких звонках есть возражение?

Мне полезнее другой:

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

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

Вопрос клиента легко принять за возражение

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

В другом разговоре клиент сравнивал ПВХ и алюминий и спросил, сильно ли варианты отличаются по цене. Сам вопрос ещё не означает, что цена стала препятствием покупке.

Были и обратные случаи. Клиент прямо говорил, что сейчас у него нет денег, но простой поиск слова «дорого» такой сигнал мог не поймать.

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

Иначе РОП получает точную статистику по слишком широкому понятию.

Даже «дорого» ещё не означает, что сделка проиграна из-за цены

Если клиент говорит «очень дорого» или «цена кусается», это важный сигнал.
Системе полезно его найти.
РОПу полезно быстро увидеть этот разговор.
Но следующий вывод:

Сделка потеряна из-за высокой цены.

уже требует дополнительных данных.

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

Это хороший пример границы. Система может показать:

Найден ценовой сигнал.

Но формулировка:

Причина провала - цена.

требует проверки всей сделки.

Звонок - это не вся сделка

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

У конкретного клиента маршрут может быть другим, но принцип один: отдельный разговор показывает только часть истории.
Поэтому связка: сделка в статусе «провалена» + один звонок
не равна: причина провала установлена.

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

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

Поэтому мы поменяли роль ИИ

Самая эффектная схема выглядит так: звонок -> ИИ -> причина провала -> рекомендация
Она обещает почти автоматического РОПа.

Но после реальных проверок мне ближе другая: звонок -> сигнал -> основание -> выборка -> проверка РОПом -> решение

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

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

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

Только после этого можно решать:

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

В другом проекте мы уже упирались в похожую проблему: CRM-статус и отдельный звонок нельзя автоматически считать одним и тем же результатом. Об этом писал в статье «Мы попросили AI отличить успешный звонок от неуспешного. Но сами не смогли показать ему разницу».

Что в итоге должен видеть руководитель

Я бы не хотел показывать РОПу карточку такого вида:

Причина провала: цена.
Менеджер не отработал возражение.
Рекомендация: обучение.

Это удобно читать, но часть цепочки может быть предположением.
Мне ближе другой формат:

Сигнал: клиент обсуждает цену.
Основание: конкретный фрагмент разговора.
Что произошло в доступном звонке: менеджер предложил такой-то вариант.
Чего не хватает: последующие коммуникации сделки не проверены.
Следующий шаг: открыть сделку и проверить продолжение.

То же самое можно делать с техническими ограничениями, «подумаю», прямым отказом, сохранённым интересом или отсутствием заметного следующего шага. Это менее похоже на магию. Зато руководитель видит не только вывод, но и основание для проверки.

Зачем нужен ИИ, если окончательное решение всё равно принимает РОП

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

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

Для «Дожми Продажи» это сейчас одна из наиболее понятных продуктовых границ:

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

После проверки начинается калибровка

Допустим, система показала десять разговоров с предполагаемыми возражениями.
РОП посмотрел их и говорит:

Здесь реальное возражение.

Здесь обычный технический вопрос.

Здесь клиент сравнивает варианты, но не отказывается.

Здесь важен не ценовой сигнал, а техническое ограничение.

А вот такую ситуацию система вообще не показала, хотя для нас она критична.

Эта обратная связь и делает следующий цикл полезнее.
Ложные срабатывания убираются.
Критерии уточняются.
Добавляются важные для конкретного отдела сигналы.

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

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

Что этот кейс пока не доказывает

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

И у нас пока нет данных, позволяющих приписать этому подходу рост конверсии или выручки. Есть более узкий и проверяемый результат. Автоматический анализ можно использовать как фильтр внимания руководителя: находить в массиве коммуникаций потенциально значимые ситуации, показывать основание и отдавать их РОПу для проверки в полном контексте сделки.

Для меня это уже полезная работа продукта.

Как я бы начинал такой анализ в другой оконной компании

Не со ста критериев и не с обещания найти все причины потерянных продаж. С одного управленческого вопроса. Например:

Какие проваленные сделки требуют внимания РОПа в первую очередь?

Затем определить несколько наблюдаемых сигналов.
Проверить их на реальных разговорах.
Взять небольшую выборку срабатываний и вместе с руководителем посмотреть полную историю сделок.

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

Такой путь выглядит менее эффектно, чем «подключили ИИ и получили причины потерь». Зато на выходе появляется не очередной отчёт, которому руководитель должен поверить или не поверить. Появляется проверяемый рабочий процесс.

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

Если у компании уже накоплены звонки и CRM-история, я бы начинал именно с одного такого вопроса и проверял, какую полезную выборку система способна собрать для РОПа.