Транскрибация переговоров в CRM: аудио в задачи в 2026

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

Я разбираю такую автоматизацию как инженерный конвейер, а не как магию вокруг нейросети. Если звонок длится 30 минут, менеджер часто тратит ещё 7–12 минут на карточку, заметки и задачу. При 40 звонках в день это уже 4,5–8 часов ручной работы на команду. Нейросеть помогает убрать копирование и пересказ, но сама по себе не решает задачу: ей нужны чистый звук, понятные правила извлечения фактов, проверка полей и аккуратная передача в CRM через API или вебхук. Для смежных сценариев полезно держать под рукой базовые принципы из статьи про нейросети для генерации текста и проверку результата, потому что резюме звонка тоже является текстовым артефактом с критериями качества.

Что именно автоматизируем за 5 минут

За 5 минут после завершения звонка реально получить 4 артефакта: транскрипт, краткое резюме, список задач и обновлённую карточку сделки. В типовом конвейере основное время забирают 2 операции, распознавание речи и генерация структурированного ответа.

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

5 минут не означают, что любой 90-минутный созвон будет обработан мгновенно. Для звонка на 12–20 минут такой срок достижим при асинхронной обработке, очереди задач и заранее подготовленном шаблоне результата. Для встречи на 60 минут лучше проектировать задержку 8–15 минут, иначе система начнёт экономить на качестве: резать контекст, терять говорящих, неверно связывать дату и поручение.

Как записать звук, чтобы транскрибация не ломалась

Для голосовой телефонии минимальный рабочий уровень, 8 кГц и один канал, но для встреч лучше писать 16 кГц или 48 кГц с отдельными дорожками участников. 1 час моно-аудио PCM 16 кГц 16 бит занимает примерно 115 МБ, а MP3 64 кбит/с, около 28,8 МБ.

Качество начинается до нейросети. Если два человека говорят одновременно, если микрофон ноутбука ловит переговорку площадью 25 м², если запись обрезает первые 2 секунды приветствия, модель получает повреждённый материал. Потом она честно распознаёт шум как слова. В CRM это превращается в задачу без срока или в неверный статус сделки.

Я обычно задаю 5 технических требований к записи: единый формат имени файла, время начала в часовом поясе компании, идентификатор звонка, идентификатор сделки или номера телефона, отсутствие ручного переименования. Формат WAV проще для обработки, FLAC экономит место без потерь, MP3 удобен для хранения, но при низком битрейте режет согласные и окончания. На русском языке это критично: «оплата в пятницу» и «оплата по пятницу» дают разные действия.

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

Как устроен конвейер от аудио до резюме

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

Ниже схема, которую я использую как базовую при проектировании. Она не привязана к конкретной CRM, потому что почти любая система с API принимает заметки, задачи и пользовательские поля.

На этапе резюме нужна не длинная стенограмма, а сжатый рабочий документ. Хороший конспект на 15-минутный звонок обычно помещается в 120–180 слов. Задач бывает меньше: 1–4 действия на звонок. Если модель вернула 12 задач, это сигнал, что промпт просит пересказать всё подряд, а не выделить обязательства.

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

Как выделять задачи без участия менеджера

Задача должна состоять минимум из 5 полей: действие, срок, ответственный, связанная сделка и источник фразы в транскрипте. Без источника невозможно быстро проверить, откуда появилась формулировка.

Я не советую писать в CRM просто «связаться с клиентом». Это мусорная задача: нет причины, срока и критерия готовности. Лучше передавать структуру: действие, «отправить коммерческое предложение»; срок, «2026-07-17»; ответственный, менеджер сделки; основание, реплика на 00:12:34; статус, «новая». Для примера: задача «позвонить Ивану до 15:00» допустима только тогда, когда в транскрипте есть имя, действие и время, иначе система должна поставить флаг «нужна проверка».

Условный пример: в звонке на 18 минут модель нашла 3 договорённости, но только 2 имеют явный срок, поэтому в CRM уходят 2 задачи, а третья попадает в заметку с меткой «без даты». Такой сценарий лучше, чем автоматическое создание задачи на случайный день. Ошибка в сроке на 1 день может сорвать оплату, демо или повторный контакт.

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

Как передавать результат в CRM без менеджера

Для записи в CRM достаточно 3 интеграционных объектов: заметка по звонку, задача и обновление полей сделки. Технически это чаще всего API-запрос или вебхук, который срабатывает после готовности структурированного JSON.

Здесь критична идемпотентность. Если обработчик упал на 4-й минуте и запустился повторно, CRM не должна получить 2 одинаковые задачи. Для этого каждому результату присваивают ключ, например call_id плюс тип артефакта. При повторной отправке система обновляет существующую заметку, а не создаёт дубль.

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

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

Как контролировать качество транскрипта и резюме

Качество нужно мерить минимум по 2 слоям: точность распознавания речи и точность бизнес-вывода. Для речи часто используют WER, долю ошибок в словах, а для разделения говорящих, DER, долю ошибок диаризации.

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

Для контроля не нужен отдел из 10 аналитиков. На старте достаточно выборки 30–50 звонков за неделю и таблицы ошибок: «неверный срок», «пропущенная задача», «лишняя задача», «не тот ответственный», «новый факт вне транскрипта». Через 2 недели обычно видно, где ломается процесс: звук, промпт, правила CRM или данные сделки.

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

Когда человек всё же нужен

Человека стоит оставить в контуре для 3 случаев: высокий финансовый риск, юридическая формулировка и низкая уверенность модели. Автоматизация должна экономить ручной труд, а не скрывать сомнения системы.

Я не люблю схемы, где все задачи сразу считаются истинными. Гораздо безопаснее разделить поток. Звонки с обычными следующими шагами уходят в CRM без проверки. Звонки с суммой выше внутреннего порога, спорной датой или словами «штраф», «расторжение», «претензия» попадают в очередь контроля. Порог может быть любым, но он должен быть числом, например 100 000 рублей для сделки или 24 часа до дедлайна.

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

Что бы я сделал на вашем месте

Я бы начал с 1 канала коммуникации, 1 типа сделки и 30 записей, а не со всей CRM сразу. Такой пилот показывает реальную точность за 5–7 рабочих дней и не ломает процессы отдела продаж.

Мой порядок действий простой. Сначала собрать записи с понятной привязкой к сделке. Затем вручную разметить 10 хороших конспектов, чтобы появился эталон. Потом настроить транскрибацию и шаблон резюме. После этого включить тестовую запись в CRM без создания задач. Лишь на последнем шаге разрешить автоматическое создание задач с флагами риска.

Если система стабильно создаёт 80–90% полезных задач без дублей и менеджеры правят в основном формулировки, а не смысл, автоматизацию можно расширять на новые воронки. Если ошибок много, не надо менять всё сразу. Обычно достаточно одного исправления: лучше записывать звук, строже описать задачу или запретить модели додумывать дату. Хороший конвейер транскрибации выглядит скучно: предсказуемые поля, повторяемые проверки, понятные исключения. Именно такая скука и экономит часы в CRM.