Cost per resolved: unit-экономика AI-автоматизации за 90 дней

Unit-экономика AI-автоматизации за 90 дней считается не «сколько сэкономили на FTE в слайде», а как cost per resolved: полная стоимость владения, делённая на число реально закрытых единиц работы с учётом handoff, переделок и простоев.

Я сажаю пилот на эту метрику с первой недели: иначе через месяц все спорят о «качественном ощущении», а бюджет уже съеден токенами, доработками интеграций и ночными разборами DLQ. Ниже — формула, KPI по месяцам и типичные поломки unit-экономики в бою.

---

Формула cost per resolved (CPR)

CPR = TCO периода / N успешно закрытых единиц, где «успех» = бизнес-критерий, а не «бот ответил».

Компонент TCO (30–90 дней)	Что включить	Часто забывают
Модель / API	Токены, voice, embedding	Пики, eval-прогоны, dev-стенды
Инфра	Хостинг, очереди, логи, secrets	Алерты, бэкапы, staging
Интеграции	CRM, телефония, мессенджеры	Повторные коннекторы после смены API
Люди build	Внедрение, промпты, guardrails	2–3 итерации после «готово»
Люди run	On-call, разбор DLQ, QA-выборка	Время менеджеров на handoff
Переделки	Баги, ложные эскалации	Репутационные скидки/компенсации
Compliance	Хранение, redaction, доступы	Юр. ревью шаблонов ответов

Что считать «resolved»

Тип потока	Единица resolved	Не считать resolved
Поддержка	Тикет закрыт без возврата 48–72ч	Авто-ответ «мы получили»
Квалификация лида	Карточка с полными полями + next step	Мусорный контакт в CRM
КП / документы	Отправлен согласованный артефакт	Черновик в чате без отправки
HR FAQ	Сотрудник получил policy-ответ	«Обратитесь в HR» без сути

Если в знаменатель класть «число сообщений бота», CPR всегда выглядит красиво и всегда врёт.

---

KPI-рамка 30 / 60 / 90 дней

Я не жду «окупаемости на второй неделе». Смотрю траекторию.

Горизонт	Фокус	Целевые сигналы
0–30	Стабильность трубы	Success rate, DLQ rate, p95, % handoff осмысленный
31–60	Качество решения	% resolved без правок, CSAT/QA sample, re-open rate
61–90	Экономика	CPR vs baseline human, ROI, доля авто-закрытия

Таблица сравнения с baseline

Метрика	До (человек)	После (AI+human)	Комментарий
Время до первого ответа			Обычно падает быстро
Время до resolved			Часто растёт, если много пинг-понга
Cost per resolved			Главный судья
% эскалаций			Высокий % не враг, если дешёвый triage
Ошибки high-risk			Деньги/юр. — строго к нулю

Правило: если CPR через 90 дней не ниже baseline на оговорённый % (или не даёт рост объёма при том же штате) — пилот не «масштабируем», а режем scope.

---

Что ломает unit-экономику в бою

Красивый POC умирает на одних и тех же статьях. Я закладываю их в модель заранее.

Поломка	Симптом в цифрах	Что делать
Токен-взрыв	API cost ↑ при том же N	Короче контекст, кэш, лимит tool-call
Handoff-пинг-понг	Время people run ↑	Пакет handoff + SLA матрица
Дубли в CRM	Лишние сделки, ручная чистка	Идемпотентность + suppress
Тихие потери лидов	Расхождение ads vs CRM	Очередь + DLQ + сверка
Вечный «ещё допилим»	Build hours не сходятся к нулю	Freeze scope, change board
Over-automation	High-risk ошибки	Вернуть human confirm на money/legal
Нет владельца метрик	Споры вместо решений	Один owner CPR + еженедельный разбор

Чеклист «экономика не нарисована»

1. TCO считает finance-friendly таблица, не скрин из кабинета API.
2. В N resolved только единицы с бизнес-определением.
3. People run — часы × ставка, не «ну это же между делом».
4. Есть baseline за те же 30 дней до пилота (или параллельная контрольная группа).
5. Сценарии high-risk вынесены: их «успех» ≠ авто-closed.

Без baseline любой ROI — маркетинг.

---

Как считать ROI без розовых слайдов

ROI периода ≈ (Выгода − TCO) / TCO.

Выгода я беру из двух корзин (можно комбинировать):

Корзина	Формула-смысл	Осторожно
Экономия труда	(минуты_human − минуты_после) × N × ставка	Не двойной счёт с FTE «уволили»
Рост объёма	Доп. resolved × маржа_на_единицу	Нужна связь с выручкой, не vanity
Скорость	Влияние SLA на конверсию/отток	Только с замером, не «кажется»

Мини-модель на 90 дней (шаблон)

1. Зафиксировать N_resolved_auto, N_resolved_human_assist, N_failed.
2. Собрать TCO (таблица выше).
3. CPR = TCO / (N_auto + N_assist с весом, если assist дешевле pure human).
4. Сравнить с CPR_baseline.
5. ROI = (CPR_baseline − CPR_new) × N_new_total / TCO − 1 (упрощённо для cost-saving кейса).

Если выгода в «росте продаж», отдельно трекаю attribution: иначе AI припишут лиды от рекламы.

---

Часто задаваемые вопросы

Какой CPR считать хорошим?
Тот, что устойчиво ниже baseline при не худшем risk profile. Абсолютное число без вашей ставки часа и сложности тикета бессмысленно.

Учитывать ли стоимость внедрения в 90 днях?
Да, но раздельно: build amortized (например, /6–12 мес) и run. Иначе пилот всегда «убыточен», а run-фаза — «волшебно дешева».

Что если 70% handoff?
Это может быть OK для triage: дешёвый intake + дорогой human на хвосте. Смотрите CPR и время до first useful action, не «% автомифа».

Как часто пересматривать модель?
Еженедельно — операционные метрики; раз в 30 дней — полная TCO/CPR; при смене модели/промпта/канала — внеочередной срез.

---

Читайте также

• TCO и ROI AI в бою: что ломается и как считать за 90 дней
• TCO AI-агента: KPI и стоимость владения за 30–90 дней
• Внедрение AI-агента за 90 дней: этапы и цифры

---

Помогу собрать вашу таблицу TCO и CPR под реальный поток заявок: https://raisovich.ru

Что входит в TCO при расчёте cost per resolved?

API и инфра, интеграции, build/run люди, переделки, compliance — не только счётчик токенов. People run считают часами × ставкой, включая handoff и DLQ.

Почему нельзя считать resolved по числу сообщений бота?

Resolved — бизнес-единица: закрытый тикет, квалифицированный лид, отправленное КП. Авто-ответ «мы получили» в знаменатель не кладут — иначе CPR всегда врёт.

На каком горизонте 30/60/90 дней смотреть экономику AI-пилота?

0–30: стабильность трубы; 31–60: качество решения; 61–90: CPR vs baseline и ROI. Масштабируют только если экономика устойчиво лучше оговорённого порога.