Hotel guest service requests and messaging data for AI

Why operator-held guest threads matter for guest-service agents

Real multi-turn service conversations with commercial training rights are scarce, which is why threads held by hotel operators are worth sourcing. The well-known public corpora of real conversations, such as ShareGPT, carry unclear or restrictive licensing terms and contain chatbot sessions, not service work [1]. Synthetic hospitality dialogues miss what makes the domain hard: a guest who asks for towels, then reports a broken air-conditioning unit, then disputes a minibar charge in the same thread.

A guest-messaging agent has to classify intent, decide whether it can answer from policy or must open a work order, route to the right department and set an honest expectation on timing. Each of those decisions needs a label that only operations systems hold. The text alone tells you what the guest said; the property management system (PMS), service-optimization tool and housekeeping board tell you what the hotel actually did. For the seller-side view of these use cases, see what AI companies build with hotels data.

The fields that make a guest request dataset trainable

A usable dataset carries thread structure, stay context, request labels and fulfillment outcomes on every record. Generic support-ticket data usually lacks stay phase and department fields, which limits its value for hotel routing models. Specify at least the following when you write a request.

Survey linkage is often partial, so ask what share of threads carries a score before you design around it. For a broader structure that applies across chat sources, the conversation transcript delivery schema covers turn-level conventions you can reuse.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "thread_id": "t_8f21c",
  "channel": "whatsapp",
  "language": "es",
  "stay_phase": "in_stay",
  "stay_day": 2,
  "room_type": "king_standard",
  "messages": [
    {"message_id": "m1", "ts": "2026-03-14T21:02:11Z", "sender_role": "guest", "text": "Hola, el aire acondicionado no enfria en la habitacion [ROOM]."},
    {"message_id": "m2", "ts": "2026-03-14T21:03:40Z", "sender_role": "agent_human", "authoring": "human_written", "text": "Lo sentimos, enviamos a mantenimiento ahora mismo."}
  ],
  "request": {"category": "maintenance", "subcategory": "hvac", "multi_request": false},
  "routing": {"department": "engineering", "reassignments": 0, "work_order_ref": "wo_[HASH]"},
  "fulfillment": {"acknowledged_at": "2026-03-14T21:03:40Z", "completed_at": "2026-03-14T21:41:05Z", "status": "completed"},
  "outcome": {"survey_score": null}
}

Separating brand templates, bot turns and human-written replies

Label every outbound turn as human-written, edited template, unedited template or bot, or your fine-tuned model will learn brand-standard boilerplate instead of service judgment. Hotel messaging platforms push scheduled pre-arrival messages, check-in links and post-stay survey requests at volume, and in many threads those outnumber the human replies. Training on them unfiltered produces an agent that greets warmly and resolves nothing.

Ask the supplier how authoring was determined: a template_id on the message, a platform flag, or text matching against the template library. Where a virtual assistant handled the first turns, look for an explicit handoff marker; Dialogflow CX, for example, emits a LiveAgentHandoff response message with a metadata field when a conversation goes to a human [5]. The guide to separating bot, macro and human turns covers detection methods and the failure modes of each.

Guest PII, room numbers and card data: what must be removed

Guest names, room numbers, loyalty IDs, phone numbers, email addresses, booking confirmation numbers and exact stay dates must be removed or replaced before delivery, because combinations of them identify a guest even when the name is gone. Sweeney's k-anonymity work showed that a few quasi-identifiers in combination can single people out [3]; a room number plus a check-in date at a named property is exactly that kind of combination. Ask for room numbers as tokens, dates shifted or expressed as relative stay days, and property identity generalized to segment and region.

Card numbers are the second hazard. Guests paste card details into chat to settle incidentals or guarantee late arrival, and agents sometimes read them back. PCI SSC guidance on recorded customer interactions explains how PCI DSS applies when cardholder data lands in recordings, and the same logic applies to stored message text [2]. Require Luhn-validated PAN detection plus pattern checks for expiry dates and security codes, and ask for the redaction log and the residual-hit rate from the supplier's own sample review.

Consents matter as much as redaction. The FTC has warned that quietly changing privacy terms to repurpose customer data for AI training can be unfair or deceptive [4], so ask what the hotel's guest privacy notice said when the messages were collected. For property-side licensing rules, see data licensing rules for hotels.

Multilingual coverage and evaluation splits

Request language distribution by property region and stay phase, because international guests write in many languages and code-switch mid-thread. A dataset that is 95 percent English will not tell you how your agent handles a Japanese guest asking about a late checkout. Ask whether the language field was set by the platform, by detection, or by the guest's profile, since profile language and message language often differ.

Build evaluation splits by property and by time, not by random thread. Random splits leak property-specific phrasing, menus and policy wording into your test set and inflate routing accuracy. Hold out entire properties and a later calendar period, and check that seasonal events (holiday peaks, conference weeks) appear in both splits.

Buyer checklist for a hotel guest messaging data request

Use this checklist to scope the request and to review a sample before you commit to a license.

Illustrative example: invented to show structure; it does not describe an available dataset.

• Scope: channels (SMS, WhatsApp, app chat, web chat, email), property segments, regions, date range and expected languages.
• Joins: whether threads link to PMS stay records, task or work-order systems and survey results, and the join keys used.
• Labels: the request category taxonomy, who assigned it (agent, rule, model) and how disagreements were resolved.
• Authoring: a human, template or bot flag on every outbound turn, and the method used to set it.
• Completeness: share of threads with fulfillment timestamps and outcomes; truncated threads flagged. The case record completeness checks give a test plan.
• Privacy: the de-identification method, the token scheme for rooms and loyalty IDs, PAN scan results and the sample review outcome.
• Rights: the collection-time privacy notice, ownership of message content between hotel and messaging vendor, and permitted uses.
• Delivery: format (JSONL per thread or Parquet per message [7]), data dictionary, taxonomy file and change log.
• Documentation: enough provenance detail to support your own training-data disclosures, such as California AB 2013 postings for generative AI systems offered to Californians [6].

How hotel threads differ from other service conversation data

Hotel threads are short-horizon and physical: the request is fulfilled by a person walking to a room, so the fulfillment timestamp is the key label. E-commerce order-support conversations hinge on order state instead, and resident maintenance requests run over days rather than minutes. If your agent must follow written policy before acting (late-checkout fees, cancellation windows), pair guest threads with the policy texts described in policy-following service agent data. The industry-specific operational data hub lists other sectors, and the AI data buyer guides cover cross-cutting topics.

How SourceX sources hotel guest messaging data

SourceX sources operational datasets, including support and service histories, from US companies on request and manages the licensing process; it does not hold hotel data in stock, and a request does not guarantee a match. You describe the data you need, not the businesses; SourceX looks for US businesses that hold it, and every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents, personal details such as names, emails, phones and account numbers are removed or replaced before delivery with the method recorded and a sample checked, and no method is perfect. You can submit a buyer request with your field list, or compare adjacent needs on the customer support buyers page and the chat logs licensing page.

Request hotel guest messaging data for your agent

Describe the channels, stay phases, request categories, languages and fulfillment fields you need, and SourceX will assess whether US hotel operators hold matching data and what licensing permissions apply. Nothing is contracted until a supplier agrees, and pricing and allowed uses are set in a license per deal. Start your hotel guest messaging data request.