1. Test a booking that has changed, not only a perfect new reservation.
2. Missing optional greetings can use neutral wording. Uncertain amounts, addresses, or access instructions should stop sending.
3. Approve what the recipient actually receives, including each button's destination.
A template passes when its final message is right for the booking at the time it is sent. Correct spelling and a successful preview are not enough. Guest messaging software must fill changing details from the right stay, and its sending rule must still fit that stay.
Use the checks below to decide whether to send, correct and retest, or hold for staff review. They test meaning rather than just whether a field produces some text.
Write the Expected Message Before Checking the Preview
A variable is a placeholder replaced by booking information, such as a name or arrival date. Choose it through the software's supported field selector. Field names copied from another system may look convincing without working.
Take a hypothetical staff-controlled test reservation: Maya arrives on 24 November, the stay costs $240, and a $60 deposit has already been collected. The remaining room balance is $180, assuming no other charges. The physical room has not been assigned.
For a balance reminder, an acceptable result could be: "Hello Maya. Your arrival is 24 November. The remaining room balance is USD 180." It should not request USD 240 or reveal an unconfirmed room number.
Write those expected facts separately from the preview. Compare them with the booking and recorded hotel payments, not yesterday's message. Otherwise, staff may approve plausible output just because every placeholder disappeared.
Check who should receive it too. An assistant may have booked for Maya. A correct traveler name inside a message sent to the wrong person is still a failure.
Smart Order places reservation context beside guest conversations, allowing reception to compare the intended reply with the stay. Use that context to verify the date or payment question; the fact that a template is available to select does not prove it has passed a test.
Verify the Detail That Changes the Guest's Next Action
Check the reservation beside the conversation before asking a guest to pay, arrive, or follow a property-specific instruction.
Test the Bookings Most Likely to Break the Template
Keep using the Maya test stay, changing one condition at a time. Use approved test records and staff-controlled recipients, not real guests or live collection requests. These are test cases, not a prescribed click sequence.
The Arrival Changes After the Message Is Prepared
Move the test arrival from 24 to 26 November through the supported procedure. Check a new preview and any already prepared or queued message. The acceptable result is the revised date, or a hold requiring the old message to be replaced.
If only new previews update, the date field may be correct while the saved message retains an earlier value. Remove or replace that stale message through the supported controls. Record the limitation in the sending procedure.
Another Payment Arrives Before Sending
Suppose another $40 is collected through the approved payment test method. The expected room balance becomes $140, not $180. Check whether the reminder refreshes and whether the older payment request remains valid.
If a current balance cannot be established reliably, omit the amount and require a staff-verified request instead. Do not substitute the booking total. For an OTA-prepaid test stay, check that the message does not request a room charge the hotel should not collect.
Optional Information Is Missing
Remove an optional first name from a suitable test record. A neutral "Hello" can be acceptable if the editor supports it. A raw field label, blank greeting, or name guessed from an email address is not.
Essential details need a different response. Missing currency, property address, or required arrival information should hold the message for review. Friendly wording cannot repair an unsafe instruction.
The Booker, Property, or Room Is Different
Test an assistant booking for Maya and, if relevant, a reservation at another property. Check the recipient, greeting, address, contact route, and arrival instructions independently. One correct value does not validate the others.
For room-specific messages, compare the assignment with the front desk reservation view. Access messages need their own approved release checks. A confirmed booking alone must not release a room number or code.
The Channel or Language Changes
Use a safe test route on the intended delivery channel where available. Read the received message on a phone, checking links, line breaks, and translated wording. An email preview does not prove that an OTA conversation displays the same content.
Translation must preserve usable fields and must not turn a payment request into a payment confirmation. Open test links to confirm their purpose. Keep real access credentials and live payment links out of shared QA notes.
Decide: Send, Correct and Retest, or Hold
Approve only the cases essential to this template's purpose. A welcome note may need no balance test; a payment reminder does. Select tests from the consequences of a wrong message, not from a universal list of fields.
Use correct and retest when the cause is understood: an unsupported field, missing optional fallback, or outdated fixed text. Repeat the affected case and other cases that depend on the change. One normal reservation looking right is not enough.
Use hold for staff review when a safe current value or recipient cannot be established, or a queued message cannot be refreshed reliably. Manually typing one correct reply helps that guest; it does not repair the reusable template.
Keep an approval note with the purpose/version, tested conditions, expected versus received results, and approver. Reopen relevant tests after changes to payment rules, property details, languages, or sending timing. Do not retest irrelevant fields just to complete a form.
If Incorrect Messages Have Already Gone Out
Pause the affected template or queue. Identify recipients by version and sending period, then send one clear correction through an approved route. A wrong greeting needs a different response from another guest's room details or an incorrect collection request.
For payment or access errors, involve the responsible manager and determine whether the old request or credential must be withdrawn. Verify any collection before asking for money again. Handle another person's exposed information through the hotel's privacy procedure.
Restore automatic sending only after the failed condition passes again. The release decision depends on what the recipient receives, not merely whether the editor saves.
