ダブルブッキング防止ガイド|小さな宿で起きる4つの原因と直し方
ゲストハウス・ホステル・民泊のダブルブッキングは、同期の遅れ、手入力の漏れ、在庫の持ち方、変更の反映漏れの4つが原因です。仕組みと防ぐ条件を解説します。
ダブルブッキングの原因は、ほぼ4つに収まります
小規模な宿のダブルブッキングは、スタッフの不注意というより、仕組みのすき間で起きることがほとんどです。原因は次の4つです。私たちが運営しながら見てきた、遭遇しやすい順に並べています(統計ではなく実感ベースの順番です)。
- カレンダー同期のタイムラグ:一方で売れた在庫が、他のサイトに反映される前にもう一度売れてしまう。
- 手入力の漏れ:電話・LINE・飛び込みの予約を、予約サイト側で閉め忘れる。
- 在庫の持ち方のずれ:ベッド単位で売るサイトと、部屋タイプ単位で売るサイトで、数え方が合わなくなる。
- 変更・キャンセル・部屋移動・ブロックの反映漏れ:予約後の「動き」が一部のサイトにしか伝わらない。
それぞれ、直すために必要なものが違います。「気をつける」ではなく、何を用意すれば止まるのかを順に説明します。
| 原因 | 起きる場面 | 直すために必要なこと |
|---|---|---|
| 同期のタイムラグ | 残り1室・1ベッドの日に、2つのサイトでほぼ同時に予約が入る | 接続方式の確認(iCalかAPIか)と、埋まりそうな日の在庫の絞り込み |
| 手入力の漏れ | 電話・直接予約・飛び込みの受付後 | すべての予約を一か所のカレンダーに入れる運用 |
| 在庫の持ち方のずれ | ドミトリーと個室を混在させて販売している | ベッド単位で持つ在庫と、サイトごとの登録単位の整理 |
| 変更の反映漏れ | 延泊、部屋移動、清掃・修理のための販売停止 | 変更も予約と同じ場所で行い、そこから各サイトへ流す |
原因1:同期のタイムラグ(いちばん誤解されやすい部分)
「同期しているのにダブルブッキングになった」という相談の多くは、ここが原因です。同期していることと、同期が瞬時であることは別のものです。
iCal(カレンダーURL)方式では、各予約サイトが一定の間隔でこちらのカレンダーを取りにいきます。その間隔を決めているのはサイト側で、宿側では変えられません。たとえばA社で最後の1室が売れても、B社が次に取りにくるまでの間は、B社上ではまだ空室のままです。この空白の間にB社で予約が入ると、ダブルブッキングになります。
API接続では、予約が入った時点でチャネルマネージャーが他のサイトへ在庫の更新を送るため、この空白はかなり短くなります。ただし「売れた瞬間」と「他のサイトの在庫が減る瞬間」の間に、ごくわずかなずれは残ります。残り1室の日に2つのサイトで同時に予約が入るケースは、どんな仕組みでも完全にゼロにはできません。
この原因への対処は次の2つです。
- 自分の宿がつないでいるサイトごとに、iCalなのかAPI接続なのかを確認する。
- 満室に近い日は、すべてのサイトに最後の1室を出さない。出すサイトを絞る、または少し余裕を残す。
民泊のように1軒貸しで代わりの部屋がない場合は、ずれの影響がそのまま重くなります。接続方式の確認は、まずここから始めてください。
原因2:手入力の漏れ
電話やLINEで受けた予約、直接予約、飛び込みのお客様。これらを予約サイトの管理画面に手で入れて在庫を閉める運用は、忙しい日ほど抜けます。サイトが3つあれば、閉める作業も3回必要です。1つ閉め忘れれば、その1つで売れます。
必要なのは注意力ではなく、入力先を一本化することです。すべての予約を先に一か所のカレンダーへ入れ、各サイトへはそこから流す形にします。サイトごとの管理画面を手で触る場面がなくなれば、閉め忘れも起きません。
原因3:在庫の持ち方のずれ
ドミトリーがある宿で起きやすい原因です。予約サイトによって、ベッド単位で売る形と、部屋タイプ単位で売る形があります。同じ4ベッドの部屋でも、サイトごとの登録方法が違うと、片方では「残り1」、もう片方では「残り0」といったずれが出ます。
さらに、個室とドミトリーを混在させている場合、個室を貸し切りにした日はそのドミトリーのベッド在庫も減らす必要があります。これを手作業で合わせていると、いつか崩れます。
直すには、まず自分の宿の在庫を最小単位(ベッド)で持つことです。そのうえで、各サイトへの登録単位を1回きちんと整理します。この整理は最初の1回で済みますが、飛ばすと後で必ず響きます。
原因4:変更・キャンセル・部屋移動・ブロックの反映漏れ
予約を取る瞬間は気をつけていても、その後の動きが漏れることがあります。
- 延泊:次の予約が入っている部屋で延泊を受けてしまう。
- 部屋移動:移動元の部屋が空いたのか、移動先が埋まったのかが、一部のサイトに伝わらない。
- ブロック:修理や清掃、オーナー利用で部屋を止めたのに、片方のサイトにしか入れていない。
- キャンセル:空いたことを反映しないだけなら機会損失で済みますが、手動で戻す際に別の日を誤って開けてしまう。
対処は原因2と同じ考え方です。変更も予約と同じカレンダー上で行い、そこから各サイトへ流します。「予約は一本化しているが、ブロックだけ各サイトで手入力」という運用は、意外と多く残っています。
自分の宿で確認する手順
- つないでいる予約サイトを書き出し、それぞれがiCalかAPI接続かを確認する。
- 電話・LINE・直接予約を、どこに入力しているか確認する。管理画面が複数なら、そこが穴になります。
- ドミトリーがあるなら、サイトごとの在庫の数え方を並べて比べる。
- 直近のダブルブッキングや危なかった件について、原因が上の4つのどれだったか振り返る。
4番は、自分の宿の記録で振り返るのが確実です。どの原因が多いかは宿ごとに違います。
Kimchee PMSでの考え方
Kimchee PMSは、釜山で自分たちの宿を運営している人間が作った、中小規模の宿向けのPMSです。ベッド単位のカレンダーで在庫を持ち、チャネルマネージャーは追加料金なしで含まれています。Channexを基盤に、490以上のチャネルに対応しています。Booking.com、Airbnb、Agoda、Expedia、Hostelworld、Trip.comなどが明示できるチャネルです。対応チャネルはチャネル一覧、機能の全体像は機能ページでご確認ください。
ここまでの4つの原因に当てはめると、予約・変更・ブロックを一つのカレンダーで扱うことが、原因2〜4への答えになります。原因1のタイムラグは、チャネルごとの接続方式に左右されます。「このサイトはどう接続されるのか」は、導入前に個別に確認してください。
料金は客室数で決まります。海外向けは月額60〜140米ドル(税込)で、機能はどの料金帯でも同じです。ドミトリーはベッド4つを客室1室として換算します。詳細は料金ページにあります。
なお、日本の予約サイトなど一部の連携は、現在まだ確定していません。対応の有無は、必ず事前にお問い合わせください。
まとめ
ダブルブッキングは「同期の遅れ」「手入力の漏れ」「在庫の持ち方」「変更の反映漏れ」の4つで説明がつきます。まずは、自分の宿がどの原因に当てはまるかを見てください。
接続方式や在庫の登録単位について相談したい方は、お問い合わせからご連絡ください。運営者の目線でお答えします。