JP2016062366A - 顧客対応システム及び顧客対応方法 - Google Patents

Abstract

【課題】過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度を適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことを課題とする。
【解決手段】固定資産税などの納付に係る納付依頼書に係る情報を受け付けて、該情報に含まれる納付額に基づいて重要顧客であるか否かを判定し、重要顧客と判定された場合にはテラーモニタ９１及び役席モニタ９０などで金融機関の担当者及び役席者に重要顧客来店の旨を報知するともに、全店の店舗サーバ２０が有する顧客データ２４ａに含まれる当該顧客の情報に重要顧客であることを反映するようにした。また、重要顧客と判定した顧客はローカウンタなどに誘導して重要顧客に応じたサービスが行えるようにした。
【選択図】図１

Description

この発明は、顧客に応じたサービスの提供を行う顧客対応システム及び顧客対応方法に関する。

従来、銀行などの金融機関では、重要顧客を他の一般客と区別して特別なサービスを提供することが多い。このため、店舗に来店した顧客が重要顧客であるか否かを判定する技術が知られている。

例えば、特許文献１には、店舗に来店した顧客が所持するカードに予め顧客情報（重要顧客か否かを示す情報）を登録しておき、顧客の店舗への来店時に店舗内に配設された機器によって顧客が所持するカードに予め登録された顧客情報を読み取り、読み取った顧客情報に基づいて該顧客が重要顧客であるか否かを判定し、該顧客が重要顧客であると判定された場合には、重要顧客が来店した旨を接客係に通知することで、該顧客に重要顧客向けのサービスを提供するシステムが開示されている。

ここで、この特許文献１によれば、予めカードに登録される重要顧客であるか否かを示す情報をどのような基準で決定しているのかが不明であるが、金融機関の担当者が、顧客が十分な預貯金を金融機関に預け入れているか否か、十分な資産を保有しているか否か等を基準として判断するのが一般的である。

特開２００２−２３６７９７号公報

しかしながら、過去の取引実績がない顧客については、重要顧客と位置づけるための情報がないため、該顧客を重要顧客と位置づけることはできない。

以上のことから、過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度をいかに適切かつ効率的に判定し、もって顧客に応じた対応を適切に行うかが重要な課題となっている。なお、かかる課題は、銀行等の金融機関のみならず、接客業を行う店舗を有する企業においても同様に生ずる課題である。

本発明は、上述した従来技術の課題を解消するためのものであって、過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度を適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことができる顧客対応システム及び顧客対応方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、顧客の来店目的に応じた書類データを受け付ける受付手段と、前記受付手段により受け付けた前記書類データに含まれる取引金額に基づいて、前記顧客が重要顧客であるか否かを判定する判定手段と、前記判定手段により前記顧客が重要顧客であると判定された場合に、前記書類データに対応する顧客が重要顧客である旨の情報を報知する報知手段とを備えたことを特徴とする。

また、本発明は、上記発明において、前記書類データは、税金又は公共料金の納付に係る情報であり、前記判定手段は、前記税金又は公共料金の納付に係る情報に含まれる税金又は公共料金の納付金額に基づいて判定することを特徴とする。

また、本発明は、上記発明において、前記重要顧客のランクと各ランクに位置づけられる重要顧客を案内する場所を示す案内情報を対応付けて記憶する案内情報記憶手段をさらに備え、前記判定手段は、前記受付手段により受け付けた前記書類データに含まれる取引金額に基づいて、前記顧客が重要顧客であるか否かと、重要顧客である場合の顧客のランクを判定し、前記報知手段は、前記書類データに含まれる顧客に係る情報とともに前記案内情報記憶手段に記憶された当該顧客のランクに対応する案内情報を報知することを特徴とする。

また、本発明は、上記発明において、前記案内情報記憶手段は、最上位のランクと顧客応接用の応接室とを対応付け、最上位以外のランクと顧客が着席可能な窓口とを対応付けて記憶することを特徴とする。

また、本発明は、上記発明において、各顧客の識別情報と、該顧客の過去の所定期間における取引金額とを対応付けて記憶する過去取引履歴記憶手段をさらに備え、前記判定手段は、前記受付手段により受け付けた書類データに含まれる取引金額及び前記過去取引履歴記憶手段に記憶された該顧客の過去の所定期間における取引金額に基づいて、前記顧客が重要顧客であるか否かを判定することを特徴とする。

また、本発明は、上記発明において、各顧客と該顧客の取引先に係る情報とを対応付けて記憶する取引先情報記憶手段と、前記取引先情報記憶手段に記憶された該顧客の取引先に係る情報に基づいて、前記判定手段により判定された顧客のランクを補正する補正手段とをさらに備えたことを特徴とする。

また、本発明は、店舗に来店した顧客に対応した処理を行う顧客対応システムにおける顧客対応方法であって、顧客の来店目的に応じた書類データを受け付ける受付工程と、前記受付工程により受け付けた書類データに含まれる取引金額に基づいて、前記顧客が重要顧客であるか否かを判定する判定工程と、前記判定工程により前記顧客が重要顧客であると判定された場合に、前記書類データに対応する顧客が重要顧客である旨の情報を報知する報知工程とを含んだことを特徴とする。

本発明によれば、顧客の来店目的に応じた書類データを受け付け、受け付けた書類データに含まれる取引金額に基づいて、顧客が重要顧客であるか否かを判定し、顧客が重要顧客であると判定された場合に、書類データに対応する顧客が重要顧客である旨の情報を報知するように構成したので、過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度を適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことができる。

図１は、実施例１に係る金融機関等に来店した顧客が重要顧客か否かを、顧客の求めるサービス内容に基づいて判定し、重要顧客と判定した場合に顧客をローカウンタに誘導するという処理の概要を説明するための図である。 図２は、実施例１に係る顧客対応システムのシステム構成図である。 図３は、図２に示した電子記帳機の実施例１に係る内部構成を示すブロック図である。 図４は、図３に示した電子記帳機の実施例１に係るデータ構成について説明するための説明図である。 図５は、図２に示した店舗サーバの実施例１に係る内部構成を示すブロック図である。 図６は、図５に示した店舗サーバの実施例１に係るデータ構成について説明するための説明図（その１）である。 図７は、図５に示した店舗サーバの実施例１に係るデータ構成について説明するための説明図（その２）である。 図８は、図２に示したセンタサーバの実施例１に係る内部構成を示すブロック図である。 図９は、図２に示した重要顧客来店に係るテラーモニタの画面表示例及び役席モニタの画面表示例である。 図１０は、図２に示した電子記帳機の実施例１に係る伝票作成に係る処理の処理手順を示すフローチャートである。 図１１は、図２に示した店舗サーバの実施例１に係る受付番号採番要求を受け付けた時の処理手順を示すフローチャートである。 図１２は、センタサーバの実施例２に係る内部構成を示すブロック図である。 図１３は、図１２に示したセンタサーバの実施例２に係るデータ構成について説明するための説明図である。 図１４は、電子記帳機の実施例３に係る内部構成を示すブロック図である。 図１５は、図１４に示した電子記帳機の実施例３に係るデータ構成について説明するための説明図である。

以下に、添付図面を参照して、本発明に係る顧客対応システム及び顧客対応方法の好適な実施例を詳細に説明する。

まず、実施例１に係る、金融機関等に来店した顧客が重要顧客か否かを、顧客の求めるサービス内容に基づいて判定し、重要顧客と判定した場合に顧客を着席可能なローカウンタに誘導するという処理の概要を、図１を用いて説明する。

固定資産税の納付を目的に来店した顧客は、電子記帳機３０において、（ａ）で来店目的が税公金の納付である旨及び持参した固定資産税の納付書に係る情報を入力することによって、納付依頼書の作成を行う。電子記帳機３０は、（ａ）で受け付けた固定資産税の納付に係る情報の中の固定資産税額に基づいて、（ｂ）に示した当該顧客が重要顧客であるか否かの判定を行う。

固定資産税は、保有する固定資産の評価額に応じて課税されるものであることから、保有する固定資産の評価額が高額である場合には、固定資産税額も高額になる。このことから、固定資産税の納付額は、顧客の富裕度を示す１つの指標であり、重要顧客の判定基準とすることは適合性が高い。

電子記帳機３０は、（ａ）に示した固定資産税の納付に係る情報の入力内容の受付処理及び（ｂ）の重要顧客の判定処理に続いて、（ｃ）の納付依頼書の印刷を行う。具体的には（ａ）で受け付けた納付依頼書の項目に対応する入力内容を納付依頼書のイメージに合成して、入力した内容の記載された納付依頼書を出力する。

また、電子記帳機３０は、（ｄ）に示したように店舗サーバ２０に対して、来店目的及び重要顧客か否かの判定結果を含む受付番号の採番要求を送信する。店舗サーバ２０は、（ｄ）で受け取った受付番号の採番要求を受け付けたならば、来店目的及び重要顧客であるか否かの判定結果に基づいて、顧客を誘導する誘導先を判定し、誘導先に応じた受付番号を採番して、（ｅ）で示したように電子記帳機３０に採番した受付番号を通知する。受付番号を受け付けた電子記帳機３０は、（ｆ）に示したように受付番号が印刷された番号札を発行する。店舗サーバ２０は、来店目的が固定資産税の納付などの税公金の納付であれば、通常は誘導先をハイカウンタとするが、重要顧客である場合には、（ｊ）に示すようにローカウンタ若しくは応接室などのような重要顧客に応じた特別なサービスの行える場所を誘導先とする。

また、店舗サーバ２０は、（ｄ）の受付番号の採番要求で採番した受付番号と、該受付番号に係る情報を受付番号状況データ２４ｂに登録し、以降受付番号に関連付けて受け付けた顧客を、サービスを提供する窓口に誘導するまで状態の管理を行う。また、店舗サーバ２０は、（ｈ）に示すように、まだ窓口などに誘導されていない受付番号の一覧情報をテラーモニタ９１に表示する。

（ｈ）でテラーモニタ９１に表示される受付番号の一覧情報は、受付番号に関連づけられた、顧客の名前、受け付けた業務の内容及び重要顧客か否かを示す顧客区分等の情報を含む。テラーモニタ９１に表示される顧客の顧客区分の情報は、顧客が（ａ）で入力した固定資産税額に基づいて、（ｂ）による重要顧客判定結果が反映されたものであり、該顧客が重要顧客であるか否かを示す。

また、店舗サーバ２０は、（ｄ）により来店した顧客が重要顧客であることを示す情報を受け付けたならば、顧客データ２４ａに含まれる対応する顧客の重要顧客であるか否かの情報に受け付けた内容を反映するとともに、（ｉ）に示すように重要顧客来店の旨を役席モニタ９０に表示する。これによって、役席者も重要顧客が来店したことを認識することが可能となる。

また、（ｄ）に基づいて、店舗サーバ２０の顧客データ２４ａが更新された場合には、（ｈ）に示すように、センタサーバ８０と店舗サーバ２０の間の顧客データの同期処理によって更新内容がお互いに通知され、更新内容が反映される。具体的には、店舗サーバ２０は、顧客データ２４ａが更新されたならば顧客データ２４ａの更新内容をセンタサーバ８０にも送信することによって、センタサーバ８０が有する顧客データ８４ａに更新内容を反映する。また、センタサーバ８０は、店舗サーバ２０からの情報に基づいて顧客データ８４ａを更新した場合には、夜間等に他の店舗に設置されている店舗サーバ２０に対して更新された顧客データ８４ａの情報を配信することによって、全店舗の店舗サーバ２０の有する顧客データ２４ａを最新化する。この（ｋ）に示す顧客データの同期処理によって、ある店舗で固定資産税額から当該顧客が重要顧客と判定された場合には、当該顧客が重要顧客であるという情報は全店で共有されることとなり、以降は他の店舗でも重要顧客として扱われることとなる。

このように、固定資産税などの納付に係る納付依頼書に係る情報を受け付けて、該情報に含まれる納付額に基づいて重要顧客であるか否かを判定し、重要顧客と判定された場合にはテラーモニタ９１及び役席モニタ９０などで金融機関の担当者及び役席者に重要顧客来店の旨を報知するともに、全店の店舗サーバ２０が有する顧客データ２４ａに含まれる当該顧客の情報に重要顧客であることを反映するようにした。また、重要顧客と判定した顧客はローカウンタなどに誘導して重要顧客に応じたサービスが行えるようにした。これらによって、過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度を適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことができる。

次に、実施例１に係る顧客対応システムのシステム構成を、図２を用いて説明する。顧客対応システムは、受付機１０と、伝票の作成処理を行う電子記帳機３０と、顧客の窓口への呼出操作などを行うためのテラーモニタ９１と、テラーモニタ９１の操作によって呼び出す顧客の受付番号の表示や呼び出しの音声出力を行う番号呼出装置９２と、顧客の来店状況などを出力する役席モニタ９０及びロビー端末９３と、これらの装置とデータ通信を行ってデータの連携や処理の連携を行う店舗サーバ２０と、店舗サーバ２０へ全店共通の情報を配信したり、店舗サーバ２０から受け付けたデータを金融機関の全体の情報として管理するセンタサーバ８０とを有する。

電子記帳機３０は、店舗の規模に応じて台数が決定され、１台又は複数設置される。テラーモニタ９１は窓口ごとに設置され、それぞれの窓口に設置されたテラーモニタ９１を操作することによって、該窓口に顧客の誘導を行う。番号呼出装置９２は、窓口の種類に相当する台数が設置される。また、受付機１０と電子記帳機３０は顧客の移動範囲である顧客ゾーンに設置される。また、ロビー端末９３も、顧客ゾーンで顧客の応対を行うロビーマンが所持することから顧客ゾーンに位置することとなる。役席モニタ９０、テラーモニタ９１及び番号呼出装置９２は金融機関の従業員の移動範囲である行員ゾーンに設置される。なお、番号呼出装置９２は、顧客ゾーンに設置されてもよい。

受付機１０は、表示操作部１１、番号札印刷部１２及びカードリーダ１３を有する。顧客は来店時に最初に本装置で来店の受付を行う。具体的には、顧客は、表示操作部１１に表示される来店目的を選択する。受付機１０は、顧客により入力された来店目的に基づいて、該来店目的に対応する窓口の種類と、伝票作成の要否とを判定する。受付機１０は、伝票作成が不要と判定した場合には、来店目的に対応する窓口の種類に応じた受付番号を採番し、受付番号の印刷された番号札を番号札印刷部１２から発行する。また、受付機１０は、伝票作成が必要と判定した場合には、番号札は発行せずに電子記帳機３０への誘導を実施する。

また、受付機１０は、カードリーダ１３で金融カードを読み取ると当該カードから読み取った個人を特定する情報を店舗サーバ２０に通知して、店舗サーバ２０から当該顧客の顧客情報を入手する。受付機１０は、該顧客情報から重要顧客と判定した場合は、店舗サーバ２０に重要顧客来店の旨を通知する。当該重要顧客来店の旨の通知を受け付けた店舗サーバ２０は、役席モニタ９０に重要顧客来店の通知を行う。

電子記帳機３０は、金融カードを読み込むためのカードリーダ３３、通帳に付けられた磁気テープを読み込む通帳ＭＳリーダ３４、顧客が持参した帳票のイメージなどを読み込むイメージスキャナ３５及び電子記帳機３０で作成した伝票を印字するプリンタ３６が接続される。電子記帳機３０は、受付機１０から誘導された顧客が伝票を作成するための機能を有する。

電子記帳機３０は、顧客の来店目的などの入力に基づいて作成する伝票を判定し、当該伝票の項目を順番に画面に表示して、顧客の入力を受け付ける。そして、各項目に対する入力内容から図示しない伝票項目データ３８ｄを生成する。また、電子記帳機３０は、生成した伝票項目データ３８ｄを店舗サーバ２０に送信して、店舗サーバ２０の伝票項目データ２４ｄに生成した伝票項目データ３８ｄの情報を登録する。

また、電子記帳機３０は、伝票の項目の内容を画面からの入力によって受け付けるだけではなく、カードリーダ３３で金融カードの情報を読み込ませたり、通帳ＭＳリーダ３４で通帳の磁気ストライプを読み込ませることによって、読み込まれた情報を伝票項目データ３８ｄの対応する項目に反映することも可能である。また、顧客の持参した税金や公共料金などの納付書をイメージスキャナ３５により読み取って、取得した納付書のイメージに含まれる納付金額などの情報を文字認識することによって、伝票項目データ３８ｄの対応する項目に反映することも可能である。

また、電子記帳機３０は、受け付けた入力内容に基づいて生成した伝票項目データ３８ｄを使用して、プリンタ３６で伝票項目データ３８ｄの情報が記載された取引を依頼する伝票を印刷する。また、電子記帳機３０は、伝票の印刷が終了すると店舗サーバ２０に受付番号の採番を依頼して、採番した受付番号の印刷された番号札を発行する。本実施例では、伝票と番号札は別々に出力されるものとしたが、受付番号などの番号札に印刷されている内容を伝票に印刷することによって、番号札を発行しないものとしてもよい。

店舗サーバ２０は、顧客データ２４ａ、受付番号状況データ２４ｂ及び伝票項目データ２４ｄなどを管理する。顧客データ２４ａは、センタサーバ８０から配信されたデータであって、金融機関で管理する顧客の情報であり、受付機１０や電子記帳機３０から店番、科目及び口座番号などの個人を特定するキー情報を指定した検索要求を受け付けると、顧客データ２４ａを検索して対応する顧客の情報を応答する機能を有する。また、顧客データ２４ａは、顧客が重要顧客であるか否かの情報も有している。また、店舗サーバ２０は、電子記帳機３０から、顧客が重要顧客である旨の通知を受け付けると、受け付けた内容に従って顧客データ２４ａに含まれる指定された顧客に関連付けられた情報の更新を行うとともに、センタサーバ８０へも顧客データ２４ａの更新の内容を通知する。また、受付番号状況データ２４ｂは、受付機１０若しくは電子記帳機３０で番号札を発行する際に採番された受付番号とその状況が記憶されたデータである。また、伝票項目データ２４ｄは、電子記帳機３０で作成された伝票の項目の入力情報が記録されている。

また、店舗サーバ２０は、重要顧客の来店を役席モニタ９０に報知したり、受付機１０や電子記帳機３０で応対が必要な状態になっている場合は、顧客ゾーンのロビーマンの所持するロビー端末９３に情報を通知する。

センタサーバ８０は、顧客データ８４ａを有しており、該顧客データ８４ａが更新されたならば、所定のタイミングで全店の店舗サーバ２０に更新内容を配信する。また、店舗サーバ２０から顧客データ２４ａの更新の内容の通知を受け付けたならば、受け付けた内容に応じて顧客データ８４ａの更新を行う。

次に、図２に示した電子記帳機３０の実施例１に係る内部構成を説明する。図３は、電子記帳機３０の実施例１に係る内部構成を示すブロック図である。電子記帳機３０は、金融カードを読み込むためのカードリーダ３３、通帳に付けられた磁気テープを読み込む通帳ＭＳリーダ３４、顧客が持参した帳票のイメージなどを読み込むイメージスキャナ３５、電子記帳機３０で作成した伝票を印字するプリンタ３６、番号札を発行する番号札プリンタ３７及び電子記帳機３０を使用する顧客の顔画像を撮像するカメラ３０ａと接続される。本実施例では、伝票をプリンタ３６で印刷し、番号札を番号札プリンタ３７で印刷するものとしたが、プリンタ３６で伝票及び番号札を印刷するものとしてもよい。若しくは、伝票に番号札に印刷されている内容を含めて印刷することによって番号札を印刷しないものとしてもよい。

また、電子記帳機３０は、表示操作部３１と、通信部３２と、記憶部３８と、制御部３９とを有する。表示操作部３１は、タッチパネルディスプレイなどであり、入力項目の表示、操作入力ボタンの表示、操作入力の受付を行う入出力部である。通信部３２は、ＬＡＮ等の通信網を介して店舗サーバ２０とデータ通信するためのインタフェース部である。

記憶部３８は、ハードディスク装置や不揮発性メモリ等からなる記憶デバイスである。記憶部３８は、顧客データ３８ａ、伝票イメージテンプレートデータ３８ｂ、伝票決定パラメータ３８ｃ、伝票項目データ３８ｄ、合成伝票イメージデータ３８ｅ、重要顧客判定条件データ３８ｆ及び顔画像データ３８ｇを有する。

顧客データ３８ａは、カードリーダ３３に金融カードが挿入されることなどによって取得した個人を特定する情報（例えば、店番、科目及び口座番号）を検索キーとして店舗サーバ２０の有する顧客の情報を検索して取得した顧客に係る情報である。

伝票イメージテンプレートデータ３８ｂは、電子記帳機３０で作成対象の全ての伝票の種類数分存在し、それぞれの伝票の種類ごとに伝票のイメージデータと、伝票上の項目の位置と項目を識別する項目識別番号等とを有する。伝票決定パラメータ３８ｃは、顧客の来店目的と伝票の種類との対応を規定したデータである。

伝票項目データ３８ｄは、顧客が表示操作部３１などで入力した、伝票の項目の入力情報である。合成伝票イメージデータ３８ｅは、伝票イメージテンプレートデータ３８ｂと伝票項目データ３８ｄとを用い、未記入の伝票のイメージに顧客の入力した伝票項目の入力値を合成したイメージデータである。

重要顧客判定条件データ３８ｆは、顧客によって入力された伝票項目データ３８ｄの内容に基づいて、当該顧客が重要顧客であるか否かを判定する条件を規定したである。顔画像データ３８ｇは、カメラ３０ａで取得した電子記帳機３０を操作する顧客の顔画像である。

制御部３９は、電子記帳機３０の全体を制御する制御部であり、顧客データ管理部３９ａ、伝票項目データ生成部３９ｂ、伝票印刷処理部３９ｃ、番号札発行処理部３９ｄ、伝票項目データ送信部３９ｅ、帳票イメージ処理部３９ｆ、顔画像取得部３９ｇ及び重要顧客判定処理部３９ｈを有する。実際には、これらの機能部に対応するプログラムを図示しないＲＯＭや不揮発性メモリに記憶しておき、これらのプログラムをＣＰＵ（Central Processing Unit）にロードして実行することにより、それぞれに対応するプロセスを実行させることになる。

顧客データ管理部３９ａは、カードリーダ３３に金融カードが挿入されたり、通帳ＭＳリーダ３４で通帳の磁気ストライプの読取が行われた場合に、金融カード若しくは通帳の磁気ストライプから取得した情報（例えば、店番、科目及び口座番号）を検索キーとして店舗サーバ２０に検索要求を行うことによって、店舗サーバ２０から来店した顧客に係る顧客情報を入手して顧客データ３８ａに記憶する。

伝票項目データ生成部３９ｂは、表示操作部３１を使用して顧客の来店目的を受け付けて、受け付けた来店目的に基づいて作成すべき伝票の種類を決定し、決定した伝票の項目に対応する情報を受け付けて、伝票項目データ３８ｄを生成する。

また、伝票項目データ生成部３９ｂは、複数枚の伝票を作成する場合には、先に作成した伝票に係る伝票項目データ３８ｄの情報を使用して、別の伝票の項目入力を省力化することができる。例えば、同一の口座に対する入出金を行うような場合には、先の伝票の作成時には口座番号を表示操作部３１の操作によって入力したとしても、後の伝票の作成時には先の伝票に対応する伝票項目データ３８ｄに含まれる口座番号の情報を使用することを指定することによって同じ口座番号の入力を繰り返す必要はない。

伝票印刷処理部３９ｃは、伝票イメージテンプレートデータ３８ｂと伝票項目データ３８ｄから、合成伝票イメージデータ３８ｅを生成して、生成した合成伝票イメージデータ３８ｅをプリンタ３６で印刷することによって伝票の印刷を行う。

番号札発行処理部３９ｄは、来店目的及び判定した重要顧客か否かの情報の反映された顧客データ２４ａを含む受付番号の採番要求を店舗サーバ２０に送信することによって、来店目的及び重要顧客に応じた受付番号を店舗サーバ２０が取得して、取得した受付番号の記載された番号札を番号札プリンタ３７で発行する。複数の伝票の作成を行った場合についても受付番号は１つだけ取得し、該受付番号を記載した番号札を１枚発行する。

伝票項目データ送信部３９ｅは、受付番号の採番後に採番した受付番号及び顧客番号とともに、伝票項目データ３８ｄを店舗サーバ２０に送信する。また、伝票項目データ送信部３９ｅは、伝票項目データ３８ｄの内容を全て送信したならば、伝票項目データ３８ｄをクリアする。

帳票イメージ処理部３９ｆは、顧客の持ち込んだ帳票のイメージをイメージスキャナ３５で取得して、取得した帳票イメージから対応する伝票の種類の判定と、帳票イメージからの文字認識によって伝票の項目の入力情報を取得する。

顔画像取得部３９ｇは、顧客の顔画像を取得して、取得した顔画像のデータを顔画像データ３８ｇに記憶するとともに、顔画像の特徴情報を算出する。顧客データ管理部３９ａは、顔画像取得部３９ｇの算出した顧客の顔画像の特徴データを含む顧客検索要求を店舗サーバ２０に送信する。店舗サーバ２０から顧客検索要求の応答として、店舗サーバ２０から指定した顔画像の特徴データに対応した顧客に係る顧客情報を入手したならば、入手した情報に基づいて顧客データ３８ａを更新する。また、顔画像取得部３９ｇは、顧客データ３８ａに顔画像の特徴データが登録されていない場合には、算出した顔画像の特徴データを顧客データ３８ａに記憶する。

重要顧客判定処理部３９ｈは、伝票項目データ生成部３９ｂが生成した伝票項目データ３８ｄと、重要顧客判定条件データ３８ｆとに基づいて、顧客が重要顧客であるか否か及び重要顧客の場合には重要顧客のランクの判定を行う。重要顧客判定処理部３９ｈは、重要顧客であると判定して、顧客データ２４ａの重要顧客で有るか否か及び重要顧客である場合には重要顧客のランクを示す情報である顧客区分が重要顧客ではないことを示す「一般」の場合には、判定した重要顧客のランクを顧客区分に反映する。また、重要顧客判定処理部３９ｈは、顧客データ２４ａの顧客区分の重要顧客のランクが判定した重要顧客のランクより低い場合には、判定した重要顧客のランクを顧客区分に反映する。

次に、図３に示した電子記帳機３０の実施例１に係るデータ構成について、図４を用いて説明する。

顧客データ３８ａは、店番、科目コード、口座番号、顧客番号、顧客区分、顧客氏名、電話番号、生年月日、住所及び顔画像の特徴データなどの情報を有する。図４の顧客データ３８ａの例は、店番が「０００５」であり、科目コードが「０１」であり、口座番号が「７６５４３２１」であり、顧客番号が「０１２３４５６７８９」であり、顧客区分が「一般」であり、顧客氏名が「福岡 花子」であり、電話番号が「０３−１２３４−５６７８」であり、生年月日が「１９８５／４／１５」であることを示している。

伝票イメージテンプレートデータ３８ｂは、伝票の種類を示す伝票ＩＤと、伝票項目情報と、該伝票ＩＤに対応する伝票のイメージデータとをレコードの項目として有し、伝票ＩＤをキーデータとするデータである。伝票項目情報は、伝票上にある顧客が記入すべき項目ごとに該項目の位置情報と該項目を識別する項目識別ＩＤなどで構成されている。図４の伝票イメージテンプレートデータ３８ｂの例は、伝票ＩＤ「００４」に対応付けられる伝票の１つ目の項目の項目識別ＩＤが「０２０」で、２つ目の項目の項目識別ＩＤが「０２１」であるレコードが含まれていることを示している。

伝票決定パラメータ３８ｃは、来店目的とそれに対応する作成すべき伝票の種類を示す伝票ＩＤをレコードの項目として有する、複数のレコードから構成されるデータである。図４の伝票決定パラメータ３８ｃの例は、来店目的が「入金」の場合には伝票ＩＤが「００１」の伝票を、来店目的が「出金」の場合には伝票ＩＤが「００２」の伝票を、来店目的が「振込」の場合には伝票ＩＤが「００３」の伝票を、来店目的が「税公金納付」の場合には伝票ＩＤが「００４」の伝票を作成しなければならないことを示している。

伝票項目データ３８ｄは、受付枝番号と、来店目的の入力等で決定した伝票ＩＤと、該伝票ＩＤの伝票の項目情報をレコードの項目として有するデータである。伝票ＩＤは、伝票の種類を示す識別情報で、伝票の項目情報は伝票ＩＤが示す伝票の項目に対応する情報で、伝票の項目ごとの項目識別ＩＤと項目値とを有する。図４の伝票項目データ３８ｄの例は、受付枝番号が「００１」に対応する伝票は、伝票ＩＤが「００４」の伝票の項目識別ＩＤが「０２０」の項目の項目値が「１２３４」であり、項目識別ＩＤが「０２１」の項目の項目値が「福岡 花子」であるレコードが含まれていることを表している。

重要顧客判定条件データ３８ｆは、伝票ＩＤ、顧客区分、判定条件をレコード保有項目とするデータである。顧客区分には重要顧客のランクが設定される。判定条件は、伝票ＩＤで規定される伝票において、顧客区分に設定されている重要顧客のランクと判定するための、伝票の項目に入力された値が満たさなければならない条件を設定した情報である。
判定条件には、伝票の項目に入力された値に対する条件を複数設定することが可能であって、それぞれの条件には伝票上の項目を識別する項目識別ＩＤと、その項目値と、条件とが含まれる。

条件は、コード化されたデータであって、条件が「１」は項目識別ＩＤで特定される項目の値が項目値で規定される値未満であることを意味し、条件が「２」は項目識別ＩＤで特定される項目の値が項目値で規定される値以下であることを意味し、条件が「３」は項目識別ＩＤで特定される項目の値が項目値で規定される値と等しいことを意味し、条件が「４」は項目識別ＩＤで特定される項目の値が項目値で規定される値以上であることを意味し、条件が「５」は項目識別ＩＤで特定される項目の値が項目値で規定される値を超過していることを意味する。また、判定条件に複数の条件が設定されている場合には、設定されているすべての条件を満たしている場合に、顧客区分に指定された重要顧客のランクであると判定される。

図４の重要顧客判定条件データ３８ｆの１レコード目のデータの例は、伝票ＩＤが「００４」である伝票において、顧客区分が「重要顧客Ａ」である条件は、少なくとも、項目識別ＩＤが「０３０」の項目値が「３」であることと、項目識別ＩＤが「０３１」の項目値が「３，０００，０００」以上であることとを条件としていることを示している。また、２レコード目のデータの例は、伝票ＩＤが「００４」である伝票において、顧客区分が「重要顧客Ｂ」である条件は、少なくとも、項目識別ＩＤが「０３０」の項目値が「３」であることと、項目識別ＩＤが「０３１」の項目値が「２，０００，０００」以上であることとを条件としていることを示している。

次に、図２に示した店舗サーバ２０の実施例１に係る内部構成を説明する。図５は、店舗サーバ２０の実施例１に係る内部構成を示すブロック図である。図５に示すように、店舗サーバ２０は、入力部２１及び表示部２２と接続される。入力部２１は、キーボードやマウス等であり、表示部２２は、液晶パネル等のディスプレイ装置である。

また、店舗サーバ２０は、通信部２３と、記憶部２４と、制御部２５とを有する。通信部２３は、ＬＡＮ及び専用線等の通信網を介して受付機１０、電子記帳機３０、役席モニタ９０、テラーモニタ９１、番号呼出装置９２、ロビー端末９３及びセンタサーバ８０とデータ通信するためのインタフェース部である。

記憶部２４は、ハードディスク装置や不揮発性メモリ等からなる記憶デバイスである。記憶部２４は、顧客データ２４ａ、受付番号状況データ２４ｂ、顧客滞留状況データ２４ｃ、伝票項目データ２４ｄ及び誘導先設定データ２４ｅを有している。

顧客データ２４ａは、所定のタイミングでセンタサーバ８０より配信された顧客に関する情報を記憶したもので、顧客の重要顧客であるか否かを示す情報を含む顧客の属性情報及び顧客の有する口座の情報などを含む。受付番号状況データ２４ｂは、番号札の発行処理時に受付機１０や電子記帳機３０からの受付番号の採番要求によって生成されるデータで、該受付番号に対応する来店目的、誘導先の窓口及び当該受付番号に対応する顧客の待ちの状況などの情報を有する。また、受付番号状況データ２４ｂは、受付機１０、電子記帳機３０及びテラーモニタ９１からの登録又は更新に係る要求に応じて登録又は更新され、受付番号に関連づけられた顧客の状況が管理されている。顧客滞留状況データ２４ｃは、窓口の種類ごとの来店した顧客数や待ち人数の情報を有する。伝票項目データ２４ｄは、店舗内の全ての電子記帳機３０で作成された伝票の情報であって、電子記帳機３０で作成された伝票項目データ３８ｄを日付、受付番号及び顧客番号などに関連付けて登録されたデータである。

誘導先設定データ２４ｅは、来店目的と重要顧客であるか否か及び重要顧客である場合の重要顧客のランクとに応じて、顧客を誘導するサービス提供窓口又は応接室などを規定したデータである

制御部２５は、店舗サーバ２０の全体を制御する制御部であり、顧客データ検索部２５ａ、受付番号管理部２５ｂ、行員報知部２５ｃ、伝票データ管理部２５ｄ、呼出処理部２５ｅ、顧客データ同期処理部２５ｆ、伝票項目データ送信部２５ｇ及び来店状況出力処理部２５ｈを有する。実際には、これらの機能部に対応するプログラムを図示しないＲＯＭや不揮発性メモリに記憶しておき、これらのプログラムをＣＰＵ（Central Processing Unit）にロードして実行することにより、対応するプロセスを実行させることになる。

顧客データ検索部２５ａは、受付機１０若しくは電子記帳機３０から顧客を特定する情報（例えば、店番、科目コード及び口座番号）の指定を含む顧客検索要求を受け付けると、顧客データ２４ａを検索して対応する顧客の情報を返信する。また、顧客データ検索部２５ａは、電子記帳機３０から顔画像の特徴データを含む顧客検索要求を受け付けると、受け付けた顔画像の特徴データに基づいて顧客データ２４ａを検索して、対応する顧客が存在した場合には該顧客の情報を返信する。

受付番号管理部２５ｂは、電子記帳機３０からの受付目的、顧客データ３８ａを含む受付番号の採番要求を受け付けたならば、受け付けた受付番号の採番要求に含まれる来店目的及び顧客データ３８ａに含まれる顧客区分の情報と、誘導先設定データ２４ｅに基づいて顧客の誘導先を決定する。また、受付番号管理部２５ｂは、決定した誘導先に応じて受付番号を新たに採番して、採番した受付番号を電子記帳機３０に返却するとともに、採取した受付番号に対応する新たなレコードを受付番号状況データ２４ｂに追加登録する。受付番号管理部２５ｂは、受付番号状況データ２４ｂに追加したレコードに、誘導先及び受付番号の採番要求に含まれる顧客データ３８ａなどの情報を反映する。

なお、実施例１では、店舗サーバ２０の受付番号管理部２５ｂで顧客の誘導先の判定を行うこととしたが、本発明はこれに限定されるものではない。例えば、誘導先設定データ２４ｅを電子記帳機３０に持たせるようにして、電子記帳機３０が誘導先を判定するようにしてもよい。その場合には、電子記帳機３０からの受付番号の採番要求には誘導先の判定結果が含まれることとなる。

また、受付番号管理部２５ｂは、受付番号の採番要求で受け付けた顧客データ３８ａに含まれる顧客区分の情報が、顧客データ２４ａの中の当該顧客に関連付けられた顧客区分から更新されている場合には、受け付けた顧客区分を顧客データ２４ａの中の当該顧客の顧客区分に反映する。また、受付番号管理部２５ｂは、受付番号の採番要求で受け付けた顧客データ３８ａに顔画像の特徴データが含まれていて、顧客データ２４ａの中に当該顧客に対応する顔画像の特徴データが登録されていない場合には、受け付けた顔画像の特徴データを顧客データ２４ａの中の当該顧客の顔画像の特徴データに反映する。

また、受付番号管理部２５ｂは、呼出処理部２５ｅによって、顧客の呼び出しが行われると、受付番号状況データ２４ｂの呼び出された受付番号に対応するデータの状況を処理中の状況に更新し、呼び出された窓口でそれまで処理中の状況になっていた受付番号に対応するデータの状況を処理済に更新する。

行員報知部２５ｃは、役席モニタ９０やロビー端末９３などにメッセージの報知を行う。具体的には、受付機１０若しくは電子記帳機３０で重要顧客の来店を認識した場合に受付機１０若しくは電子記帳機３０から重要顧客来店の旨の通知を受けると、行員報知部２５ｃは、役席モニタ９０に重要顧客来店の旨のメッセージの報知を行う。また、顧客ゾーンで顧客の応対を行うロビーマンに対する指示や情報提供する場合には、行員報知部２５ｃは、ロビーマンの所持するロビー端末９３にメッセージの報知を行う。

伝票データ管理部２５ｄは、電子記帳機３０から受付番号、顧客番号及び伝票項目データ３８ｄを含む伝票項目データ登録要求を受け付けたならば、伝票項目データ３８ｄを日付、受付番号及び顧客番号に関連付けたデータとして伝票項目データ２４ｄに登録する。また、伝票データ管理部２５ｄは、日付及び受付番号を含む検索要求を受け付けたならば、伝票項目データ２４ｄから日付及び受付番号に対応するデータを検索して返信する。また、伝票データ管理部２５ｄは、日付、受付番号及び該受付番号に対応する伝票の項目の入力情報の更新内容を含む更新要求を受け付けたならば、伝票データ管理部２５ｄの日付及び該受付番号に対応するデータを指示された更新内容で更新する。

呼出処理部２５ｅは、テラーモニタ９１から顧客の窓口への誘導の要求を受け付けると、受付番号状況データ２４ｂから要求元のテラーモニタ９１の設置されている窓口に誘導されることを待っている顧客の中で、受付時刻が最も早い受付番号に対応する顧客を要求元のテラーモニタ９１の設置されている窓口に誘導する。具体的には、呼出処理部２５ｅは、番号呼出装置９２の表示部に受付番号などを表示するとともに、番号呼出装置９２の音声出力部で受付番号及び誘導先の窓口の番号などを音声出力する。

顧客データ同期処理部２５ｆは、センタサーバ８０から顧客データの配信を受け付けた場合には、受け付けた顧客データを顧客データ２４ａに反映する。また、顧客データ同期処理部２５ｆは、電子記帳機３０等の通知に基づいて顧客データ２４ａの更新を行ったならば、夜間などの所定のタイミングで顧客データ２４ａの更新内容をセンタサーバ８０に送信する。

伝票項目データ送信部２５ｇは、夜間などの所定のタイミングで未送信の伝票項目データ２４ｄをセンタサーバ８０に送信する。センタサーバ８０は受け付けた伝票項目データ２４ｄを店舗で受け付けた取引の履歴として管理する。

来店状況出力処理部２５ｈは、テラーモニタ９１からの来店状況照会要求に応じて、テラーモニタ９１に来店状況の一覧及び一覧に関連する依頼取引の詳細内容の出力を行う。

次に、図５に示した店舗サーバ２０の実施例１に係るデータ構成について、図６及び図７を用いて説明する。

図６に示すように、顧客データ２４ａは、顧客番号、更新フラグ、顧客属性情報及び口座情報をレコードの項目として有するデータである。顧客番号は金融機関内で顧客を一意に特定することのできる番号である。更新フラグは、店舗サーバ２０によって当該レコードの更新を行ったか否かを示す情報であって、「０」は未更新で、「１」は更新済で有ることを示す。顧客属性情報は、顧客区分、顧客氏名、電話番号及び顔画像特徴データ等の情報を有する。口座情報は、当該顧客番号に対応する顧客が有している口座の情報で、口座ごとに店番号、科目コード、口座番号を有する。図６の顧客データ２４ａの例は、顧客番号が「０１２３４５６７８９」の顧客の情報は更新フラグが「１」であり店舗サーバ２０で更新されていて、顧客区分が「重要顧客Ｂ」で、顧客氏名が「福岡 花子」であり、電話番号が「０３−１２３４−５６７８」であり、店番号が「０００５」であり、科目コードが「０１」であり、口座番号が「７６５４３２１」である口座を有していることを示している。

図６に示すように、受付番号状況データ２４ｂは、受付番号、来店目的、受付日付、受付時刻、誘導先窓口種類、状況、顧客区分、店番号、科目コード、口座番号及び顧客の顔の画像データをレコードの項目として有する。これらの項目のうち、受付番号はキー項目である。この受付番号は番号札発行時に採番される番号で、来店した顧客を一意に識別可能な番号である。来店目的はコード化されたデータであり、「１」は来店目的が入金であることを示し、「２」は来店目的が出金であることを示し、「３」は来店目的が振込であることを示し、「４」は来店目的が税公金納付であることを示し、「５」は来店目的が諸届であることを示し、「６」は来店目的がローンであることを示す。受付日付、受付時刻は番号札を発行した日付と時刻である。誘導先窓口種類は、来店目的及び顧客区分によって判定された誘導先の窓口の種類であり、「１」はハイカウンタで、「２」はローカウンタで、「３」は応接室であることを示している。状況は、当該レコードの受付番号の番号札を持った顧客の状況を示すデータであって、「１」はハイカウンタ待ち、「２」はハイカウンタで処理中、「３」はローカウンタ待ち、「４」はローカウンタで処理中、「９」は処理済であることを示す。顧客区分は、受付番号採番要求に含まれる顧客データ３８ａに基づいて設定されたデータであり、伝票項目データ３８ｄに基づいて判定された重要顧客であるか否か及び重要顧客である場合には重要顧客のランクの情報が反映された情報である。また、店番号、科目コード、口座番号は、受付機１０や電子記帳機３０で金融カード若しくは通帳ＭＳが読み込まれた場合などに書き込まれる情報である。

図６の受付番号状況データ２４ｂの例は、受付番号「１２５」の番号札をもっている顧客は、利用目的が税公金納付を示す「４」であり、受付日付が「２０１３／４／１０」であり、受付時刻が「１２：３０」であり、誘導先窓口種類がローカウンタを示す「２」であり、状況がローカウンタ待ちを示す「３」であり、顧客区分が「重要顧客Ｂ」であり、店番が「０００５」であり、科目コードが「０１」であり、口座番号が「７６５４３２１」である口座を有することを示すレコードを含むことを表している。また、受付番号「５２３」の番号札をもっている顧客は、利用目的が諸届を示す「５」であり、受付日付が「２０１３／４／１０」であり、受付時刻が「１２：４０」であり、誘導先窓口種類がローカウンタを示す「２」であり、状況がローカウンタ待ちを示す「３」であり、顧客区分は一般であり、店番が「００１８」であり、科目コードが「１０」であり、口座番号が「０８９７６５２」である口座を有することを示すレコードを含むことを表している。

図６に示すように、顧客滞留状況データ２４ｃは、電子記帳機３０の待ち人数、処理中の人数及び処理済の人数、ハイカウンタの待ち人数、処理中の人数及び処理済の人数、ローカウンタの待ち人数、処理中の人数及び処理済の人数を有する。図６の顧客滞留状況データ２４ｃの例は、電子記帳機３０の待ち人数が「０」人であり、処理中の人数が「３」人であり、処理済の人数が「９５」人であり、ハイカウンタの待ち人数が「１２」人であり、処理中の人数が「２」人であり、処理済の人数が「９０」人であり、ローカウンタの待ち人数が「３」人であり、処理中の人数が「２」人であり、処理済の人数が「２５」人であることを示している。

図７に示すように、伝票項目データ２４ｄは、日付、店舗番号、顧客番号、受付番号、受付枝番号、伝票ＩＤ及び該伝票ＩＤの伝票の項目情報をレコードの項目として有し、日付、店舗番号、顧客番号、受付番号及び受付枝番号をキー項目とするデータである。受付枝番号以下の項目は、電子記帳機３０の伝票項目データ３８ｄと同じである。伝票項目データ３８ｄに対して伝票データ受け付けた日付、伝票データを受け付けた店舗の識別情報である店番、顧客番号及び受付番号をキー項目として追加することによって、全店の電子記帳機３０で作成された伝票項目データ３８ｄを所定期間蓄積したとしても、個々の伝票をユニークに識別することができる。

図７の伝票項目データ２４ｄの例は、日付が「２０１３／４／１５」に、店番が「０１８」の店舗で受け付けた、顧客番号が「０１２３４５６７８９」の顧客の作成した、受付番号が「１２５」で、受付枝番号が「００１」の伝票に関するデータであって、伝票ＩＤが「００４」で、該伝票の項目識別ＩＤ「０２０」に対応する項目の項目値が「１２３４」で、項目識別ＩＤ「０２１」に対応する項目の項目値が「福岡 花子」であることを示すレコードが含まれていることを表している。

図７に示すように、誘導先設定データ２４ｅは、顧客区分及び来店目的に応じた誘導先を規定したデータである。図７の誘導先設定データ２４ｅの例は、顧客区分が「重要顧客Ａ」の顧客は誘導先が「応接室」で、顧客区分が「重要顧客Ｂ」の顧客は誘導先が「ローカウンタ」で、顧客区分が「一般」で来店目的が「入金」の顧客は誘導先が「ハイカウンタ」で、顧客区分が「一般」で来店目的が「出金」の顧客は誘導先が「ハイカウンタ」で、顧客区分が「一般」で来店目的が「振込」の顧客は誘導先が「ハイカウンタ」で、顧客区分が「一般」で来店目的が「税公金収納」の顧客は誘導先が「ハイカウンタ」で、顧客区分が「一般」で来店目的が「諸届」の顧客は誘導先が「ローカウンタ」であることを示している。

次に、図２に示したセンタサーバ８０の実施例１に係る内部構成を説明する。図８は、センタサーバ８０の実施例１に係る内部構成を示すブロック図である。図８に示すように、センタサーバ８０は、入力部８１及び表示部８２と接続される。入力部８１は、キーボードやマウス等であり、表示部８２は、液晶パネル等のディスプレイ装置である。

また、センタサーバ８０は、通信部８３と、記憶部８４と、制御部８５とを有する。通信部８３は、専用線などの通信網を介して店舗サーバ２０とデータ通信するためのインタフェース部である。

記憶部８４は、ハードディスク装置や不揮発性メモリ等からなる記憶デバイスである。記憶部２４は、顧客データ８４ａ及び取引履歴データ８４ｂを有している。

顧客データ８４ａは、顧客に関する情報を記憶したもので、顧客の属性や該顧客の有する口座の情報を含む。取引履歴データ８４ｂは、店舗サーバ２０の有する伝票項目データ２４ｄを収集し蓄積したデータであり、店舗において電子記帳機３０で入力を受け付けて作成した伝票の入力情報を取引履歴として蓄積したものである。

制御部８５は、センタサーバ８０の全体を制御する制御部であり、顧客データ管理部８５ａ及び取引履歴収集部８５ｂを有する。実際には、これらの機能部に対応するプログラムを図示しないＲＯＭや不揮発性メモリに記憶しておき、これらのプログラムをＣＰＵ（Central Processing Unit）にロードして実行することにより、対応するプロセスを実行させることになる。

顧客データ管理部８５ａは、顧客データ８４ａを管理する処理部である。顧客データ管理部８５ａは、顧客データ８４ａが更新されたならば、全店の店舗サーバ２０に顧客データ８４ａを配信する。また、顧客データ管理部８５ａは、店舗サーバ２０から顧客データ８４ａに含まれる情報の更新要求を受け付けた場合には、受け付けた更新要求に基づいて顧客データ８４ａの更新を行う。

取引履歴収集部８５ｂは、店舗サーバ２０から伝票項目データ２４ｄを受け付けて、受け付けた伝票項目データ２４ｄを、取引履歴データ８４ｂに登録する。

次に、図２に示した重要顧客来店に係るテラーモニタ９１の画面表示例及び役席モニタ９０の画面表示例を、図９を用いて説明する。

図９（ａ）は、テラーモニタ９１に表示される顧客の来店状況一覧の画面構成である。図９（ａ）の顧客の来店状況一覧は、店舗サーバ２０の来店状況出力処理部２５ｈが、テラーモニタ９１の要求に応じてテラーモニタ９１の表示部に出力した画面であって、店舗サーバ２０の受付番号状況データ２４ｂ及び伝票項目データ２４ｄに基づいて、窓口に誘導されることを待っている顧客の一覧を表示した画面である。

図９（ａ）に示すように、受付番号に、顧客の名前、処理対象の口座番号、受け付けている業務、受け付けている伝票の枚数、自行向けの処理なのか他行向けの処理なのかを示す処理区分及び顧客区分が関連付けられて１行に表示される。また、図９（ａ）に示すように、重要顧客の場合には、顧客区分に「ＶＩＰ」の表示がされるとともに、顧客区分が「ＶＩＰ」ではない一般顧客と異なる色で表示される。

また、図９（ａ）に示すように、各行の最も右に「詳細」ボタンが配置されており、「詳細」ボタン押下によって当該受付番号に関連付けられている受け付けた伝票の項目ごとの詳細な入力内容を参照することができる。また、画面最下部には「前ページ」、「次ページ」などのボタンが配置される。「前ページ」及び「次ページ」のボタンは、顧客の来店状況一覧が１ページに収まらずに複数のページに渡る場合に有効なページの表示を切り替えるためのボタンである。

また、図９（ａ）の２行目に表示された例は、受付番号「１２５」は、名前が「福岡 花子」である顧客に関連付けられており、該顧客の伝票記載の項目の口座番号が「７６５４３２１」で、受け付けている業務が「税公金」で、受け付けている業務にかかる伝票の枚数が「１」枚で、処理区分が自行向けであり、顧客区分が「ＶＩＰ」であり重要顧客であることを示している。また、顧客区分が「ＶＩＰ」であることから、他の行と比較して白黒反転表示されることによって強調表示されている。

図９（ｂ）は、重要顧客の来店を検知した場合に、役席モニタ９０及びロビー端末９３に表示される画面の画面構成である。店舗サーバ２０は、受付機１０及び電子記帳機３０から重要顧客の来店の検知を受け付けたならば、役席モニタ９０及びロビー端末９３の表示部に図９（ｂ）に示したような重要顧客の来店を通知するポップアップウィンドウを表示する。

図９（ｂ）の例は、事前に重要顧客として登録されていない顧客が、電子記帳機３０で２２０万円の固定資産税納付の伝票を作成したことによって重要顧客であると判定された場合に表示される画面の例である。図９（ｂ）に示すように、重要顧客の来店を通知するポップアップウィンドウには「ＶＩＰ来店通知」という報知メッセージと、当該顧客の受付番号、受付時刻、顧客の名前、対応予定の窓口及び取引内容などが表示される。また、ポップアップウィンドウの下部には、「詳細」ボタンと「確認」ボタンが配置される。

「詳細」ボタンの押下によって、当該受付番号に関連付けられている伝票の項目として入力された詳細の内容を参照することができる。また、「確認」ボタンを押下することによって当該ポップアップウィンドウを消去することができる。

次に、図２に示した電子記帳機３０の実施例１に係る伝票作成に係る処理の処理手順を説明する。図１０は、電子記帳機３０の実施例１に係る伝票作成に係る処理の処理手順を示すフローチャートである。

顧客データ管理部３９ａは、顔画像取得部３９ｇがカメラ３０ａで取得した顔画像から生成した顔画像の特徴データを含む顧客検索要求を店舗サーバ２０に送信して応答を待ち合わせる（ステップＳ１０１）。ステップＳ１０１の顧客検索要求で指定した顔画像の特徴データに対応する顧客が特定できた旨の返信を受け付けたならば（ステップＳ１０２；Ｙｅｓ）、顧客データ管理部３９ａは、店舗サーバ２０から受け付けた顧客の情報を顧客データ３８ａとして記憶する（ステップＳ１０３）。ステップＳ１０１の顧客検索要求で指定した顔画像の特徴データに対応する顧客が特定できなかった旨の返信を受け付けた場合（ステップＳ１０２；Ｎｏ）には、ステップＳ１０３をスキップしてステップＳ１０４に移行する。

伝票項目データ生成部３９ｂは、顧客の依頼する取引内容に係る情報の入力を受け付けて（ステップＳ１０４）、伝票項目データ３８ｄの更新を行う（ステップＳ１０５）。店舗サーバ２０から顧客の情報をまだ取得できていない場合で、且つステップＳ１０５で更新された伝票項目データ３８ｄに含まれる情報で顧客を特定できる情報が入力済となった場合（ステップＳ１０６；Ｙｅｓ）には、顧客データ管理部３９ａは、伝票項目データ３８ｄに含まれる顧客を特定できる情報を含む顧客検索要求を店舗サーバ２０に送信して、店舗サーバ２０から応答受け付けて、受け付けた顧客の情報を顧客データ３８ａとして記憶する（ステップＳ１０７）。店舗サーバ２０から顧客の情報を既に取得できている場合又は更新された伝票項目データ３８ｄに含まれる情報で顧客を特定できる情報が入力済となっていない場合（ステップＳ１０６；Ｎｏ）には、ステップＳ１０７の処理はスキップしてステップＳ１０８に移行する。

入力中の伝票に対する入力がまだ終了していない場合（ステップＳ１０８；Ｎｏ）には、ステップＳ１０４に戻ることによって、入力中の伝票に対する入力の終了を待ち合わせる。入力中の伝票に対する入力が終了している場合（ステップＳ１０８；Ｙｅｓ）は、重要顧客判定処理部３９ｈは、伝票項目データ３８ｄの入力が完了した伝票に係るデータ及び重要顧客判定条件データ３８ｆに基づいて当該顧客が重要顧客であるか否か及び重要顧客である場合には重要顧客のランクの判定を行い、判定内容に応じて顧客データ３８ａの顧客区分の更新を行う（ステップ１０９）。

また、伝票印刷処理部３９ｃは、伝票項目データ３８ｄの入力が完了した伝票の項目に対する情報と、伝票イメージテンプレートデータ３８ｂとに基づいて入力した伝票の項目の情報が合成された伝票イメージを生成して合成伝票イメージデータ３８ｅに記憶して、該合成伝票イメージデータ３８ｅをプリンタ３６で印刷する（ステップＳ１１０）。ステップＳ１１０で印刷済の伝票以外の伝票の作成が必要な場合（ステップＳ１１１；Ｙｅｓ）には、ステップＳ１０４に戻ることによって次の伝票に関する入力を継続する。

ステップＳ１１０で印刷済の伝票以外の伝票の作成が不要な場合（ステップＳ１１１；Ｎｏ）には、番号札発行処理部３９ｄは、来店目的及び顧客データ３８ａを含む受付番号の採番要求を店舗サーバ２０に送信することによって、店舗サーバ２０から採番された受付番号を取得する（ステップＳ１１２）。また、番号札発行処理部３９ｄは、ステップＳ１１２で取得した受付番号の記載された番号札を番号札プリンタ３７で印刷する（ステップＳ１１３）。

最後に、伝票項目データ送信部３９ｅは、生成された伝票項目データ３８ｄを店舗サーバ２０に送信して、顧客データ３８ａ、伝票項目データ３８ｄ、顔画像データ３８ｇをクリアして（ステップＳ１１４）、処理を終了する。

次に、図２に示した店舗サーバ２０の実施例１に係る受付番号採番要求を受け付けた時の処理手順を説明する。図１１は、店舗サーバ２０の実施例１に係る受付番号採番要求を受け付けた時の処理手順を示すフローチャートである。

電子記帳機３０からの受付番号の採番要求を受け付けていて（ステップＳ２０１；Ｙｅｓ）、受け付けた受付番号の採番要求に含まれる顧客データ３８ａの顧客区分が、顧客データ２４ａに含まれる同じ顧客の顧客区分の値から更新されている場合（ステップＳ２０２；Ｙｅｓ）には、受付番号管理部２５ｂは、電子記帳機３０から受け付けた顧客データ３８ａの顧客区分の内容を顧客データ２４ａに含まれる同じ顧客の顧客区分に反映する（ステップＳ２０３）。

電子記帳機３０からの受付番号の採番要求を受け付けていない場合（ステップＳ２０１；Ｎｏ）には、処理を終了する。受け付けた受付番号の採番要求に含まれる顧客データ３８ａの顧客区分が、顧客データ２４ａに含まれる同じ顧客の顧客区分の値から更新されていない場合（ステップＳ２０２；Ｎｏ）には、ステップＳ２０３をスキップしてステップＳ２０４に移行する。

電子記帳機３０から受け付けた受付番号の採番要求に含まれる顧客データ３８ａに顔画像の特徴データが存在して（ステップＳ２０４；Ｙｅｓ）、顧客データ２４ａに同じ顧客に関連付けられた顔画像の特徴データが登録されていない場合（ステップＳ２０５；Ｙｅｓ）には、受付番号管理部２５ｂは、電子記帳機３０から受け付けた受付番号の採番要求に含まれる顧客データ３８ａに顔画像の特徴データを、顧客データ２４ａに同じ顧客に対応する顔画像の特徴データとして登録する（ステップＳ２０６）。

電子記帳機３０から受け付けた受付番号の採番要求に含まれる顧客データ３８ａに顔画像の特徴データが存在ない場合（ステップＳ２０４；Ｎｏ）、又は電子記帳機３０から受け付けた受付番号の採番要求に含まれる顧客データ３８ａに顔画像の特徴データが存在して（ステップＳ２０４；Ｙｅｓ）いても、顧客データ２４ａに同じ顧客に関連付けられた顔画像の特徴データが登録されている場合（ステップＳ２０５；Ｎｏ）には、ステップＳ２０６の処理はスキップしてステップＳ２０７に移行する。

受付番号管理部２５ｂは、電子記帳機３０から受け付けた受付番号の採番要求に含まれる来店目的及び顧客データ３８ａの顧客区分と、誘導先設定データ２４ｅに基づいて、顧客の誘導先を決定する（ステップＳ２０７）。また、受付番号管理部２５ｂは、ステップＳ２０７で決定した誘導先に応じた受付番号を採番して、受付番号の採番要求元の電子記帳機３０に採番した受付番号を通知する（ステップＳ２０８）。

受付番号管理部２５ｂは、電子記帳機３０から受け付けた受付番号の採番要求に含まれる顧客データ３８ａに含まれる情報、ステップＳ２０７で決定した顧客の誘導先の情報をステップＳ２０８で採番した受付番号に関連付くデータとして受付番号状況データ２４ｂに追加登録して（ステップＳ２０９）、処理を終了する。

上述してきたように、実施例１では、固定資産税などの納付に係る納付依頼書に係る情報を受け付けて、該情報に含まれる納付額に基づいて重要顧客であるか否かを判定し、重要顧客と判定された場合にはテラーモニタ９１及び役席モニタ９０などで金融機関の担当者及び役席者に重要顧客来店の旨を報知するともに、全店の店舗サーバ２０が有する顧客データ２４ａに含まれる当該顧客の情報に重要顧客であることを反映し、重要顧客と判定した顧客はローカウンタなどに誘導して重要顧客に応じたサービスが行えるよう構成したので、過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度を適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことができる。

なお、実施例１では、主に固定資産税の納付金額に基づいて顧客が重要顧客であるか否かの判定を行うこととしたが、説明した内容は一例であって本発明はこれに限定されるものではない。例えば顧客の所得規模が反映される住民税や、顧客が法人である場合の法人税、事業税、消費税などに基づいて判定するようにしてもよい。また、本発明は判定基準として税金の納付金額に限定するものでもなく、例えば社会保険料の納付金額や所定期間の出金額の累計などであってもよい。

また、実施例１では、電子記帳機３０において重要顧客であるか否か及び重要顧客である場合に重用顧客のランクの判定を行った結果を、センタサーバ８０及び店舗サーバ２０が有する顧客データ８４ａ、２４ａに反映するようにしたが、本発明はこれに限定されるものではない。例えば、電子記帳機３０の重要顧客の判定結果は、顧客データ８４ａ、２４ａには反映しないものとしてもよい。又は、例えば、電子記帳機３０の重要顧客の判定基準ごとに、顧客データ８４ａ、２４ａへの反映をするか否かの指定ができるようにしてもよい。

また、実施例１では、受け付けた伝票項目の内容に基づいて電子記帳機３０において重要顧客であるか否かの判定を行うことを説明してきたが、本発明はこれに限定されるものではない。例えば、電子記帳機３０で受け付けた内容を店舗サーバ２０等の上位装置に送信して、該上位装置が重要顧客であるか否かの判定を行うものとしてもよい。

実施例１では、電子記帳機３０で顧客により入力された伝票の項目の内容に基づいて該顧客が重要顧客であるか否かの判定を行う例を説明した。しかしながら、実施例１に示した例では、一時点の状態で顧客が重要顧客であるか否かを判定することとなり、例えば現時点では設定された条件を満たさないものの、事業が軌道に乗って急速に成長を続けているような顧客の場合には、重要顧客とは判定されない。そこで、実施例２では、顧客の所定期間おける伸び率に基づいて重要顧客の判定を行う例を説明する。

まず、センタサーバ１８０の実施例２に係る内部構成を説明する。図１２は、センタサーバ１８０の実施例２に係る内部構成を示すブロック図である。図１２では、実施例１の図８に示したセンタサーバ８０と同じ構成要素については同じ符号を付与し、実施例１のセンタサーバ８０と異なる構成要素については新たな符号を付与した。センタサーバ１８０の内部構成の説明においては、実施例１のセンタサーバ８０と同じ構成要素についての説明は省略し、実施例１のセンタサーバ８０と異なる構成要素を中心に説明するものとする。

記憶部８４には、実施例１のセンタサーバ８０と比較すると、統計処理結果データ１８４ｃ及び重要顧客判定基準データ１８４ｄが追加されている。統計処理結果データ１８４ｃは、取引履歴データ８４ｂに基づいて、顧客ごとに過去の取引履歴の集計を時系列に行った結果である。重要顧客判定基準データ１８４ｄは、統計処理結果データ１８４ｃに基づいて、顧客が重要顧客であるか否か及び重要顧客である場合には重要顧客のランクを判定するための基準データである。

制御部８５には、実施例１のセンタサーバ８０と比較すると、統計処理部１８５ｃと重要顧客判定処理部１８５ｄが追加になっている。統計処理部１８５ｃは、取引履歴データ８４ｂに基づいて、顧客及び時系列に統計処理を行って統計処理結果データ１８４ｃを生成する処理部である。重要顧客判定処理部１８５ｄは、統計処理部１８５ｃにより生成された統計処理結果データ１８４ｃと、重要顧客判定基準データ１８４ｄに基づいて顧客が重要顧客であるか否か及び重要顧客である場合には重要顧客のランクを判定し、判定結果を顧客データ８４ａに反映する。また、このようにして重要顧客のランクが更新された場合には、顧客データ管理部８５ａは、更新された内容を全店の店舗サーバ２０に配信する。

次に、図１２に示したセンタサーバ１８０の実施例２に係るデータ構成について、図１３を用いて説明する。

統計処理結果データ１８４ｃは、顧客番号ごとに過去５年間の固定資産税納付額及び過去３年間の法人税納付額などを集計したデータである。図１３の統計処理結果データ１８４ｃの１レコード目の例は、顧客番号が「１１２２３３４４５５」の顧客が、固定資産税を最終年度に「６００」千円、（最終−１）年度に「４００」千円、（最終−２）年度に「０」千円、（最終−３）年度に「２００」千円、（最終−４）年度に「２００」千円納付していて、法人税については過去３年間には納付履歴がないことを示している。また、図１３の統計処理結果データ１８４ｃの２レコード目の例は、顧客番号が「６６７７８８９９００」の顧客が、固定資産税については過去５年間に納付履歴がなく、法人税を最終年度に「１，５００」千円、（最終−１）年度に「０」千円、（最終−２）年度に「１，８００」千円納付していることを示している。

重要顧客判定基準データ１８４ｄは、顧客が重要顧客であるか否か及び重要顧客である場合に重要顧客のランクを固定資産税及び法人税の過去の納付金額の推移に基づいて判定するための基準が設定されたデータである。固定資産税にかかる判定基準は、重要顧客のランクごとに、最終年度の固定資産税の納付金額の下限値、平均伸び率の下限値、評価対象となる期間及び判定に必要な最低サンプル数を含む。法人税にかかる判定基準も固定資産税と同様に、重要顧客のランクごとに、最終年度の固定資産税の納付金額の下限値、平均伸び率の下限値、評価対象となる期間及び判定に必要な最低サンプル数を含む。

図１３の重要顧客判定基準データ１８４ｄの例は、固定資産税の最終年度の納付金額が「５００千円」以上で、評価対象期間である過去「５年間」に、少なくとも「４」年分の履歴があって、年平均伸び率が「７０％」以上であればランクを重要顧客Ａと判定し、固定資産税の最終年度の納付金額が「５００千円」以上で、評価対象期間である過去「５年間」に、少なくとも「４」年分の履歴があって、年平均伸び率が「５０％」以上であればランクを重要顧客Ｂと判定し、法人税税の最終年度の納付金額が「２，０００千円」以上で、評価対象期間である過去「３年間」に、少なくとも「２」年分の履歴があって、年平均伸び率が「５０％」以上であればランクを重要顧客Ａと判定し、法人税税の最終年度の納付金額が「１，０００千円」以上で、評価対象期間である過去「３年間」に、少なくとも「２」年分の履歴があって、年平均伸び率が「１００％」以上であればランクを重要顧客Ｂと判定するということを示している。

上述してきたように、実施例２では、実施例１で示した基準に基づく重要顧客の判定に加えて、顧客の過去の取引履歴から所定期間の固定資産税及び法人税などの納付金額の推移を集計し、現状の固定資産税又は法人税などの納付金額と所定期間における伸び率にかかる基準を満たしていることを条件として重要顧客であるか否か及び重要顧客である場合には重要顧客のランクを判定するよう構成したので、実施例１で示した基準だけでは重要顧客とは判定されなかったが、ある程度の固定資産税又は法人税などの納付金額があって成長性の高い顧客について重要顧客と判定するよう構成したので、顧客が店舗に来店した際に、該顧客の重要度を成長性も考慮した上で適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことができる。

なお、実施例２では、固定資産税及び法人税の所定期間の平均伸び率に基づいて重要顧客であるか否か及び重要顧客である場合重要顧客のランクを判定するものとしたが、説明した内容は一例であって本発明はこれに限定されるものではない。例えば顧客の所得規模が反映される住民税や、顧客が法人である場合の法人税、事業税、消費税などに基づいて判定するようにしてもよい。また、本発明は判定基準として税金の納付金額に限定するものでもなく、例えば社会保険料の納付金額や所定期間の出金額の累計などであってもよい。また、評価対象と期間や、集計サイクルについても、使用するデータの発生サイクルなどの特徴によっては月や四半期などを単位として行ってもよい。また、基準値として平均伸び率を使用する例を説明したが、例えば伸び率の増加率や、所定の伸び率を継続している年数などを基準値としてもよい。

実施例１及び実施例２では、顧客自身の取引履歴に基づいて該顧客が重要顧客であるか否かの判定を行う例を説明した。しかしながら、顧客が企業であるような場合には、顧客である企業の実績との相関の高い税金の納付額だけに基づいて重要顧客のランクを判定すると、まだ実績に現れていない事業環境の良し悪しが該ランクの判定に全く反映されず、適切にランク判定ができているとは言えない。そこで、実施例３では、金融機関が企業の信用調査などの結果として有している企業の事業環境に関する情報を重要顧客のランク判定に利用する例を説明する。

まず、電子記帳機１３０の実施例３に係る内部構成を説明する。図１４は、電子記帳機１３０の実施例３に係る内部構成を示すブロック図である。図１４では、実施例１の図３に示した電子記帳機３０と同じ構成要素については同じ符号を付与し、実施例１の電子記帳機３０と異なる構成要素については新たな符号を付与した。電子記帳機１３０の内部構成の説明においては、実施例１の電子記帳機３０と同じ構成要素についての説明は省略し、実施例１の電子記帳機３０と異なる構成要素を中心に説明するものとする。

記憶部３８の実施例１との差異は、顧客データ１３８ａが実施例１の顧客データ３８ａと差異があるという部分と、新たにランク補正基準データ１３８ｈが追加になっているという部分である。顧客データ１３８ａは、実施例１の顧客データ３８ａが有していた情報に追加して、顧客が企業である場合の該企業の事業環境を示す情報として顧客の取引先の企業に関する情報を含んでいる。

ランク補正基準データ１３８ｈは、一旦、実施例１及び実施例２で説明した手順で判定した結果を一次判定結果とした場合に、顧客データ１３８ａに追加された顧客の取引先の企業に関する情報に基づく一次判定結果の補正に係る基準を設定したデータである。

制御部３９の実施例１との差異は、重要顧客判定処理部１３９ｈが実施例１の重要顧客判定処理部３９ｈと差異があるという部分だけである。重要顧客判定処理部１３９ｈは、上記の一次判定結果を出すところまでは実施例１で説明した重要顧客判定処理部３９ｈと同じで、該一次判定結果と、顧客データ１３８ａに追加された顧客の取引先の企業に関する情報と、ランク補正基準データ１３８ｈとに基づいて、一次判定結果を補正して最終的な重要顧客のランクとする。

次に、図１４に示した電子記帳機１３０の実施例３に係るデータ構成を、図１５を用いて説明する。

顧客データ１３８ａは、店番から顔画像特徴データまでは、実施例１で説明した顧客データ３８ａに同じであり、その後ろに関連企業情報が追加されている。関連企業情報は、当該顧客が事業推進上関係する企業ごとに、該企業の顧客コード、該企業の顧客区分及び該企業に対する事業の依存度を含む。図１４の顧客データ１３８ａの関連企業情報の例は、当該顧客が顧客コートが「２２４４６６８８００」の企業と取引があり、該企業の顧客区分が「重要顧客Ａ」で、該企業に対する事業の依存度が「８０％」であることを示している。

ランク補正基準データ１３８ｈは、一次判定ランクと、補正後のランクと、一次判定ランクを補正後のランクに補正を認める条件とをレコード項目とするデータである。補正を認める条件には、関連する企業の顧客区分と該顧客区分の顧客に対する事業の依存度の下限値とを含む。図１５のランク補正基準データ１３８ｈは、一次判定ランクが「重要顧客Ｃ」である場合には、「重要顧客Ａ」の企業に事業の依存度が「８０％」以上である場合には、重要顧客のランクを「重要顧客Ｂ」とされることを示している。

上述してきたように、実施例３では、顧客の取引先の企業、該企業の優良度及び該企業に対する事業の依存度などの顧客の事業環境の状況を示す情報を管理し、該事業環境を示す情報に従って実施例１又は実施例２で示した基準に基づいて判定した重要顧客のランクの補正を行うよう構成したので、顧客が店舗に来店した際に、該顧客の重要度を顧客の事業環境も考慮した上で適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことができる。

なお、実施例３では、顧客の事業環境を評価する指標として取引先のランクと該取引先の依存度を使用する例を説明したが、本発明はこれに限定されるものではない。例えば、顧客の行っている事業領域の市場規模の成長率や、顧客の行っている事業の市場全体に占めるシェアなどであってもよい。

なお、実施例３では、実施例１及び実施例２に基づく一次判定の結果を、顧客の事業環境を表す指標に基づいて補正するものとしたが、本発明はこれに限定されるものではない。例えば、一次判定に使用したデータと、顧客の事業環境を表す指標との組み合わせによって総合的に重要顧客であるか否か及び重要顧客である場合に重用顧客のランクを判定するものとしてもよい。

また、上述の実施例１、実施例２及び実施例３で図示した各構成は機能概略的なものであり、必ずしも物理的に図示の構成をされていることを要しない。すなわち、各装置の分散・統合の形態は図示のものに限られず、その全部又は一部を各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

以上のように、本発明に係る顧客対応システム及び顧客対応方法は、過去の取引実績がない顧客が店舗に来店した際に、該顧客の重要度を適切かつ効率的に判定し、もって顧客の重要度に応じた対応を適切に行うことに適している。

１０ 受付機
１１、３１ 表示操作部
１２ 番号札印刷部
１３、３３ カードリーダ
２０ 店舗サーバ
２１、８１ 入力部
２２、８２ 表示部
２３、３２、８３ 通信部
２４、３８、８４ 記憶部
２４ａ、３８ａ、８４ａ、１３８ａ 顧客データ
２４ｂ 受付番号状況データ
２４ｃ 顧客滞留状況データ
２４ｄ、３８ｄ 伝票項目データ
２４ｅ 誘導先設定データ
２５、３９、８５ 制御部
２５ａ 顧客データ検索部
２５ｂ 受付番号管理部
２５ｃ 行員報知部
２５ｄ 伝票データ管理部
２５ｅ 呼出処理部
２５ｆ 顧客データ同期処理部
２５ｇ、３９ｅ 伝票項目データ送信部
２５ｈ 来店状況出力処理部
３０、１３０ 電子記帳機
３０ａ カメラ
３４ 通帳ＭＳリーダ
３５ イメージスキャナ
３６ プリンタ
３７ 番号札プリンタ
３８ｂ 伝票イメージテンプレートデータ
３８ｃ 伝票決定パラメータ
３８ｅ 合成伝票イメージデータ
３８ｆ 重要顧客判定条件データ
３８ｇ 顔画像データ
３９ａ、８５ａ 顧客データ管理部
３９ｂ 伝票項目データ生成部
３９ｃ 伝票印刷処理部
３９ｄ 番号札発行処理部
３９ｆ 帳票イメージ処理部
３９ｇ 顔画像取得部
３９ｈ、１３９ｈ、１８５ｄ 重要顧客判定処理部
８０、１８０ センタサーバ
８４ｂ 取引履歴データ
８５ｂ 取引履歴収集部
９０ 役席モニタ
９１ テラーモニタ
９２ 番号呼出装置
９３ ロビー端末
１３８ｈ ランク補正基準データ
１８４ｃ 統計処理結果データ
１８４ｄ 重要顧客判定基準データ
１８５ｃ 統計処理部

Claims (7)

1. 顧客の来店目的に応じた書類データを受け付ける受付手段と、
   前記受付手段により受け付けた前記書類データに含まれる取引金額に基づいて、前記顧客が重要顧客であるか否かを判定する判定手段と、
   前記判定手段により前記顧客が重要顧客であると判定された場合に、前記書類データに対応する顧客が重要顧客である旨の情報を報知する報知手段と
   を備えたことを特徴とする顧客対応システム。
2. 前記書類データは、税金又は公共料金の納付に係る情報であり、
   前記判定手段は、前記税金又は公共料金の納付に係る情報に含まれる税金又は公共料金の納付金額に基づいて判定する
   ことを特徴とする請求項１に記載の顧客対応システム。
3. 前記重要顧客のランクと各ランクに位置づけられる重要顧客を案内する場所を示す案内情報を対応付けて記憶する案内情報記憶手段をさらに備え、
   前記判定手段は、
   前記受付手段により受け付けた前記書類データに含まれる取引金額に基づいて、前記顧客が重要顧客であるか否かと、重要顧客である場合の顧客のランクを判定し、
   前記報知手段は、
   前記書類データに含まれる顧客に係る情報とともに前記案内情報記憶手段に記憶された当該顧客のランクに対応する案内情報を報知する
   ことを特徴とする請求項１又は２に記載の顧客対応システム。
4. 前記案内情報記憶手段は、最上位のランクと顧客応接用の応接室とを対応付け、最上位以外のランクと顧客が着席可能な窓口とを対応付けて記憶することを特徴とする請求項３に記載の顧客対応システム。
5. 各顧客の識別情報と、該顧客の過去の所定期間における取引金額とを対応付けて記憶する過去取引履歴記憶手段をさらに備え、
   前記判定手段は、
   前記受付手段により受け付けた書類データに含まれる取引金額及び前記過去取引履歴記憶手段に記憶された該顧客の過去の所定期間における取引金額に基づいて、前記顧客が重要顧客であるか否かを判定する
   ことを特徴とする請求項１に記載の顧客対応システム。
6. 各顧客と該顧客の取引先に係る情報とを対応付けて記憶する取引先情報記憶手段と、
   前記取引先情報記憶手段に記憶された該顧客の取引先に係る情報に基づいて、前記判定手段により判定された顧客のランクを補正する補正手段と
   をさらに備えたことを特徴とする請求項３に記載の顧客対応システム。
7. 店舗に来店した顧客に対応した処理を行う顧客対応システムにおける顧客対応方法であって、
   顧客の来店目的に応じた書類データを受け付ける受付工程と、
   前記受付工程により受け付けた書類データに含まれる取引金額に基づいて、前記顧客が重要顧客であるか否かを判定する判定工程と、
   前記判定工程により前記顧客が重要顧客であると判定された場合に、前記書類データに対応する顧客が重要顧客である旨の情報を報知する報知工程と
   を含んだことを特徴とする顧客対応方法。

Images