# Анализ звонков продаж с ИИ: локальный транскрипт и черновик CRM

Источник: https://modelium.tech/zhurnal/analiz-zvonkov-prodazh-lokalno/

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

**Источники просмотрены 26 сентября 2026 года.** Это сценарий проверки на собственных звонках, а не проведённый Modelium тест. Частотность запроса не измерялась; законность записи и обработки определяет владелец процесса по применимым правилам, а не модель.

## Что именно анализировать в звонке продаж?

Начните не с «оценки менеджера по шкале ИИ», а с **черновика двух–четырёх проверяемых фактов**: какой продукт обсуждали, какое следующее действие предложено, назван ли срок и есть ли явно высказанное возражение. Для каждого поля сохраняйте цитату, таймкод и статус «подтверждено человеком / не подтверждено / в записи нет». Это проект формы пилота, не измеренная эффективность. Не превращайте отсутствие ответа клиента в согласие и не выводите намерение купить из вежливой реплики.

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

Синтетический пример, написанный редакцией: «Пришлите расчёт в пятницу» → `next_action = отправить расчёт`, `deadline_text = в пятницу`, `deadline_date = null`, пока календарная дата и говорящий не подтверждены. Фраза «Возможно, вернёмся к вопросу» → `commitment = not_confirmed`. Это **не** результат распознавания и не реальный клиентский разговор.

## Как пройти путь от аудио до локальной модели?

**Шаг 1 — речь.** Whisper — многоязычная модель распознавания; закреплённый README показывает локальную команду `whisper audio.flac --model turbo` [s1](#src-s1). Для русского звонка проверяйте текст на реальной выборке и не обещайте точность по одному тесту. Альтернатива для локального CPU/GPU — faster-whisper: документация показывает `device="cpu", compute_type="int8"`, сегменты с началом и концом и предупреждает, что `segments` ленивый генератор — пока его не перебрали, расшифровка не завершена [s2](#src-s2). Скорость и память в таблицах разработчика относятся к указанным им моделям, железу и аудио, **не** к этому пилоту [s2](#src-s2). Ни размер файла весов, ни такая таблица не дают минимальную память для вашего стека: тестируйте выбранные версии и длины записей на своём устройстве.

**Шаг 2 — кто говорил.** Если аудио уже разделено по двум каналам с известными ролями, используйте эту информацию и ручную сверку. Для смешанной дорожки pyannote `community-1` предлагает *локальную* разметку смен говорящих, но получение модели требует принятия условий и токена Hugging Face; в том же README `precision-2` описан как отдельный сервис на серверах pyannoteAI [s3](#src-s3). Не выдавайте облачный pipeline за закрытый контур. Метки `speaker_0` и `speaker_1` сами по себе не определяют, где менеджер, а где клиент: проверьте голоса и сдвиги таймкодов вручную на каждой тестовой записи. Загрузка модели и телеметрия тоже должны войти в [сетевую проверку](/zhurnal/proverka-offline-kontura-ii/) до использования закрытых данных; локальное вычисление одного этапа не доказывает изоляцию всей цепочки.

**Шаг 3 — структура.** В качестве кандидата для извлечения из готового транскрипта, а не для распознавания аудио, можно испытать Qwen3-8B: автор заявляет мультиязычные возможности и указывает `apache-2.0` в карточке репозитория [s4](#src-s4). Это не гарантия качества на русском разговорном языке и не юридическое заключение об условиях конкретной сборки. Для локального runtime рассмотрите Ollama; в его документации поле `format` для `/api/chat` принимает JSON Schema и отдельно показана проверка полученного JSON кодом приложения [s5](#src-s5). Сначала подберите **реальный доступный тег** модели и проверьте память, скорость и текстовый вывод на своём компьютере; в этой статье запуск не выполнялся. Подробная инструкция — в [гайде структурированного ответа](/zhurnal/structured-output-lokalno-json-schema/).

Схема черновика: `call_id`, `speaker_role`, `product_mentioned`, `next_action`, `deadline_text`, `deadline_date`, `objection_text`, `evidence_start_sec`, `evidence_end_sec`, `unknowns`. Пусть обязательными будут поля *формата*, а неизвестные значения остаются `null` или «не указано», а не выдумываются. JSON Schema проверяет форму, после чего приложение дополнительно сверяет каждую цитату с транскриптом и менеджер слушает соответствующий отрезок аудио. Валидный JSON **не** означает истинный факт [s5](#src-s5).

## Когда и как связать черновик с CRM?

До проверки человеком — **никаких прав записи в CRM** у ASR и LLM. Создайте карточку вне продуктивной CRM с ссылкой на разрешённую запись и сохраните исходный и исправленный варианты; менеджер подтверждает факт, роль говорящего, дату и нужную сделку. Недоверенный транскрипт может содержать реплики вроде «запиши мне скидку»: OWASP описывает косвенное внедрение инструкций из внешних данных и рекомендует минимальные права и человеческое подтверждение рискованных действий [s6](#src-s6). Не передавайте модели токен CRM и не считайте текст звонка командой к действию.

Например, HubSpot Calls API описывает `properties` звонка, в том числе `hs_call_body`, и `associations` с другими CRM-записями; `POST /crm/v3/objects/calls` уже создаёт запись [s8](#src-s8). Это **пример схемы одного поставщика**, а не универсальный рецепт импорта и не инструкция посылать аудио во внешнюю CRM. Если ваша CRM и политика допускают запись только краткого подтверждённого итога, не прикладывайте весь транскрипт или ссылку на запись без отдельного решения владельца данных. Для первой проверки достаточно ручного ввода подтверждённых полей сотрудником; никаких рабочих учётных данных модели не нужно.

## Как проверить результат и решить, нужен ли пилот?

Отберите обезличенные тестовые звонки с разрешённым использованием: разные акценты, шум, перебивания, разные продавцы, звонок без следующего действия и случай с неоднозначным сроком. Два проверяющих фиксируют эталонные поля и таймкоды **до просмотра черновика модели**. Отдельно считайте ошибки расшифровки важных имён/чисел, неверную роль говорящего, выдуманное обязательство, пропущенное возражение, неверную привязку к сделке и время ручной правки. NIST AI RMF Measure 2.1 требует документировать набор тестов, метрики и инструменты, но не устанавливает достаточную для вашего отдела продаж точность [s7](#src-s7). Порог остановки и критерий успеха согласуйте с владельцем процесса заранее.

Сравните обработку **одних и тех же звонков** с обычной ручной работой: запись → черновик → ручное исправление против запись → ручной итог. Храните версию аудио, модель ASR/LLM, настройки, источник идентификаторов CRM, редакции карточки и список ошибок. Если менеджер исправляет больше, чем экономит, или модель неверно приписывает слова клиенту, не включайте автоматическую запись в CRM. Проверка изолированного контура — отдельный этап в [гайде по закрытому ИИ](/zhurnal/ii-v-zakrytom-konture-i-personalnye-dannye/). Modelium не выполнял эти прогоны и не измерял конверсию или время.

**Следующий шаг:** возьмите одну разрешённую обезличенную запись, [составьте JSON Schema для карточки](/zhurnal/structured-output-lokalno-json-schema/) и потребуйте для каждого поля таймкод и ручное подтверждение менеджера. Только после сверки решайте, нужны ли автоматизированный перенос в CRM и отдельная проверка его прав.

## Источники

1. [OpenAI Whisper — README, fixed Git revision](https://github.com/openai/whisper/blob/86098128c0b4f24f0e2aa2994de830614b474227/README.md) — получено 2026-09-26
2. [SYSTRAN faster-whisper — README, fixed Git revision](https://github.com/SYSTRAN/faster-whisper/blob/ed9a06cd89a93e47838f564998a6c09b655d7f43/README.md) — получено 2026-09-26
3. [pyannote.audio — community-1 and precision-2, fixed Git revision](https://github.com/pyannote/pyannote-audio/blob/1752fac2bd9847aa5df0c2a708c26975104e07c5/README.md) — получено 2026-09-26
4. [Qwen — Qwen3-8B model card, fixed revision](https://huggingface.co/Qwen/Qwen3-8B/resolve/b968826d9c46dd6066d109eabc6255188de91218/README.md) — получено 2026-09-26
5. [Ollama — Structured Outputs](https://docs.ollama.com/capabilities/structured-outputs) — получено 2026-09-26
6. [OWASP — LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) — получено 2026-09-26
7. [NIST — AI RMF Core, Measure 2.1](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) — получено 2026-09-26
8. [HubSpot Developer Docs — Calls API guide](https://developers.hubspot.com/docs/api-reference/crm-calls-v3/guide) — получено 2026-09-26