Резюме звонков в CRM: от транскрипции до следующего действия

AI-резюме звонка полезно, когда делает следующий операционный шаг проверяемым. Оно становится рискованным, когда гладкий абзац молча превращается в запись о клиенте, коммерческое обещание или задачу не тому человеку. Практическая задача уже: сохранить источник звонка, собрать разрешённый пакет транскрипта, получить структурированное резюме с evidence и uncertainty, применить CRM-правила и проверить записанный результат.

Это long-tail implementation guide, а не обещание заменить моделью sales или support-команду. Широкий локальный коммерческий запрос остаётся у страницы AI-специалист в Армении. Scope реализации смотрите в AI-автоматизации; публичные доказательства работ остаются отдельно в разделе кейсов.

1. Начните с записи звонка и границы данных

Надёжный workflow начинается до транскрипции. Call event должен иметь stable ID, tenant boundary, ссылку на запись или транскрипт, speaker labels при наличии, source timestamps, состояние consent/retention и CRM object, который потенциально получит результат. Модели не нужен безлимитный доступ к записям, всей истории заметок, несвязанным контактам или credentials.

Сначала зафиксируйте разрешённый вопрос:

• Результат — internal summary, draft follow-up, review task или proposed CRM field update?
• Какие части транскрипта можно использовать, хранить и показывать оператору?
• Какие утверждения являются evidence из звонка, а какие — интерпретацией?
• Какие темы всегда требуют человека: цены и обязательства, изменение договора, payment dispute, legal request, security incident, запрос на удаление данных или разговор с человеком?
• Кто владеет ambiguous contact match, плохой транскрипцией и отклонённым next action?

Source и proposal нужно хранить отдельно. Пример source envelope:

{
  "callId": "call-2026-08-09-041",
  "tenantId": "workspace-42",
  "recordingRef": "sealed://calls/041",
  "transcriptVersion": "asr-v3",
  "crmContactId": "contact-884",
  "policyVersion": "CALL-6",
  "retentionState": "permitted_internal_review"
}

Этот объект сохраняет то, что вошло в workflow; это не prompt. Модель получает меньший approved packet: выбранные spans транскрипта, разрешённый CRM context, фиксированную output schema и taxonomy действий. Если speaker attribution сомнительна, это нужно сохранить как uncertainty, а не превращать в уверенную фразу клиента.

2. Используйте CALL-6: источник, summary, policy, owner, read-back

Модель может сделать длинный разговор удобным для оператора. Она не должна превращать неопределённую реплику в authoritative CRM update. Одна контролируемая последовательность CALL-6 выглядит так:

1. Capture идентифицируемый call receipt, source references, tenant boundary и применимое состояние retention/consent.
2. Prepare bounded transcript packet: нормализовать timestamps, redaction исключённых данных, отметить speaker uncertainty и сохранить transcript version.
3. Propose typed summary с evidence spans, unresolved questions, declared next actions и uncertainty band.
4. Validate schema, identity CRM object, action taxonomy, required fields и policy constraints без передачи этого решения модели.
5. Review or gate обязательства, sensitive topics, ambiguous identity, слабое transcript evidence и consequential updates у named owner.
6. Commit and reconcile одно idempotent internal write или approved task, затем сделать CRM read-back и записать correction/recovery.

В CRM должны быть отдельные поля для source call, proposal, deterministic policy decision, final human-edited outcome и destination receipt. Зелёный status job доказывает только запуск кода, но не то, что у нужного контакта появилась правильная задача или follow-up.

{
  "callId": "call-2026-08-09-041",
  "summary": "Клиент попросил внутренне проверить текущий onboarding workflow.",
  "evidence": [{ "start": "00:08:14", "end": "00:08:29", "text": "Could your team review our onboarding flow?" }],
  "nextAction": "create_review_task",
  "owner": "account_team",
  "confidenceBand": "review_required",
  "policyVersion": "CALL-6"
}

Proposal не даёт права обещать срок delivery, менять договор, обновлять lifecycle stage или писать клиенту. Это отдельные решения со своей authority.

3. Явно опишите CRM и transcript contracts

Call summary проходит через telephony/meeting provider, speech-to-text, context service, AI step, CRM, task system и operations. У каждого слоя должна быть узкая ответственность.

Idempotency key строят из tenant, call ID, transcript version, action type и policy version. Provider retry или пересозданный transcript не должны создать duplicate tasks или затереть human correction. Перед commit сравнивайте ожидаемую CRM record version с текущей: если запись изменилась после proposal, отправляйте случай на review.

Policy gate обязан направить на review, когда source отсутствует, качество транскрипта недостаточно, identity ambiguous, evidence не поддерживает action, action вне allowed taxonomy, у контакта есть более новая human note или CRM write нельзя authoritative read-back. Смежные границы разобраны в AI-обогащении CRM и AI-ассистенте для sales email.

4. Проверьте неудобные случаи до запуска

Не проверяйте workflow только на чистых звонках и идеальных транскриптах. Соберите representative acceptance set с реальными языками, качеством аудио, перебиваниями, акцентами, product terminology и типами звонков. Храните минимум данных, нужных для оценки, в рамках применимых retention rules.

Включите сценарии:

• клиент меняет мнение или делает два несвязанных запроса;
• голоса пересекаются, имя распознано неверно или segment транскрипта потерян;
• contact match слабый либо есть несколько CRM records;
• клиент просит человека, удаление данных, смену договора, возврат или помощь с безопасностью;
• во время разговора упомянуты цена или дата, которые не должны стать commitment;
• транскрипт пересоздан после human correction;
• CRM приняла write, но read-back недоступен;
• provider повторно доставил тот же call event;
• модель вернула valid JSON с неподдерживаемым action;
• policy изменилась между proposal и commit.

Acceptance criteria должны быть наблюдаемыми:

• Каждое summary ссылается на stable source и transcript version.
• Каждый важный вывод имеет permitted evidence либо помечен unresolved.
• Человек может исправить или отклонить summary без редактирования hidden model state.
• Sensitive, commercial и ambiguous actions попадают в настроенный review path.
• Retries не создают duplicate tasks и не перезаписывают более новые human changes.
• Destination read-back подтверждает write либо создаёт видимую reconciliation task.
• Не-AI процесс остаётся рабочим при pause transcription, model или CRM integration.

Оценивайте failure classes раздельно. Пропущенная несущественная деталь — не то же самое, что task не тому контакту или tentative discussion, ошибочно записанная как обещание. От этого зависит, где нужна правка: в транскрипции, context selection, schema, policy, CRM integration или operational training.

5. Эксплуатируйте сигналы слабых контрактов, а не vanity metrics

Полезные operational signals: source-receipt failures, изменения transcript version, summaries на review, unsupported action proposals, evidence gaps, причины operator corrections, duplicate-action blocks, stale CRM-version blocks, read-back failures, возраст reconciliation и использование pause switch. Они показывают слабые места workflow, но не доказывают качество звонков, конверсию, customer satisfaction или выручку.

Назначьте owner для call taxonomy и review rules, а также owner для integration incidents. Версионируйте prompts, schemas, transcript providers, policies и destination mappings, чтобы оператор мог объяснить появление конкретного proposal. Сохраните обычный manual note и task path: команда должна продолжать работу, пока AI step расследуется.

CALL-6 production acceptance gate

require(call.id && call.tenantId && transcript.version && policy.version);
require(proposal.schemaValid && proposal.evidence.length && action.isAllowed);
commit = reviewer.approved && destination.readBack && recovery.owner;

Gate не обещает более чистые звонки или лучший sales outcome. Он проверяет, что proposed next action имеет идентифицируемый источник, bounded context, валидную структуру, разрешённую authority, destination evidence и recovery owner.

Контролируемый первый rollout

Начните с одного internal use case — например, operator-reviewed summary — и одного reversible task type. Прогоните небольшой набор representative calls, включая messy и uncomfortable cases. Сравните proposal с финальной human record, сохраните source reference и проверьте CRM read-back. Расширяйте scope, только когда команда понимает correction patterns, identity boundary, retention rules и recovery path.

Такова полезная роль AI-резюме звонков: они делают переход от разговора к работе проверяемым, пока люди, policies и CRM records сохраняют authority. Чтобы обсудить controlled implementation, запросите пилот AI-автоматизации.