民泊の直接予約。自社サイトを作る前に決める運用

OTAと直接予約を、手元に残る額で比べる

OTA手数料と、直接予約の決済手数料だけを比べると、集客や運用にかかる費用が抜けます。Guestyの直接予約機能もOTAコミッションの削減を訴求しますが、決済処理の費用には触れています。自社では、サービスの見積もりと現在の明細を使って、経路ごとに残る額を見ます。

まず、同じ施設・比較期間の販売額と、販売・決済手数料を揃えます。OTAの明細に決済費用が含まれているなら二重に引かず、別契約ならその費用も含めます。清掃費などを販売額へ含めるかも、両経路で統一します。

そのうえで、直接予約のために増える費用を見積もります。

• 検索・広告・SNS等から予約へつなぐ集客費。
• サイト制作・保守と、予約システムの初期・継続費用。
• 支払い、変更・取消、問い合わせへ対応する人の費用。

過去に泊まった人が自発的に施設名で探す場合と、広告で新規客を集める場合では、集客費の前提が違います。予約が入らない月にも続く費用と、予約ごとに増える費用を分けて比べます。これらを引いた残額も、清掃や施設維持などの共通経費を引く前なら、最終的な利益とは区別します。

サイト、予約エンジン、在庫管理をつなぐ

自社サイトは施設を説明する入口、予約エンジンは日程・人数・料金を確定して申込みを受ける仕組みです。その先で、OTAを含む販売在庫を揃える必要があります。

Guestyの直接予約機能は、サイト、予約エンジン、手動予約と在庫の連携を説明しています。Beds24販売元の基本操作ガイドでも、在庫や売止め、集金の設定を扱っています。機能が別々に使えることと、自施設で一続きに動くことは分けて確かめます。

試すのは、予約の成立だけではありません。人数変更、日程変更、取消、決済失敗の後に、販売できる在庫がどうなるかを見ます。問い合わせフォームを置く方式なら、誰がいつ在庫を確保し、確定を返すかを決めます。詳しい在庫の選定は民泊管理システム、重複が起きた際はダブルブッキング対応を参照してください。

決済と取消の窓口を、公開前に用意する

直接予約では、自社が案内する利用条件、支払方法、変更・取消の手続、返金の連絡先を揃えます。OTAの条件や補償が、自社予約にもそのまま付くと説明しないようにします。

決済は、正規の決済サービス等へつなぎます。カード番号を一般の問い合わせフォームやメールで集める方法を作る必要はありません。支払結果が予約へ届かなかった場合に、誰が何を確認するかまで試します。

結果が分からない場合は、予約番号と決済サービス側の取引記録を照合します。予約画面に反映されていないだけか、支払い自体が失敗したかを確かめてから、ゲストへ再手続きや確定の案内を返します。「確認メールが届かない」という問い合わせだけで、もう一度支払ってもらう処理に進めないようにします。

試す場面	確かめること
申込中に支払いが失敗	予約・在庫・再試行の状態が分かるか
予約後に日程を変える	差額と在庫の変更、相手の同意を揃えられるか
全部または一部を取消す	適用する条件、返金、在庫解放がつながるか
担当不在時の問い合わせ	予約番号から状況を追い、次の担当へ渡せるか

集客から滞在後まで、一つの予約で試す

施設名で調べた人、過去に泊まった人、地域情報から来た人では、必要な説明が違います。初めて来る人には施設・周辺環境・利用条件を、再利用する人にも前回から変わった設備や料金条件を示します。どの入口から来たか、どの質問で予約が止まったかを記録し、予約前の案内を直します。

OTA経由の問い合わせと外部への勧誘

Airbnbの料金設定と支払いの方針は、現在・将来・リピートの予約の支払いをプラットフォーム上で行うことを求め、外部予約への勧誘、外部予約を条件にした割引、既存予約を取り消して外で取り直す行為などを禁じています。「宿泊後なら直接予約へ誘ってよい」とは扱いません。

自社の検索・広告・SNS等から来る経路を用意することと、OTAで届いた問い合わせや予約を外へ移すことを分けます。過去のゲスト自身から自社へ申込みが来た場合も、事業者側からOTA外へ誘導した案件とは分けて記録します。再利用という属性だけで同じ経路と扱わず、誰がどこから申し込み、どの案内を経たかを確かめます。この記録を付けただけで、受け付けてよいと判断できるわけではありません。個別の経緯を現在の契約・規約に照らし、判断がつかない場合は、その予約サイト等の窓口へ確認します。他の予約サイトも、そのサイトの契約・規約で確認します。

直接予約の運用確認表（CSV）で、流入、案内、申込み、決済、在庫、到着前の連絡、取消の結果を一件ずつ試せます。訪問数だけで判断せず、予約に進まなかった疑問、確定後に必要だった連絡も見ます。

開始する範囲を、試した結果から決める

「予約できた」だけで開始を決めず、試験に使った施設・日程・経路と、次の結果を残します。

項目	開始前の確認
予約成立	日程・人数・料金・条件と、相手に届いた確定通知
在庫の反映	自社と対象OTAでの実表示、変更・取消後の結果
支払い	予約と決済・返金取引の一致、結果不明時の照会先と実行担当
引継ぎ	担当不在時にも参照できる記録と、次に連絡する人

在庫の不一致、二重請求の疑い、条件の未確定など、ゲストの予約に影響する不明点があれば、担当と再確認の予定を決めて解消します。確認できた施設・経路を開始範囲とし、別のOTAや施設まで一律に動作確認済みとは扱いません。集客費と対応時間も実際の記録から見直し、運用できる範囲で広げます。

テマトクには、予約前の質問や滞在中の連絡を含め、運営者が決めた条件を案内し、確認が必要な用件を担当へつなぐ分担を相談できます。導入時に任せる仕事を決める際に、サイトから一件の対応を通して見直してください。