Guest messages on booking sites: who answers, how fast and what never goes in the chat

Booking-site guest messages are the questions and requests a guest sends through the booking site's own inbox before or during the stay. One named owner per shift answers them, the hotel sets its own first-reply target, and card numbers and identity documents never travel through that chat.

It is 23:40 and a guest writes through the booking site asking whether the airport transfer can be paid at the desk. The message is opened at 07:15 by the person starting the morning shift, and the answer arrives after the guest has already booked a transfer elsewhere. Nothing in that story is unusual, which is the problem. After reading this article you will be able to name an owner for every shift, write a reply standard you can keep, build ready answers for the ten commonest questions, route special requests to the right department, and keep the chat free of card numbers and identity documents.

Why does the booking-site inbox need one owner?#

A message with no owner is nobody's job until it becomes a complaint. One named person per shift, with a written handover, is what turns the inbox into a queue that empties.

A shared login is not an owner#

If four people can open the inbox, each of them assumes someone else already answered. The fix is not more logins or more training; it is a rota. Name an owner for every shift that exists in your hotel: reservations in the morning, front desk in the afternoon, night audit at night. The owner either answers the message or hands it over with a note.

The inbox owner is not the owner of every answer. Rate questions go to revenue, group questions to sales, but the inbox owner still sends the reply so the guest hears one voice. That distinction keeps the guest experience consistent without making one person the expert on everything.

What the handover note must carry#

The handover note carries three things: what the guest asked, what was promised, and by when. A promise made at 22:00 is a task for the morning shift, not a memory. If the note is missing one of the three, the next shift has to re-read the whole thread and guess.

Weekends and public holidays are where the standard breaks first. Put a named weekend owner on the rota in advance instead of discovering the gap on Sunday. Write the rota where the team can see it: a rota that lives in one manager's head disappears on the first sick day.

What first-reply standard should a hotel set for itself?#

One the hotel chooses, writes down and can still keep on its worst day: a stated time for messages that arrive during working hours, and a stated promise for those that arrive after them.

Measure from the moment the message lands, not from the moment someone opens it. The guest's clock starts at sending. Separate the holding reply from the answer: a holding reply buys time only if it says when the real answer comes, for example "we will confirm by 10:00 tomorrow".

Choose hours you can actually staff. A 24-hour promise from a hotel with no night desk is a promise broken every night, and guests remember the break, not the intention. Write the standard as two sentences and put it where the team sees it daily; if it takes a paragraph to explain, it will not survive a busy check-in.

Review the standard monthly against the actual unanswered list, not against memory, because memory reports the good days. Do not copy another hotel's number: the standard has to match the rota you built above. Check the site's current rules in your extranet for how response times are displayed and which message features exist; those rules change, and this article makes no claim about them. If guests keep writing outside your answered hours, consider setting an after-hours auto-reply that helps instead of annoys.

Which ten questions fill the inbox, and who keeps the answers current?#

Build the list from your own last month of messages; the ten you write down are the ones your hotel actually receives, and each answer needs an owner in the hotel who keeps it true. Write the answers once.

The fact and the wording#

Each answer has two parts: the fact (check-in time, parking arrangement, transfer price band) and the wording (short, plain, no promise the hotel cannot keep). Give every answer an owner: front office for arrival and check-in, housekeeping for early check-in and extra beds, kitchen for breakfast and diet, reservations for rates and children's policy, accounting for invoices.

When an answer goes stale#

Review the answers whenever something changes: a renovation, a new parking arrangement, different breakfast hours. A stale answer is worse than no answer because it sounds confident. Keep the answers in one document the whole shift can open, not buried in a chat history or one person's notes.

Answer in the guest's language where the hotel can. If it cannot, say so plainly and answer in English rather than sending a machine translation nobody has read. Watch which question keeps arriving: a repeated question usually means the listing text is unclear, and fixing the listing removes the message. The ten answers fit naturally into the morning extranet routine on booking sites.

Where do special requests go, and what does the guest hear back?#

A special request is a task for a department, not a sentence in a chat. It goes onto the reservation, reaches housekeeping or the kitchen, and the guest hears back only what has actually been confirmed.

Sort the request before answering it. Some the hotel decides alone (high floor, quiet room), some need another department (a cake, a late meal, a cot), and some the hotel cannot promise at all (a specific room number). Write the request onto the reservation itself, so the arrival shift sees it without opening the chat thread.

Reply with the state of the request in one of three words: confirmed, noted but not guaranteed, or not possible. "Noted" is honest. "Confirmed" is a promise the hotel now owns. Never confirm anything that depends on a supplier or a shift nobody has asked yet; ask first, then answer.

Recheck the request on the arrival day, because a cake ordered eleven days ago is a cake nobody remembers. If the request cannot be met, say so before arrival, not at the desk: the guest can still plan around a no, but not around a surprise. Keep the guest's own words where the detail matters, such as allergies or accessibility needs, because paraphrasing those is where mistakes start.

What never goes in the chat, and what do we do when a guest asks for WhatsApp?#

Card numbers, card security codes and photographs of passports or identity cards never travel through the booking-site chat, in either direction. A guest who asks to continue elsewhere is moved deliberately, with the reservation record kept intact.

Never ask a guest to type a card number, a card security code or a photograph of an identity document into the chat. If payment is the question, point to the site's own payment flow or to payment at the desk. Never send a guest's card details or identity document back through the chat, not even to "confirm" what you received.

In Türkiye every stay involves personal data (KVKK, the personal data protection law). The fewer copies of a passport sitting in inboxes, the fewer places the hotel has to protect. Keep other things out too: another guest's rate or booking, internal notes about the guest, staff mobile numbers, and anything you would not want forwarded to a lawyer.

When the guest sends a card number first#

If a guest sends card details unprompted, do not repeat them, do not keep them in the thread, and tell the guest plainly that the hotel does not hold card details in messages. If the card later turns out to be invalid, follow the site's reporting process, as described in invalid cards and no-shows on booking sites, rather than asking the guest to retype the details into the chat.

When a guest asks for WhatsApp or e-mail, agree, but keep anything that changes the reservation on the booking-site record as well, and get consent before sending anything beyond the answer to their question. The rules for in-stay messaging are covered in messaging guests on WhatsApp during the stay. Check the site's current rules in your extranet on what may be shared in messages; we make no claim about those rules here.

What daily and weekly checks stop messages sitting overnight?#

A short end-of-shift check and a longer weekly read. The first catches today's messages, the second catches the pattern nobody replied to.

At the end of each shift, open the inbox, count the unanswered threads, then answer each one or hand it over with a note. A count on the handover sheet is the cheapest control a hotel has. Before the night shift ends, take one last look: a message that arrives at 23:50 is tomorrow's problem only if someone writes it down.

Weekly, read the slowest threads rather than the average, because an average hides the single message that waited three days and became a review. Test the ten answers against reality: has anything changed, and does the person on shift still know where the document is? Monthly, look at which source markets ask which questions, and whether those answers exist in that language. Keep every check short enough to survive a busy Sunday: a check that takes an hour is abandoned in the first high season.

What to do next#

Name the owner for each shift this week and write the two-sentence reply standard on the same page, because the rest depends on both: ready answers only help if someone is there to send them, and a fast reply only helps if it is accurate. Then build the ten answers, route special requests onto the reservation, and keep cards and identity documents out of the chat entirely. The daily check is what proves the other four are still working.