Guest Communication

What you asked for

Centralise guest communication and cut the repetition. AI reads incoming messages, learns from your previous replies and property information, and prepares a suggested response for staff to approve. Corrections improve future suggestions. Then the loop into operations:

Guest reports AC issue
  → AI recognises maintenance issue
  → response suggested
  → maintenance task created
  → staff notified
  → completion recorded
  → guest update suggested

Human approval before anything is sent or actioned, for now.

This is the right priority and the loop above is the correct design. Almost none of it requires inventing new technology. Nearly all of the difficulty is in three specific places, which this chapter is mostly about.

What is actually possible

You cannot read Airbnb messages yourself

The single most important constraint in this entire handbook. Airbnb has no open messaging API. Guest messaging is available only through its restricted partner programme, granted to vetted PMS and channel-manager companies — not to individual operators, however many units they hold. Airbnb has been tightening this deliberately: it stopped distributing guest alias email addresses in 2023 specifically to force all host-guest contact through its own API-mediated thread.

The other channels vary:

So the architecture is settled by force: build the co-pilot on top of one certified PMS's unified inbox API, not on the OTAs. Guesty documents message webhooks; Hostaway documents an inbox and message endpoints. Every AI messaging vendor in this market — Hostaway AI, Guesty, Enso Connect, Besty, HostAI, Duve, Akia — sits on exactly these same gated connections. There is no clever route around it.

One thing that makes this less annoying than it sounds: OTAs enforce response-time SLAs, and response rate feeds Airbnb's Superhost status and search ranking. So a co-pilot that halves your median response time is not only a labour saving, it is a distribution improvement.

The market already contains what you described

Worth knowing before building, because in several cases you can buy the pattern:

• Hostaway AI drafts from conversation history, reservation and listing data, and its own documentation states that all suggested replies require human approval. Bundled into the PMS tier.
• Guesty runs a unified inbox across Airbnb, Vrbo, Booking.com, email, SMS and WhatsApp with AI-drafted replies and message webhooks on its Open API.
• Enso Connect (EnsoAI) is explicitly "instant drafts for your approval — review, tweak, send," translates to 20+ languages, and holds Airbnb partner status for live messaging.
• Besty AI is the most architecturally interesting: it autosends only when fully confident, drafts when not, and steps back automatically when a guest is unhappy. That three-way gate is the pattern you should copy whether or not you buy it.
• Duve splits it into named agents — SmartReply (draft or autosend, your choice), SmartPriority for triage — grounded in reservation data across 100+ languages.
• Breezeway Concierge is the one that already does your AC example: guest messaging tied to the operations graph, so a query can check whether a work order already exists, and messages can spawn tasks.

And the Japan-native side, which matters for tone and which the Western tools do not address:

• talkappi — the most credible Japanese hospitality AI vendor at scale (2,200+ properties), notable for selling a self-updating knowledge base product separately from the chatbot, explicitly positioned against "wrong answers" and "knowledge scattered across tools." Their architecture is the one to study.
• MOSVA (民泊おもてなしAI) — in-room QR chat, 15 languages, escalating anything it cannot answer to LINE for a human. A very lightweight version of your loop.
• AssistBnB — around ¥8,000/month, drafts a human-reviewed reply within 15 minutes, "learns once and doesn't forget."
• やどチャット — markets itself on "zero-incident design," i.e. guardrails first.
• BenStay AI Concierge — Claude-based, 8 languages, LINE integration, from roughly ¥30,000/month.

The consistent pattern in the Japanese products is escalation-to-human as the default safety net rather than confident autosend, and flat monthly pricing per property rather than per-listing tiers. That is a cultural read on risk tolerance, and it happens to match your stated preference exactly.

Build or buy

Recommendation: buy the inbox, build the co-pilot.

The inbox — connections, message sync, threading, delivery, retries — is undifferentiated plumbing that must be certified with each OTA. Take whatever your chosen PMS provides.

The co-pilot is where your competitive advantage lives, for a specific reason: the value is in the loop into operations, and no vendor's loop reaches into your task system, your inventory, your staff on LINE and your Japanese/Indonesian workflows. Breezeway comes closest and is English-only frontline. Buying a bolt-on AI replier gets you a faster typist. Building the co-pilot on your own spine gets you the AC scenario end to end.

A reasonable interim: switch on the PMS's own AI suggestions on day one (essentially free, immediately useful), while building the real co-pilot behind it. You lose nothing and you start collecting approval data early.

How it should be built

The knowledge layer — and why RAG, not fine-tuning

You asked for "learning." There are two ways to do it and only one is right here.

Retrieval-augmented generation with a curated answer library. Two corpora:

1. Property knowledge base — structured, versioned, per-listing facts: check-in and check-out times, access method, Wi-Fi name and password, appliance instructions, house rules, rubbish rules, nearest station and transit, luggage storage, parking, pet policy, noise ordinance specifics, emergency contacts. Structured fields, not prose blobs.
2. Answer library — staff-approved question/answer pairs and edited replies, tagged by intent, language and property type, growing continuously from corrections.

Fine-tuning is the wrong tool and it is worth being explicit about why, because it is the intuitive choice and it fails in this exact application. Fine-tuning bakes knowledge into weights. Your knowledge changes weekly — a door code rotates, a laundry closes, a rule changes — and at hundreds of units, weekly is optimistic. Fine-tuned knowledge goes stale silently and cannot be audited: you cannot point at why the model said something, which matters both for QA and for any later dispute. RAG lets you change one row and have every future reply reflect it instantly, and lets an ops manager — not an engineer — maintain the brain. This is precisely what talkappi is selling with its self-updating knowledge base, and it is the industry consensus for support systems: retrieval for knowledge, fine-tuning reserved at most for narrow style adaptation.

So: corrections do not retrain the model. They flow into the answer library after review. That is what "learning" means here, and it is better than retraining because it is inspectable and reversible.

The confidence gate

Three outcomes per incoming message, decided before a human sees anything:

                    ┌─────────────────────────┐
  incoming message  │  classify + retrieve    │
  ───────────────►  │  intent · language ·    │
                    │  sentiment · property   │
                    └───────────┬─────────────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        ▼                       ▼                       ▼
   AUTOSEND-ELIGIBLE       DRAFT FOR APPROVAL      ESCALATE NOW
   (disabled initially)                            
   routine · high          anything policy-,       refund · injury ·
   retrieval confidence    money-, or access-      police · "allergic" ·
   Wi-Fi · check-out       related; ambiguous;     sentiment collapse ·
   time · bins             low retrieval score     repeated unresolved

Everything starts in the middle column. That is your stated preference and it is correct. But build the gate now anyway, because the gate is what makes later autonomy a configuration change rather than a rewrite — and because the right-hand column earns its keep from day one. An angry guest reaching a human in ninety seconds instead of forty minutes is worth more than any draft.

Note what Besty does and copy it: step back automatically when the guest is unhappy. Sentiment is a circuit breaker, not a tone hint.

The three rules that prevent the disasters

These are not optional and they should be enforced in code, not in a prompt.

1. Door codes and access instructions are never generated. They are injected from reservation-bound structured data, validated for format, and gated on a reservation-ID match plus a stay-window check. A model that has "seen" a door code in a past conversation must never be able to reproduce it. This is the single highest-severity failure mode in short-term rentals — a code sent to the wrong guest or for the wrong dates — and it is entirely preventable by not letting the language model near the value.
2. Policy numbers are quoted, never paraphrased. Cancellation windows, fees, refund amounts, deposit values: pulled as literal strings from structured fields. The model composes the sentence around them; it never computes or recalls them.
3. No retrieval hit means no draft. If the knowledge base has no answer, the system escalates with "no source found" rather than producing a fluent guess. A refusal costs a staff member thirty seconds. A confident hallucination about a cancellation policy costs a refund and a review.

Japanese, English, Indonesian

Detect language per message, not per thread — travellers switch mid-conversation, and group bookings often have one Japanese speaker among foreign guests.

On keigo: models default to a generic 丁寧語 register that is usually fine for routine STR exchanges, but misjudge when the situation calls for 謙譲語 or 尊敬語 — apologies, refunds, safety incidents, anything an owner might be forwarded. Handle this structurally: maintain a small set of approved Japanese templates for high-stakes intents which the model selects and adapts rather than composing freely, and route those intents to human review regardless of confidence. Do the same for Indonesian, where general model quality is decent but politeness handling is much less battle-tested than Japanese or English.

Where uncertain, reply bilingually (JA + EN). Several vendors do this by default and it is a cheap safety measure.

The loop into operations

Your AC example, as it should actually run:

1. Guest (Airbnb, 23:41):  "エアコンが冷えません"
2. Classify: intent=maintenance · subtype=hvac · urgency=high (night, heat)
              language=ja · property=Osaka-04 · sentiment=negative-mild
3. Retrieve: unit history — "AC serviced 2026-01; filter replaced 2026-06"
             known issue? no open ticket
4. Prepare TWO artefacts, one approval:
     ├─ Draft reply (JA, apologetic register, no promised time)
     └─ Draft maintenance ticket: unit, symptom, guest photo,
        priority=high, suggested assignee (on-call), history attached
5. Ops approves once → message sends, ticket created, assignee
   pushed on LINE with the guest's photo attached
6. Technician marks resolved with a photo and a note
7. System prepares a follow-up message to the guest for approval:
   "対応が完了しました。ご不便をおかけし申し訳ございません。"
8. Every step written to the audit log against reservation + ticket

Two design points that matter more than they look:

• One approval, two artefacts. If approving the reply and creating the ticket are separate actions, staff will do one and forget the other, and you will have rebuilt your current problem with extra steps.
• Never promise a time the ops system has not committed to. The draft should say someone is being dispatched, and only state a window if the task system actually holds an assignment for that window. This is the most common way an automated reply creates a worse guest experience than silence.

The same structure covers cleaning requests, extra towels, missing amenities — each maps to an intent, a task template, and a follow-up. Towels are a task plus an inventory deduction; that is Chapter 4 wiring into the same loop.

The approval screen

The whole productivity gain lives in this screen, so it deserves specificity. Per pending item, one screen, keyboard-driven:

• The thread, with the incoming message highlighted, in its original language.
• The draft reply, editable in place.
• The retrieved sources shown as citations — which knowledge-base rows and which past replies produced this. Non-negotiable: it is how staff learn to trust it, and how they catch a stale door code before it goes out.
• Reservation context: guest name, dates, unit, nights remaining, channel.
• Any proposed side effects, listed plainly: "will create maintenance ticket," "will deduct 2 bath towels."
• Three keys: approve and send · edit and send · escalate. Nothing else. A staff member handling forty of these a morning should never touch a mouse.

Every edit is captured as a (draft, correction, context) triple. Those triples do two jobs: candidates for the answer library after review, and — more importantly — the evaluation set.

Evaluation, because otherwise you are guessing

Keep a fixed set of representative messages across JA/EN/ID and all major intents, with gold answers. Run it against every knowledge-base or prompt change before deploying. This is what stops a well-meaning knowledge edit from silently breaking twenty other answers.

Then measure, weekly:

• Approval rate — sent unedited vs edited vs discarded. The headline number.
• Edit distance on edited drafts. Falling edit distance is real learning; rising approval rate with rising edit distance is staff getting lazy.
• Median time to first response, per channel. The number OTAs care about.
• Escalation precision and recall — did the gate catch the angry guests, and how many false alarms.
• Hallucination incidents, counted manually from a sampled review. Sample autosent messages too, if you ever enable autosend; the approval queue is not where the risk lives once the gate is trusted.

Target for a realistic go/no-go on any autonomy: sustained approval-without-edit above roughly 85% on a specific intent, over a few thousand messages, with zero hallucination incidents in that intent. Then autosend that intent only. Never autosend a category, always an intent.

Privacy and APPI — the part vendors do not discuss

Guest messages contain personal data, and sometimes a lot of it: names, phone numbers, and at check-in occasionally passport details. Japan's Personal Information Protection Commission issued formal guidance in 2023 cautioning organisations about entering personal information into generative AI services, and it remains operative. This is an active compliance area, not a theoretical one, and none of the vendors surveyed make strong specific claims about Japan-compliant data handling. Make it a written procurement question.

Concretely, for your build:

• Redact before prompting. Strip and tokenise names, phone numbers, ID numbers and payment references before the message reaches a model. The model rarely needs them to draft a reply about bin day.
• Never send identity documents to a model. Ever, for any reason.
• Contract for no-training and appropriate data-processing terms. Enterprise tiers of the major providers offer this; default and consumer tiers typically do not.
• Treat overseas-hosted inference as a cross-border transfer under APPI, and satisfy it properly — adequacy, contractual safeguards, or consent depending on the data class.
• Keep the compliance-grade guest register in a separate, access-controlled store from the operational messaging pipeline. This matters twice: it limits blast radius, and it makes the statutory register cleanly exportable for the 宿泊者名簿 obligation and inspection. Chapter 7 covers this boundary.

OTA messaging policy

Airbnb, Booking.com and Expedia all restrict promotional and spammy content inside reservation messaging, and bulk templated messages that read as non-personalised marketing are a specific risk category. Several vendors in this space push in-message upselling hard. Tread carefully there: the policies change, are not fully public, and enforcement lands on your account, not the vendor's. Verify directly with each channel before shipping any upsell messaging, and keep operational replies and marketing strictly separated.

Effort and risk

Effort: high — this is the largest build in the handbook and the one that most rewards patience. The inbox integration is a week. The knowledge base structure is a week of engineering and a month of someone actually writing the property facts down, which is the real critical path and should start immediately. The gate, the approval screen and the evaluation harness are where the quality lives; budget more than you think for the screen, because a co-pilot that takes four clicks per message saves nobody anything.

Risk: the highest in the handbook, and concentrated in three places. Door codes (solved by never generating them). Hallucinated policy (solved by quoting, and by refusing without retrieval). PII into models (solved by redaction and contracts). Every other risk here is an inconvenience.

Decisions for you

1. Which PMS provides the inbox? This is really the Chapter 5 decision, and guest messaging is the reason it is urgent. Airbnb message access is the gating requirement.
2. Start the property knowledge base this month. Independent of every other decision. One structured document per unit. This is the critical path and it needs a person, not an engineer.
3. Export your message history now. Your archive of past replies is the most valuable proprietary asset in this plan and some channels do not retain it indefinitely.
4. Who approves, and during what hours? A 23:41 AC complaint is only solved fast if someone is on the queue. Decide whether approval follows the sun (Bali covering Japan's night, and vice versa) — with two regions this is a genuine structural advantage.
5. Do you want talkappi or a Japanese vendor in the mix for native-grade Japanese tone, alongside your own co-pilot? Worth a conversation with them regardless, as a benchmark.
6. Agoda: accept manual. Confirm you are content for Agoda messages to stay a human, extranet-based workflow. Automating it means browser automation against their terms, which is not a recommendation this handbook will make.