A guest may ask about early check-in through a booking channel, send transfer details by email and call reception on arrival day about the same reservation. If those contacts remain in separate screens, the team may answer the same question twice, miss an important request at shift change or send information from the wrong reservation to another person. A reliable messaging workflow matches each channel message to the right reservation and guest, makes response ownership visible, avoids unnecessary copies of personal data and preserves an auditable history.

What you will learn in this article
  • Messages should be matched by property, conversation, reservation and participant IDs rather than channel name, and ambiguous records should not be linked automatically.
  • Read, awaiting reply and completed must be separate states, and every message should be assignable to a user or team.
  • Templates, automation and AI suggestions should support human oversight, with separate security rules for sensitive data, attachments, links and retention periods.

Bring every channel into one inbox

Guest communication is not limited to email. Messages from online travel agencies, website forms, WhatsApp and phone notes may all concern the same stay. A central inbox should show these contacts in one list while preserving the source channel, because sending windows, attachment support and reply methods may differ by channel. The Booking.com Messaging API supports retrieving conversations by property, conversation or reservation ID, sending text and attachments, and managing read or no-reply-needed states. Expedia Group also documents querying message threads by property or ID and receiving new-message notifications through webhooks.

One screen does not mean flattening every message into plain text. The system should retain the original channel message ID, arrival time, sender, reservation reference and any attachments. Replies should go back through the originating channel, and staff should see which identity and channel they are using. If a channel connection is temporarily unavailable, the message must not disappear: it should remain visible in an error queue and be retried safely.

  • Channel, property, conversation and message IDs were stored in separate fields.
  • New messages were received through polling or webhooks without loss or duplication.
  • Unsent replies showed the failure reason and retry status.
  • Offline contacts such as phone calls were added to the same timeline with a staff note.

Match each message to the right reservation and guest

The most reliable match uses the reservation or conversation reference supplied by the channel. Similar names, phone numbers or email addresses should be supporting signals only; guests with the same name and group bookings with several rooms can cause incorrect automatic matches. Booking.com documents that a new empty conversation is created for each reservation and can be queried by reservation ID. When that relationship is carried into the PMS, the message can appear directly on the relevant reservation timeline.

If no match is found, the system must not save its guess as a confirmed record. It should show possible reservations with date, property, room, lead guest and channel number, and log the reason for a manual selection. Message history should not be deleted when a reservation is cancelled or a room changes; it should be associated with the new state. If one message concerns several rooms, keep the parent reservation link and create tasks for the relevant rooms.

  • Channel reservation and conversation references were given priority.
  • Name or email similarity alone was not used for automatic matching.
  • Ambiguous matches required user confirmation and were written to the audit history.
  • Message history was preserved and relinked after cancellation, room changes and group-booking updates.

Do not confuse read status with completed work

Opening a message on screen does not mean its request has been fulfilled. States such as 'unread', 'awaiting reply', 'internal task created', 'awaiting guest information' and 'completed' should be separate. A cot request may have been answered, for example, but the operation is not complete until housekeeping finishes the task. Relying only on read status can make open requests disappear during shift handover.

Every message or request should be assigned to a team or user, with the target response time and latest activity visible. Reception, reservations, housekeeping and maintenance should track their own tasks on one record instead of copying the same message into different lists. The shift-handover view should highlight overdue items and open requests for guests arriving today.

  • Read, replied and operationally completed were separate states.
  • The request became a task with a responsible team, user and target time.
  • Open and overdue tasks were listed automatically at shift handover.
  • Completion time and the user who performed the action were kept in the audit log.

Use templates for speed without losing context

Approved templates shorten response time for recurring topics such as early check-in, parking, transfers, breakfast hours and directions. A template should fill fields such as property name, arrival date or reservation code from a trusted source and show the user a full preview before sending. A fast reply in the wrong language, with outdated hours or another guest's name can create more trouble than no reply at all.

Template selection can be suggested by conversation language, stage of stay and request type, but staff must be able to edit the text. If machine translation is used, retain the original message and flag low-confidence translations. Topics involving charges, cancellations, health, safety or identity information should require approval from an authorized user instead of automatic sending.

  • Each template had an owner, language, version and last-review date.
  • Dynamic fields were filled only from verified reservation data.
  • The recipient, channel and full message preview were shown before sending.
  • Automatic sending was disabled for charges, cancellations and sensitive requests.

Handle attachments, links and sensitive content securely

A message attachment may contain an identity image, travel document or payment information. Files should never become public links: scan them for malware, apply type and size limits, and grant time-limited access only to authorized users. Preview copies and downloaded temporary files must follow the same retention rule. Staff should be instructed not to request card numbers, passwords or unnecessary identity images through messages.

The channel's security result must also be respected. Booking.com documents that it may remove unapproved links from responses and redact messages detected as phishing content together with their attachments. The PMS should not restore redacted content from an old cache and must clearly tell the user that the channel hid the message for security reasons. Instead of clicking a suspicious link, staff should verify the conversation source and reservation.

  • Attachments were opened with authenticated, time-limited access and malware checks.
  • Sharing card data, passwords and unnecessary identity documents was prevented.
  • Messages and attachments redacted by the channel were not restored from local copies.
  • Suspicious content was presented with a security warning and reporting step.

Define purpose, access and retention for data protection

A guest message may constitute personal-data processing because it can include a name, contact details, reservation information and sometimes health or identity data. The general principles of Turkey's data-protection law require processing for specified, explicit and legitimate purposes, in a relevant, limited and proportionate way, and retention only for as long as necessary. Keeping every message forever because it may be useful later is therefore not an appropriate approach.

The hotel should document the message category, processing purpose, legal basis, roles with access, service providers receiving data and retention period. The Turkish Data Protection Authority's security guidance calls for appropriate technical and organizational measures to prevent unlawful processing and access and to safeguard the data. A permissions matrix, access logs, encryption, backup security, staff training and incident response are parts of that approach. The retention and disposal policy should also define the deletion, destruction or anonymization method used when the reason for processing no longer exists.

  • Purpose, legal basis and retention period were defined for each message category.
  • Role-based access and message-view logs were reviewed regularly.
  • External service providers and data transfers were clearly listed in the inventory.
  • Expired content, including backups, followed a defined disposal process.

Keep humans in control of automation and AI

Automation can classify a message by topic, suggest a suitable template, detect the language or draft a reply. Changing a reservation, promising a price, interpreting cancellation terms or transferring personal data to another system are higher-risk actions. Those steps should not run without explicit authorization, user approval and an audit record.

The system should visually distinguish suggested text from a sent message, and staff should be able to record why they changed a suggestion. Wrong answers, wrong-language replies and low-confidence classifications should be sampled for regular quality checks. Guests should know when they are talking to a bot and be able to reach a person easily. If a channel or AI service is unavailable, preserve the queue and clearly show the user that the message was not sent.

  • Permissions for automatic classification, drafting and sending were defined separately.
  • Replies that changed finances or reservations required human approval.
  • A visible path to human support was kept available to the guest.
  • Suggestion, editing, approval and sending were logged as separate steps.

Measure response quality and test outage scenarios

Total message count alone does not show operational quality. First-response time, unanswered conversations, overdue tasks, reopened requests, messages linked to the wrong reservation and channel-specific send failures should be monitored together. Speed metrics should not push the team toward rushed, copied replies; assess them alongside resolution time and repeat-contact rate. Management reports should identify busy periods, understaffed shifts and recurring service problems rather than act mainly as a tool for penalizing staff.

Before go-live, test new and cancelled reservations, group stays, messages with attachments, different languages, redacted content and channel outages end to end. A duplicate delivery must not create a second record; polling should close the gap if a webhook is delayed; and a failed send must never be shown as successful. Run the same test suite after every channel change.

  • First response, resolution, unanswered conversations and reopen rates were measured together.
  • Webhook, polling and duplicate-message scenarios were tested.
  • Queue, warning and retry behavior were verified during a channel outage.
  • Correction and notification workflows were defined for bad matches and access incidents.
Short answers

FAQ

Is it enough to collect hotel messages on one screen?

No. Each message must be matched to the right reservation, retain its source channel, have clear response ownership, complete any operational task and expose failed sends. A single list is only the starting point.

How long should guest messages be retained?

There is no single period for every hotel. Define category-based retention after assessing the processing purpose, legal basis and applicable legislation, then apply the documented deletion, destruction or anonymization process when the need ends.

Can AI answer guest messages automatically?

Controlled automation can handle low-risk questions with clear rules. Human approval and an easy handoff to staff are safer for topics involving charges, cancellations, reservation changes, health, safety or personal data.

Sources and updates

Operational recommendations should be adapted to the property's own conditions. Information about PMS and channel workflows was checked against the official documents below on 25 September 2026.