Guest request automation across hotel shifts

The problem and current manual process

An early arrival request comes through a booking channel. A dietary request is emailed separately. At shift change, staff have a booking reference but no record of what was promised.

Who should use this approach?

Hospitality teams passing requests between reservations, reception and operations, with supported access to booking records and a staffed duty-manager route.

When it is not a good fit

A small operation may only need a shared request board. Avoid autonomous replies where room availability is stale, reservation identity cannot be verified or there is no responsible person to handle exceptions.

Proposed workflow

Systems involved: Property management system, booking channels, shared inbox, staff task board.

1. Match channel messages to the reservation and capture each request in a shared service record.
2. Assign tasks by department and arrival time, checking room or service availability before preparing a response.
3. Track acknowledgement, escalate overdue tasks to the duty manager and include open commitments in the shift handover.

Synthetic example: an early-arrival enquiry comes through a booking channel while a dietary request arrives by email. Both attach to the verified reservation as separate tasks, with separate owners. The next shift sees what was requested, what was confirmed and what still awaits a decision.

Where AI is useful

AI can propose a request summary and department from Thai, English or mixed-language messages. A competent reviewer checks ambiguity, dates and commitments. Translation must not turn a preference such as early arrival into a confirmed early check-in.

Where deterministic rules are better

Use verified reservation identifiers, explicit due times and department assignment rules. Query availability in the source system before a person confirms a change. A generated response must not invent an upgrade, refund, allergen guarantee or availability promise.

States and human approval

1. Received: preserve source channel and message reference.
2. Matched: verify the reservation and authorised requester.
3. Assigned: split requests by department, owner and due time.
4. Pending decision: hold promises that require availability or staff judgement.
5. Acknowledged: record exactly what was communicated.
6. Handed over: include unresolved commitments in the next shift’s queue.

Staff approve upgrades, refunds and commitments that depend on availability. Sensitive guest requests are shared only with the responsible team.

Failure modes and recovery

Similar guest names

Request clarification or staff matching; never use a name alone to expose a reservation.

Late message after checkout

Check current reservation state before assigning a pre-arrival task.

PMS unavailable

Keep the request pending and avoid a new availability commitment.

Shift owner absent

Escalate to the duty manager using an agreed deadline and alternate channel.

Security and privacy boundaries

Guest preferences can include sensitive information. Give each department only what it needs to fulfil its task. Separate original messages from broadly visible handover summaries and agree access, retention and model-processing boundaries before using live guest data.

What a pilot should prove

• Unverified guests receive no reservation information.
• Requests have distinct owners even when linked to one reservation.
• A shift handover preserves open commitments and due times.
• AI summaries cannot independently confirm upgrades or special arrangements.
• A source-system outage leaves an actionable pending queue.

Intended operational effect

Each shift can see what the guest needs, what was promised and what still needs doing.

Measure a representative baseline, then compare the same scope during the pilot. Include review, exception handling and maintenance effort. Proposed measures: requests unresolved at arrival; time to acknowledge guest requests; missed commitments per stay.