Как ИИ-агент превращает телефонный звонок в готовую карточку заявки

Конец рабочего дня. Менеджер по продажам стройматериалов кладёт трубку после очередного звонка. В блокноте у него три строчки, обведённые кружком: «ВВГ 3х2.5 — 800 метров», «доставка на Новую Ригу, склад №4», «перезвонить в понедельник до обеда». В CRM он это внесёт когда-нибудь потом. Или не внесёт: половину забудет, вторую половину зафиксирует так, что через месяц никто не поймёт, о чём договаривались.

Когда мы пришли к заказчику — крупному дистрибьютору стройматериалов — картина была именно такая. Из потока входящих звонков в CRM попадала оформленной хорошо если половина. Остальное — россыпь заметок, отсутствующие суммы, «клиент вроде хотел». Руководитель отдела продаж считал воронку по этому и терял сделки на ровном месте — просто потому что менеджер не успевал занести данные.

Задача звучала просто: превратить звонок в готовую карточку заявки за минуту после окончания разговора. Без вмешательства менеджера. С точностью, которой можно доверять на этапе первого касания. По сути — построить ИИ-агента для конкретного бизнес-процесса, а не абстрактного «умного помощника».

Почему «просто прогнать через STT и попросить LLM резюмировать» не работает

Первый подход у нас был именно таким. Сырое аудио в SaluteSpeech, транскрипт целиком в GigaChat Pro с промптом «извлеки сущности». Хотелось сделать быстро и показать заказчику работающий прототип. Показали. Работало ужасно. Причин, как выяснилось, было три.

Первая: без диаризации транскрипт превращается в кашу. «Восемьсот метров надо да у нас есть на складе а какая цена» — это одна реплика или две? Кто из говорящих клиент, а кто менеджер? LLM угадывает, но с процентом ошибок, при котором в карточку прилетает «клиент готов отгрузить со своего склада». Мы такое поймали на демо, и было неловко.

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

Третья: SaluteSpeech и Yandex SpeechKit прекрасно справляются с обычной речью, но спотыкаются на артикулах и марках. «ВВГ три на два с половиной» на выходе выглядит как «в вэ гэ три на два с половиной», а иногда — как «в веге на два с половиной». Прогнать это через справочник 1С без предобработки — гарантированный промах.

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

Конвейер, который сработал

Мы разложили задачу на пять шагов. Каждый — короткий, у каждого своя метрика качества и своя ответственность.

Шаг 1. Транскрипция с диаризацией. Взяли SaluteSpeech от Сбера для распознавания и отдельный проход по диаризации на pyannote (self-hosted, крутится на нашей же машине рядом с pgvector). На выходе — размеченный по спикерам транскрипт с таймингами:

[SPEAKER_00, 00:12–00:18]: Здравствуйте, это Артём, компания-поставщик.
[SPEAKER_01, 00:18–00:24]: Артём, добрый день. По кабелю звоню, вы посмотрели?

На телефонной записи 8 кГц диаризация работает уверенно — достаточно, чтобы дальше LLM правильно понимала, кто именно произнёс каждую фразу.

Шаг 2. Нормализация артикулов. Перед передачей в LLM пропускаем транскрипт через простой регулярный препроцессор с локальным словарём частотных сущностей отрасли. «В вэ гэ» — «ВВГ». «Три на два с половиной» — «3х2.5». Ловим большую часть типовых искажений STT ещё до того, как текст видит модель. Оставшееся — задача уже для LLM с доступом к справочнику через MCP.

Шаг 3. Чанкинг по смысловым блокам. Не по количеству токенов, а по паузам и смене темы. Технически: считаем расстояние между репликами по таймингу и векторное сходство соседних фрагментов через эмбеддинги GigaChat. Точка разрыва — там, где либо пауза больше 4 секунд, либо косинус между блоками падает ниже 0.62. Порог мы подобрали руками на примерно двухстах записях — сначала было 0.7, но тогда система рвала разговор посреди обсуждения одной позиции. Средний звонок так режется на несколько смысловых блоков, каждый из которых уже помещается в промпт без риска, что модель потеряет начало.

Шаг 4. Параллельное извлечение по ролям. Каждый чанк уходит в GigaChat Pro одновременно в трёх ролях — фактически это маленькая сеть ИИ-агентов, работающих над одним разговором:

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

Три параллельных запроса на чанк — это дороже, чем один общий, но каждый промпт короче и точнее. Мы тестировали и универсальный промпт, и роли: с ролями качество извлечения заметно выше. Разница между «менеджер всё равно всё перепроверит» и «менеджер проверил и подтвердил».

Шаг 5. Сборка карточки и валидация через JSON Schema. Все извлечённые куски собираются в одну структуру и прогоняются через строгую схему: артикул обязан существовать в справочнике 1С, дата — быть валидным timestamp, телефон — соответствовать формату. Если что-то не бьётся — карточка помечается флагом «требует внимания» и уходит менеджеру в очередь на верификацию, а не автоматически в CRM. Оркестрацию всего конвейера мы собрали в n8n: ИИ-агенты в связке с n8n удобно тем, что каждый шаг видно на схеме, любую ветку можно перезапустить руками, а логика ретраев и очередей уже встроена в платформу.

Что получилось

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

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

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

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

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

Три грабли, о которых стоит знать заранее

Гарнитура клиента важнее, чем гарнитура менеджера. На нашем стеке качество распознавания менеджера почти всегда отличное: он в офисе, микрофон нормальный. А клиент говорит через колонку в машине, гарнитуру от ноутбука или динамик громкой связи. Диаризация иногда путается именно потому, что клиентский канал шумный. Фильтр шумов перед STT снял часть проблемы, но не всю — от «клиент кричит из грузовика на трассе» не спасает никакая нейросеть.

Локальные словари важнее хороших промптов. Мы долго наращивали промпт для GigaChat, пытаясь заставить его нормализовать артикулы. Помогла в итоге не длина промпта, а короткий словарь самых частотных сущностей отрасли, применяемый до LLM. Дёшево, быстро, работает. Причём собрал этот словарь не инженер, а руководитель отдела продаж за один вечер — он их и так помнил наизусть.

Не автоматизируйте всё. Первая версия отправляла в CRM все карточки подряд. Через пару недель менеджеры взбунтовались: половину времени они тратили на исправление автоматически созданных записей, потому что не доверяли им. Ввели порог уверенности и очередь ручной верификации на сомнительное — доверие вернулось. Менеджеры знают: если карточка в CRM — её проверила машина; если в очереди — они посмотрят сами. Это, кстати, общий вывод по всем ИИ-агентам для бизнеса, которые мы делаем в России: полностью автономный агент почти всегда проигрывает связке «агент + человек на исключениях».

Что дальше

Следующий шаг — обратная связь от менеджера в конвейер. Каждая правка в карточке становится тренировочным сигналом: если менеджер несколько раз подряд исправил «ВВГ 3х2.5» на «ВВГ-нг 3х2.5», система запоминает предпочтение конкретного клиента и в следующий раз предложит правильный артикул сразу. Это уже область self-improvement loop, о которой мы писали раньше — но здесь она замыкается не на текстовые касания, а на голосовые.

Вопрос, который остаётся открытым: где грань между «ИИ-агент сам заполняет CRM» и «ИИ-агент помогает менеджеру заполнять CRM»? Наш опыт говорит, что пока честнее быть ассистентом, а не заменой — особенно там, где ошибка на первом касании стоит дорого. А у вас как разложилось?