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

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

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

Ввод «05/06» тоже не следует трактовать по языку интерфейса с полной уверенностью. При вероятной неоднозначности проще спросить месяц словами. Задача агента не в том, чтобы демонстрировать уверенность при любом вводе, а в том, чтобы с минимальным числом уточнений получить дату, которую обе стороны понимают одинаково.

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

Учебный пример: клиент написал 30 сентября поздно вечером «хочу завтра», а обработчик вернулся к сообщению уже 1 октября. Если основанием остаётся исходное сообщение в согласованной зоне, предложение относится к 1 октября, а не ко 2 октября. При сомнении в давности или часовом поясе агент уточняет конкретную дату.

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

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

Задавайте вопрос только о параметре, который мешает следующему действию. Если услуга и филиал уже выбраны, не спрашивайте их повторно вместе с датой. Вместо общего «уточните время» предложите понятный выбор: «Вы имеете в виду 2 или 9 октября?» Это короче и уменьшает риск ещё одного неоднозначного ответа.

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

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

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

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

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

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