JP2015032058A - 個別要望対応機能を備えた予約システム - Google Patents

Abstract

【課題】顧客から受付センターに寄せられる顧客独自の個別要望を含んだ予約の依頼に対して、予約の獲得率を向上させることができるチェーン店舗に適した予約システムを提供する。
【解決手段】顧客要望受付手段が受付センターで入力された顧客要望データをサーバに送信すると、新規顧客要望データ送信手段が顧客要望に対する候補店舗に顧客要望データを送信する。候補店舗の顧客対応入力手段は受信した顧客要望データを表示するとともに当該候補店舗での顧客との予約条件の協議内容及び対応状況からなる顧客対応データを入力させてサーバに送信すると、候補店舗対応状況データ送信手段がさらに各候補店舗に顧客対応データを送信する。
【選択図】図８

Description

本発明は、顧客からの個別要望に応じることができる予約システムに関する。

複数の飲食店を経営する外食チェーンなどでは、顧客からの予約に対応する店舗の負担軽減や顧客の利便性向上、予約獲得の拡大などを目的として、各店舗への予約を一括して受付ける受付センター（集中コールセンターなどとも呼ばれる）が設けられている。この受付センターでは、予約の円滑な受付業務の実行と、各店舗、外食チェーン本部などでも顧客から受付けた予約情報を共有することができる予約システムが利用されている。

この予約システムでは、一般的にオペレータが顧客から予約の電話を受付けた際、顧客の希望する店舗・日時・人数・席の種類・予算などの条件を満たす店舗を確認し、顧客の希望に叶う条件で受付けが可能な場合には予約入力を行う事で顧客の予約を成立させる。また、顧客の希望に叶う第１の条件に該当する店舗が無い場合には、オペレータは顧客から第１の条件の中から優先度の低い条件項目の範囲を広げた第２、第３の条件などを確認してその条件に叶う店舗を提案し、顧客からの了承が得られた場合には予約を成立させるという一連の販促行為を行うことによって、予約獲得率の向上に貢献している。

一方、予約に際して顧客が求める希望には、オペレータが予約システムで予約を成立させることが出来ない顧客独自の個別要望（例えば、コース料理の内容変更、お子様向け料理や営業時間外利用など）も多くあり、これらの希望に対しては店舗側での受入れ可・不可の判断を要するため、オペレータはこの顧客の予約を獲得するために、顧客が希望する店舗に顧客独自の個別要望を伝達するなどして顧客と店舗の仲介を行わなければならず、効率的に予約を獲得することが困難となっていた。

このような背景から、顧客独自の要望に対して各店舗側からの回答を行うことができるＷｅｂ検索システムが提案されている。（例えば、特許文献１参照）。

特開２００７−３４７９４号公報（第７〜１３頁、図２）

特許文献１のＷｅｂ検索システムによれば、顧客は自ら申込み登録フォームに規定の条件（時間・場所・予算など）と、顧客独自の要望（店舗に対する相談内容）を入力し、システムの検索結果により規定の条件に一致した候補店舗では、顧客独自の要望に対する回答を入力する。これにより顧客は独自の要望に対して回答のあった複数の候補店舗の中から各回答内容を吟味して予約を行うことができる。しかしながらこのＷｅｂ検索システムを、外食チェーンで利用した場合には、１件の予約に対して複数店舗が同時に獲得活動を行うこととなるため、次のような問題があった。

１．候補店舗では他の候補店舗の存在や、各候補店舗が回答した内容を把握できないことから、他店舗と同様の回答や、他店舗の回答よりも明らかに見劣りするような予約を獲得できる可能性が低い回答を行う場合がある。また、他の候補店舗の回答を把握した上で顧客独自の要望により近い条件を回答するなど、自店舗が予約を獲得できる可能性を高めることができない。２．獲得活動を行った複数の店舗では、利用者が予約を確定させるまでの間、この予約が成立した場合に備えて他の予約を成立させることが出来ない場合がある。つまり、他の予約の獲得機会が減少する。

本発明は以上述べた問題点を解決し、顧客独自の個別要望に応じて顧客と店舗間で行われる予約条件の協議を効率的に実施することができ、予約の獲得率を向上させることができる予約システムを提供することを目的とする。

本発明は上述の課題を解決するため、本発明の請求項１に記載の発明は、顧客の要望を定型の第一顧客情報と不定型の第二顧客情報として受け付け前記第一顧客情報と前記第二顧客情報を合わせて顧客要望データを生成して送信する顧客要望受付手段と、前記顧客要望データを受信して記憶するとともに、同顧客要望データに基づいて予め記憶された複数の店舗の店舗情報を検索して前記第一顧客情報に該当する候補店舗を抽出し、前記候補店舗に対する新規顧客要望データとして前記顧客要望データを送信する新規顧客要望データ送信手段と、受信した前記新規顧客要望データに対して入力された当該候補店の応答である顧客対応データを送信する顧客対応入力手段と、受信した前記顧客対応データを前記顧客要望データと関連付けて候補店舗対応状況データとして記憶する候補店舗対応状況記憶手段と、前記候補店舗対応状況データを送信する候補店舗対応状況データ送信手段とがそれぞれ通信回線で接続され、前記顧客対応入力手段は受信した前記候補店舗対応状況データに対して入力された当該候補店の応答を新たな顧客対応データとして送信することを特徴とする。

また、本発明の請求項２に記載の発明は、前記候補店舗対応状況記憶手段は前記顧客対応データが受信される度に前記顧客要望データと関連付けて記憶された前記候補店舗対応状況データを更新して記憶し、前記候補店舗対応状況データ送信手段は前記候補店舗対応状況データが更新される度に同候補店舗対応状況データを送信することを特徴とする。

また、本発明の請求項３に記載の発明は、前記第一顧客情報は、顧客が希望する予約内容を予め定められた複数のパターンからの選択により入力する情報であり、前記第二顧客情報は、顧客が希望する予約内容を直接入力する情報であることを特徴とする。

また、本発明の請求項４に記載の発明は、前記顧客対応データは、当該顧客に対する当該候補店の応答を予め用意された複数のステータスからの選択により入力する情報を含み
、前記ステータスには少なくとも、予約の成立、予約の不成立、前記顧客と交渉中、を各々示すものが含まれることを特徴とする。

以上の手段を用いることにより、本発明による予約システムによれば、顧客独自の個別要望に応じた各候補店舗の対応状況を店舗スタッフが把握することができるため、１件の個別要望に対して複数店舗が予約の獲得活動を同時に実施すること無く、効率的に予約を獲得できる可能性を高めることができる。また、各候補店舗では顧客から予約を行うか否かの回答を受けるまでの待ち時間が生まれないため、複数の個別要望に対して次々に獲得活動を行うことができ予約獲得率を向上させることができる。

本発明による予約システムのシステム構成概要を示す構成図である。 本発明によるサーバの概略構成を示すブロック図である。 本発明によるクライアントの概略構成を示すブロック図である。 本発明による顧客要望受付手段を説明する説明図である。 本発明による顧客対応入力手段を説明する説明図である。 本発明によるサーバに記憶される店舗ＤＢを説明する説明図である。 本発明によるサーバに記憶されるリクエストＤＢを説明する説明図である。 本発明によるサーバの制御部の処理概要を説明するフローチャートである。 本発明による受付センターのクライアントの処理概要を説明するフローチャートである。 本発明による店舗のクライアントの処理概要を説明するフローチャートである。 本発明によるクライアントに表示される処理選択メニュー画面である。 本発明によるクライアントに表示される新規顧客要望データの受信通知画面である。

以下、本発明の実施の形態を、添付図面に基づいた実施例として詳細に説明する。なお
、本発明は以下の実施形態に限定されることなく、本発明の主旨を逸脱しない範囲で種々変形することが可能である。

図１は、本発明による予約システムのシステム構成概要を示す構成図である。予約システム１は、受付センター、店舗及び本部などに複数設置され予約の受付入力や、状況確認などの業務に利用するクライアント２０と、各クライアント２０に通信接続されるネットワーク３０と、各クライアント２０から受信した通信データの内容に応じて各種処理を行うサーバ１０とで構成される。なお、各クライアント２０は同一のネットワーク３０に接続されるが通信処理については各クライアント２０とサーバ１０とで１対１の関係となっている。

図２は、本発明によるサーバの概略構成を示すブロック図である。サーバ１０は、ネットワーク３０を介して各クライアント２０との通信データを送受信する通信部１１と、予約システム１を使用して業務を行うユーザの情報を記憶するユーザデータベース（以降データベースは“ＤＢ”と記す）１２１、店舗情報を記憶する店舗ＤＢ１２２、成立した予約情報を記憶する予約管理ＤＢ１２３、顧客からの受付けた個別要望に関する情報を記憶するリクエストＤＢ１２４などが記憶される記憶部１２と、これらを制御する制御部１３を備えている。なお、制御部１３には、一般的な予約システムにおいて行われる処理の他に、顧客独自の個別要望に関する処理を行うために詳細は後述する新規顧客要望データ送信手段１３１と、候補店舗対応状況記憶手段１３２と、候補店舗対応状況データ送信手段１３３とを備えている。

図３は、本発明によるクライアントの概略構成を示すブロック図である。クライアント２０は、ネットワーク３０を介してサーバ１０との通信データを送受信する通信部２１と
、クライアント２０の使用者からの操作を受付ける操作部２２と、同使用者へ操作部２２や通信部２１から入力された情報を表示する表示部２３と、予約システム１のプログラムや通信データなどを記憶する記憶部２４と、これらを制御する制御部２５を備えている。なお、制御部２５には、一般的な予約システムにおいて行われる処理の他に、顧客独自の個別要望に関する処理を行うために詳細は後述する顧客要望受付手段２５１と、顧客対応入力手段２５２とを備えている。

図４は、本発明による顧客要望受付手段を説明する説明図である。この顧客要望受付手段２５１はクライアント２０の制御部２５において、顧客から個別要望を受付けた受付センターのオペレータの操作により、受付内容を入力するとともに顧客要望データを生成して通信部２１を介してサーバ１０へ送信する。なお、（４−１）表示例は、受付内容の入力画面であり、（４−２）メッセージ例は顧客要望データをサーバ１０へ送信した後に表示されるメッセージ画面である。

（４−１）表示例は、クライアント２０の制御部２５がオペレータからの顧客要望の受付入力の処理を選択する操作を、操作部２２を介して受付けた時（例えば処理選択メニューから顧客要望受付入力と記されたボタンをクリックするなど）顧客要望受付手段２５１が表示部２３に表示させる画面を示している。入力項目の上段は“予約日”、“予約時間”など、顧客からの受付内容に応じて選択式に入力させる定型の情報であり、以降の説明ではこれらの情報を“第一顧客情報”と呼称する。中段は“要望内容”の項目に顧客が希望する独自の要望内容を文字で直接入力させる不定型の情報であり、以降の説明ではこの情報を“第二顧客情報”と呼称する。また下段の“候補店舗”は顧客から店舗指定の希望を受付けた際、選択式に入力させる項目である。

（４−２）メッセージ例は、（４−１）表示例の最下部に表示した処理選択ボタンのうち、「登録」のボタンが選択された時、顧客要望受付手段２５１が画面に入力されたデータから顧客要望データを生成し、通信部２１を介してサーバ１０へ送信した際に表示部２３に表示するメッセージ画面である。なお、“リクエストＮｏ．”の項目については顧客要望データを受信したサーバ１０が自動採番した顧客要望の管理番号である。

図５は、本発明による顧客対応入力手段を説明する説明図である。この顧客対応入力手段２５２はクライアント２０の制御部２５において、個別要望の候補店舗として選定された店舗のスタッフの操作により、個別要望に対して実施する顧客への対応を入力するとともに顧客対応データを生成して通信部２１を介してサーバ１０へ送信する。なお、（５−１）表示例は、顧客からの個別要望の内容を表示するとともに、その顧客への対応を入力する画面であり、（５−２）〜（５−４）メッセージ例は、サーバ１０へ顧客対応データを送信する前後に表示されるメッセージ画面である。

（５−１）表示例は、クライアント２０の制御部２５が候補店舗のスタッフからの顧客対応の入力の処理を選択する操作を、操作部２２を介して受付けた時（例えば図１１に示す処理選択メニューから「顧客対応入力」が選択された場合や、顧客からの要望に対する候補店として選定された事を通知する図１２に示すメッセージ画面から「顧客対応入力へ」と記されたボタンをクリックするなど）顧客対応入力手段２５２が表示部２３に表示させる画面を示している。なお、上段は顧客要望データを表示し下段は顧客対応データを表示し、候補店舗のスタッフは上段の各表示項目から顧客の要望内容と、下段の各表示項目から他の候補店の対応内容を把握した上で、自店舗の対応を検討して顧客との予約条件の協議を行い、自店舗の顧客との対応内容を“対応状況”と“対応記録”の項目に入力する。

“対応状況”は予め用意されたステータスの中から選択入力させる項目であり、例えば
、店舗側の判断で顧客との協議を行わない場合に選択する「辞退」、店舗と顧客との協議の結果予約を獲得した場合に選択する「成立」、店舗と顧客との協議の結果予約の獲得には至らなかった場合に選択する「不成立」、顧客との協議を開始または、協議の継続中に選択する「交渉中」などがある。また、“対応記録”は顧客との協議内容を文字で直接入力させる項目である。

（５−２）〜（５−４）メッセージ例は、（５−１）表示例の最下部に配置された処理選択ボタンのうち、「登録」のボタンが選択された時、顧客対応入力手段２５２が入力された“対応状況”のステータスに応じて表示するメッセージ画面である。より詳細には（５−２）は“対応状況”のステータスに「辞退」「不成立」「交渉中」が入力された場合に、当該候補店において入力された“対応状況”と“対応記録”からなる顧客対応データを通信部２１を介してサーバ１０へ送信した際に表示部２３に表示するメッセージ画面である。（５−３）は他の候補店の“対応状況”のステータスに「成立」や「交渉中」があるときに当該候補店での“対応状況”のステータスに同じく「成立」や「交渉中」が選択されることを禁止することで、複数店舗での予約の重複や顧客との協議の同時進行を防止する顧客対応の運用ルールに基づいた操作制限を表示部２３に表示するメッセージ画面である。（５−４）は“対応状況”のステータスに「成立」が入力された場合に、（５−２）と同様の顧客対応データをサーバ１０へ送信するとともに、引き続き店舗スタッフに当該候補店舗での座席割当てなど予約を成立させる操作を促すために表示部２３に表示するメッセージ画面である。

図６は、本発明によるサーバに記憶される店舗ＤＢを説明する説明図である。この店舗ＤＢ１２２は、各店舗の詳細な情報が予め登録されたものであり、受付センターで顧客からの予約を受付けた時や、サーバ１０の新規顧客要望データ送信手段１３１が顧客要望データの条件に該当する候補店舗を抽出する時の検索などで使用される。

店舗ＤＢ１２２の各項目について、図６の左側から説明する。「店舗コード」は店舗識別用の数字である。「店舗名」は店舗の正式名称である。「業態種別」は店舗が属する業態の分類、例えば、飲食店の中でもファミリーレストラン、居酒屋、中華などの種類や、同じファミリーレストランであっても複数の屋号がある場合に使用される店舗の種類など
である。以降は、所在地情報として「郵便番号」「住所」「最寄駅」など、営業情報として「開閉店時間パターン」「店休日パターン」など、座席情報として「座席数」「個室数」「最大宴会人数」「禁煙席数」など、連絡先情報として「外線番号」「内線番号」などがあり、これらはその項目名称が示す店舗固有の情報である。なお、店舗ＤＢ１２２には、図示しない日別、時間帯別及びテーブル別の成立した予約情報を記憶し予約管理ＤＢ１２３を兼ねても良い。

図７は、本発明によるサーバに記憶されるリクエストＤＢを説明する説明図である。このリクエストＤＢ１２４は、クライアント２０の顧客要望受付手段２５１から顧客要望データを受信した時、サーバ１０の新規顧客要望データ送信手段１３１によって記憶される情報であり、また、クライアント２０の顧客対応入力手段２５２から候補店舗対応状況データを受信した時、サーバ１０の候補店舗対応状況記憶手段１３２によって記憶される情報である。

リクエストＤＢ１２４の項目について、図７の左側から説明する。「リクエストＮｏ．」は新規顧客要望データ送信手段１３１によって顧客要望データをリクエストＤＢ１２４へ記憶する際に自動採番する各データの識別番号である。「データ種別」は以下のリクエストＤＢ１２４に記憶される各情報を説明するために設けた情報の種類によって分類した“１”〜“３”の番号である。

データ種別“１”は図４の顧客要望受付手段２５１で説明した顧客要望データのうち、（４−１）表示例の画面から選択式に入力された「予約日」「予約時間」「席タイプ」「人数」「業態種別」、コース料理の種類を示す「コース料理」「予算」「対応期限」や図示しない候補店舗の抽出に用いる「最寄駅」「郵便番号」などの定型の第一顧客情報が記憶される。

データ種別“２”は同じく図４の顧客要望受付手段２５１で説明した顧客要望データのうち、（４−１）表示例の画面から顧客が希望する独自の要望内容を文字で直接入力された「個別要望」を示す不定型の第二顧客情報が記憶される。

データ種別“３”の「候補店舗コード」の項目は、新規顧客要望データ送信手段１３１が顧客要望データを受信した時、“第一顧客情報”に該当する候補店舗を店舗ＤＢ１２２を検索して抽出した複数の“候補店舗コード”の情報が記憶される。なお、顧客要望データ内に“候補店舗コード”の情報が既に存在する場合には、顧客から候補店舗の指定を受付けているため新規顧客要望データ送信手段１３１は候補店舗の抽出を行わず、顧客要望データに従って“候補店舗コード”の情報が記憶される。

データ種別“３”の「候補店舗コード」の項目に対応する「対応状況」と「対応記録」の項目は、図５の顧客対応入力手段２５２で説明した顧客対応データの内容を、図７の各リクエストＮｏ．毎のデータが示すとおり、顧客要望データに関連付けて記憶される。なお
、以降の説明ではこれら情報を“候補店舗対応状況データ”と呼称する。

また、リクエストＤＢ１２４の“候補店舗対応状況データ”に新たな情報が記憶される度に、候補店舗対応状況データ送信手段１３３は、データ種別“３”の全ての候補店舗に対して“候補店舗対応状況データ”を送信する。

図８は、本発明によるサーバの制御部の処理概要を説明するフローチャートであり、特に顧客要望に応じてサーバ１０の制御部１３で行われる新規顧客要望データ制御手段１３１と、候補店舗対応状況記憶手段１３２及び候補店舗対応状況データ送信手段１３３との動作を説明する。なお、図８〜図１０のフローチャートに記載のＳＴはステップを表し、これに続く数字はステップ番号を表している。

（８−１）は新規顧客要望データ制御手段１３１の動作を示すフローチャートである。動作が開始される前提条件として、クライアント２０の顧客要望受付手段２５１から通信部１１を介して顧客要望データを受信したものとする。

新規顧客要望データ制御手段１３１は、受信した顧客要望データに候補店舗の情報が含まれているか否かを確認する（ＳＴ１）。候補店舗の情報が含まれていない場合（ＳＴ１−Ｎｏ）、記憶部１２の店舗ＤＢ１２２を検索し、顧客要望データの第一顧客情報に該当する複数の候補店舗を抽出する（ＳＴ２）。続いて、顧客要望データと抽出または受信した候補店舗のデータを記憶部１２のリクエストＤＢ１２４に記憶する（ＳＴ３）。さらに
、通信部１１を介して各候補店舗に新規顧客要望データを送信する（ＳＴ４）。そして新規顧客要望データ制御手段１３１の動作を終了する。

新規顧客要望データ制御手段１３１はＳＴ１において、受信した顧客要望データに候補店舗の情報が含まれている場合（ＳＴ１−Ｙｅｓ）、ＳＴ３にジャンプする。なお、ＳＴ２において検索する店舗ＤＢ１２２に成立した予約情報が含まれていない場合には、予約管理ＤＢ１２３も含めて検索し第一顧客情報に該当する候補店舗を抽出する。

（８−２）は候補店舗対応状況記憶手段１３２及び候補店舗対応状況データ送信手段１３３の動作を示すフローチャートである。動作が開始される前提条件として、クライアント２０の顧客対応入力手段２５２から通信部１１を介して顧客対応データを受信したものとする。

候補店舗対応状況記憶手段１３２は、受信した顧客対応データをリクエストＤＢ１２４に既に記憶されている顧客要望データと関連付け、候補店舗対応状況データとしてリクエストＤＢ１２４へ記憶する（ＳＴ１１）。続いて、候補店舗対応状況データ送信手段１３３は記憶したリクエストＮｏ．に基づいて、候補店舗対応状況データに含まれる各候補店舗に候補店舗対応状況データを送信する（ＳＴ１２）。そして候補店舗対応状況記憶手段１３２及び候補店舗対応状況データ送信手段１３３の動作を終了する。

図９は、本発明による受付センターのクライアントの処理概要を説明するフローチャートである。処理が開始される前提条件として、クライアント２０の予約システム１が起動されネットワーク３０を介してサーバ１０と通信可能となったものとする。

制御部２５は、予約システム１の表示部２３に図１１に示す処理選択メニュー画面を表示する（ＳＴ２１）。処理選択メニュー画面の各種業務ボタンが選択された操作を操作部２２から受付けたか否かを確認する（ＳＴ２２）。各種業務ボタンを選択する操作を受付けていない場合（ＳＴ２２−Ｎｏ）、操作部２２から予約システム１を終了する操作を受付けたか否かを確認する（ＳＴ２３）。予約システム１を終了する操作を受付けた場合（ＳＴ２３−Ｙｅｓ）、予約システム１を終了する。一方、予約システム１を終了する操作を受付けていない場合（ＳＴ２３−Ｎｏ）、ＳＴ２２へ戻る。

制御部２５はＳＴ２２において、各種業務ボタンを選択する操作を受付けた場合（ＳＴ２２−Ｙｅｓ）、選択された業務のボタンが顧客要望受付入力であるか否かを確認する（ＳＴ２４）。顧客要望受付入力のボタンが選択された場合（ＳＴ２４−Ｙｅｓ）、記憶部２４に記憶される図４−１で説明した顧客要望受付入力画面の情報を表示部２３に表示し、操作部２２からの操作を受付ける（ＳＴ２５）。操作部２２から画面に表示した登録ボタンの操作を受付けたか否かを確認する（ＳＴ２６）。登録ボタンの操作を受付けた場合（ＳＴ２６−Ｙｅｓ）、受付入力画面に入力された情報から顧客要望データを作成し、通信部２１を介してサーバ１０へ送信する（ＳＴ２７）。そしてＳＴ２１へ戻る。

制御部２５はＳＴ２６において、操作部２２から登録ボタンの操作を受付けていない場合（ＳＴ２６−Ｎｏ）、操作部２２から終了ボタンの操作を受付けたか否かを確認する（ＳＴ２８）。終了ボタンの操作を受付けた場合（ＳＴ２８−Ｙｅｓ）、ＳＴ２１へ戻る
。一方、終了ボタンの操作を受付けていない場合（ＳＴ２８−Ｎｏ）、ＳＴ２６へ戻る。また、ＳＴ２４において、選択された業務のボタンが顧客要望受付入力では無い場合（ＳＴ２４−Ｎｏ）、選択された業務のボタンに応じて制御する（ＳＴ２９）。そして、ＳＴ２１へ戻る。なお、図３及び図４で説明した制御部２５の顧客要望受付手段２５１は、図９のＳＴ２５〜ＳＴ２８の中で説明した処理を実行するための構成である。

図１０は、本発明による店舗のクライアントの処理概要を説明するフローチャートである。処理が開始される前提条件として、クライアント２０の予約システム１が起動されネットワーク３０を介してサーバ１０と通信可能となったものとする。

制御部２５は、予約システム１の表示部２３に図１１に示す処理選択メニュー画面を表示する（ＳＴ３１）。通信部２１を介して顧客要望データを受信したか否かを確認する（ＳＴ３２）。顧客要望データを受信していない場合（ＳＴ３２−Ｎｏ）、通信部２１を介して顧客対応データを受信したか否かを確認する（ＳＴ３３）。顧客対応データを受信していない場合（ＳＴ３３−Ｎｏ）、処理選択メニュー画面の各種業務ボタンが選択された操作を操作部２２から受付けたか否かを確認する（ＳＴ３４）。各種業務のボタンを選択する操作を受付けていない場合（ＳＴ３４−Ｎｏ）、操作部２２から予約システム１を終了する操作を受付けたか否かを確認する（ＳＴ３５）。予約システム１を終了する操作を受付けた場合（ＳＴ３５−Ｙｅｓ）、予約システム１を終了する。一方、予約システム１を終了する操作を受付けていない場合（ＳＴ３５−Ｎｏ）、ＳＴ３２へ戻る。

制御部２５はＳＴ３４において、各種業務のボタンを選択する操作を受付けた場合（ＳＴ３４−Ｙｅｓ）、選択された業務のボタンが顧客対応入力であるか否かを確認する（ＳＴ３６）。顧客対応入力のボタンが選択された場合（ＳＴ３６−Ｙｅｓ）、記憶部２４に記憶される図５−１で説明した顧客対応入力画面の情報と、顧客要望データ及び顧客対応データを表示部２３に表示し、操作部２２からの操作を受付ける（ＳＴ３７）。操作部２２から画面に表示した登録ボタンの操作を受付けたか否かを確認する（ＳＴ３８）。登録ボタンの操作を受付けた場合（ＳＴ３８−Ｙｅｓ）、受付入力画面に入力された情報から顧客対応データを作成し、通信部２１を介してサーバ１０へ送信する（ＳＴ３９）。そしてＳＴ３１へ戻る。一方、ＳＴ３８において、操作部２２から登録ボタンの操作を受付けていない場合（ＳＴ３８−Ｎｏ）、操作部２２から終了ボタンの操作を受付けたか否かを確認する（ＳＴ４０）。終了ボタンの操作を受付けた場合（ＳＴ４０−Ｙｅｓ）、ＳＴ３１へ戻る。一方、終了ボタンの操作を受付けていない場合（ＳＴ４０−Ｎｏ）、ＳＴ３８へ戻る。

制御部２５はＳＴ３２において、顧客要望データを受信した場合（ＳＴ３２−Ｙｅｓ）
、受信した顧客要望データを記憶部２４へ記憶し、図１２に示す新規顧客要望データの受信通知画面を表示部２３に表示する（ＳＴ４１）。新規顧客要望データの受信通知画面に表示された「顧客対応入力へ」のボタンが選択されたか否かを確認する（ＳＴ４２）。「顧客対応入力へ」のボタンが選択された場合（ＳＴ４２−Ｙｅｓ）、ＳＴ３７へジャンプする。一方、「後で確認する」のボタンが選択された場合（ＳＴ４２−Ｎｏ）、ＳＴ３３へジャンプする。

制御部２５はＳＴ３３において、通信部２１を介して顧客対応データを受信した場合（ＳＴ３３−Ｙｅｓ）、受信した顧客対応データを記憶部２４へ記憶する（ＳＴ４３）。そしてＳＴ３４へジャンプする。また、ＳＴ３６において選択された業務のボタンが顧客対応入力では無い場合（ＳＴ３６−Ｎｏ）、選択された業務のボタンに応じて制御する（ＳＴ４４）。そして、ＳＴ３１へ戻る。なお、図３及び図５で説明した制御部２５の顧客対応入力手段２５２は、図１０のＳＴ３７〜ＳＴ４０の中で説明した処理を実行するための構成である。

なお、図２〜図１２では、新規顧客要望データ送信手段１３１と候補店舗対応状況記憶手段１３２と候補店舗対応状況データ送信手段１３３がサーバ１０の制御部１３に構成されるもの、顧客要望受付手段２５１が受付センターのクライアント２０、顧客対応入力手段２５２が店舗のクライアント２０の各制御部２５に構成されるものとして説明したが、各手段（１３１〜１３３、２５１、２５２）はそれぞれがネットワーク３０で通信可能となっていればよく、各手段がサーバ１０及びクライアント２０のいずれかに分散もしくは集中していても、予約システム１で全ての手段を備えていればよい。

１ 予約システム
１０ サーバ
１１ 通信部（サーバ）
１２ 記憶部（サーバ）
１２１ ユーザＤＢ
１２２ 店舗ＤＢ
１２３ 予約管理ＤＢ
１２４ リクエストＤＢ
１３ 制御部（サーバ）
１３１ 新規顧客要望データ送信手段
１３２ 候補店舗対応状況記憶手段
１３３ 候補店舗対応状況データ送信手段
２０ クライアント
２１ 通信部（クライアント）
２２ 操作部（クライアント）
２３ 表示部（クライアント）
２４ 記憶部（クライアント）
２５ 制御部（クライアント）
２５１ 顧客要望受付手段
２５２ 顧客対応入力手段
３０ ネットワーク

Claims (4)

1. 顧客の要望を定型の第一顧客情報と不定型の第二顧客情報として受け付け前記第一顧客情報と前記第二顧客情報を合わせて顧客要望データを生成して送信する顧客要望受付手段と、前記顧客要望データを受信して記憶するとともに、同顧客要望データに基づいて予め記憶された複数の店舗の店舗情報を検索して前記第一顧客情報に該当する候補店舗を抽出し、前記候補店舗に対する新規顧客要望データとして前記顧客要望データを送信する新規顧客要望データ送信手段と、受信した前記新規顧客要望データに対して入力された当該候補店の応答である顧客対応データを送信する顧客対応入力手段と、受信した前記顧客対応データを前記顧客要望データと関連付けて候補店舗対応状況データとして記憶する候補店舗対応状況記憶手段と、前記候補店舗対応状況データを送信する候補店舗対応状況データ送信手段とがそれぞれ通信回線で接続され、前記顧客対応入力手段は受信した前記候補店舗対応状況データに対して入力された当該候補店の応答を新たな顧客対応データとして送信することを特徴とする予約システム。
2. 前記候補店舗対応状況記憶手段は前記顧客対応データが受信される度に前記顧客要望データと関連付けて記憶された前記候補店舗対応状況データを更新して記憶し、前記候補店舗対応状況データ送信手段は前記候補店舗対応状況データが更新される度に同候補店舗対応状況データを送信することを特徴とする請求項１に記載の予約システム。
3. 前記第一顧客情報は、顧客が希望する予約内容を予め定められた複数のパターンからの選択により入力する情報であり、前記第二顧客情報は、顧客が希望する予約内容を直接入力する情報であることを特徴とする請求項１に記載の予約システム。
4. 前記顧客対応データは、当該顧客に対する当該候補店の応答を予め用意された複数のステータスからの選択により入力する情報を含み、前記ステータスには少なくとも、予約の成立、予約の不成立、前記顧客と交渉中、を各々示すものが含まれることを特徴とする請求項１に記載の予約システム。
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

Images