JP2003316962A - 営業支援システム - Google Patents

Abstract

(57)【要約】 【課題】 本発明の課題は、既存の外部処理系にて処理
されている最新の情報を顧客が使用する端末装置に提供
できると共に、端末装置と外部処理系との間で情報交換
処理を行うことができるような営業支援システムを提供
することである。 【解決手段】 端末装置からの要求に応じて外部処理系
に対するサービス情報要求データを所定の形式にて作成
し、その作成されたサービス情報要求データの形式を外
部処理系にて処理可能な形式に変換すると共に、該サー
ビス情報要求データに応答して外部処理系から提供され
るサービス情報を当該所定の形式に変換し、更に、所定
の形式に変換されたサービス情報を要求元の端末装置に
提供するように構成した。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、営業支援システム
に係り、詳しくは、外部の既存処理系（銀行勘定系、証
券ホスト、データウエアハウスなど）と種々の端末装置
（チャンネル）とを接続し、既存処理系の最新の情報を
顧客が使用する最適な端末装置に提供できるようにする
と共に、端末装置からの情報をその顧客が希望する既存
処理系に提供できるようにした営業支援システムに関す
る。

【０００２】

【従来の技術】従来、例えば、図１に示すような構成の
営業支援システムが提案されている。この営業支援シス
テム６０は銀行内のコールセンターなどに設置されてお
り、銀行のフロアなどに設置されたコンピュータ端末装
置や電話器などのメディア１０と接続され、メディア１
０に対して種々のサービス情報を提供するように構成さ
れている。

【０００３】この営業支援システム６０は、銀行サービ
スに関するオペレータ業務の代行や補助を行うアプリケ
ーション６１、データの収集やデータ管理を行うデータ
管理オブジェクト６２、各データの所在場所などの定義
を行う項目定義ユニット６３及び顧客情報等のサービス
情報に関するデータベース６５を備えている。そして、
メディア１０から情報( 例えば、口座の残高照会) の要
求コマンドが入力されると、対応するアプリケーション
６１がデータ管理オブジェクト６２に要求に係る情報の
検索を依頼する。データ管理オブジェクト６２は、要求
に係る情報がデータ管理オブジェクト６２内にあれば、
そのままその情報をアプリケーション６１に返す。ま
た、要求に係る情報がデータ管理オブジェクト６２にな
ければ、項目定義ユニット６３を参照してデータベース
６３からその要求に係る情報( 口座残高) を検索してデ
ータ管理オブジェクト６２内に取り込むと共にアプリケ
ーション６１に返す。

【０００４】アプリケーション６１は、要求に係る情報
をデータ管理オブジェクト６２から得ると、その情報を
要求のあったメディア１０に返送する。その結果、その
メディア１０を使用する顧客は、口座残高等のサービス
情報をメディア１０を介して得ることができる。

【０００５】

【発明が解決しようとする課題】ところで、上述したよ
うな従来の営業支援システムでは、顧客情報のサービス
情報に関するデータベース６５は、通常、週単位、月単
位でのバッチ処理、あるいは、ディレード処理により銀
行の勘定系や各所のデータウエアハウスから情報を集め
て更新される。従って、メディア１０を用いた顧客から
の要求に対して、実際に銀行の勘定系で管理されている
情報と異なる場合があり、最新の情報を提供することが
できない。

【０００６】また、銀行の勘定系、データウエアハウス
などの外部の処理系に直接接続されていないことから、
銀行の勘定系との間で行うべき処理( 振り込み処理、ロ
ーン契約など) は、別系統のシステムにて行わなければ
ならない。そこで、本発明の課題は、既存の外部処理系
にて処理されている最新の情報を顧客が使用する端末装
置に提供できると共に、端末装置と外部処理系との間で
情報交換処理を行うことができるような営業支援システ
ムを提供することである。

【０００７】

【課題を解決するための手段】上記課題を解決するた
め、本発明に係る営業支援システムは、請求項１に記載
されるように、プロトコルの異なる複数の処理系と、顧
客が利用する複数の端末装置とに、ネットワークを介し
て接続され、顧客から要求に応じて要求されたサービス
に係る情報を提供する営業支援システムであって、端末
装置を介して、顧客からの要求を受け付けるサービス要
求受付手段と、受け付けた顧客からの要求に応じて、前
記処理系において当該顧客に対応づけて記憶されている
顧客情報のうち、当該要求に必要となる当該顧客情報の
データ項目の内容を要求するデータ要求手段と、予めデ
ータ項目とデータ項目の内容が格納されている前記処理
系から当該データ項目の内容を取得するためのデータア
クセスルーチンとが対応付けられて記憶されている項目
定義部を参照して、要求された顧客のデータ項目に対応
するアクセスルーチンを起動するアクセスルーチン起動
手段と、起動されたアクセスルーチンから発行された取
得要求を、取得要求先である処理系と前記端末装置との
間のデータ交換に使用されるプロトコルに変換して、当
該処理系に送出する取得要求プロトコル変換手段と、前
記処理系から取得要求に基づいて返信されてきたデータ
項目の内容を、前記顧客の端末装置に送出するサービス
提供手段とを備えるように構成される。

【０００８】このような営業支援システムでは、顧客の
操作により端末装置からサービス情報要求データが入力
されると、所定の形式のサービス情報要求データが作成
される。そして、そのサービス情報要求データが外部処
理系にて処理可能な形式に変換( プロトコル変換など)
される。外部処理系は、営業支援システムからのサービ
ス情報要求データに応答してサービス情報を返送する。
この返送されたサービス情報は上記所定の形式に変換さ
れ( プロトコル変換など) 、サービス情報の要求元の端
末装置に提供される。

【０００９】このようなシステムによれば、外部処理系
に対してサービス情報要求データが当該外部処理系で処
理可能な形式にて提供されると共に、そのサービス情報
要求データに応答して外部処理系から返送された当該外
部処理系独自の形式のサービス情報が所定の形式に変換
される。従って、この外部処理系は、特に当該営業支援
システムとの入出力関係を考慮することなく接続するこ
とができる。そして、営業支援システムは、当該外部処
理系からの最新のサービス情報を仮想的なデータベース
からの情報として要求元の端末装置に提供することがで
きる。

【００１０】また、この営業支援システムは、外部処理
系に接続されているので、端末装置と外部処理系との間
で行われる情報交換処理の支援を行うことができる。

【００１１】また、本発明は、請求項２に記載されるよ
うに、プロトコルの異なる複数の処理系と、顧客が利用
する複数の端末装置とに、ネットワークを介して接続さ
れ、顧客から要求に応じて要求されたサービスに係る情
報を提供する営業支援システムであって、端末装置を介
して、顧客からの要求を受け付けるサービス要求受付手
段と、前記処理系から取得した、当該顧客に関するデー
タ項目の内容を記録するためのレコード領域を管理する
顧客情報レコード管理手段と、受け付けた顧客からの要
求に応じて、前記処理系において当該顧客に対応づけて
記憶されている顧客情報のうち、当該要求に必要となる
当該顧客情報のデータ項目の内容が、前記顧客情報レコ
ード管理手段で管理されたレコード領域に存在するか否
かを確認し、当該データ項目の内容が存在しない場合
に、当該データ項目の内容を要求するデータ要求手段
と、予めデータ項目とデータ項目の内容が格納されてい
る前記処理系から当該データ項目の内容を取得するため
のデータアクセスルーチンとが対応付けられて記憶され
ている項目定義部を参照して、要求された顧客のデータ
項目に対応するアクセスルーチンを起動するアクセスル
ーチン起動手段と、起動されたアクセスルーチンから発
行された取得要求を、取得要求先である処理系と前記端
末装置との間のデータ交換に使用されるプロトコルに変
換して、当該処理系に送出する取得要求プロトコル変換
手段と、前記処理系から取得要求に基づいて返信されて
きたデータ項目の内容を、前記顧客情報レコード領域の
該当項目に記憶すると共に、前記顧客の端末装置に送出
するサービス提供手段とを有するように構成することが
できる。

【００１２】このようなシステムによれば、外部処理系
に対してサービス情報要求データが当該外部処理系で処
理可能な形式にて提供されると共に、そのサービス情報
要求データに応答して外部処理系から返送された当該外
部処理系独自の形式のサービス情報が所定の形式に変換
される。従って、この外部処理系は、特に当該営業支援
システムとの入出力関係を考慮することなく接続するこ
とができる。そして、営業支援システムは、要求に必要
となる当該顧客情報のデータ項目の内容が、顧客情報レ
コード管理手段で管理されたレコード領域に存在するか
否かを確認し、当該データ項目の内容が存在しない場合
に、当該データ項目の内容を要求するため、データ項目
の内容を要求する処理の負荷を軽減すると共に、当該外
部処理系からの最新のサービス情報を仮想的なデータベ
ースからの情報として要求元の端末装置に提供すること
ができる。

【００１３】

【発明の実施の形態】以下、本発明の実施の一形態を図
面に基づいて説明する。本発明の実施の一形態に係る営
業支援システムのハードウエア構成は、例えば、図２に
示すようになっている。この営業支援システムは、例え
ば、銀行のコールセンターに設置される。図２におい
て、この営業支援システム１００は、交換機１０１、音
声応答装置（Ｖｏｉｃｅ Ｒｅｓｐｏｎｃｅ Ｕｎｉｔ：
ＶＲＵ）１０２、オペレータ端末１０３ａ、１０３ｂ、
サーバ１０５を有している。電話器１１及びファックス
１２が公衆網４０を介して交換機１０１に接続されてい
る。交換機１０１は、電話器１１からの呼を原則的に音
声応答装置１０２に接続する。また、この交換機１０１
は、自動呼分配機能（ＡＣＤ）を備えており、所定のア
ルゴリズムに従って、外部からの呼が各オペレータ端末
１０３ａ、１０３ｂに振り分けられる。上記音声応答装
置１０２及びオペレータ端末１０３ａ、１０３ｂはサー
バ１０５に接続され、夫々、サーバ１０５内に蓄積され
た情報を利用できるようになっている。各オペレータ端
末１０３ａ、１０３ｂは、内蔵電話ユニット（ＴＡＰ
Ｉ）を有しており、各オペレータは、その内蔵電話ユニ
ットにて顧客と会話を行いながらオペレータ端末１０３
ａ、１０３ｂの操作を行うことができるようになってい
る。 この営業支援システム１００は、更に、ルータ１
１０、受付端末１１１及びサーバ１１５を有している。
コンピュータ端末（個人用コンピュータ端末、所謂キオ
スク端末等を含む）２０がインターネットなどのデータ
通信網５０を介してルータ１１０に接続されている。ル
ータ１１０を介してデータ通信網５０上の他のコンピュ
ータ端末と接続された受付端末１１１はサーバ１１５に
接続され、このサーバ１１５の情報を利用できるように
なっている。

【００１４】この営業支援システム１００は、また更
に、ゲートウエイ１２０ａ、１２０ｂ、１２０ｃを有し
ている。これらのゲートウエイ１２０ａ、１２０ｂ、１
２０ｃは、上述した各サーバ１０５、１１５と共にＬＡ
Ｎに接続されている。ゲートウエイ１２０ａ、１２０
ｂ、１２０ｃには、夫々、銀行の勘定系( ホスト) ２０
０、データウエアハウスのデータベース（Ｍ−ＣＩＦ）
３００、証券会社のホスト４００（それぞれが外部処理
系）が接続されている。営業支援システム１００内で処
理されたデータは、ゲートウエイ１２０ａ、１２０ｂ、
１２０ｃを介して上記銀行の勘定系２００、データベー
ス３００及び証券会社のホスト４００に提供される共
に、上記銀行の勘定系２００、データベース３００及び
証券会社のホスト４００からのデータは、夫々、ゲート
ウエイ１２０ａ、１２０ｂ、１２０ｃを介して当該営業
支援システム１００内に取り込まれるようになってい
る。

【００１５】また、会員（顧客）情報を格納したＣＲＭ
サーバ１２５がＬＡＮに接続され、このＣＲＭサーバ１
２４５内の情報をサーバ１０５、１１５を介して各オペ
レータ端末１０３ａ、１０３ｂ及び受付端末１１１にて
利用できるようになっている。上記のようなハードウエ
ア構成となる営業支援システム１００は、例えば、図３
に示されるような機能構成を有している。

【００１６】即ち、この営業支援システム１００は、機
能的に、上記電話器１１、ファックス１２、コンピュー
タ端末２０などのメディア１０と結合して、顧客に対す
るサービス情報の提供に係るオペレータ業務の代行や補
助を行うアプリケーション１５０、データ収集や顧客に
提供すべき情報の管理を行うデータ管理オブジェクト１
５１、外部処理系（銀行の勘定系ホスト２００、データ
ベース３００、証券会社のホスト４００）に対するアク
セス処理を行うアクセスルーチン１５２ａ、１５２ｂ、
１５２ｃ、各データ項目とそのデータを得るためのアク
セスルーチンの関係が記述された項目定義１５３、そし
て、プロトコル変換を行うゲートウエイ１２０ａ、１２
０ｂ、１２０ｃを有している。また、顧客に対して、各
種キャンペーン（年金、新規定期、ローン、証券等）情
報を提供するためのＣＲＭエージェント１５５及びキャ
ンペーンマネージャー１５６が設けられている。

【００１７】上記アプリケーション１５０、データ管理
オブジェクト１５１、アクセスルーチン１５２ａ〜１５
２ｃ、定義項目１５３、ＣＲＭエージェント１５５及び
キャンペーンマネージャー１５６は、図２に示すオペレ
ータ端末１０３ａ、１０３ｂ、サーバ１０５、１１５の
機能として構築される。上記ＣＲＭエージェント１５５
は、データ管理オブジェクト１５１と情報の交換を行
い、このデータ管理オブジェクト１５１内の最新の情報
に基づいたキャンペーン情報を生成してアプリケーショ
ン１５０に提供すようになっている。キャンペーンマネ
ージャー１５６は、ＣＲＭエージェント１５５で収集す
べきキャンペーン情報や、提供すべきメディア１０（端
末装置）等について管理するものであり、例えば、図４
に示すように構成されている。

【００１８】図４において、キャンペーンマネージャー
１５６は、モニタユニット１５６１、キャンペーンセレ
クター１５６２、チャンネルセレクター１５６３、チャ
ンネルバランサー１５６４、キャンペーンキュー１５６
５及びキャンペーンスケジューラー１５６６から構成さ
れている。モニタユニット１５６１は、キャンペーン毎
にその成約率及びチャンネル（メディア）毎の成約率を
モニターしている。このモニターの結果がキャンペーン
のスケジューリングやチャンネルの負荷調整等に用いら
れる。

【００１９】キャンペーンセレクター１５６２は、セグ
メント分析の手法等を用いてキャンペーンを勧めるべき
顧客（年齢、性別、年収等でセグメント化されている）
のポテンシャル値を演算し、そのポテンシャル値に基づ
いて顧客に勧めるべきキャンペーンを決定する。チャン
ネルセレクター１５６３は、顧客とチャンネルの相性を
スコアリングして、顧客に対する最適なチャンネルを決
定する。即ち、キャンペーン成約において顧客に効果の
在るチャンネル（電子メール、ダイレクトメール、電話
等）を決定する。スコアリングは例えば、（チャンネル
の指定事実）×重み（チャンネルの使用頻度）×重み
（マイニング結果）×重みの合計値として演算される。
ここでマイニングとは、顧客に勧めるべき商品の分析処
理をいう。

【００２０】チャンネルバランサー１５６４は、特定の
チャンネルに負荷が集中しないようにキャンペーンの実
行すべき各顧客のチャンネルを調整するものである。初
期は、チャンネル毎の単位時間の目標処理件数とスケジ
ュール件数で負荷率を算出する。そして、稼働すると、
モニタユニット１５６１からの単位時間当たりの処理能
力結果からパラメータを補正する。

【００２１】上記キャンペーンセレクター１５６２、チ
ャンネルセレクター１５６３、チャンネルバランサー１
５６４は、モニタユニット１５６１にて得られたキャン
ペーン毎やチャンネル毎の成約率に基づいてそれぞれの
決定事項の補正を行う。例えば、モニタされたチャンネ
ル毎の成約率に基づいて効果的なチャンネル（例えば、
電子メール）を過負荷気味に調整し（処理件数を補
正）、効果の低いチャンネル（例えば、ダイレクトメー
ル）は頻度を低く調整することができる。このような調
整により、キャンペーンの成約率を向上させ、効果的な
営業支援を行うことが可能となる。

【００２２】上記のような営業支援システム１００にお
いて、例えば、アプリケーション１５０が、メディア１
０（電話、コンピュータ端末装置）から聞き取った顧客
の口座番号に基づいて、その顧客の口座残高を取得する
処理は、例えば、図５乃至図７に示す手順に従って実行
される。図５において、メディア１０（例えば、コンピ
ュータ端末装置）から残高照会の要求があると、その要
求に従ってアプリケーション１５０がデータ管理オブジ
ェクト１５１にレコードのオープンを依頼する（Ｓ
１）。データ管理オブジェクト１５１は、項目定義１５
３内の項目情報に基づいてメモリ上にレコード領域の準
備を行う。項目情報は、項目の属性の他、情報の所在場
所（アクセスルーチンの識別）を示すタグを有する。次
いで、アプリケーション１５０が聞き取った口座番号が
データ管理オブジェクト１５１に収納される。そして、
データ管理オブジェクト１５１の先読みが指示される
（Ｓ４）。このように、データ管理オブジェクト１５１
の先読みが指示されると、利用者との会話と並列してホ
スト通信が行われる。（Ｓ５）。

【００２３】その後、図６に示す処理に移行し、アプリ
ケーション１５０は、残高の参照をデータ管理オブジェ
クト１５１に依頼する（Ｓ６）。データ管理オブジェク
ト１５１は、この依頼に係る残高について既にアクセス
があったか否かを判定し（Ｓ７）、まだ、そのアクセス
が無い場合には、項目定義１５３内の項目情報のタグが
示すアクセスルーチン（１５２ａ、１５２ｂまたは１５
２ｃ）を読み出す（Ｓ８）。この場合、例えば、銀行の
勘定系２００に口座残高をアクセスするためのアクセス
ルーチン１５２ａが読み出される。

【００２４】この読み出されたアクセスルーチン１５２
ａは、対応するゲートウエイ１２０ａに残高照会の要求
を行う（Ｓ９）。なお、このアクセスルーチン１５２ａ
は要求情報如何にかかわらず呼ばれれば残高照会を行
う。そして、ゲートウエイ１２０ａは、この要求データ
を既存の銀行の勘定系２００と端末装置（ＡＴＭ等）と
の間のデータ交換に採用されるプロトコルにインターフ
ェース変換する。そして、残高照会上り電文がゲートウ
エイ１２０ａから銀行の勘定系２００に送信される（Ｓ
１０）。

【００２５】その後、図７に示す処理に移行し、当該勘
定系ホスト２００は、残高照会上り電文に応答して、そ
の電文に含まれる口座番号をキーにしてその口座の残高
を検索する。そして、その結果得られた残高を含む下り
電文を設定し、その下り電文が勘定系ホスト２００から
営業支援システム１００に返信される（Ｓ１１）。この
返信された下り電文をゲートウエイ１２０ａが受信する
と、このゲートウエイ１２０ａは、受信した下り電文の
プロトコル変換を行い、アクセスルーチン１５２ａに中
継する（Ｓ１２）。アクセスルーチン１５２ａは、下り
電文から残高等の情報を抽出し、その抽出した情報をデ
ータ管理オブジェクト１５１に供給する。そして、その
情報がデータ管理オブジェクト１５１のメモリ内に格納
される（Ｓ１３）。その後、データ管理オブジェクト１
５１は、メモリ内の情報をアプリケーション１５０に引
き渡す（Ｓ１４）。残高等の情報を取得したアプリケー
ション１５０は、その要求元のメディア１０に口座残高
等に関する情報を提供する。その結果、顧客は、そのメ
ディア１０から当該顧客の口座残高を知ることができ
る。

【００２６】なお、図６に示すステップＳ７での処理に
おいて、データ管理オブジェクト１５１が残高について
は既にアクセス済みであると判定されると、処理は、図
７に示すステップＳ１４に移行し、既にアクセスされる
ことによってメモリ内に格納されている残高に関するデ
ータがデータ管理オブジェクト１５１からアプリケーシ
ョン１５０に引き渡される。

【００２７】上記のようなシステムでは、データ管理オ
ブジェクト１５１が要求に係る情報をプロトコル変換を
行うゲートウエイ１２０ａ、１２０ｂ、１２０ｃを介し
て外部処理系（銀行の勘定系２００等）から得るように
しているので、アプリケーション１５０は、あたかも、
従来のデータベース（図１参照）から情報を得るのと同
様の処理にて当該要求に係る情報を得ることができる。
そして、その情報は、外部の処理系（銀行の勘定系２０
０等）から直接得られるものであり、常に最新のものと
なる。

【００２８】また、外部の処理系（銀行の勘定系２００
等）は、ゲートウエイを用いることによって、既存の端
末装置と同様の接続関係にて当該営業支援システム１０
０と接続できるので、当該外部の処理系の設計変更を行
う必要がない。また、上記のようにサービス情報（口座
残高、キャンペーン情報等）に関する情報を顧客に提供
する処理が、前記キャンペーンマネージャー１５６にて
モニタされており、そのモニタ結果に応じて顧客が成約
しそうなキャンペーン情報が当該顧客に対して最も有効
なチャンネルを用いて提供されることになる。

【００２９】上述したような営業支援システム１００の
機能を複数のサーバに分散させることも可能である。こ
の場合、例えば、図８に示すように、複数のシステムが
ブロードチャンネルバスによって統合される。図８にお
いて、営業支援システム１００（１）乃至１００（ｎ）
が分散されて設けられ、各営業支援システム１００
（ｉ）（ｉ＝１〜ｎ）は、図３に示すものと同様に、メ
ディア１０（ｉ）に結合されたアプリケーション１５０
（ｉ）、データ管理オブジェクト１５１（ｉ）、アクセ
スルーチン１５２ａ（ｉ）〜１５２ｃ（ｉ）及び項目定
義１５３（ｉ）を有している。なお、図示していない
が、図３の例と同様に、各営業支援システム１００
（ｉ）は、ＣＲＭエージェント及びキャンペーンマネー
ジャーを有している。

【００３０】各営業支援システム１００（ｉ）のアクセ
スルーチン１５２ａ（ｉ）〜１５２ｃ（ｉ）は、並列的
にブロードチャンネルバス５００に接続され、このブロ
ードチャンネルバス５００によって各営業支援システム
１００（１）〜１００（ｎ）が統合されている。更に、
このブロードチャンネルバス５００には、銀行の勘定系
２００の間のプロトコル変換を行うゲートウエイ２１０
ａ〜２１０ｃ、データウエアハウスのデータベース３０
０との間のプロトコル変換を行うゲートウエイ３１０ａ
及び３１０ｂ、また、証券会社のホスト４００との間の
プロトコル変換を行うゲートウエイ４１０ａ及び４１０
ｂが接続されている。その結果、何れの営業支援システ
ム１００（ｉ）も、ブロードチャンネルバス５００及び
ゲートウエイを介して外部の処理系（銀行の勘定系２０
０、データベース３００、証券会社のホスト４００）と
の間でデータ交換を行うことが可能となる。

【００３１】更に、このブロードチャンネルバス５００
には、分散されたシステム全体の管理を行う統合スーパ
バイザ５１０及び当該ブロードチャンネルバス５００の
監視を行うバス監視装置５２０が接続されている。ブロ
ードチャンネルバス５００は、例えば、図９に示すよう
な機能構成となっている。即ち、分散された営業支援シ
ステムに対応して、ノードアプリケーション、通信ＡＰ
Ｉ、バスシステム、通信プロトコル、ＬＡＮプロトコル
で構成される各ユニット５００（１）〜５００（ｎ）が
構築され、各ユニット５００（１）〜５００（ｎ）がＴ
ＣＰ／ＩＰネットワーク網に接続されている。また、上
記バス監視システム５２０に対応した宛て先情報等のデ
ィレクトリを管理する監視システム５２０ａを有してい
る。この監視システム５２０ａは、バス監視装置アプリ
ケーション、通信ＡＰＩ、バスシステム、通信プロトコ
ル及びＬＡＮプロトコルによって構成され、ＴＣＰ／Ｉ
Ｐネットワーク網に接続されている。

【００３２】上記各ユニットにおけるバスシステムは、
図１０に示すような機能を有している。即ち、通信ＡＰ
Ｉが論理宛て先を付けて送受信の依頼を行うと、バスシ
ステムは、バス監視装置５２０から配信されるノードデ
ィレクトリ情報とスクリプト情報に基づいて受け取った
論理宛て先を実宛て先（通常バス内スクリプトの宛て
先）に変換する。そして、要求に係る情報をその実宛て
先に送信する。この宛て先は、スクリプトであってもよ
い。宛て先となるスクリプトによって、メッセージの加
工や新たなメッセージの生成が可能となる。

【００３３】また、上述したような営業支援システム１
００（図２及び図３参照）によって、次のような手順に
て顧客に対するサービス提供が可能となる。以下の例
は、インターネット利用者とローン契約を結ぶ場合の処
理手順である。 １）データベース（Ｍ−ＣＩＦ）３００の情報（利用チ
ャンネルの頻度、顧客の指定）をダイナミックに判定
し、例えば、インターネット利用者であれば、電子メー
ルで案内を送付する。

【００３４】２）その電子メールにＵＲＬを含めること
により、顧客の端末装置において、そのＵＲＬをクリッ
クすることにより、即座にｗｅｂ画面に移行される（Ｓ
ＥＴ認証プロトコルで残高照会を内部発行することで本
人認証が終了する）。 ３）ｗｅｂの相談希望ボタンでカスタマーリレーション
センター（コールセンタ等）に自動接続する。

【００３５】顧客との対話により、融資条件等を打ち合
わせ、契約内容を固める。最終条件は、顧客端末装置
（ＰＣ）上に送られ顧客の意思でボタンを押すことによ
って自動的に稟議申請がなされる。会話中に自動審査シ
ステムと連動し、一次審査を行う。このとき、会話録
音、及び声紋認証により本人確認の精度向上と意思確認
がとれているため法的なトラブルに対処できる。

【００３６】４）また、稟議書は自動作成され、ワーク
フローを経由して審査部門に回送される。

【００３７】５）審査部門承認により、審査の結果を電
子メールで自動送付する。

【００３８】６）実際に店頭での本人確認を行うことな
く、返済予定表、契約書を送付する。

【００３９】７）認証時点で即時融資の実行がおこなわ
れる。 上記のようにして、従来顧客が店頭に来るなどして直接
行っていたローン契約がインターネットを利用して安
全、確実に行うことが可能となる。

【００４０】

【発明の効果】以上、説明してきたように、本発明によ
れば、顧客の端末装置から上げられたサービス情報要求
データを外部処理系にて処理可能な形式に変換すると共
に、外部処理系からの応答サービス情報をシステム内で
処理できる形式に変換して、そのサービス情報を顧客に
提供するようにしたため、既存の外部処理系にて処理さ
れている最新の情報を顧客が使用する端末装置に提供で
きる。

【００４１】また、外部処理系と当該営業支援システム
が直接接続がなされることにより、端末装置と外部処理
系との間で情報交換処理を行うことができるようにな
る。

【００４２】

【図面の簡単な説明】

【図１】従来の営業支援システムの構成例を示すブロッ
ク図である。

【図２】本発明の実施の一形態に係る営業支援システム
のハードウエア構成を示すブロック図である。

【図３】本発明の実施の一形態に係る営業支援システム
の機能構成例を示すブロック図である。

【図４】キャンペーンマネージャーの詳細機能構成を示
すブロック図である。

【図５】営業支援システムにて実行される処理の手順を
示すフローチャート（その１）である。

【図６】営業支援システムにて実行される処理の手順を
示すフローチャート（その２）である。

【図７】営業支援システムにて実行される処理の手順を
示すフローチャート（その３）である。

【図８】営業支援システムの機能を分散させた場合の構
成例を示すブロック図である。

【図９】ブロードチャンネルバスの機能構成例を示すブ
ロック図である。

【図１０】バスシステムの機能を示すブロック図であ
る。

【符号の説明】

１０ メディア １１ 電話器 １２ ファックス ２０ コンピュータ端末 １００ 営業支援システム １０２ 音声応答装置 １０３ａ、１０３ オペレータ端末 １０５ サーバ １１１ 受付端末 １１５ サーバ １２０ａ、１２０ｂ、１２０ｃ ゲートウエイ １５０ アプリケーション １５１ データ管理オブジェクト １５２ａ、１５２ｂ、１５２ｃ アクセスルーチン １５５ ＣＲＭエージェント １５６ キャンペーンマネージャー ２００ 銀行の勘定系 ３００ データベース ４００ 証券会社のホスト

Claims (2)

【特許請求の範囲】
1. 【請求項１】 プロトコルの異なる複数の処理系と、顧
   客が利用する複数の端末装置とに、ネットワークを介し
   て接続され、顧客から要求に応じて要求されたサービス
   に係る情報を提供する営業支援システムであって、 端末装置を介して、顧客からの要求を受け付けるサービ
   ス要求受付手段と、 受け付けた顧客からの要求に応じて、前記処理系におい
   て当該顧客に対応づけて記憶されている顧客情報のう
   ち、当該要求に必要となる当該顧客情報のデータ項目の
   内容を要求するデータ要求手段と、 予めデータ項目とデータ項目の内容が格納されている前
   記処理系から当該データ項目の内容を取得するためのデ
   ータアクセスルーチンとが対応付けられて記憶されてい
   る項目定義部を参照して、要求された顧客のデータ項目
   に対応するアクセスルーチンを起動するアクセスルーチ
   ン起動手段と、 起動されたアクセスルーチンから発行された取得要求
   を、取得要求先である処理系と前記端末装置との間のデ
   ータ交換に使用されるプロトコルに変換して、当該処理
   系に送出する取得要求プロトコル変換手段と、 前記処理系から取得要求に基づいて返信されてきたデー
   タ項目の内容を、前記顧客の端末装置に送出するサービ
   ス提供手段とを備えた営業支援システム。
2. 【請求項２】 プロトコルの異なる複数の処理系と、顧
   客が利用する複数の端末装置とに、ネットワークを介し
   て接続され、顧客から要求に応じて要求されたサービス
   に係る情報を提供する営業支援システムであって、 端末装置を介して、顧客からの要求を受け付けるサービ
   ス要求受付手段と、 前記処理系から取得した、当該顧客に関するデータ項目
   の内容を記録するためのレコード領域を管理する顧客情
   報レコード管理手段と、 受け付けた顧客からの要求に応じて、前記処理系におい
   て当該顧客に対応づけて記憶されている顧客情報のう
   ち、当該要求に必要となる当該顧客情報のデータ項目の
   内容が、前記顧客情報レコード管理手段で管理されたレ
   コード領域に存在するか否かを確認し、当該データ項目
   の内容が存在しない場合に、当該データ項目の内容を要
   求するデータ要求手段と、 予めデータ項目とデータ項目の内容が格納されている前
   記処理系から当該データ項目の内容を取得するためのデ
   ータアクセスルーチンとが対応付けられて記憶されてい
   る項目定義部を参照して、要求された顧客のデータ項目
   に対応するアクセスルーチンを起動するアクセスルーチ
   ン起動手段と、 起動されたアクセスルーチンから発行された取得要求
   を、取得要求先である処理系と前記端末装置との間のデ
   ータ交換に使用されるプロトコルに変換して、当該処理
   系に送出する取得要求プロトコル変換手段と、 前記処理系から取得要求に基づいて返信されてきたデー
   タ項目の内容を、前記顧客情報レコード領域の該当項目
   に記憶すると共に、前記顧客の端末装置に送出するサー
   ビス提供手段とを備えた営業支援システム。