まず30秒。これだけ読めばOK
「割引を束ねて40%」は、実際には40%にならない。
だから“検証する仕組み”が要る。
- Booking.comの割引は単純に足し算で重ならない。原則“最も深い1つ”＋Geniusが別途。複数束ね ≠ 合計%
- ＝「単体40% vs 束ねて40%」は手取り・見え方が変わる。勘ではなく数字で出すのがこのシステム。
- 中身は3モジュール：①組み合わせ検証ツール ②プラン一元カタログ ③隔週の効果検証（季節補正つき）。
- ①は手持ちデータで今すぐ着手可。まず①で実証 → ②③へ拡張（段階導入）。
↓ 各モジュールの中身・データ根拠・進め方・正直な限界はこの下にスクロール
▼ ここから下が中身（じっくり読みたい人向け）
1結論：何を作るか（3モジュール）
経営からの要求を、実現できる単位に分解。1個の巨大システムを一括ではなく、価値の出る順に段階構築する。
| 要求（依頼ブリーフ） | 形にするもの | いつ |
|---|
①割引の組み合わせ検証
（単体40% vs 複数束ね40%） | 組み合わせ検証ツール（入力＝プラン構成／出力＝実質ゲスト価格・手数料後の手取り・損益分岐・解放される露出） | 今すぐ可 |
| ②各種割引の一元管理 | プラン・カタログ（各割引の幅・解放フィルタ/バッジ・併用ルール・施設別ON/OFF・改定履歴を常時更新） | 雛形可・運用要 |
| ③隔週のアクセス・予約検証＋季節要因 | 隔週レポート＋季節指数（AirHost予約＋各施設アナリティクスPDFを投入、月別シーズン補正つき） | データ供給前提 |
2大前提：割引は“足し算で重ならない”
このシステムの存在理由。Booking.comの割引は原則「最も深い1つが適用」＋Geniusは常時別途、一部は順次計算（足し算ではない）。
つまり「5プラン束ねて合計40%」と設定しても、ゲストに出るのは40%にならないことが多い。
だからこそ：「単体で深い1本＋Genius＋露出系を1枚」と「中途半端な束ね」では、
同じ“見かけ40%”でも手取りも検索露出も別物。これを毎回数字で判定するのがモジュール①。
（正確な併用可否は構築時にBooking.com公式の最新併用ルールで確定する。）
3モジュール①：割引組み合わせ検証ツール
自社の最初の本命。インタラクティブな1画面ツール（既存の民泊シミュレーターと同じ作り方）。
入力
基本料金／適用するプラン（Genius L1・L2・L3、モバイル料金、早期割、直前割、連泊割、季節キャンペーン、返金不可の値引き分 など）／施設・想定リードタイム
出力（自動計算）
| 出す数字 | 確度 |
|---|
| 実際にゲストに表示される実質割引％・価格（Booking.com併用ルール反映） | 厳密 |
| 手数料控除後の1予約あたり手取り・損益分岐 | 厳密 |
| 「単体40% vs 束ねて40%」の手取り差・解放される検索フィルタ/バッジの差 | 厳密（価格） |
| 予約数がどう動くか（増減） | レンジ（弾力性＝外部前提） |
正直な限界：価格・手取り・損益は厳密に出せる。一方「どちらが“予約が増える”か」は弾力性の前提が要るので、
断定でなくレンジ＋前提明示で出す（過去の効果予測と同じ流儀）。
4モジュール②：プラン一元カタログ
「Booking.com等が頻繁に出す割引を常に一元管理」への答え。常時更新する1枚の管理表。
| 管理する項目 | 例 |
|---|
| 割引の種類と幅 | Genius L1/L2/L3、モバイル、早期割、直前割、連泊割、季節キャンペーン、返金不可 … |
| 解放される露出 | そのプランで点くフィルタ/バッジ（検索で見られる経路） |
| 併用ルール | 足し算か順次か・Geniusとの関係・排他か |
| 施設別 ON/OFF | 8施設それぞれの現在設定 |
| 改定履歴 | Booking.comの仕様変更・新プラン追加の日付 |
体制：雛形は作れる。運用＝OTA担当が更新（仕様変更を見たら追記）。①のツールはこのカタログの数値を参照して計算する設計。
5モジュール③：隔週の効果検証＋季節要因
「1〜2週単位でアクセス・予約を検証、シーズン要因も組み込む」への答え。
データ源
| データ | 取得元 | 状態 |
|---|
| 予約・キャンセル・実現売上・リードタイム | AirHost 予約エクスポート | 取得済の方式 |
| 表示回数・閲覧・転換（アクセス数） | 各施設アナリティクス・ダッシュボードのPDF（隔週で書き出し） | 隔週PDF供給 |
| 季節指数（月別の需要補正） | 2025年実データから算出（保有済） | 算出可 |
回し方（隔週ループ）
仮説（どのプラン構成にするか）→ 1〜2週運用 → アナリティクスPDF＋AirHostを突合 → 季節補正してから「表示・閲覧・予約・転換・手取り」を評価 → 効きを①ツールに反映（モデル較正）→ 次の構成へ。
季節要因の扱い：「先月比で予約が落ちた」を鵜呑みにせず、月別の季節指数で割り戻して“施策の効果”と“季節の効果”を分離する。これが無いと判断を誤る。
6進め方（段階導入）
- モジュール①ツールを構築（手持ちデータで着手可）。「単体40% vs 束ね40%」を即数字化 → 効果を実証。
- ②カタログ雛形を①に接続（ツールがカタログ値を参照）。OTA担当の更新運用を開始。
- ③隔週レポートを稼働（アナリティクスPDFの供給開始後）。季節指数を組み込み較正ループを回す。
- ①②③連動：カタログ更新→ツール再計算→隔週検証→較正、の定例化。
狙い：勘と惰性で割引を盛る運用から、「どの見せ方が手取りと予約を最大化するか」を毎回数字で決める運用へ。最初の①だけでも意思決定の質が変わる。
7正直な限界・前提（先に明示）
- 厳密にできる：割引の併用反映・実質価格・手数料後手取り・損益分岐（自社条件＋公式併用ルールから計算）。
- レンジでしか出せない：「どの構成が予約を増やすか」は弾力性＝外部前提。断定せずレンジ＋前提明示。隔週検証（③）で実測較正して精度を上げる設計。
- ③の前提：表示回数等のアクセスデータはAirHostに無く、各施設アナリティクスPDFの隔週供給が必須。供給が止まると③は予約データのみの簡易版に縮退。
- 仕様変更リスク：Booking.com併用ルールは改定されうる。②カタログの改定履歴で追従する前提。構築時に公式最新ルールで確定。