AI Guest Inquiry-to-Booking Playbook

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 transitionSource to checkAllowed resultStop 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

RoleOwnsApprovesReceives handoff
Reservations ownerAvailability, rate plan, booking stateReservation confirmationBooking exception
Revenue/commercial ownerRate and offer authorityDiscount or packageCommercial exception
Front desk/guest serviceArrival and in-stay truthService recoveryUrgent guest issue
Finance/security ownerPayment channel and identity controlsPayment exceptionFraud signal
Hospitality workflow ownerPilot scope and expansionKeep/pause/expandCross-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.

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.

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 transitionSource to checkAllowed resultStop or human handoff
Family-room inquiry to confirmed arrangementCurrent room/rate record, then reservation writeSend verified rates; confirm only after booking reference existsUnverified 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.

TriggerSeverityOwner
Availability/rate conflictHighReservations
Identity/payment anomalyCriticalFinance/security
Active in-stay issueHighGuest service
TriggerRequired contextResponse targetFallback
Availability/rate conflictDates, party, room/rate version, channelBefore quote/confirmationWithdraw and verify
Identity/payment anomalyProperty channel, instruction, reservation IDBefore paymentBlock and use verified contact
Active in-stay issueRoom/reservation, issue, urgency, languageImmediate queueHuman-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.

MetricDefinitionBaseline
Valid-action rateActions supported by current guest, room, rate, permission, and service state / attempted actionsPre-pilot replay
Reconciliation rateDue transitions whose guest-facing and reservation outcomes match / due transitionsPilot
High-severity conflict rateIdentity, payment, booking, or service conflicts / attempted actionsPre-pilot audit
MetricDecision thresholdOwnerCadence
Valid-action rateSet before launchReservationsWeekly
Reconciliation rateSet before expansionWorkflow ownerWeekly
High-severity conflict ratePause threshold pre-setFinance/guest serviceWeekly
FailureEarly signalCorrective action
Phantom room, stale rate, or hidden feeQuote version differs from the reservation source or required fee field is missingWithdraw the quote, suppress confirmation, and have the reservations owner reconcile the source
Duplicate or partial reservationReused idempotency key, missing booking ID, or customer/system states differStop messages, restore the last verified state, and let the reservations owner resolve the record
Payment, service, or handoff escapePayment channel changes, an active complaint exists, or no owner acceptsBlock 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.

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.

FAQ

Recommended for you