AI-агент записи: как проверять свободные слоты перед подтверждением

Учебный пример: в 10:00 агент предложил клиенту визит на 18:00, а в 10:20 получил ответ «да, подходит». Между сообщениями администратор мог принять звонок и занять этот интервал. Если агент просто повторит собственное предложение как подтверждённую запись, уверенный ответ скроет отсутствие реальной брони.

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

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

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

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

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

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

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

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

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

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

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

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

Даже идентификатор созданного заказа не всегда означает окончательное подтверждение. Заказ может ожидать предусмотренного согласования или оплаты. Сопоставляйте ответ клиенту с фактическим бизнес-статусом, а не только с наличием объекта в базе.

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

На демонстрации AI-агента MySlot попросите пройти эти сценарии в тестовой среде. Уточните источник свободного времени, наличие удержаний, проверку операции и передачу сотруднику. Конкретные механизмы должны быть подтверждены выбранной конфигурацией, а не выведены из общего названия «AI-агент записи».