Эскалация жалоб: как AI распознаёт риск, но не принимает финальное решение

Жалоба клиента — важный сигнал для поддержки, но плохое место для автономного действия. В сообщении могут быть раздражение, претензия по безопасности, приватности или оплате, просьба о возврате, угроза уйти к конкуренту либо неполный контекст. AI может помочь обнаружить паттерны и собрать evidence; он не устанавливает обязательство компании, не обещает remedy и не принимает финальное решение об эскалации.

Ниже — разбор узкой инженерной задачи «AI-эскалация жалоб клиентов». Он не заменяет broad commercial landing page AI-специалист в Армении. Scope внедрения находится в AI-автоматизации, а публичные подтверждения работ — в разделе кейсов.

1. Эскалация — это контролируемое решение, а не sentiment score

Небезопасное сокращение выглядит так: negative sentiment -> urgent ticket. Жалобы различаются по тяжести, доказательству и последствиям. Клиент может резко написать о небольшой задержке, а спокойное сообщение может содержать обоснованный риск по безопасности, данным или платежу. Поэтому система должна разъединять три вопроса:

• что именно сказано в source message и какими записями это подтверждается;
• какие indicators риска присутствуют в versioned taxonomy;
• какой authorized человек или deterministic policy выбирает следующее действие.

Начните с неизменяемой intake-записи: tenant, channel receipt, source message reference, event time, conversation version и policy version. Сохраните original language и attachment references. Краткое резюме для prompt не становится source of truth, а отредактированная позднее CRM-заметка не должна незаметно заменить исходное сообщение.

{
  "eventId": "evt-2026-08-10-0049",
  "tenantId": "workspace-42",
  "conversationVersion": 18,
  "sourceRef": "sealed://message/9914",
  "riskPolicyVersion": "ESCALATE-7",
  "delivery": "received",
  "decisionState": "evidence_pending"
}

Классификатор должен вернуть bounded proposal, а не instruction. Он может назвать detected signals, указать небольшие evidence spans, отметить missing context и выбрать review band. Он не должен формировать финальный legal, financial, safety или customer-facing decision.

2. Постройте ESCALATE-7 вокруг явной authority

ESCALATE-7 — reference workflow, который превращает жалобу в inspectable review packet. Он не зависит от провайдера: email, chat, voice transcription и social messages требуют adapters, но decision contract остаётся стабильным.

1. Receive подписанное или иначе verified source event и сохранить receipt.
2. Deduplicate по tenant, external event ID и operation, чтобы retry не создавал параллельные эскалации.
3. Resolve context только из allow-listed conversation, order, account и prior-case fields.
4. Extract evidence в typed proposal: topic, indicators, quotations или source offsets, uncertainty и blocked data.
5. Apply policy для category, account state, timing, customer request, contractual rule и required reviewer role.
6. Route review к named owner с deadline и non-AI fallback path.
7. Record the decision с rationale, authority, current source version и resulting command.

У модели есть authority только над заявленной output shape. Policy service определяет, нужна ли review и какая queue допускается. Reviewer принимает final disposition, когда правила требуют judgment. Destination system остаётся source of truth для того, существует ли эскалация, case, refund hold или customer response.

Для начальной маршрутизации используйте AI-маршрутизацию обращений. Если жалоба затрагивает CRM, статья об AI-обогащении CRM объясняет, почему нужны source hierarchy и read-back.

3. Дайте модели ограниченную evidence-задачу

Передавайте только данные, необходимые для review packet: разрешённый message text или redacted transcription, language state, current open-case flag, order или service reference, если доступен, и policy taxonomy. Не передавайте credentials, несвязанный account history, hidden notes или широкий customer profile только ради более уверенного текста.

type EscalationProposal = {
  eventId: string;
  indicators: Array<"safety" | "privacy" | "payment" | "service_failure" | "threat" | "unknown">;
  evidence: Array<{ sourceRef: string; excerpt: string }>;
  uncertainty: Array<"identity" | "missing_context" | "language" | "policy">;
  reviewBand: "mandatory" | "priority_review" | "standard_review";
  policyVersion: "ESCALATE-7";
};

Schema validity — это транспортная проверка, а не доказательство правильности классификации. Policy может требовать mandatory review, если клиент просит человека, претензия касается safety или privacy, identity неясна, source устарел, evidence нет, язык сообщения вне evaluated set либо следующее действие влияет на деньги, доступ или legal position.

Храните original text и detected language в разных полях. Если в production scope есть Armenian, Russian и English, тестируйте весь путь для каждого языка. Хороший результат на нескольких английских примерах не доказывает равную работу на другом языке. Не описывайте язык как autonomous support capability без human-reviewed operational workflow.

4. Спроектируйте failure modes до live rollout

Эскалация жалоб — прежде всего задача интеграций и governance. Проверьте ситуации, которые dashboard может скрыть:

• одно сообщение приходит дважды или out of order;
• модель находит risk label, но не может сослаться на разрешённый source span;
• CRM account неоднозначен или принадлежит другому tenant;
• policy меняется после proposal, но до review;
• клиент отвечает, пока case ждёт reviewer;
• reviewer открывает старый packet после решения human agent;
• destination write timeout-ится, хотя мог уже выполниться;
• attachment недоступен, небезопасен для обработки или хранится слишком долго;
• оператор ставит AI path на паузу во время incident;
• queue недоступна или deadline истёк.

Для каждого случая нужны safe state и owner. Неоднозначный destination write становится reconcile_required, а не blind retry. Proposal без evidence становится review_required, а не urgent escalation. Policy mismatch аннулирует packet и собирает его из current source. Paused model path всё равно принимает source event и ведёт его через обычный human intake.

5. Тестируйте полный contract и запускайте узкий pilot

Unit tests покрывают normalisation, tenant isolation, policy predicates, idempotency keys и stale-version rejection. Contract tests replay channel fixtures. Integration tests работают с реальным или sandbox case destination и читают запись обратно. End-to-end tests включают reviewer correction, expired decision и recovery ambiguous write.

Соберите acceptance set из representative complaint topics, lengths, channel formats, languages и известных edge cases. Храните минимально необходимое test data и provenance fixtures. Тяжёлые ошибки анализируйте отдельно от обычного routing quality: пропущенный urgent signal, cross-tenant disclosure, непроверенное обещание клиенту и duplicate external action требуют разного containment.

Полезные operational signals проверяемы, а не рекламны: duplicate blocks, evidence-missing proposals, mandatory-review queue age, overrides, stale-packet rejections, policy-version mismatches, destination read-back failures и reconciliation duration. Они показывают, где workflow нуждается в улучшении; они не доказывают customer satisfaction, compliance или бизнес-результат.

ESCALATE-7 production acceptance gate

require(event.id && tenant.id && source.receipt && policy.version);
require(proposal.schemaValid && proposal.evidence.length && proposal.sourceVersion === conversation.version);
escalate = policy.permits && reviewer.authorized && destination.readBack && recovery.owner;

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

Начните с одного канала, небольшой versioned taxonomy, review-first routing, named owner и reversible destination action. Прогоните historic или sandbox fixtures до небольшого live cohort. Обычная support queue должна работать, если model, adapter или policy service поставлены на паузу. Расширяйте scope только после понимания evidence quality, human correction, delivery ordering и recovery behavior.

AI может сделать intake жалоб понятнее, но не должен превращать probabilistic label в финальное решение. Для bounded architecture review и pilot design запросите разбор AI-автоматизации.