JP2002133236A - ホテルの客室販売方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 予約の受付に伴うホテルのリスクを解消し、
宿泊を希望するユーザのために客室確保の可能性を高
め、フロントでのスムースな案内を可能とする。 【解決手段】 通信回線を介して接続された端末装置と
の信号応答により、少なくとも、宿泊予定日の空室状況
を呈示する段階、希望する部屋の種別および数を含む宿
泊内容を確認する段階、宿泊内容に基づく支払明細を作
成して呈示する段階を備えるとともに、クレジットカー
ドによる支払い決済を受ける段階、および、いずれかの
段階の後において、宿泊者のうち少なくとも一を特定で
きる個人データの記入を求める段階を備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、通信回線を介して
ホテルの客室を販売するための方法およびシステムに関
する。

【０００２】

【従来の技術】ホテル（旅館を含む各種の宿泊施設）
は、客室を販売するに際し、一般には電話やファクシミ
リによる予約の受付を行い、宿泊客の来館を待って支払
いを受ける。また近時インターネットが普及したことに
より、ホームページを開設し、通信回線を介して各種の
ルートからアクセスしてくるユーザに対して、より詳細
な情報を提供し、予約を受付るサービスを提供する形態
も増加している。

【０００３】インターネットを用いた予約の受付は、通
常、例えば図３に示すように、ホテル側のサーバ装置１
とインターネット回線２を用いて、当該ホテルのイメー
ジ写真、所在地および地図、交通アクセスの案内欄、館
内設備の案内欄等で構成した基本的事項の説明ページ
（３）、空室状況の提供ページ（４）、および予約受付
ページ５を、ユーザの端末装置６に対して提供する。

【０００４】予約受付ページ５は、具体的には、宿泊予
定日、人数、希望する部屋の種類、宿泊者の氏名／住所
／電話番号または会員番号等の必要データ（７）を、ユ
ーザの端末装置６からテキスト／選択形式で受け、空室
状況との数量比較を行い（８）、空室データに反しない
場合には当該予約を受付る（９）。基本的には空室があ
る限り当該空室をユーザからの求めに応じて予約させる
方式をとる。ユーザは、予約確認番号等の確認データを
ブラウザ上で受け取り、当日ホテルのフロントでその旨
（予約があることや予約番号等）を伝えれば良い。万
一、ユーザ側にキャンセルの必要が生じた場合は、予約
受付ページ５上においてユーザに取消処理を実行しても
らう。

【０００５】尚、ホテルの予約に関するシステムとして
は、従来例えば、特開平１１−３２８２７７号、特開平
０９−３２６０８３号、特開平０９−０８１６２６号等
が知られている。

【０００６】

【発明が解決しようとする課題】ところで、通信回線を
用いたホテルの予約システムには次のような問題があ
る。第一に、ホテル側に生ずる問題として、悪戯や真剣
ではない予約が増加する危険があり、宿泊を真に希望す
る者の予約が確保できない等の事態を惹起しやすい点で
ある。悪戯ではなくても、旅行者の中にはスケジュール
が確定していない場合もあり、万一の押さえとして二箇
所、三箇所の異なるホテルに同日の予約を入れる場合も
少なくない。また、そういった場合でもキャンセル処理
を適正に行ってくれれば良いのであるが、キャンセル処
理をせずに当日になっても来館しない予約客も確率的に
は１０〜３０％程度が想定される。

【０００７】このような状態になると、満室の予約状況
であっても、恒常的に１０〜３０％は空室が発生するこ
とになる。この問題を解決するには、予約を依頼してき
たユーザの個人データに関して詳細を求めるか、恒常的
なオーバーブッキングを行うしかない。しかし個人デー
タの詳細を求める方法は、簡易な予約というもともとの
理念に反し、また恒常的なオーバーブッキングの肯定は
ホテルの信頼を損なう結果を招く。

【０００８】一方、ユーザ側の問題としては、予約の際
に氏名／住所／電話番号等の個人データをテキスト形式
でホテルのサーバ装置１に送信する煩わしさがあり、そ
の上で予約をとっても、当日ホテルに出向いた際にはフ
ロントにおいて宿帳に同一項目を再び記入させられる煩
わしさである。

【０００９】観光目的の旅行であってもビジネス上の出
張であっても、疲れているときに宿帳の記入を求められ
るのは精神的に辛い。コンピュータ上の予約受付の時点
で、ホテル側は本人の氏名／住所／電話番号／勤務先な
どのデータを持っているはずであり、それと同一の内容
を改めて宿帳に記入させるのはシステム運営としても疑
問が残る。

【００１０】そこで本発明の目的は、予約の受付に伴う
ホテルのリスクを解消し、また真に宿泊を希望するユー
ザのために客室確保の可能性を高め、来館した宿泊客に
対するフロントでのスムースな案内を可能とする点にあ
る。

【００１１】

【課題を解決するための手段】前記目的を達成するた
め、本発明に係るホテルの客室販売方法は、通信回線を
介して接続された端末装置との信号応答により、少なく
とも、宿泊予定日の空室状況を呈示する段階、希望する
部屋の種別および数を含む宿泊内容を確認する段階、宿
泊内容に基づく支払明細を作成して呈示する段階を備え
るとともに、クレジットカードによる支払い決済を受け
る段階、および、いずれかの段階の後において、宿泊者
のうち少なくとも一を特定できる個人データの記入を求
める段階、を備える。

【００１２】また前記目的を達成するシステムは、宿泊
予定日の空室状況をユーザ端末に呈示する空室データ送
出部と、希望する部屋の種別と数を確認する宿泊内容確
認部と、ユーザ端末からの宿泊者の氏名および住所のテ
キストデータを記録する宿帳記録部と、前記宿泊内容確
認部のデータに基づき、支払金額を演算して支払い明細
を作成する支払明細作成部と、支払明細をユーザ端末に
呈示する明細送出部と、ユーザ端末におけるクレジット
カード決済の事実を確認する決済確認部と、当該決済確
認部のＯＫ信号に基づき、予約および支払の確認データ
をユーザ端末に対して送出する宿泊確認処理部を備える
よう構成する。

【００１３】

【作用】本発明は、ユーザが希望する宿泊予定日の客室
を必要な数量、ユーザのクレジットカードに基づいて販
売し、予め決済処理を済ませる。ホテル側としては、支
払いに関するリスクが解消され、ユーザ側としては単な
る予約ではないので到着時刻等を理由とした予約取消の
扱いを受けずに済み、早い時刻のチェックインという心
理的な強制を受けずに済む。

【００１４】また当然の帰結として、従来の問題、すな
わち、疑わしい予約による収益低下、真に宿泊を希
望する顧客に対する誠実な客室販売の困難、来館した
宿泊客に対する宿帳記入の要求、といったリスクと煩雑
をすべて解消できる。ユーザ側にとってはスムースなホ
テル利用が可能となり、ホテル側にとってはスムースな
案内誘導と一層質の高いサービス提供が可能となる。

【００１５】尚、各種事情によるキャンセルは当然に発
生する。本発明においてもキャンセル処理の段階を設け
ることが望ましい。尚、クレジットカードに基づく決済
があったとしても、クレジットカードが内包する個人デ
ータはホテル側にも漏洩しない。しかし決済後のキャン
セルが繰り返されても、その当人の履歴は確実にホテル
側に残る。通常の予約変更や予約取消と異なり、決済後
の予約取消が頻繁に繰り返される場合は悪戯の可能性が
高い。そのような場合は宿泊拒否等、適切な措置をホテ
ル側において講ずる機会となる。

【００１６】

【発明の実施の形態】図１は、本発明に係る客室販売の
方法の一実施形態を示す図であり、通信回線を介して接
続されたユーザからの要求に基づき、客室の販売処理を
行う際の流れ図である。

【００１７】ユーザからの客室の購入希望があると、ス
タート（Ｓ−１）から始まって、ホテル側のサーバ装置
は、まずユーザ側の端末装置のブラウザに対して、空室
状況を呈示する（Ｓ−２）。客室の空き状況に基づい
て、ユーザから宿泊を希望する旨の適宜の要求信号（Ｓ
−３）を受けたときは、宿泊内容の記入画面をユーザ側
ブラウザに送出する（Ｓ−４）。宿泊内容の記入欄は、
例えば宿泊希望日、部屋のタイプ、人数、食事の有無、
その他の要求項目を選択形式でまたは文字テキスト記入
形式で設定するものである。割引パックの利用、優待券
の有無、禁煙室の希望など詳細な希望を書き込んでも良
いが、これらの詳細な希望は、後段の適当箇所（例えば
宿帳記入時等）において実行しても良い。

【００１８】尚、空室状況の呈示（Ｓ−２）または宿泊
内容の記入画面（Ｓ−４）に対してユーザからの応答が
ない場合は、例えば元の画面である（Ｓ−２）または
（Ｓ−４）に戻るか、宿泊処理を中止してホームページ
に戻る等の適宜の処理を行う。ユーザからの応答が正し
くない場合や一定時間内に応答がない場合、その他の処
理ステップにおいても同様とする。

【００１９】宿泊内容の記入画面（Ｓ−４）に対して、
ユーザから宿泊に関する最小限の記入応答（Ｓ−５）が
あったときは、当該応答に基づいて支払明細を作成しユ
ーザ側のブラウザに呈示する（Ｓ−６）。支払金額およ
び支払明細について、ユーザからの了解（ＯＫ応答）が
あったときは（Ｓ−７）、ユーザの宿泊意思は確定的で
あり、爾後の処理においては一定時間応答がない場合で
も明確な意志表示があるまでは終了処理を控え、待機ま
たは表示画面の更新処理等を行う。

【００２０】支払金額および支払明細についてユーザか
らの了解（ＯＫ応答）があった場合（Ｓ−７）に戻り、
この場合には、ユーザ側のブラウザに対して、宿帳の記
入画面を呈示する（Ｓ−８）。この記入画面は、基本的
には宿泊者の氏名と住所を、文字テキストデータとして
入力してもらうフィールドを備える。より詳細な個人デ
ータ、例えば電話番号、勤務先、性別、生年月日、年齢
等は、項目によっては宿帳の必須の条件ではないから、
これらは記入応答がなくても次段処理に進んでも良い場
合がある。尚、２回目以降の宿泊客は、後段の処理にお
いてホテル側から通知する顧客番号を入力するだけで宿
帳記入の目的を達するので、氏名、住所等のテキスト入
力は基本的には不要である（住所変更等をユーザが自発
的に更新記入することは望ましい）。

【００２１】また宿泊者が複数いる場合は、全員の氏名
と住所を求めるが、複数宿泊の場合は、支払者が全員の
フルネームと住所を知っているとは限らないことが少な
くない。従って、その場合は代表者（支払者）だけの氏
名と住所（必要に応じて電話番号）の記入があれば良
い。宿帳記入は後日でも通信回線を介して自由に書き込
みや変更が出来るからである。またホテル到着の当日
に、代表者以外の必要な宿帳記入を求めても良い。

【００２２】宿帳の記入応答があったときは（Ｓ−
９）、必要金額の支払いを求める画面をユーザ側のブラ
ウザに呈示する（Ｓ−１０）。この画面案内に基づき、
ユーザは指定されたクレジットカードから任意のカード
を選択し、画面の案内に従って支払いを行う。支払い
は、クレジット会社とユーザとの関係における契約であ
り、ホテル側のサーバ装置は、契約の成立の有無だけを
チェックする（クレジット会社からの応答信号に基づく
チェック）。従って、案内画面の構成もクレジット会社
の誘導画面を基本とし、ホテル側のサーバ装置は表示画
面を提供しつつも支払契約における処理の内容にはタッ
チしない。

【００２３】クレジットカードを用いた金銭の支払い
は、支払の総額と明細をユーザが了解するかどうかの確
認だけで良く、特に必要な場合を除いては、暗証番号の
入力などの煩雑な手続を要しない。ユーザが支払いを了
解する場合には、例えば「ＯＫ（承認）」等の意思表示
の選択箇所をクリックすれば良く、暗証番号を入力操作
する必要もないので、支払手続は通常、数秒以内に完了
する。

【００２４】ユーザの支払いがあったときは（Ｓ−１
１）、ユーザからの宿泊内容の記入（Ｓ−５）と宿帳
（Ｓ−９）に基づいて所定フォームの予約確認書を作成
し、ユーザ側のブラウザに送信する（Ｓ−１２）。

【００２５】ユーザは、ブラウザ上で受け取った予約確
認書をプリントアウトし、宿泊当日ホテルに持参するこ
とで、ホテルのフロントにおいて直ちに部屋のキーを受
け取ることが出来る。尚、複数人数の宿泊時において宿
帳の記入応答が全員に関して適正でなかった場合（記入
漏れがあった場合等）は、来館時に直接本人の宿帳記入
を求める。

【００２６】予約確認書の呈示（Ｓ−１２）の呈示に対
し、ユーザから処理終了の応答（了解）があったときは
（Ｓ−１３）、客室販売の処理を終了する（Ｓ−１
４）。

【００２７】かかるホテルの客室販売方法によれば、ユ
ーザの希望する宿泊条件とホテル側が提供できる宿泊条
件の合致を得て、予め支払決済を行う事が可能となり、
ホテル側にとっては従来のリスクを著しく軽減でき、ユ
ーザ側はチェックイン時の煩雑が解消され、スムースな
宿泊が可能となる。

【００２８】ユーザ側からいえば、予約確認書の呈示に
よって部屋のキーを受け取ることが出来るので、疲れて
いるときや時間がないときのチェックインの利便が高ま
ることにより、当該ホテルに対する宿泊需要は確実に向
上する。またホテル側にとっては不安定な予約状況を解
消でき、真に宿泊を希望する顧客への適切な客室提供と
不要人員の削減に伴う競争力の向上、および不要事務の
削減に伴う一層のサービス向上を図ることが可能とな
る。

【００２９】図２は、本発明に係る客室販売システムの
一実施形態を示す図である。この実施形態は、図１に示
した処理過程を実行するためのホテル側のサーバ装置１
０を具体的に示すものである。符号１２はインターネッ
ト等の通信回線、１４は、サーバ装置１０の通信ポート
（ターミナルアダプタやモデム）、１５はユーザ側の各
種の端末装置（コンピュータ端末装置、携帯電話等）で
ある。端末装置１５は通信回線１２を介してサーバ装置
１０に応答できる機材であれば良い。

【００３０】サーバ装置１０は、端末装置１５からの求
めに応じて空室状況を呈示する空室データ送出部２１
と、ユーザに宿泊内容を特定させる宿泊内容確認部２２
を備える。空室データ送出部２１は、例えば今後一ヶ月
の空室状況あるいは宿泊希望日を含む特定期間（例えば
前後二週間等）など、適宜の期間の空室状況を呈示する
ことが望ましい。宿泊内容確認部２２は、宿泊内容を具
体的に特定してもらうためのもので、例えば宿泊日、部
屋タイプ、宿泊人数、食事（朝食／夕食等）、パッケー
ジプラン等のオプションの指定、割引制度の利用などを
クリック選択形式で又は／および文字テキスト形式で記
入し当該データを受信し格納する。

【００３１】２３は、宿泊内容確認部２２に送られたユ
ーザからの応答データに基づき、支払金額を計算する支
払金額演算部、２４は、支払金額演算部２３の計算結果
に基づいて支払い明細を作成する支払明細作成部であ
る。尚、支払金額演算部２３と支払明細作成部２４と
は、別の機能ではあるが、ユーザに対して提示する金額
は項目明細と合計金額を同時に提示することが望ましい
ことから、表裏一体となって機能する作表手段である。

【００３２】作成された支払明細は、明細送出部２５を
介してユーザの端末装置１５に送出する。２６は、支払
明細をユーザが確認し、端末装置１５からＯＫの返送信
号があったときに起動する宿帳記録部である。宿帳記録
部２６は、少なくとも宿泊者の氏名、住所、電話番号、
および顧客番号（ＰＩＮ）をテキスト形式で記入する書
込フィールドを備える。顧客番号（ＰＩＮ）は初回の宿
泊の時に通知するものであり、従って二回目以降の宿泊
客が用いる記入欄である。二回目以降の宿泊客は、氏
名、住所、電話番号をテキスト入力する代わりに顧客番
号を入力するだけで宿帳記入が完了する。尚、後述する
ように宿帳の記入は必ずしも完全である必要はない。本
システムを運用する上で必ずしも致命的な欠陥とはなら
ないからである。また、同様の理由で宿帳記入を求める
処理段階はカード決済の前でも後でも構わない。

【００３３】２７は、宿帳記録部２６から送出した呈示
画面に対して、必要データの書き込みを受けたときに起
動する、決済確認部である。この決済確認部２７は、二
段階の機能を営む。第一は、利用可能なクレジットカー
ドの呈示を含む支払い手続の案内画面の呈示である。第
二は、クレジットカードによる支払い手続が完了したと
きに、当該クレジットカードの決済処理を実行する他の
サーバ装置（図示せず）からの終了信号を受けて、再び
サーバ装置１０における処理に復帰する機能である。

【００３４】決済確認部２７は、当初、支払いの案内画
面を呈示するが、ユーザが任意のクレジットカードを選
択し、カード番号の入力、カードに刻印されている氏名
の入力、有効期限の入力など、所定のテキスト入力デー
タを送信するときには、当該テキストデータは、例えば
サーバ装置１０を介して指定の信販会社に送信される。
もちろん、当該データはサーバ装置１０には残らない。
記入ミスがあったときは、例えば信販会社のサーバ装置
を介してサーバ装置１０からやり直し画面を端末装置１
５に送出する。こうして支払いが完了したときは、信販
会社のサーバ装置からの信号を受けて、決済確認部２７
が再びサーバ装置１０における処理に復帰させる。尚、
支払い手続段階でキャンセルがあった場合も同様であ
る。

【００３５】２８は、決済確認部２７からの信号に基づ
き、宿泊確認書を送出する宿泊確認処理部である。この
宿泊確認処理部２８は、宿泊内容確認部２２と宿帳記録
部２６に記録されているデータに基づき、少なくとも、
宿泊者の氏名（複数いるときは全員の氏名を記入するこ
とが好ましい）、宿泊日、部屋タイプ、食事等のオプシ
ョン内容を明示した確認書を作成し、端末装置１５に送
出する。送出先は、端末装置１５のブラウザでも良い
し、ｅ−メールアドレスであっても良い。確認書は、チ
ェックイン時に部屋キーと交換するためのものであるか
ら、ユーザは来館前に確認書をプリントアウトして持参
する。但し、確認書がなくても支払いは終了しているの
で、フロントにおいて本人であることを確認できれば部
屋キーを渡すことは勿論である。

【００３６】以上説明したように、かかる構成によれ
ば、ホテル側のサーバ装置１０とユーザ側の端末装置１
５との間で、必要事項の応答を進めながら支払いを行
い、宿泊確認書の授受が出来る。

【００３７】尚、宿泊日や宿泊者の変更、部屋タイプや
食事の変更など、ホテル業務として通常想定できる変更
の手続も、前記実施形態の方法およびシステムと略同様
に行うことが出来る。支払金額に修正の必要が生じる場
合も同様である。また宿泊自体のキャンセルは、クレジ
ットカードによるマイナス決済として処理できる。また
キャンセルや予約内容の変更の場合は、例えば予約確認
書に記載されたパスワードや個人ＩＤの入力等により、
本人だけが開くことの出来る修正／変更ページにおいて
予約の変更／取消を行う。

【００３８】確認書を受け取った後、宿泊をキャンセル
し、その状態のまま来館して確認書を呈示しても、サー
バ装置１０においてキャンセル扱いになっている限りは
部屋キーを渡さないのは当然である。この場合には、通
常の来館宿泊客と同様の対応をすれば良い。

【００３９】また、本発明においては、宿泊日、人数、
部屋タイプ、オプション（食事を含む）が確定すれば、
支払い明細の呈示が可能である。従って、決済後（同日
でも後日でも良い）、宿帳を記入してもらっても良い
し、空欄があっても本人が来館したときにフロントで記
入を求めることも出来る。このため、宿帳記入は確認書
の受取人が特定できる最小限の項目、例えば氏、あるい
は電話番号だけでも良い。このような場合は、決済を受
けているホテル側にリスクは殆どないと考えられ、入力
を嫌ったユーザ側のチェックイン時の手間が多少増える
だけであって、システム運用上の致命的な欠陥となるも
のではないと考える。

【００４０】また、ホテル側のリスクを軽減する意味で
は、本発明に係る宿泊処理を終了する前に、宿泊約款を
ユーザの端末装置１５に呈示し、その同意を求めること
が望ましい。宿泊約款は、来館宿泊の場合は同意の有無
を問わず同意したものとしてホテルと宿泊客との規律と
なるが、通信回線を介して宿泊を希望するユーザに対し
ては決済の前または後に同意を得ておくのが望ましい。

【００４１】系列グループ等において複数のホテルが本
システムを共同利用する場合は、各ホテルが提供可能な
空き部屋数を遠隔地からサーバ装置に対して随時増減変
更できるようにしておくことが望ましい。

【００４２】

【発明の効果】以上説明したように、本発明によれば、
予約の受付に伴うホテルのリスクを解消し、また真に宿
泊を希望するユーザのために客室確保の可能性を高め、
来館した宿泊客に対するフロントでのスムースな案内を
可能とすることが出来る。

【図面の簡単な説明】

【図１】本発明に係る客室販売方法の実施形態を示すフ
ローチャートである。

【図２】本発明に係る客室販売システムの実施形態を示
すブロック図である。

【図３】従来のホテルの検索予約システムを例示する図
である。

【符号の説明】

１０ サーバ装置 １２ 通信回線 １４ 通信ポート（ターミナルアダプタ等） １５ ユーザ側の端末装置 ２１ 空室データ送出部 ２２ 宿泊内容確認部 ２３ 支払金額演算部 ２４ 支払明細作成部 ２６ 宿帳記録部 ２７ 決済確認部 ２８ 宿泊確認処理部

Claims (3)

【特許請求の範囲】
1. 【請求項１】通信回線を介して接続された端末装置との
   信号応答により、少なくとも、 宿泊予定日の空室状況を呈示する段階、希望する部屋の
   種別および数を含む宿泊内容を確認する段階、宿泊内容
   に基づく支払明細を作成して呈示する段階を備えるとと
   もに、 クレジットカードによる支払い決済を受ける段階、 および、いずれかの段階の後において、宿泊者のうち少
   なくとも一を特定できる個人データの記入を求める段
   階、を備えることを特徴とするホテルの客室販売方法。
2. 【請求項２】通信回線を介して接続された端末装置との
   信号応答に基づき、 宿泊予定日の空室状況を呈示する第一の段階、 希望する部屋の種別および数を含む宿泊内容を確認する
   第二の段階、 第二の段階または第四の段階の後において、少なくとも
   宿泊者の氏名と住所を確認する第三の段階、 第二の段階または第三の段階の後に支払い明細を呈示す
   る第四の段階、 クレジットカードを介したユーザ端末の決済事実を確認
   する第五の段階、の各段階を備えることを特徴とするホ
   テルの客室販売方法。
3. 【請求項３】通信回線を介して接続されたユーザ端末か
   らの入力信号に基づきホテルの客室を販売するシステム
   であって、少なくとも、 宿泊予定日の空室状況をユーザ端末に呈示する空室デー
   タ送出部と、 希望する部屋の種別と数を確認する宿泊内容確認部と、 ユーザ端末からの宿泊者の氏名および住所のテキストデ
   ータを記録する宿帳記録部と、 前記宿泊内容確認部のデータに基づき、支払金額を演算
   して支払い明細を作成する支払明細作成部と、 支払明細をユーザ端末に呈示する明細送出部と、 ユーザ端末におけるクレジットカード決済の事実を確認
   する決済確認部と、 当該決済確認部のＯＫ信号に基づき、予約および支払の
   確認データをユーザ端末に対して送出する宿泊確認処理
   部を備えることを特徴とするホテルの客室販売システ
   ム。