JP3996384B2 - 顧客情報管理システム - Google Patents
顧客情報管理システム Download PDFInfo
- Publication number
- JP3996384B2 JP3996384B2 JP2001370070A JP2001370070A JP3996384B2 JP 3996384 B2 JP3996384 B2 JP 3996384B2 JP 2001370070 A JP2001370070 A JP 2001370070A JP 2001370070 A JP2001370070 A JP 2001370070A JP 3996384 B2 JP3996384 B2 JP 3996384B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- customer
- daily
- business
- explanation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、証券、金融、保険業界等において、金融商品の取引における重要事項の説明を、顧客に対して確実に実施したか否かを確認でき、重要事項の説明の実施を促すことができる顧客情報管理システムに関するものである。
【０００２】
【従来の技術】
金融機関が金融商品を販売する上で、リスクに関する説明が顧客へ十分になされていないことが多々あり、トラブルの原因となっている。そのため、２００１年４月から施行された金融商品販売法により、金融機関は金融商品を販売する際に、その金融商品の特徴、リスク等の金融商品の取引における重要事項を顧客へ説明することを義務付けられている。
【０００３】
従来、金融商品毎の重要事項の説明を顧客が必要としているか否かの情報を含む顧客属性情報、及び重要事項の説明を顧客に対して実施したか否かの情報を含む営業日報情報は、例えば紙による記録や電子化されたデータベースにより管理されている。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の顧客属性情報と営業日報情報は、それぞれ独立して入力され保存されている。そのため、実際に営業員が営業日報情報を作成しながら顧客と接触する場合、顧客が購入しようとしている金融商品の重要事項の説明を必要としているのか否かの情報を営業日報情報から得ることができず、営業員は重要事項の説明を怠ってしまう場合がある。
【０００５】
本発明は上述した課題に鑑みてなされたものであり、重要事項の説明を必要とする顧客に対してもれなく説明を実施することができ、さらに重要事項の説明を顧客に対して実施したか否かを容易に確認することができる顧客情報管理システムを提供することを目的とする。
【０００６】
【課題を解決するための手段】
上述した目的を達成するために、本発明は、金融商品の取引における顧客情報を管理する顧客情報管理システムであって、前記顧客情報は、顧客に関する情報である顧客属性情報と、前記顧客との接触内容である営業日報情報を含み、前記顧客属性情報は、前記顧客が金融商品毎の重要事項の説明を必要としているか否かの情報を含み、前記営業日報情報は、前記顧客に対して前記重要事項の説明が実施されたか否かの情報を含み、前記営業日報情報の保存時に、前記顧客属性情報と前記営業日報情報を照合し、前記顧客が必要としている前記重要事項の説明が実施されていない場合に、通知を行うことを特徴とするものである。
【０００７】
このような構成によれば、顧客が必要としている重要事項の説明を実施していないことを通知することにより、営業員は、顧客に対して確実に重要事項の説明を実施することができる。
【０００８】
また、本発明に係る顧客情報管理システムにおいて、前記重要事項の説明が実施されない場合は、前記営業日報情報の保存を行わないことを特徴とするものである。
【０００９】
このような構成によれば、重要事項の説明を実施したことが入力されるまで営業日報情報の保存を行うことができないようにすることにより、営業員は、顧客に対してより確実に重要事項の説明を実施することができる。
【００１０】
また、前記顧客情報は、さらに前記顧客との前記取引に関する情報である取引情報を含み、本発明に係る顧客情報管理システムは、前記取引情報に対応する前記営業日報情報を検索し、前記営業日報情報に含まれた前記重要事項の説明が実施されたか否かの情報を表示することを特徴とすることもできる。
【００１１】
このような構成によれば、取引された商品に対して重要事項の説明が実施されたか否かを表示することにより、営業員は、顧客に対して適切な営業活動を行うことができる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して詳細に説明する。本実施の形態における顧客情報管理システムとは、顧客属性情報、取引情報、営業日報情報を関連づけて顧客情報として管理することである。ここでは証券会社を例にとり、本実施の形態における顧客情報管理システムの構成について説明する。図１は、本実施の形態における顧客情報管理システムの構成の一例を示すブロック図である。この顧客情報管理システムは、本店１００と支店２００から構成されている。本店１００には、証券会社ホスト１１０とサーバ１２０とデータベース１３０とクライアント１４０が備えられている。支店２００には、クライアント１４０Ａが備えられている。サーバ１２０には証券会社ホスト１１０とデータベース１３０が接続されている。サーバ１２０とクライアント１４０，１４０Ａ間におけるデータの送受信は、イントラネット３００を介して行われる。クライアント１４０とクライアント１４０Ａは、同様の構成を持ち同様の動作を行う。
【００１３】
なお、データベース１３０は、サーバ１２０内に備えられていても良いし、サーバ１２０とクライアント１４０は一つの構成としても良いし、クライアント１４０とクライアント１４０Ａは複数であっても良く、図１に示されるような形態に限定されるものではない。
【００１４】
次に、顧客情報管理システムの動作の概略について図１を用いて説明する。証券会社ホスト１１０は、必要に応じて顧客属性情報と取引情報をサーバ１２０へ送信する。なお、これはクライアント１４０から入力され、データベース１３０に蓄積するようにしても良い。つまり、ホスト１１０からデータ転送されるばあしに限定されることは無い。ここで、顧客属性情報とは、部店コード、顧客コード、顧客名、金融商品毎の重要事項説明の要否等からなる情報である。取引情報とは、部店コード、顧客コード、顧客名、商品区分、約定日、銘柄コード等からなる情報である。図２は本実施の形態における顧客属性情報のテーブル構造例を示す図である。サーバ１２０は、証券会社ホスト１１０から受信した顧客属性情報を、図２に示したテーブル構造に従ってデータベース１３０へ蓄積する。図３は本実施の形態における取引情報のテーブル構造例を示す図である。ここで、商品の性格上、注文を取引とみなせる商品がある。また、注文から約定（取引成立）まで時間を要する商品がある。そのため、注文に関する情報を取引情報に含める場合がある。サーバ１２０は、証券会社ホスト１１０から受信した取引情報を、図３に示したテーブル構造に従ってデータベース１３０へ蓄積する。
【００１５】
営業員は、作成した営業日報情報をクライアント１４０，１４０Ａからサーバ１２０へ送信する。ここで、営業日報情報とは、部店コード、顧客コード、顧客名、接触日時、提案商品、金融商品毎の重要事項説明の実施状況等からなる情報である。図４は本実施の形態における営業日報情報のテーブル構造例を示す図である。サーバ１２０は、クライアント１４０，１４０Ａから受信した営業日報情報を、図４に示したテーブル構造に従ってデータベース１３０へ蓄積する。
【００１６】
また、営業員は、クライアント１４０，１４０Ａからサーバ１２０へアクセスする。サーバ１２０は、クライアント１４０，１４０Ａからのアクセスに応じて、データベース１３０に蓄積されている顧客属性情報や取引情報や営業日報情報をクライアント１４０，１４０Ａへ送信する。
【００１７】
クライアント１４０，１４０Ａは、営業日報作成画面と、取引リスク説明確認画面と、顧客カード参照画面と、管理者用取引確認画面と、営業員用取引確認画面等の表示を行うとともに、営業員の入力を受け付ける。営業日報作成画面と、取引リスク説明確認画面と、顧客カード参照画面と、管理者用取引確認画面と、営業員用取引確認画面については、後述する図６乃至図１０において詳細に説明する。
【００１８】
次に、顧客情報管理システムの動作の詳細について説明する。まず、営業日報情報の入力及び保存に関する動作について図５のフローチャートと図６の画面例を用いて説明する。ここでは、本社１００の営業員がクライアント１４０に表示される画面の閲覧及びクライアント１４０を用いた入力を行いながら、電話または対面により顧客と接触している場合を想定して説明を行う。なお、支社２００の営業員であっても、クライアント１４０Ａを用いて同様の動作を行うことが可能である。
【００１９】
予め、営業員はクライアント１４０を用いてサーバ１２０へアクセスし、データベース１３０に蓄積されている顧客属性情報に対して重要事項説明の要否を入力する（Ｓ１）。顧客は事前に金融商品毎の重要事項の説明が必要か否かの選択を行っており、営業員は選択された結果に基づいて重要事項説明の要否を入力する。
【００２０】
顧客との接触時に、営業員はクライアント１４０を用いて営業日報作成画面のウィンドウを開く（Ｓ２）。図６は本実施の形態における営業日報作成画面の一例を示す図である。この営業日報作成画面は、検索条件入力エリアと顧客属性情報表示エリアと営業日報情報入力エリアから構成される。
【００２１】
まず、営業員は検索条件入力エリアへ例えば顧客コードを入力し、「顧客検索ボタン」１を押下する。クライアント１４０は、顧客コードをサーバ１２０へ送信する。顧客コードを受信したサーバ１２０は、データベース１３０から顧客コードに対応した顧客属性情報を検索し、クライアント１４０へ送信する。クライアント１４０は、受信した顧客属性情報を、顧客属性情報表示エリアへ表示させる。
【００２２】
次に、営業員は、顧客との接触に応じた営業日報情報を営業日報情報入力エリアへ入力する（Ｓ３）。営業員は、全ての営業日報情報を営業日報情報入力エリアへ入力し、「日報保存ボタン」２を押下する（Ｓ４）。この時、クライアント１４０は、営業日報情報入力エリアの「提案商品チェック欄」にチェックされた提案商品に対応する顧客属性情報表示エリアの「重要事項説明不要チェック欄」のチェックと、営業日報情報入力エリアの「重要事項説明実施チェック欄」のチェックとの照合結果が正しいか否かの判断を行う（Ｓ５）。
【００２３】
例えば、営業員が顧客に対して国内債の商品を提案した場合、営業員は営業日報情報入力エリアの「提案商品チェック欄」の国内債にチェックを入れる。このとき、顧客属性情報表示エリアの「重要事項説明不要チェック欄」において国内株と外国株にチェックが入っているとする。これはチェックが入っている国内株と外国株以外の商品に対して、顧客が重要事項の説明を必要としていることを示す。提案された国内債に関して顧客は重要事項の説明を必要としているため、営業員は国内債に関する重要事項の説明を行い、営業日報情報入力エリアの「重要事項説明実施チェック欄」の国内債にチェックを入れなければならない。
【００２４】
照合結果が正しくない場合（Ｓ５，Ｎ）、例えば「提案商品チェック欄」の国内債にチェックがあり、かつ「重要事項説明不要チェック欄」の国内債にチェックがないにもかかわらず、「重要事項説明実施チェック欄」の国内債にチェックがない場合、クライアント１４０は「商品：国内債について、重要事項の説明が行われていません」等のポップアップメッセージの表示を行い（Ｓ６）、処理Ｓ７へ移行する。
【００２５】
一方、照合結果が正しい場合（Ｓ５，Ｙ）、例えば「提案商品チェック欄」の国内債にチェックがあり、かつ「重要事項説明不要チェック欄」の国内債にチェックがなく、「重要事項説明実施チェック欄」の国内債にチェックがある場合、処理Ｓ７へ移行する。
【００２６】
次に、クライアント１４０は営業日報情報の保存を行い（Ｓ７）、このフローを終了する。クライアント１４０は営業員により作成された営業日報情報をサーバ１２０へ送信する。営業日報情報を受信したサーバ１２０は、データベース１３０に営業日報情報の登録を行う。
【００２７】
ここではポップアップメッセージを表示して営業日報情報の保存を行うとしたが、「重要事項説明実施チェック欄」にチェックが入るまでは営業日報情報の保存を行うことができないようにしても良い。「重要事項説明実施チェック欄」にチェックが入らなくても営業日報情報の保存を行うことができるか否かは、設定を更新することにより制御される。また、ここではポップアップメッセージを表示するとしたが、ログファイルを作成するようにしても良い。以上が、営業日報情報の入力及び保存に関する動作である。
【００２８】
次に、取引情報と営業日報情報のチェックのための表示について図７と図８の画面例を用いて説明する。まず、営業員はクライアント１４０を用いて取引リスク確認画面のウィンドウを開く。図７は本実施の形態における取引リスク確認画面の一例を示す図である。この取引リスク確認画面は、検索条件入力エリアと検索結果表示エリアから構成される。次に、営業員は確認したい情報に関する顧客コード、取引年月日、取引商品、売買区分等の検索条件を、検索条件入力エリアへを入力し、「検索ボタン」１１を押下する。クライアント１４０は、検索条件をサーバ１２０へ送信する。
【００２９】
検索条件を受信したサーバ１２０は、データベース１３０から検索条件に対応した取引情報、及びその取引情報の商品区分に予め設定されたリスク説明事項の要否を検索し、クライアント１４０へ送信する。ここで、リスク説明事項とは、重要事項の内容として説明すべきリスクの種類であり、例えば価格変動リスク、信用リスク、為替リスク、期間の制限リスクの４項目からなり、商品区分に応じて説明を必要とする項目が異なる。例えば株式という商品区分においては、価格変動リスク、信用リスクの２項目のリスク説明事項が必要と設定されている。クライアント１４０は、検索結果の一覧を検索結果表示エリアへ表示させる。
【００３０】
次に、営業員は、検索結果表示エリアに表示されている検索結果の一覧の中から、取引情報と営業日報情報の確認をしたい顧客を選択し、その顧客に対応する「表示希望ボタン」１２を押下する。クライアント１４０は、選択された顧客の顧客コードをサーバ１２０へ送信する。顧客コードを受信したサーバ１２０は、データベース１３０から顧客コードに対応した取引情報とその取引情報に関連する営業日報情報を検索し、クライアント１４０へ送信する。
【００３１】
次に、クライアント１４０は、受信した取引情報の一覧と営業日報情報の一覧を、顧客カード参照画面のウィンドウを開いて表示する。図８は本実施の形態における顧客カード参照画面の一例を示す図である。この顧客カード参照画面は、営業日報情報表示エリアと取引情報表示エリアから構成される。営業日報情報表示エリアには、選択された顧客に関する営業日報情報の一覧として、主に商品区分とその商品区分に対する説明方法が表示される。ここで、説明方法とは、重要事項の説明をどのように実施したかを示すものである。図８に示す例では、訪問（自宅）により株式に関する重要事項の説明を実施したことを示す○が表示されている。取引情報表示エリアには、選択された顧客に関する取引情報の一覧が表示される。この顧客カード参照画面を閲覧することにより、営業員は取引された商品に対して重要事項の説明が実施されたか否かを確認することができる。
【００３２】
次に、取引情報と営業日報情報の厳密なチェックのための表示について図９と図１０の画面例を用いて説明する。まず、営業員が取引情報と営業日報情報の厳密なチェックを行う場合について説明する。営業員はクライアント１４０を用いて営業員用確認画面のウィンドウを開く。図９は本実施の形態における営業員用確認画面の一例を示す図である。この営業員用確認画面は、検索条件入力エリアと検索結果表示エリアから構成される。次に、営業員は検索条件入力エリアへ日付等の検索条件を入力し、「検索ボタン」２１を押下する。クライアント１４０は、検索条件をサーバ１２０へ送信する。検索条件を受信したサーバ１２０は、データベース１３０から検索条件に対応した取引情報と営業日報情報から予め定義された確認項目を抽出し、クライアント１４０へ送信する。次に、クライアント１４０は、受信した確認項目を検索結果表示エリアへ表示する。営業員は、検索結果表示エリアに表示された確認項目についてチェックを行う。
【００３３】
図９の例では、取引情報の日付と顧客カードの作成状況を検索条件としている。また、顧客カードの作成不要理由を、検索結果表示エリアへ表示する確認項目としている。具体的に、目論見書の作成不要理由には、「不要申し入れあり」、「既に作成済み」、「取引経験有り、了承済み」、「未選択」等の種類がある。ここで、予め定義された確認項目は他の項目であってもよい。
【００３４】
次に、管理者が取引情報と営業日報情報の厳密なチェックを行う場合について説明する。管理者はクライアント１４０を用いて管理者用確認画面のウィンドウを開く。図１０は本実施の形態における管理者用確認画面の一例を示す図である。この管理者用確認画面は、検索条件入力エリアと検索結果表示エリアから構成される。次に、管理者は検索条件入力エリアへ日付等の検索条件を入力し、「検索ボタン」３１を押下する。クライアント１４０は、検索条件をサーバ１２０へ送信する。検索条件を受信したサーバ１２０は、データベース１３０から検索条件に対応した取引情報と営業日報情報から予め定義された確認項目を抽出し、クライアント１４０へ送信する。次に、クライアント１４０は、受信した確認項目を検索結果表示エリアへ表示する。管理者は、検索結果表示エリアに表示された確認項目についてチェックを行う。
【００３５】
図１０の例では、取引情報の日付とチェック状況を検索条件としている。また、確認書のチェックと目論見書のチェックを、検索結果表示エリアへ表示する確認項目としている。すなわち、管理者は、検索結果表示エリアに表示された確認書のチェックと目論見書のチェックを行う。ここで、予め定義された確認項目は他の項目であってもよい。
【００３６】
以上に詳述したように本実施の形態によれば、同一画面に顧客属性情報と営業日報情報が表示されるとともに、顧客が必要としている重要事項の説明が実施されていない場合は重要事項の説明の実施を促すポップアップメッセージ等が表示されることより、営業員は顧客に対して確実に重要事項の説明を実施することができる。また、同一画面に取引情報と営業日報情報が表示されることにより、営業員は取引された商品に対して重要事項の説明が実施されたか否かを確認し、顧客に対して適切な営業活動を行うことができる。また、取引情報と営業日報情報に関する確認項目を抽出し、営業員と管理者はその確認項目のチェックを行うことにより、顧客に対して適切な営業活動を行うことができる。
【００３７】
【発明の効果】
以上に詳述したように本発明によれば、重要事項の説明を必要とする顧客に対してもれなく説明を実施することができ、さらに重要事項の説明を顧客に対して実施したか否かを容易に確認することができる顧客情報管理システムを提供することができるという効果を奏する。
【図面の簡単な説明】
【図１】本実施の形態における顧客情報管理システムの構成の一例を示すブロック図である。
【図２】本実施の形態における顧客属性情報のテーブル構造例を示す図である。
【図３】本実施の形態における取引情報のテーブル構造例を示す図である。
【図４】本実施の形態における営業日報情報のテーブル構造例を示す図である。
【図５】本実施の形態における営業日報情報の入力及び保存に関する動作の一例を示すフローチャートである。
【図６】本実施の形態における営業日報作成画面の一例を示す図である。
【図７】本実施の形態における取引リスク確認画面の一例を示す図である。
【図８】本実施の形態における顧客カード参照画面の一例を示す図である。
【図９】本実施の形態における営業員用確認画面の一例を示す図である。
【図１０】本実施の形態における管理者用確認画面の一例を示す図である。
【符号の説明】
１００ 本店、１１０ 証券会社ホスト、１２０ サーバ、１３０ データベース、１４０，１４０Ａ クライアント、２００ 支店、３００ イントラネット。
【発明の属する技術分野】
本発明は、証券、金融、保険業界等において、金融商品の取引における重要事項の説明を、顧客に対して確実に実施したか否かを確認でき、重要事項の説明の実施を促すことができる顧客情報管理システムに関するものである。
【０００２】
【従来の技術】
金融機関が金融商品を販売する上で、リスクに関する説明が顧客へ十分になされていないことが多々あり、トラブルの原因となっている。そのため、２００１年４月から施行された金融商品販売法により、金融機関は金融商品を販売する際に、その金融商品の特徴、リスク等の金融商品の取引における重要事項を顧客へ説明することを義務付けられている。
【０００３】
従来、金融商品毎の重要事項の説明を顧客が必要としているか否かの情報を含む顧客属性情報、及び重要事項の説明を顧客に対して実施したか否かの情報を含む営業日報情報は、例えば紙による記録や電子化されたデータベースにより管理されている。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の顧客属性情報と営業日報情報は、それぞれ独立して入力され保存されている。そのため、実際に営業員が営業日報情報を作成しながら顧客と接触する場合、顧客が購入しようとしている金融商品の重要事項の説明を必要としているのか否かの情報を営業日報情報から得ることができず、営業員は重要事項の説明を怠ってしまう場合がある。
【０００５】
本発明は上述した課題に鑑みてなされたものであり、重要事項の説明を必要とする顧客に対してもれなく説明を実施することができ、さらに重要事項の説明を顧客に対して実施したか否かを容易に確認することができる顧客情報管理システムを提供することを目的とする。
【０００６】
【課題を解決するための手段】
上述した目的を達成するために、本発明は、金融商品の取引における顧客情報を管理する顧客情報管理システムであって、前記顧客情報は、顧客に関する情報である顧客属性情報と、前記顧客との接触内容である営業日報情報を含み、前記顧客属性情報は、前記顧客が金融商品毎の重要事項の説明を必要としているか否かの情報を含み、前記営業日報情報は、前記顧客に対して前記重要事項の説明が実施されたか否かの情報を含み、前記営業日報情報の保存時に、前記顧客属性情報と前記営業日報情報を照合し、前記顧客が必要としている前記重要事項の説明が実施されていない場合に、通知を行うことを特徴とするものである。
【０００７】
このような構成によれば、顧客が必要としている重要事項の説明を実施していないことを通知することにより、営業員は、顧客に対して確実に重要事項の説明を実施することができる。
【０００８】
また、本発明に係る顧客情報管理システムにおいて、前記重要事項の説明が実施されない場合は、前記営業日報情報の保存を行わないことを特徴とするものである。
【０００９】
このような構成によれば、重要事項の説明を実施したことが入力されるまで営業日報情報の保存を行うことができないようにすることにより、営業員は、顧客に対してより確実に重要事項の説明を実施することができる。
【００１０】
また、前記顧客情報は、さらに前記顧客との前記取引に関する情報である取引情報を含み、本発明に係る顧客情報管理システムは、前記取引情報に対応する前記営業日報情報を検索し、前記営業日報情報に含まれた前記重要事項の説明が実施されたか否かの情報を表示することを特徴とすることもできる。
【００１１】
このような構成によれば、取引された商品に対して重要事項の説明が実施されたか否かを表示することにより、営業員は、顧客に対して適切な営業活動を行うことができる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して詳細に説明する。本実施の形態における顧客情報管理システムとは、顧客属性情報、取引情報、営業日報情報を関連づけて顧客情報として管理することである。ここでは証券会社を例にとり、本実施の形態における顧客情報管理システムの構成について説明する。図１は、本実施の形態における顧客情報管理システムの構成の一例を示すブロック図である。この顧客情報管理システムは、本店１００と支店２００から構成されている。本店１００には、証券会社ホスト１１０とサーバ１２０とデータベース１３０とクライアント１４０が備えられている。支店２００には、クライアント１４０Ａが備えられている。サーバ１２０には証券会社ホスト１１０とデータベース１３０が接続されている。サーバ１２０とクライアント１４０，１４０Ａ間におけるデータの送受信は、イントラネット３００を介して行われる。クライアント１４０とクライアント１４０Ａは、同様の構成を持ち同様の動作を行う。
【００１３】
なお、データベース１３０は、サーバ１２０内に備えられていても良いし、サーバ１２０とクライアント１４０は一つの構成としても良いし、クライアント１４０とクライアント１４０Ａは複数であっても良く、図１に示されるような形態に限定されるものではない。
【００１４】
次に、顧客情報管理システムの動作の概略について図１を用いて説明する。証券会社ホスト１１０は、必要に応じて顧客属性情報と取引情報をサーバ１２０へ送信する。なお、これはクライアント１４０から入力され、データベース１３０に蓄積するようにしても良い。つまり、ホスト１１０からデータ転送されるばあしに限定されることは無い。ここで、顧客属性情報とは、部店コード、顧客コード、顧客名、金融商品毎の重要事項説明の要否等からなる情報である。取引情報とは、部店コード、顧客コード、顧客名、商品区分、約定日、銘柄コード等からなる情報である。図２は本実施の形態における顧客属性情報のテーブル構造例を示す図である。サーバ１２０は、証券会社ホスト１１０から受信した顧客属性情報を、図２に示したテーブル構造に従ってデータベース１３０へ蓄積する。図３は本実施の形態における取引情報のテーブル構造例を示す図である。ここで、商品の性格上、注文を取引とみなせる商品がある。また、注文から約定（取引成立）まで時間を要する商品がある。そのため、注文に関する情報を取引情報に含める場合がある。サーバ１２０は、証券会社ホスト１１０から受信した取引情報を、図３に示したテーブル構造に従ってデータベース１３０へ蓄積する。
【００１５】
営業員は、作成した営業日報情報をクライアント１４０，１４０Ａからサーバ１２０へ送信する。ここで、営業日報情報とは、部店コード、顧客コード、顧客名、接触日時、提案商品、金融商品毎の重要事項説明の実施状況等からなる情報である。図４は本実施の形態における営業日報情報のテーブル構造例を示す図である。サーバ１２０は、クライアント１４０，１４０Ａから受信した営業日報情報を、図４に示したテーブル構造に従ってデータベース１３０へ蓄積する。
【００１６】
また、営業員は、クライアント１４０，１４０Ａからサーバ１２０へアクセスする。サーバ１２０は、クライアント１４０，１４０Ａからのアクセスに応じて、データベース１３０に蓄積されている顧客属性情報や取引情報や営業日報情報をクライアント１４０，１４０Ａへ送信する。
【００１７】
クライアント１４０，１４０Ａは、営業日報作成画面と、取引リスク説明確認画面と、顧客カード参照画面と、管理者用取引確認画面と、営業員用取引確認画面等の表示を行うとともに、営業員の入力を受け付ける。営業日報作成画面と、取引リスク説明確認画面と、顧客カード参照画面と、管理者用取引確認画面と、営業員用取引確認画面については、後述する図６乃至図１０において詳細に説明する。
【００１８】
次に、顧客情報管理システムの動作の詳細について説明する。まず、営業日報情報の入力及び保存に関する動作について図５のフローチャートと図６の画面例を用いて説明する。ここでは、本社１００の営業員がクライアント１４０に表示される画面の閲覧及びクライアント１４０を用いた入力を行いながら、電話または対面により顧客と接触している場合を想定して説明を行う。なお、支社２００の営業員であっても、クライアント１４０Ａを用いて同様の動作を行うことが可能である。
【００１９】
予め、営業員はクライアント１４０を用いてサーバ１２０へアクセスし、データベース１３０に蓄積されている顧客属性情報に対して重要事項説明の要否を入力する（Ｓ１）。顧客は事前に金融商品毎の重要事項の説明が必要か否かの選択を行っており、営業員は選択された結果に基づいて重要事項説明の要否を入力する。
【００２０】
顧客との接触時に、営業員はクライアント１４０を用いて営業日報作成画面のウィンドウを開く（Ｓ２）。図６は本実施の形態における営業日報作成画面の一例を示す図である。この営業日報作成画面は、検索条件入力エリアと顧客属性情報表示エリアと営業日報情報入力エリアから構成される。
【００２１】
まず、営業員は検索条件入力エリアへ例えば顧客コードを入力し、「顧客検索ボタン」１を押下する。クライアント１４０は、顧客コードをサーバ１２０へ送信する。顧客コードを受信したサーバ１２０は、データベース１３０から顧客コードに対応した顧客属性情報を検索し、クライアント１４０へ送信する。クライアント１４０は、受信した顧客属性情報を、顧客属性情報表示エリアへ表示させる。
【００２２】
次に、営業員は、顧客との接触に応じた営業日報情報を営業日報情報入力エリアへ入力する（Ｓ３）。営業員は、全ての営業日報情報を営業日報情報入力エリアへ入力し、「日報保存ボタン」２を押下する（Ｓ４）。この時、クライアント１４０は、営業日報情報入力エリアの「提案商品チェック欄」にチェックされた提案商品に対応する顧客属性情報表示エリアの「重要事項説明不要チェック欄」のチェックと、営業日報情報入力エリアの「重要事項説明実施チェック欄」のチェックとの照合結果が正しいか否かの判断を行う（Ｓ５）。
【００２３】
例えば、営業員が顧客に対して国内債の商品を提案した場合、営業員は営業日報情報入力エリアの「提案商品チェック欄」の国内債にチェックを入れる。このとき、顧客属性情報表示エリアの「重要事項説明不要チェック欄」において国内株と外国株にチェックが入っているとする。これはチェックが入っている国内株と外国株以外の商品に対して、顧客が重要事項の説明を必要としていることを示す。提案された国内債に関して顧客は重要事項の説明を必要としているため、営業員は国内債に関する重要事項の説明を行い、営業日報情報入力エリアの「重要事項説明実施チェック欄」の国内債にチェックを入れなければならない。
【００２４】
照合結果が正しくない場合（Ｓ５，Ｎ）、例えば「提案商品チェック欄」の国内債にチェックがあり、かつ「重要事項説明不要チェック欄」の国内債にチェックがないにもかかわらず、「重要事項説明実施チェック欄」の国内債にチェックがない場合、クライアント１４０は「商品：国内債について、重要事項の説明が行われていません」等のポップアップメッセージの表示を行い（Ｓ６）、処理Ｓ７へ移行する。
【００２５】
一方、照合結果が正しい場合（Ｓ５，Ｙ）、例えば「提案商品チェック欄」の国内債にチェックがあり、かつ「重要事項説明不要チェック欄」の国内債にチェックがなく、「重要事項説明実施チェック欄」の国内債にチェックがある場合、処理Ｓ７へ移行する。
【００２６】
次に、クライアント１４０は営業日報情報の保存を行い（Ｓ７）、このフローを終了する。クライアント１４０は営業員により作成された営業日報情報をサーバ１２０へ送信する。営業日報情報を受信したサーバ１２０は、データベース１３０に営業日報情報の登録を行う。
【００２７】
ここではポップアップメッセージを表示して営業日報情報の保存を行うとしたが、「重要事項説明実施チェック欄」にチェックが入るまでは営業日報情報の保存を行うことができないようにしても良い。「重要事項説明実施チェック欄」にチェックが入らなくても営業日報情報の保存を行うことができるか否かは、設定を更新することにより制御される。また、ここではポップアップメッセージを表示するとしたが、ログファイルを作成するようにしても良い。以上が、営業日報情報の入力及び保存に関する動作である。
【００２８】
次に、取引情報と営業日報情報のチェックのための表示について図７と図８の画面例を用いて説明する。まず、営業員はクライアント１４０を用いて取引リスク確認画面のウィンドウを開く。図７は本実施の形態における取引リスク確認画面の一例を示す図である。この取引リスク確認画面は、検索条件入力エリアと検索結果表示エリアから構成される。次に、営業員は確認したい情報に関する顧客コード、取引年月日、取引商品、売買区分等の検索条件を、検索条件入力エリアへを入力し、「検索ボタン」１１を押下する。クライアント１４０は、検索条件をサーバ１２０へ送信する。
【００２９】
検索条件を受信したサーバ１２０は、データベース１３０から検索条件に対応した取引情報、及びその取引情報の商品区分に予め設定されたリスク説明事項の要否を検索し、クライアント１４０へ送信する。ここで、リスク説明事項とは、重要事項の内容として説明すべきリスクの種類であり、例えば価格変動リスク、信用リスク、為替リスク、期間の制限リスクの４項目からなり、商品区分に応じて説明を必要とする項目が異なる。例えば株式という商品区分においては、価格変動リスク、信用リスクの２項目のリスク説明事項が必要と設定されている。クライアント１４０は、検索結果の一覧を検索結果表示エリアへ表示させる。
【００３０】
次に、営業員は、検索結果表示エリアに表示されている検索結果の一覧の中から、取引情報と営業日報情報の確認をしたい顧客を選択し、その顧客に対応する「表示希望ボタン」１２を押下する。クライアント１４０は、選択された顧客の顧客コードをサーバ１２０へ送信する。顧客コードを受信したサーバ１２０は、データベース１３０から顧客コードに対応した取引情報とその取引情報に関連する営業日報情報を検索し、クライアント１４０へ送信する。
【００３１】
次に、クライアント１４０は、受信した取引情報の一覧と営業日報情報の一覧を、顧客カード参照画面のウィンドウを開いて表示する。図８は本実施の形態における顧客カード参照画面の一例を示す図である。この顧客カード参照画面は、営業日報情報表示エリアと取引情報表示エリアから構成される。営業日報情報表示エリアには、選択された顧客に関する営業日報情報の一覧として、主に商品区分とその商品区分に対する説明方法が表示される。ここで、説明方法とは、重要事項の説明をどのように実施したかを示すものである。図８に示す例では、訪問（自宅）により株式に関する重要事項の説明を実施したことを示す○が表示されている。取引情報表示エリアには、選択された顧客に関する取引情報の一覧が表示される。この顧客カード参照画面を閲覧することにより、営業員は取引された商品に対して重要事項の説明が実施されたか否かを確認することができる。
【００３２】
次に、取引情報と営業日報情報の厳密なチェックのための表示について図９と図１０の画面例を用いて説明する。まず、営業員が取引情報と営業日報情報の厳密なチェックを行う場合について説明する。営業員はクライアント１４０を用いて営業員用確認画面のウィンドウを開く。図９は本実施の形態における営業員用確認画面の一例を示す図である。この営業員用確認画面は、検索条件入力エリアと検索結果表示エリアから構成される。次に、営業員は検索条件入力エリアへ日付等の検索条件を入力し、「検索ボタン」２１を押下する。クライアント１４０は、検索条件をサーバ１２０へ送信する。検索条件を受信したサーバ１２０は、データベース１３０から検索条件に対応した取引情報と営業日報情報から予め定義された確認項目を抽出し、クライアント１４０へ送信する。次に、クライアント１４０は、受信した確認項目を検索結果表示エリアへ表示する。営業員は、検索結果表示エリアに表示された確認項目についてチェックを行う。
【００３３】
図９の例では、取引情報の日付と顧客カードの作成状況を検索条件としている。また、顧客カードの作成不要理由を、検索結果表示エリアへ表示する確認項目としている。具体的に、目論見書の作成不要理由には、「不要申し入れあり」、「既に作成済み」、「取引経験有り、了承済み」、「未選択」等の種類がある。ここで、予め定義された確認項目は他の項目であってもよい。
【００３４】
次に、管理者が取引情報と営業日報情報の厳密なチェックを行う場合について説明する。管理者はクライアント１４０を用いて管理者用確認画面のウィンドウを開く。図１０は本実施の形態における管理者用確認画面の一例を示す図である。この管理者用確認画面は、検索条件入力エリアと検索結果表示エリアから構成される。次に、管理者は検索条件入力エリアへ日付等の検索条件を入力し、「検索ボタン」３１を押下する。クライアント１４０は、検索条件をサーバ１２０へ送信する。検索条件を受信したサーバ１２０は、データベース１３０から検索条件に対応した取引情報と営業日報情報から予め定義された確認項目を抽出し、クライアント１４０へ送信する。次に、クライアント１４０は、受信した確認項目を検索結果表示エリアへ表示する。管理者は、検索結果表示エリアに表示された確認項目についてチェックを行う。
【００３５】
図１０の例では、取引情報の日付とチェック状況を検索条件としている。また、確認書のチェックと目論見書のチェックを、検索結果表示エリアへ表示する確認項目としている。すなわち、管理者は、検索結果表示エリアに表示された確認書のチェックと目論見書のチェックを行う。ここで、予め定義された確認項目は他の項目であってもよい。
【００３６】
以上に詳述したように本実施の形態によれば、同一画面に顧客属性情報と営業日報情報が表示されるとともに、顧客が必要としている重要事項の説明が実施されていない場合は重要事項の説明の実施を促すポップアップメッセージ等が表示されることより、営業員は顧客に対して確実に重要事項の説明を実施することができる。また、同一画面に取引情報と営業日報情報が表示されることにより、営業員は取引された商品に対して重要事項の説明が実施されたか否かを確認し、顧客に対して適切な営業活動を行うことができる。また、取引情報と営業日報情報に関する確認項目を抽出し、営業員と管理者はその確認項目のチェックを行うことにより、顧客に対して適切な営業活動を行うことができる。
【００３７】
【発明の効果】
以上に詳述したように本発明によれば、重要事項の説明を必要とする顧客に対してもれなく説明を実施することができ、さらに重要事項の説明を顧客に対して実施したか否かを容易に確認することができる顧客情報管理システムを提供することができるという効果を奏する。
【図面の簡単な説明】
【図１】本実施の形態における顧客情報管理システムの構成の一例を示すブロック図である。
【図２】本実施の形態における顧客属性情報のテーブル構造例を示す図である。
【図３】本実施の形態における取引情報のテーブル構造例を示す図である。
【図４】本実施の形態における営業日報情報のテーブル構造例を示す図である。
【図５】本実施の形態における営業日報情報の入力及び保存に関する動作の一例を示すフローチャートである。
【図６】本実施の形態における営業日報作成画面の一例を示す図である。
【図７】本実施の形態における取引リスク確認画面の一例を示す図である。
【図８】本実施の形態における顧客カード参照画面の一例を示す図である。
【図９】本実施の形態における営業員用確認画面の一例を示す図である。
【図１０】本実施の形態における管理者用確認画面の一例を示す図である。
【符号の説明】
１００ 本店、１１０ 証券会社ホスト、１２０ サーバ、１３０ データベース、１４０，１４０Ａ クライアント、２００ 支店、３００ イントラネット。
Claims (3)
- データベースに接続されたサーバにクライアント装置を接続した金融商品の取引における顧客情報を管理する顧客情報管理システムであって、
前記データベースは、顧客コード、顧客名、金融商品毎の重要事項説明の要否に関する情報を含む顧客属性情報と、顧客コード、顧客名、金融商品毎の重要事項説明の実施状況に関する情報を含む営業日報情報を、それぞれ顧客属性情報テーブル、営業日報情報テーブルとして蓄積し、前記クライアント装置は、クライアント装置で作成した顧客属性情報と営業日報情報を前記サーバに送信して、前記データベースにそれぞれ顧客属性情報テーブル、営業日報情報テーブルとして蓄積するとともに、前記サーバにアクセスして前記データベースの顧客属性情報テーブル、営業日報情報テーブルに蓄積されている顧客属性情報と営業日報情報を受信できるものであり、
前記クライアント装置において営業日報を作成する際に、該クライアント装置に営業日報作成画面が表示され、営業日報情報が入力された後、日報保存ボタンが押下されると、該クライアント装置が、顧客属性情報に含まれる金融商品毎の重要事項説明の要否に関する情報と、営業日報情報に含まれる金融商品毎の重要事項説明の実施状況に関する情報の照合を行い、照合結果が正しくない場合に、重要事項の説明が行われていない旨の表示を行うようにした顧客情報管理システム。 - 請求項１に記載の顧客情報管理システムにおいて、
前記照合結果が正しくない場合は、前記営業日報情報の保存を行わないようにした顧客情報管理システム。 - 請求項１又は請求項２に記載の顧客情報管理システムにおいて、
クライアント装置において営業日報を作成する際に表示される前記営業日報作成画面が、顧客属性情報表示エリアと営業日報情報表示エリアを有し、特定の顧客が指定され検索されると、前記顧客属性情報表示エリアに、該特定の顧客についての金融商品毎の重要事項説明の要否に関する情報を含む顧客属性情報が表示され、該顧客属性情報が表示された状態で、営業日報情報表示エリアに、該特定の顧客についての金融商品毎の重要事項説明の実施状況に関する情報を含む営業日報情報入力画面が表示されて営業日報情報が入力され、顧客属性情報に含まれる金融商品毎の重要事項説明の要否に関する情報と、営業日報情報に含まれる金融商品毎の重要事項説明の実施状況に関する情報の照合が行われるようにした顧客情報管理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001370070A JP3996384B2 (ja) | 2001-12-04 | 2001-12-04 | 顧客情報管理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001370070A JP3996384B2 (ja) | 2001-12-04 | 2001-12-04 | 顧客情報管理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003167997A JP2003167997A (ja) | 2003-06-13 |
| JP3996384B2 true JP3996384B2 (ja) | 2007-10-24 |
Family
ID=19179358
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001370070A Expired - Fee Related JP3996384B2 (ja) | 2001-12-04 | 2001-12-04 | 顧客情報管理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3996384B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4731751B2 (ja) * | 2001-07-19 | 2011-07-27 | 株式会社日立国際電気 | 金融機関営業支援システム、金融機関営業支援用サーバ |
| JP5475226B2 (ja) * | 2007-11-27 | 2014-04-16 | 株式会社三井住友銀行 | 渉外営業支援システム及びその方法 |
| JP5323430B2 (ja) * | 2008-09-22 | 2013-10-23 | 沖電気工業株式会社 | 窓口端末 |
| CN106982197A (zh) | 2016-01-19 | 2017-07-25 | 阿里巴巴集团控股有限公司 | 业务处理方法和装置 |
| JP7421179B2 (ja) | 2020-05-12 | 2024-01-24 | 学校法人 芝浦工業大学 | 情報処理装置、情報処理システム、および情報処理方法 |
-
2001
- 2001-12-04 JP JP2001370070A patent/JP3996384B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003167997A (ja) | 2003-06-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8407100B2 (en) | Machine, methods, and program product for electronic order entry | |
| US20040143516A1 (en) | System for allowing vendors to manage product information in a database system | |
| JP2002041842A (ja) | 商品売買のための電子的仲介サービスおよび価格決定 | |
| US7575154B2 (en) | System and method for issuing and managing a plurality of credit card accounts | |
| JP3977989B2 (ja) | 販売価格決定方法及び装置及び販売価格決定プログラムを格納した記憶媒体 | |
| JP3996384B2 (ja) | 顧客情報管理システム | |
| JP6916701B2 (ja) | 営業支援システム | |
| JP2022019974A (ja) | 顧客抽出システム、顧客抽出装置、顧客抽出方法、及びコンピュータプログラム | |
| JP2004227035A (ja) | 証券業務支援システム | |
| JP2916354B2 (ja) | クレジットカード発行装置 | |
| US8583510B2 (en) | Automatic sales assistant for electronic commerce customers | |
| JP2001283005A (ja) | 金融商品照会システム及びその方法、並びにコンピュータ上で動作する金融商品照会プログラムを記録した記録媒体 | |
| JP7451447B2 (ja) | 顧客情報管理システム | |
| Gian et al. | Development of Electronic Business from the Historical Point of View of an E-Commerce Concept | |
| JP7394819B2 (ja) | 倉庫内商品取引システム、倉庫内商品取引方法、およびプログラム | |
| JP2003085253A (ja) | コンピュータシステム、コンピュータシステムの制御方法及びプログラム | |
| JP7256652B2 (ja) | Ｃｒｍシステム | |
| JP2002269392A (ja) | インターネット利用の購買エージェント支援サーバ | |
| JP2003108767A (ja) | ローンの逆オークションシステム | |
| JP2022050756A (ja) | 取引明細照合システム及び取引明細照合方法 | |
| JP2002169937A (ja) | 取引処理システム、商品取扱サーバ及び取引処理方法 | |
| JP2020109712A (ja) | プログラム、情報処理方法、および情報処理システム | |
| JP3570342B2 (ja) | 電子取引システムと電子取引方法およびその処理プログラムを記録した記録媒体 | |
| JP2005038146A (ja) | 証券取引支援システム及び支援プログラム | |
| TWM636182U (zh) | 進銷貨廠商資料系統 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041125 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050720 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070104 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070116 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070315 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070731 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070802 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100810 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3996384 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100810 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110810 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120810 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130810 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140810 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |