PETER / LONG-STAY

連泊割 判定カルテ — Booking.com / 京都から

Peter が連泊割を設計しました。実測は有効予約2,114件・Booking.com 673件(2026-07-30)。要判断は2件、追認3件、報告2件です。外部配信かつ金銭に直結するので、要判断2件は推奨をプリセットしていません。明示回答をいただくまで実行しません。

要判断 4追認 34
この施策の発端: 京都のディレクション「3泊してゆっくりし、ここを拠点に京都の全てを楽しむ」に対して、Peter のランク表には滞在の長さという次元が無く、連泊施策を1件も提案できなかった(`pricing_rules.md` §6 の TBD)。それを埋めるのが今回です。 最初に共有したい発見が1つ。連泊割のコストは値引き率ではなく「既にその泊数で泊まっている客に、何もせず値引きを配る額」です。だから 既に連泊が取れているところほど、連泊割は割に合わない。 これが2つの結論を生みました。①Booking.com 優先というご指示はデータ的に正しい(全673件中3泊以上は6.5%=1泊チャネル=漏出が最小)。②一方で 京都は全施設の中で連泊割が最も効きにくい(Booking.com 34件のうち13件が既に3泊以上)。 京都から始めること自体はディレクションどおりに設計しています。ただ「京都は実利より型づくり」という位置づけになる、という点だけ先にお伝えします。

要判断4 件

Otakeさんにしか答えが無いものだけ。ここをお願いします。

Q1

京都の連泊割を、どの閾値・どの幅で出すか要判断

外部配信・金銭/撤退は即時可

器は「ベーシックセール+最低宿泊数」。これは Portfolio カテゴリで、既存の早期予約割引12%・直前割引15%と同じ枠を奪い合います。カテゴリ内は最大1つしか適用されないので、既存より低い率だと一度も効きません。京都のリードタイム中央値は 3泊=29日 / 4泊=137日 / 5泊=77.5日。

無回答なら 回答がなければ実行しません。Step 0〜2(読み取り調査と現況実測)だけ進めて、設計値は保留にします。

Q2

同時にどこまで広げるか要判断

外部配信・金銭/施設ごとに撤退可

館山・九十九里・南葉山は Booking.com の既存3泊以上予約が0件なので、**値引きコストが構造的に発生しません**(必要転換率0%)。1泊型施設に連泊需要があるかは未知ですが、コスト0で試せる枠です。手が届くのは同一グループアカウントの6施設のみ。

無回答なら 回答がなければ ① の範囲で設計だけ用意し、実行はしません。

Core 河口湖の Booking.com アカウントに心当たりはありますか要判断

連泊割の最大の買い場は Core 河口湖です(Booking.com 506件・¥28.7M・必要転換率10%・延泊候補113件)。ただし当グループアカウントには載っておらず、別アカウントで掲載されているようです。ここに手が届くと実利が一段変わります。

その他・気になったこと要判断

追認3 件

私が決めました。違うものだけ触ってください(無操作=この通り進めます)。

A1

実装場所は OTA側プロモーションのみ。会員ランク表は触らない追認

pricing_rules.md §6 で「OTA側か会員側か」が TBD のまま残っていた
提案Booking.com のプロモーションで実装する。SoT GSheet のランク表には滞在の長さという次元を足さない

推奨 ① この線でいい — ランク表の4行構造は絶対行番号で参照が結ばれており、列を足すと rate_sync・apply_verdicts・数式参照へ連鎖します。Booking.com が最低宿泊数付きプロモを持つのでOTA側で足り、②を今やる理由が見つかりませんでした。

無回答なら OTA側のみで進めます(会員価格は現状のまま)

A2

Airbnb には連泊割を出さない追認

実態Airbnb は全社で3泊以上比18.4%=既に連泊チャネル。必要転換率は 京都183% / 渋谷175% / ホテレジ京都404%
提案Airbnb は対象外にする。連泊は Booking.com で取りにいく

推奨 ① この線でいい — ②は取れている売上を自分で削る形になります。Airbnb で連泊を伸ばすなら値引きではなく掲載面(Brandon の領域)が筋です。

無回答なら Airbnb は対象外で進めます

A3

実行の前に Extranet の現物を1回だけ実測する追認

「ベーシックセールに最低宿泊数フィールドが実在するか」「最低割引率は何%か」は AirHost の公式仕様書では確認済みですが、Extranet の実画面は未実測です。本日は Otake さんの Vivaldi 側にセッションがあり、こちらからは未ログインで見られませんでした。

提案承認後、作成の直前に読み取りだけ1回入れる(ランブック Step 1)

推奨 ① この線でいい — ②は「設定したのに効かない」を作りがちです。過去に URL 推測で4つ空振りした前例があり、実測1回のコストのほうが安いと判断しました。

無回答なら 作成直前に実測を1回入れます

4 件

実装・反映済みの事後報告。読むだけで大丈夫です。

✓1

媒体横断の連泊割ナレッジを新設した

knowledge/ota/LONGSTAY_MATRIX.md ー 漏出の法則(判定式つき)/チャネル別の買い場判定/媒体別の実装能力マトリクス(Booking.com・Airbnb・一休・楽天・じゃらん)/施設別の必要転換率。Booking.com と Airbnb は AirHost からも設定でき、楽天・じゃらん・一休は同期不可で各社画面での手作業になります。

推奨 ① これでいい

✓2

Booking.com の実行ランブックを作った

knowledge/booking_com/LONGSTAY_RUNBOOK.md ー 到達可能な施設とhotel_id/Portfolio枠の競合の解き方/Extranet と AirHost の2経路/効果測定は売上でなく泊数構成で見る/撤退手順。承認が出たらこの手順どおりに動きます。

推奨 ① これでいい

✓0

昨日お聞きした「幅」の前提が変わりました(器がより良いものに)

7/29 は Booking.com の連泊手段を「週・月単位料金」と見ており、Targeting カテゴリでモバイル割引10%と競合するので10%超が必要、とお伝えしていました。今回それより良い器が見つかりました。週・月単位料金は 7泊/28泊 固定ですが、京都の Booking.com で7泊以上は実績1件しかなく、この器では実質何も動きません。「ベーシックセール+最低宿泊数」なら 0〜7泊で自由に閾値を置けます。カテゴリも Targeting → Portfolio に変わるので、競合相手はモバイル割引10%ではなく早期予約割引12%・直前割引15%になります。Q1 の選択肢はこの新しい器を前提にしています。

推奨 ① 了解

✓3

SoT 3本を更新した

pricing_rules.md §6(連泊割TBDに調査結果を追記)/ facility_direction.md §1京都(武器の現況・チャネル別の買い場・やらないことにAirbnbを追加・判断待ちを更新)/ ota・booking_com の各INDEXから新ファイルへの導線。

推奨 ① これでいい

回答テキスト(自動生成・差分だけ出ます)

下の枠内で Ctrl+A → Ctrl+C でコピー
コピーしました