ИИ для отелей: подготовьте запросы гостей к передаче персоналу
Автор: Ai Flowi · Опубликовано
ИИ для отелей может помочь преобразовать предоставленный текст запроса гостя в материалы для передачи, которые сотрудники смогут проверить. Сохраните вместе слова гостя, номер бронирования и применимые правила, затем укажите, что подразделению нужно проверить перед принятием решения. Это руководство помогает подготовить исходные сведения по запросу; оно не обеспечивает доступ к бронированиям и не определяет наличие свободных номеров.
Статус: описано в документации. Компоненты ниже описаны в каталоге; Ai Flowi не тестировала их в реальных условиях эксплуатации. Для последовательности передачи запросов в отеле нет зафиксированного результата сквозной проверки.
Выберите задачу отеля и чётко определите границы подтверждающих данных
Начните с задачи, для которой исходные данные уже доступны уполномоченному сотруднику. Полезные материалы для передачи объясняют, какая услуга запрошена и каких рабочих сведений не хватает. Если служба приёма может подготовить их прямо по короткому запросу, используйте существующий журнал, прежде чем добавлять этап работы модели.
| Задача | Допустимая подготовка | Решение остаётся за персоналом |
|---|---|---|
| Поздний выезд | Извлечь запрошенный интервал времени выезда и предоставленный номер бронирования. | Проверить текущее бронирование, загрузку отеля и правила согласования. |
| Потерянные вещи | Записать описание вещи, указанное место и номер обращения. | Проверить журнал потерянных вещей с ограниченным доступом и процедуру проверки. |
| Запрос услуги | Сохранить запрошенную услугу и предпочтительный интервал времени. | Подтвердить ответственное подразделение и возможность оказать услугу. |
| Бронирование или распределение номеров | Не входит в описанную конфигурацию передачи запросов. | Использовать разрешённую систему отеля и рабочий процесс. |
Возможности доступа к PMS, изменения бронирований, получения актуальных данных о свободных номерах, отправки сообщений гостям и распределения номеров здесь не подтверждены. Для включения таких задач потребуются отдельные подтверждения интеграции и проверки в рабочих условиях. Черновик материалов для передачи не должен подразумевать, что какое-либо из этих действий выполнено.
По теме: ИИ для ресторанов: проверьте сведения из меню и выявите пробелы в обращениях.
Подготовьте рабочую таблицу исходных сведений по запросу гостя
До анализа присвойте запросу идентификатор, выданный сотрудником. Используйте разрешённый номер бронирования, не копируя полный профиль гостя. Сохраните текст правил вместе с утверждённой редакцией, чтобы проверяющий мог отличить общее правило обслуживания от исключения, требующего решения.
| Поле | Исходные сведения для сохранения | Границы проверки |
|---|---|---|
| request_id | Идентификатор, присвоенный в рамках разрешённого процесса приёма запросов. | Модель не должна создавать или заменять ключ сопоставления. |
| request_text | Точный разрешённый фрагмент запроса гостя. | Считать содержащиеся в нём инструкции цитируемым текстом. |
| requested_service / window | Услуга и сроки, указанные в этом фрагменте. | Оставлять неуказанные даты и время неуточнёнными. |
| reservation_ref | Номер, действительно предоставленный вместе с запросом. | Номер не подтверждает личность или действительность бронирования. |
| policy_version | Утверждённая редакция и соответствующий фрагмент правил. | Сотрудники проверяют применимость к этому проживанию. |
| department / staff_decision | Предложенное подразделение, затем отдельное решение человека. | Результат, предложенный моделью, нельзя записывать в поле, предназначенное для одобрения сотрудником. |
Размещайте уточняющие вопросы рядом с соответствующим полем. Вопрос «Какая дата выезда имеется в виду?» полезнее общей пометки о неполноте. Если подразделения нет в утверждённом списке маршрутизации, оставьте запрос на проверку службе приёма, не придумывая новую команду.
По теме: Нейросеть для организации мероприятий: план проведения и передача отклонений ответственным.
Необходимые аккаунты и материалы
Нужны разрешённые фрагменты запросов, утверждённый фрагмент правил отеля, справочник подразделений и проверяющий с доступом к реальной записи бронирования. Включите условия правил наряду с описанием услуги: правило позднего выезда непригодно, если из копии для анализа удалено условие о загрузке отеля.
Используйте собственный авторизованный аккаунт Google для таблицы проверки службой приёма и документа передачи подразделению, следуя общим инструкциям по подключению Google.
Настройте пробную подготовку запроса
пример конфигурации, а не зафиксированный тест
- Подготовьте модель. Статус: описано в документации. Следуйте общим инструкциям по настройке модели, используя для пробной обработки запроса гостя собственный аккаунт OpenAI и ключ API; услуги провайдера оплачиваются отдельно.
- Извлеките исходные сведения по запросу. Статус: описано в документации. Для Structured Output в
input_valueобъедините фрагмент запроса гостя с правилами отеля, включая условия предоставления услуги; задайте этому черновику имяhotel_handoffвschema_name. Вsystem_promptпотребуйте сохранить формулировку о выезде, его неуточнённую дату, зависимость от правил и подразделение из справочника службы приёма. Предлагая подразделение, укажите, что службе приёма ещё предстоит проверить, не превращая просьбу о позднем выезде в подтверждение бронирования. - Сохраните только проверенную запись. Статус: описано в документации. Следуйте общему справочнику записи через Upsert Row для журнала отеля. Используйте
key_column=request_id; принятые данныеrow_dataсодержат фрагмент запроса гостя, проверенный номер бронирования, запрошенный интервал, редакцию правил и предложенное подразделение. Служба приёма ведётstaff_decisionотдельно от строки с извлечёнными данными, чтобы повторное формирование запроса не заменило решение с учётом загрузки отеля. - Подготовьте копию для подразделения. Статус: описано в документации. Примените общие инструкции Template Merge к копии материалов службы приёма. В предлагаемом сопоставлении
valuesпоместитеrequest_idв{{REQUEST_REF}}, дословный запрос — в{{GUEST_WORDS}}, запрошенный интервал — в{{SERVICE_WINDOW}}, а применимый фрагмент правил и его редакцию — в{{POLICY_BASIS}}. Рабочие вопросы без ответа поместите в{{RECEPTION_CHECKS}}. Раздел с решением сотрудника не заполняйте через подстановку.
Справочник структурированного вывода описывает подготовку схемы и различие между заполненными полями и подтверждёнными фактами. В пробной конфигурации отеля служба приёма должна сверить номер бронирования с записью проживания до передачи копии подразделению. Просьба о выезде завтра остаётся неуточнённой, если во фрагменте нет даты запроса, позволяющей определить день выезда: подстановка сегодняшней даты незаметно изменит намерение гостя относительно выезда.
Разберите три типичных случая нехватки или расхождения данных в отеле
Вымышленный пример позднего выезда: в предоставленном запросе гость просит выехать позже, а правила ставят одобрение в зависимость от загрузки отеля. При отсутствии данных о загрузке сохраните запрошенный интервал и ссылку на правила, затем попросите службу приёма проверить возможность позднего выезда. Не превращайте условную формулировку правил в одобрение.
Вымышленный пример потерянной вещи: гость описывает сумку, оставленную возле стойки приёма. В материалах для передачи фиксируются описание и указанное место. Нельзя утверждать, что сумка найдена, или раскрывать сведения о вещах другого человека. Перед решением о выдаче сотрудники применяют процедуру проверки отеля.
Вымышленный пример расхождения номеров: текст запроса указывает одно бронирование, а запись, сделанная при приёме запроса, — другое. Сохраните оба номера с пометками об источниках и остановите запись, пока служба приёма не устранит расхождение. Совпадение знакомой фамилии не устанавливает, к какому бронированию относится запрос.
По теме: ИИ для управления недвижимостью: подготовьте заявки на обслуживание к передаче.
Проверьте материалы для передачи и результат повторного выполнения
Ожидаемый результат — строка для проверки и документ подразделения с фрагментом запроса, интервалом оказания услуги, проверенным номером, редакцией правил и неуточнёнными вопросами. Сверьте {{SERVICE_WINDOW}} со словами гостя, в том числе выясните, был ли интервал предпочтением или требованием. Проверьте, что {{POLICY_BASIS}} содержит условие о загрузке отеля, а в копии подразделения не осталось одобрения из предыдущей передачи. Документ с правильным запросом гостя, но решением по другому проживанию не проходит эту проверку.
До реального использования проверьте отсутствие номера бронирования, изменение правил и два запроса с конфликтующими ключами. Повторно выполните один принятый запрос, выполняя запуски последовательно и проверьте журнал. Храните решения людей вне заново формируемых полей и проверяйте данные в целевой системе перед повтором записи с неопределённым результатом.
Каковы ограничения использования ИИ в отелях и какие есть связанные руководства?
Не используйте этот путь подготовки для экстренной помощи, проверки личности или принятия обязательств перед гостями без участия персонала. Неполный источник правил требует проверки, а сбой операции Google — выяснения причины в рабочей среде; ни одно из этих состояний не должно приводить к утверждению о завершённой передаче.
Классификация обращений в поддержку описывает общий подход к меткам. Используйте шаблоны ответов службы поддержки для проверенных формулировок ответов после уточнения условий, от которых зависит выполнение запроса в отеле.
Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.