HospitaLink ChecklistLPへ戻る
導入前に、現場の詰まりを30分で見る。
商談・初回ヒアリング用。チェックが多いほど、Slackを入口にした運用整理・承認フロー・地域変数化の余地があります。
予約・OTA
予約情報が「誰かが見に行く」運用になっているかを確認します。
Airbnb / Booking.com / Beds24 / AirHost など複数画面を毎日見ている
通知の集約余地あり
+2
新規予約・キャンセルのSlack通知が統一されていない
見落としリスク
+2
予約台帳が人によって違う場所にある
Sheets/DBの一本化候補
+3
ゲスト対応
自動返信ではなく、止めるべき返信が止まるかを確認します。
返信文が担当者の記憶に依存している
AI下書き・FAQ化候補
+2
返金・鍵・入室不可・事故・クレームの判断基準が曖昧
人間レビューゲート必須
+3
地域特有の質問が多い
雪道、温泉、駐車場、町家、台風、送迎など
+2
清掃・現場
清掃・点検・例外対応がログとして残るかを確認します。
清掃依頼が手入力/口頭/個別LINEに分散している
清掃通知とステータス化
+3
当日チェックイン・チェックアウトの例外がSlackに残らない
運用ログ化候補
+2
価格・売上
価格判断が「AI任せ」でも「人の勘だけ」でもない状態を作れるかを確認します。
空室が残った時の価格判断が属人的
価格アラート導入候補
+2
地域イベントや季節要因が価格ルールに反映されていない
地域変数化候補
+2
ねっぱん等の推奨価格をそのまま反映することに不安がある
承認キュー候補
+3
請求・領収証・宿泊税
売上後処理や税区分が手作業で残っていないかを確認します。
領収証・請求書の発行依頼がメールやDMで個別対応になっている
発行フロー・テンプレート化候補
+2
インボイス登録番号、宛名、但し書き、消費税区分の確認が毎回手作業
国税庁・インボイス対応支援候補
+3
地域ごとの宿泊税・入湯税・免税条件を都度確認している
地方別宿泊税の自動算出候補
+3
宿泊者名簿・個人情報
必要な情報を集めつつ、Slackや資料に出しすぎていないかを確認します。
宿泊者名簿が紙、フォーム、OTA画面、スプレッドシートに分散している
電子管理・保存期間設計候補
+3
氏名、住所、連絡先、予約ID、鍵情報がSlackにそのまま流れることがある
マスキング・通知要約が必要
+3
退去後や解約時のデータ削除ルールが決まっていない
保持期間・削除SOP候補
+2
レビュー・改善サイクル
レビューを「読むだけ」で終わらせず、改善タスクに戻せているかを確認します。
低評価レビューの原因が、清掃・設備・案内文のどこにあるか集計できていない
レビュー資産化・改善提案候補
+2
地域特有の不満キーワードが返信テンプレや事前案内に反映されていない
地域別レビュー改善候補
+2
レビュー改善の担当者・期日・効果確認がSlack上で追えない
改善タスク・月次レポート化候補
+2
CRM・顧客関係管理
宿泊後の関係を、再訪・紹介・法人利用につなげる準備があるかを確認します。
OTA宿泊者と公式予約者の関係履歴が分かれておらず、再訪候補を把握できない
宿泊履歴・顧客タグ設計候補
+2
LINE/メール登録、配信同意、配信停止、削除依頼のルールが曖昧
同意管理・停止導線の設計が必要
+3
リピーター、法人、紹介、長期滞在などのセグメント別施策を出せていない
CRM配信・再訪導線候補
+2
レビュー、アンケート、再訪案内がバラバラで、改善施策に戻っていない
レビュー資産化とCRM連携候補
+2
判定
0〜8点まず運用整理- 通知先と台帳を整理
- Slackチャンネル設計
- 手順書・担当者を明確化
9〜18点ライト診断向き- 現状フローを棚卸し
- 承認ポイントを定義
- 改善優先度をレポート
19点以上初期構築パッケージ向き- Slack OS構築
- 価格/返信/請求のガードレール
- 月次改善まで設計
次に確認すること
運用ヒアリング
使用SaaS、予約経路、清掃連絡、価格調整、ゲスト返信の責任者を確認します。
リスク確認
価格・在庫・ゲスト返信・個人情報・外部送信は、人間承認を前提に設計します。
商談メモ: チェックが多い施設ほど「完全自動化」ではなく、「通知・承認・ログを整える」提案が刺さりやすい。