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

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

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

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

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

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

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

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

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

Схема черновика: 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.

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

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

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

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

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

Сравните обработку одних и тех же звонков с обычной ручной работой: запись → черновик → ручное исправление против запись → ручной итог. Храните версию аудио, модель ASR/LLM, настройки, источник идентификаторов CRM, редакции карточки и список ошибок. Если менеджер исправляет больше, чем экономит, или модель неверно приписывает слова клиенту, не включайте автоматическую запись в CRM. Проверка изолированного контура — отдельный этап в гайде по закрытому ИИ. Modelium не выполнял эти прогоны и не измерял конверсию или время.

Следующий шаг: возьмите одну разрешённую обезличенную запись, составьте JSON Schema для карточки и потребуйте для каждого поля таймкод и ручное подтверждение менеджера. Только после сверки решайте, нужны ли автоматизированный перенос в CRM и отдельная проверка его прав.