概要
このページで整理していること
- Beds24連携は、予約情報を使う場面と、施設案内の正本を使う場面を分けて設計する。
- 予約情報があるだけでは、Wi-Fi、ゴミ出し、設備案内、ハウスルールの品質は安定しない。
- Hinoki ではQRガイドを主導線にしてから、必要な予約情報連携を後付けする順序を取りやすい。
Beds24連携を前提に、民泊・宿泊施設のゲストメッセージ自動化をどう設計するかを整理する公開ナレッジです。予約情報、FAQ、例外対応の責務を分けて説明します。
概要
ポイント
Beds24 は予約情報や宿泊期間に紐づく運用を扱ううえで重要です。予約者、宿泊日、物件、人数などを使うことで、送るべき案内や確認事項を切り替えやすくなります。
一方で、施設ごとのFAQ、設備説明、近隣ルール、ゴミ出し手順は予約管理とは別の正本が必要です。連携だけを先に入れても、回答内容が古いままだと問い合わせ削減にはつながりません。
ポイント
Beds24連携の前に、ゲストが現地で確認する情報を整理しておくと導入後の迷いが減ります。Wi-Fi、駐車場、チェックアウト、ゴミ出し、ハウスルールなどは、予約情報よりも施設ルールの正本管理が重要です。
Hinoki Concierge では、この正本をQRガイドとFAQに反映し、必要になった段階で Beds24 の予約情報を接続する考え方を取ります。
ポイント
Codex、Claude、OpenClaw などの外部エージェントを使うチームでは、運用者がHinokiの設定や案内内容を確認しながら改善する場面があります。
Hinoki Concierge MCP は、オーナーが発行したcredentialを使ってローカルMCPとして接続するため、予約管理システムを直接書き換える前に、Hinoki backend の承認済みcontrol planeを経由できます。
FAQ
不要にはなりません。Beds24は予約情報の連携に強く、FAQや施設ルールの正本管理は別に整える必要があります。
問題ありません。むしろ、現地でよく聞かれる情報を整理してから予約情報連携を入れる方が、導入範囲を判断しやすくなります。
初回のHinoki Concierge MCPは、Hinoki backendの制御面に接続するlocal MCPです。外部エージェントが無制限に外部システムへ直接操作する前提ではありません。