Сбои AI-агента записи: как избежать дублей и передать запрос человеку

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

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

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

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

Для запроса, который ещё не отправлялся, подойдёт сообщение: «Не удалось проверить свободное время. Можем передать пожелание администратору; это пока не запись». Для потерянного ответа после отправки нужна другая формулировка: «Проверяем, создана ли запись. Пока не оформляйте её повторно». Эти сообщения нельзя подменять друг другом.

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

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

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

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

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

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

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

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

В сценарии MySlot обсудите связку AI-агента, календаря, CRM и уведомлений. Попросите показать потерю ответа после создания и передачу обращения при недоступной CRM. Работающий диалог в штатном режиме не доказывает наличие аварийной очереди, автоматической сверки или резервного канала: эти возможности подтверждают отдельно.