JP2009230689A - 予約処理システム - Google Patents

Abstract

【課題】各顧客の要望に対応し得る予約処理システムを提供する。
【解決手段】顧客からの対人業務に関する予約を処理するシステムであって、顧客ＩＤごとに顧客の利用実績に関する履歴データを記憶する顧客情報データベース８と、顧客の予約内容に対し、前記履歴データに基づいて顧客の要望に合うデリバリチャネル２を予測し、前記予約内容に対して対応可能なそのデリバリチャネル２の候補を抽出する予約サーバ４と、顧客に抽出したデリバリチャネル２の候補を提示する提示手段と、を備える予約処理システム１とした。
【選択図】図１

Description

本発明は、顧客からデリバリチャネルを介して申し込まれた対人業務に関する予約を処理するシステムに関する。

顧客が銀行などの金融機関に対して金融商品（預金、ローン、投資信託、保険等）の相談予約を行う場合、特定の営業店舗に赴き或いは電話をかけ、商品担当者を呼び出してもらって口頭で相談日時を決めるというやり方が一般的である。

近年では顧客と金融機関との接点となるデリバリチャネルの一部も利用されはじめており、営業店舗の窓口、ＡＴＭ、インターネット、コールセンタなど、各種のデリバリチャネルが存在する内でインターネットを利用した予約システムが運営されている。

なお、金融機関の関連ではないが、複数のテナント間で顧客情報を共有する管理システムにおいて、テナントビルに設置した専用端末を介して或いはインターネット経由で入力された予約の処理技術に関する一例が特許文献１に記載されている。
特開２００１−２５６２８５号公報（段落００２９〜００３６）

顧客にとって商品担当者との口頭による予約方法では、所望する相談日時を決めることはできるが、相談場所についてはその商品担当者の在籍する営業店舗に限られてしまうことになる。顧客のニーズとして、例えば平日なら自分の職場に近い営業店舗で、休日なら家族と一緒に相談したいので自宅近くやショッピング途上路にある営業店舗で相談したいということも考えられ、この場合、予約時になるべく自分の要望に合った相談場所の選択肢を提示してくれると顧客にはとても便利であるが、前記営業店舗での口頭による予約方法では対応が困難である。

インターネットを利用した予約方法は、例えばインターネット接続した携帯電話の発信電波を基に、電話をかけている場所から最寄りの営業店舗を自動的に抽出して顧客に案内するものであり、前記口頭による予約方法と同様、顧客の要望に合った相談場所の選択肢を提示するものではない。

なお、専用端末やインターネットを用いた予約システムの従来例である特許文献１の技術は、顧客が自分の利用したいテナントに予約をいれたうえでの予約処理に関するものであり、場所の選択という課題は無い。

本発明は、以上のような問題を解決するために創作されたものであり、各顧客の要望に対応し得る予約処理システムを提供することを目的としている。

本発明の手段は、前記課題を解決するため、顧客からの対人業務に関する予約を処理するシステムであって、顧客ＩＤごとに顧客の利用実績に関する履歴データを記憶する記憶手段と、顧客の予約内容に対し、前記履歴データに基づいて顧客の要望に合うデリバリチャネルを予測し、前記予約内容に対して対応可能なそのデリバリチャネルの候補を抽出する抽出手段と、顧客に前記デリバリチャネルの候補を提示する提示手段と、を備えることを特徴とする予約処理システムとした。

この予約処理システムによれば、顧客の利用実績に基づいて、顧客の要望に合いそうなデリバリチャネルの候補を予測し、その中で顧客の予約内容に対して対応可能なもの、すなわち予約が可能である候補を提示するため、顧客の要望に即した予約サービスを提供できる。

また、前記デリバリチャネルは複数の営業店舗を含み、前記抽出手段は、前記複数の営業店舗の内の所定数を候補として抽出することを特徴とする予約処理システムとした。

この予約処理システムによれば、営業店舗の候補を所定数抽出するため、顧客にとっては自分の要望に最も適した営業店舗を予約できる。

また、前記抽出手段は、前記履歴データの内の少なくとも予約情報に基づいて顧客の要望に合うデリバリチャネルを予測することを特徴とする予約処理システムとした。

この予約処理システムによれば、少なくとも顧客の予約情報に基づいてデリバリチャネルを予測するため、顧客が望む確率の高いデリバリチャネルを抽出でき、予測精度に優れた予約サービスを提供できる。ここで、「予約情報」とは、顧客の予約履歴に関する情報であって、顧客を特定する顧客ＩＤ、予約指定された日付を示す予約日付、予約指定された時刻を示す予約時刻、保険、投資信託、ローンなど具体的な相談内容を示す取引種別、予約指定された店舗名などを示す予約チャネル、応対した担当者を示す担当者ＩＤなどからなる。

また、前記抽出手段は、以前に顧客が予約指定した回数の多いものからデリバリチャネルを抽出することを特徴とする予約処理システムとした。

この予約処理システムによれば、以前に顧客が予約指定した回数の多いものからデリバリチャネルを抽出するため、顧客が望む確率の一層高いデリバリチャネルを抽出でき、予測精度に優れた予約サービスを提供できる。

また、顧客の予約内容は取引種別を含み、前記抽出手段は、以前に顧客が同じ取引種別で予約指定した回数の多いものからデリバリチャネルを抽出することを特徴とする予約処理システムとした。

この予約処理システムによれば、取引種別に関する顧客の予約傾向に基づいてデリバリチャネルを抽出するため、顧客が望む確率の一層高いデリバリチャネルを抽出でき、予測精度に優れた予約サービスを提供できる。

また、顧客の予約内容は日時情報を含み、前記抽出手段は、以前に顧客が平日か休日かの条件が一致しかつ略同じ予約時刻帯で予約指定した回数の多いものからデリバリチャネルを抽出することを特徴とする予約処理システムとした。

この予約処理システムによれば、取引日時に関する顧客の予約傾向に基づいてデリバリチャネルを予測するため、顧客が望む確率の一層高いデリバリチャネルを抽出でき、予測精度に優れた予約サービスを提供できる。

また、前記抽出手段により抽出されたデリバリチャネルの候補ごとに、応対の担当者を仮決めする担当者仮決め手段をさらに備えることを特徴とする予約処理システムとした。

この予約処理システムによれば、後に担当者を本決めする際の段取りもスムースとなり、担当者本人も自分が指名された状況を把握しやすくなる。仮決めした担当者の名前をデリバリチャネルの候補とともに顧客に提示することもでき、さらに、適任の担当者が複数いる場合にはその担当者の候補を顧客に提示すれば、顧客は自分の相談環境に合った人物を選べる。

本発明によれば、顧客の行動履歴に基づいてデリバリチャネルを予測するため、各顧客の要望に即した予約サービスを提供できる。

本発明を金融機関の予約処理システムに適用した形態について説明する。図１は本発明に係る予約処理システムの構成例を示し、図２は本発明における概略的な予約処理の流れをイメージで示している。

図２において、顧客が予約操作を行うデリバリチャネルで相談申し込みの予約を行うと（ステップＳ１）、予約処理システムの呼び出しが行われ（ステップＳ２）、予約処理システムは各処理を経て相談対応が可能でかつ顧客の要望に合うデリバリチャネル（店舗）を予測する。予測されたデリバリチャネルは顧客が望むデリバリチャネルの予約候補として相談予約の設定がなされ（ステップＳ３）、顧客にその予約候補が提示される（ステップＳ４）。顧客が提示された中から１つを選び予約が成立すると、顧客が望んだ場所（デリバリチャネル）や日付などの予約情報が顧客情報データベースに記録される（ステップＳ５）。なお予約候補の提示は、予約操作を行うデリバリチャネルの表示装置あるいは音声出力装置等の出力手段によって行われる。

以下、図１を参照して予約処理システムの具体的な構成について説明する。予約処理システム１の基本構成は、顧客に対する金融サービスの提供ルートであるデリバリチャネル２と、このデリバリチャネル２にＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）などのネットワーク３を介して接続する予約サーバ４と、この予約サーバ４にそれぞれ接続するＣＲＭ（Customer Relationship Management）サーバ５および予約情報６を有する顧客情報データベース８とからなる。

予約操作を行う際のデリバリチャネル２としては、顧客側が所有するパソコンや携帯電話などの顧客端末９、営業店舗１０の窓口に設置された端末システム１０Ａ、各種金融の自動取引装置であるＡＴＭ１１、電話による案内サービスであるコールセンタ１２などが挙げられる。デリバリチャネル２で顧客が申し込む予約内容は、相談したい予約日時、取引種別（保険、投資信託、ローンなど具体的な金融商品の相談内容）などである。

仮に保険について相談予約する場合、各デリバリチャネル２での操作態様は概ね次の通りとなる。

（１）顧客端末９を用いてインターネット経由で予約する場合、自己の顧客ＩＤやパスワードを入力したうえで、モニタに表示された予約案内画面で各取引種別の中から「保険」をクリックする。予約日時の指定がある場合には、所望の日時を入力する。

（２）営業店舗１０の端末システム１０Ａを用いて予約する場合、窓口担当者に自己の顧客ＩＤやパスワードを伝えたうえで、保険について相談予約したい旨や所望の日時を伝え、入力してもらう。

（３）ＡＴＭ１１を用いて予約する場合、自己の顧客ＩＤやパスワードを入力したうえで、操作ディスプレイに表示された予約案内画面で各取引種別の中から「保険」の欄を指で押す。予約日時の指定がある場合には、所望の日時を入力する。

（４）コールセンタ１２を用いて予約する場合、電話担当者に自己の顧客ＩＤやパスワードを伝えたうえで、保険について相談予約したい旨や所望の日時を伝え、コールセンタ１２に設置された専用端末で入力してもらう。

ＣＲＭサーバ５は、ＣＲＭサービス、すなわち各顧客の行動、嗜好を基に各顧客に適合した金融サービスを予測して提供するサービスの処理を行うサーバであり、顧客情報データベース８と接続している。

顧客情報データベース８は、顧客ＩＤごとに顧客の利用実績に関する履歴データを記憶する記憶手段として構成され、顧客情報７と後に詳述する予約情報６とを有する。顧客情報７には、例えば顧客の基本情報（氏名、住所、年齢、職業、家族構成など）、口座情報（保有口座情報、預金金額、貸出金額など）、取引履歴情報（入金、出金などの取引内容時系列情報など）、工作情報（紹介・推奨商品情報など）、工作履歴情報（セールス経緯、結果など）、その他情報（例えば、顧客の趣味、ライフスタイル、興味のある商品など）が格納されている。ＣＲＭサーバ５は、これらの情報を基にして各目的に応じた解析を行い、例えば新規のキャンペーン商品に対して有望そうな顧客をピックアップするなどの処理を行う。

予約サーバ４は、デリバリチャネル２を介して申し込まれた顧客の予約内容に対し、前記顧客の利用実績に関する履歴データに基づいて、顧客の要望に合うデリバリチャネル２を予測し、顧客の予約内容に対して対応可能な、つまりまだ予約を受け付ける空きのあるそのデリバリチャネル２の候補を抽出する抽出手段を構成する。抽出される候補は、もちろん金融商品の相談など対人業務が可能なデリバリチャネル２であり、最も好ましいのは直接の接客対応ができる営業店舗１０であるが、電話での相談も可能なコールセンタ１２も抽出対象となり得る。

予約サーバ４の構成例としては、予約受付処理部４１、顧客予約予測処理部４２および推奨チャネル抽出部４３を備えたものとする。予約受付処理部４１は、デリバリチャネル２を介して申し込まれた顧客の予約内容の受付処理をする。

顧客予約予測処理部４２は、予約受付処理部４１で受け付けた予約内容に対し、少なくとも予約情報６を検索し、適宜に顧客情報７を検索して、顧客の要望に合うデリバリチャネル２を予測する。

予約情報６の構成例を図３に示す。予約情報６は、顧客の予約履歴に関する情報であって、顧客を特定する顧客ＩＤ、予約指定された日付を示す予約日付、予約指定された時刻を示す予約時刻、保険、投資信託、ローンなど具体的な金融商品の相談内容を示す取引種別、予約指定された店舗名などを示す予約チャネル、応対した担当者を示す担当者ＩＤなどからなる。この予約情報６は、基本的に予約が成立して実際に相談が行われたものが格納される。場合によっては、例えば予約が成立したものの顧客が途中でキャンセルして相談が行われなかったものも格納しておいてもよく、この場合、担当者ＩＤの欄だけを空欄にする措置で足りることになる。

図３に示した例では、番号“０００１”の顧客ＩＤで特定される顧客が、２００７年９月１日の午前１０時に保険に関する相談を営業店舗Ａ店で行う予約をし、そのとき担当者ＩＤ“Ａ００１”の担当者が相談を行い、同年１１月２５日の午後２時に投資信託に関する相談を営業店舗Ｃ店で行う予約をし、そのとき担当者ＩＤ“Ｃ００３”の担当者が相談を行い、２００８年３月７日の午前１０時にローンに関する相談を営業店舗Ａ店で行う予約をし、そのとき担当者ＩＤ“Ａ００２”の担当者が相談を行った場合を示しており、これらのデータは時系列的に格納管理される。

顧客予約予測処理部４２における予測演算プログラムは適宜に設定される。先ず、顧客が予約内容として取引種別のみを指定する場合、第１の設定例としては、以前に顧客が予約指定したことのあるデリバリチャネルを優先的に選び出す設定が挙げられる。つまり、以前に顧客が予約指定した回数の多いものからデリバリチャネルを選び出す。図３に示した例では、営業店舗Ａ店が最多の２回予約指定を受けている実績があるので、今回顧客の要望する営業店舗もＡ店である可能性が高いものと予測し、営業店舗Ａ店を最優先して選び出し、次いで１回の予約指定を受けたことのあるＣ店を選び出す。

第２の設定例としては、以前に顧客が同じ取引種別で予約指定したことのあるデリバリチャネルを優先的に選び出す設定が挙げられる。つまり、以前に顧客が同じ取引種別で予約指定した回数の多いものからデリバリチャネルを選び出す。例えば、今回顧客が予約したい取引種別が投資信託である場合、図３に示した例では、営業店舗Ｃ店が投資信託の相談を受けた実績があるので、今回顧客の要望する営業店舗もＣ店である可能性が高いものと予測し、営業店舗Ｃ店を優先して選び出す。

また、顧客が予約内容として予約日時を指定する場合、第３の設定例としては、以前に顧客が、平日か休日かの条件が一致しかつ略同じ予約時刻帯で予約指定したことのあるデリバリチャネルを優先的に選び出す設定が挙げられる。つまり、以前に顧客が、平日か休日かの条件が一致しかつ略同じ予約時刻帯で予約指定した回数の多いものからデリバリチャネルを選び出す。例えば、今回顧客が予約したい予約日時が平日の午前１０時である場合、図３に示した例では、２００７年９月１日、２００８年３月７日が平日であるとすると、営業店舗Ａ店が平日の午前１０時の予約で２回相談を受けた実績があるので、今回顧客の要望する営業店舗もＡ店である可能性が高いものと予測し、営業店舗Ａ店を優先して選び出す。予約時刻帯についてはある程度の許容幅を持たせるようにし、例えば予約指定された時刻に対して前後それぞれ１時間以内の時刻で相談した実績があれば、略同じ予約時刻帯とみなして処理すればよい。

平日と休日とに区分する理由は、営業店舗の殆どは平日のみ相談業務に対応可能であり、休日に対応可能なデリバリチャネルは特殊な営業店舗やコールセンタに限られることが多いので、両者を区分して処理することで顧客の要望に対する予測精度を高めるためである。

以上の複数の設定例を組み合わせた予測演算プログラムとすることも当然に可能であるが、この場合、予測するデリバリチャネルの数が増えてしまい、候補として絞りきれない事態も生じうる。例えば、デリバリチャネルを１つ予測したいのに、前記３つの設定例を均等に設定すると、図３の例ではＡ店、Ｃ店の両方とも条件を満たしてしまう。この場合、各設定例で選ばれるデリバリチャネルに異なる重み付け処理をすることで、予測するデリバリチャネルの数を絞ることができる。例えば、前記第１の設定例で選ばれるデリバリチャネルに最も大きな重み付け係数をかければその分、Ａ店の予測点数が大きくなるのでＡ店が選ばれ、前記第２の設定例で選ばれるデリバリチャネルに最も大きな重み付け係数をかければＣ店が選ばれる。各設定例の重み付け係数は適宜に設定される。

また、図１において、予約情報６に加えて顧客情報７も予測因子として利用することができる。例えば、顧客情報７の取引履歴情報から、顧客が或る営業店舗１０の窓口やＡＴＭ１１で頻繁に入出金、振込、振替などの取引をしているなどの状況が判るので、金融商品の相談予約でもこの営業店舗を要望する可能性が高いとし、この営業店舗１０に適宜な重み付け処理をするなどして予測対象にいれることができる。別例では、顧客情報７の工作履歴情報から、予約ではなく窓口で直接申し込まれた金融相談などの履歴が判るので、予約でもこの営業店舗１０を要望する可能性が高いとし、この営業店舗１０に適宜な重み付け処理をするなどして予測対象にいれることができる。

また、顧客の自宅の住所、職場の住所を基に、その住所から最も近い営業店舗１０に適宜な重み付け処理をするなどして予測対象にいれることもできる。ライフスタイルに関する情報も考慮でき、例えば或る顧客が夏休み期間は別荘で生活するなどの情報があれば、その期間の滞在先の住所等の滞在先情報を予め顧客情報として記憶しておき、その期間の予約指定があった場合、別荘に近い営業店舗１０を予測対象にいれることもできる。

以上の顧客予約予測処理部４２で予測されたデリバリチャネル２は、推奨チャネル抽出部４３により、予測点数の大きなものから決められた数だけ抽出される。

なお、顧客の予約内容の項目として、たとえ営業店舗１０の指定、つまり特定のデリバリチャネル２を予約指定する項目があったとしても、複数のデリバリチャネル２の候補を抽出する手段は有効である。例として、予約したい日付においてその営業店舗１０が既に他の予約で一杯になっていた場合、別の営業店舗１０の候補を抽出して顧客に提示することで、顧客は予め決めていた日取りを変えることなく相談できる、などの効果が挙げられる。

次に、予約サーバ４には、推奨チャネル抽出部４３により抽出されたデリバリチャネル２の候補ごとに、応対の担当者を仮決めする担当者仮決め処理部４４を設けることができる。仮決めする担当者としては、以前にその顧客に応対したことのある者が好ましく、今回予約指定された取引種別、予約時刻などと同じ条件で応対したことのある者がより好ましい。

図３の例では、例えば営業店舗Ａ店が候補に挙げられた場合、今回予約の取引種別が保険の場合には担当者ＩＤ“Ａ００１”の担当者を仮決めし、ローンの場合には担当者ＩＤ
“Ａ００２”の担当者を仮決めする。また、図示していないが、仮に今回の予約が保険に関して午後２時の指定であり、営業店舗Ａ店の別の担当者が保険に関して午後２時に相談していた履歴があれば、担当者ＩＤ“Ａ００１”の担当者よりもその別の担当者を仮決めする。

このように担当者を仮決めしておけば、店舗内において後の本決めの段取りもスムースとなり、担当者本人も自分が指名された状況を把握しやすくなる。仮決めされた担当者の名前は、デリバリチャネル２の候補とともに顧客に提示することもできる。また、適任の担当者が複数いる場合には、その担当者の候補を顧客に提示し、誰にするかを顧客に選択させて仮決めする態様にしてもよい。

図１において、推奨チャネル抽出部４３により抽出されたデリバリチャネル２の候補は、予約操作を行ったデリバリチャネル２により顧客に提示される。提示する候補数は適宜に設定される。各デリバリチャネル２での提示態様は概ね次の通りとなる。

（１）顧客端末９を用いてインターネット経由で予約操作した場合、モニタに予約可能なデリバリチャネル２の候補が表示される。もし、初めの予約操作時で取引種別のみ入力する態様の場合には、デリバリチャネル２の候補ごとに予約可能な日時が併せて表示される。顧客は候補の中から要望するデリバリチャネル２を選んでクリックし、日時の指定が必要な場合には指定して、予約を完了する。

（２）営業店舗１０の端末システム１０Ａを用いて予約した場合、端末システム１０Ａのモニタに予約可能なデリバリチャネル２の候補が表示される。もし、初めの予約操作時で取引種別のみ入力する態様の場合には、デリバリチャネル２の候補ごとに予約可能な日時が併せて表示される。窓口担当者は、その内容を印刷するなどして顧客に提示する。顧客は候補の中から要望するデリバリチャネル２を選び、日時の指定が必要な場合には指定して窓口担当者に伝える。窓口担当者は指定されたデリバリチャネル２や日時を端末システム１０Ａで入力し、予約を完了する。

（３）ＡＴＭ１１を用いて予約した場合、操作ディスプレイに予約可能なデリバリチャネル２の候補が表示される。もし、初めの予約操作時で取引種別のみ入力する態様の場合には、デリバリチャネル２の候補ごとに予約可能な日時が併せて表示される。顧客は候補の中から要望するデリバリチャネル２を選んでクリックし、日時の指定が必要な場合には指定して、予約を完了する。

ＡＴＭ１１の操作ディスプレイにおける提示例を図５に示す。提示表現は、金融機関から場所や日時を押し付けるものではなく、「お客様のお取引内容に関しては以下の店舗にて準備ができております」というように、ご提案というかたちの表現が好ましい。提示例は図５に限られず様々なレイアウトが考えられ、前記した仮決めした担当者の名前を表示したり、「お急ぎの場合や営業店時間外であれば、コールセンタをご利用ください」などの表示を行うことで、よりよいサービスを提供できる。

（４）コールセンタ１２を用いて予約した場合、コールセンタ１２に設置された専用端末のモニタに予約可能なデリバリチャネル２の候補が表示される。もし、初めの予約操作時で取引種別のみ入力する態様の場合には、デリバリチャネル２の候補ごとに予約可能な日時が併せて表示される。電話担当者はその内容を顧客に伝え、顧客は候補の中から要望するデリバリチャネル２を選び、日時の指定が必要な場合には指定して電話担当者に伝える。電話担当者は指定されたデリバリチャネル２や日時を専用端末で入力し、予約を完了する。

以上のようにして予約が完了すると、今回の予約情報が予約サーバ４により顧客情報データベース８の予約情報６に格納される。

予約処理システム１の一連の処理動作について図４を参照して、具体的な構成要素については適宜に図１を参照して説明する。図４は予約処理システム１の処理の流れを示すフローチャートである。顧客からＡＴＭ１１などのデリバリチャネル２により、顧客ＩＤやパスワードの入力を伴う予約の申し込みがあると（ステップＳ１０１のＹＥＳ）、予約サーバ４は顧客ＩＤから顧客を特定し（ステップＳ１０２）、その顧客に関して顧客情報データベース８（予約情報６、顧客情報７）を検索する（ステップＳ１０３）。ステップＳ１０１でＮＯの場合はステップＳ１０１の処理に戻る。

予約サーバ４は、予約内容と検索したデータとを照合して顧客の要望に合うデリバリチャネル２を予測し、抽出する（ステップＳ１０４）。所定数抽出した場合（ステップＳ１０５のＹＥＳ）、顧客が申し込みに使用しているデリバリチャネル２を介して、抽出した所定数のデリバリチャネル２の候補を提示する（ステップＳ１０６）。提示の候補数は適宜に設定され、全顧客に対して同数であってもよいし、顧客ごとに異なる仕様にしてもよい。ステップＳ１０５でＮＯの場合はステップＳ１０４の処理に戻る。

次いで顧客により候補が選択されると（ステップＳ１０７のＹＥＳ）、今回の予約情報が予約サーバ４により顧客情報データベース８の予約情報６に格納（記憶）され（ステップＳ１０８）、予約処理を終了する。ステップＳ１０７でＮＯの場合はステップＳ１０７の処理に戻る。

以上のように、図１において、顧客ＩＤごとに顧客の利用実績に関する履歴データを記憶する記憶手段（顧客情報データベース８）と、顧客の予約内容に対し、前記履歴データに基づいて顧客の要望に合うデリバリチャネル２を予測し、前記予約内容に対して対応が可能なそのデリバリチャネル２の候補を抽出する抽出手段（顧客予約予測処理部４２、推奨チャネル抽出部４３）と、顧客にデリバリチャネル２の候補を提示する提示手段（顧客が申し込みに使用しているデリバリチャネル２の提示画面など）と、を備える予約処理システム１とすれば、予約が可能であって、かつ顧客の要望に合いそうなデリバリチャネル２を複数提示でき、各顧客の要望に即した予約サービスを提供できる。

また、抽出手段（顧客予約予測処理部４２、推奨チャネル抽出部４３）は、履歴データの内の少なくとも予約情報６に基づいて顧客の要望に合うデリバリチャネルを予測・抽出する構成とすれば、顧客の予約傾向が反映されたデリバリチャネルを抽出できるため、予測精度に優れた予約サービスを提供できる。

また、抽出手段（顧客予約予測処理部４２、推奨チャネル抽出部４３）は、以前に顧客が予約指定した回数の多いものからデリバリチャネル２を抽出する構成とすれば、今回も同じデリバリチャネル２を選ぶ確率が高いとして、顧客が望む確率の一層高いデリバリチャネル２を抽出でき、予測精度に優れた予約サービスを提供できる。

また、顧客の予約内容が取引種別を含む場合において、抽出手段（顧客予約予測処理部４２、推奨チャネル抽出部４３）は、以前に顧客が同じ取引種別で予約指定した回数の多いものからデリバリチャネル２を抽出する構成とすれば、取引種別に関する顧客の予約傾向に基づいてデリバリチャネル２を予測するため、顧客が望む確率の一層高いデリバリチャネル２を抽出でき、予測精度に優れた予約サービスを提供できる。

また、顧客の予約内容が日時情報を含む場合において、抽出手段（顧客予約予測処理部４２、推奨チャネル抽出部４３）は、以前に顧客が平日か休日かの条件が一致しかつ略同じ予約時刻帯で予約指定した回数の多いものからデリバリチャネル２を抽出する構成とすれば、取引日時に関する顧客の予約傾向に基づいてデリバリチャネル２を予測するため、顧客が望む確率の一層高いデリバリチャネル２を抽出でき、予測精度に優れた予約サービスを提供できる。

さらに、抽出手段（顧客予約予測処理部４２、推奨チャネル抽出部４３）により抽出されたデリバリチャネル２の候補ごとに、応対の担当者を仮決めする担当者仮決め手段（担当者仮決め処理部４４）を備える構成とすれば、後に担当者を本決めする際の段取りもスムースとなり、担当者本人も自分が指名された状況を把握しやすくなる。
仮決めした担当者の名前をデリバリチャネル２の候補とともに顧客に提示してもよく、さらに、適任の担当者が複数いる場合にはその担当者の候補を顧客に提示すれば、顧客は自分の相談環境に合った人物を選べる。

以上、本発明について最良の実施形態を説明した。本発明の予約処理システムは、金融機関以外にも適用可能であり、例えば携帯電話会社のサービス網において携帯電話の契約に関する相談予約などに適用できる。また、説明した形態では、予約サーバ４とＣＲＭサーバ５とを分けていたが、予約受付処理部４１、顧客予約予測処理部４２、推奨チャネル抽出部４３、担当者仮決め処理部４４を備えていれば、両サーバを単体として構成してもよい。さらに、説明した形態では、予約情報６と顧客情報７とを備えた顧客情報データベース８としたが、もちろん予約情報６専用のデータベースと顧客情報７専用のデータベースとに分けてもよい。

また、予測したデリバリチャネル２の候補を顧客に提示可能なものであればその提示態様は説明したものに限られず、モニタや操作ディスプレイにおける提示画面のレイアウトも様々なものが考えられる。

顧客の利用実績を検索するという本発明の特徴部を利用して、予約処理とともに、その顧客の興味がありそうな金融商品（新規なキャンペーン商品など）を予測・抽出し、デリバリチャネル２の候補の提示に加えてその金融商品を広告宣伝することも可能である。

本発明に係る予約処理システムの構成例を示す図である。 本発明における概略的な予約処理の流れを示すイメージ図である。 予約情報の構成例を示す図である 本発明に係る予約処理システムの処理の流れを示すフローチャートである。 ＡＴＭの操作ディスプレイにおける提示例を示す図である。

符号の説明

１ 予約処理システム
２ デリバリチャネル
４ 予約サーバ
６ 予約情報
７ 顧客情報
８ 顧客情報データベース
４１ 予約受付処理部
４２ 顧客予約予測処理部
４３ 推奨チャネル抽出部
４４ 担当者仮決め処理部

Claims (7)

1. 顧客からの対人業務に関する予約を処理するシステムであって、
   顧客ＩＤごとに顧客の利用実績に関する履歴データを記憶する記憶手段と、
   顧客の予約内容に対し、前記履歴データに基づいて顧客の要望に合うデリバリチャネルを予測し、前記予約内容に対して対応可能なそのデリバリチャネルの候補を抽出する抽出手段と、
   顧客に前記デリバリチャネルの候補を提示する提示手段と、
   を備えることを特徴とする予約処理システム。
2. 前記デリバリチャネルは複数の営業店舗を含み、
   前記抽出手段は、前記複数の営業店舗の内の所定数を候補として抽出することを特徴とする請求項１に記載の予約処理システム。
3. 前記抽出手段は、前記履歴データの内の少なくとも予約情報に基づいて顧客の要望に合うデリバリチャネルを予測することを特徴とする請求項１または請求項２に記載の予約処理システム。
4. 前記抽出手段は、以前に顧客が予約指定した回数の多いものからデリバリチャネルを抽出することを特徴とする請求項３に記載の予約処理システム。
5. 顧客の予約内容は取引種別を含み、
   前記抽出手段は、以前に顧客が同じ取引種別で予約指定した回数の多いものからデリバリチャネルを抽出することを特徴とする請求項３に記載の予約処理システム。
6. 顧客の予約内容は日時情報を含み、
   前記抽出手段は、以前に顧客が平日か休日かの条件が一致しかつ略同じ予約時刻帯で予約指定した回数の多いものからデリバリチャネルを抽出することを特徴とする請求項３に記載の予約処理システム。
7. 前記抽出手段により抽出されたデリバリチャネルの候補ごとに、応対の担当者を仮決めする担当者仮決め手段をさらに備えることを特徴とする請求項１ないし請求項６のいずれかに記載の予約処理システム。

Images