ホテルコンサルタントの堀口です。
ホテル・旅館関係者を震え上がらせた「事故」が起きました。
大型連休期間に、200室程度の仙台のホテルで4000件を超える宿泊予約を受け付けてしまったというのです。
この事故は人気グループ「嵐」のコンサートで宿泊需要が爆発したためと報道されたこともあり、一般の方にも広く注目を集めたようです。
しかし、宿泊業界を震え上がらせたのは、事故の原因が「予約システム障害」と報道されたことでしょう。「システム障害」であれば、同じシステムを使っているホテル・旅館でも同じ事件が起きかねないからです。
現時点では原因は公表されていませんが、その一つと考えられる「サイトコントローラーの特性」を踏まえて対応策を取っていただき、同様の事故が起きないようにしていただきたいというのが本コラムの意図です。
考えられる事故の原因
まず、事故の原因と考えられるものをいくつか挙げてみましょう。
- システムの設計ミス
- サイトコントローラーの特性の問題
- 人為的ミス
1. システム設計のミスか？
システム設計のミスを理由に挙げる方は「排他制御」が不十分であったと考えているようです。
排他制御を簡単に説明すると「誰かが予約しようとしている間は他の人が予約できないようにする」仕組みのことです。詳しくは以下の検証ページが参考になるでしょう。
2. サイトコントローラーの特性の問題か？
サイトコントローラー（以下SC）とは、複数のインターネット予約サイトの料金・在庫を一括で管理するサービスで、これにより管理が劇的に効率化されました。
なにせ、以前は「10数室あるから、Aサイトに3室、Bサイトに3室、自社サイトに4室登録しよう」なんて風に数のバランスを考えて、3回設定する必要があったのですが、SC登場後は「10室をSCに登録しよう」と1回の手間ですむようになりました。
在庫の割り振りを考える手間や、実際に在庫を設定する手間が省かれたうえ、販売機会も拡大するのですから宿泊業界の方にとっては非常にありがたいサービスです。
SCは「在庫を各サイトに配布し、予約サイトから予約が入ると、各予約サイトの在庫を最新のものに書き換える」という動きをします。この機能を「在庫連動」と言います。SCの考慮すべき特性とは、「
予約サイトでの予約発生から他サイトの在庫情報が更新されるまでの仕組みと所要時間」です。
予約サイトが予約を受け付けたかどうかを、SCが知る方法は大きく2つあります。
- API方式
- 巡回方式
API方式とは、予約サイト自身が予約を受け付けたことをSCに通知する仕組みで、ほぼリアルタイムな処理ができます。
巡回方式とは、SC自身が一定の間隔で各予約サイトを回り予約があるかを確認する方法で、巡回間隔分リアルタイムとは言い難いでしょう。
そうするとAPI方式のほうが優れていると言えますが、SCの会社と各予約サイトの協力が必要になりますし、すべてのSC・すべての予約サイトがこれに対応している訳ではありません。
これらの要因を踏まえると、くだんのホテルが巡回型のSCを使っていた場合、巡回時間の間隔分はダブルブッキングの可能性があるということになります。
3. 人為的ミスなのか？
どのようなシステムも最終的には人が操作するものですから、人為的ミスの可能性は否定しきれません。
同様の事故を防ぐには
さて、今回のコラムは原因を追求することではなく同様の事故を防ぐのが目的ですので、予想される原因への対策を考えたいと思います。
1. システムの設計ミスが原因の場合
主に自社予約システムが対象になり、「排他制御」に関する同様の問題が起きないかどうか、システム会社に問い合わせしていただくことをお薦めします。
2. サイトコントローラーの特性が原因の場合
自社で使用しているSCの予約情報取得方式と、予約情報を受け取ってから各サイトに在庫共有されるまでの所要時間をシステム会社に確認していただくことをお勧めします。
ただし、在庫共有までの所要時間が短いシステムは月額利用料が高めのこともありますので、費用対効果を考えてSCを選ぶ方が良いでしょう。
また、SCに「在庫をどの程度提供するか」を検討する必要があります。
過去には「登録された在庫数順に表示される」OTAがあったため、在庫数を"999"と登録しているホテルがありました。これでは予約が集中すれば簡単にオーバーブックしてしまいます。
「コンサートやマラソン大会などの大型の需要（特需）の時だけ気をつければ良い」という考えもありますが、怖いのは例外的に開催されるイベントなどをホテル側は把握しにくい、という点です。
東京ドームや武道館のように、定期的にコンサートが開催される立地であればコンサートの状況も把握する必要が高いですから、主要アーティストのファンクラブに入るなどして情報を集めている宿泊施設もあるようです。
しかし、今回の嵐のコンサートのように例外的なイベントの開催の場合は、情報を集めるのが難しいことを前提にしておく方が現実的です。
そうなると、「
サイトコントローラーに登録する在庫は現時点で販売できる客室数以内に収める」と考えておいた方がよさそうです。
当たり前だと思われるかもしれませんが、SCの機能と宿泊施設側の設定によっては、この対応が難しいケースがあるのです。
例えば「週末は2名利用の人気があるから、1名利用は販売数を制限したい」と考えた時に、同じツインの部屋タイプを「T1（1名利用の部屋）」「T2（2名利用の部屋）」と分けてコントロールする宿泊施設が散見されます。
ある程度の予約数に達したら、T1の販売を停止し、T2のみを販売できるようにすることで売上増を期待します。
ところが、この設定だと「あと10室販売できる」時に「T1とT2を足して10室販売したら在庫0」になるのが理想的なのですが、T1とT2を別々に在庫登録する必要があるSCが存在します。
このようなSCを使っていると「T1に3室、T2に7室、合計ツインは10室」と配分を考えるか、「T1に10室、T2に10室、合計20室になってしまうから途中経過を見て販売停止」にするかがよく見られる対処法です。
そして後者の場合、本当に販売できる数以上に在庫登録されていますので、オーバーブックが起きやすくなってしまうのです。
これを防ぐには、
1
名利用
2
名利用の販売コントロールを、部屋タイプで行うのではなくプラン単位で行うのがお薦めの対処方法となります。
※詳しい設定方法は個別のサイトコントローラーで異なります
本当に望ましいのは「カード決済」かもしれない
人為的ミスはともかくとして、システムの仕様やSCの特性から考えられる対処方法を挙げてみましたが、本来望ましい対処方法はカード決済の普及なのかもしれません。
コンサート関係で予約してくださるお客様は、「チケットは抽選式で買えるかどうかまだわからないけど、一応宿泊だけは先に予約しておこう」という考え方をお持ちのようです。
それが証拠に、コンサート関係の需要が大きい宿泊施設の予約動向を見ていると、コンサートが発表された日に一気に予約が入り、抽選日に一気に予約がキャンセルされる、という傾向が見られます。
そこで、カード決済を導入すると「一応宿泊だけは先に予約しておこう」という気持ちになるのを防ぐことができるのではないか、と考えられています。
一部宿泊施設では、このような特需の日には事前カード決済のプランだけを販売しているそうです。
※この場合、キャンセル規定も併せて検討する方が良いでしょう
※極端なキャンセル規定（予約直後から100％キャンセル料が必要）などは、お客様に不信感を与えたりネガティブな口コミが発生したりというリスクがあるようです
オーバーブックという、お客様にも宿泊施設にも不幸な事故が起きないことを願って止みません。皆様も十分にご注意ください。
観光マーケティング実務スタッフ（旅行好き大歓迎！）【株式会社マーケティング・ボイス】
