Разбираю практическую схему: аудио звонка становится текстом, текст превращается в договорённости, а договорённости уходят в CRM без ручного конспекта.

Менеджер после звонка обычно делает пять мелких действий: вспоминает детали, пишет краткую сводку, отмечает потребность клиента, ставит задачу, переносит дату следующего контакта. Каждое действие кажется маленьким. На серии из 8–12 звонков в день эта рутина легко съедает до 2 часов, особенно если разговоры длятся по 10–20 минут и по каждому нужно сохранить контекст.

Я смотрю на такие инструменты не как на «магическую кнопку», а как на конвейер из понятных этапов. Сначала аудио переводится в текст. Затем текст очищается, разделяется по спикерам и отправляется на смысловой анализ. После этого система формирует структурированный результат: краткое резюме, договорённости, риски, задачи, дату следующего шага. Финальный слой передаёт данные в CRM или отдаёт их человеку на проверку.

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

Из чего состоит система разбора звонков

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

Третий слой отвечает за смысл. Языковая модель получает стенограмму и инструкцию: найти факты, отделить точные договорённости от предположений, вытащить даты, суммы, названия продуктов, условия оплаты, следующий шаг. Четвёртый слой превращает ответ в формат, который принимает CRM: задача, комментарий, тег, стадия сделки, поле «следующий контакт».

Аудио звонка → распознавание речи → стенограмма → смысловой анализ → задачи и поля CRM

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

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

Что делает распознавание речи, а что делает нейросеть

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

Сравнение помогает быстро увидеть границы каждого подхода.

Подход Что получается на выходе Где полезен Ограничение
Ручные заметки менеджера Краткий конспект в свободной форме Малые команды, редкие звонки, сложные переговоры Контекст теряется, формат зависит от дисциплины человека
Только транскрибация Полный текст разговора Контроль качества, поиск спорных фраз, обучение новичков Текст длинный, задачи и договорённости нужно искать вручную
Транскрибация плюс нейросеть Сводка, договорённости, риски, задачи Продажи, поддержка, онбординг, проектные созвоны Нужны промпты, проверка фактов и правила передачи в CRM
Полный контур с CRM Заполненная карточка, задачи, теги, следующий шаг Команды с регулярным потоком звонков Требуется интеграция, журнал ошибок и права доступа

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

Практический конвейер: от аудио до задачи

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

  1. Запись попадает в хранилище после завершения звонка.
  2. Сервис распознавания речи создаёт стенограмму и метки спикеров.
  3. Нормализатор чистит повторы, междометия, слишком длинные паузы, но не меняет смысл.
  4. Языковая модель извлекает сущности: компанию, контакт, проблему, договорённость, срок, ответственного.
  5. Валидатор проверяет, что задача имеет минимум три поля: действие, исполнитель, срок или условие следующего шага.
  6. Интеграционный слой создаёт комментарий и задачу в CRM.
  7. Человек видит результат и может подтвердить, исправить или отклонить запись.

Последний пункт часто недооценивают. На старте автоматическая запись в CRM без проверки выглядит заманчиво, но ошибка в дате следующего контакта может стоить сделки. Я предпочитаю мягкий запуск: первые 2–4 недели система предлагает карточку, менеджер подтверждает, а руководитель смотрит частоту правок. Когда типовые ошибки понятны, часть действий можно переводить в автоматический режим.

Модельный кейс: отдел продаж с 12 менеджерами проводит около 90 звонков в день, и каждый сотрудник тратит 6–10 минут на послезвонковую фиксацию итогов. При таком объёме автоматическая сводка экономит десятки человеко-часов в неделю, даже если менеджер всё равно проверяет результат перед отправкой в CRM. Здесь ценность не в полной замене человека, а в снятии механического набора текста.

Какие поля извлекать из звонка

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

Базовый отчёт после звонка может включать:

  • краткое резюме на 3–5 предложений;
  • статус клиента: интерес, сомнение, отказ, повторный контакт;
  • ключевую потребность клиента;
  • возражения и вопросы;
  • договорённости с прямой привязкой к фразам из стенограммы;
  • задачи с исполнителем и сроком;
  • риски, если клиент назвал бюджет, конкурента, юридическое ограничение или техническую зависимость.

Для примера: если клиент говорит «пришлите расчёт до пятницы, я покажу финансовому директору», корректная задача звучит так: «Подготовить расчёт и отправить клиенту до пятницы». Некорректная версия: «Клиент готов согласовать покупку». Во второй формулировке модель уже додумала решение, которого в разговоре не было.

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

Как писать промпт для сводки звонка

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

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

Условный пример: для звонка длительностью 18 минут промпт может вернуть 1 резюме, 4 факта, 2 возражения и 3 задачи. Если задач получилось 12, это сигнал к проверке: модель, вероятно, превратила каждую реплику в действие. Если задач нет совсем, хотя клиент просил письмо или расчёт, значит инструкция слишком мягкая.

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

Контроль качества: где система ошибается

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

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

Компания из сферы B2B-услуг, ~80 сотрудников, может начать с 30 звонков в неделю и проверять только два показателя: сколько задач создано корректно и сколько задач менеджер удалил как лишние. Такой пилот не требует сложной аналитики, зато быстро показывает, можно ли доверять системе следующий шаг.

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

Что передавать в CRM автоматически, а что оставлять на проверку

Не все данные одинаково безопасны для автозаписи. Я разделяю их по риску.

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

Автоматизация должна помогать менеджеру, а не создавать вторую работу. Если после каждого звонка человек тратит 7 минут на исправление машинного отчёта, экономии нет. Нормальный целевой сценарий выглядит иначе: менеджер открывает предложенную сводку, за 30–60 секунд правит одну фразу, подтверждает задачи и идёт к следующему звонку.

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

Безопасность и права доступа

Записи звонков часто содержат персональные данные, коммерческие условия, телефоны, адреса и внутренние комментарии. Поэтому до запуска нужно описать, кто видит аудио, кто видит стенограмму, кто может выгружать отчёты, сколько хранится запись и как удаляются данные по запросу. Это не бюрократия ради галочки. Без таких правил менеджеры начинают пересылать фрагменты разговоров в личные чаты, а руководитель теряет контроль над контекстом.

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

Как запустить пилот без лишней сложности

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

План на первый месяц может быть таким. На первой неделе собрать 20–30 записей и вручную определить идеальный формат сводки. На второй неделе настроить транскрибацию и промпт анализа. На третьей неделе сравнить машинный отчёт с ручным. На четвёртой неделе подключить передачу безопасных полей в CRM: комментарий, теги, черновик задачи. Поля с высоким риском лучше оставить на подтверждение.

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

Заключение

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

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