Як Intercom Fin вимірює resolution rate AI-агента на Claude

У customer support легко показати велику automation rate: бот відповів, людина не підключилася, тікет закрито. Але мовчання клієнта може означати як успішну відповідь, так і втому, відмову від каналу або невдалу пораду. Кейс Fin важливий не лише заявленими результатами, а тим, що Intercom публічно описує denominator і стани, з яких складається resolution rate.

Anthropic повідомляє, що Fin на Claude автоматично вирішує в середньому 51% звернень одразу після запуску, а окремі клієнти досягають показника до 86%. Це provider-reported діапазон, а не незалежний benchmark. Порівнювати з ним власний pilot можна лише після вирівнювання каналів, складності запитів, правил ескалації, періоду вимірювання та самого визначення resolved.

У поточній документації Intercom resolution rate — частка Fin-involved conversations, де агент дав відповідь і діалог завершився confirmed або assumed resolution. Confirmed означає явну позитивну реакцію користувача. Assumed означає, що після останньої відповіді користувач не попросив людину й не дав негативної реакції. Отже показник містить як сильний, так і слабкий outcome signal.

Це не робить метрику неправильною, але вимагає декомпозиції. Dashboard має окремо показувати confirmed resolution rate, assumed resolution rate, escalation rate, pending rate, повторне звернення з тієї самої проблеми та downstream correction. Інакше зміна timeout, close rule або escalation guidance може підняти headline rate без покращення допомоги клієнту.

• Confirmed → користувач явно підтвердив, що отримав допомогу;
• Assumed → після відповіді не було запиту на додаткову допомогу;
• Escalated → користувач або policy передали діалог людині;
• Pending → агент чекає уточнення або наступної дії;
• Reopened/recontact → проблема повернулася після формального закриття.

Anthropic описує Fin через чотири capability layers. Knowledge знаходить grounded відповідь у матеріалах компанії. Behavior застосовує tone, guidance і policy. Actions виконують процедури на кшталт перевірки eligibility, refund або account change. Insights агрегують сигнали з підтримки. Такий поділ корисніший за формулу «додати чатбот»: кожен шар має інший failure mode і доказ якості.

Knowledge перевіряють на citation support, freshness і retrieval coverage; behavior — на policy adherence та стабільність між мовами; actions — на schema validation, idempotency, authorization і side-effect receipts; insights — на traceability до розмов і захист персональних даних. Спільний model call не скасовує окремих контрактів цих компонентів.

Intercom розповідає, що під час розробки Fin 2 провів понад 120 A/B tests. Команда відхиляла зміни, які збільшували resolution rate ціною вищої hallucination rate. Це принципова деталь: coverage і correctness утворюють constrained optimization, а не одну метрику, яку треба максимізувати.

Практичний release gate порівнює candidate з baseline на однаковому наборі діалогів. Promotion дозволяється, якщо confirmed resolution або task success зростає, а unsupported-claim rate, policy violation, wrong action, avoidable escalation і customer recontact залишаються в погоджених межах. Для рідкісних high-impact помилок потрібен абсолютний stop condition, навіть якщо середнє покращилося.

Відповідь про refund policy і фактичне повернення коштів — різні рівні authority. Для інформаційного запиту достатньо актуального джерела й коректної цитати. Для action агент має ідентифікувати клієнта, перевірити eligibility у system of record, сформувати структуровану пропозицію, пройти policy gate і отримати execution receipt.

A4 тут означає bounded autonomy: дозволені процедури можуть завершуватися без синхронного approval, але лише в межах суми, типу акаунта, каналу й risk class. Неясна особа, суперечливі записи, виняток із policy або незворотна дія переводять workflow у human handoff. Текстова впевненість моделі не розширює її повноваження.

• read → знайти policy та стан акаунта;
• propose → створити typed action без side effect;
• validate → перевірити identity, eligibility і межі;
• commit → виконати вузьку idempotent operation;
• verify → записати receipt і показати результат клієнту;
• escalate → передати людині повний trace без повторного опитування.

Середнє 51% і максимум до 86% описують різні зрізи. Перше Anthropic та Intercom пов’язують із середнім out-of-box результатом, друге — з найкращими customer deployments. Різниця може залежати від якості knowledge base, query mix, мов, maturity, дозволених actions і escalation policy. Без розподілу cohort ці значення не доводять очікуваний результат конкретної компанії.

Перед business case зафіксуйте власний baseline: eligible conversations, confirmed і assumed resolutions, human handling time, repeat-contact window, CSAT coverage, wrong-answer severity та cost per verified outcome. Публікуйте numerator, denominator і exclusions поруч із відсотком. Це запобігає ситуації, коли з denominator прибирають складні діалоги, а потім називають решту всією підтримкою.

Почніть з одного intent family, де є authoritative content і безпечний handoff: наприклад, зміна плану без індивідуальної знижки. На першому етапі агент працює у shadow mode: пропонує відповідь і наступну дію, а команда порівнює їх із фактичним outcome. Потім малий cohort отримує grounded answers, але всі account changes залишаються draft-only.

Лише після проходження eval дозволяйте одну reversible action через typed tool. Щотижневий review розбирає assumed resolutions, повторні звернення, ескалації та action failures. Розширення intent coverage відбувається після доказу стабільності, а не після досягнення красивого загального відсотка.