«Давайте наберём AI-ботов — и поддержка станет дешевле». Что может пойти не так

Простая операция, которая заняла пять часов

Заказчик по ошибке зарегистрировался не в том продукте одного провайдера. Аккаунт был пустым: без сайтов, доменов, почты и баз данных. Требовалось перенести доступный баланс из аккаунта виртуального хостинга в новый Cloud-аккаунт, чтобы купить сервер.

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

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

1. Пользователь описывает задачу

   Указывает источник, получателя и желаемый результат.

2. Агент снова уточняет контекст

   Часть уже известных данных приходится повторять.

3. Диалог передают коллеге

   Новый участник заново восстанавливает смысл переписки.

4. Цикл начинается сначала

   Ответ появляется быстро, но операция не приближается к завершению.

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

Что должен хранить backend

Уже после нескольких реплик система могла сформировать структурированное состояние обращения. Реальные реквизиты здесь намеренно обезличены.

{
  "intent": "transfer_full_balance",
  "source": {
    "account_id": "hosting_account_redacted",
    "product": "virtual_hosting",
    "owner_verified": true
  },
  "destination": {
    "account_id": "cloud_account_pending",
    "product": "cloud",
    "owner_verified": false
  },
  "assets": {
    "balance": "all_available",
    "sites": 0,
    "domains": 0,
    "mailboxes": 0,
    "databases": 0
  },
  "status": "identity_verification_required",
  "next_action": "verify_owner",
  "completion": [
    "balance_visible_in_cloud",
    "customer_can_sign_in",
    "server_purchase_available"
  ]
}

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

Точный факт, привязанный не к той сущности

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

В одном обращении одновременно присутствовали аккаунт, из которого писали в поддержку, аккаунт заказчика, продукты Hosting и Cloud, а также email владельца. Если интерфейс или AI не хранит связь «факт → сущность → источник → время проверки», возникает опасная комбинация:

Правильный факт + неправильная сущность = неправильный ответ.

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

Техническое событие не равно пользовательскому результату

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

cloud_account_created = true

Но бизнес-результат выглядел иначе:

customer_can_access_cloud = true
balance_is_visible = true
server_purchase_is_available = true

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

Как встроить LLM в оркестратор поддержки

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

1. Извлечение данных

   После каждого сообщения модель возвращает intent, entities, facts и requested_action по заданной схеме.

2. Валидация и запись

   Backend проверяет типы, связывает факты с сущностями, фиксирует источник и сохраняет изменения.

3. Разрешение конфликтов

   Новое значение не молча переписывает подтверждённый факт. Система создаёт конфликт и запрашивает проверку.

4. Выбор workflow

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

5. Контракт handoff

   Получатель видит структурированный контекст, причину передачи и следующий шаг, а не только длинную переписку.

6. Проверка outcome

   Система закрывает задачу лишь после выполнения completion criteria или явного подтверждения клиента.

У обращения должен быть владелец

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