Кейсы ИИ-агентов: какие цифры проверять перед покупкой

«Сократили время в 10 раз». «Автоматизировали 80% работы». «Получили рост конверсии на 37%».

Звучит сильно. Но до покупки ИИ-агента важнее другой вопрос: что именно посчитали?

Одна большая цифра без исходной точки, периода, выборки и затрат ничего не доказывает. Иногда за ней стоит хороший проект. Иногда - удачный день, ручная работа команды и показатель, который к деньгам вообще не относится.

Ниже - практическая проверка кейса ИИ-агента. Она помогает за 10-15 минут понять, где есть измеримый результат, где пока только гипотеза, а где цифру лучше не использовать для решения.

Коротко: что должно быть в проверяемом кейсе

Если хотя бы половины этих пунктов нет, перед вами не обязательно плохой проект. Но это ещё не доказанный кейс. Это повод задавать вопросы, а не повод сразу переносить цифры в финансовую модель.

Почему большая цифра ещё не означает результат

ИИ-агент работает внутри процесса. На итог одновременно влияют качество данных, правила, интеграции, сотрудники, сезонность, спрос и обычные изменения в бизнесе.

Поэтому фраза «после запуска выросли продажи» слабее, чем кажется. Продажи могли вырасти из-за акции, нового трафика или сильного менеджера. Чтобы связать изменение с агентом, нужен хотя бы честный способ сравнения и описание других факторов.

Активность не равна ценности

Число запросов, сгенерированных текстов и запущенных сценариев показывает, что системой пользовались. Но не показывает, что работа стала лучше.

Пятьсот подготовленных ответов не радуют, если половину пришлось переписывать. Тысяча обработанных лидов не помогает, если агент неверно определял приоритет. Активность полезна как технический показатель, но покупать нужно не активность.

Скорость без качества тоже обманывает

Можно сократить подготовку документа с часа до десяти минут, а потом потратить сорок минут на проверку и исправления. В презентации останутся «10 минут». В процессе останутся те же пятьдесят.

Поэтому скорость нужно считать до принятого результата, а не до первого черновика.

Проверка кейса за 10 минут

Не начинайте с интерфейса, модели или списка интеграций. Сначала восстановите логику доказательства.

1. Что делали до запуска агента?
2. Что изменил агент?
3. Сколько единиц работы попало в расчёт?
4. За какой период собраны данные?
5. Как посчитана главная цифра?
6. Кто и сколько времени проверял результат?
7. Какие ошибки и исключения произошли?
8. С чем сравнивали результат?
9. Какие полные затраты учли?
10. Что из этого можно повторить в другом процессе?

Если на эти вопросы есть короткие и проверяемые ответы, кейс можно разбирать дальше. Если ответ сводится к «мы использовали лучшие модели», технология подменила результат.

Шаг 1. Зафиксировать задачу и единицу результата

Формулировка «автоматизация продаж» слишком широкая. Внутри могут быть поиск контактов, подготовка резюме звонка, заполнение CRM, черновик письма или решение о скидке. Это разные задачи, риски и метрики.

Что считать единицей работы

Единицей может быть:

• один обработанный диалог;
• один принятый документ;
• одна карточка лида;
• один опубликованный материал;
• один закрытый запрос поддержки;
• один завершённый запуск сценария.

Чем конкретнее единица, тем сложнее спрятать неудачи в общем проценте.

Как проверить границы процесса

Спросите, где работа агента начиналась и где заканчивалась. Если система подготовила черновик коммерческого предложения, а менеджер собрал половину данных и полностью переписал текст, это не автономное создание предложения. Это ассистирование, которое тоже может быть полезным. Просто считать его нужно честно.

Шаг 2. Найти исходную точку

Без показателя до внедрения нельзя понять, что изменилось. Нужна база: прежнее время, стоимость, доля ошибок, конверсия или объём ручной работы.

Сравнивать одинаковое с одинаковым

До и после должны использовать одну формулу и одинаковые границы процесса. Нельзя до запуска считать всё время сотрудника, а после - только время работы модели. Нельзя сравнивать простые обращения после запуска со всей очередью до запуска.

Если история не сохранилась, допустим параллельный тест: часть похожих задач проходит старым способом, часть - через агента. Это не идеальная лаборатория, но уже лучше памяти участника о том, что «раньше было намного дольше».

Когда исходной точки нет

Такой проект может быть полезным, но вывод нужно ослабить. Вместо «сократили время на 60%» честно написать: «за период агент подготовил 42 результата, 31 приняли после проверки; данные до запуска не собирались».

Это не проигрыш. Это нормальная граница доказательства.

Шаг 3. Проверить период, выборку и сопоставимость

Процент без количества наблюдений легко выглядит серьёзнее, чем есть.

Один успешный запуск из одного - это 100%. Девяносто успешных из ста - 90%. Для решения о внедрении второй результат обычно полезнее, хотя цифра ниже.

Период должен захватывать обычную работу

Два дня демонстрации могут не включать пиковую нагрузку, нестандартные данные и смену ответственного сотрудника. Для пилота важнее увидеть несколько повторений процесса и хотя бы один проблемный сценарий.

Окно измерения должно совпадать

Если один материал получил 40 просмотров за сутки, а второй 50 за трое суток, сравнивать эти цифры нельзя. То же относится к лидам, ответам поддержки и документам: момент сбора должен быть одинаковым.

Шаг 4. Разобрать формулу и знаменатель

Главная защита от рекламной цифры - попросить формулу обычными словами.

Что скрывается за «80% автоматизации»

Возможны очень разные расчёты:

• агент запускался в 80% случаев;
• агент дошёл до конца в 80% запусков;
• 80% результата приняли без изменений;
• 80% времени процесса прошло без участия человека;
• автоматизировано 8 из 10 шагов, хотя два оставшихся занимают большую часть времени.

Все варианты могут быть правдой. Они означают разное.

Минимальная запись метрики

Хорошая формула помещается в одну строку:

доля принятых результатов = число результатов без обязательной доработки / все результаты агента за период

Рядом нужны числа. Например: 34 принятых результата из 50, то есть 68%. Тогда видно и процент, и масштаб проверки.

Шаг 5. Разделить технические, качественные и бизнес-метрики

Одна метрика не описывает весь результат. Я делю показатели на четыре уровня.

Почему нужен набор, а не одна звезда

Технический успех без качества создаёт поток ошибок. Качество без операционной выгоды может не окупить внедрение. Бизнесовая метрика без связи с действиями агента превращается в красивое совпадение.

Для первого пилота часто достаточно одной главной метрики результата и двух защитных: качество и число исключений. Потом добавляются деньги.

Шаг 6. Посчитать полную стоимость результата

Стоимость модели - лишь одна строка. В полном расчёте есть подготовка данных, интеграции, инфраструктура, наблюдение, проверка, исправления и поддержка.

Формула, которая ближе к реальности

стоимость принятого результата = все затраты процесса за период / число результатов, прошедших критерий приёмки

Если делить только счёт за токены на все черновики, экономика получится слишком красивой.

Какие затраты чаще забывают

• время сотрудника на подготовку входных данных;
• ручную проверку и исправление;
• повторные запуски после ошибок;
• хранение и передачу данных;
• поддержку интеграций;
• работу руководителя или эксперта на согласовании;
• потери от неверного действия.

Отдельно полезно сверить расчёт со статьёй о ROI ИИ-агента и посмотреть, как меняется срок окупаемости при менее оптимистичной доле принятых результатов.

Шаг 7. Показать участие человека

Человек в процессе не портит кейс. Спрятанный человек портит расчёт.

Три разных роли человека

1. Подготовка. Сотрудник собирает данные и ставит задачу.
2. Проверка. Эксперт принимает, исправляет или отклоняет результат.
3. Вмешательство. Человек восстанавливает процесс после сбоя или принимает рискованное решение.

В кейсе важно указать время на каждую роль. Тогда можно понять, агент действительно снял нагрузку или просто перенёс её в новый интерфейс.

Автономность лучше считать по исходам

Полезный показатель - доля запусков, где агент завершил работу в пределах правил без обязательного вмешательства. Ещё полезнее разделить исходы: завершено, передано человеку по правилу, остановлено безопасно, завершено с ошибкой.

Эскалация по понятному правилу не всегда провал. Иногда это и есть правильное поведение.

Шаг 8. Попросить ошибки и ограничения

Кейс без ошибок выглядит не сильным, а неполным. В реальной работе встречаются пустые поля, недоступные сервисы, спорные формулировки и необычные запросы.

Что должно быть раскрыто

• сколько запусков завершилось ошибкой;
• сколько результатов вернули на доработку;
• какие типы задач агент не обрабатывает;
• где требуется обязательное подтверждение;
• что происходит при недоступности модели или интеграции;
• можно ли отменить неверное действие.

Почему ограничения повышают доверие

Они показывают границу, внутри которой цифра имеет смысл. Например, хороший результат на типовых обращениях поддержки нельзя автоматически переносить на претензии, возвраты и юридически значимые ответы.

Шаг 9. Проверить атрибуцию

Чем дальше метрика от действия агента, тем осторожнее вывод.

Если агент сократил время заполнения карточки CRM, связь прямая. Если после запуска выросла выручка, между событием и цифрой десятки факторов.

Вопросы к бизнес-результату

• Что ещё изменилось в этот период?
• Был ли контрольный сегмент или сопоставимая группа?
• Сохранилась ли разница после пилота?
• Какую часть результата команда готова приписать агенту?
• Есть ли метрика, которая связывает действие агента с итогом ближе?

Иногда честнее показать экономию времени и качество результата, а рост выручки оставить наблюдением, не причинным выводом.

Шаг 10. Найти первичный след

Слайд - это пересказ. Для проверки нужен след, из которого цифра собрана.

Что может служить доказательством

• выгрузка из CRM или системы поддержки;
• журнал запусков и вызовов инструментов;
• версия результата до и после проверки;
• протокол приёмки;
• одинаковые временные срезы аналитики;
• список ошибок и ручных вмешательств;
• формула, которую можно пересчитать.

Публиковать внутренние данные не обязательно. Но подрядчик должен уметь объяснить, где они хранятся, кто их проверял и как из них получена цифра.

Для агентных систем отдельно полезны трассы: последовательность решений, вызовов инструментов и остановок. Они помогают увидеть не только итог, но и путь, на котором появилась ошибка.

Как я показываю собственный кейс

На странице кейсов ИИ-агентов я разбираю собственный семидневный эксперимент с Telegram. Это внутренний кейс ShvedkovPRO, не клиентский проект и не обещание результата для другой компании.

Что в нём подтверждено

В период 10-16 августа 2026 года вышли все семь запланированных публикаций. Процесс проходил только в Telegram. Система поддержала регулярность выпуска.

Что не нужно из него заключать

Процесс не был полностью автономным. В отдельные дни потребовались ручное восстановление, исправление или подтверждение. Были задержка и дубль, блокировка связки, раздельная отправка текста и изображения, поздний опрос, замена слишком светлого визуала и ручной перезапуск после ошибки модели.

Первые показатели охвата нельзя честно сравнивать: они собраны в разные моменты. Поэтому этот кейс подтверждает производственную регулярность и показывает ошибки контура. Он не доказывает рост продаж или охвата.

Мне такая форма кажется полезнее идеальной истории. Видно, что сработало, где помог человек и что нужно измерять в следующем цикле.

Шаблон карточки кейса ИИ-агента

Используйте эту карточку для своего проекта или отправьте её подрядчику до встречи.

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

Красные флаги в кейсах внедрения ИИ

Процент без знаменателя

«Точность 95%» ничего не говорит без числа примеров, состава выборки и определения ошибки.

Сравнение разных процессов

До внедрения считают полный цикл, после - работу модели. Сложные случаи убирают из новой выборки, но оставляют в старой.

Экономия времени по ощущениям

Участников спрашивают, сколько они «примерно» тратили раньше, и сравнивают с секундомером после запуска. Лучше замерить сопоставимые задачи или прямо отметить слабость базы.

Ошибки исчезли из отчёта

Показывают только успешные запуски. Повторы, остановки и ручное восстановление называют техническими деталями и не включают в стоимость.

Бизнес-результат без атрибуции

Агент начал работать одновременно с новой рекламой, ценой и командой продаж, а весь рост записали на ИИ.

Нет даты проверки

Модели, тарифы, правила и интеграции меняются. Кейс без периода быстро превращается в вечную цифру из уже другого процесса.

Как сравнить два предложения подрядчиков

Попросите обоих описать один кейс по одинаковой карточке. Затем оцените не размер процента, а качество доказательства.

До договора полезно отдельно проверить подрядчика по ИИ-агентам и запросить не только демонстрацию, но и логику измерения.

Как принять решение о пилоте

Хороший кейс не обязан полностью совпадать с вашей компанией. Он должен показать, что команда умеет ставить границы, измерять результат и не прятать ручную работу.

Перед пилотом зафиксируйте:

1. одну операцию;
2. единицу результата;
3. исходную точку;
4. главную метрику и две защитные;
5. период и объём выборки;
6. допустимые ошибки;
7. роль человека и полномочия агента;
8. полную стоимость;
9. условие остановки;
10. формат итогового отчёта.

Такой подход хорошо сочетается с пилотом ИИ-агента: сначала доказать пользу в одном узком контуре, затем расширять доступы и нагрузку.

Если расчёт уже показывает, что процесс подходит, можно сравнить стоимость внедрения ИИ-агента с ценой текущей операции. А если нет базы, начните с измерения, а не с интеграций.

Частые вопросы

Какой кейс ИИ-агента можно считать доказанным?

Тот, где названы процесс, база сравнения, период, выборка, формула метрики, качество, полные затраты, участие человека, ошибки и ограничения. Цифру можно пересчитать по первичному следу.

Сколько наблюдений нужно для кейса?

Универсального числа нет. Выборка должна включать нормальную вариативность процесса и несколько повторений каждого важного сценария. Один удачный запуск подходит для демонстрации, но не для экономического вывода.

Можно ли доверять проценту автоматизации?

Да, если понятно, что стоит в числителе и знаменателе. Лучше считать не число автоматизированных шагов, а долю завершённых результатов без обязательного вмешательства и отдельно показывать безопасные эскалации.

Что важнее: скорость или точность?

Зависит от процесса, но скорость нужно считать до принятого результата. Если исправления съедают экономию, быстрый черновик не стал быстрой работой.

Нужно ли показывать ошибки публично?

Не обязательно раскрывать внутренние данные. Но в кейсе должны быть типы ошибок, их частота, способ восстановления и границы применимости. Иначе покупатель не сможет оценить риск.

Что делать, если у подрядчика нет похожего кейса?

Не требовать выдуманного сходства. Попросить показать качество измерения на другом процессе и собрать узкий пилот с заранее согласованными метриками. Для сложного проекта можно обсудить внедрение ИИ-агента, но решение всё равно должно опираться на ваш процесс и ваши данные.