Когда сегодня обсуждают экономику ИИ-агентов, разговор очень быстро скатывается к цене токенов. Сколько стоит миллион входных и выходных токенов? Какой будет темп расходования бюджета? Какую модель взять, чтобы не переплачивать? Если размещаемся в контуре заказчика, то сколько нужно GPU-ускорителей и какой будет их утилизация?
Все эти вопросы правильные. Но если мы говорим про корпоративный клиентский сервис — ответов на эти вопросы критически недостаточно.
Клиентский сервис — не место, где агент «просто отвечает на вопрос». В реальных условиях он должен понять обращение, поднять контекст клиента, сходить в CRM, проверить статус заказа или полиса, соблюсти ограничения по персональным данным, иногда выполнить транзакцию, корректно передать обращение оператору и оставить после себя понятный след в системах учета. Если это голос, добавляются ASR, TTS, телефония, задержки, перебивания, шумы, очереди, маршрутизация и мониторинг качества разговора.
Поэтому считать стоимость такого агента только по токенам — примерно как считать стоимость контактного центра по цене электричества для компьютеров операторов.
Почему токены кажутся дешевыми
На уровне «сырой» модели экономика действительно выглядит почти магически. В статье InfoWorld приводится простой расчет: если агент потребляет 2 млн токенов в день, то за год получается 730 млн токенов. При условной усредненной цене $3 за 1 млн токенов это около $2 190 в год на одного агента поддержки клиентов.
На фоне ФОТ операторов, супервайзеров и инфраструктуры контактного центра цифра выглядит почти незаметной. Отсюда рождается соблазнительная презентационная арифметика: берем текущий объем обращений, умножаем на цену токенов, сравниваем с зарплатами операторов и получаем окупаемость «почти сразу».
Но в промышленной эксплуатации живет не модель. В промышленной эксплуатации живет система.
Что появляется вокруг модели
Даже если не уходить в экзотику, промышленный агент для службы заботы требует минимум несколько слоев:
-
платформа оркестрации агентов;
-
управление инструкциями для модели, версиями и выпусками;
-
поиск по базе знаний (RAG) или другой способ доступа к знаниям;
-
интеграции с CRM, расчетной системой, телефонией, DWH, BI и внутренними API;
-
observability: журналы событий, трассировка, показатели, оповещения, стоимость по сценариям;
-
оценка качества диалогов и регрессионная проверка поведения;
-
ограничители поведения, права доступа, аудит действий;
-
защита персональных данных и контурные требования;
-
контур с участием человека для сложных, рискованных или эмоционально чувствительных обращений.
В InfoWorld это описано как множитель к стоимости токенов: реальная эксплуатационная стоимость может быть в 2-5 раз выше сырой стоимости токенов, а для регулируемых и критически важных сред еще выше. Для клиентского сервиса это особенно заметно, потому что ошибка агента редко остается «внутри системы». Ее слышит клиент.
Агент, который отвечает, и агент, который решает
В клиентском сервисе ключевая экономическая единица — не ответ и не диалог. Это решенное обращение. Если агент красиво отвечает, но не может проверить статус заказа, оформить возврат, записать клиента, изменить данные, отправить уведомление или корректно эскалировать обращение, он снижает нагрузку только на простых вопросах. Это тоже полезно, но потолок автоматизации будет невысоким.
Видимый экономический эффект появляется там, где агент закрывает сквозные задачи первой линии. Агенты на больших языковых моделях дают рост автоматизации и CSI не потому, что «говорят человеческим языком», а потому что понимают контекст и действуют как человек в рамках процесса. Но действие в рамках процесса — это всегда интеграции, права, тестирование, ограничения и ответственность. То есть стоимость.
Самая часто забываемая статья затрат: команда заказчика
Во многих расчетах стоимость поставщика видна хорошо: лицензия, минуты, диалоги, внедрение, поддержка, оборудование. А команда заказчика куда-то исчезает. Как будто корпоративная система сама отдаст API, сама согласует доступы, сама опишет процессы и сама примет выпуск версии.
На практике со стороны заказчика почти всегда нужны люди:
-
бизнес-аналитик, который понимает клиентские сценарии, исключения и целевые показатели;
-
интеграционный разработчик или системный аналитик, который разбирается во внутренних API;
-
специалист по телефонии, если речь идет о голосе;
-
владелец процесса в клиентском сервисе;
-
ИБ, юристы, ответственные за персональные данные;
-
специалисты или команда контроля качества диалогов.
Из моего опыта участия в подобных проектах для расчета можно заложить 3 ШЕ команды внедрения со стороны заказчика и 1 ШЕ на мониторинг и контроль качества. Это вещь, которую нельзя упустить из виду: если эти люди не включены в расчет, проект на бумаге окупается быстрее, чем в жизни.
Целевой уровень автоматизации не появляется в день запуска
Еще одна инфантильная привычка — считать экономию так, будто агент в первый день промышленной эксплуатации уже работает на целевом уровне автоматизации.
В реальности внедрение имеет кривую:
-
Разработка и тестирование.
-
Первый запуск в промышленную эксплуатацию на ограниченных сценариях.
-
Сбор реальных диалогов и ошибок.
-
Донастройка агента, базы знаний, интеграций и эскалаций.
-
Расширение тематик.
-
Стабилизация качества.
-
Выход на целевую автоматизацию.
Это не ошибка технологии, а нормальная динамика внедрения. На базе знакомых мне клиентских примеров: в одном корпоративном проекте автоматизация выросла с 0 до 52% за 6 месяцев; в другом — с 0 до 55% за первые 4 месяца. Это не «почему не 80% сразу?», а нормальный путь от первого запуска к промышленному эффекту.
Поэтому честный расчет должен учитывать постепенный выход на целевую “мощность”. В первый месяц экономия может быть меньше затрат. Потом кривая пересекает точку безубыточности. Потом проект начинает давать чистый эффект.
Так, в SaaS-модели платформы голосовых ИИ-агентов при допущении 300 тыс. минут трафика в месяц, пределе автоматизации 81%, 3 ШЕ команды внедрения заказчика и 1 ШЕ мониторинга прогнозируемая окупаемость — около 9 месяцев. В модели размещения в контуре заказчика, где появляются закупка оборудования, лицензии и внутренняя инфраструктура, окупаемость растягивается примерно до 20 месяцев.
Это все еще может быть очень хорошей экономикой. Просто она уже похожа на реальный корпоративный проект, а не на демонстрационный калькулятор.
Почему появляются «95% неуспешных внедрений ИИ»
Публичные отчеты про генеративный ИИ часто звучат драматично: только небольшая доля проектов дает измеримый эффект, большая часть пилотных проектов не достигает целевых показателей. Такой тезис легко превратить в набившее оскомину «ИИ не работает».
Но в клиентском сервисе чаще правильнее сказать иначе: не работает ожидание, что производственный эффект можно получить без производственного внедрения.
Если агент не встроен в процессы, не имеет доступа к нужным системам, не умеет передавать сложные обращения оператору, не проходит регулярную оценку качества, не управляется через выпуски версий и не имеет владельца на стороне бизнеса, он останется пилотным проектом. Даже если модель сама по себе достаточно мощная.
Технология может быть сильной, но организационная часть все-равно не исчезает.
Как считать честно
Минимальная формула для обсуждения экономики агента клиентского сервиса должна выглядеть не так: 
И даже не так: 
А примерно так:
совокупная стоимость = платформа + работа модели + связь + интеграции + внедрение + команда заказчика + мониторинг + контроль качества + безопасность + поддержка + стоимость постепенного выхода на мощность
А эффект:
эффект = сэкономленные минуты операторов + снижение пиковых нагрузок + доступность 24/7 + рост качества + управляемость + аналитика — стоимость ошибок и эскалаций
Для финансовой модели лучше использовать несколько показателей:
-
стоимость решенного обращения;
-
стоимость автоматизированной минуты;
-
доля сквозных закрытых обращений;
-
LCR / доля удержанных в автоматизации обращений;
-
CSI/NPS по автоматизированным обращениям;
-
доля передач оператору и причины таких передач;
-
стоимость контроля качества;
-
время до точки безубыточности;
-
чистый эффект по годам, а не только в целевом режиме.
Особенно важно считать не только «идеальный третий год», но и первый год, где команда внедрения еще работает, автоматизация растет постепенно, а часть затрат уже понесена.
Что из этого следует для менеджеров и инженеров
Для менеджера главный вывод простой: ИИ-агент не является бесплатным цифровым сотрудником. Это программная система с вероятностным ядром, вокруг которого нужно построить понятный контур надежности. Чем больше автономии вы даете агенту, тем больше должны инвестировать в контроль, тестирование, права, наблюдаемость и эскалации.
Для инженера вывод другой, но связанный: стоимость агента часто определяется не моделью, а архитектурой вокруг нее. Не всегда нужен «агент» там, где достаточно классификатора, правила, роботизации процессов или одного вызова языковой модели. Агентность оправдана там, где есть многошаговая задача, неполная информация, динамическое планирование, работа с инструментами и исключениями.
В клиентском сервисе таких задач много. Но именно поэтому здесь нельзя относиться к агенту как к окну чата с хайповой моделью под капотом.
ИИ-агенты для клиентского сервиса действительно могут менять экономику поддержки: закрывать первую линию, держать пики нагрузки, работать 24/7, снижать стоимость обращения и давать аналитику по причинам контактов. Это одна из тех технологий, которые способны радикально изменить привычную операционную модель.Но радикальность технологии не отменяет трезвого внедрения.
Если считать только токены, проект будет выглядеть почти бесплатным. Если добавить платформу, интеграции, безопасность, команду заказчика, мониторинг качества и кривую выхода на целевую автоматизацию, экономика станет менее волшебной, но гораздо более управляемой.
И это хорошая новость. Потому что зрелый расчет не убивает проект. Он снижает вероятность завышенных ожиданий, недостигнутых показателей и разочарования, из которого потом рождаются рассказы про «ИИ не взлетел».
ИИ-агенты «взлетают» не там, где их считают дешевыми, а там, где их считают как полноценную корпоративную систему.
ссылка на оригинал статьи https://habr.com/ru/articles/1055934/