Catalog / Conversational AI & Assistants / CONV-012

Travel & hospitality concierge

A multilingual chat and voice concierge that answers guest and traveller questions, handles bookings, changes and upsells, and hands over to staff, for hotels, airlines, tour operators and destinations.

Quick win: proven, manageable effort, first results within weeks, low regulatory risk.

Guests ask the same questions at all hours and in many languages: check-in time, parking, breakfast, rebooking, baggage rules, what to do tomorrow. A concierge assistant grounded in the property's own knowledge base and connected to live reservation data answers instantly on the guest's preferred channel, executes simple changes and sells upgrades, and passes anything delicate to staff with context. Benefit: fewer repetitive front-desk tasks, 24/7 coverage, more ancillary revenue.

Problem & value

  • Today: front-desk and reservation staff answer the same questions by phone, email, OTA inbox and WhatsApp, often outside staffed hours; small hotels lose direct bookings to unanswered enquiries. Airlines and tour operators face peaks during disruption (strikes, weather) when call centres saturate.
  • AI value: instant multilingual answers, structured handling of changes and requests, proactive pre-arrival messages, upsell at the right moment (late check-out, spa, transfer), and cleaner handover to humans. Staff time shifts from FAQ answering to hosting.
  • Evidence: Mews launched native AI-assisted Guest Messaging in October 2026 covering SMS, WhatsApp, Booking.com, Expedia and a guest portal, with replies drawn from live reservation data and the property knowledge base; its resolution-rate claims are vendor figures and should be tested on your own traffic [1]. Cautionary precedent: a Canadian tribunal held Air Canada liable for wrong refund advice given by its website chatbot [2].

Variants

  • Independent hotel / B&B / holiday rental: messaging inbox with AI reply drafting, PMS-linked.
  • Hotel chain / resort: multi-property concierge with brand voice, loyalty data, in-room voice or QR-code chat.
  • Airline / rail / airport: disruption rebooking, baggage and rights information (EU passenger rights), usually transactional with strict policy grounding.
  • Tour operator / OTA: trip enquiries, package changes, supplier coordination (overlaps CONV-006, PERS-003).
  • Destination / tourist office: local-tips and events assistant, multilingual, public sector (see CONV-011).
  • Voice: phone reservations and room-service ordering (CONV-002).
  • Private use: traveller-side planning assistants are PERS-003.

How it works

  1. guest message (chat / WhatsApp / voice
  2. ASR)
  3. language detection + intent routing (small model)
  4. grounding: RAG over knowledge base + live PMS/CRS/booking API lookups (tools)
  5. LLM answer or action (check availability, modify booking, create service ticket, offer upsell)
  6. guardrails (policy check, price/commitment limits, PII filter)
  7. reply (text / TTS) or handover to staff with summary
  8. logging, feedback, review request
  • Retrieval + tools: policies and FAQs come from a versioned knowledge base; anything about the guest's own stay comes from the PMS via API, never from model memory.
  • Actions: read-only by default; write actions (change dates, refunds, compensation) require limits, confirmation steps or staff approval.
  • Human-in-the-loop: complaints, medical or safety issues, refund and compensation decisions, group bookings and anything the bot cannot ground are escalated. Staff can also run it in "draft only" mode where the AI proposes replies.

Data preparation

A concierge needs property facts and local knowledge: room types, prices and policies, restaurant and spa hours, house rules, FAQ, local tips and event calendars. In a hotel these live in the PMS, the website CMS, Word and PDF info sheets on the file share, the reception's notes and e-mail threads with past guests. Typical gaps: contradictory or outdated information across the website, OTA listings and the in-house folder, missing translations, scanned brochures, knowledge held only by long-serving staff and guest data mixed into the same sources.

Preparation steps: (1) collect all guest-facing information into one authoritative knowledge base with a named owner (GUIDE-003, PREP-013); (2) turn tribal knowledge into short written entries (PREP-014) and add synonyms and terms in the languages of your guests (PREP-015); (3) OCR old brochures (PREP-006, DOC-014); (4) gather real guest questions and good answers as test and gold examples (PREP-016, PREP-018); (5) keep personal guest data out of the knowledge base and pseudonymise exports (PREP-022). Tools: a simple wiki or spreadsheet, the PMS API, Paperless-ngx for OCR. Expect around 25 % of the effort in data work, mostly in the first weeks, followed by a quarterly review.

Implementation paths

Which path for whom

  • SMB: Path A, because mature EU-hostable concierge and messaging products exist at SMB prices and hotel guest questions are a standard process.
  • Enterprise: Path B, because hotel chains and travel groups must integrate with their own booking, PMS and loyalty systems and want brand-specific behaviour.
  • Developer: Path B, because cloud APIs plus the PMS and booking interfaces give the fastest route to a tailored concierge product.
  • Private: Path A, because travellers use ready-made assistants and booking apps rather than running their own.
  • PMS-native: Mews (EU, Amsterdam) Guest Messaging and Automations [1]; most modern PMS vendors (e.g. Apaleo, Cloudbeds, Oracle OPERA Cloud) offer or integrate messaging and AI modules — verify current feature status and EU data residency per vendor.
  • Hospitality chatbot/guest-communication vendors: e.g. Quicktext, HiJiffy, Bookboost and similar, several EU-based; check WhatsApp Business API support, languages, PMS connectors and DPA.
  • Customer-service platforms: Zendesk, Intercom, Salesforce, plus EU Sinch or Infobip for messaging channels.
  • Choose A when: < ~100 properties, standard PMS, no unusual workflows. Insist on EU hosting, a DPA, logged handover and the ability to restrict what the bot may promise.

Path B — Build on cloud APIs

  • Models: Mistral (EU), Claude, Gemini, GPT via EU regions (Azure OpenAI EU Data Zone, Vertex AI europe-west, Amazon Bedrock Frankfurt); small model for routing, larger for answers.
  • Stack: WhatsApp Business Platform / Twilio / Sinch for channels; vector store (pgvector, Qdrant); tool calling against PMS APIs (e.g. Mews Connector API, Apaleo API); orchestration with n8n or LangGraph; voice via a realtime speech API.
  • Choose B when: you are a chain, airline or OTA with proprietary booking logic and want your own brand experience.

Path C — Self-host (open source)

  • Models: open-weight LLMs such as Mistral Small/Medium-class, Qwen3, Llama or Gemma families; embeddings such as BGE-M3 or multilingual-e5; Whisper-class ASR; reranker (bge-reranker).
  • Serving: vLLM or Ollama; Qdrant/pgvector; Rasa or custom agent code for deterministic flows.
  • Hardware: HW2 handles a 14–30B quantised model for a hotel group's traffic; HW3 for a larger model plus voice.
  • Choose C when: data sovereignty, public-sector tourism bodies, or very high volumes.

Path D — Custom training

Rarely required. Fine-tune a small model for brand tone, intent routing or dialect/language coverage using a few thousand anonymised, approved conversations; retrieval handles factual content.

State of the art (2026)

  • Agentic concierge: LLMs with tool calling now complete lookups and simple changes end to end; PMS and OTA vendors ship native messaging AI (e.g. Mews, October 2026) [1].
  • Messaging-first: WhatsApp and OTA inboxes are the primary channels; voice agents add phone and in-room use.
  • Limits and failure modes: hallucinated policies or prices, outdated knowledge base, over-promising (the Air Canada case shows the operator owns what the bot says [2]), prompt injection through guest-written text, mistranslation of legal terms, weak handling of upset guests, and rate/availability data lag. Mitigate with grounding, answer-only-from-sources rules, tool-side validation and mandatory handover triggers.
  • Evaluation: test sets of real past guest questions per language, with policy-compliance checks.

Shared resources & combinations

  • Same stack (llm-general + vector-db + guardrails + workflow-automation): CONV-001 customer service chatbot, CONV-003 booking assistant, CONV-005/006 sales and commerce, CONV-007 agent assist.
  • Voice: CONV-002 inbound voicebot shares ASR/TTS and telephony infrastructure.
  • Adjacent: PERS-003 (traveller-side planning), AGENT-010 (corporate travel booking), PRED-022 (no-show prediction and overbooking), CONV-018 (avatar kiosks at reception).
  • One self-hosted LLM server can serve concierge, review-response and internal staff assistants.

Effort, cost & KPIs

  • Path A: days to weeks; subscription per property, often plus per-conversation or per-message channel fees (WhatsApp).
  • Path B: 2–4 months incl. PMS integration; costs are model tokens, messaging fees, hosting.
  • Path C: 3–6 months plus GPU and operations.
  • KPIs: automated-resolution rate, handover rate and quality, first-response time, CSAT/review scores, direct-booking conversion, upsell revenue per stay, policy-error rate from audits.

People & change

Involve the owner or general manager for the decision, the front-office and housekeeping leads who know the guest questions, and the staff who will answer escalations. Add IT or the PMS vendor for integration and the data protection officer (external for most small hotels) for the AVV under Art. 28 GDPR; guest data is personal data, and a DPIA is normally not required for a plain FAQ bot but is advisable if profiles or preferences are stored. Works council: depends. Only hotels with an elected works council are affected; if the bot logs which employee handled which escalation or measures response times, it is suited to monitor performance and §87(1) no. 6 BetrVG applies, and §90(1) no. 3 requires early information when work processes change. Agree a short works agreement, with the expert allowed under §80(3) if needed.

AI literacy: under Art. 4 AI Act, take measures to support staff literacy; a one-hour session on what the bot can and cannot do is enough to start. Disclose the AI to guests (Art. 50, applicable since 2 August 2026). Pilot at one property or on one channel such as the website chat, and calm fears of replaced jobs by showing that the bot takes over repetitive questions at night while staff keep personal service. Staff can always take over a conversation. See GUIDE-008, GUIDE-006 and GUIDE-005.

Risks, regulation & compliance

  • EU AI Act: typically limited risk. Art. 50(1) requires telling people they interact with an AI system unless obvious; this applied from 2 August 2026 and was not postponed by the Digital Omnibus (which moved Annex III high-risk duties and the grace period for marking synthetic content) [3][4]. Avoid Art. 5 practices, e.g. manipulative techniques or exploiting vulnerabilities in upselling, and emotion inference from voice for staff monitoring. AI literacy (Art. 4) applies to staff.
  • GDPR: guest names, contact data, stay details, passport/ID data, special requests (health, diet, religion can reveal special-category data, Art. 9). Needs a legal basis, DPA with vendors, retention limits, data minimisation, transfer safeguards (WhatsApp/Meta, US model providers), and no use of guest chats for model training without basis.
  • Consumer and travel law: wrong binding information can create liability [2]; EU Package Travel Directive and passenger-rights rules (e.g. Regulation 261/2004) set information and refund duties that the bot must not contradict. ePrivacy rules for outbound messages and consent for marketing.
  • Security: prompt injection, payment data (PCI DSS: never take card numbers in free chat; use hosted payment links).
  • Mitigations: grounded answers only, action limits, disclosure of AI, easy human contact, logging, regular audits.

Getting started

  1. Collect the top 100 guest questions per language and the policies behind them; clean the knowledge base.
  2. Start with draft-only mode on your PMS-native or messaging tool; measure acceptance.
  3. Enable autonomous answers for low-risk intents (FAQ, directions), keep refunds and complaints human.
  4. Add AI disclosure, DPA, retention settings and handover rules before going live.
  5. Review transcripts weekly, fix knowledge gaps, then add booking changes and upsell.

Sources

  1. Mews — Guest Messaging and Automations launch (2026) — https://www.mews.com/en/press/mews-launches-guest-messaging-automations
  2. AI Incident Database — Air Canada chatbot case (Moffatt v. Air Canada, 2024 BCCRT 149) — https://incidentdatabase.ai/reports/3673/
  3. Regulation (EU) 2024/1689 (AI Act), Art. 50 — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  4. Dastra — AI Act transparency rules, 2 August 2026 — https://www.dastra.eu/en/blog/ai-act-transparency-rules-what-changes-august-2-2026/60164
  5. FEDIL — AI Act update, Digital Omnibus timeline — https://fedil.lu/en/publications/ai-act-update-enforcement-begins-as-the-digital-omnibus-reshapes-the-timeline/
  6. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj