概要

このハブで先に整理すること

Collection
  • 購入後は、まずHinoki workspaceを有効化し、物件ごとのQRガイドとFAQ正本を整える。
  • Beds24 webhookは、QR導線と承認済み案内が固まったあとに予約連動が必要な範囲へ追加する。
  • 自動対応をONにする前に、テスト予約・変更・キャンセル・例外対応の動きを確認する。

公開ページ一覧

検索意図ごとの入口

ポイント

購入後の基本順序

Hinokiは、支払い直後にすべてを全自動化する前提ではありません。最初にworkspaceを発行し、物件情報、チェックイン案内、滞在中FAQ、ハウスルールを確認済みの情報として登録します。

そのうえで、室内QRガイドをゲストの主導線にし、必要な場合だけBeds24 webhookやMCP credentialを追加します。導入順序を分けることで、回答内容のぶれや誤った自動返信を避けやすくなります。

  • 1. Paid workspaceを有効化する
  • 2. 物件ごとの案内文とFAQ正本を登録する
  • 3. QRガイドを確認し、テストゲスト導線で見る
  • 4. 予約連動が必要な物件からBeds24 webhookを追加する
  • 5. 自動対応ON前に担当者の確認境界を決める

ポイント

Beds24 webhook導入の位置づけ

Beds24 webhookは、予約作成・変更・キャンセルなどのイベントをHinoki側へ知らせ、予約情報に応じた案内や確認を整えるための接続です。FAQや施設ルールの正本そのものを作る機能ではないため、先に案内内容を整理しておく必要があります。

Hinoki側では、webhookで受け取った予約情報を物件・workspaceに紐づけ、どの案内を出せるか、どの問い合わせを担当者へ渡すかを確認します。返金、補償、クレームなどの判断は自動化しない前提です。

  • 予約情報の受信
  • 物件・予約IDの対応付け
  • チェックイン/滞在中案内の条件分岐
  • 例外案件のDesk引き継ぎ

ポイント

公開前チェックで見ること

導入後すぐに本番の全予約へ広げるのではなく、まず対象物件を絞って受信ログ、案内内容、担当者通知を確認します。テスト予約、日程変更、人数変更、キャンセル相当のイベントを確認できると安全です。

Webhook secretやowner credentialは公開ページやゲスト向け資料に載せず、漏えい時は再発行します。Hinokiは、ゲストが見るQR導線と運営者が扱う設定導線を分けて運用する前提です。

  • テスト予約でイベント受信を確認
  • 予約変更時の物件/日付反映を確認
  • 失敗時の担当者通知を確認
  • secret・credentialの保管場所を限定