AI QA звонков — агент, который читает расшифровку разговора и сверяет её с карточкой в CRM: что произошло в звонке и честен ли статус. Кейс кладётся в очередь руководителю с цитатой клиента. Агент не меняет статус лида: последнее слово за человеком. Подключение к CRM — через MCP-инструменты, а не через «промпт в чат».
С чем обычно приходят
Типичные ситуации, когда стандартные решения уже не справляются.
- Клиент хотел приехать или взять кредит, а в CRM — «корзина»; РОП узнаёт случайно или никогда
- Прослушать все звонки невозможно, а слушать «по длительности» врёт: длинный звонок ≠ интерес
- Правила CRM ловят SLA и дубли, но не смысл фразы «подумаю / дорого / хочу адрес»
- Страшно давать нейросети кнопку «сменить статус» — ошибка модели разнесёт воронку
Как я работаю
Пошаговый процесс — от диагностики до передачи в эксплуатацию.
- 01
Граница полномочий и триггер
Фиксирую, какие переходы статусов запускают проверку (типично — уход в корзину), что агенту можно читать и что нельзя писать. Статус лида агент не меняет: только очередь на human review.
- 02
Контракт вердикта
Задаю JSON-схему: качество расшифровки, вердикт по разговору, сверка с CRM, красные флаги только с прямой цитатой. Аудит без обязательных полей в очередь не попадает.
- 03
MCP и доступ к CRM
Поднимаю инструменты: карточка лида, таймлайн, транскрипт, справочник статусов, отправка аудита, очередь и решение РОПа. Агент сам выбирает, что запросить; запись в CRM — только submit аудита.
- 04
Пилот и очередь руководителя
Запускаю на рискованных кейсах, а не на 100% звонков. РОП видит приоритет, цитату и ссылку на запись; подтверждает или отклоняет. Метрики precision и ложных тревог снимаем после накопления review.
Что вы получаете
- РОП смотрит очередь с доказательствами, а не «нейросеть сказала плохо»
- Воронка не ломается ошибкой модели: статус меняет человек
- Проверяются рискованные кейсы, а не весь поток звонков
- Эффект считается по подтверждённым review, а не по числу алертов агента
Что входит в проект
- Правила триггера и запрет агенту менять статусы CRM
- JSON-контракт вердикта с валидацией обязательных полей
- MCP-контур к CRM: чтение лида и транскрипта, запись только аудита
- Очередь QA для руководителя: приоритет, цитата, ссылка на звонок
- Пилот на согласованном сегменте (например, переход в корзину)
- Регламент review и набор метрик для оценки после пилота
Почему мне доверяют такие задачи
Михаил Клименко собрал AI QA на живой воронке ESM-CRM: агент ходит в CRM через MCP, отдаёт строгий JSON и не меняет статусы. Архитектуру и границы полномочий разобрал в статье на Хабре. Знаю разницу между «встроить AI» и измеримой ошибкой бизнеса — статус в корзине при явном интересе в звонке.
Частые вопросы
Чем это отличается от агента первой линии?
Агент первой линии отвечает клиенту на входе. AI QA работает после звонка: сверяет речь со статусом и готовит кейс руководителю. Это разные контуры и разные полномочия.
Зачем MCP, если можно дергать API из промпта?
MCP даёт агенту ограниченный набор инструментов с понятными правами: прочитать лид, взять транскрипт, сдать аудит. Так проще запретить смену статуса и проще отлаживать вызовы на реальных карточках.
Можно на Bitrix24, amoCRM или только на ESM-CRM?
Контур привязан к вашей CRM через инструменты, не к одному продукту. На ESM-CRM уже есть рабочий пилот; для другой системы сначала фиксирую, какие статусы, записи и API доступны.
Сколько звонков гоняете через модель?
Не весь поток. Обычно — событие риска, например переход в корзину, плюс дедуп повторных аудитов. Покрытие и пороги согласуем на пилоте по стоимости inference и нагрузке РОПа.
