Когда автоматизировать, а когда передавать человеку: проектирование SLA

Любой поставщик автоматизации скажет вам, что его AI-агент способен «обрабатывать 80% обращений». Почти никто из них не скажет, какие именно 80%, и что происходит с клиентом, попавшим в оставшиеся 20% и застрявшим в цикле общения с ботом, пока его окно возврата закрывается. Об этом никто не хочет писать, потому что их бизнес-модель зависит от того, поверите ли вы, что автоматизация — ответ на всё.

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

Ложная дилемма

Большинство команд формулируют это как выбор «либо-либо»: какие процессы автоматизировать, а какие оставить ручными. Такая постановка вопроса приводит к плохим результатам в обоих направлениях. Переборщите с автоматизацией — и клиенты застревают, споря с ботом из-за гарантийной претензии на $400, пока показатель CSAT незаметно снижается. Недоавтоматизируете — и ваша команда вручную разбирает сброс паролей и вопросы о статусе заказа, которые рабочий процесс мог бы решить за секунды, тратя штат на работу, не требующую суждения.

Более правильный вопрос — не «следует ли автоматизировать этот процесс», а «при каких условиях данному конкретному взаимодействию требуется человек, и как быстро этот человек должен отреагировать после того, как случай помечен?» Это вопрос SLA, а не стратегии автоматизации, и отвечать на него нужно на уровне отдельных триггеров, а не целых рабочих процессов.

Три переменные, которые должны определять границу

1. Обратимость

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

2. Уверенность

Каждая классификация, которую делает агент — намерение, тональность, срочность — сопровождается показателем уверенности, даже если ваша панель мониторинга его не отображает. SLA не должен относиться ко всем автоматическим решениям одинаково. Обращение, классифицированное как «задержка доставки» с уверенностью 95% и известным путём решения, может быть закрыто автоматически. То же намерение, классифицированное с уверенностью 60% или сопровождаемое негативной тональностью, обнаруженной в поле свободного текста, должно направляться человеку — не постфактум, а до того, как сработает автоматическое действие.

3. Ставки

Стоимость заказа, уровень контракта и пожизненная ценность клиента — всё это должно учитываться в логике маршрутизации. Возврат на $30 от клиента, впервые совершившего покупку, и заказ на $3000 от корпоративного аккаунта с продлением через 60 дней — это не одно и то же решение, даже если заявленная причина («неправильный размер», «пришло повреждённым») идентична. Возможность объединения данных о транзакциях с взаимодействием в реальном времени — а не поиск вручную — делает маршрутизацию по ставкам возможной в масштабе.

Разобранный пример: сортировка заявок на возврат (RMA) с многоуровневыми SLA

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

Вот как можно распределить по уровням границу «автоматизация/передача человеку» для этого рабочего процесса:

• Уровень 1 — полностью автоматизировано, SLA не требуется: причина возврата — определённый код дефекта, стоимость товара ниже $75, у клиента нет открытых споров, а тональность поля свободного текста нейтральная или положительная. Агент одобряет возврат, генерирует транспортную этикетку и закрывает цикл — человек не вовлекается.
• Уровень 2 — автоматизировано со страховочной сетью быстрого реагирования: стоимость товара составляет $75–400, либо причина возврата указана как «другое» и требует суждения, но тональность нейтральна. Агент составляет решение и публикует его в потоке Conversation, связанном с записью RMA, с SLA в 4 рабочих часа для одобрения или отмены человеком до исполнения. Если никто не отвечает вовремя, черновик одобряется автоматически — человек выступает проверкой, а не узким местом.
• Уровень 3 — немедленная передача, без автоматического исполнения: стоимость товара превышает $400, клиент помечен как риск повторных возвратов, либо анализ тональности в описании свободного текста выявляет раздражение или угрозу оставить публичный отрицательный отзыв. Агент прекращает попытки решить вопрос и создаёт поток Conversation с SLA в 1 час, отмечая назначенного представителя и предоставляя вместе с сообщением полную историю транзакций и поведения клиента.

Триггерные данные для этой маршрутизации получаются путём объединения трёх типов сигналов по ID клиента: транзакционной записи (стоимость заказа, история возвратов), голосового сигнала (анализ тональности и извлечение сущностей из поля свободного текста RMA) и поведенческого контекста (просматривал ли этот клиент неоднократно страницу политики возврата за дни до подачи заявки — событие Clickstream Publisher, указывающее скорее на предумышленность, чем на подлинный дефект). Ни один из этих сигналов сам по себе не подскажет, какой уровень применить; вместе они это делают.

Как написать SLA так, чтобы он был исполнимым, а не желаемым

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

• Таймер, который запускается автоматически. В момент, когда условие рабочего процесса направляет взаимодействие человеку, отсчёт должен начинаться по отношению к потоку сообщений, а не к общему почтовому ящику, где обращение может лежать непрочитанным.
• Путь эскалации. Если назначенный сотрудник не отвечает в пределах окна SLA, поток должен автоматически переназначаться или уведомлять руководителя — поток, открытый дольше положенного окна, сам по себе является сигналом, требующим действия.
• Запись произошедшего. Когда агент передал обращение, почему, кто его принял, сколько времени это заняло, какое решение было принято. Без этого невозможно понять, правильно ли откалибрована ваша уровневая система — действительно ли обращения уровня 2 малорисковые, или вы автоматически одобряете то, что должно эскалироваться.

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

Где агентам никогда не следует пытаться довести дело до конца

Несколько категорий заслуживают постоянного правила против полной автоматизации, независимо от показателей уверенности:

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

Чем помогает SurveyAnalytica

Конструктор no-code агентов SurveyAnalytica создан именно с учётом этой проблемы границы. Агенты могут вести многошаговые диалоги, выполнять действия и обращаться к базе знаний — но их также можно настроить на явную передачу обращения, направляя взаимодействие в поток Conversation с уже прикреплённым полным контекстом (связанный отклик, транзакционная запись, история клиента), вместо того чтобы просто сбросить представителю расшифровку разговора и заставить его самостоятельно восстанавливать картину произошедшего.

Движок Flows — это то, что делает многоуровневую маршрутизацию, подобную примеру с RMA, практичной, а не теоретической: события клика по потоку, данные транзакций и показатели тональности из полей свободного текста могут поступать в одну и ту же логику триггеров, поэтому решение «автоматизировать, быстро проверить или немедленно передать» принимается на основе объединённых сигналов в реальном времени, а не на основе единственного источника данных в изоляции. Состояния жизненного цикла потоков и метки истечения срока дают исполнимый таймер, необходимый для SLA, а потоки Audit обеспечивают защищённый от подделки след на случай, если кто-то спросит, как было принято решение.

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

Заключение

Команды, извлекающие наибольшую пользу из AI-агентов, — это не те, у кого самый высокий процент автоматизации, а те, кто честно определил, где автоматизация должна останавливаться. Это требует относиться к участию человека в цикле как к SLA, который нужно спроектировать, а не как к резервному варианту, за который нужно извиняться. Проводите границу, опираясь на обратимость, уверенность и ставки; обеспечивайте её исполнение с помощью таймеров и путей эскалации, а не общих почтовых ящиков; и ведите достаточно надёжную запись, способную обосновать решения, которые вы приняли не сами.