Как сделать ИИ-агента для анализа звонков и контроля качества

Что получится в результате

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

Первая рабочая версия будет делать так:

1. запись звонка попадает в `call_recordings`;
2. n8n создает строку в `call_queue`;
3. агент сохраняет метаданные звонка: менеджер, клиент, сделка, длительность, направление;
4. STT-сервис делает расшифровку;
5. текст попадает в `transcript_log`;
6. LLM выделяет summary, вопросы клиента, возражения, next steps и обещания;
7. правила из `scorecard_rules` оценивают звонок;
8. результат пишется в `qa_results`;
9. спорные оценки уходят в `qa_review_queue`;
10. задачи менеджеру и руководителю попадают в `coaching_tasks`;
11. разрешенные поля готовятся для CRM в `crm_updates`;
12. ошибки и спорные кейсы пишутся в `error_log` и `appeal_queue`.

В первой версии агент не должен штрафовать сотрудника, менять KPI, публиковать оценки, раскрывать записи лишним людям и делать кадровые выводы без ручной проверки.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Источник звонков: телефония, CRM, Aircall, Twilio, Asterisk, Zoom, Google Meet или ручная папка с аудио.
• Google Drive или S3 для хранения записей и transcript.
• Google Sheets для очередей, scorecard, логов и review.
• STT-сервис для speech-to-text.
• LLM API для summary, извлечения фактов и оценки по чек-листу.
• 20-50 тестовых звонков с разным качеством.
• Руководитель или QA-специалист, который подтвердит scorecard.
• Правила хранения записей, доступа и оспаривания оценки.

Шаг 1. Выберите один тип звонка

Не начинайте со всех разговоров компании.

Для первого прототипа выберите один сценарий:

входящие звонки поддержки по обращениям клиентов

Входит:

• запись звонка;
• расшифровка;
• краткое summary;
• причина обращения;
• соблюдение скрипта;
• корректность решения;
• тон общения;
• next step;
• задача руководителю, если есть риск качества.

Не входит:

• оценка всех менеджеров;
• автоматический штраф;
• кадровые решения;
• публикация рейтингов;
• анализ личных разговоров;
• прослушка без правил;
• запись чувствительных данных без маскирования.

Проверка: вы можете описать один тип звонка, одну команду и один итоговый отчет.

Шаг 2. Зафиксируйте правила записи и доступа

Перед технической сборкой согласуйте правила.

Нужно решить:

• какие звонки можно записывать;
• нужно ли предупреждать клиента;
• где хранится запись;
• сколько дней хранится запись;
• кто видит аудио;
• кто видит transcript;
• кто видит scorecard;
• какие данные маскируются;
• кто может оспорить оценку;
• какие звонки запрещено анализировать.

В `settings` добавьте:

retention_days
mask_phone
mask_email
mask_payment_data
allow_manager_access
allow_employee_appeal
qa_publish_mode

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

Шаг 3. Создайте структуру папок

В Google Drive или S3 создайте:

Call quality AI agent
  call_recordings
  archive
  transcripts
  qa_reports
  needs_review
  coaching_notes
  test_calls

Правило:

оригинальная запись сохраняется в archive
transcript хранится отдельно
qa_reports не содержат лишних персональных данных

Проверка: тестовую запись можно положить в `call_recordings`, а копия появляется в `archive`.

Шаг 4. Создайте таблицу проекта

Создайте Google Sheet:

Call quality AI agent

Добавьте листы:

call_queue
call_metadata
transcript_log
scorecard_rules
qa_results
qa_review_queue
coaching_tasks
crm_updates
appeal_queue
audit_log
error_log
test_cases
settings

Проверка: n8n имеет доступ к таблице на чтение и запись.

Шаг 5. Настройте call_queue

В `call_queue` добавьте колонки:

call_id
created_at
source_system
recording_url
archive_url
transcript_url
call_type
direction
agent_email
customer_id
crm_deal_id
duration_seconds
status
qa_score
risk_level
current_owner
review_reason
last_error
updated_at

Статусы:

new
registered
transcribing
transcribed
analyzing
scoring
needs_review
coaching_created
crm_ready
done
error

Проверка: один тестовый звонок можно добавить со статусом `new`.

Шаг 6. Создайте call_metadata

В `call_metadata` храните нормализованные данные звонка.

Колонки:

call_id
started_at
ended_at
source_system
direction
agent_email
agent_team
customer_phone_masked
customer_email_masked
crm_contact_id
crm_company_id
crm_deal_id
queue_name
call_disposition
recording_duration
language
created_at

Проверка: один и тот же формат используется для Aircall, Twilio, CRM и ручных загрузок.

Шаг 7. Создайте scorecard_rules

В `scorecard_rules` опишите чек-лист качества.

Колонки:

rule_id
call_type
criterion
description
max_points
critical
evidence_required
owner_role
is_active

Первый набор для поддержки:

greeting | support | приветствие и идентификация | 5 | no | yes | qa
problem_clarified | support | оператор уточнил проблему | 10 | no | yes | qa
solution_correct | support | предложено корректное решение | 20 | yes | yes | qa
no_false_promise | support | нет ложных обещаний | 20 | yes | yes | manager
next_step_fixed | support | зафиксирован следующий шаг | 10 | no | yes | manager
tone_ok | support | спокойный и корректный тон | 10 | no | yes | qa
crm_update_needed | support | нужны данные для CRM | 5 | no | no | sales_ops
escalation_needed | support | сложный кейс передан выше | 10 | no | yes | support_lead

Проверка: у каждого критерия есть максимум баллов и требование к доказательству.

Шаг 8. Настройте входящий workflow

Создайте workflow:

Call quality intake

Минимальные узлы:

1. `Webhook`, `Schedule Trigger`, `Aircall`, `Twilio`, `HTTP Request` или `Google Drive Trigger`;
2. `Get call metadata`;
3. `Generate call_id`;
4. `Copy recording to archive`;
5. `Append row to call_queue`;
6. `Append row to call_metadata`;
7. `Set status = transcribing`.

Формат ID:

CALL-2026-000001

Проверка: новая запись создает строку в `call_queue` и `call_metadata`.

Шаг 9. Сделайте транскрибацию

Создайте workflow:

Call transcription

Правила:

• если transcript уже есть в телефонии, заберите его;
• если есть только аудио, отправьте в STT;
• если запись длиннее лимита, разбейте на части;
• если язык неизвестен, определите его;
• если качество плохое, ставьте `needs_review`;
• если в тексте есть платежные данные, маскируйте.

Сохраняйте transcript в `transcripts`:

CALL-2026-000001.txt

Проверка: по звонку есть текст, который можно прочитать и сверить с аудио.

Шаг 10. Заполните transcript_log

В `transcript_log` добавьте колонки:

call_id
transcript_url
stt_provider
language
words_count
confidence
speaker_labels
masked
quality_status
created_at

Статусы качества:

good
medium
bad
empty

Правило:

bad или empty -> status = needs_review

Проверка: плохая расшифровка не получает жесткий QA-score.

Шаг 11. Разберите звонок в JSON

Создайте LLM-узел `Extract call facts`.

Prompt:

Разбери transcript звонка. Верни только JSON.
Не оценивай сотрудника на этом шаге.
Если факта нет в transcript, ставь null.

Формат:
{
  "call_summary": "",
  "customer_goal": "",
  "customer_problem": "",
  "questions_asked": [],
  "objections": [],
  "promises_made": [],
  "risks": [],
  "next_steps": [],
  "crm_facts": [],
  "sensitive_data_detected": true|false
}

Проверка: summary и next steps основаны на transcript, а не на догадках.

Шаг 12. Запишите qa_results

В `qa_results` добавьте колонки:

qa_result_id
call_id
rule_id
criterion
score
max_points
evidence_quote
explanation
critical_failed
confidence
created_at

Проверка: каждая оценка имеет цитату или явное указание, почему доказательства нет.

Шаг 13. Оцените звонок по scorecard

Создайте LLM-узел `Score call`.

Prompt:

Оцени звонок по scorecard.
Используй только transcript и правила.
Верни JSON array.
Не делай кадровых выводов.
Не ставь 0 без цитаты или объяснения.

Каждый объект:
{
  "rule_id": "",
  "score": 0,
  "evidence_quote": "",
  "explanation": "",
  "critical_failed": true|false,
  "confidence": 0.0
}

Проверка: scorecard заполняется одинаковым форматом для всех звонков.

Шаг 14. Рассчитайте общий qa_score

Суммируйте баллы:

qa_score = sum(score) / sum(max_points) * 100

Risk level:

high: critical_failed=true или qa_score < 60
medium: qa_score 60-79
low: qa_score >= 80

Если `confidence < 0.7` по критичному правилу:

status = needs_review
review_reason = low_confidence_score

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

Шаг 15. Создайте qa_review_queue

В `qa_review_queue` отправляйте спорные звонки.

Колонки:

review_id
call_id
reason
risk_level
assigned_owner
question
transcript_url
recording_url
status
decision
decision_comment
created_at
closed_at

Причины:

bad_transcript
critical_failed
low_confidence_score
sensitive_data_detected
customer_complaint
employee_appeal
qa_score_too_low

Проверка: низкая оценка или плохая расшифровка уходит человеку.

Шаг 16. Подготовьте coaching_tasks

В `coaching_tasks` создавайте конкретные задачи, а не абстрактные “улучшить качество”.

Колонки:

task_id
call_id
agent_email
manager_email
task_type
task_text
evidence_quote
status
due_date
created_at
closed_at

Типы задач:

review_call
practice_script
fix_crm
follow_up_customer
escalate_issue
update_knowledge_base
manager_feedback

Проверка: задача содержит конкретный фрагмент звонка и действие.

Шаг 17. Подготовьте crm_updates

В `crm_updates` храните только черновики изменений.

Колонки:

crm_update_id
call_id
crm_deal_id
crm_contact_id
update_type
draft_text
fields_to_update
status
approved_by
created_at

Что можно готовить:

• summary звонка;
• next step;
• задача перезвонить;
• причина обращения;
• риск сделки;
• обещание клиенту;
• тема для follow-up.

Проверка: CRM обновляется после approval или хотя бы через черновик, а не прямой записью от модели.

Шаг 18. Сделайте уведомление руководителю

Сообщение:

Звонок CALL-2026-000001 требует внимания.
Менеджер: manager@example.com
Тип: support
QA score: 58
Риск: high
Причина: критичный пункт no_false_promise
Ссылка на отчет: ...

Не отправляйте аудио и полный transcript в открытый чат.

Проверка: руководитель получает короткую карточку и ссылку на защищенный отчет.

Шаг 19. Создайте appeal_queue

Сотрудник должен иметь возможность оспорить оценку.

В `appeal_queue` добавьте колонки:

appeal_id
call_id
agent_email
qa_result_id
appeal_text
status
reviewer
decision
decision_comment
created_at
closed_at

Статусы:

open
accepted
rejected
need_more_info
closed

Проверка: спорная оценка не остается окончательной без процесса.

Шаг 20. Ведите audit_log

В `audit_log` добавьте колонки:

event_id
call_id
event_type
actor
source
details
created_at

Логируйте:

• получение записи;
• копирование в archive;
• создание transcript;
• маскирование данных;
• запуск анализа;
• расчет scorecard;
• создание review;
• создание coaching task;
• создание CRM draft;
• решение QA;
• апелляцию.

Проверка: можно восстановить, почему звонок получил оценку и кто ее подтвердил.

Шаг 21. Настройте error_log

В `error_log` добавьте колонки:

error_id
call_id
workflow_name
node_name
error_type
error_message
input_snapshot
status
owner
created_at

Типы ошибок:

recording_not_found
permission_denied
audio_download_failed
stt_failed
empty_transcript
llm_json_invalid
scorecard_missing
crm_match_failed
notification_failed
sensitive_data_not_masked

Проверка: если звонок не обработался, видно, где именно произошел сбой.

Шаг 22. Создайте test_cases

В `test_cases` добавьте тестовые звонки.

Колонки:

test_id
recording_url
expected_call_type
expected_quality_status
expected_risk_level
expected_flags
expected_score_range
last_run_at
last_result

Первый набор:

good_support_call
bad_transcript_noise
false_promise_call
no_next_step
angry_customer
short_empty_call
call_with_payment_data
call_without_crm_match
excellent_discovery
employee_appeal_case

Проверка: изменение prompt или scorecard не ломает старые ожидаемые результаты.

Шаг 23. Прогоните полный путь на одном звонке

Порядок:

1. положите аудио в `call_recordings`;
2. проверьте строку в `call_queue`;
3. проверьте копию в `archive`;
4. проверьте `call_metadata`;
5. проверьте transcript в `transcript_log`;
6. проверьте `qa_results`;
7. проверьте общий `qa_score`;
8. проверьте `qa_review_queue`, если есть риск;
9. проверьте `coaching_tasks`;
10. проверьте `crm_updates`;
11. проверьте `audit_log`;
12. проверьте отсутствие ошибок в `error_log`.

Проверка: от записи звонка до coaching-задачи процесс проходит без ручного копирования текста.

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• запись создает строку в `call_queue`;
• метаданные пишутся в `call_metadata`;
• оригинал сохраняется в `archive`;
• transcript сохраняется в `transcript_log`;
• плохая расшифровка уходит в review;
• scorecard считается по `scorecard_rules`;
• каждая оценка имеет evidence_quote;
• общий `qa_score` считается по баллам;
• критичные нарушения уходят в `qa_review_queue`;
• coaching-задачи создаются в `coaching_tasks`;
• CRM-изменения остаются черновиками в `crm_updates`;
• апелляции можно вести через `appeal_queue`;
• история видна в `audit_log`;
• ошибки пишутся в `error_log`;
• `test_cases` проходят после изменения prompt.

Что нельзя автоматизировать в первой версии

• штрафы и кадровые решения;
• публикацию рейтингов сотрудников;
• доступ к записям без прав;
• отправку полного transcript в открытые чаты;
• выводы по плохой расшифровке;
• прямое изменение CRM без approval;
• анализ звонков без правил записи и хранения;
• хранение платежных и чувствительных данных в transcript;
• финальное решение по спорной оценке без человека.

Частые вопросы

Можно ли начать без интеграции с телефонией?

Да. Для прототипа достаточно папки `call_recordings`, куда вручную кладутся 10-20 тестовых записей. После проверки scorecard можно подключать Aircall, Twilio, CRM или другую телефонию.

Нужно ли хранить аудио или хватит transcript?

Для QA лучше хранить защищенную ссылку на аудио, потому что transcript может ошибаться. Но доступ к записи должен быть ограничен, а срок хранения нужно определить заранее.

Можно ли автоматически ставить оценку менеджеру?

Можно считать предварительный `qa_score`, но в первой версии низкие и критичные оценки лучше отправлять в `qa_review_queue`. Итоговую оценку подтверждает руководитель или QA.

Что делать с плохой расшифровкой?

Ставить `quality_status = bad`, отправлять звонок в review и не делать жестких выводов. Плохой STT может исказить смысл, особенно при шуме, перебиваниях и слабой записи.

Какой минимум нужен для запуска?

`call_queue`, `call_metadata`, `transcript_log`, `scorecard_rules`, `qa_results`, `qa_review_queue`, `coaching_tasks`, `crm_updates`, `audit_log`, `error_log`, n8n workflow и 10 тестовых звонков.