Master Prompts for Hospitality: Guest Communication, Operations, and Service Documentation

Hospitality depends on context: a reservation state, room or table availability, guest request, property policy, operating condition, and staff judgment at that moment.

A master prompt can turn approved context into a clear draft or shift handoff. It should not promise availability, change a reservation, authorize compensation, decide safety, or infer what a guest needs.

Define the Property and Service Scope

{
  "property_or_venue_id": "authorized-id",
  "service_area": "approved-enum",
  "reservation_or_case_id": "authorized-id-or-null",
  "locale": "approved-locale",
  "channel": "approved-channel",
  "policy_versions": []
}

Code should prevent guest and operational records from different properties, venues, groups, rooms, tables, or reservations from being combined.

Guest Communication

Retrieve the minimum verified details needed: reservation status, dates, approved amenities, hours, request status, service case, and communication preference.

The model may draft confirmations, pre-arrival notes, answers from approved property information, and follow-up messages. It should not promise an upgrade, early arrival, special item, accessibility arrangement, refund, or exception until the responsible system or staff confirms it.

Read Guest Experience AI for personalization and consent boundaries.

Operations Handoffs

Front desk, housekeeping, maintenance, food and beverage, events, security, and management need concise, role-specific information. A master prompt can transform approved task records and notes into a structured shift handoff.

Keep observation, request, assignment, work performed, verification, and closure as separate fields. The model should not mark a room, equipment item, food-safety issue, or guest case complete.

Keep Employee Records in Their Systems

Shift notes can include staffing gaps and assigned work, but should not become an uncontrolled personnel file. Performance, attendance, accommodation, health, discipline, tip, payroll, and investigation data require separate authorized workflows.

The model should not infer employee performance from guest sentiment or task counts. Managers review context and follow approved employment practices.

Use Approved Operational Knowledge

Property maps, room and table attributes, amenity details, menus, recipes, equipment procedures, vendor contacts, and emergency information need owners, effective dates, and property scope.

Retrieval should prefer the exact venue source and return “not found” when it is unavailable. A similar property's answer can create a safety issue or a broken guest promise.

Design for Outages

When reservation, point-of-sale, property-management, or task systems are unavailable, route work to the property's established manual process. Do not let the model infer live state from earlier conversation.

Queue drafts with timestamps and revalidate current state before sending after service returns. This avoids confirming a room, table, menu item, or resolution that changed during the outage.

Service Documentation

For a guest concern, preserve the guest's words, time, channel, location, reservation context, staff observations, actions already taken, promised follow-up, and owner.

{
  "case_id": "service-record-id",
  "guest_statement": "",
  "verified_facts": [],
  "actions_taken": [],
  "pending_commitments": [],
  "draft_response": "",
  "manager_review_required": false
}

The model may draft an empathetic response without inventing fault, compensation, or completion.

Safety and Accessibility

Emergency, security, food allergy, food safety, medical, maintenance, evacuation, and accessibility requests require approved procedures and trained staff. Route them immediately under property policy rather than waiting for a polished response.

Do not diagnose, minimize a hazard, recommend medical action, improvise allergen information, or decide that an accommodation is adequate. Use current approved information and qualified human review.

Protect Guest Data

Limit identity documents, payment data, room numbers, travel details, preferences, messages, health or accessibility information, and incident records. Mask sensitive values in logs and evaluation sets.

A prompt instruction does not create consent or a permitted marketing use. Privacy and legal teams define retention, access, communication, and cross-property rules; developers enforce them.

Control Every Action

The model should not create or cancel reservations, assign rooms, issue keys, charge cards, apply credits, change rates, send marketing, dispatch security, modify food orders, or close service cases.

It returns a proposed message or task. Application code verifies current state, role, guest preference, approval, and idempotency before an allowed action.

Test Hospitality Reality

Test an overbooked night, changed hours, unavailable amenity, duplicate reservation, room move, guest opt-out, allergy request, accessibility request, safety incident, disputed charge, wrong property, hostile message text, and records from another guest.

Staff Create the Experience

Property leaders own policy and escalation. Frontline and operations staff own verified service, safety, and guest decisions within their roles. Privacy, food-safety, security, accessibility, and legal specialists own applicable guidance. Developers own record identity, permissions, validation, versioning, and actions.

The master prompt supports consistent handoffs and communication. It does not replace hospitality judgment.

Browse hospitality workflow contracts in the CyWire marketplace and apply the production-ready checklist before connecting reservation or guest data.

This article is technical information, not hospitality, accessibility, food-safety, security, medical, privacy, or legal advice.