前回の「レベニューマネジメントに不可欠な要素、フォーキャスト（２）」からはいよいよフォーキャストの実践的な説明に入ってきました。ディマンドフォーキャストの作成に不可欠なデータ収集を行う上で必ず収集したいデータ項目をいくつか列挙しましたが、そのデータ項目の中からの解説を続けます。
ディナイアル、リグレット
このデータ項目は、先に説明したアンコンストレイントディマンドならではのデータ項目です。まずはそれぞれの定義を明記しましょう。
ディナイアル（Denial）：空室がないことによりホテルからお断りした問い合わせ
リグレット（Regret）：料金などの理由により消費者が購買を見送った問い合わせ
前回、ディマンドフォーキャスト作成にあたり必ず収集したいデータ項目の1つとしてキャンセルデータをあげましたが、その理由として「キャンセル予約がアンコンストレイントディマンドの一部だから」という話をしました。キャンセルされたというのはあくまでも結果に過ぎないわけであって、それもホテルが集客過程で獲得した総需要の１つであるということに変わりはないからです。
同じように、上記で説明した「空室がないことによりホテルからお断りした問い合わせ」を指すディナイアルと「料金などの理由により消費者が購買を見送った問い合わせ」であるリグレットも、結果的に実績とはならなかった予約であるものの「もし問い合わせがあった時点でまだホテルに空室があったら」「もし問い合わせがあった時点で3日前まで出ていたプロモーション料金がまだ販売されていたら」など、もし条件が合致していたら実績として記録されていたかもしれない需要、つまり総需要の１つです。
例えばオラクルのOpera PMSを使っているホテルは、料金を調べるいわゆる「Rate Query」の機能の中に、このリグレットやディナイアルを記録する仕組みがあることをご存じかもしれません。OperaのRate Queryでは、一度、料金・在庫検索をするために設定した条件をクリアする（最初からやり直す）場合、「その検索をなぜ終えるのか」という理由を選択しないと条件をクリアすることができません。これは、例えば皆さんがあるショッピングサイトでメルマガを購読していてその購読を止める際、場合によっては購読中止する理由、例えば「自分にあったオファーが届かないから」「メルマガの頻度が多いから」などを選ばないと購読中止ができないのと同じような仕組みです。
一方で、昨今ではこのディナイアルとリグレットのデータは、その収集とデータの質に課題を抱えるようになってきました。インターネットなどのネットワークによる予約が普及する前、ホテルの予約は基本的にホテルの宿泊予約課の手で作成されていました。それが電話の予約であれFaxの予約であれ、宿泊予約課に問い合わせが入り、その条件をもとに空室検索を行ったうえで回答を行っていました。その際にその問い合わせに応えられなければ、それが「空室状況ゆえなのか」「料金ゆえなのか」も含めてすべて記録することもできました。
OTAや各旅行会社の予約ネットワークにより予約網が格段に広がった現在、このディナイアルとリグレットのそのすべてを収集、記録することは容易ではありません。例えばあるOTAであなたのホテルの空室が探していた消費者が、空室がないことを理由に別のホテルを予約したという事がどのようにわかるのでしょうか？またある消費者が、あなたの競合ホテルに予約することを決めた理由が価格に由来する（もしくは由来しない）という理由がどのようにわかるのでしょうか？
このディナイアルとリグレットのデータは、アンコンストレイントディマンドを記録する上で欠かせないデータの1つではありますが、昨今はその正確なトラッキングに大きな課題を抱えていることは否めません。
グループ予約のキャンセル、減室
アンコンストレイントディマンドに個人（Transient）、団体（Group）の区別はありません。例えある団体の問い合わせが結果的に実績にならなかったとしても、問い合わせがあったという事実はアンコンストレイントディマンドとしてきちんと記録されなくてはいけません。問い合わせがあったけれども結果的に空室がなくてお断りしたのか、もしくは料金が合わなくて断られたのか、いずれの理由でも先ほど説明したリグレット、およびディナイアルとしてきちんと記録することができます。
往々にして、団体予約はその正確な記録に課題があることは否めません。おもに営業部のビジネスとして扱われる団体予約は、その記録が営業部によって扱われること、また場合によっては記録の仕方により説明責任を問われてしまうことから、それが事実の正確な記録をますますゆがめてしまい、それが結果として適切なフォーキャスト、レベニューマネジメントの実行を大きく妨げることもしばしばです。
こういった問題ゆえに営業部とレベニューマネジメントは別の指揮系統で、同等の権限をもってそれぞれが独立して職務に携わるべきなのですが、往々にして営業部や宿泊部の下につくことが多いその組織体系が、日本のホテルのおける団体予約管理をさらに難しくしているように思います。（レベニューマネジメントの組織体系については過去の記事を参照してください）
繰り返しますが、正確なディマンドフォーキャストの作成には正確な記録のトラッキングが不可欠です。団体予約の問い合わせ状況やリグレット、ディナイアルの記録、実際に契約されてからの在庫や料金反映、およびそこからの減室、増室、キャンセルを含めたすべての記録が記録されている必要があります。
販売不可部屋、無料宿泊部屋、ハウスユース
レベニューマネージャーは、このような宿泊要素の動きもきちんと観察していなくてはなりません。特にディスプレイスメントが発生しそうなショルダー、ピークシーズンについては、このような要素の予約が売り上げの最大化を阻害する要因となっていないか注意する必要があります。
例えば、明らかなピークシーズンのど真ん中に部屋のクリーニングや、法定点検などで生じるアウトオブオーダー（販売不可）等は入っていないでしょうか？これらの要素により結果的に売り上げを最大化できなかった場合、説明を負うべきは、それらの作業を行った施設管理部の人間ではなく、それらの日にちにアウトオブオーダーが入っていることをやり過ごしたレベニューマネージャーです。
またピークシーズンのど真ん中に、ハウスユースなどでスタッフの宿泊などは入っていないでしょうか？こういった宿泊についても、もし他の手立てを講じることによって売り上げをさらに最大化できる可能性があるのであれば、例えば宿泊コストなどを鑑み、もし隣のホテルにスタッフを移動させた方が全体の売り上げの最大化に適うのであれば、そのような措置も躊躇なく行われるべきです。
データ収集の範囲と必ず必要なデータ
このようにしてデータ収集するわけですが、まずはホテルが使用している現在のシステムやディストリビューションの仕組みを考えたときに、どのようなデータをどこまで正確に集めることができるのか検討しましょう。もちろん、先にあげたデータ項目をできる限り多く集めることができるに越したことはないですが、その中の１つや２つが欠けるからといってディマンドフォーキャストができないということではありません。
一方で、ディマンドフォーキャストを作成するにあたって決して欠かすことができないデータもあります。例えば、マーケットセグメントごとのルームナイツや売り上げといったデータは、これらのデータなしではそもそもキャストの作成が難しいデータと言えるでしょう。PMSによっては既存の設定項目ではこういったデータを入力する項目がない、また会社から収集するように指示されているマーケットセグメントの定義が、レベニューマネジメントにおけるマーケットセグメントの定義と異なる などの事情もあると思いますが、正確なマーケットセグメントの定義に基づくデータ収集はフォーキャストの要です。
マーケットセグメントごとのデータは、少し開発費用を払ってでもマーケットセグメントを入力できる項目をPMSに追加してもらう、全社的な定義とは別にレベニューマネジメントにおけるマーケットセグメントの定義をきちんと定め、そのデータも平行して収集を進めるなど、適切なレベニューマネジメント実行のために必ず収集してほしいデータです。
On the book レポート
これらのデータ収集の壁を乗り越えると、まずはOn the book （オンハンド）のレポートの完成に大きく近づきます。つまり「現時点で先にどれだけ予約が入っているか」ということを数字で確認できるレポートです。
データ収集可能な項目の数字を毎日、自らのホテルが予約を承っている期間分だけ記録していきます。例えば今日が21年9月1日だとして、ホテルが22年8月31日までの先1年分の予約を承っているとしたら、21年9月1日時点での9月1日のオンハンド、9月2日のオンハンド、9月3日のオンハンド・・・これを22年8月31日分まで日ごとに記録していきます。
このように書いてみると気の遠くなる作業ですが、あらかじめレポートとして出力するデータ項目をテンプレートとして保管しておけば、基本的にはワンクリックでその先365日分のデータが一気に抽出されるようになるはずです。こうして毎日蓄積していくデータがオンハンドのレポートとなります。（これらのデータをすべてマーケットセグメントごとに記録することを忘れずに）
次回からは、いよいよディマンドフォーキャストの作成に入ってきます。