AI-агенты в поддержке: где они реально закрывают тикеты

За последний год крупные вендоры поддержки один за другим выкатили не чат-ботов с деревом сценариев, а именно агентов: систему, которая читает базу знаний компании, сама решает, ответить клиенту, вернуть деньги или передать тикет человеку. Intercom продаёт Fin, Zendesk и Salesforce встроили агентов в свои платформы, а стартапы вроде Sierra и Decagon строят вокруг этого весь бизнес. Обещание везде одно: закрыть значимую долю обращений без оператора. Вопрос в том, какую именно долю и какой ценой.

Что изменилось по сравнению с чат-ботами

Старый чат-бот работал по заранее прописанным веткам: нажмите 1, чтобы узнать статус заказа. Шаг влево от сценария — и клиент упирался в «я вас не понял». AI-агент¹ устроен иначе: он получает вопрос на естественном языке, ищет ответ в подключённых источниках (база знаний, документация, история заказов через API) и формулирует ответ сам. Если у него есть право на действие — оформить возврат, поменять тариф, отменить подписку — он его выполняет.

Ключевое отличие в том, что агент опирается на технику RAG²: он не выдумывает ответ из общих знаний модели, а подтягивает конкретные документы компании и отвечает на их основе. Это снижает риск галлюцинаций, но не убирает его: если в базе знаний ошибка или пробел, агент честно ответит неверно.

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

Сколько это стоит

Ценообразование в этой нише устроено непривычно. Часть вендоров берёт не за место оператора, а за решённое обращение (resolution) — то есть платите вы только тогда, когда агент реально закрыл тикет без человека. Intercom для Fin публично называл цену порядка 0,99 доллара за решённое обращение, но тарифы меняются, и перед расчётом бюджета их нужно сверять на официальной странице продукта. Salesforce и Zendesk используют смешанные модели: подписка плюс плата за разговоры или действия агента.

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

Сравнение подходов

Кому это пригодится, а кому нет

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

Где агент закрывает поток

• Массовые типовые вопросы. «Где мой заказ», «как сбросить пароль», «какие способы оплаты» — здесь агент отвечает быстрее человека и не устаёт к концу смены.
• Компании с хорошей документацией. Если у вас есть подробная база знаний и справочный центр, агент получает материал, на котором реально работает.
• Ночные и пиковые нагрузки. Агент снимает очередь, которую иначе пришлось бы закрывать переработками или потерянными клиентами.
• Первая линия перед эскалацией. Агент отсекает простое и передаёт человеку только то, что действительно требует человека.

Где он проваливается

• Эмоционально заряженные конфликты. Клиент, потерявший деньги или данные, хочет разговаривать с человеком, а не с формулировкой «понимаю ваше разочарование».
• Нестандартные и юридически чувствительные случаи. Спорный возврат, претензия, вопрос на грани договора — цена ошибки агента здесь выше экономии.
• Продукты без внятной документации. Агенту неоткуда брать правильный ответ, и он либо отказывается отвечать, либо галлюцинирует.
• Маленький поток сложных обращений. Когда тикетов немного и каждый уникален, окупить внедрение и настройку тяжело.

Замена или дополнение

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

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

Что проверить перед внедрением

1. Посчитайте долю типовых обращений в общем потоке — это потолок автоматизации.
2. Оцените качество базы знаний: без неё агент бесполезен.
3. Уточните модель оплаты у конкретного вендора и посчитайте её на вашем объёме тикетов, а не на маркетинговом примере.
4. Задайте правила эскалации: что агент никогда не делает сам и в каких случаях сразу зовёт человека.
5. Настройте контроль качества ответов агента хотя бы на первые месяцы.

¹ AI-агент — программа на базе языковой модели, которая не просто отвечает текстом, а сама выбирает и выполняет действия (запрос к API, оформление возврата, передача тикета человеку) для достижения цели, поставленной пользователем.

² RAG (retrieval-augmented generation) — подход, при котором модель перед ответом ищет релевантные документы во внешней базе и формулирует ответ на их основе, а не только на знаниях, зашитых при обучении.