Разбираю рабочую схему: от аудиофайла до чистой расшифровки, короткого резюме, списка задач и безопасной записи в CRM.

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

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

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

Где ломается путь от аудио к задаче

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

На практике я разделяю поток на четыре типа данных:

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

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

Шаг 1. Подготовить запись до распознавания

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

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

Условный пример: если 12-минутный звонок содержит 4 минуты музыки ожидания и 90 секунд разговора двух людей одновременно, система должна пометить результат как требующий проверки, а не создавать задачу «клиент ждёт КП» без уверенности. В таких местах лучше потерять минуту на ручной контроль, чем получить испорченную CRM.

Технический минимум для аудио: стабильный формат файла, нормальная громкость, отсутствие обрезанных первых секунд, корректная привязка к сущности CRM. Частота 16 кГц для речи обычно достаточна, стерео имеет смысл, когда каналы несут разных участников. Если звонки приходят из разных источников, я ставлю нормализацию перед распознаванием: система приводит громкость и формат к единому виду.

Шаг 2. Сделать расшифровку полезной, а не просто длинной

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

Хороший промежуточный формат выглядит так:

{
  «call_id»: «12345»,
  «segments»: [
    {«speaker»: «оператор», «start»: «00:01:12», «text»: «Уточню срок поставки и вернусь сегодня до пяти»},
    {«speaker»: «клиент», «start»: «00:01:18», «text»: «Да, и пришлите расчёт на двадцать пользователей»}
  ]
}

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

После распознавания я запускаю очистку. Не литературную правку, а техническую: убрать повторы, пометить неуверенные слова, восстановить пунктуацию, сохранить числа в нормальном виде. Фраза «созвон во вторник в пятнадцать» должна превратиться в дату только при наличии контекста. Если неделя не ясна, в результат лучше записать «вторник, дата не определена».

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

Шаг 3. Извлечь договорённости без фантазий

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

Пример промпта для извлечения:

Ты анализируешь расшифровку делового звонка. Верни результат строго по схеме.
Не создавай задачу, если нет явного действия, срока или ответственного.
Для каждой договорённости укажи короткую цитату из разговора.
Если дата относительная, запиши её как «требует уточнения».
Поля: summary, agreements, tasks, crm_updates, risks, unclear_fragments.

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

Модельный кейс: компания из сферы B2B-сервиса, ~80 сотрудников, обрабатывает 60 записей продаж в день и хочет создавать задачи по итогам звонков. Я бы не начинал с полной записи в CRM. Сначала собрал бы 100 расшифровок, разметил вручную 10–15 типовых договорённостей и проверил, сколько задач модель создаёт без срока, владельца или цитаты. Эти три признака показывают качество лучше, чем общая оценка «резюме понравилось».

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

Шаг 4. Превратить результат в задачу CRM

CRM обычно принимает задачи через API: тема, описание, срок, ответственный, связанная сделка, контакт, тип активности. Нейросеть не должна напрямую «нажимать сохранить» без промежуточной логики. Я бы ставил между моделью и CRM слой валидации. Он проверяет, что дата распознана, ответственный существует, сделка найдена, поле не пустое, а действие относится к бизнес-процессу.

Хорошая задача выглядит скучно:

{
  «title»: «Отправить расчёт на 20 пользователей»,
  «due_at»: «2026-07-03 17:00»,
  «owner»: «менеджер сделки»,
  «source_quote»: «пришлите расчёт на двадцать пользователей»,
  «confidence»: 0.86,
  «review_required»: false
}

Если срок звучит как «после праздников», поле review_required должно быть true. Если в карточке нет ответственного, задача не создаётся автоматически. Если модель нашла два разных срока, система должна сохранить черновик и отправить его на проверку.

Для примера: «клиент просил вернуться завтра» нельзя записывать в CRM как точную дату, если звонок попал в очередь обработки через сутки и дата разговора не передана в метаданных. Это мелочь, но именно такие мелочи создают просроченные задачи и раздражают менеджеров.

Связь с CRM лучше проектировать как очередь событий. Сначала появляется объект «результат анализа звонка», затем валидатор превращает часть полей в задачи и обновления. Так проще повторить обработку после правки промпта, увидеть историю изменений и откатить ошибочное правило.

Шаг 5. Настроить промпты и контроль качества

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

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

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

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

Какие инструменты нужны в связке

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

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

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

Ошибки, которые дорого чинить после запуска

Первая ошибка: писать в CRM всё, что похоже на действие. Фраза «можем обсудить договор на следующей неделе» ещё не задача. Задача появляется, когда есть действие и владелец: «Ирина отправит проект договора во вторник».

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

Третья ошибка: смешивать обновления карточки и задачи. Обновить поле «интересует тариф для 20 пользователей» и поставить задачу «выслать расчёт» — разные действия. У них разные правила проверки.

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

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

Как я бы запускал проект

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

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

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