Проектирование ИИ-агента клиентской поддержки: триаж, знания, действия и эскалация

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

Универсального и обоснованного процента автоматизации для «типичной очереди SaaS-поддержки» не существует. Сброс пароля, спор по оплате, сбой сервиса и ошибка продукта требуют разного уровня участия человека, а поставщики по-разному определяют, что считать решённым обращением. Агент может выдавать неподтверждённые или нарушающие правила ответы, даже если его язык звучит уверенно. Архитектура и методика измерения важнее эффектного процента в заголовке.

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

Четыре задачи агента поддержки

Полезный ИИ-агент поддержки последовательно делает четыре вещи:

1. Понять тикет. Что на самом деле спрашивает клиент? С какими эмоциями он сюда пришёл? К какой категории относится проблема?
2. Подтянуть нужный контекст. Аккаунт клиента, его историю с вами, релевантную документацию, похожие закрытые тикеты.
3. Решить, что делать. Ответить по существу, задать уточняющий вопрос, отправить человеку, выполнить действие над аккаунтом.
4. Исполнить авторизованное решение. Отправить ответ, задать вопрос, эскалировать или выполнить одобренное действие над аккаунтом, фиксируя доказательства, авторизацию и результат, необходимые для эксплуатации и аудита.

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

Архитектура

Один из вариантов процесса:

Входящий тикет
    ↓
[Агент триажа: классификация, приоритизация, маршрутизация]
    ↓
[Сбор контекста: данные клиента, история, RAG по базе знаний]
    ↓
[Агент принятия решений: предложение ответа или действия]
    ↓
[Шлюз правил: авторизовать, подтвердить, заблокировать или направить]
    ↓
[Составление ответа / контролируемое исполнение действия]
    ↓
[Проверка качества ответа, отправка или эскалация]

Блоки обозначают обязанности, а не обязательное число моделей или сервисов. Их можно объединить или разделить в n8n, агентном фреймворке либо собственном сервисе при условии, что граница авторизации остаётся вне модели. Поток напоминает паттерн маршрутизации из руководства Anthropic по созданию эффективных агентов, где среди примеров есть маршрутизация клиентской поддержки; это не гарантия, независимая от платформы.

Пройдёмся по каждому шагу.

Шаг 1: триаж

Триаж-агент принимает сырой входящий тикет и классифицирует его.

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

Вы — агент триажа службы поддержки [Company]. Классифицируйте каждый входящий тикет по трём измерениям:

1. CATEGORY: одно из
   - account_access (вход, пароль, MFA, заблокированный аккаунт)
   - billing (списания, возвраты, смена тарифа, счета)
   - product_question (инструкции, вопросы о функциях, настройка)
   - bug_report (что-то сломано или работает неожиданно)
   - feature_request (запрос функции, которой у нас нет)
   - complaint (недовольный клиент без конкретной технической проблемы)
   - other

2. URGENCY: одно из "critical" (продакшен недоступен, спор по оплате), "normal", "low" (информационный запрос).

3. EMOTIONAL_TONE: одно из "calm", "frustrated", "very_angry". Будьте честны.

Выведите JSON с полями `category`, `urgency`, `emotional_tone`, `confidence` и `needs_review`. Установите `needs_review`, если данных недостаточно или результат не проходит проверенный порог для этой категории.

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

Выход триажа может влиять на два решения по правилам:

• В одной политике обращения высокой срочности или с тоном very_angry сразу идут к человеку. Для другой очереди могут использоваться иные сигналы или потребоваться детерминированные правила инцидентов.
• Категория может ограничить доступные далее источник знаний и инструменты, но не должна сама предоставлять разрешения.

Шаг 2: сбор контекста

Качество контекста — существенная переменная качества поддержки. Без релевантных и авторизованных доказательств модель может заполнять пробелы неподтверждёнными выводами.

Три возможных источника контекста:

Данные клиента. Кто этот клиент? Тариф, возраст аккаунта, недавняя активность, статус оплаты, открытые тикеты. Обычно тянется из CRM или продуктовой БД через API.

История переписки. Этот клиент к вам обращался раньше? По какому поводу? Чем закончилось? Избегайте провала вида «я же вам это вчера сказал».

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

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

Получив тикет [content], соберите контекст:

1. Найдите клиента по email. Если найден, получите plan, account_age_days, recent_actions (последние 7 дней), open_tickets.

2. Найдите историю тикетов клиента (последние 90 дней). Получите до 5 последних тикетов с их resolution.

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

4. Найдите в базе решённые тикеты с похожими проблемами. Получите топ-2 с их resolutions.

Объедините в объект context.

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

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

Шаг 3: рассуждающий агент

Теперь агент предлагает, что делать. Этот промпт — пример правила решения, а не разрешение выполнить действие. Замените фиксированные денежные пороги, пороги уверенности и эмоционального тона значениями, одобренными для каждой категории обращений и юрисдикции:

Вы — специалист службы поддержки [Company]. Ваша задача — решить проблему клиента.

Для каждого тикета:

1. Внимательно прочитайте тикет и контекст. Контекст включает аккаунт клиента, его историю обращений к нам и релевантную документацию.

2. Выберите одно из этих действий:
   - RESOLVE: у вас есть уверенный ответ или решение. Составьте ответ.
   - CLARIFY: вам нужна дополнительная информация. Составьте уточняющий вопрос.
   - ESCALATE: это требует человека. Объясните почему.
   - ACT_AND_RESOLVE: предложите действие над аккаунтом (оформить возврат, сбросить пароль, сменить тариф и т. д.) и подготовьте ответ, который последует после него. Не выполняйте действие; последующий шлюз правил решит, можно ли это сделать.

3. Ваш тон — прямой, тёплый и компетентный. Соответствуйте регистру клиента. Никогда не поучайте. Никогда не извиняйтесь больше одного раза. Никогда не используйте шаблонную фразу «благодарим за терпение».

4. При ссылке на документацию давайте ссылку на конкретную статью. Не пересказывайте по памяти.

5. Если клиент расстроен, кратко и ясно признайте это, затем переходите к решению.

6. Всегда эскалируйте, если:
   - Клиент просит поговорить с человеком.
   - Вопрос связан с финансовым спором свыше €100 / $100.
   - Случай не проходит проверенный порог уверенности или правил для своей категории.
   - Тон клиента злой, а проблема не решается простым одношаговым действием.
   - Вопрос связан с безопасностью или конфиденциальностью.
   - Вопрос — жалоба на сотрудника нашей команды.

7. Ваш вывод должен быть JSON:
{
  "action": "<resolve|clarify|escalate|act_and_resolve>",
  "confidence": <0.0-1.0>,
  "reasoning": "<brief explanation>",
  "response_draft": "<the email body>",
  "escalation_reason": "<if applicable>",
  "action_to_take": "<if act_and_resolve, the specific action and arguments>"
}

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

Шаг 4: исполнение действия

Для RESOLVE и CLARIFY предложенный ответ всё равно проходит проверку качества и правил до отправки.

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

Для ACT_AND_RESOLVE модель предлагает действие. Отдельный контрольный путь решает, разрешено ли его выполнить. Руководство OWASP по избыточной агентности рекомендует минимальные функции и права, выполнение в контексте безопасности пользователя, последующую авторизацию и человеческое одобрение для действий с серьёзными последствиями. Примените эти меры к процессу поддержки:

• Белый список с минимальными правами. Предоставляйте только узкие операции. Правило может, например, разрешать наглядные возвраты до €50 и требовать проверки выше этой суммы, но реальная граница должна следовать из авторизованной политики, а не из этой статьи или промпта.
• Идентичность и авторизация. До выполнения определите аутентифицированного клиента, арендатора, оператора и предоставленный объём прав. Проверяйте доступ в последующем сервисе при каждом вызове; классификация или уверенность модели не могут предоставить разрешение.
• Валидированные аргументы. Ограничьте имена действий и аргументы схемой, отклоняйте неожиданные поля и непосредственно перед побочным эффектом заново проверяйте аккаунт, валюту, сумму, адресата и правило. Если поставщик поддерживает вызовы инструментов по строгой схеме, включите их. Например, режим strict для вызова функций в OpenAI обеспечивает соответствие схеме, но не доказывает авторизацию или фактическую правильность.
• Подтверждение и одобрение. Требуйте явного подтверждения клиента или одобрения человека там, где этого требуют риск, политика, право или неоднозначность. Чувствительное восстановление доступа должно следовать проверенной процедуре идентификации, а не общему действию сброса.
• Идемпотентность и конкурентность. Назначайте каждому действию ключ идемпотентности, не допускайте повторного выполнения при повторах и обрабатывайте устаревшее состояние аккаунта или конкурирующие обновления.
• Обратимость и обработка ошибок. Предпочитайте поэтапные или обратимые операции, предусмотрите откат или сверку при частичном сбое и направляйте неопределённый результат человеку вместо слепого повторения.
• Средства безопасности. Применяйте ограничения частоты, тайм-ауты инструментов, изоляцию арендаторов, обработку секретов и мониторинг злоупотреблений независимо от модели.
• Аудиторская запись. Записывайте идентификатор запроса, личности оператора и клиента, очищенные входы, идентификаторы и версии доказательств, результат проверки политики и авторизации, подтверждение либо данные ответственного за одобрение, точные аргументы действия, результат инструмента и состояние ошибки или отката. Сгенерированное моделью обоснование может помочь проверке, но не является аудиторским следом.

Шаг 5: проверка качества

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

Вы — рецензент качества ответов службы поддержки, сгенерированных ИИ.

Получив исходный тикет и подготовленный ответ, проверьте:

1. Ответ действительно отвечает на вопрос клиента?
2. Он точен на основе предоставленного контекста (без выдуманных фактов)?
3. Тон правильный (тёплый, прямой, без поучений, без чрезмерных извинений)?
4. Есть ли битые или неверные ссылки?
5. Содержит ли он какие-либо из этих красных флагов:
   - Обещание того, что мы не можем выполнить
   - Извинения за то, в чём мы не виноваты
   - Злой или саркастичный тон
   - Использование внутреннего жаргона
   - Раскрытие внутренней информации

Вывод: APPROVE или REVISE (с конкретными предложенными исправлениями).

Если проверка качества вернула APPROVE и ответ прошёл правила, его можно отправить. Если получен REVISE, примените ограниченное исправление и проверьте снова либо направьте человеку. Ограничьте число автоматических исправлений, чтобы сбойный детектор не создавал цикл.

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

Сделайте базу знаний проверяемой

База знаний — один из критически важных факторов качества агента. Если ваш help-центр устарел, противоречив или неполон, агент может выдавать уверенные, но неподтверждённые ответы.

Практические принципы:

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

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

Включайте явные секции «do NOT». Многие тикеты — про то, как сделать то, что клиенту делать не стоит. Статьи базы знаний должны явно говорить: «если вы пытаетесь сделать X, вот почему мы это не рекомендуем, и вот альтернатива».

Представляйте область применимости. Метаданные вроде «только бесплатный тариф», «только клиенты ЕС» или «только приложение iOS» могут поддерживать фильтры. Принудительно применяйте эти ограничения на уровне извлечения и тестируйте исключение противоречивого или неприменимого материала.

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

Калибруйте эскалацию по правилам и оценкам

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

Направлять человеку или в специализированную очередь:

• Явные просьбы поговорить с человеком.
• Гнев выше порога (особенно после одной плохой реплики агента).
• Споры о реальных деньгах.
• Вопросы безопасности или приватности.
• Влияние на здоровье, безопасность или юридические последствия.
• Повторные тикеты от одного клиента по одной и той же проблеме.
• Случаи, которые не проходят проверенный порог уверенности или правил для своей категории.

Кандидаты на автоматизацию после прохождения соответствующих оценок:

• Тривиальные вопросы с чёткими ответами в KB.
• Бытовое обслуживание аккаунта (сброс пароля, базовые изменения профиля).
• Запросы статуса («мой возврат прошёл?»).
• Запросы на новые фичи (направляются в продуктовую команду, а не в живую поддержку).

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

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

Рассчитайте целевой уровень автоматизации по своей очереди

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

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

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

Измеряйте результаты для клиента

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

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

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

Повторяющийся автоматизированный цикл без рабочего пути к человеку — предсказуемый режим отказа. Измеряйте повторные обращения и прерванные сессии, ограничивайте автоматические повторы и делайте эскалацию заметной.

Несколько конкретных паттернов

Персонализация может быть уместна. «Здравствуйте, Анна, вижу, что вы на тарифе Pro и с нами с 2023 года» воспринимается иначе, чем «Здравствуйте, клиент». Используйте только одобренные сведения, которые помогают решить вопрос, и избегайте деталей, создающих ощущение слежки.

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

Подтверждайте релевантную деталь. «Вы упомянули, что импорт ломался на записях со специальными символами в названии компании». Используйте это только при точном соответствии обращению; повторение не доказывает понимание системой.

Заканчивайте проверенным следующим шагом. «[Платёжная система] приняла возврат в [время]. Текущее окно зачисления — [проверенная политика или срок поставщика]». Не утверждайте по черновику модели, что действие выполнено, и не придумывайте срок поступления.

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

Разобранный пример

Клиент пишет:

Здравствуйте! Уже три дня не могу войти: система всё время пишет, что пароль неверный. Я уверен, что ввожу правильный пароль — пользуюсь им два года. Начинаю думать, что вас взломали.

Более безопасный черновик после проверки аккаунта и одобренного пути восстановления:

Здравствуйте, Анна!

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

Воспользуйтесь ссылкой восстановления аккаунта на нашей проверенной странице входа: [одобренный URL восстановления]. До завершения сброса процесс восстановления проверит вашу личность. Не сообщайте службе поддержки пароль, одноразовый код, код восстановления или ссылку сброса.

Если вы не узнаёте эти попытки, не можете пройти проверенный процесс восстановления или заметили неизвестный сеанс либо изменение аккаунта, ответьте здесь, и я направлю обращение команде безопасности аккаунтов. Их целевой срок ответа — [проверенный SLA очереди безопасности].

— Служба поддержки AI Expert

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

Что создавать в первую очередь

Устанавливайте целевой уровень решения обращений по размеченной исходной выборке и данным пилота, а не по этой статье или кейсу поставщика. Модель — лишь одна часть системы. Основных рычагов четыре:

1. Управляемая и оценённая база знаний.
2. Надёжный сбор контекста (данные клиента, история, извлечение из KB, похожие закрытые тикеты).
3. Рассуждающий агент с чёткими критериями решений и правилами эскалации.
4. Контрольные шлюзы (авторизация, белые списки, подтверждение, проверки ответа и аудиторские журналы).

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

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

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