顧客来店通知方法、顧客来店通知システム及び役席端末
【課題】役席端末の混雑状態に応じて、来店通知の表示を制御する。
【解決手段】役席端末220、顧客取引端末210及び来店通知サーバ100を備える顧客来店通知システム10で行われ、以下の過程を備えて構成される。先ず、顧客重要度を含む顧客情報、及び、顧客が使用している顧客取引端末の情報を含む取引状況を、来店通知データとして受け取る。次に、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、及び、顧客取引端末及び顧客重要度に応じて定められた待機時間を含む来店通知条件を読み出す。次に、顧客重要度及び来店通知フラグから、来店通知表示が必須か否かを判定する。来店通知表示が必須でない場合に、役席端末が混雑しているか否の判定を来店通知待機時間が経過するまで繰り返し行う。来店通知表示が必須の場合、又は、役席端末が混雑していない場合は、来店通知表示を行う。
【解決手段】役席端末220、顧客取引端末210及び来店通知サーバ100を備える顧客来店通知システム10で行われ、以下の過程を備えて構成される。先ず、顧客重要度を含む顧客情報、及び、顧客が使用している顧客取引端末の情報を含む取引状況を、来店通知データとして受け取る。次に、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、及び、顧客取引端末及び顧客重要度に応じて定められた待機時間を含む来店通知条件を読み出す。次に、顧客重要度及び来店通知フラグから、来店通知表示が必須か否かを判定する。来店通知表示が必須でない場合に、役席端末が混雑しているか否の判定を来店通知待機時間が経過するまで繰り返し行う。来店通知表示が必須の場合、又は、役席端末が混雑していない場合は、来店通知表示を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、金融機関の営業店などに重要顧客が来店したことを営業店内の端末に通知する、顧客来店通知方法及び顧客来店通知システムと、顧客来店通知システムが備える役席端末に関するものである。
【背景技術】
【０００２】
金融機関の営業店などでは、顧客が来店して取引を行う場合に、カードや通帳に含まれる顧客識別データが、金融機関のセンターに送られる。金融機関のセンターでは、当該顧客が重要顧客である場合に、重要顧客が来店して取引している旨の、来店通知データを作成することがある（例えば、特許文献１参照）。この来店通知データは、重要顧客が来店している営業店の、所定の端末（役席端末）に通知される。役席端末では、来店通知データを受信すると、モニタなどに来店通知が表示される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平７−８５１８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述の従来例では、役席端末は、来店通知データを受信すると、即時に来店通知の表示を行う。ここで、役席端末では、高額取引などの特定の取引の場合に金融機関のセンターの端末や営業店の窓口に設置される営業店端末などから送信される承認依頼に対して、取引実行の承認を行う承認業務が行われていることが多い。従来例の構成では、役席端末が承認業務で混雑している状態であっても、来店通知の表示がなされることになり、役席端末での承認業務の効率を低下させる原因となっていた。
【０００５】
この発明は、上述の問題点に鑑みてなされたものであり、この発明の目的は、役席端末の混雑状態に応じて、来店通知の表示を制御する、顧客来店通知システム及び顧客来店通知方法を提供することにある。
【課題を解決するための手段】
【０００６】
上述した目的を達成するために、この発明の顧客来店通知方法は、役席端末、顧客取引端末及び来店通知サーバを備える顧客来店通知システムで行われ、以下の過程を備えて構成される。
【０００７】
先ず、顧客重要度を含む顧客情報、及び、顧客が使用している顧客取引端末を特定する取引情報を、来店通知データとして受け取る。次に、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、並びに、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間を含む来店通知条件を読み出す。次に、顧客重要度及び来店通知フラグから、来店通知表示が必須か否かを判定する。来店通知表示が必須でない場合には、当該役席端末が混雑しているか否かの判定が、来店通知待機時間が経過するまで繰り返し行われる。来店通知表示が必須の場合、又は、役席端末が混雑していない場合は、来店通知表示を行う。
【０００８】
また、この発明の役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システム、及び、当該顧客来店通知システムが備える役席端末は、来店通知条件取得部と、顧客属性判定部と、閾値判定部と、待機処理部と、来店通知表示部とを備えて構成される。
【０００９】
来店通知条件取得部は、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間、顧客重要度に応じて定められた来店通知許可閾値、並びに、顧客取引端末及び顧客重要度に応じて定められた検知間隔を含む来店通知条件を読み出す。顧客属性判定部は、来店通知サーバから受け取る来店通知データに含まれる顧客重要度と、来店通知フラグから、来店通知表示が必須か否かを判定する。閾値判定部は、役席端末の承認待機数を取得し、承認待機数が来店通知許可閾値以下であるか否かを判定する。待機処理部は、来店通知待機時間を待機時間として設定し、待機時間が０よりも大きいか否かを判定し、待機時間が０よりも大きい場合は、検知間隔の間待機するとともに、待機時間から検知間隔を減算する。来店通知表示部は、来店通知表示を行う。
【発明の効果】
【００１０】
この発明の顧客来店通知システム及び顧客来店通知方法によれば、役席端末の混雑状態に応じて、来店通知の表示を制御する。すなわち、役席端末が承認業務で混雑している場合は、来店通知の表示が抑制されるので、役席端末での業務効率の低下を抑制することができる。
【図面の簡単な説明】
【００１１】
【図１】顧客来店通知システムの概略図である。
【図２】来店通知サーバの概略的な機能ブロック図である。
【図３】役席端末の概略的な機能ブロック図である。
【図４】来店通知サーバの処理フローを示す図である。
【図５】役席端末の処理フローを示す図である。
【図６】来店通知の表示例を示す図である。
【図７】来店通知サーバの概略的な機能ブロック図である。
【図８】役席端末の概略的な機能ブロック図である。
【図９】来店通知サーバの処理フローを示す図である。
【発明を実施するための形態】
【００１２】
以下、図を参照して、この発明の実施形態について説明するが、この発明が理解できる程度に概略的に示したものに過ぎない。また、以下、この発明の好適な構成例につき説明するが、数値的条件などは、単なる好適例にすぎない。従って、この発明は以下の実施形態に限定されるものではなく、この発明の構成の範囲を逸脱せずにこの発明の効果を達成できる多くの変更又は変形を行うことができる。
【００１３】
（第１実施形態）
図１を参照して、顧客来店通知システムについて説明する。図１は、顧客来店通知システムの概略図である。この顧客来店通知システム１０は、金融機関のセンター１００と、１又は複数の営業店２００を備えて構成される。
【００１４】
各営業店２００には、来店した顧客が操作する現金自動預け払い機（ＡＴＭ）２１２、窓口担当者が使用する窓口端末２１４が設けられている。また、各営業店２００には、役席端末２２０が設けられている。これらＡＴＭ２１２及び窓口端末２１４（以下、顧客取引端末２１０と総称することもある。）と、役席端末２２０とは、店舗内ネットワークで接続されている。
【００１５】
金融機関のセンター１００には、来店通知サーバ１１０及び顧客データベース（ＤＢ）１２０が設けられている。顧客ＤＢ１２０には、顧客属性データが格納されている。来店通知サーバ１１０は、各営業店２００の店舗内ネットワークに接続されている。
【００１６】
顧客取引端末２１０は、顧客のカードや通帳に設けられている磁気ストライプなどから、顧客の口座番号などの顧客識別データを読み取り、センター１００に送信する（図中、矢印Ｓ１０１で示す）。この顧客識別データの一例を表１に示す。
【００１７】
【表１】
【００１８】
センター１００では、顧客識別データから、来店している顧客が重要顧客である場合は、来店通知データを作成し、作成した来店通知データを営業店２００の役席端末２２２に送る（図中、矢印Ｓ１０３で示す）。また、承認業務が必要な場合は、承認依頼が窓口端末２１４などから役席端末２２０に送られる（図中、矢印Ｓ１０５で示す）。
【００１９】
図２を参照して、センター１００が備える来店通知サーバ１１０について説明する。図２は、来店通知サーバの概略的な機能ブロック図である。来店通知サーバ１１０は、制御部１３０、記憶部１４０、送受信部１５０、顧客属性データ取得部１６０及び来店通知データ作成部１７０を備えている。記憶部１４０は、例えば、ＲＯＭ及びＲＡＭで構成される。ＲＯＭには、来店通知サーバ１１０の制御を行うプログラムが格納されていて、制御部１３０は、このプログラムを記憶部１４０から読み出して実行することにより、来店通知サーバ１１０の制御を行う。また、ＲＡＭには、来店通知サーバ１１０での処理結果が適宜格納される。送受信部１５０は、各営業店２００との間での送受信を行う。
【００２０】
顧客属性データ取得部１６０及び来店通知データ作成部１７０の機能については、後述する。
【００２１】
図３を参照して、役席端末について説明する。図３は、役席端末の概略的な機能ブロック図である。
【００２２】
役席端末２２０は、制御部２３０、記憶部２４０、送受信部２５０、入出力部２８０、待機処理部２８２、承認処理部２８４、顧客属性判定部２８６、来店通知条件取得部２８８、閾値判定部２９０及び来店通知表示部２９２を備えている。記憶部２４０は、例えば、ＲＯＭ及びＲＡＭで構成される。ＲＯＭには、役席端末２２０の制御を行うプログラムが格納されていて、制御部２３０は、このプログラムを記憶部２４０から読み出して実行することにより役席端末２２０の制御を行う。また、ＲＡＭには、役席端末２２０での処理結果が適宜格納される。送受信部２５０は、金融機関のセンター１００や、内部ネットワークに接続されている顧客取引端末２１０などとの間で送受信を行う。
【００２３】
入出力部２８０は、キーボード、マウスなどの入力手段と、液晶ディスプレイ、プリンタなどの出力手段を備えている。送受信部２５０が承認依頼を受け取ると、入出力部２８０は、承認処理用の画面を、役席端末２２０を利用する者（以下、単に役席と称する。）に対して表示する。承認依頼を受けた役席が、入出力部２８０を介して所定の入力を行うと、承認処理部２８４が、その入力内容に応じて承認処理を行う。この承認処理については、一般に金融機関で行われる処理であるので、ここでは説明を省略する。
【００２４】
待機処理部２８２、顧客属性判定部２８６、来店通知条件取得部２８８、閾値判定部２９０及び来店通知表示部２９２が、いわゆる顧客来店通知に用いられる機能手段である。この各機能手段が実現する機能については、後述する。
【００２５】
図４及び図５を参照して、顧客来店通知システムを用いた顧客来店通知方法について説明する。図４は、来店通知サーバの処理フローを示す図である。また、図５は、役席端末の処理フローを示す図である。
【００２６】
営業店２００に来店した顧客が、顧客のカードや通帳を用いてＡＴＭ２１２あるいは窓口２１４で取引を開始すると、顧客取引端末２１０は、顧客のカードや通帳に設けられている磁気ストライプなどから、顧客識別データを読み取り、センター１００に送信する。
【００２７】
センター１００の来店通知サーバ１１０では、ステップ（以下、ステップをＳで示す。）１０において、送受信部１５０が顧客識別データを送信した顧客取引端末２１０の種別を示す取引チャネル情報（取引チャネル機種及び機番）と共に顧客識別データを取得する。この顧客識別データ及び取引チャネル情報は、記憶部１４０に格納される。顧客属性データ取得部１６０は、顧客識別データの取得に応答して、顧客データベース１２０にアクセスし、顧客識別データに対応する顧客属性データを取得する。この顧客属性データは、記憶部１４０に格納される。
【００２８】
次に、Ｓ１２において、来店通知データ作成部１７０は、記憶部１４０に格納されている顧客属性データから顧客が重要顧客であるか否かを判定する。顧客が重要顧客である場合は、来店通知データ作成部１７０は、顧客識別データ、顧客属性データ、及び取引チャネル情報を含んだ来店通知データを作成する。この来店通知データは、記憶部１４０に格納される。
【００２９】
来店通知データの一例を表２に示す。この来店通知データには、顧客識別データに加えて、顧客氏名、生年月日、顧客重要度（顧客ＶＩＰランク）などを含む顧客情報と、顧客が取引を行っている顧客取引端末（取引端末）を特定する取引情報とが格納されている。この構成例では、顧客重要度はＡからＤの４ランクに分類されている。Ａランクが最も重要度が高く、Ｂ、Ｃ、Ｄの順に重要度が低くなる。
【００３０】
【表２】
【００３１】
来店通知データ作成部１７０により来店通知データが作成された場合は、Ｓ１４において、送受信部１５０が、この来店通知データを、その顧客が来店している営業店２００に送る。
【００３２】
営業店２００では、Ｓ２０において、役席端末２２０の送受信部２５０が、この来店通知データを受け取り、記憶部２４０に格納する。
【００３３】
次に、Ｓ２２において、来店通知条件取得部２８８は、記憶部２４０に格納されている来店通知条件を読みだす。来店通知条件には、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間が含まれている。顧客重要度に応じて定められた来店通知許可閾値、並びに、顧客取引端末及び顧客重要度に応じて定められた混雑状態検知間隔（以下、検知間隔と称することもある。）、その他、来店通知条件には、表示抑制条件（以下、抑制条件と称することもある。）が含まれている場合もある。これらの来店通知条件の構成例を表３〜６に示す。
【００３４】
【表３】
【００３５】
【表４】
【００３６】
【表５】
【００３７】
【表６】
【００３８】
表３は、条件１として、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグを示している。表４は、条件２として、顧客重要度に応じて定められた来店通知許可閾値を示している。表５は、混雑状態検知時間として、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間、並びに、検知間隔を示している。また、表６は、抑制条件を示している。
【００３９】
次に、Ｓ２４において、顧客属性判定部２８６が、来店通知が必須であるか否かを判定する。この過程では、先ず、顧客属性判定部２８６が、来店通知データに含まれる顧客重要度を読みだして、顧客重要度を判定する。例えば、来店通知条件として、表３に示される条件１を用いる場合、顧客重要度がＡランクの場合は来店通知が必須であり、役席端末２２０の混雑状況にかかわらず、Ｓ４０の来店通知表示を行う。一方、顧客重要度がＢ〜Ｄランクの場合は来店通知が必須ではなく、役席端末２２０が混雑している場合は来店通知を行わず、役席端末２２０が混雑していない場合に来店通知を行う。
【００４０】
なお、ここでは、顧客属性の判定を顧客重要度に基づいて行う例について説明するが、この例に限定されない。すなわち、この顧客属性の判定では、顧客重要度だけでなく、表６に示されているように、顧客の「生年月日」、「既婚／未婚」及び「役職」を抑制条件として用いてもよい。例えば、顧客の生年月日から、顧客が定年退職を控えていると推測される場合や役職者が来店した場合は、顧客重要度がＡランクでなくても、来店通知を必須とする構成にすることができる。あるいは、既婚者の顧客重要度を高めて、未婚者より既婚者を優先して来店通知を行うなどしてもよい。
【００４１】
表２に示す来店通知データの例では、顧客重要度がＢランクであるため、来店通知は必須ではなく、続いて、Ｓ２６の承認待機数取得が行われる。Ｓ２６では、閾値判定部２９０が、記憶部２４０に格納されている、役席端末２２０が受け付けた承認依頼の数を承認待機数として取得する。この実施形態では、承認待機数を１０として説明する。
【００４２】
次に、Ｓ２８において、閾値判定部２９０が、承認待機数が、来店通知許可閾値（以下、閾値と称する。）以下であるか否かを比較することにより、役席端末２２０が混雑しているか否かを判定する。承認待機数が閾値以下である場合は、役席端末２２０が混雑していないと判定され、続いて、Ｓ４０の来店通知表示が行われる。一方、承認待機数が閾値より大きい場合は、役席端末２２０が混雑していると判定され、一定時間待機する。この閾値は、表４に示される条件２を用いて定められる。
【００４３】
この実施形態では、顧客重要度がＢランクであるため、表４に示すように、閾値は７となる。従って、閾値判定部２９０は、承認待機数（＝１０）が閾値（＝７）より大きい、すなわち、役席端末２２０が混雑していると判定する。従って、続いて、Ｓ３０の処理が行われる。
【００４４】
Ｓ３０では、待機処理部２８２が、待機時間が０よりも大きいか否かが判定される。待機時間が０よりも大きい場合は、続いて、Ｓ３２の過程で、一定時間待機する。一方、待機時間が０以下の場合は、待機時間切れとして処理を終了する。
【００４５】
ここで、待機時間は、Ｓ２２の来店通知条件取得の過程で、表５に示される来店通知待機時間の値として設定される。来店通知待機時間は、表５に示すように、顧客重要度と、顧客取引端末２１０の取引チャネル情報とに応じて予め定められている。この実施形態では、表２に示すように、顧客重要度がＢランクであり、また、顧客取引端末２１０がＡＴＭであるので、来店通知待機時間は２０秒である。従って、待機時間は２０秒と設定される。この、待機時間（＝２０秒）は０秒よりも大きいので、続いて、Ｓ３２の過程により、予め定められた検知間隔の間、待機する。検知間隔は、表５に示すように、顧客重要度と、顧客取引端末の取引チャネル情報とに応じて予め定められている。この実施形態では、表２に示すように、顧客重要度がＢランクであり、また、顧客取引端末がＡＴＭであるので、検知間隔は５秒となる。一定時間として、検知間隔の５秒間待機した後、再び、Ｓ２６及びＳ２８の過程において、閾値判定部２９０が承認待機数を取得した後、役席端末２２０が混雑しているか否かを判定する。また、Ｓ３２の過程では、待機処理部２８２は、待機時間（＝２０秒）から検知間隔（５秒）を減算し、待機時間を１５秒とする。その後、Ｓ２６の処理が行われる。すなわち、Ｓ２６の処理は、検知間隔ごとに行われる。
【００４６】
Ｓ２６において、閾値判定部２９０が取得した承認待機数が７に下がっていると、Ｓ２８での比較により、承認待機数（＝７）が閾値（＝７）以下となるため、続いてＳ４０の来店通知表示が行われる。
【００４７】
この実施形態では、役席端末２２０の混雑状態の判定を、承認待機数と、閾値との比較を行う例について説明しているが、この例に限定されない。例えば、表６に示されているように、顧客の「取引期間」、「勤続年数」及び「オペレータＩＤ」などの抑制条件を用いてもよい。この場合、取引期間や勤続年数が一定期間未満の顧客に対して、閾値を表４に示される値よりも低く設定して、表示頻度を抑制しても良い。また、顧客取引端末が窓口端末であり、その窓口端末のオペレータが熟練者である場合なども、表示頻度を抑制しても良い。
【００４８】
一方、抑制条件として、役席端末２２０での業務状況データを用いても良い。例えば、閾値判定部２９０は承認待機数を取引内容から即時承認が必要なもののみを判別して計数し、即時承認が必要とされないものは、閾値と比較する対象となる承認待機数に含めないようにしても良い。一方、１つの承認処理に引き続いて他の承認処理が必要とされる取引内容の承認依頼の場合には、閾値判定部２９０は承認待機数によらず、役席端末２２０を混雑状態と判定するなどしても良い。
【００４９】
このＳ２６〜Ｓ３２までの過程は、待機時間が０以下になるまで繰り返される。
【００５０】
Ｓ４０の来店通知表示の過程では、来店通知表示部２９２が、入出力部２８０に来店通知表示を行う指示を送り、入出力部２３０は、役席端末２２０のディスプレイ上に表示する。図６に、来店通知表示の一例を示している。
【００５１】
この実施形態の来店通知システム及び来店通知方法では、重要顧客が来店している場合に、顧客重要度がＡランク以外の重要顧客に対しては、役席端末２２０の混雑状態に応じて、来店通知の表示を制御する。すなわち、役席端末２２０が承認業務で混雑している場合は、来店通知の表示が抑制される。このため、役席端末２２０での業務効率の低下を抑制することができる。
【００５２】
（第２実施形態）
図７及び図８を参照して、第２実施形態の来店通知サーバ及び役席端末について説明する。図７は、来店通知サーバの概略的な機能ブロック図である。図８は、役席端末の概略的な機能ブロック図である。
【００５３】
来店通知サーバ１１２は、制御部１３０、記憶部１４０、送受信部１５０、顧客属性データ取得部１６０、来店通知データ作成部１７０、待機処理部１８２、顧客属性判定部１８６、来店通知条件取得部１８８及び閾値判定部１９０を備えている。また、役席端末２２２は、制御部２３０、記憶部２４０、送受信部２５０、入出力部２８０、承認処理部２８４及び来店通知表示部２９２を備えている。
【００５４】
第２実施形態では、第１実施形態の役席端末２２０に設けられている待機処理部２８２、顧客属性判定部２８６、来店通知条件取得２８８部及び閾値判定部２４０が、待機処理部１８２、顧客属性判定部１８６、来店通知条件取得部１８８及び閾値判定部１９０として来店通知サーバ１１２に設けられている点が、第１実施形態と異なっている。それ以外の構成や、各機能手段が実現する機能については、第１実施形態と同様であるので、重複する説明を省略する。
【００５５】
図９を参照して、顧客来店通知システムを用いた顧客来店通知方法について説明する。図９は、来店通知サーバの処理フローを示す図である。第２実施形態では、来店通知サーバ１１２が、役席端末２２２の混雑状況を判定して、来店通知表示を行うか否かを判定する。従って、役席端末２２２は、受け取った来店通知データをそのまま表示する。
【００５６】
Ｓ１０及びＳ１２の処理については、図４を参照して説明した第１実施形態の来店通知サーバの処理と同様である。第２実施形態では、図５を参照して説明した第１実施形態の役席端末２２２が行うＳ２２〜Ｓ３２の処理が、来店通知サーバ１１２で行われる。このため、第１実施形態のＳ１４及びＳ２０の来店通知データの送受信の過程は行われない。また、Ｓ４１の来店通知表示の過程では、役席端末２２２に対して、来店通知データを送り、役席端末２２２は受け取った来店通知データをそのまま表示する構成にすれば良い。
【００５７】
なお、第２実施形態の構成では、役席端末２２２が混雑しているか否かの判定が、来店通知サーバ１１２でなされるので、承認依頼は来店通知サーバ１１２を経て所定の役席端末２２２に送られる。
【００５８】
この第２実施形態の構成によれば、第１実施形態と同様の効果を得るにあたり、来店通知サーバ１１２の構成のみが従来と異なっていて、役席端末２２２の構成は従来と同様の構成にすることができる。
【００５９】
なお、上述した各実施形態では、１つの役席端末について、その構成及び動作を説明したが、営業店に複数の役席端末が設けられていても良い。第１実施形態の構成では、複数の役席端末に同時に来店通知データが送られ、各役席端末では、その混雑状況に応じて来店通知の表示がなされる。また、第２実施形態の構成では、来店通知が必須でない場合は、役席端末ごとの混雑状況を判定し、混雑していない役席端末に選択的に来店通知データを送る構成にすることができる。
【符号の説明】
【００６０】
１０ 顧客来店通知システム
１００ センター
１１０、１１２ 来店通知サーバ
１２０ 顧客ＤＢ
１３０、２３０ 制御部
１４０、２４０ 記憶部
１５０、２５０ 送受信部
１６０ 顧客属性データ取得部
１７０ 来店通知データ作成部
１８２、２８２ 待機処理部
１８６、２８６ 顧客属性判定部
１８８、２８８ 来店通知条件取得部
１９０、２９０ 閾値判定部
２００ 営業店
２１０ 顧客取引端末
２１２ ＡＴＭ
２１４ 窓口端末
２２０、２２２ 役席端末
２８０ 入出力部
２８４ 承認処理部
２９２ 来店通知表示部
【技術分野】
【０００１】
この発明は、金融機関の営業店などに重要顧客が来店したことを営業店内の端末に通知する、顧客来店通知方法及び顧客来店通知システムと、顧客来店通知システムが備える役席端末に関するものである。
【背景技術】
【０００２】
金融機関の営業店などでは、顧客が来店して取引を行う場合に、カードや通帳に含まれる顧客識別データが、金融機関のセンターに送られる。金融機関のセンターでは、当該顧客が重要顧客である場合に、重要顧客が来店して取引している旨の、来店通知データを作成することがある（例えば、特許文献１参照）。この来店通知データは、重要顧客が来店している営業店の、所定の端末（役席端末）に通知される。役席端末では、来店通知データを受信すると、モニタなどに来店通知が表示される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平７−８５１８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述の従来例では、役席端末は、来店通知データを受信すると、即時に来店通知の表示を行う。ここで、役席端末では、高額取引などの特定の取引の場合に金融機関のセンターの端末や営業店の窓口に設置される営業店端末などから送信される承認依頼に対して、取引実行の承認を行う承認業務が行われていることが多い。従来例の構成では、役席端末が承認業務で混雑している状態であっても、来店通知の表示がなされることになり、役席端末での承認業務の効率を低下させる原因となっていた。
【０００５】
この発明は、上述の問題点に鑑みてなされたものであり、この発明の目的は、役席端末の混雑状態に応じて、来店通知の表示を制御する、顧客来店通知システム及び顧客来店通知方法を提供することにある。
【課題を解決するための手段】
【０００６】
上述した目的を達成するために、この発明の顧客来店通知方法は、役席端末、顧客取引端末及び来店通知サーバを備える顧客来店通知システムで行われ、以下の過程を備えて構成される。
【０００７】
先ず、顧客重要度を含む顧客情報、及び、顧客が使用している顧客取引端末を特定する取引情報を、来店通知データとして受け取る。次に、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、並びに、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間を含む来店通知条件を読み出す。次に、顧客重要度及び来店通知フラグから、来店通知表示が必須か否かを判定する。来店通知表示が必須でない場合には、当該役席端末が混雑しているか否かの判定が、来店通知待機時間が経過するまで繰り返し行われる。来店通知表示が必須の場合、又は、役席端末が混雑していない場合は、来店通知表示を行う。
【０００８】
また、この発明の役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システム、及び、当該顧客来店通知システムが備える役席端末は、来店通知条件取得部と、顧客属性判定部と、閾値判定部と、待機処理部と、来店通知表示部とを備えて構成される。
【０００９】
来店通知条件取得部は、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間、顧客重要度に応じて定められた来店通知許可閾値、並びに、顧客取引端末及び顧客重要度に応じて定められた検知間隔を含む来店通知条件を読み出す。顧客属性判定部は、来店通知サーバから受け取る来店通知データに含まれる顧客重要度と、来店通知フラグから、来店通知表示が必須か否かを判定する。閾値判定部は、役席端末の承認待機数を取得し、承認待機数が来店通知許可閾値以下であるか否かを判定する。待機処理部は、来店通知待機時間を待機時間として設定し、待機時間が０よりも大きいか否かを判定し、待機時間が０よりも大きい場合は、検知間隔の間待機するとともに、待機時間から検知間隔を減算する。来店通知表示部は、来店通知表示を行う。
【発明の効果】
【００１０】
この発明の顧客来店通知システム及び顧客来店通知方法によれば、役席端末の混雑状態に応じて、来店通知の表示を制御する。すなわち、役席端末が承認業務で混雑している場合は、来店通知の表示が抑制されるので、役席端末での業務効率の低下を抑制することができる。
【図面の簡単な説明】
【００１１】
【図１】顧客来店通知システムの概略図である。
【図２】来店通知サーバの概略的な機能ブロック図である。
【図３】役席端末の概略的な機能ブロック図である。
【図４】来店通知サーバの処理フローを示す図である。
【図５】役席端末の処理フローを示す図である。
【図６】来店通知の表示例を示す図である。
【図７】来店通知サーバの概略的な機能ブロック図である。
【図８】役席端末の概略的な機能ブロック図である。
【図９】来店通知サーバの処理フローを示す図である。
【発明を実施するための形態】
【００１２】
以下、図を参照して、この発明の実施形態について説明するが、この発明が理解できる程度に概略的に示したものに過ぎない。また、以下、この発明の好適な構成例につき説明するが、数値的条件などは、単なる好適例にすぎない。従って、この発明は以下の実施形態に限定されるものではなく、この発明の構成の範囲を逸脱せずにこの発明の効果を達成できる多くの変更又は変形を行うことができる。
【００１３】
（第１実施形態）
図１を参照して、顧客来店通知システムについて説明する。図１は、顧客来店通知システムの概略図である。この顧客来店通知システム１０は、金融機関のセンター１００と、１又は複数の営業店２００を備えて構成される。
【００１４】
各営業店２００には、来店した顧客が操作する現金自動預け払い機（ＡＴＭ）２１２、窓口担当者が使用する窓口端末２１４が設けられている。また、各営業店２００には、役席端末２２０が設けられている。これらＡＴＭ２１２及び窓口端末２１４（以下、顧客取引端末２１０と総称することもある。）と、役席端末２２０とは、店舗内ネットワークで接続されている。
【００１５】
金融機関のセンター１００には、来店通知サーバ１１０及び顧客データベース（ＤＢ）１２０が設けられている。顧客ＤＢ１２０には、顧客属性データが格納されている。来店通知サーバ１１０は、各営業店２００の店舗内ネットワークに接続されている。
【００１６】
顧客取引端末２１０は、顧客のカードや通帳に設けられている磁気ストライプなどから、顧客の口座番号などの顧客識別データを読み取り、センター１００に送信する（図中、矢印Ｓ１０１で示す）。この顧客識別データの一例を表１に示す。
【００１７】
【表１】
【００１８】
センター１００では、顧客識別データから、来店している顧客が重要顧客である場合は、来店通知データを作成し、作成した来店通知データを営業店２００の役席端末２２２に送る（図中、矢印Ｓ１０３で示す）。また、承認業務が必要な場合は、承認依頼が窓口端末２１４などから役席端末２２０に送られる（図中、矢印Ｓ１０５で示す）。
【００１９】
図２を参照して、センター１００が備える来店通知サーバ１１０について説明する。図２は、来店通知サーバの概略的な機能ブロック図である。来店通知サーバ１１０は、制御部１３０、記憶部１４０、送受信部１５０、顧客属性データ取得部１６０及び来店通知データ作成部１７０を備えている。記憶部１４０は、例えば、ＲＯＭ及びＲＡＭで構成される。ＲＯＭには、来店通知サーバ１１０の制御を行うプログラムが格納されていて、制御部１３０は、このプログラムを記憶部１４０から読み出して実行することにより、来店通知サーバ１１０の制御を行う。また、ＲＡＭには、来店通知サーバ１１０での処理結果が適宜格納される。送受信部１５０は、各営業店２００との間での送受信を行う。
【００２０】
顧客属性データ取得部１６０及び来店通知データ作成部１７０の機能については、後述する。
【００２１】
図３を参照して、役席端末について説明する。図３は、役席端末の概略的な機能ブロック図である。
【００２２】
役席端末２２０は、制御部２３０、記憶部２４０、送受信部２５０、入出力部２８０、待機処理部２８２、承認処理部２８４、顧客属性判定部２８６、来店通知条件取得部２８８、閾値判定部２９０及び来店通知表示部２９２を備えている。記憶部２４０は、例えば、ＲＯＭ及びＲＡＭで構成される。ＲＯＭには、役席端末２２０の制御を行うプログラムが格納されていて、制御部２３０は、このプログラムを記憶部２４０から読み出して実行することにより役席端末２２０の制御を行う。また、ＲＡＭには、役席端末２２０での処理結果が適宜格納される。送受信部２５０は、金融機関のセンター１００や、内部ネットワークに接続されている顧客取引端末２１０などとの間で送受信を行う。
【００２３】
入出力部２８０は、キーボード、マウスなどの入力手段と、液晶ディスプレイ、プリンタなどの出力手段を備えている。送受信部２５０が承認依頼を受け取ると、入出力部２８０は、承認処理用の画面を、役席端末２２０を利用する者（以下、単に役席と称する。）に対して表示する。承認依頼を受けた役席が、入出力部２８０を介して所定の入力を行うと、承認処理部２８４が、その入力内容に応じて承認処理を行う。この承認処理については、一般に金融機関で行われる処理であるので、ここでは説明を省略する。
【００２４】
待機処理部２８２、顧客属性判定部２８６、来店通知条件取得部２８８、閾値判定部２９０及び来店通知表示部２９２が、いわゆる顧客来店通知に用いられる機能手段である。この各機能手段が実現する機能については、後述する。
【００２５】
図４及び図５を参照して、顧客来店通知システムを用いた顧客来店通知方法について説明する。図４は、来店通知サーバの処理フローを示す図である。また、図５は、役席端末の処理フローを示す図である。
【００２６】
営業店２００に来店した顧客が、顧客のカードや通帳を用いてＡＴＭ２１２あるいは窓口２１４で取引を開始すると、顧客取引端末２１０は、顧客のカードや通帳に設けられている磁気ストライプなどから、顧客識別データを読み取り、センター１００に送信する。
【００２７】
センター１００の来店通知サーバ１１０では、ステップ（以下、ステップをＳで示す。）１０において、送受信部１５０が顧客識別データを送信した顧客取引端末２１０の種別を示す取引チャネル情報（取引チャネル機種及び機番）と共に顧客識別データを取得する。この顧客識別データ及び取引チャネル情報は、記憶部１４０に格納される。顧客属性データ取得部１６０は、顧客識別データの取得に応答して、顧客データベース１２０にアクセスし、顧客識別データに対応する顧客属性データを取得する。この顧客属性データは、記憶部１４０に格納される。
【００２８】
次に、Ｓ１２において、来店通知データ作成部１７０は、記憶部１４０に格納されている顧客属性データから顧客が重要顧客であるか否かを判定する。顧客が重要顧客である場合は、来店通知データ作成部１７０は、顧客識別データ、顧客属性データ、及び取引チャネル情報を含んだ来店通知データを作成する。この来店通知データは、記憶部１４０に格納される。
【００２９】
来店通知データの一例を表２に示す。この来店通知データには、顧客識別データに加えて、顧客氏名、生年月日、顧客重要度（顧客ＶＩＰランク）などを含む顧客情報と、顧客が取引を行っている顧客取引端末（取引端末）を特定する取引情報とが格納されている。この構成例では、顧客重要度はＡからＤの４ランクに分類されている。Ａランクが最も重要度が高く、Ｂ、Ｃ、Ｄの順に重要度が低くなる。
【００３０】
【表２】
【００３１】
来店通知データ作成部１７０により来店通知データが作成された場合は、Ｓ１４において、送受信部１５０が、この来店通知データを、その顧客が来店している営業店２００に送る。
【００３２】
営業店２００では、Ｓ２０において、役席端末２２０の送受信部２５０が、この来店通知データを受け取り、記憶部２４０に格納する。
【００３３】
次に、Ｓ２２において、来店通知条件取得部２８８は、記憶部２４０に格納されている来店通知条件を読みだす。来店通知条件には、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間が含まれている。顧客重要度に応じて定められた来店通知許可閾値、並びに、顧客取引端末及び顧客重要度に応じて定められた混雑状態検知間隔（以下、検知間隔と称することもある。）、その他、来店通知条件には、表示抑制条件（以下、抑制条件と称することもある。）が含まれている場合もある。これらの来店通知条件の構成例を表３〜６に示す。
【００３４】
【表３】
【００３５】
【表４】
【００３６】
【表５】
【００３７】
【表６】
【００３８】
表３は、条件１として、顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグを示している。表４は、条件２として、顧客重要度に応じて定められた来店通知許可閾値を示している。表５は、混雑状態検知時間として、顧客取引端末及び顧客重要度に応じて定められた来店通知待機時間、並びに、検知間隔を示している。また、表６は、抑制条件を示している。
【００３９】
次に、Ｓ２４において、顧客属性判定部２８６が、来店通知が必須であるか否かを判定する。この過程では、先ず、顧客属性判定部２８６が、来店通知データに含まれる顧客重要度を読みだして、顧客重要度を判定する。例えば、来店通知条件として、表３に示される条件１を用いる場合、顧客重要度がＡランクの場合は来店通知が必須であり、役席端末２２０の混雑状況にかかわらず、Ｓ４０の来店通知表示を行う。一方、顧客重要度がＢ〜Ｄランクの場合は来店通知が必須ではなく、役席端末２２０が混雑している場合は来店通知を行わず、役席端末２２０が混雑していない場合に来店通知を行う。
【００４０】
なお、ここでは、顧客属性の判定を顧客重要度に基づいて行う例について説明するが、この例に限定されない。すなわち、この顧客属性の判定では、顧客重要度だけでなく、表６に示されているように、顧客の「生年月日」、「既婚／未婚」及び「役職」を抑制条件として用いてもよい。例えば、顧客の生年月日から、顧客が定年退職を控えていると推測される場合や役職者が来店した場合は、顧客重要度がＡランクでなくても、来店通知を必須とする構成にすることができる。あるいは、既婚者の顧客重要度を高めて、未婚者より既婚者を優先して来店通知を行うなどしてもよい。
【００４１】
表２に示す来店通知データの例では、顧客重要度がＢランクであるため、来店通知は必須ではなく、続いて、Ｓ２６の承認待機数取得が行われる。Ｓ２６では、閾値判定部２９０が、記憶部２４０に格納されている、役席端末２２０が受け付けた承認依頼の数を承認待機数として取得する。この実施形態では、承認待機数を１０として説明する。
【００４２】
次に、Ｓ２８において、閾値判定部２９０が、承認待機数が、来店通知許可閾値（以下、閾値と称する。）以下であるか否かを比較することにより、役席端末２２０が混雑しているか否かを判定する。承認待機数が閾値以下である場合は、役席端末２２０が混雑していないと判定され、続いて、Ｓ４０の来店通知表示が行われる。一方、承認待機数が閾値より大きい場合は、役席端末２２０が混雑していると判定され、一定時間待機する。この閾値は、表４に示される条件２を用いて定められる。
【００４３】
この実施形態では、顧客重要度がＢランクであるため、表４に示すように、閾値は７となる。従って、閾値判定部２９０は、承認待機数（＝１０）が閾値（＝７）より大きい、すなわち、役席端末２２０が混雑していると判定する。従って、続いて、Ｓ３０の処理が行われる。
【００４４】
Ｓ３０では、待機処理部２８２が、待機時間が０よりも大きいか否かが判定される。待機時間が０よりも大きい場合は、続いて、Ｓ３２の過程で、一定時間待機する。一方、待機時間が０以下の場合は、待機時間切れとして処理を終了する。
【００４５】
ここで、待機時間は、Ｓ２２の来店通知条件取得の過程で、表５に示される来店通知待機時間の値として設定される。来店通知待機時間は、表５に示すように、顧客重要度と、顧客取引端末２１０の取引チャネル情報とに応じて予め定められている。この実施形態では、表２に示すように、顧客重要度がＢランクであり、また、顧客取引端末２１０がＡＴＭであるので、来店通知待機時間は２０秒である。従って、待機時間は２０秒と設定される。この、待機時間（＝２０秒）は０秒よりも大きいので、続いて、Ｓ３２の過程により、予め定められた検知間隔の間、待機する。検知間隔は、表５に示すように、顧客重要度と、顧客取引端末の取引チャネル情報とに応じて予め定められている。この実施形態では、表２に示すように、顧客重要度がＢランクであり、また、顧客取引端末がＡＴＭであるので、検知間隔は５秒となる。一定時間として、検知間隔の５秒間待機した後、再び、Ｓ２６及びＳ２８の過程において、閾値判定部２９０が承認待機数を取得した後、役席端末２２０が混雑しているか否かを判定する。また、Ｓ３２の過程では、待機処理部２８２は、待機時間（＝２０秒）から検知間隔（５秒）を減算し、待機時間を１５秒とする。その後、Ｓ２６の処理が行われる。すなわち、Ｓ２６の処理は、検知間隔ごとに行われる。
【００４６】
Ｓ２６において、閾値判定部２９０が取得した承認待機数が７に下がっていると、Ｓ２８での比較により、承認待機数（＝７）が閾値（＝７）以下となるため、続いてＳ４０の来店通知表示が行われる。
【００４７】
この実施形態では、役席端末２２０の混雑状態の判定を、承認待機数と、閾値との比較を行う例について説明しているが、この例に限定されない。例えば、表６に示されているように、顧客の「取引期間」、「勤続年数」及び「オペレータＩＤ」などの抑制条件を用いてもよい。この場合、取引期間や勤続年数が一定期間未満の顧客に対して、閾値を表４に示される値よりも低く設定して、表示頻度を抑制しても良い。また、顧客取引端末が窓口端末であり、その窓口端末のオペレータが熟練者である場合なども、表示頻度を抑制しても良い。
【００４８】
一方、抑制条件として、役席端末２２０での業務状況データを用いても良い。例えば、閾値判定部２９０は承認待機数を取引内容から即時承認が必要なもののみを判別して計数し、即時承認が必要とされないものは、閾値と比較する対象となる承認待機数に含めないようにしても良い。一方、１つの承認処理に引き続いて他の承認処理が必要とされる取引内容の承認依頼の場合には、閾値判定部２９０は承認待機数によらず、役席端末２２０を混雑状態と判定するなどしても良い。
【００４９】
このＳ２６〜Ｓ３２までの過程は、待機時間が０以下になるまで繰り返される。
【００５０】
Ｓ４０の来店通知表示の過程では、来店通知表示部２９２が、入出力部２８０に来店通知表示を行う指示を送り、入出力部２３０は、役席端末２２０のディスプレイ上に表示する。図６に、来店通知表示の一例を示している。
【００５１】
この実施形態の来店通知システム及び来店通知方法では、重要顧客が来店している場合に、顧客重要度がＡランク以外の重要顧客に対しては、役席端末２２０の混雑状態に応じて、来店通知の表示を制御する。すなわち、役席端末２２０が承認業務で混雑している場合は、来店通知の表示が抑制される。このため、役席端末２２０での業務効率の低下を抑制することができる。
【００５２】
（第２実施形態）
図７及び図８を参照して、第２実施形態の来店通知サーバ及び役席端末について説明する。図７は、来店通知サーバの概略的な機能ブロック図である。図８は、役席端末の概略的な機能ブロック図である。
【００５３】
来店通知サーバ１１２は、制御部１３０、記憶部１４０、送受信部１５０、顧客属性データ取得部１６０、来店通知データ作成部１７０、待機処理部１８２、顧客属性判定部１８６、来店通知条件取得部１８８及び閾値判定部１９０を備えている。また、役席端末２２２は、制御部２３０、記憶部２４０、送受信部２５０、入出力部２８０、承認処理部２８４及び来店通知表示部２９２を備えている。
【００５４】
第２実施形態では、第１実施形態の役席端末２２０に設けられている待機処理部２８２、顧客属性判定部２８６、来店通知条件取得２８８部及び閾値判定部２４０が、待機処理部１８２、顧客属性判定部１８６、来店通知条件取得部１８８及び閾値判定部１９０として来店通知サーバ１１２に設けられている点が、第１実施形態と異なっている。それ以外の構成や、各機能手段が実現する機能については、第１実施形態と同様であるので、重複する説明を省略する。
【００５５】
図９を参照して、顧客来店通知システムを用いた顧客来店通知方法について説明する。図９は、来店通知サーバの処理フローを示す図である。第２実施形態では、来店通知サーバ１１２が、役席端末２２２の混雑状況を判定して、来店通知表示を行うか否かを判定する。従って、役席端末２２２は、受け取った来店通知データをそのまま表示する。
【００５６】
Ｓ１０及びＳ１２の処理については、図４を参照して説明した第１実施形態の来店通知サーバの処理と同様である。第２実施形態では、図５を参照して説明した第１実施形態の役席端末２２２が行うＳ２２〜Ｓ３２の処理が、来店通知サーバ１１２で行われる。このため、第１実施形態のＳ１４及びＳ２０の来店通知データの送受信の過程は行われない。また、Ｓ４１の来店通知表示の過程では、役席端末２２２に対して、来店通知データを送り、役席端末２２２は受け取った来店通知データをそのまま表示する構成にすれば良い。
【００５７】
なお、第２実施形態の構成では、役席端末２２２が混雑しているか否かの判定が、来店通知サーバ１１２でなされるので、承認依頼は来店通知サーバ１１２を経て所定の役席端末２２２に送られる。
【００５８】
この第２実施形態の構成によれば、第１実施形態と同様の効果を得るにあたり、来店通知サーバ１１２の構成のみが従来と異なっていて、役席端末２２２の構成は従来と同様の構成にすることができる。
【００５９】
なお、上述した各実施形態では、１つの役席端末について、その構成及び動作を説明したが、営業店に複数の役席端末が設けられていても良い。第１実施形態の構成では、複数の役席端末に同時に来店通知データが送られ、各役席端末では、その混雑状況に応じて来店通知の表示がなされる。また、第２実施形態の構成では、来店通知が必須でない場合は、役席端末ごとの混雑状況を判定し、混雑していない役席端末に選択的に来店通知データを送る構成にすることができる。
【符号の説明】
【００６０】
１０ 顧客来店通知システム
１００ センター
１１０、１１２ 来店通知サーバ
１２０ 顧客ＤＢ
１３０、２３０ 制御部
１４０、２４０ 記憶部
１５０、２５０ 送受信部
１６０ 顧客属性データ取得部
１７０ 来店通知データ作成部
１８２、２８２ 待機処理部
１８６、２８６ 顧客属性判定部
１８８、２８８ 来店通知条件取得部
１９０、２９０ 閾値判定部
２００ 営業店
２１０ 顧客取引端末
２１２ ＡＴＭ
２１４ 窓口端末
２２０、２２２ 役席端末
２８０ 入出力部
２８４ 承認処理部
２９２ 来店通知表示部
【特許請求の範囲】
【請求項１】
役席端末、顧客取引端末及び来店通知サーバを備える顧客来店通知システムで行われる顧客来店通知方法であって、
顧客重要度を含む顧客情報、及び、顧客が取引に用いている前記顧客取引端末を特定する取引情報を、来店通知データとして取得する過程と、
前記顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、並びに、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間を含む来店通知条件を取得する過程と、
前記顧客重要度及び前記来店通知フラグから、来店通知表示が必須か否かを判定する過程と、
前記来店通知表示が必須でない場合に、前記来店通知待機時間が経過するまで前記役席端末が混雑しているか否かを判定する過程と、
前記来店通知表示が必須の場合、又は、前記役席端末が混雑していない場合に、来店通知表示を行う過程と
を備えることを特徴とする顧客来店通知方法。
【請求項２】
前記来店通知条件には、前記顧客重要度に応じて定められた来店通知許可閾値が含まれていて、
前記役席端末が混雑しているか否かの判定は、当該役席端末での承認待機数が、前記来店通知許可閾値以下か否かの判定によりなされる
ことを特徴とする請求項１に記載の顧客来店通知方法。
【請求項３】
前記来店通知条件には、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔が含まれていて、前記役席端末が混雑しているか否かの判定は、前記検知間隔ごとに繰り返し行われる
ことを特徴とする請求項２に記載の顧客来店通知方法。
【請求項４】
前記顧客情報には、少なくとも１つの顧客属性データが含まれ、前記来店通知表示が必須か否かの判定で前記顧客属性データが用いられる
ことを特徴とする請求項２又は３に記載の顧客来店通知方法。
【請求項５】
前記来店通知条件には、顧客属性条件及び取引条件の少なくとも１つが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項２〜４のいずれか一項に記載の顧客来店通知方法。
【請求項６】
前記来店通知条件には、少なくとも１つの前記役席端末での業務状況データが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項２〜５のいずれか一項に記載の顧客来店通知方法。
【請求項７】
役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システムが備える役席端末であって、
顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間、前記顧客重要度に応じて定められた来店通知許可閾値、並びに、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔を含む来店通知条件を取得する来店通知条件取得部と、
前記来店通知サーバから受け取る来店通知データに含まれる前記顧客重要度と、前記来店通知フラグから、来店通知表示が必須か否かを判定する顧客属性判定部と、
当該役席端末の承認待機数を取得し、前記承認待機数が前記来店通知許可閾値以下であるか否かを判定する閾値判定部と、
来店通知待機時間を待機時間として設定し、待機時間が０よりも大きいか否かを判定し、待機時間が０よりも大きい場合は、前記検知間隔の間待機するとともに、前記待機時間から検知間隔を減算する待機処理部と、
来店通知表示を行う来店通知表示部と
を備えることを特徴とする役席端末。
【請求項８】
前記顧客情報には、少なくとも１つの顧客属性データが含まれ、前記来店通知表示が必須か否かの判定で前記顧客属性データが用いられる
ことを特徴とする請求項７に記載の役席端末。
【請求項９】
前記来店通知条件には、顧客属性条件及び取引条件の少なくとも１つが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項７又は８に記載の役席端末。
【請求項１０】
前記来店通知条件には、少なくとも１つの前記役席端末での業務状況データが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項７〜９のいずれか一項に記載の役席端末。
【請求項１１】
役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システムであって、
前記来店通知サーバが、
前記顧客取引端末から送られた顧客識別データに対応する顧客属性データを取得する顧客属性データ取得部と、
前記顧客属性データから、顧客が重要顧客であるか否かを判定し、該顧客が重要顧客である場合は、来店通知データを作成して、前記役席端末に送る来店通知データ作成部と
を備え、
前記役席端末が、
顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間、前記顧客重要度に応じて定められた来店通知許可閾値、並びに、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔を含む来店通知条件を読み出す来店通知条件取得部と、
前記来店通知サーバから受け取る来店通知データに含まれる顧客重要度と、前記来店通知フラグから、来店通知表示が必須か否かを判定する顧客属性判定部と、
前記役席端末の承認待機数を取得し、前記承認待機数が前記来店通知許可閾値以下であるか否かを判定する閾値判定部と、
来店通知待機時間を待機時間として設定し、待機時間が０よりも大きいか否かを判定し、待機時間が０よりも大きい場合は、前記検知間隔の間待機するとともに、前記待機時間から検知間隔を減算する待機処理部と、
来店通知表示を行う来店通知表示部と
を備えることを特徴とする顧客来店通知システム。
【請求項１２】
役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システムであって、
前記来店通知サーバが、
前記顧客取引端末から送られた顧客識別データに対応する顧客属性データを取得する顧客属性データ取得部と、
顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間、前記顧客重要度に応じて定められた来店通知許可閾値、及び、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔を含む来店通知条件を読み出す来店通知条件取得部と、
前記顧客重要度と、前記来店通知フラグから、来店通知が必須か否かを判定する顧客属性判定部と、
前記役席端末の承認待機数を取得し、前記承認待機数が前記来店通知許可閾値以下であるか否かの判定により、前記役席端末が混雑しているか否かを判定する閾値判定部と、
前記来店通知待機時間を待機時間として設定し、前記待機時間が０よりも大きいか否かを判定し、前記待機時間が０よりも大きい場合は、前記検知間隔の間待機するとともに、前記待機時間から検知間隔を減算する待機処理部と、
前記顧客属性判定部が、来店通知が必須と判定した場合、あるいは、前記役席端末が混雑していない場合は、来店通知データを作成して、前記役席端末に送る来店通知データ作成部と
を備え、
前記役席端末が、来店通知表示を行う来店通知表示部を備える
ことを特徴とする顧客来店通知システム。
【請求項１３】
前記顧客情報には、少なくとも１つの顧客属性データが含まれ、前記来店通知表示が必須か否かの判定で前記顧客属性データが用いられる
ことを特徴とする請求項１１又は１２に記載の顧客来店通知システム。
【請求項１４】
前記来店通知条件には、顧客属性条件及び取引条件の少なくとも１つが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項１１〜１３のいずれか一項に記載の顧客来店通知システム。
【請求項１５】
前記来店通知条件には、少なくとも１つの前記役席端末での業務状況データが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項１１〜１４のいずれか一項に記載の顧客来店通知システム。
【請求項１】
役席端末、顧客取引端末及び来店通知サーバを備える顧客来店通知システムで行われる顧客来店通知方法であって、
顧客重要度を含む顧客情報、及び、顧客が取引に用いている前記顧客取引端末を特定する取引情報を、来店通知データとして取得する過程と、
前記顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、並びに、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間を含む来店通知条件を取得する過程と、
前記顧客重要度及び前記来店通知フラグから、来店通知表示が必須か否かを判定する過程と、
前記来店通知表示が必須でない場合に、前記来店通知待機時間が経過するまで前記役席端末が混雑しているか否かを判定する過程と、
前記来店通知表示が必須の場合、又は、前記役席端末が混雑していない場合に、来店通知表示を行う過程と
を備えることを特徴とする顧客来店通知方法。
【請求項２】
前記来店通知条件には、前記顧客重要度に応じて定められた来店通知許可閾値が含まれていて、
前記役席端末が混雑しているか否かの判定は、当該役席端末での承認待機数が、前記来店通知許可閾値以下か否かの判定によりなされる
ことを特徴とする請求項１に記載の顧客来店通知方法。
【請求項３】
前記来店通知条件には、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔が含まれていて、前記役席端末が混雑しているか否かの判定は、前記検知間隔ごとに繰り返し行われる
ことを特徴とする請求項２に記載の顧客来店通知方法。
【請求項４】
前記顧客情報には、少なくとも１つの顧客属性データが含まれ、前記来店通知表示が必須か否かの判定で前記顧客属性データが用いられる
ことを特徴とする請求項２又は３に記載の顧客来店通知方法。
【請求項５】
前記来店通知条件には、顧客属性条件及び取引条件の少なくとも１つが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項２〜４のいずれか一項に記載の顧客来店通知方法。
【請求項６】
前記来店通知条件には、少なくとも１つの前記役席端末での業務状況データが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項２〜５のいずれか一項に記載の顧客来店通知方法。
【請求項７】
役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システムが備える役席端末であって、
顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間、前記顧客重要度に応じて定められた来店通知許可閾値、並びに、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔を含む来店通知条件を取得する来店通知条件取得部と、
前記来店通知サーバから受け取る来店通知データに含まれる前記顧客重要度と、前記来店通知フラグから、来店通知表示が必須か否かを判定する顧客属性判定部と、
当該役席端末の承認待機数を取得し、前記承認待機数が前記来店通知許可閾値以下であるか否かを判定する閾値判定部と、
来店通知待機時間を待機時間として設定し、待機時間が０よりも大きいか否かを判定し、待機時間が０よりも大きい場合は、前記検知間隔の間待機するとともに、前記待機時間から検知間隔を減算する待機処理部と、
来店通知表示を行う来店通知表示部と
を備えることを特徴とする役席端末。
【請求項８】
前記顧客情報には、少なくとも１つの顧客属性データが含まれ、前記来店通知表示が必須か否かの判定で前記顧客属性データが用いられる
ことを特徴とする請求項７に記載の役席端末。
【請求項９】
前記来店通知条件には、顧客属性条件及び取引条件の少なくとも１つが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項７又は８に記載の役席端末。
【請求項１０】
前記来店通知条件には、少なくとも１つの前記役席端末での業務状況データが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項７〜９のいずれか一項に記載の役席端末。
【請求項１１】
役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システムであって、
前記来店通知サーバが、
前記顧客取引端末から送られた顧客識別データに対応する顧客属性データを取得する顧客属性データ取得部と、
前記顧客属性データから、顧客が重要顧客であるか否かを判定し、該顧客が重要顧客である場合は、来店通知データを作成して、前記役席端末に送る来店通知データ作成部と
を備え、
前記役席端末が、
顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間、前記顧客重要度に応じて定められた来店通知許可閾値、並びに、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔を含む来店通知条件を読み出す来店通知条件取得部と、
前記来店通知サーバから受け取る来店通知データに含まれる顧客重要度と、前記来店通知フラグから、来店通知表示が必須か否かを判定する顧客属性判定部と、
前記役席端末の承認待機数を取得し、前記承認待機数が前記来店通知許可閾値以下であるか否かを判定する閾値判定部と、
来店通知待機時間を待機時間として設定し、待機時間が０よりも大きいか否かを判定し、待機時間が０よりも大きい場合は、前記検知間隔の間待機するとともに、前記待機時間から検知間隔を減算する待機処理部と、
来店通知表示を行う来店通知表示部と
を備えることを特徴とする顧客来店通知システム。
【請求項１２】
役席端末、顧客取引端末及び来店通知サーバを含む顧客来店通知システムであって、
前記来店通知サーバが、
前記顧客取引端末から送られた顧客識別データに対応する顧客属性データを取得する顧客属性データ取得部と、
顧客重要度に応じて来店通知表示が必須か否かを定めた来店通知フラグ、前記顧客取引端末及び前記顧客重要度に応じて定められた来店通知待機時間、前記顧客重要度に応じて定められた来店通知許可閾値、及び、前記顧客取引端末及び前記顧客重要度に応じて定められた検知間隔を含む来店通知条件を読み出す来店通知条件取得部と、
前記顧客重要度と、前記来店通知フラグから、来店通知が必須か否かを判定する顧客属性判定部と、
前記役席端末の承認待機数を取得し、前記承認待機数が前記来店通知許可閾値以下であるか否かの判定により、前記役席端末が混雑しているか否かを判定する閾値判定部と、
前記来店通知待機時間を待機時間として設定し、前記待機時間が０よりも大きいか否かを判定し、前記待機時間が０よりも大きい場合は、前記検知間隔の間待機するとともに、前記待機時間から検知間隔を減算する待機処理部と、
前記顧客属性判定部が、来店通知が必須と判定した場合、あるいは、前記役席端末が混雑していない場合は、来店通知データを作成して、前記役席端末に送る来店通知データ作成部と
を備え、
前記役席端末が、来店通知表示を行う来店通知表示部を備える
ことを特徴とする顧客来店通知システム。
【請求項１３】
前記顧客情報には、少なくとも１つの顧客属性データが含まれ、前記来店通知表示が必須か否かの判定で前記顧客属性データが用いられる
ことを特徴とする請求項１１又は１２に記載の顧客来店通知システム。
【請求項１４】
前記来店通知条件には、顧客属性条件及び取引条件の少なくとも１つが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項１１〜１３のいずれか一項に記載の顧客来店通知システム。
【請求項１５】
前記来店通知条件には、少なくとも１つの前記役席端末での業務状況データが抑制条件として含まれ、前記役席端末が混雑しているか否かの判定では、前記抑制条件に応じて、前記来店通知許可閾値を変化させる
ことを特徴とする請求項１１〜１４のいずれか一項に記載の顧客来店通知システム。
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１】
【図２】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１】
【図２】
【公開番号】特開２０１１−２０３９４２（Ｐ２０１１−２０３９４２Ａ）
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願番号】特願２０１０−６９８１４（Ｐ２０１０−６９８１４）
【出願日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
【公開日】平成２３年１０月１３日（２０１１．１０．１３）
【国際特許分類】
【出願日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
[ Back to top ]