Message guests from the booking

Choose the correct booking as conversation context

Open Guests → Messages or the guest detail messages. Search by booking number, guest, dates or room and verify the context panel before writing.

Only bookings linked to a main guest can be messaged. Fix a missing link in the guest or booking record rather than creating another person.

Start every conversation from the exact booking. Search by booking number, guest or stay dates, open the record and compare recipient, arrival, departure, room category, current state and booking source. The same guest may have several past or future stays, and a profile alone does not identify which arrival, cancellation or invoice the message concerns. STRYK therefore uses guest and booking together. If the booking context is unclear, stop before writing and resolve it in the source record. Keep private details inside the authorised booking conversation and use a booking or room reference in handover notes rather than copying contact data elsewhere. The context check is complete when another colleague can identify the intended recipient and stay without guessing from the message body.

Understand the channel from the booking source

Manual, phone, walk-in, email, website and booking-engine reservations use email, with subject and plain or HTML formats. Verify the stored address first.

OTA and channel bookings use a plain-text channel conversation. Do not bypass it with a separate email, or the booking history becomes incomplete.

Read the communication channel from the booking source. Manual and direct bookings use email; OTA or channel bookings use the booking channel as a plain-text conversation. The composer does not provide a free channel choice because changing the route would break the relationship between reservation source and message history. Confirm the displayed channel and available recipient before selecting a template. Email can use plain text or approved HTML with preview, while channel messages remain plain text and must not depend on unsupported formatting. If a different contact route is operationally necessary, treat it as a separately authorised process and document why; do not hide the change inside the composer. For portal bookings, STRYK sends the plain-text message through the connected Booking.com or Airbnb route and keeps every reply in the same booking conversation.

Choose a template by purpose, channel and language

The list shows active templates matching the derived channel. Choose by the guest-journey purpose and required language, not by a similar-sounding name.

STRYK applies format, subject and body. Recurring corrections belong in the central template; one-off details stay in the draft. Avoid private outdated copies.

Choose a template by one concrete purpose, the displayed channel and the guest language. Arrival information, payment reminder, missing data and post-stay thanks are different decisions and should not be combined into a vague universal message. Use only an active template offered for the derived channel. Read it before applying: check salutation, tone, hotel times, links, cancellation or payment wording and signature against current hotel practice. A template is a reviewed starting point, not permission to send unchanged. If the guest language differs from the hotel default, select or write a complete version in that language; a translated subject with mixed-language body is not ready. Remove paragraphs that do not apply to this stay and add only facts already approved in booking, policy or hotel settings.

Review placeholders from the real booking context

The picker exposes values resolvable in the current guest and booking context. Read the resolved preview and compare dates, room and booking details with the context panel.

Unresolved placeholders are shown below preview. Fix missing source data, reload and review again; if unavailable by design, remove the token or rewrite the sentence.

Resolve every placeholder in preview against the current booking. Check guest salutation and name, hotel, arrival and departure, category or assigned room, booking number, total, outstanding amount, cancellation policy and contact details according to the template purpose. An unresolved token, empty dash or implausible value is a blocker, not cosmetic text. Correct missing source data when it should exist; otherwise rewrite the sentence without making a promise. If no room is assigned, say the booked category rather than guessing a room number. If a payment value is disputed, do not replace it manually in the message; resolve Finance first. Alias placeholders may render for compatibility, but the picker should use current canonical values available in this booking context. The final preview must contain only real, explainable data.

Read content as both host and reviewer

Read as the guest: the first two sentences should explain why the hotel writes and what happens next. Use clear times and everyday language, not internal codes.

Then review recipient, salutation, booking number, dates, room claims, price references, links, signature and language. HTML needs visual review; channel messages remain clear plain text.

Read the final message twice: first as a host, then as a reviewer. As host, make the next guest action obvious, use respectful language and include only information that helps the stay. As reviewer, verify booking facts, dates, amounts, policy statements, links, response deadline, signature and privacy. One message should have one primary goal and a clear answer to what the guest should know or do. Avoid internal jargon, blame, legal promises the hotel cannot keep and sensitive data not required for the purpose. For an urgent change, state what changed, which stay is affected and where the guest can respond. For HTML email, inspect both formatted preview and readable text; for channel messages, ensure meaning survives plain text. A concise specific message is safer than a long template full of irrelevant clauses.

Send once and prove the result in the thread

Confirm the booking, send once and wait. If STRYK shows an error, keep the draft, correct the cause and do not record success prematurely.

After success, find the message in the same booking thread and verify direction, time, channel, subject where applicable and booking number. If it is not visible, reload before retrying.

Send once and wait for the actual result. A disabled button, spinner or slow network is not permission to click repeatedly. On success, reopen the same booking conversation and verify exactly one outgoing entry with correct timestamp, channel, subject where applicable and visible content. For email, a successful application result and thread entry prove that STRYK accepted the send; delivery failures must remain visible through the appropriate status or follow-up. For a channel conversation, confirm the plain-text message sits in the correct reservation thread. If sending fails, preserve the draft, read the error and correct recipient, channel, content or connection at its source. Never create a local success entry or copy the message into another booking merely to make the history appear complete.

Check two common mistakes with a separate test. First case: the guest does not have a usable e-mail address in a direct booking. The correct result is not guessing the recipient or using another guest's address, but visible blocking and clarifying the contact information in the guest profile or booking. Second case: They would choose an email template for OTA booking. The channel and plain text form derived by the system should remain visible; do not manually copy the message to a separate email by losing the conversation connection. For both rehearsals, write down the reservation number, expected channel, actual feedback and next person in charge. This way, the team can handle not only successful sending, but also safe stopping when the source data or channel is not suitable.

Maintain one team messaging standard

Define one responsible template per recurring situation, channel and language, with ownership and regular review. Prefer a small clear set over many similar names.

Hotel Nordlicht tests direct plain email, direct HTML preview, OTA plain channel, a missing placeholder and a guest with two bookings. Issues are fixed at source, template or booking level.

Maintain a small team standard for recurring messages. Every approved template needs purpose, channel, language, owner, last review date and next review trigger. Review after changes to check-in times, payment process, cancellation policy, hotel contact, links or guest journey. Keep approved templates in STRYK so every colleague works with the same current wording. After activation, open one test conversation and check recipient, stay, channel, wording and single delivery before the team uses the template. Retire obsolete templates instead of leaving near-duplicates active. The process is reliable when a colleague can later understand purpose, recipient, stay, channel, exact content and result solely from the booking conversation.

Sample at least three conversations per month or after each significant operational change: one direct email, one channel plain text message, and one case where the sending had to be blocked. Check the correct booking contact, guest language, unlocked placeholder, clear goal, one-time outgoing line and responsible closing of the error. Do not copy personal content into an educational document; quality control should record only the required booking reference and result. In the event of a recurring error, do not correct each message one by one: identify whether it is caused by a template, central hotel data, booking source or team process, order a correction and a new test.

Record the date and person responsible for the review next to the template so that the reason and due date for the next review is clear to all colleagues.