AI слушает звонки, сверяет CRM и ничего не меняет: как я собрал QA-агента через MCP

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

Ниже — кейс и пошаговый разбор, как повторить: поднять MCP-сервер, завести агента в Yandex AI Studio и подключить его к CRM.

Зачем это вообще понадобилось

Клиент звонит в автодилеру: «Хочу приехать посмотреть машину». Оператор обсуждает условия, разговор длится несколько минут. Через пять минут в CRM появляется статус «корзина».

В CRM всё выглядит нормально: статус проставлен, обязательные поля заполнены. Для компании — возможно, только что потеряли клиента.

Это типовая боль дилерского колл-центра: клиент хотел приехать / взять кредит / посмотреть авто → лид «умер», а РОП узнаёт об этом случайно или никогда.

Прослушать все звонки невозможно. Слушать «на глаз» по длительности — врёт: длинный звонок ≠ интерес, короткий ≠ мусор.

Отсюда идея AI QA: модель читает расшифровку, отвечает на два независимых вопроса — что произошло в разговоре? и совпадает ли с этим CRM? — и кладёт кейс в очередь руководителю. И главное: AI не меняет статус лида. Никогда.

Почему обычных правил CRM недостаточно

В CRM давно живут детерминированные правила — без нейросетей, на фактах из карточки, телефонии и валидации UI. Они умеют:

• считать SLA реакции по регламенту дилера;

• мерить KPI операторов: missed / connect / длительность;

• подсвечивать дубли по телефону;

• блокировать дыры в карточке: визит без даты не сохранить, «приехал» без даты конверсии — тоже.

Они отвечают на вопросы «успели ли ответить? был ли звонок? не дубль ли это?». Но не на главный: что на самом деле сказал клиент — и честен ли статус «корзина»?

«Дорого / подумаю / только нал» нельзя свести к SQL-условию без ложных срабатываний. Человек слышит контекст, но все записи не прослушать. Поэтому два слоя:

Слой A— детерминизм: отбирает риск и меряет процесс

Слой B— AI QA: понимает смысл разговора и сверяет со статусом,

     только очередь на human review

Что именно делает AI

Порядок мышления жёстко зафиксирован:

факты → сигналы → вердикт → сверка с CRM → приоритет → рекомендация

Вердикт по разговору — один из пяти:

Правила, которые спасают от ложных тревог: «дорого / подумаю» сами по себе ≠ отказ; нет ясности → «непонятно», а не «придумай статус»; плохая расшифровка → проверка качества данных, не алерт.

Сверка с CRM — четыре исхода: совпадает; похоже, потеряли лид (интерес в речи, корзина в CRM); похоже, зря держат открытым; нужна ручная проверка.

Красный флаг — сильный интерес (визит, покупка, финансы, обмен, тест-драйв) + корзина + прямая цитата клиента. Без цитаты высший приоритет запрещён: лучше пропустить серый кейс, чем заспамить РОПа. «Просто узнать цену» в «срочно» автоматически не попадает.

Результат — не свободный текст, а строгий JSON-контракт с версионированием. Сейчас используем версию mvp_v1. Выдержка из реального ответа модели:

{
  "lead_id": 53464,
  "policy_version": "mvp_v1",

  "transcript_quality": {
    "usable": true,
    "asr_confidence": 0.92,
    "speaker_labels": true,
    "duration_sec": 124,
    "issues": []
  },

  "conversation": {
    "disposition": "INTERESTED",
    "intent_level": "HOT",
    "confidence": 0.88,
    "final_client_position": "хочет приехать сегодня",
    "signals": [
      {
        "type": "VISIT_INTENT",
        "speaker": "client",
        "evidence": "хочу приехать сегодня, продиктуйте адрес",
        "strength": "STRONG",
        "confidence": 0.90,
        "negated": false
      }
    ]
  },

  "crm_consistency": {
    "result": "FALSE_NEGATIVE",
    "confidence": 0.95,
    "reason": "явный интерес к визиту, но лид в корзине",
    "ui_label": "Похоже, потеряли лид"
  },

  "critical": [
    {
      "id": "C4",
      "severity": "P0",
      "title": "Потерянный интерес — корзина после явного запроса визита",
      "evidence": "хочу приехать сегодня, продиктуйте адрес",
      "signal_type": "VISIT_INTENT",
      "confidence": 0.90
    }
  ],

  "severity": "P0",
  "recommended_action": "REVIEW_STATUS"
}

Почему JSON, а не свободный текст? Потому что следующий слой системы должен одинаково понимать результат агента — а человек в очереди должен видеть конкретные поля, а не прозу.

Если модель ошибётся в формате или пропустит обязательное поле — такой аудит не пройдёт валидацию по схеме и просто не попадёт в очередь РОПа.

Что ещё есть в полном контракте, но не попало в выдержку: checks (проход по чек-листам Q1–Q4, S1–S3), coaching (подсказки для РОПа), review (структура решения человека — CONFIRMED / REJECTED / NEEDS_MORE_DATA), suspected_root_cause (гипотеза о причине: оператор, процесс CRM, клиент, качество записи). Модель обязана вернуть все обязательные поля — иначе submit_qa_audit отклонит аудит.

(В API поля называются disposition / crm_consistency / critical; на уровне продукта это «вердикт по разговору», «сверка с CRM» и «красные флаги» с C4 как главным.)

Почему AI не имеет права менять CRM

На первый взгляд самый простой вариант — дать агенту ещё один инструмент update_lead_status() и закрыть задачу полностью.

Я специально этого не делал.

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

Как это выглядит глазами РОПа

РОП открывает вкладку «AI QA» и видит очередь: у каждого кейса — приоритет, цитата из разговора, ссылка на звонок и кнопки «подтвердить / отклонить».

РОП видит не «нейросеть сказала плохо», а доказательство.

Что происходит под капотом

Теперь самое интересное: что происходит под капотом, когда новый лид оказывается в корзине?

CRM ── событие: lead → basket

    ↓

   очередь (crm_qa_jobs)

    ↓

   worker

    ↓

   AI-агент (Yandex AI Studio)

    ↓ MCP tools

   MCP ── CRM / таймлайн / транскрипт

    ↓

   AI QA аудит → вкладка у РОПа

Как агент ходит в CRM через MCP

Сначала — что делает система:

AI

 ↓ get_lead()

 ↓ get_transcripts()

 ↓ сформировать вердикт

 ↓ submit_qa_audit()

А уже потом — протокол. MCP (Model Context Protocol) — стандарт подключения AI к внешним системам через «инструменты»: функции, которые достают данные напрямую из системы. Какой и когда вызвать — агент решает сам.

Основные инструменты: get_lead, get_lead_timeline, get_transcripts, get_statuses (с готовыми признаками «закрыто» / «корзина», чтобы модель не гадала), submit_qa_audit, get_qa_queue, review_qa_audit — и другие.

Сначала тот же MCP жил в Cursor (stdio — локально, рядом с редактором): удобно отлаживать схему на реальных лидах. Потом поднял HTTP-копию на VPS для Яндекса.

Как подключить MCP к Yandex AI Studio

Шаг 0. До Studio. MCP-сервер доступен извне по HTTPS с валидным TLS; эндпоинт отвечает на initialize (проверяется любым HTTP-клиентом — иначе Studio молча не покажет инструменты); токен Bearer лежит в одном источнике правды — secrets.

Шаг 1. Создать агента. Сильная instruct-модель + системная инструкция + компактный JSON-контракт. Для MVP контракт лежит прямо в инструкции.

Шаг 2. Подключить MCP. В настройках агента: URL, транспорт Streamable HTTP, авторизация Bearer. Сохраняем — Studio подтягивает список инструментов.

Шаг 3. Проверить в чате. «Проведи AI QA по лиду 53464» — и смотрим реальные вызовы: get_lead → get_transcripts → submit_qa_audit.

Шаг 4. Автоматизация через Responses API. В Yandex Cloud — сервисный аккаунт и API-ключ с правом yc.ai.languageModels.execute.

client.responses.create(

  prompt={"id": "<agent_id>"},

  input="Проведи AI QA по лиду 53464. Сохрани через submit_qa_audit.",

)

[скрин: успешный запуск через API]

Перед публикацией скринов: замазать токены, домены, телефоны и имена клиентов.

Как превратить чат в автоматизацию

Чат — для проверки. В проде система event-driven: реагирует на событие и сама запускает работу.

status changed → job → worker → Responses API → agent → audit

• триггер — переход именно в корзину (и лид не был в ней до этого);

• дедуп: pending-задачи и недавние аудиты не плодим;

• разговор ≥ ~30с предпочтителен, но job ставится и без локальной записи — агент доберёт данные через MCP;

• всё асинхронно: оператор не должен ждать 60–120 секунд модель в том же HTTP, что сохраняет статус.

Что получилось на практике

За первые сутки работы системы РОП вернул в работу 80 лидов — клиентов, которые просто сгорели бы в корзине.

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

И критически важно, как это произошло: система сама не поменяла ни одного статуса — она лишь подсветила, куда смотреть. Финальное решение по каждому случаю принимал человек.

Что не делал и почему

• Не давал AI менять статусы CRM.

• Не гонял 100% звонков через модель — только рискованные кейсы (переход в корзину).

• Не делал «качество речи» главной метрикой: срочность ≠ quality_score.

• Не превращал поиск виноватого в истину: suspected_root_cause — лишь гипотеза о причине (оператор / процесс CRM / клиент / качество записи), решение принимает человек.

Что измерять дальше

Результат первых суток — это старт, а не точность. Чтобы честно оценить систему, нужно накопить статистику подтверждений и ложных тревог. Вот критерии, по которым буду оценивать результат:

• % корзин, дошедших до QA;

• precision P0 — доля кейсов, подтверждённых РОПом;

• ложные тревоги;

• доля «непонятно»;

• время до review;

• лиды, возвращённые в работу после «пересмотреть статус».

Без human review метрики AI QA — самообман.

Статья — про подход и архитектуру MVP, а не универсальный «AI для всех колл-центров». Не начинайте с вопроса «куда встроить AI». Начните с конкретной ошибки бизнеса, которую уже можно измерить, и дайте агенту только тот контекст и те полномочия, которые нужны для её поиска.