AI Guest Inquiry-to-Booking Playbook

When a guest asks whether a room is available, a fast answer is useful only if the room, rate, and payment route are still valid. This playbook moves one inquiry to a confirmed reservation or an accepted human handoff without turning a chat response into an unverified promise.

Start by copying the pilot card below into a document or spreadsheet and filling its first cell with one exact guest request. If the team cannot name the source or the person who receives an exception, stop there and repair the process first.

Copy the pilot card and define completion

Guest transition	Source to check	Allowed result	Stop or human handoff
When [guest request] occurs, move from [start] to [end]	[room/rate/reservation source and freshness]	[answer, hold, booking, or no action]	[conflict and named receiver]

• Start: one journey break has an owner, baseline, source map, and explicit guest permission.
• End: one bounded transition reaches a confirmed, cancelled, or accepted human state without conflicting with reservation or service records.
• Evidence: room/rate version, guest request, consent, action log, booking reference, handoff receipt, correction, and outcome.
• Time horizon: one representative booking-and-stay cycle, including sold-out, change, cancellation, and active-service cases.

Roles and prerequisites

Role	Owns	Approves	Receives handoff
Reservations owner	Availability, rate plan, booking state	Reservation confirmation	Booking exception
Revenue/commercial owner	Rate and offer authority	Discount or package	Commercial exception
Front desk/guest service	Arrival and in-stay truth	Service recovery	Urgent guest issue
Finance/security owner	Payment channel and identity controls	Payment exception	Fraud signal
Hospitality workflow owner	Pilot scope and expansion	Keep/pause/expand	Cross-team conflict

Before launch, name the source of truth for property, room type, occupancy, restrictions, taxes/fees, rate validity, reservation, payment instructions, guest preference, service case, and consent. Define timezone, expiry, duplicate protection, backup owners, and rollback.

Phase 1: map the guest and reservation state

• Owner: reservations owner with front desk.
• Inputs: booking sources, rate plans, inventory, service and message events.
• Actions: trace inquiry, quote, hold, confirmation, pre-arrival, check-in, in-stay issue, checkout, and permitted follow-up.
• Output: state map with source, freshness, owner, and conflict precedence.
• Exit gate: every selected answer or action has a current authoritative source.
• Escalation/rollback: stop automation where channel inventory, rate, or reservation identifiers cannot be reconciled.

Phase 2: choose one guest transition

• Owner: hospitality workflow owner.
• Inputs: journey evidence, baseline, reversibility, staffing coverage.
• Actions: compare FAQ, quote request, booking handoff, arrival preparation, service routing, and post-stay follow-up.
• Output: one transition, no-action rule, and acceptance criteria.
• Exit gate: the job is bounded, observable, permitted, and owned.
• Escalation/rollback: fix the reservation process first when staff cannot accept the handoff.

Zalo describes a booking-management utility for Official Accounts. This supports a booking workflow mechanism only; it does not establish hotel inventory, rate, or revenue performance. Review the source.

Phase 3: apply truth, safety, and service precedence

• Owner: reservations for room/rate; finance/security for payment; guest service for active issues.
• Inputs: current inventory, rate expiry, verified property channels, active reservations and cases.
• Actions: recheck facts before commitment; display uncertainty; suppress commercial follow-up during unresolved service or identity risk.
• Output: eligible context or named human route.
• Exit gate: the property, rate, availability, payment route, and guest state agree.
• Escalation/rollback: withdraw a stale quote, block payment instruction, and route the complete context.

A Vietnamese public warning describes accommodation impersonation and advises verification before booking or payment. It supports identity and payment controls, not a claim about incident frequency. Review the source.

Phase 4: execute, confirm, and reconcile

• Owner: reservations owner; front desk/guest service accepts exceptions.
• Inputs: eligible context, approved message/action, live reservation events.
• Actions: perform one idempotent action; issue a booking reference only after the system confirms it; reconcile changes before follow-up.
• Output: confirmed, cancelled, expired, or human-owned result.
• Exit gate: guest-facing and reservation states match.
• Escalation/rollback: suppress confirmation after a partial write and restore the last verified state.

Phase 5: review and expand by hospitality cell

• Owner: hospitality workflow owner.
• Inputs: valid-action, reconciliation, conflict, handoff, complaint, and opt-out records.
• Actions: compare with baseline by property, channel, language, journey stage, and shift; inspect every high-severity error.
• Output: signed keep/pause/expand decision.
• Exit gate: pre-set quality thresholds hold across representative exceptions.
• Escalation/rollback: disable only the affected property/channel/stage cell and investigate before re-entry.

Fictional completed run

A fictional 24-room guesthouse pilots family-room inquiry handling on its direct messaging channel. A guest requests adjoining rooms for a weekend. The assistant finds two room types but cannot verify adjacency, so it presents the current rates and sends the constraint, dates, party size, and reply deadline to reservations. Staff confirms one valid arrangement and creates the booking reference; the assistant then relays the verified confirmation. When a later request asks for a bank transfer to a newly supplied account, the payment rule blocks it and provides the property's verified channel. The pilot records one accepted handoff and one blocked payment exception; it makes no revenue claim.

Guest transition	Source to check	Allowed result	Stop or human handoff
Family-room inquiry to confirmed arrangement	Current room/rate record, then reservation write	Send verified rates; confirm only after booking reference exists	Unverified adjacency goes to reservations; changed payment details go to finance/security

Handoff, QA, and measurement

The Trigger column is the join key between the two compact tables.

Trigger	Severity	Owner
Availability/rate conflict	High	Reservations
Identity/payment anomaly	Critical	Finance/security
Active in-stay issue	High	Guest service

Trigger	Required context	Response target	Fallback
Availability/rate conflict	Dates, party, room/rate version, channel	Before quote/confirmation	Withdraw and verify
Identity/payment anomaly	Property channel, instruction, reservation ID	Before payment	Block and use verified contact
Active in-stay issue	Room/reservation, issue, urgency, language	Immediate queue	Human-first service

QA checks: source freshness; timezone and rate expiry; taxes/fees; occupancy and restrictions; verified property identity; payment wording; duplicate booking; service suppression; accepted handoff; rollback tested.

The Metric column is the join key between the two compact tables.

Metric	Definition	Baseline
Valid-action rate	Actions supported by current guest, room, rate, permission, and service state / attempted actions	Pre-pilot replay
Reconciliation rate	Due transitions whose guest-facing and reservation outcomes match / due transitions	Pilot
High-severity conflict rate	Identity, payment, booking, or service conflicts / attempted actions	Pre-pilot audit

Metric	Decision threshold	Owner	Cadence
Valid-action rate	Set before launch	Reservations	Weekly
Reconciliation rate	Set before expansion	Workflow owner	Weekly
High-severity conflict rate	Pause threshold pre-set	Finance/guest service	Weekly

Failure	Early signal	Corrective action
Phantom room, stale rate, or hidden fee	Quote version differs from the reservation source or required fee field is missing	Withdraw the quote, suppress confirmation, and have the reservations owner reconcile the source
Duplicate or partial reservation	Reused idempotency key, missing booking ID, or customer/system states differ	Stop messages, restore the last verified state, and let the reservations owner resolve the record
Payment, service, or handoff escape	Payment channel changes, an active complaint exists, or no owner accepts	Block the action and route the complete context to finance/security or front desk/guest service

Pause the affected hospitality cell until the corrective action is verified.

Frequently asked questions

Should an assistant confirm a room from a cached availability result?

No. Revalidate against the current reservation source and issue confirmation only after the write succeeds.

Can it negotiate a rate or promise an upgrade?

Only within documented authority and current eligibility. Otherwise route the request to the commercial or reservations owner.

When should follow-up stop?

On opt-out, cancellation, identity/payment risk, an unresolved service case, or any state that invalidates the planned message.

How should multilingual handoff work?

Pass the original guest wording, detected language, verified facts, unresolved question, urgency, and the exact action already taken.

What to do after completion

Limits. This is an operating method. It claims no hospitality benchmark, booking lift, occupancy gain, integration, payment protection, or Easy AI capability.

Use the revenue opportunity guide to prioritize the next break, the appointment reminder template for a verified time-bound event, and the AI-to-human handoff guide to standardize exception ownership.