An enquiry contains several different jobs
A fictional guest writes: “Landing in Bangkok around 01:00 on 8 November. Two adults, one child. Can we have a twin room for two nights and check in when we arrive? The website says breakfast included.” A fast answer might offer 8 to 10 November with immediate check-in. That answer could leave the family in the lobby before the booked night starts.
Before proposing anything, resolve what stay the guest means. Record arrival as a timestamp, the requested check-in arrangement, check-out date, occupancy and bed preference. The operational question is whether arrival early on 8 November requires a reservation starting 7 November under this hotel's policy. AI should surface the question; it must not decide the hotel's overnight-arrival rules.
A booking draft has value even when it cannot confirm anything. It gives the reservations colleague a clean request, identifies the questions that change the offer and prevents the guest from explaining the same details twice. This guide uses a fictional hotel and illustrative conditions, not an actual room offer or a DLVX client result.
Build a reservation evidence card
Use a row for each fact with its source and checked time. The arrival message establishes what the guest expects. The property-management system or approved reservation system establishes inventory and reservation state. A current rate record establishes the room price, occupancy terms, meal inclusion and cancellation conditions. A generic website screenshot does not establish that a particular rate includes breakfast on the guest's dates.
For the example, the reservations colleague confirms that the proposed stay must start 7 November for the requested arrival arrangement. The guest confirms check-out on 10 November. That creates a three-night proposal, not the two-night request originally written. The discrepancy belongs near the price, where the guest will see it. Never silently “correct” the dates and send a more expensive total.
Child age is missing. Ask for the age needed to apply the hotel's occupancy rules rather than requesting unrelated identity details. A twin preference, guaranteed twin allocation and room category availability are different facts. If the property can only record a preference, say so. Early arrival, airport transfer, adjoining rooms and late checkout each need their own evidence.
A useful draft before the room exists
At 14:10 Bangkok time, imagine the reservation system shows one eligible room for the proposed dates. The draft should say that the team has an option to offer, subject to its normal reservation process. It shouldn't say “your room is secured” unless a valid hold or reservation actually exists. A competing booking can consume that room while someone reviews the draft.
Illustrative customer draft: “To accommodate arrival around 01:00 on 8 November, the proposed reservation starts on 7 November and ends on 10 November, covering three nights. Please confirm that these dates match your plan and tell us your child's age so reservations can check the occupancy terms. Twin beds remain a request until the hotel confirms allocation.” Include actual price and meal terms only after retrieving the correct rate.
The reservation card should also explain which condition prevents confirmation. “Awaiting guest date confirmation” is actionable. “Pending” isn't. When the guest replies “yes,” compare it with the exact proposal they received. If the price or cancellation terms changed in the meantime, that yes doesn't accept the revised offer.
Use a worksheet with an explicit stop
RESERVATION DRAFT, NOT A CONFIRMATION Guest request reference: Arrival timestamp and timezone: Proposed check-in date: Proposed check-out date: Nights, calculated from dates: Adults / children / required age details: Room category / bed request / allocation status: Rate identifier / currency / inclusions / exclusions: Cancellation and payment conditions, source version: Inventory source and check time: Hold or reservation reference, if one actually exists: Guest acceptance: exact offer version and message: STOP IF Dates conflict, occupancy is unresolved, inventory read fails, rate terms conflict, or the reservation write is unverified. OUTPUT Internal missing-question list. Customer draft with only the current supported state. Evidence needed before using the word confirmed.
Let the existing booking system calculate totals and enforce inventory rules. AI can explain an approved quote, but arithmetic generated inside prose is a poor place to apply nightly rates, changing inclusions or supplements. The model should receive a calculated breakdown with clearly named units. If the breakdown and total disagree, return the discrepancy to reservations.
A timeout is not an available room
Suppose the reservation action times out after the guest accepts. The team now faces uncertainty about whether the system created the booking. Sending the action again without checking can create a duplicate. Sending a confirmation without checking can create a promise with no reservation behind it.
The correct recovery depends on the actual booking system. Look up the intended reservation using the system's supported reference or duplicate-prevention method, then inspect the resulting record. Match guest, dates, occupancy, room category and offer version. If the result remains uncertain, a staff member owns reconciliation and the guest receives an honest status update. Never make the customer troubleshoot an internal integration failure.
A confirmed booking email is generated from the verified reservation record. Payment success by itself doesn't prove that record exists, and a reservation record doesn't necessarily mean payment has settled. Keep both states visible when the property's process requires both. These are design recommendations; confirm implementation details with the reservation platform you actually use.
What to test with the front desk
Run the arrival example with a changed check-out date, a child age that changes occupancy, an expired offer and inventory disappearing during review. Include a screenshot of an old room promotion and a guest who says “same as last time.” The reviewer should need no guesswork to find which information controls the offer.
Keep the first pilot inside one room category and a small set of approved rate plans. Stop expansion if staff spend more time reconciling offers than they used to spend writing replies. Measure accepted drafts, missing-question rounds, conflicting reservations and minutes of rescue work. Faster acknowledgment is secondary to the guest reaching the desk with the room and terms they expected.
The DLVX workflow guide, checked 20 October 2026, explains how to measure completed work. For reservations, that completed unit is a verified booking with understood conditions. A beautiful answer in a chat window is only an intermediate document.
Sources and dates
Sources checked on 20 October 2026. Worked examples are teaching examples unless explicitly attributed. Provider documentation describes product behaviour; the operating recommendations are DLVX editorial judgement.
- DLVX Bangkok workflow guideEditorial framework for accepted outcomes and verified workflow results; hotel examples are original and fictional. Checked 2026-10-20.