Разработка AI-системы автообзвона для подтверждения заказов

Отметим: когда входящие заказы падают в CRM, а подтверждение висит часами — начинается отток. Мы разрабатываем голосовых ботов для автообзвона подтверждения заказов, которые перехватывают этот момент: звонят через 30 минут после оформления, через 2 часа после неоплаты. Конверсия подтверждения — 70–80%, доля невыкупов падает с 20% до 5–8%. Экономия на операторском отделе достигает 30–50% от текущих затрат, а средняя стоимость звонка снижается до 0,5–1 рубля — в 30 раз дешевле живого оператора.

Недавно для интернет-магазина цифровой техники с 8000 заказов в день мы внедрили бота: за месяц доля невыкупов упала с 25% до 7%, а конверсия подтверждения достигла 82%. Операторский отдел сократили на 40% на основе данных проекта. Свяжитесь с нами, чтобы обсудить аналогичный кейс.

Проблемы, которые решает AI-автообзвон

Первая — человеческий фактор: операторы тратят время на повторы, забывают перезванивать, ошибаются в статусах. Вторая — масштабирование: в пик сезона 100+ заказов/час, нанять столько операторов нереально. Третья — обработка отказов: клиент может отменить заказ или изменить адрес — это нужно корректно обработать и передать в логистику. По скорости реакции AI-бот опережает оператора в 20–40 раз: звонок инициируется через 5–15 секунд против 5–10 минут у человека. При этом точность логирования у бота 100%, а у оператора — не более 70%.

Мы спроектировали систему, которая решает эти проблемы без потери качества. В основе лежит диалоговый движок на LLM (GPT-4o, LLaMA 3 или Qwen — зависит от требований к latency), который понимает естественную речь и гибко реагирует на отклонения от сценария. Подробнее о технологии LLM можно прочитать на Wikipedia.

Как AI-бот обрабатывает отмену заказа?

При получении сигнала об отмене система фиксирует причину (код и комментарий), блокирует запуск сборки, инициирует возврат средств (если был предоплачен). Все изменения синхронизируются с CRM в real-time через WebSocket. Если клиент отменяет частично — бот уточняет позиции и создаёт заказ-изменение. Скорость обработки отмены — менее секунды, что критично для логистических окон.

Почему retry-стратегия критична для конверсии?

До 30% заказов на момент первого звонка не отвечают. Без retry эти заказы уходят в невыкуп. Наш алгоритм использует адаптивное расписание для retry-стратегии: первый звонок через 30 минут, второй — через 2 часа, третий — через 6 часов. Если не дозвонились — отправляем SMS с URL для подтверждения и ставим задачу оператору. Эта схема повышает процент подтверждённых заказов на 15–20%.

RETRY_SCHEDULE = [
    timedelta(minutes=30),   # первый retry
    timedelta(hours=2),      # второй retry
    timedelta(hours=6),      # третий retry
]

После трёх неудачных попыток — push-уведомление в мобильное приложение или звонок оператора.

Как внедрить AI-обзвон за 3 шага

1. Аудит процессов — анализируем текущие скрипты, триггеры и интеграции (1–2 дня).
2. Запуск MVP — реализуем базовый сценарий с retry-логикой и интеграцией через REST API (5–7 дней).
3. Оптимизация — на основе данных первых 1000 звонков корректируем сценарии и настраиваем эскалации (3–5 дней).

Сравнение: AI-бот vs живой оператор

Этапы внедрения и сроки

Что входит в работу

• Диаграммы диалогов и схемы интеграции в Confluence
• Документация API и инструкции для операторов
• Доступ к дашборду метрик (конверсия, latency, процент ошибок)
• Обучение команды и 2 недели пост-релизной поддержки
• Возможность кастомизации сценариев под новые бизнес-процессы

Как мы это делаем: стек и архитектура

Типовое решение строится на микросервисах:

• FastAPI — API для управления заказами и очередью звонков
• PostgreSQL + pgvector — хранение диалогов и семантический поиск по интенту
• WebSocket — real-time синхронизация статусов
• Triton Inference Server / vLLM — инференс LLM с latency p99 < 500 мс
• ChromaDB — векторное хранилище для few-shot примеров

Звонок инициируется через SIP-транк или WebRTC, аудио-стриминг в ASR (Whisper или собственные модели), ответ генерирует LLM, синтезирует речь TTS (Silero, Coqui или ElevenLabs).

Гарантия и опыт команды

Наши специалисты — 5+ лет в голосовых ассистентах, 30+ запущенных проектов в e-commerce РФ. Имеем сертификаты по интеграции с 1С и Bitrix24. Согласно внутренней статистике, средняя экономия клиентов составляет 30–50% от затрат на операторский отдел — например, если ранее вы тратили 100 000 рублей в месяц, после внедрения бота расходы составят около 20 000 рублей. Гарантируем корректную обработку 100% предусмотренных веток диалога и снижение доли невыкупов до 5–8% в течение первого месяца.

Получите консультацию — проверьте качество диалогов на своих сценариях. Закажите demo-звонок: свяжитесь с нами, чтобы обсудить интеграцию и получить коммерческое предложение.

Распознавание и синтез речи: ASR, TTS, клонирование голоса

Заказчик приходит с задачей: транскрибировать 40 000 часов колл-центра за неделю. Штатный облачный ASR (Google Speech-to-Text) выдаёт WER 28% на отраслевой лексике и стоит ощутимо дорого при таких объёмах. Задача — снизить WER ниже 10% и перейти на self-hosted инференс.

Типовые проблемы, с которыми приходят

WER не сходится к нужной метрике. Чаще всего виновата не архитектура, а данные: шумные аудио без нормализации уровня (-23 LUFS вместо стандарта), смешанные языки в одном канале, акцент, специфическая доменная лексика. Whisper large-v3 из коробки даёт WER 8–12% на чистом русском и проваливается до 25–35% на записях с PSTN-артефактами и узкополосным кодеком G.711.

Диаризация ломается при больше двух спикеров. pyannote/speaker-diarization-3.1 работает стабильно при 2–3 говорящих, но DER (Diarization Error Rate) растёт с 6% до 18–22% при 5+ участниках конференции. Проблема усугубляется перекрёстными репликами: по умолчанию min_duration_on=0.1 срезает короткие вставки.

Клонирование голоса — латентность или качество. XTTS v2 (Coqui) даёт натуральный голос, но при потоковой генерации stream_chunk_size=20 первый аудиочанк прилетает через 1.4–2.0 с — неприемлемо для интерактивных сценариев. StyleTTS2 и Kokoro быстрее, но требуют точной подготовки референсного аудио.

Как это решается на практике

Базовый стек для production-пайплайна:

• ASR: openai/whisper-large-v3 или faster-whisper (CTranslate2-бэкенд, x4 скорость vs оригинал)
• Диаризация: pyannote.audio 3.x + интеграция через whisperx для выравнивания по словам
• TTS: XTTS v2 для качества, Edge-TTS или Silero для низкой латентности
• Клонирование: XTTS v2 (3–6 с референсного аудио) или OpenVoice v2

Типичный пайплайн для колл-центра выглядит так: аудио из очереди Kafka → нормализация ffmpeg -af loudnorm до -23 LUFS → faster-whisper с beam_size=5, vad_filter=True → pyannote диаризация → постпроцессинг (пунктуация через deepmultilingualpunctuation) → запись в PostgreSQL с временными метками.

Кейс из практики. Финтех-компания с 12 000 звонков/день. Исходный WER на русском с банковской лексикой — 22% (Google STT). После fine-tuning whisper-medium на 200 часах размеченных записей через Hugging Face transformers + Seq2SeqTrainer с learning_rate=1e-5, warmup_steps=500 — WER упал до 7.3%. Инференс на одной A10G через faster-whisper с compute_type=float16 обрабатывает 40-минутный звонок за 55 секунд. Итоговая стоимость инференса — $0.0008/мин против $0.016/мин у облачного провайдера.

Дообучение Whisper на доменных данных

Когда общая модель не справляется, fine-tuning — первый инструмент. Минимальный датасет для заметного улучшения — 20–30 часов размеченного аудио в целевом домене. Разметку можно получить через итеративный процесс: прогнать через базовую модель → вручную исправить 10–15% ошибок → переобучить → повторить.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

Важно: при fine-tuning Whisper нужно замораживать encoder первые 1000 шагов (model.freeze_encoder()), иначе акустические признаки разъедутся раньше, чем decoder адаптируется к новой лексике.

Синтез речи: выбор под задачу

Для интерактивных ботов с требованием TTFB < 300 мс — Silero или Kokoro. Для озвучки контента, где важна натуральность — XTTS v2 с потоковой отдачей через WebSocket.

Процесс работы

Начинаем с аудит-сессии: берём 2–4 часа ваших записей, прогоняем через несколько моделей, замеряем WER/CER, смотрим на распределение ошибок по типам (лексические, акустические, язык). Это занимает 1–2 дня и сразу показывает, нужен ли fine-tuning или достаточно пост-обработки.

Далее — выбор архитектуры под ваш throughput: один GPU для 1000 мин/день или кластер с балансировщиком для 100 000+ мин/день. Деплой через Docker-контейнер с FastAPI или Triton Inference Server для батчированного инференса.

Сроки зависят от сложности: базовая интеграция готовой модели — 1–2 недели. Fine-tuning с подготовкой данных и валидацией — 4–8 недель. Полная разработка голосового пайплайна (ASR + диаризация + TTS + мониторинг) — 2–4 месяца.