Дизайн ескалації AI-агента: 71% vs 30% за Stanford

Найбільша помилка SMB-власників у дизайні AI-агентів — плутати "питати людину про схвалення" і "ескалувати людині". Це не одне й те саме, і різниця між ними — приблизно 2.4× у вимірюваній продуктивності.

У чому різниця між approval та escalation?

Approval-routing: агент робить роботу, потім просить людину благословити кожен output. Людина — чек-поінт на happy path. Throughput обмежений увагою рев'юера.

Escalation-routing: агент діє автономно при високій впевненості і явно передає людині, коли впевненості нема. Людину викликають для кейсів, якими агенту не варто володіти, а не для тих, з якими він уже впорався.

Definition: Escalation rule — детерміністична умова (не "відчуття"), за якої агент перестає діяти і передає кейс іменованій людині, з контекстом і запропонованою дефолтною дією.

Це важливо, бо в approval-routing рев'юер — bottleneck на КОЖНІЙ взаємодії. У escalation — лише на тих, що цього потребують.

Чому escalation випереджає approval у ~2.4×?

Stanford-цифра — ~71% vs ~30% — має простий механізм:

1. Approval-routing створює чергу. Чергa додає wait time, не лише review time.
2. Рев'юер з 100% чергою починає швидко проглядати. Швидкий перегляд approve'ить погані outputs.
3. Рев'юер з 5-15% чергою реально читає. Читання ловить помилки.
4. Агенти, відкалібровані під escalation, отримують гостріший фідбек на саме ті кейси, де людина залучилась глибоко.

Тобто: approval-routing нічого не вчить агента і максимально витрачає увагу людей. Escalation вчить правильним урокам і витрачає мінімум.

Як виглядає добре спроєктоване правило escalation?

Три компоненти, без винятків:

1. Trigger condition. Вимірюваний сигнал — confidence нижче X, наявність ключових слів, тип документа, тариф клієнта, сума, мова — будь-що детерміністичне.
2. Default suggested action. Що, на думку агента, має статись, щоб людина accept/edit/reject, а не починала з нуля.
3. Named owner. Не "команда" — конкретна роль і бекап.

Якщо чогось із цього бракує — це не escalation, а флаг, який агент піднімає, перш ніж кинути кейс.

Шаблон матриці ескалації

Workflow: [назва]

Trigger                              | Owner            | Default action               | SLA
Confidence < 0.7                     | Lead reviewer    | Hold + людський draft        | 4h
Customer LTV > €50K                  | Account manager  | Auto-route, без auto-reply   | 1h
"complaint"/"refund" у тексті        | Support lead     | Hold + escalation tag        | 2h
Quote > €10K                         | Sales lead       | Draft + hold send            | 4h
Не-англомовний тред                  | Bilingual review | Hold + людський переклад     | 8h
Зовнішня юрособа в CC                | Legal/ops        | Hard stop, без auto-reply    | next biz day
Tool call failure x2                 | Eng on-call      | Stop, alert                  | 30m
Невідомий SKU                        | Product ops      | Hold + product lookup        | 4h

Якщо не вдається заповнити 4-6 рядків — у вас не дизайн ескалації, а сподівання.

Tool tip (AIAdvisoryBoard.me): Матриця настільки добра, наскільки добре ви розумієте сам воркфлоу. Запустіть 7-денний Plan → Fact → Gap до написання матриці. Plan — правила, які ви думаєте мають ескалювати; Fact — що дійсно йшло шкереберть останнього кварталу і хто це фіксив; Gap — рядок, який ви б інакше пропустили. Більшість матриць пишуться по пам'яті, не по даних. Як це показує діагностика — https://aiadvisoryboard.me/?lang=en.

Де ескалація типово ламається

Чотири повторювані провали:

1. Без "default suggested action." Агент ескалує "needs human review" без контексту. Людина робить роботу з нуля — повільніше, ніж без агента взагалі.
2. Vague triggers. "Ескалувати, коли клієнт виглядає сердитим" — не тригер, а сподівання. Мапте на конкретні терміни, sentiment scores чи патерни.
3. Один owner без бекапа. День, коли Марія у відпустці — і кожен escalated айтем гниє.
4. Без SLA. Ескалації падають у поштову скриньку, яку ніхто не зобов'язаний почистити за вікно.

Walk-back Klarna 2025 — частково історія про дизайн ескалації: агент не мав чітких правил передачі людині на кейсах, що псували CSAT, і коли патерн став видимим, довіра вже впала.

Як це поєднується з калібруванням впевненості?

Більшість сучасних агентів видають confidence score. Використовуйте його, але не довіряйте сліпо. Мапте до thresholds ескалації, потім аудит щотижня: серед айтемів, які агент позначив "high confidence", але які редагували/відхилили на гейті — який патерн? Підкручуйте threshold, не давайте scor'у "плисти".

Manager scan (2-minute digest example)

• Plan: "Агент ескалує на low confidence."
• Fact: Threshold = 0.5; 60% айтемів над ним. Із них 18% редагувались.
• Gap: Threshold замалий — поставте 0.75, ескалюватимете ~30%, але довіра до auto-handled 70% різко зросте.
• Plan: "Ескалація іде тому, хто на зміні."
• Fact: Двоє на зміні, жоден не названий owner'ом; 23 айтеми старіли >24h минулого тижня.
• Gap: Іменуйте primary + backup з ротацією на тиждень. SLA 4h.
• Plan: "Ескалюємо на negative sentiment."
• Fact: Sentiment-модель плутає сарказм, фрустровані лояльні клієнти йдуть не в ту чергу.
• Gap: Додайте детерміністичний backstop — будь-який тред зі словом "cancel" / "lawyer" ескалує незалежно від sentiment'у.

Tool tip #2 — ескалація як learning system

Tool tip (AIAdvisoryBoard.me): Матриця не статична — це живий артефакт, який тюнять щомісяця через Plan → Fact → Gap. Plan — поточна матриця. Fact — останні 30 днів: які тригери спрацьовували коректно, які ескалації були "no-op" (людина каже "агент мав рацію"), які auto-handled айтеми довелось переробляти. Gap — ревізія на наступний місяць. Команди, що ставляться до матриці як до code-once-deploy-forever, стагнують; ті, хто оновлюють її щотижневими доказами, тримають 71% gain в позитивному компаунді. Daily-management OS — https://aiadvisoryboard.me/?lang=en.

Micro-case (що змінюється за 7-14 днів)

SaaS-support на 200 людей замінює approval-routing на 8-рядкову матрицю ескалації для inbound-агента. Тиждень 1: ~22% айтемів ескалюються; рев'юери витрачають ~4 год/день на ескалації проти попередніх ~10 год/день на approvals. Тиждень 2: команда знаходить два false-escalation патерни і затягує матрицю; ескалація падає до 16%, час рев'юера до ~3 год/день. CSAT на auto-handled стабільний; CSAT на escalated росте, бо у рев'юерів нарешті є час написати справжню відповідь. Висновок власника: агент не став розумнішим — роутинг став.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

FAQ

Чи всім агентам потрібна escalation, не approval? Перші 2-4 тижні (human-review гейт) 100% approval — правильно. Після гейту перемикайтесь на escalation — саме там і з'являється Stanford'івський 71% gain.

Скільки рядків у матриці? 4-8 — sweet spot. Менше 4 — пропускаєте реальні ризики. Більше 8 — ескалюєте стільки, що вже простіше approval.

Що якщо confidence score нестабільний? Не робіть його єдиним тригером. Поєднуйте з детерміністичними правилами (ключові слова, тариф, сума). Confidence — корисний сигнал, не вирок.

Як це пов'язано з Klarna walk-back 2025? Відомий розворот Klarna з повного AI-CS — частково проблема дизайну ескалації: бракувало human handoffs у потрібні моменти. Урок: "AI-first з обов'язковою людською ескалацією" (патерн Intercom Fin) майже скрізь б'є "AI-only".

Працює і для внутрішніх агентів? Так — навіть чіткіше. Внутрішні агенти (HR triage, IT requests) виграють непропорційно: внутрішні юзери толерантніші до "перенаправлю до правильної людини", ніж до неправильної автовідповіді.

Що зробити цього тижня

Відкрийте воркфлоу, яким володіє (або володітиме) ваш агент. Накидайте 4-6 рядків ескалації за шаблоном. Для кожного — primary + backup owner, детерміністичний тригер, default action, SLA. Якщо клітинка розмита — ви знайшли роботу з дизайну, що має статись до запуску.

Якщо хочете систему, що щодня показує Plan → Fact → Gap по компанії — подивіться, як працює 7-денна діагностика: https://aiadvisoryboard.me/?lang=en