Голосовой AI-менеджер на входящих звонках B2B-торговли

1. Контекст бизнеса

Клиент это производственно-торговая компания федерального масштаба, дистрибьютор инженерного оборудования для систем водоснабжения, отопления и газоснабжения. Работает с начала 1990-х. В каталоге свыше 20 000 SKU от европейских и российских производителей. Клиентская база это крупные B2B-клиенты. Производство, торговля, строительство, инфраструктурные объекты.

Объёмы. Свыше 100 отгрузок в день, география вся РФ. Входящая телефонная линия (московский номер плюс 8-800) это основной канал первичного контакта.

Команда первой линии. 5 операторов. Фонд оплаты труда с налогами и рабочим местом около 195 000 ₽ на человека в месяц.

Проблемы, ради которых заказчик пошёл в проект

1. До 20% пропущенных звонков в часы пик. Клиент звонил трижды, потом уходил к конкуренту. 20%пропуска в пик
2. 100% потерянных звонков в ночь и выходные. Заказы из регионов в часовых поясах +3…+7 от Москвы терялись.
3. Текучка первой линии 30–40% в год. Новый оператор выходил на продуктивность 2–3 месяца, и всё это время качество было ниже.
4. 60–70% звонков типовые справочные («есть ли товар, какая цена, когда отгрузите»). Дорогой ресурс оператора уходил на справочную функцию.
5. Среднее время обработки запроса «наличие + цена + срок» доходило до 4–6 минут. Параллельно оператор не успевал заполнять карточку клиента в CRM.

2. Решение коротко

Голосовой AI-агент первым отвечает на входящий звонок и ведёт диалог голосом. Что он делает.

• Идентифицирует клиента по номеру через 1С.
• Ищет товары в каталоге через RAG.
• Получает остатки и цены через REST API 1С.
• Оформляет типовые повторные заказы напрямую в 1С.
• При сложном вопросе или явном запросе «дайте человека» переключает на оператора с подгруженным контекстом.

С коммерческой стороны AI закрывает три сценария:

1. Справочный звонок. «Есть ли труба X на складе, какая цена, когда отгрузите». Робот отвечает за 1–2 секунды, данные тянет напрямую из 1С, не из кэша.
2. Первичная квалификация лида. Кто звонит, что нужно, объём, сроки, регион. AI заполняет карточку лида в CRM, переводит на живого менеджера если квалификация прошла.
3. Принятие повторного заказа от действующего клиента. Контрагент опознан по номеру, история есть, AI собирает заказ, передаёт на подтверждение менеджеру.

За живыми менеджерами осталось вот что. Новые сделки от 500 000 ₽, нестандартные позиции под заказ, споры по качеству, переговоры по отсрочке, рекламации.

3. Архитектура одним кадром

Входящий звонок приходит в Asterisk. Stasis-приложение через ARI WebSocket поднимает медиа-канал, через externalMedia поток RTP уходит в Python-воркер. Воркер режет аудио на чанки по VAD, гонит в faster-whisper для частичной транскрипции, финальный текст идёт в LLM. LLM работает с двумя инструментами. Это REST в 1С и retrieval из векторного индекса. Ответ потоково в TTS, обратно в RTP-канал. Параллельно MixMonitor пишет двухканальный stereo WAV.

4. Технический стек и архитектурные решения

4.1. Телефония на Asterisk 20 LTS, ARI + externalMedia

Слой интеграции переписан относительно типовых решений. AGI для realtime-стриминга это плохой выбор. AGI блокирующий, спавнит процесс на каждый звонок, не даёт нормально стримить медиа. Переход на ARI Stasis + externalMedia стабилен с Asterisk 18. Stasis-приложение получает StasisStart, через POST /channels/id/externalMedia поднимаются два RTP-сокета (slin16, 20 ms ptime), Python-воркер слушает их через asyncio / aiortc.

Подводные камни, которые реально стреляют:

• NAT/jitter. Если Asterisk и медиа-воркер не в одном L2-сегменте, нужны directmedia=no, force_rport, rtp_symmetric=yes. Между ДЦ идёт IPsec/WireGuard, не голый RTP.
• Echo cancellation. Без agc, denoise, формата 16 кГц mono Whisper глохнет на эхо от плохих SIP-телефонов клиента.
• Codec transcoding. Входящий G.711 μ-law → slin16 на Asterisk даёт +5–10 ms и +20% CPU. На 100 одновременных звонков нужен dedicated DSP-сервер.
• Stream buffer. ARI externalMedia шлёт 20 ms фреймы. Whisper хочет минимум 200–500 ms. Буферизация в Python через collections.deque с VAD-cut.

4.2. ASR на faster-whisper Large-v3 + Silero VAD

faster-whisper (CTranslate2-порт) работает в 2–4× быстрее официального Whisper, потребляет 2–3× меньше VRAM. Альтернатива whisper.cpp на CPU тянет, но на GPU faster-whisper объективно быстрее без квантизационных артефактов на русском.

Замеры на проде (GPU RTX 4090, Large-v3, int8_float16) дают вот что. Чанк 5 секунд русской речи это 280–450 ms inference. На 30 одновременных потоков упирается в VRAM. WER на чистом канале (телефония 8 кГц апсемплированная до 16 кГц) держится 8–12%. На терминологии (артикулы, иностранные бренды) растёт до 15–22%. Лечится дообучением с LoRA на 50–100 часов записей.

4.3. LLM с маршрутизацией по сложности запроса

В реальной эксплуатации не работает «один LLM на всё». Поэтому сделан маршрутизатор.

• Простые intent (наличие, цена, режим, статус заказа) идут в локальную Qwen 2.5-7B-Instruct или YandexGPT 5 Lite через self-hosted vLLM. Latency 200–400 ms, стоимость нулевая.
• Сложные сценарии (техконсультация, подбор аналога, нестандартная отгрузка) идут во внешний API через РФ-резидентного посредника либо GigaChat Pro / YandexGPT 5 Pro.
• Fallback на человека срабатывает, если у LLM confidence < threshold или 2 раунда не сошлись с клиентом, либо клиент явно сказал «дай человека».

4.4. RAG на pgvector в той же PostgreSQL, что и состояние диалога

Поменяно решение из исходного проекта (там планировался ChromaDB). На проде стоит pgvector в основной PostgreSQL. Причина в том, что одна БД держит всё (диалоги, метрики, эмбеддинги), один backup, одна миграция. ChromaDB на стенде падал на 500k+ векторов. Qdrant нормальный, но pgvector с HNSW-индексом покрывает потребность до 5–10M векторов с p95 < 50 ms.

Эмбеддинги. intfloat/multilingual-e5-large для русского идёт на голову выше OpenAI text-embedding-3-large на B2B-терминологии. Self-hosted на том же GPU.

4.5. TTS, реалистичный выбор для русского realtime

Выбран Silero TTS v4 для основного потока + Yandex SpeechKit как fallback для редких голосов. От клонирования голоса оператора отказались. 152-ФЗ требует согласия на обработку голоса, риски подделки голоса в РФ растут, стандартный голос Silero не хуже клонированного по фактическому качеству диалога.

4.6. 1С-интеграция через FastAPI-шлюз, не прямой REST

В исходном проекте стоял прямой /api/v1/... REST в 1С. На реальных контурах типичны три варианта.

1. HTTP-сервисы 1С (нативно, тянет до ~50 RPS на нормально настроенной 1С).
2. OData v3 из коробки 1С 8.3. Для read-only справочников ок, для записи кривовато.
3. Шина (1С:КД, RabbitMQ/Kafka) для крупных контуров.

Стандартизирован контракт через FastAPI-шлюз между LLM-tools и 1С. LLM думает что у неё чистый REST, шлюз решает «это OData или HTTP-сервис». Это спасает при смене подрядчика 1С.

5. Латентность. Честные цифры, не маркетинг

«1–2 секунды отклика» в типовых КП это маркетинг. Честная картина end-to-end, p50 на проде, выглядит так.

То есть честно. 1.0–1.3 секунды до первого слова на простых запросах, 2.0–2.5 сек на сложных с обращением в 1С/RAG, p95 до 3 сек.

Где можно срезать ещё

• Streaming Whisper (partial transcripts) + ранний trigger LLM на стабильном префиксе. Экономит 150–300 ms, рискует ошибиться.
• Спекулятивный pre-fetch в 1С на частые intent. Экономит 100–200 ms, усложняет.
• LLM-routing на эмбеддингах вместо генерации. Экономит 50–80 ms.

6. Эксплуатация и наблюдаемость

По каждому звонку пишется в ClickHouse через Vector/Fluent-bit вот что.

• call_id, caller_id, agent_id, длительность, число тёрнов.
• На каждый тёрн vad_duration_ms, asr_latency_ms, asr_confidence, transcript, llm_model, llm_latency_ms, tool_calls[].
• intent_detected, confidence, fallback_to_human с причиной.
• sentiment по клиенту на каждой реплике через мелкий классификатор. Нужен для алертов «клиент злится, выруби бота».

Реалистичный SLA на 100+ звонков/день

«99.9% uptime» в типовых КП относится к сетевому железу, не к системе целиком. Любой апдейт LLM-провайдера, любая ошибка в RAG-индексе, любая правка скрипта Asterisk открывает окно недоступности. Честный SLA равен 99.5%.

7. Бизнес-кейс и экономика

Метрики, которые я готов защитить

Везде ниже цифра идёт диапазоном, не точкой. Нижняя граница измерена по факту за первые 90 дней пилота. Верхняя это экстраполяция при сохранении того же качества.

Что я НЕ ставлю в метрики

• «Клиент не отличает AI от человека». Часть отличает. Это нормально, управляется приветствием.
• «Рост среднего чека на 10% за счёт кросс-продаж». Не воспроизвели в контролируемых условиях. Гипотеза.
• «Рост выручки на 20%». Невозможно атрибутировать AI отдельно от сезонности и работы живых менеджеров.

ROI, два сценария, оба защитимы

Инвестиции (CAPEX)

Операционные расходы (OPEX, в месяц)

Два сценария

ROI 130–220% годовых я готов писать в инвестиционный паспорт проекта и защищать перед собственником. ROI 1041% это лозунг для коммерческого предложения, а не цифра для принятия решения.

8. Когда сценарий подходит и когда нет

Подходит, если

• Минимум 1 500 входящих звонков/мес. Если меньше, окупаемость растягивается за горизонт планирования.
• Доля типовых справочных звонков от 50% и выше. Это критическая граница. Если AI закрывает меньше половины, экономика разваливается.
• Есть учётная система (1С или аналог) с API или возможностью допилить API.
• Существует digital-каталог. Документация, прайс, описания товаров в структурированном виде. RAG нужно чем-то кормить.
• Есть Asterisk, MikoPBX, Mango Office или любая PBX с возможностью внешнего AGI/SIP-моста.

Не подходит, если

• Звонок это уже зрелая сделка с индивидуальной комплектацией. AI не заменит инженера-консультанта.
• Меньше 500 входящих в месяц. Проще нанять ещё одного человека.
• В компании нет внутреннего владельца процесса. AI требует регулярного review логов и обновления знаний. Если этим некому заниматься, через 3–4 месяца система начинает врать и терять клиентов.

Что AI-менеджер НЕ делает

• Не ведёт переговоры о цене. Скидки, отсрочка, индивидуальные условия всегда на человека.
• Не принимает претензии. При распознавании конфликтной интонации идёт мгновенная эскалация супервайзеру.
• Не продаёт то, чего нет в 1С. Если позиции нет, честно говорит «уточню у менеджера, он перезвонит». Без галлюцинаций по остаткам.
• Не работает в тишине. Звонок логируется, разговор записывается, расшифровка попадает в CRM.
• Не заменяет отдел продаж. Это первая линия. KPI отдела продаж остаются на живых людях.

9. Стратегические сценарии применимости

После этого проекта я выделил 4 устойчивых сценария, где AI-голосовой агент даёт измеримый эффект для среднего бизнеса (50–500 человек) в РФ в 2026.

Сценарий 1. Дистрибуция / B2B-торговля с большим каталогом

Это наш кейс. Условия такие. 1 000+ SKU в активном каталоге, 70%+ звонков типовые, ERP с REST API, B2B-клиенты с карточкой в ERP. Типичный ROI. Окупаемость 4–6 месяцев, экономия ФОТ первой линии 40–60%.

Сценарий 2. Сервисное обслуживание / запись на визит

Медицина, автосервис, ремонт, репетиторские центры, салоны красоты. Закрывает запись, перенос, отмена, ответ на «какие услуги», «сколько стоит».

Сценарий 3. Финансы, лизинг, страхование. Квалификация лида

Условия такие. Большой поток лидов с маркетинга, квалификация по 5–10 параметрам перед передачей менеджеру, скоринговая модель как источник решения. По регуляторике повышенные требования по 152-ФЗ, 115-ФЗ, 161-ФЗ. LLM с правом давать рекомендации по продуктам это отдельный регуляторный кейс.

Сценарий 4. Государственный сектор и справочные функции

Условия такие. Нет юридически значимых решений со стороны AI, информационная база официально публикуема и не содержит ПДн.

Где AI-голосовой агент НЕ работает

• Сложные B2B-продажи длинного цикла (от 1 млн ₽, проектные поставки). Клиент хочет говорить с экспертом.
• VIP-обслуживание. Премиум-клиенты ожидают человека.
• Конфликтные / экстренные ситуации. Нужен человек с эмпатией и юридической ответственностью.
• Многоязычность с сильными акцентами. Качество ASR падает.

10. Roadmap внедрения по фазам

AI-голосовой агент не внедряется big-bang релизом. Только три последовательные фазы с decision-gates.

11. Change management, самая недооценённая часть

В большинстве презентаций AI-проектов это рисуют одним слайдом «обучение персонала». В реальности это половина успеха проекта. Технология сегодня готова. Провалится проект на людях, не на коде.

Как готовить операторов первой линии

Что НЕ работает

• «AI вас не заменит, не волнуйтесь». Операторы видят план и не верят.
• «Это просто инструмент». Операторы видят, что инструмент берёт их хлеб.
• «Будет переобучение». Операторы спрашивают «куда?», не получают ответа.

Что работает

1. Честность с первого дня. «Через 6 месяцев нужно 2 человека вместо 5. Есть три варианта. Переобучение на VIP-линию, переобучение на curator-промпт-инженерию, выходное пособие + рекомендации».
2. Финансовые гарантии. Тем, кто остаётся, повышение оклада на 30–50%. Тем, кто уходит, 3 оклада + рекомендации.
3. Участие в проекте. Лучшие операторы участвуют в тренировке AI. Их фразы становятся образцом для prompt engineering, они проводят первичный разбор фейлов.
4. Прозрачные метрики. Команда видит, что AI делает и что не делает, какие ошибки, как растёт качество. Не «чёрный ящик».

Что говорить клиентам

В IVR при входящем звонке: «Здравствуйте. Меня зовут [имя AI]. Я могу помочь с наличием товаров, ценами и оформлением заказов. По сложным вопросам переключу на менеджера-эксперта». Это и информирование «вы говорите с AI», и снятие напряжения.

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

12. Регуляторика. Что обязательно в РФ

Раздел, который проваливает большинство презентаций AI-проектов. И именно он становится миной при первой проверке.

152-ФЗ, персональные данные

ФИО, телефон, email клиентов в карточке 1С это ПДн. Голос в трактовке Роскомнадзора относится к биометрическим ПДн.

• Уведомление в РКН (ст. 22). Форма утверждена Приказом Роскомнадзора № 274 от 24.02.2021. Категория «обработка с применением средств автоматизации, голосовая».
• Политика обработки ПДн на сайте (ст. 18.1).
• Согласие на запись разговора и обработку голоса (ст. 9). Получается конклюдентным действием, продолжением разговора после уведомления.
• Локализация ПДн на территории РФ (242-ФЗ от 21.07.2014, ст. 18 ч. 5 152-ФЗ). 1С и записи лежат на on-prem или в РФ-резидентных облаках. Не AWS, не GCP.
• Уровень защищённости ИСПДн. Для типичного коммерческого B2B это УЗ-3 или УЗ-4. Пакет документов 80–100 страниц, готовится 4–6 недель.

Облачные LLM и трансграничная передача

Когда отправляем расшифровку в OpenAI / Anthropic, это трансграничная передача ПДн. До отправки маскируем PII. Телефон → [PHONE], ФИО → [NAME], адрес → [ADDRESS].

Двухконтурная схема LLM. Для типовых запросов идёт облачный LLM с маскированным текстом (через РФ-резидентного посредника). Для запросов с явными ПДн идёт переход на локальную Qwen 2.5 / YandexGPT Lite на on-prem GPU.

Право клиента на разговор с человеком

В 2024–2025 в РФ приняты поправки, обсуждается дальнейшее регулирование автоматизированного обслуживания. Действующее ядро это обязанность информировать клиента, что он говорит с AI плюс возможность переключения на человека.

13. Vendor lock-in и стратегия запасного варианта

Это раздел, который в большинстве КП отсутствует. На уровне CIO он обязателен.

Риск 1. Облачный LLM-провайдер заблокирует РФ или поднимет цены

Сценарий не теоретический. На горизонте 2026–2028 он возможен с ненулевой вероятностью.

Что делается в архитектуре:

• Двухконтурная LLM с автоматическим переключением. Primary это облачный LLM. Fallback это локальная Qwen 2.5-7B на on-prem GPU. Просадка качества ~15–20% относительно облачного primary.
• Автоматический trigger.Если запросы возвращают ошибку >3 раз подряд за 60 сек, все новые звонки идут на локальную LLM. Алерт CIO.
• Кэширование частых ответов без обращения к LLM вообще.

Риск 2. PoC провалится, что делаем

Сценарий такой. PoC показал, что технически не получается достичь нужного качества. Вот активы, которые не теряются.

1. RAG-база каталога. Структурированная база 20 000 SKU с эмбеддингами. Переиспользуется в семантическом поиске на сайте, в чат-боте, в помощнике менеджеров.
2. REST API 1С через FastAPI-шлюз. Эндпоинты переиспользуются в любом канале (сайт, мобильное приложение, партнёрский API).
3. Промпт-библиотека и сценарии диалогов. Идут на обучение операторов, скрипты холодных звонков, тренинг новых менеджеров.
4. Мониторинг и аналитика звонков. Stereo-запись, расшифровка, классификация исходов. Ценен даже без AI-агента.

Доля «затопленных» активов при полном откате около 30%. Остальные 70% переиспользуются.

14. FAQ, частые вопросы на ознакомительном звонке

Клиенты заметят, что говорят с AI?

Часть заметит, и это нормально. Мы открыто говорим в первой фразе IVR, что разговаривает автоматизированная система. Клиенты, которые принципиально не хотят разговаривать с роботом, говорят «дайте человека», и переключение мгновенное.

Если AI ошибётся в цене или товаре, кто отвечает?

AI оформляет заказ в 1С с пометкой «оформлен через AI». До отгрузки заказ проходит финальную проверку человеком. За корректность данных в 1С отвечает компания, не вендор AI. Это закрепляется в договоре и в регламенте.

Сколько разговоров AI ведёт параллельно?

На RTX 4090 (24 GB) с faster-whisper + локальной Qwen 2.5 около 25–30 параллельных. С внешним LLM на сложных диалогах всё ограничено параллельностью API провайдера. В нашем кейсе пиковая нагрузка 15 параллельных, обрабатывалась с запасом.

Что если упадёт интернет?

Asterisk работает локально. AI-ядро на локальном GPU работает. Падает только облачный LLM, и срабатывает автоматический fallback на локальную с просадкой качества ~15–20%, никаких потерь звонков. На полный отказ AI-ядра Asterisk переходит в режим «оператор первой линии» как было до внедрения.

Можно ли начать с пилота, без обязательства на полное внедрение?

Да. Стандартная схема это Фаза 1 (PoC, 4 недели, ~400 000 ₽) с гейтом go/no-go. Если решение «no-go», заказчик платит за PoC и получает RAG-базу, API 1С, документацию архитектуры. Активы остаются и могут использоваться без AI-агента.

15. Что обсуждаю на ознакомительном звонке

30 минут, бесплатно. На звонке отвечу на три вопроса.

1. Подходит ли сценарий вашему профилю звонков (нужны цифры по объёму, доле типовых, наличию API).
2. Какой реалистичный диапазон окупаемости в вашем случае.
3. С чего начинать. Пилот на одной линии, аудит инфраструктуры или сразу полноценный проект.

По итогам звонка отдам короткий документ с оценкой потенциала проекта и трёх возможных roadmap (минимальный / оптимальный / агрессивный).