HospitaLink ChecklistLPへ戻る
導入前に、現場の詰まりを30分で見る。
商談・初回ヒアリング用。チェックが多いほど、Slackを入口にした運用整理・承認フロー・地域変数化の余地があります。
予約・OTA
予約情報が「誰かが見に行く」運用になっているかを確認します。
Airbnb / Booking.com / Beds24 / Hospitable など複数画面を毎日見ている
通知の集約余地あり
+2
新規予約・キャンセルのSlack通知が統一されていない
見落としリスク
+2
予約台帳が人によって違う場所にある
Sheets/DBの一本化候補
+3
ゲスト対応
自動返信ではなく、止めるべき返信が止まるかを確認します。
返信文が担当者の記憶に依存している
AI下書き・FAQ化候補
+2
返金・鍵・入室不可・事故・クレームの判断基準が曖昧
人間レビューゲート必須
+3
地域特有の質問が多い
雪道、温泉、駐車場、町家、台風、送迎など
+2
清掃・現場
清掃・点検・例外対応がログとして残るかを確認します。
清掃依頼が手入力/口頭/個別LINEに分散している
清掃通知とステータス化
+3
当日チェックイン・チェックアウトの例外がSlackに残らない
運用ログ化候補
+2
価格・売上
価格判断が「AI任せ」でも「人の勘だけ」でもない状態を作れるかを確認します。
空室が残った時の価格判断が属人的
価格アラート導入候補
+2
地域イベントや季節要因が価格ルールに反映されていない
地域変数化候補
+2
PriceLabs等の推奨価格をそのまま反映することに不安がある
承認キュー候補
+3
判定
0〜5点まず運用整理- 通知先と台帳を整理
- Slackチャンネル設計
- 手順書・担当者を明確化
6〜12点ライト診断向き- 現状フローを棚卸し
- 承認ポイントを定義
- 改善優先度をレポート
13点以上初期構築パッケージ向き- Slack OS構築
- 価格/返信のガードレール
- 月次改善まで設計
次に確認すること
運用ヒアリング
使用SaaS、予約経路、清掃連絡、価格調整、ゲスト返信の責任者を確認します。
リスク確認
価格・在庫・ゲスト返信・個人情報・外部送信は、人間承認を前提に設計します。
商談メモ: チェックが多い施設ほど「完全自動化」ではなく、「通知・承認・ログを整える」提案が刺さりやすい。