Как настроить ИИ-агента поддержки клиентов: база знаний, тикеты и handoff

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

Короткая версия: начните с agent assist и ответов по базе знаний, добавьте классификацию обращений, правила handoff, создание тикетов и контроль качества. Полную автономию включайте только для тем, где есть проверенные статьи и низкая цена ошибки.

Что мы собираем

Соберем практическую схему ИИ-агента поддержки. Она подойдет для сайта, Telegram, Zendesk, Intercom, Usedesk, Helpdesk, CRM или собственной системы тикетов.

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

Шаг 1. Выберите стартовый режим

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

• Agent assist: агент готовит черновик ответа для оператора.
• Semi-auto: агент отвечает сам по безопасным темам, а сложное передает человеку.
• Auto-support: агент сам закрывает типовые обращения, но с правилами эскалации и контролем качества.

Для большинства компаний лучший старт - agent assist или semi-auto. Так команда быстрее получает пользу и меньше рискует качеством поддержки.

Шаг 2. Разберите обращения по темам

Возьмите 100-300 последних обращений и разметьте их по темам. Это покажет, где агент реально поможет, а где пока опасно автоматизировать.

• Частые вопросы по настройке.
• Ошибки и технические проблемы.
• Тарифы, оплата, возвраты.
• Статус заказа или заявки.
• Жалобы и конфликтные обращения.
• Индивидуальные условия.
• Юридические и финансовые вопросы.

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

Шаг 3. Подготовьте базу знаний

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

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

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

Шаг 4. Настройте RAG для поддержки

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

• Индексируйте только опубликованные и актуальные статьи.
• Храните metadata: title, url, product, language, updated_at, audience.
• Используйте фильтры по продукту, тарифу, языку и правам доступа.
• Возвращайте 1-3 источника в ответе или во внутреннем summary.
• Проверяйте, что top-3 retrieval действительно содержит нужную статью.

Если база знаний большая, добавьте reranking. В поддержке часто есть похожие статьи, и обычный vector search может выбрать соседнюю тему.

Шаг 5. Опишите классификацию обращения

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

{
  "topic": "billing",
  "intent": "refund_request",
  "risk": "high",
  "sentiment": "negative",
  "needs_human": true,
  "missing_fields": ["order_id"]
}

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

Шаг 6. Добавьте правила handoff оператору

Handoff - это не фраза “обратитесь в поддержку”. Хороший handoff передает оператору контекст: что спросил клиент, какие статьи агент нашел, что уже уточнил и почему решил передать человеку.

Передавайте оператору, если:

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

Шаг 7. Создавайте тикеты аккуратно

Если каждое сообщение превращать в тикет, поддержка получит мусор. Тикет нужен, когда вопрос требует учета, передачи, SLA или дальнейшего действия.

• Создавайте тикет после явного обращения или неуспешного ответа агента.
• Заполняйте тему, категорию, приоритет, канал и клиента.
• Добавляйте summary диалога.
• Добавляйте ссылки на статьи, которые использовал агент.
• Не пишите в тикет секреты и лишние персональные данные.
• Не закрывайте тикет автоматически, если не уверены.

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

Шаг 8. Настройте SLA и приоритет

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

• P1: сервис недоступен, деньги списались неверно, безопасность, массовая проблема.
• P2: важная функция не работает у конкретного клиента.
• P3: обычный вопрос по настройке.
• P4: консультация, обучение, общая информация.

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

Шаг 9. Добавьте шаблоны ответов

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

Структура ответа:
1. Коротко подтвердить вопрос.
2. Дать ответ по найденному источнику.
3. Если нужны действия клиента - перечислить шаги.
4. Указать ограничение или условие.
5. Предложить передачу оператору, если вопрос не решен.

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

Шаг 10. Подключите feedback loop

Агент поддержки должен улучшать базу знаний. Каждый раз, когда он не нашел ответ, ошибся или передал вопрос оператору, это сигнал для редактора.

• Не найден ответ: нужна новая статья или обновление существующей.
• Найдена не та статья: проблема retrieval или metadata.
• Оператор исправил ответ: добавить пример в eval dataset.
• Клиент поставил плохую оценку: разобрать диалог.
• Частая эскалация по теме: тема пока не готова к автоматизации.

Без feedback loop агент быстро упирается в качество старых документов.

Шаг 11. Проверьте качество перед запуском

Соберите тестовый набор из реальных обращений. Для поддержки важно проверять не только точность, но и тон, источники, handoff и отсутствие опасных обещаний.

• Агент правильно отвечает на частые вопросы.
• Источник действительно подтверждает ответ.
• Агент просит недостающие данные, а не угадывает.
• Агент передает человеку конфликтные и рискованные кейсы.
• Агент не раскрывает внутренние инструкции.
• Агент не сохраняет лишние персональные данные.
• Оператор получает понятное summary.

Шаг 12. Запустите мягко

Не включайте агента сразу на 100% обращений. Начните с узкого набора тем, одного канала и ограниченного времени наблюдения.

• Неделя 1: agent assist для операторов.
• Неделя 2: автоответы только по 5-10 безопасным темам.
• Неделя 3: расширение тем после проверки CSAT и ошибок.
• Постоянно: разбор неудачных ответов и обновление базы знаний.

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

Мини-чеклист запуска

• Есть список тем, которые агент может закрывать сам.
• Есть список тем, где обязателен оператор.
• База знаний актуальна и индексируется через RAG.
• Ответы содержат источники или внутренние ссылки.
• Тикеты создаются только по правилам.
• Summary для оператора понятно и нейтрально.
• SLA и priority ограничены допустимыми значениями.
• Есть feedback loop в редактуру базы знаний.
• Есть eval dataset из реальных обращений.
• Запуск начинается с agent assist или ограниченного набора тем.

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

С чего начать ИИ-агента поддержки?

Начните с agent assist: агент готовит черновики ответов и summary для оператора. Это быстрее дает пользу, не ломает клиентский опыт и помогает собрать данные для безопасной автоматизации.

Можно ли полностью заменить операторов поддержки?

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

Что важнее: модель или база знаний?

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

Как понять, что вопрос надо передать человеку?

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

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

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