Настройте карту эскалации для ИИ-агента: агент, человек или стоп

Зачем определить маршрут до первого обращения

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

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

NIST описывает AI Risk Management Framework как добровольную рамку управления рисками для людей, организаций и общества при проектировании, использовании и оценке ИИ-систем. Среди принципов ответственного применения ИИ Google отдельно называет человеческий надзор, должную осмотрительность и механизмы обратной связи. Эти источники не дают универсального списка запретов для каждого бизнеса, но поддерживают сам подход: границы и контроль определяют до того, как система начинает действовать.

Три маршрута на одной странице

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

Маршрут «человек» нужен не потому, что агент «не справился». Это штатная часть процесса: исключение передаётся тому, кто вправе оценить обстоятельства и последствия.

«Стоп» — тоже полезный результат. Он не позволяет заменить отсутствие данных уверенным предположением и не маскирует отсутствие полномочий вежливым, но вводящим в заблуждение ответом.

Сигналы, которые переводят обращение человеку

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

К основным сигналам относятся:

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

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

Как собрать карту за пять ручных шагов

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

1. Перечислите типы обращений. Возьмите реальные категории входящих запросов: справка, статус, изменение данных, претензия, запрос исключения.
2. Отметьте красные флаги. Для каждой категории зафиксируйте, что переводит диалог человеку или в стоп.
3. Назначьте получателя. Укажите не абстрактный «менеджер», а роль или очередь, ответственную за решение.
4. Опишите пакет передачи. Человек должен увидеть контекст, исходный запрос, уже сделанное действие и вопрос, который нужно решить.
5. Протестируйте на примерах. Проведите учебные обращения через карту и уточните двусмысленные формулировки.

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

Учебный пример: запрос на изменение контакта

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

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

В CRM важна не ссылка сама по себе, а задача с карточкой контакта. Если команда действительно ведёт такие обращения в системе, рабочее место с контактами CRM Smokva может быть частью ручного процесса ответственного сотрудника. Эта статья не утверждает, что изменение контакта выполняется автоматически: способ передачи, права и доступность действий нужно проверять в конкретном сценарии.

Шаблон правила для каждой категории

Заполните этот шаблон для повторяющегося типа обращения. Он помогает превратить общую установку «будьте осторожны» в проверяемое правило.

Категория обращения: [название]

>

Агент действует сам, если: [утверждённые условия и обратимое действие].

>

Передать человеку, если: [исключение, неопределённость, жалоба, данные или последствия].

>

Остановить действие, если: [нет полномочий, проверки, фактов или безопасного маршрута].

>

Получатель эскалации: [роль, очередь или ответственный].

>

В передаче обязательно указать: [контекст, исходный запрос, действие агента, причину, вопрос].

>

Владелец правила и дата пересмотра: [заполняет организация].

Формулируйте условия наблюдаемыми признаками. Вместо «сложные вопросы — менеджеру» лучше написать: «запрос на исключение из утверждённых условий — ответственному за условия». Так проверка перестаёт зависеть от личного ощущения агента или сотрудника.

Чек-лист передачи человеку

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

1. Контекст: кто обратился и о каком процессе речь.
2. Исходное обращение без изменения смысла.
3. Что уже сделал или не сделал агент.
4. Конкретная причина эскалации.
5. Решение, которое требуется от человека.

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

Как проверить карту до запуска

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

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

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

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

Нужно ли передавать человеку каждое обращение с персональными данными?

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

Можно ли дать агенту право на исключения в типовых правилах?

Только если организация явно установила границы такого решения, последствия и ответственного владельца. В противном случае исключение — сигнал для человека, а не повод для догадки.

Чем «стоп» отличается от передачи человеку?

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

Встраивайте карту в рабочие правила

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

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