JP2016181230A - 金融商品販売支援システムおよび金融商品販売支援プログラム - Google Patents

Abstract

【課題】金融機関における投資信託の窓口販売において、販売員が顧客に対して行う一連の販売・営業業務における画面遷移の戻りや中断時点からの再開を可能とする。【解決手段】窓販会社２において販売員２１による顧客２２への金融商品の窓口販売に係る業務を支援する金融商品販売支援システム１であって、対象の前記金融商品の窓口販売に係る販売員２１と顧客２２との面談の状況を含む情報を記録する面談管理ＤＢ１１２と、前記面談の進行に沿って販売員２１が使用する販売員端末２０に所定の画面を表示させるとともに、画面の遷移状況、前記面談のステータス、および前記面談の結果に係る情報を面談管理ＤＢ１１２に随時記録し、販売員端末２０から画面の遷移を戻る旨の指示を受けた場合に、面談管理ＤＢ１１２に記録されている情報に基づく内容によって戻り先に対応する画面を表示させる面談管理部１１とを有する。【選択図】図１

Description

本発明は、金融機関における営業支援技術に関し、特に、投資信託の窓口販売業務を支援する金融商品販売支援システムおよび金融商品販売支援プログラムに適用して有効な技術に関するものである。

金融機関窓口での投資信託の窓口販売の解禁以来、銀行等における窓口販売は増加しており、販売員が顧客に対して投資信託等の金融商品の販売を行う際の業務を情報処理システムとして支援するための仕組みが検討・実装されている。

例えば、特開２００５−３２０９１号公報（特許文献１）には、投資信託の買付、解約、乗換取引に必要な処理を実行する投資信託取引支援システムにおいて、各投資信託の危険度に対応した商品セグメントと、各顧客の耐危険度に対応した顧客セグメントとの組合せによる取引パターン毎に取引の適合性を定義しておくマトリクスＤＢを保持することで、顧客の属性や商品の危険度に応じた最適な説明情報を販売員に提示するとともに、問題のある取引を事前に検知して販売員に確認を促したり、取引自体を停止したりすることを可能とする技術が記載されている。

また、例えば、特開２００５−２５０８０９号公報（特許文献２）には、窓口販売支援システムにおいて、データベースに複数のユーザが共通で用いるルールデータを記憶しておき、ユーザごとにルールデータとリスク許容度データとの対応の設定と、各取引の妥当性判断に用いる属性データを記憶できるようにすることで、ユーザが設定した基準に応じて顧客の取引内容をチェックできるようにし、ユーザの経験等に応じた適切なコンプライアンスチェックを可能とする技術が記載されている。

また、特開２００８−１９７９９６号公報（特許文献３）には、金融商品販売支援システムにおいて、顧客端末とデータ通信を行って顧客認証を行い、各販売手順にあわせて画面データを販売員端末と顧客端末のそれぞれに同送するとともに、顧客端末においてなされた入力事象のデータに基づいて販売手順の遷移可否を判定し、遷移可となった場合に次手順に対応する画面データを販売員端末と顧客端末のそれぞれに同送することで、販売員と顧客との間における適切な情報共有や、状況に即した顧客指示の迅速な確認等を可能とする技術が記載されている。

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

従来技術によれば、金融機関における投資信託等の金融商品の窓口販売において、コンプライアンスに配慮しつつ、販売員の販売業務・営業業務をナビゲーションするなどの支援を行うことが可能である。しかしながら、従来技術では、金融機関毎に個別に支援システムを構築する必要があり、構築や運用に係るコストが高いものとなっていた。

また、販売員が一連の販売業務・営業業務を行う際に情報処理端末を用いて顧客に提示する画面について、一般的には、情報処理端末上のＷｅｂブラウザ等に対してネットワークを介してＷｅｂサーバシステムから画面データを送信して表示させる。しかしながら、このような業務に用いる情報処理端末では、通常はＷｅｂブラウザのキャッシュを使用不可とすることから、過去の画面に柔軟に戻れるような画面遷移を行うことは困難である。また、口頭での商品説明の際など、一定時間以上端末操作がない状態が継続する場合や、後日改めて説明する場合など、現在までの説明状況（画面遷移）をいったん保持した上でリセットしたいというニーズがある。これについては、予期しない通信セッションの切断等の場合でも後にその状態から再開できるようにすることも考慮して、販売員による明示の操作などを要さずに常時保持できるのが望ましい。

そこで本発明の目的は、金融機関における投資信託の窓口販売において、販売員が顧客に対して行う一連の販売・営業業務における画面遷移の戻りや中断時点からの再開を可能とする金融商品販売支援システムおよび金融商品販売支援プログラムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による金融商品販売支援システムは、金融機関において販売員による顧客への金融商品の窓口販売に係る業務を支援する金融商品販売支援システムであって、対象の前記金融商品の窓口販売に係る前記販売員と前記顧客との面談の状況を含む情報を記録する面談管理情報保持部と、前記面談の進行に沿って前記販売員が使用する情報処理端末に所定の画面を表示させるとともに、画面の遷移状況、前記面談のステータス、および前記面談の結果に係る情報を前記面談管理情報保持部に随時記録し、前記情報処理端末から画面の遷移を戻る旨の指示を受けた場合に、前記面談管理情報保持部に記録されている情報に基づく内容によって戻り先に対応する画面を表示させる面談管理部と、を有するものである。

また、本発明は、上記の金融商品販売支援システムとして機能するようコンピュータに処理を実行させる金融商品販売支援プログラムにも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、金融機関における投資信託の窓口販売において、販売員が顧客に対して行う一連の販売・営業業務における画面遷移の戻りや中断時点からの再開が可能となる。

本発明の一実施の形態である金融商品販売支援システムの構成例について概要を示した図である。 本発明の一実施の形態における案件管理ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における面談管理ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における会社マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における顧客マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における基本属性設定ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における任意属性マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における商品マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における商品のグルーピングの例について概要を示した図である。 本発明の一実施の形態における商品設定マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における取引明細ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における適合性判定方法ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるメッセージ設定ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における合理性判定方法ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における質問事項設定ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における説明事項設定ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における説明資料ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における販売員の営業活動の処理の流れと画面遷移の例について概要を示した図である。 本発明の一実施の形態における販売員が顧客と面談を行う際の一連の処理の流れと画面遷移の例について概要を示した図である。 本発明の一実施の形態における「手続き確認」画面の具体例について概要を示した図である。 本発明の一実施の形態における「購入手続き確認」画面の具体例について概要を示した図である。 本発明の一実施の形態における「お客様カード確認・更新」画面の具体例について概要を示した図である。 本発明の一実施の形態における顧客マスタＤＢの標準的な属性項目についての設定情報を予め登録する画面の具体例について概要を示した図である。 本発明の一実施の形態における顧客マスタＤＢの任意項目についての設定情報を予め登録する画面の具体例について概要を示した図である。 本発明の一実施の形態における「お客様カード確認・更新」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「投資内容確認」画面の具体例について概要を示した図である。 本発明の一実施の形態における「投資内容確認」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における質問事項を予め登録するシステム設定画面の具体例について概要を示した図である。 本発明の一実施の形態における過去のリスクプロファイルの情報が存在する場合の確認画面の具体例について概要を示した図である。 本発明の一実施の形態における「購入商品群選択」画面の具体例について概要を示した図である。 本発明の一実施の形態における商品の設定情報を予め登録するシステム設定画面の具体例について概要を示した図である。 本発明の一実施の形態における「購入商品群選択」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態における面談を終了等する場合に表示されるダイアログの具体的な例について概要を示した図である。 本発明の一実施の形態における面談が終了した場合の面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「事前説明事項」画面の具体例について概要を示した図である。 本発明の一実施の形態における「事前説明事項」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における面談が終了した場合の面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「購入商品選択」画面の具体例について概要を示した図である。 本発明の一実施の形態における「購入商品選択」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における、購入商品の確認画面の具体例について概要を示した図である。 本発明の一実施の形態における「適合性・合理性判定」画面の具体例について概要を示した図である。 本発明の一実施の形態における「適合性・合理性判定」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における適合性判定の条件を予め登録するシステム設定画面の具体例について概要を示した図である。 本発明の一実施の形態における警告メッセージを予め登録するシステム設定画面の具体例について概要を示した図である。 本発明の一実施の形態におけるエラーメッセージを予め登録するシステム設定画面の具体例について概要を示した図である。 本発明の一実施の形態における取引経済合理性判定の条件を予め登録するシステム設定画面の具体例について概要を示した図である。 本発明の一実施の形態における「重要事項説明」画面の具体例について概要を示した図である。 本発明の一実施の形態における「重要事項説明」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における面談が終了した場合の面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「説明資料確認」画面の具体例について概要を示した図である。 本発明の一実施の形態における「説明資料確認」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「今後確認」画面の具体例について概要を示した図である。 本発明の一実施の形態における「今後確認」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「取引内容確認」画面の具体例について概要を示した図である。 本発明の一実施の形態における面談が終了した場合の面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「面談完了」画面の具体例について概要を示した図である。 本発明の一実施の形態における「面談完了」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における確認書を出力した後の「面談完了」画面の具体例について概要を示した図である。 本発明の一実施の形態における確認書を出力した状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「解約商品選択」画面の具体例について概要を示した図である。 本発明の一実施の形態における「取引内容確認」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。 本発明の一実施の形態における「面談内容入力」画面の具体例について概要を示した図である。 本発明の一実施の形態における「面談内容入力」画面に遷移している状況での面談管理ＤＢの具体的な内容の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜システム構成＞
図１は、本発明の一実施の形態である金融商品販売支援システムの構成例について概要を示した図である。金融商品販売支援システム１は、投資信託等の金融商品を窓口販売する銀行等の複数の金融機関（図中では窓販会社２）に対して、インターネット等のネットワーク３を介したＡＳＰ（Application Service Provider）サービスとして窓口販売業務の支援サービスを提供する情報処理システムである。各窓販会社２の販売員２１は、ＰＣ（Personal Computer）やタブレット型端末などの情報処理端末上の図示しないＷｅｂブラウザなどを利用して金融商品販売支援システム１にアクセスし、表示される画面を利用して来店した顧客２２に対して面談により投資信託の窓口販売業務や営業業務などを行う。

金融商品販売支援システム１は、例えば、各窓販会社２に対して窓口販売の支援サービスを提供する事業者等が運営するサーバ機器やクラウドコンピューティング環境上に構築された仮想サーバ等により実装されたサーバシステムであり、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアとして実装された面談管理部１１、案件管理部１２、および設定管理部１３などの各部を有する。

また、データベースやメモリ上に展開されたテーブルなどにより実装された案件管理データベース（ＤＢ）１１１、面談管理ＤＢ１１２、会社マスタＤＢ１２０、顧客マスタＤＢ１３０、基本属性設定ＤＢ１３１、任意属性マスタＤＢ１３２、商品マスタＤＢ１４０、商品設定マスタＤＢ１４１、取引明細ＤＢ１５０、適合性判定方法ＤＢ１６１、メッセージ設定ＤＢ１６２、合理性判定方法ＤＢ１６３、質問事項設定ＤＢ１７１、説明事項設定ＤＢ１７２、および説明資料ＤＢ１７３などの各データストアを有する。

面談管理部１１は、販売員２１が投資信託の窓口販売に関連して顧客２２に対して行う面談の際に、必要な情報を販売員端末２０の画面上に表示させて支援するとともに、画面の遷移により面談の進行をナビゲーションする機能を有する。また、金融機関（窓販会社２）毎に、面談の進捗や面談内容を面談管理ＤＢ１１２に記録して管理する機能を有する。これにより、面談時における画面遷移の戻りや中断時点からの再開などの制御を可能とし、面談の効率を向上させることができる。

本実施の形態では、販売員２１が顧客２２に対して説明や検討等を行った投資信託などの商品毎に１件の「面談」として取り扱う。これに対し、案件管理部１２は、窓販会社２毎に複数の「面談」をまとめて「案件」として案件管理ＤＢ１１１に登録・管理する機能を有する。顧客２２の１回の来店の際に複数商品について説明等を行った場合は、これら複数の「面談」をまとめて１つの「案件」として管理することができる。異なる来店時に説明等がされた複数の「面談」をまとめて１つの「案件」としてもよい。

設定管理部１３は、販売員２１が顧客２２との間で面談を行う際に必要となる各種設定情報等を窓販会社２毎に予め登録・更新しておくためのメンテナンス機能を有する。本実施の形態の金融商品販売支援システム１は、複数の窓販会社２が共同利用するＡＳＰサービスを提供するシステムであり、各窓販会社２に共通の事項については標準で有しているが、各窓販会社２に固有の内容については、個別に設定・登録可能とすることで柔軟にカスタマイズできるようにする。各窓販会社２に固有の内容としては、例えば、顧客２２の属性情報として用いる項目や、商品の種類、商品の属性情報として用いる項目、取引の適合性や合理性を判定するための判定事項や判定条件、顧客２２に対する質問事項や説明事項、配布したり参照したりする資料などが挙げられる。

＜データ構成＞
図２は、案件管理ＤＢ１１１のデータ構成の例について概要を示した図である。案件管理ＤＢ１１１は、複数の面談をまとめた案件についての情報を保持するテーブルであり、例えば、会社コード、案件番号、顧客コード、担当者ＩＤ、面談番号１〜ｎなどの各項目を有する。

会社コードの項目は、対象の案件を取り扱う窓販会社２を特定するためのコード値等の情報を保持する。この値は後述する会社マスタＤＢ１２０に定義されている。案件番号の項目は、対象の案件を窓販会社２の単位で一意に識別するシーケンス番号等の情報を保持する。顧客コードの項目は、対象の案件における顧客２２を特定するためのコード値等の情報を保持する。この値は後述する顧客マスタＤＢ１３０に定義されている。担当者ＩＤの項目は、対象の案件における販売員２１を特定するためのＩＤ等の情報を保持する。面談番号１〜ｎの項目は、対象の案件に含まれる各面談を特定するためのシーケンス番号等の情報を保持する。この値は後述する面談管理ＤＢ１１２に登録されている。図２の例では１つの案件にｎ個の面談を含むことができるが、ｎの値は例えば５などとして予め決定しておく。

図３は、面談管理ＤＢ１１２のデータ構成の例について概要を示した図である。面談管理ＤＢ１１２は、販売員２１が顧客２２に対して特定の商品等に対して行った、もしくは現在行っている面談についての情報を保持するテーブルであり、例えば、会社コード、面談番号、面談内容、商品群、商品種別、商品、面談進捗、ステータス、および面談結果などの各項目を有する。

会社コードの項目は、対象の面談を取り扱う窓販会社２を特定するためのコード値等の情報を保持する。面談番号の項目は、対象の面談を窓販会社２の単位で一意に識別するシーケンス番号等の情報を保持する。面談内容の項目は、対象の面談の内容を示すコード値等の情報を保持する。例えば、対象の面談が具体的な投資の提案なのか、より一般的な投資の相談なのか、特定の商品の取引を行うものなのか、などを区分するコード値が含まれる。

商品群、商品種別、および商品の各項目は、それぞれ、対象の面談において取り扱われた商品が属する商品群、商品種別、および当該商品を示すコード値等の情報を保持する。商品を示すコード値等は後述する商品マスタＤＢ１４０に定義されている。また、商品群や商品種別の値は後述する商品設定マスタＤＢ１４１に定義されている。面談進捗の項目は、対象の面談の進捗状況（画面遷移状況）を示すコード値等の情報を保持する。後述するように、面談の進行パターン（画面遷移）は予め設定されているため、現在どこまで進んでいるかの情報を保持することで、面談毎の進捗状況を容易に把握することができる。また、面談管理ＤＢ１１２の各項目は、面談の進行状況（表示する画面）を復元するために必要な情報を含んでいる。したがって、画面管理ＤＢ１１２の内容を参照することで、面談の中断・再開などの制御も可能となる。

ステータスの項目は、対象の面談の現在のステータスを示すコード値等の情報を保持する。ステータスには、例えば、商品選択中や面談中、処理待ちなどの面談の状況、エラーや警告の発生の有無、承認の状況などを示すコード値が含まれる。面談結果の項目は、対象の面談が終了したときの結果の内容を示すコード値等の情報を保持する。例えば、成約、見送り、拒否、重要事項等の説明に対する不同意、解約、交渉継続などを区分するコード値が含まれる。

図４は、会社マスタＤＢ１２０のデータ構成の例について概要を示した図である。会社マスタＤＢ１２０は、金融商品販売支援システム１による投資信託の窓口販売の支援サービスを利用する窓販会社２についてのマスタ情報を保持するテーブルであり、例えば、会社コード、会社名、ＵＲＬ、およびオプション設定などの各項目を有する。

会社コードの項目は、対象の窓販会社２を金融商品販売支援システム１において一意に識別するコード値等の情報を保持する。会社名の項目は、対象の窓販会社２の表示名称の情報を保持する。ＵＲＬの項目は、対象の窓販会社２の販売員２１が販売員端末２０によって金融商品販売支援システム１にアクセスする際のＵＲＬ（Uniform Resource Locator）として窓販会社２毎に設定された情報を保持する。オプション設定の項目は、対象の窓販会社２が金融商品販売支援システム１による投資信託の窓口販売の支援サービスを利用するに際して、予め用意された選択可能なオプション項目がある場合には、その選択状況に係る情報を保持する。

図５は、顧客マスタＤＢ１３０のデータ構成の例について概要を示した図である。顧客マスタＤＢ１３０は、各窓販会社２の顧客２２についての属性情報を含むマスタ情報を保持するテーブルであり、例えば、会社コード、顧客コード、扱者、個人法人区分、氏名・名称、性別、生年月日・設立日、住所、連絡先、顧客セグメント、職業コード、勤務先、法人区分、融資有無、投資家区分、および任意項目１〜ｎなどの各項目を有する。

会社コードの項目は、対象の顧客２２に対応する窓販会社２を特定するためのコード値等の情報を保持する。顧客コードの項目は、対象の顧客２２を窓販会社２の単位で一意に識別するコード値等の情報を保持する。扱者の項目は、対象の顧客２２の扱者である担当者を特定するＩＤ等の情報を保持する。個人法人区分の項目は、対象の顧客２２が個人か法人かを区分するコード値等の情報を保持する。氏名・名称の項目は、対象の顧客２２の氏名（個人の場合）もしくは名称（法人の場合）の情報を保持する。性別の項目は、対象の顧客２２が個人の場合にその性別を特定するコード値等の情報を保持する。生年月日・設立日の項目は、対象の顧客２２の生年月日（個人の場合）もしくは設立日（法人の場合）の情報を保持する。住所および連絡先の各項目は、対象の顧客２２の住所および連絡先（電話番号や電子メールアドレスなど）の情報を保持する。

顧客セグメントの項目は、対象の顧客２２が窓販会社２が設定したどのセグメントに属するかを特定するコード値等の情報を保持する。職業コードの項目は、対象の顧客２２が個人の場合にその職業の種別を特定するコード値等の情報を保持する。勤務先の項目は、対象の顧客２２が個人の場合にその勤務先の名称等の情報を保持する。法人区分の項目は、対象の顧客２が法人の場合にその種別を区分するコード値等の情報を保持する。融資有無の項目は、対象の顧客２２が窓販会社２である銀行からの融資を現在受けているか否かを示す情報を保持する。投資家区分の項目は、対象の顧客２２が一般投資家かプロ投資家かなどを区分するコード値等の情報を保持する。

任意項目１〜ｎの項目は、顧客２２の属性情報として標準的に用意されている上記の各項目以外に、各窓販会社２が個別に設定することができる属性情報を特定するコード値等の情報を保持する。任意項目１〜ｎによって設定した各属性情報の内容については、後述する任意属性マスタＤＢ１３２において定義する。なお、図５の例ではｎ個の任意項目を設定することができるが、ｎの値は例えば５０などとして予め決定しておく。これにより、各窓販会社２は、標準的に用意されている基本属性に加えて、独自の属性項目を柔軟に設定することが可能となる。

図６は、基本属性設定ＤＢ１３１のデータ構成の例について概要を示した図である。基本属性設定ＤＢ１３１は、図５に示した顧客マスタＤＢ１３０のデータ項目のうち、顧客２２の属性情報として標準的に用意されている基本属性について、その利用内容を各窓販会社２が任意に設定した内容を保持するテーブルであり、例えば、会社コード、項目名、表示名、個人法人区分、印刷、および表示／非表示などの各項目を有する。

会社コードの項目は、対象の基本属性に対する設定を行った窓販会社２を特定するためのコード値等の情報を保持する。項目名の項目は、対象の基本属性の項目（例えば、図５の顧客マスタＤＢ１３０における「氏名・名称」、「性別」など）を示す名称の情報を保持する。表示名の項目は、対象の基本属性の項目を画面表示する際の表示名称の情報を保持する。個人法人区分の項目は、対象の基本属性を個人顧客、法人顧客、もしくはその両方のいずれに対して適用するのかを示すコード値等の情報を保持する。印刷および表示／非表示の各項目は、それぞれ、対象の基本属性の項目を印刷対象とするか否か、および画面表示するか否か示す情報を保持する。

図７は、任意属性マスタＤＢ１３２のデータ構成の例について概要を示した図である。任意属性マスタＤＢ１３２は、図５に示した顧客マスタＤＢ１３０のデータ項目のうち、顧客２２の属性情報として各窓販会社２が独自に設定した任意属性について、その内容に係る情報を保持するテーブルであり、例えば、会社コード、任意項目ＩＤ、表示名、個人法人区分、印刷、使用区分、選択肢１〜ｎ表示文言、選択肢１〜ｎ配点、および選択肢１〜ｎ使用区分などの各項目を有する。なお、任意属性としては、例えば、“投資目的”や“資産状況”、“取引動機”、“年収”などが挙げられる。

会社コードの項目は、対象の任意属性の設定を行った窓販会社２を特定するためのコード値等の情報を保持する。任意項目ＩＤの項目は、対象の任意項目を窓販会社２の単位で一意に識別するＩＤ等の情報を保持する。この項目は、図５の顧客マスタＤＢ１３０の任意項目１〜ｎに対応する。表示名の項目は、対象の任意属性の表示名称や表示内容の情報を保持する。個人法人区分の項目は、対象の任意属性を個人顧客、法人顧客、もしくはその両方のいずれに対して適用するのかを示すコード値等の情報を保持する。印刷および使用区分の各項目は、それぞれ、対象の任意属性の項目を印刷対象とするか否か、および使用するか否か示す情報を保持する。

対象の任意属性に対して実際に値を設定する際は、予め窓販会社２が設定した選択肢の中から選択して設定するものとする。本実施の形態では、各選択肢の内容も、選択肢１〜ｎ表示文言、選択肢１〜ｎ配点、および選択肢１〜ｎ使用区分などの各項目によって任意に設定することができる。図７の例では各任意属性に対してｎ個の選択肢を設定することができるとしているが、ｎの値は例えば１０などとして予め決定しておく。

選択肢１〜ｎ表示文言の項目は、各選択肢の表示文言の情報を保持する。例えば、対象の任意属性が“資産状況”の場合は、選択肢の表示文言は、“０円以上、３００万円未満”、“３００万円以上、５００万円未満”、“５００万円以上、１，０００万円未満”、“１，０００万円以上、３，０００万円未満”、“３，０００万円以上”などとすることができる。選択肢１〜ｎ配点の項目は、対象の選択肢が選択された場合の評価値の重み付け値の情報を保持する。これにより、例えば、顧客２２の属性情報として設定された内容に基づいて評価値を集計し、顧客２２に対する評価として利用することを可能とする。選択肢１〜ｎ使用区分の項目は、対象の選択肢を使用するか否かを示す情報を保持する。

図８は、商品マスタＤＢ１４０のデータ構成の例について概要を示した図である。商品マスタＤＢ１４０は、各窓販会社２が販売する金融商品についてのマスタ情報を保持するテーブルであり、例えば、会社コード、商品コード、商品名称、商品種別、商品群、商品セグメント１〜ｎ、単位、通貨、商品提供会社、最低投資情報、元本割れリスク情報、手数料、および表示順などの各項目を有する。

会社コードの項目は、対象の商品を取り扱う窓販会社２を特定するためのコード値等の情報を保持する。商品コードの項目は、対象の商品を窓販会社２の単位で一意に識別するコード値等の情報を保持する。商品名称の項目は、対象の商品の表示名称の情報を保持する。商品種別、商品群、および商品セグメント１〜ｎの各項目は、対象の商品をグルーピングする単位として、当該商品が属する商品種別、商品群および１つ以上の商品セグメントを特定するコード値等の情報を保持する。

図９は、商品のグルーピングの例について概要を示した図である。図示するように、各商品は商品種別に分類され、さらに各商品種別の中で商品群に分類される。また、複数の商品種別を跨って商品セグメントとしてグルーピングすることもできる。図９の例では、１つの商品が複数の商品セグメントに属することができることを示しているが、複数の商品群や商品種別に属するように設定することも可能である。このような設定は、各窓販会社２が個別に自由に行うことができる。図８の例では商品が最大ｎ個の商品セグメントに属することができるとしているが、ｎの値は例えば１０などとして予め決定しておく。

商品種別としては、例えば、“保険”、“外貨預金”、“投信”、“円預金”などを設定する。商品群は、商品種別と同じであってもよいが、必要に応じてさらに詳細化することができる。商品セグメントとしては、例えば、“中長期運用不適合”、“短期運用不適合”、“法人販売不可”など商品種別や商品群に関わらず一定の制約や特性を有する商品をグルーピングするものや、“保険商品”、“投資信託”など一定の種類の商品をグルーピングするものを適宜設定することができる。

図８に戻り、単位および通貨の各項目は、それぞれ、対象の商品を計数する単位（例えば“口数”や“金額”）および通貨を示すコード値等の情報を保持する。商品提供会社の項目は、対象の商品が他社が提供するものである場合にその提供元の会社の情報を保持する。最低投資情報の項目は、対象の商品の最低投資期間や最低投資口数・金額などの最低投資条件に係る情報を保持する。元本割れリスク情報は、対象の商品が元本割れリスクを有するものか否か、リスクを有する場合のその内容などの情報を保持する。手数料の項目は、対象の商品を販売する際の手数料に係る情報を保持する。表示順の項目は、商品一覧を画面表示する際の対象の商品の表示順位に係る情報を保持する。

図１０は、商品設定マスタＤＢ１４１のデータ構成の例について概要を示した図である。商品設定マスタＤＢ１４１は、商品が属する商品種別や商品群、商品セグメントについてのマスタ情報を保持するテーブルであり、例えば、会社コード、グルーピング区分、名称、およびコード値などの各項目を有する。

会社コードの項目は、対象のマスタ情報を使用する窓販会社２を特定するためのコード値等の情報を保持する。グルーピング区分の項目は、対象のマスタ情報が商品種別、商品群、および商品セグメントのいずれを設定したものかを識別するコード値等の情報を保持する。名称およびコード値の各項目は、対象のマスタ情報（商品種別、商品群、商品セグメント）の表示名称およびこれを示すコード値等の情報を保持する。

図１１は、取引明細ＤＢ１５０のデータ構成の例について概要を示した図である。取引明細ＤＢ１５０は、各窓販会社２における商品毎の取引の明細情報を夜間バッチ処理等により各窓販会社２のシステムから取得して保持するテーブルであり、例えば、会社コード、顧客コード、商品別口座番号、商品別取引番号、商品種別、商品コード、申込日、取引区分、金額・口数、および通貨などの各項目を有する。

会社コードの項目は、対象の取引が行われた窓販会社２を特定するためのコード値等の情報を保持する。顧客コードの項目は、対象の取引を行った顧客２２を特定するコード値等の情報を保持する。商品別口座番号および商品別取引番号の各項目は、それぞれ、対象の取引における商品別の口座番号および当該取引を特定する取引番号の情報を保持する。商品種別および商品コードの各項目は、それぞれ、対象の取引における商品が属する商品種別を特定するコード値等および当該商品を特定する商品コードの情報を保持する。

申込日の項目は、対象の取引において顧客２２が申込を行った日付の情報を保持する。金額・口数の項目は、対象の取引における金額および口数の少なくとも一方の情報を保持する。通貨の項目は、対象の取引における通貨を示すコード値等の情報を保持する。

図１２は、適合性判定方法ＤＢ１６１のデータ構成の例について概要を示した図である。適合性判定方法ＤＢ１６１は、顧客２２が行おうとうする取引が当該顧客２２にとって適合したものか（不適合なものではないか）を、顧客２２の属性情報と商品の内容との関連に基づいて判定する適合性判定の条件に係る設定情報を保持するテーブルである。適合性判定方法ＤＢ１６１は、例えば、会社コード、適合性タイトル、適合性判定番号、個人法人区分、商品セグメント、商品種別、商品コード、通貨、年齢範囲、顧客セグメント、職業コード、特定関係者区分、投資家区分、投資目的、資産状況、金融資産、年収、任意項目１〜ｎ、判定区分、メッセージＩＤ、および使用区分などの各項目を有する。

会社コードの項目は、対象の適合性判定条件を用いる窓販会社２を特定するためのコード値等の情報を保持する。適合性タイトルおよび適合性判定番号の各項目は、それぞれ、対象の適合性判定条件の表示名称および当該方法を窓販会社２の単位で一意に識別するシーケンス番号等の情報を保持する。

個人法人区分の項目は、対象の適合性判定条件を個人、法人もしくはその両方のいずれに適用するかを示すコード値等の情報を保持する。商品セグメントから任意項目１〜ｎまでの各項目は、商品マスタＤＢ１４０および顧客マスタＤＢ１３０に設定される商品および顧客２２の各属性情報であり、これらについてそれぞれ、適合性判定の際の条件の情報を保持する。例えば、「年齢範囲」として“７０歳以上”、「投資家区分」として“一般投資家”、「投資目的」として“元本割れ回避”という内容が設定されていた場合に、顧客２２および当該顧客が行おうとしている取引がこれらの条件に合致する場合には、後述するように警告もしくはエラーが出力される。なお、判定の条件として用いない上記以外の各項目については値を設定する必要はない。

判定区分の項目は、対象の適合性判定条件に合致した場合に、警告もしくはエラーのいずれを出力するのかを示すコード値等の情報を保持する。メッセージＩＤの項目は、警告もしくはエラーを出力する際に表示するメッセージを特定するＩＤ等の情報を保持する。なお、メッセージの内容は後述するメッセージ設定ＤＢ１６２に定義される。使用区分の項目は、対象の適合性判定条件を使用するか否かを示す情報を保持する。

図１３は、メッセージ設定ＤＢ１６２のデータ構成の例について概要を示した図である。メッセージ設定ＤＢ１６２は、上述した適合性判定および後述する取引経済合理性判定において警告もしくはエラーと判定された場合等、販売員端末２０に出力する各種メッセージの内容に係る設定情報を保持するテーブルであり、例えば、会社コード、メッセージＩＤ、メッセージ、および使用区分などの各項目を有する。

会社コードの項目は、対象のメッセージを用いる窓販会社２を特定するためのコード値等の情報を保持する。メッセージＩＤの項目は、対象のメッセージを窓販会社２の単位で一意に識別するためのＩＤ等の情報を保持する。メッセージの項目は、対象のメッセージのテキスト情報を保持する。販売員端末２０上のＷｅｂブラウザ上で対象のメッセージを表示する際にＨＴＭＬ（HyperText Markup Language）を解釈する構成とした場合には、メッセージにＨＴＭＬのタグを挿入して文字を修飾できるようにしてもよい。使用区分の項目は、対象のメッセージを使用するか否かを示す情報を保持する。

図１４は、合理性判定方法ＤＢ１６３のデータ構成の例について概要を示した図である。合理性判定方法ＤＢ１６３は、顧客２２が行おうとうする取引が取引経済の観点から合理性を有するものか（不合理なものではないか）を、商品の内容と過去の取引内容との関連に基づいて判定する取引経済合理性判定の条件に係る設定情報を保持するテーブルである。合理性判定方法ＤＢ１６３は、例えば、会社コード、合理性判定番号、判定期間、商品セグメント、商品種別、商品コード、通貨、判定区分、メッセージ、および使用区分などの各項目を有する。

会社コードの項目は、対象の取引経済合理性判定条件を用いる窓販会社２を特定するためのコード値等の情報を保持する。合理性判定番号の項目は、対象の取引経済合理性判定条件を窓販会社２の単位で一意に識別するシーケンス番号等の情報を保持する。判定期間の項目は、判定の対象とする顧客２２の過去の取引を抽出する期間の始期および終期の情報を保持する。

商品セグメントから通貨までの各項目は、商品マスタＤＢ１４０に設定される商品の各属性情報であり、これらについてそれぞれ、取引経済合理性判定の際の条件に係る設定情報を保持する。例えば、「商品種別」として、“保険”、“外貨預金”、“投信”、“円預金”が設定されていた場合に、取引明細ＤＢ１５０を参照して、顧客２２が過去の一定期間（「判定期間」として例えば“１２ヶ月以内”が設定されていた場合は過去１２ヶ月）にこれらの商品種別に合致する取引を行っていた場合には、後述するように警告もしくはエラーが出力される。なお、判定の条件として用いない上記以外の各項目については値を設定する必要はない。

判定区分の項目は、対象の取引経済合理性判定条件に合致した場合に、警告もしくはエラーのいずれを出力するのかを示すコード値等の情報を保持する。メッセージＩＤの項目は、警告もしくはエラーを出力する際に表示するメッセージを特定するＩＤ等の情報を保持する。メッセージの内容は図１３に示したメッセージ設定ＤＢ１６２に定義される。使用区分の項目は、対象の取引経済合理性判定条件を使用するか否かを示す情報を保持する。

図１５は、質問事項設定ＤＢ１７１のデータ構成の例について概要を示した図である。質問事項設定ＤＢ１７１は、販売員２１が顧客２２と面談を行う際に、顧客マスタＤＢ１３０に登録すべき属性情報を顧客２２から取得するためのプロファイルを行う際の質問の内容に係る設定情報を保持するテーブルであり、例えば、会社コード、質問ＩＤ、質問内容、個人法人区分、表示順、入力形式、回答内容１〜ｎ、回答表示順１〜ｎ、および配点１〜ｎなどの各項目を有する。

会社コードの項目は、対象の質問事項を用いる窓販会社２を特定するためのコード値等の情報を保持する。質問ＩＤの項目は、対象の質問事項を窓販会社２の単位で一意に識別するためのＩＤ等の情報を保持する。質問内容の項目は、対象の質問の内容に係るテキスト情報を保持する。例えば、“今回の投資で想定している投資期間はどのくらいでしょうか？”などとすることができる。個人法人区分の項目は、対象の質問事項を個人、法人もしくはその両方のいずれに適用するかを示すコード値等の情報を保持する。表示順の項目は、対象の質問事項を画面上に表示する際の表示順位を示す情報を保持する。

入力形式の項目は、対象の質問事項に回答する際の入力形式を特定するコード値等の情報を保持する。入力形式としては、例えば、“ラジオボタン”や“チェックボックス”等とすることができ、複数の選択肢の中から該当するものを選択して回答することができる。選択肢の内容は、回答内容１〜ｎ、回答表示順１〜ｎ、および配点１〜ｎなどの各項目によって任意に設定することができる。図１５の例では各質問事項に対してｎ個の選択肢を設定することができるとしているが、ｎの値は例えば１０などとして予め決定しておく。

回答内容１〜ｎの項目は、各選択肢の回答内容のテキスト情報を保持する。例えば、「入力形式」の項目が“ラジオボタン”の場合には、ボタンの表示テキストとして“１年以内”、“１〜３年”、“３年以上”などとすることができる。回答表示順１〜ｎの項目は、対象の選択肢の表示順位を示す情報を保持する。配点１〜ｎの項目は、対象の回答内容が選択された場合の評価値の重み付け値の情報を保持する。これにより、顧客２２の属性として設定された内容に基づいて評価値を集計し、顧客２２に対する評価として利用することを可能とする。

図１６は、説明事項設定ＤＢ１７２のデータ構成の例について概要を示した図である。説明事項設定ＤＢ１７２は、販売員２１が顧客２２と面談を行う際に、顧客２２に対して説明する事項（説明が必須な重要事項や、必要に応じて説明すれば足りる任意事項が含まれる）に係る設定情報を保持するテーブルであり、例えば、会社コード、説明事項ＩＤ、区分、および説明内容などの各項目を有する。

会社コードの項目は、対象の説明事項を用いる窓販会社２を特定するためのコード値等の情報を保持する。説明事項ＩＤの項目は、対象の説明事項を窓販会社２の単位で一意に識別するためのＩＤ等の情報を保持する。区分の項目は、対象の説明事項が事前説明事項や重要説明事項などのいずれに該当するかを区分するコード値等の情報を保持する。説明内容の項目は、対象の説明事項の内容に係るテキスト情報を保持する。

図１７は、説明資料ＤＢ１７３のデータ構成の例について概要を示した図である。説明資料ＤＢ１７３は、販売員２１が顧客２２と面談を行う際に、顧客２２に対して説明したり配布したりする資料を電子データとして閲覧可能としたものに係る情報を保持するテーブルであり、例えば、会社コード、資料ＩＤ、資料タイプ、資料名、およびＵＲＬなどの各項目を有する。

会社コードの項目は、対象の説明資料を用いる窓販会社２を特定するためのコード値等の情報を保持する。資料ＩＤの項目は、対象の資料を窓販会社２の単位で一意に識別するためのＩＤ等の情報を保持する。資料タイプの項目は、対象の資料の種別・タイプを特定するコード値等の情報を保持する。例えば、資料の内容に関する区分や、資料の媒体に関する区分を示す情報が含まれる。ＵＲＬの項目は、対象の資料を販売員端末２０から閲覧・参照するためのＵＲＬの情報を保持する。

なお、上述の図２〜図１７で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。また、マスタ情報を保持するテーブルや、各窓販会社２による個別の設定情報を保持するテーブルでは、レコードの内容が更新される都度、当該レコードについてバージョンを付す等により世代管理を行い、過去の登録内容や設定内容を遡って参照できるようにしておく。また、販売員２１が面談を行うことにより、例えば図３に示した面談管理ＤＢ１１２の内容が更新された場合も含めて、販売員２１等により行われた操作等の内容や日時の情報は、図示しないログテーブル等に記録しておくのが望ましい。これらの情報を参照することにより、過去に行った面談の内容を復元・再現することが可能となる。

＜画面遷移＞
図１８は、販売員２１の営業活動における処理の流れと画面遷移の例について概要を示した図である。販売員２１は、販売員端末２０を利用して金融商品販売支援システム１にアクセスし、まず、事前確認を行う（Ｓ０１）。ここでは、「お知らせ一覧」、「案件一覧」、「保有資格」などのメニュー・表示内容から、留意すべき通知事項や、現在仕掛り中の案件の一覧などを確認し、当日の業務計画の立案・確認などを行う。

その後、販売員２１は、顧客検索の画面や機能を用いて顧客特定を行い（Ｓ０２）、表示された顧客サマリー画面を通して顧客情報確認を行う（Ｓ０３）。ここではさらに、「顧客カード」、「面談履歴」、「取引明細」、「残高明細」などのメニュー・表示内容から、対象の顧客２２についての属性情報や過去の取引状況などの各種情報を参照する。その後、対象の顧客２２との間で実際に面談・商品選定を行う（Ｓ０４）。ここでは、面談の進行に応じて各種画面が表示されるが、この内容については後述する。

面談が終了すると、販売員２１は、販売員端末２０の画面を通して面談内容入力を行う（Ｓ０５）。ここでは、「届出事項」、「面談基本情報」、「面談内容」などのメニュー・表示内容から、面談の内容を入力したり参照したりすることができる。また、「操作履歴」のメニューから面談時の操作の履歴（ログ）を参照することができる。その後、入力した面談の内容について上長承認を行う（Ｓ０６）。例えば、公知のワークフロー技術などを用いて上長への承認依頼を行い、上長は入力された面談内容を参照して承認処理を行う。その後、面談において商品購入が成約した場合は、必要に応じて発注手続きを行う（Ｓ０７）。金融商品販売支援システム１が金融商品の取引システムと連携している場合には、シームレスで発注手続きまで行うことができる。

図１９は、販売員２１が顧客２２と面談を行う際の一連の処理の流れと画面遷移の例について概要を示した図である。すなわち、図１８の処理の流れにおけるステップＳ０４の面談の部分を詳細化したものである。まず、「手続き確認」画面により、顧客２２との間で当該面談において行う手続きを選択・確認する（図１９のＳ１１）。図２０は、「手続き確認」画面の具体例について概要を示した図である。ここで「新規もしくは追加のご購入」ボタンが押下された場合、図１９における「購入手続き確認」画面に遷移し、販売員２１は、顧客２２との間で購入手続きの内容について選択・確認する（図１９のＳ１２）。

図２１は、「購入手続き確認」画面の具体例について概要を示した図である。当該画面で「戻る」ボタンが押下された場合は、図２０の「手続き確認」画面に戻る。一方、当該画面で「資産運用のご提案」もしくは「資産運用のご相談」ボタンが押下された場合は、図１９の画面遷移における「お客様カード確認・更新」画面に遷移し、販売員２１は、「お客様カード」、すなわち顧客マスタＤＢ１３０に登録された顧客属性について顧客２２に確認し、必要に応じて内容を登録もしくは更新する（図１９のＳ１３）。図２２は、「お客様カード確認・更新」画面の具体例について概要を示した図である。ここでは、「お客様カード」として、顧客２２について現在顧客マスタＤＢ１３０に登録されている内容の一部が表示されている。

本実施の形態では、顧客マスタＤＢ１３０の各属性項目については、各窓販会社２が独自に柔軟に設定することが可能である。図２３は、顧客マスタＤＢ１３０の標準的な属性項目についての設定情報を予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、標準的な属性情報について、表示名や個人／法人の区分、表示／非表示の区分などを設定することができる。設定内容は、図６に示した基本属性設定ＤＢ１３１に登録される。

また、図２４は、顧客マスタＤＢ１３０の任意項目についての設定情報を予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、任意属性項目について、タイトルや選択肢などの情報を設定することができる。設定内容は、図７に示した任意属性マスタＤＢ１３２に登録される。このように、本実施の形態では、顧客２２の属性情報の項目自体を各窓販会社２が独自に柔軟に設定することができる。

また、本実施の形態では、上述したように、面談時における画面遷移の戻りや中断時点からの再開などの制御を可能とするため、面談の進捗状況や面談内容を面談管理ＤＢ１１２に記録して管理する。図２５は、「お客様カード確認・更新」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、図２１の「購入手続き確認」画面において「資産運用のご提案」ボタンが押下された場合として、「面談内容」の項目に“投資提案”という内容を示すコード値等が設定されている。なお、本実施の形態では、面談の進捗状況や面談内容などの情報を面談管理ＤＢ１１２に記録するものとしているが、参照頻度が高いものなどについては必要に応じてデータベースではなく金融商品販売支援システム１上の図示しないメモリテーブル上に記録するようにしてもよい。

図２２の「お客様カード確認・更新」画面において、「変更する」ボタンが押下された場合は、お客様カードの登録内容、すなわち顧客マスタＤＢ１３０の登録内容を変更するための画面（図示しない）に遷移する。また、「戻る」ボタンが押下された場合は、図２１の「購入手続き確認」画面に戻る。戻った画面でさらに「戻る」ボタンが押下された場合は、図２５に示した面談管理ＤＢ１１２の「面談内容」の項目をクリアした上で図２０の「手続き確認」画面に戻る。

図２２の「お客様カード確認・更新」画面において、「確認しました」ボタンが押下された場合は、図１９の画面遷移における「投資内容確認」画面に遷移し、販売員２１は、顧客２２に対して今回の投資の内容について確認（リスクプロファイルを実施）する（図１９のＳ１４）。図２６は、「投資内容確認」画面の具体例について概要を示した図である。ここでは、投資の内容を確認するために予め設定された１つ以上の質問事項につき、画面を通して問い合わせてその回答の入力を受け付ける。図２６の例では、回答の選択肢がボタンにより示されており、合致する選択肢のボタンを押下することで回答を入力する。複数の質問事項について１画面で収まらない場合には複数のページにわたって表示する。

図２７は、「投資内容確認」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談番号」の項目に新たに採番された番号が設定され、また、「面談進捗」の項目には「投資内容確認」画面に遷移中であることを示す“プロファイル”という内容を示すコード値等が設定され、「ステータス」の項目には“面談中”という内容を示すコード値等が設定され、「面談結果」の項目には“未登録”という内容を示すコード値等が設定されている。

図２６の「投資内容確認」画面での質問事項は、窓販会社２毎に管理者等によって予め設定され、図１５に示した質問事項設定ＤＢ１７１に登録されている。図２８は、質問事項を予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、質問事項毎に、質問内容や回答の選択肢の情報を独自に入力して登録することができる。

図２６の「投資内容確認」画面において顧客２２に対してリスクプロファイルを行う際に、当該顧客２２が過去の面談で実施したプロファイルの結果がある場合は、当該プロファイルを再利用するか否かを問い合わせる。図２９は、「投資内容確認」の際に過去のリスクプロファイルの情報が存在する場合の確認画面の具体例について概要を示した図である。この画面において、「商品群選択」ボタンが押下された場合は、以前のリスクプロファイルの結果を再利用して、リスクプロファイルの実施を省略する。これにより、重複したリスクプロファイルを回避して販売員２１および顧客２２の負担を低減させることができる。「プロファイル実施」ボタンが押下された場合は、図２６の「投資内容確認」画面を通して通常通りリスクプロファイルを実施する。

図２６の「投資内容確認」画面において、「入力内容の確認」ボタンが押下された場合は、プロファイルの内容・結果を顧客２２が確認した上で、図１９の画面遷移における「購入商品群選択」画面に遷移し、顧客２２が購入を検討している商品の商品群を選択する（図１９のＳ１５）。図３０は、「購入商品群選択」画面の具体例について概要を示した図である。ここでは、顧客２２のリスクプロファイルの結果に基づいて所定の基準により抽出された商品群を提示して、顧客２２による選択を受け付ける。図３０の例では、商品群の選択肢がボタンにより示されており、対象の商品群のボタンを押下することで選択する。商品群は、例えば、画面左側のタブ（もしくはしおり）に示すように、“推奨商品群”、“適合商品群”、“不適合商品群”の区分に分類して提示してもよい。

商品群などの商品に係る設定情報は、窓販会社２毎に管理者等によって予め設定され、図８に示した商品マスタＤＢ１４０に登録されている。図３１は、商品の設定情報を予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、商品の名称や商品種別、商品群、商品セグメントなどの情報を独自に設定することができる。

図３２は、「購入商品群選択」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「購入商品群選択」画面に遷移中であることを示す“商品群選択”という内容を示すコード値等に更新されている。

図３３は、図３０の「購入商品群選択」画面から面談を終了等する場合に表示されるダイアログの具体的な例について概要を示した図である。図３０の「購入商品群選択」画面において、顧客２２もしくは販売員２１が商品群を選択するボタンを押下すると、例えば、販売員２１が当該商品群の販売資格を有しているか否か、当該商品群が高齢者などを勧誘する際に所定の条件が必要となるものであるか否かなどの所定のチェックが行われる。このチェックに該当した場合は、例えば、図３３（ａ）に示すようなダイアログを表示し、商品群を変更するか、面談を終了（中断）するかの選択を受け付ける。「商品群を変更する」ボタンが押下された場合は、図３０の「購入商品群選択」画面に戻る。

図３３（ａ）のダイアログで「面談を終了する」ボタンが押下された場合は、図３３（ｂ）に示すような確認のダイアログを表示した上で、面談を終了する。図３０の「購入商品群選択」画面において「面談終了」ボタンが押下された場合も同様である。

図３４は、「購入商品群選択」画面に遷移している状況で面談が終了した場合の面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新され、また、「面談結果」の項目が“面談中断”という内容を示すコード値等に更新されている。なお、ここでの「面談終了」は、面談の「中断」を意味し、面談管理ＤＢ１１２の「ステータス」の項目などを参照することで、別途「購入商品群選択」画面から面談を再開することが可能である。

図３０の「購入商品群選択」画面において、顧客２２もしくは販売員２１が商品群を選択した上で「選択」ボタンを押下すると、図１９の画面遷移における「事前説明事項」画面に遷移し、販売員２１が顧客２２に事前に説明が必要な事項を説明する（図１９のＳ１６）。図３５は、「事前説明事項」画面の具体例について概要を示した図である。ここでは、図１６に示した説明事項設定ＤＢ１７２に登録されている説明事項を示し、販売員２１からの説明に対する顧客２２の同意／不同意の入力を受け付ける。説明事項の内容を画面上に表示するようにしてもよい。なお、説明事項設定ＤＢ１７２に登録されている説明事項がない場合は、当該画面はスキップする。

図３６は、「事前説明事項」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「事前説明事項」画面に遷移中であることを示す“事前説明事項”という内容を示すコード値等に更新され、また、「商品群」の項目には図３０の「購入商品群選択」画面で選択された商品群である“商品群Ａ”が設定されている。

図３５の「事前説明事項」画面において「戻る」ボタンが押下された場合は、後述する「商品指定」が行われている場合を除き、図３０の「購入商品群選択」画面に戻る。このとき、面談管理ＤＢ１１２の「面談進捗」の項目の更新および「商品群」の項目のクリアしないものとする。したがって、「戻る」ボタンの押下により画面遷移を戻った後に、例えば通信断等によりセッションが途切れ、その後面談を再開する場合、図３５の「事前説明事項」画面から再開することになる。一方、「商品指定」が行われている場合は、「戻る」ボタンの押下により画面遷移を戻れないように制御する。

図３５の「事前説明事項」画面において「同意しない」ボタンが押下された場合は、図３３（ｂ）と同様の確認のダイアログを表示した上で、面談を終了する。図３７は、「購入商品選択」画面に遷移している状況で面談が終了した場合の面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新され、また、「面談結果」の項目が“事前確認不同意”という内容を示すコード値等に更新されている。

一方、図３５の「事前説明事項」画面において「同意する」ボタンが押下された場合は、図１９の画面遷移における「購入商品選択」画面に遷移し、図３０の「購入商品群選択」画面で選択された商品群の中から顧客２２もしくは販売員２１が購入対象の商品を選択する（図１９のＳ１７）。図３８は、「購入商品選択」画面の具体例について概要を示した図である。ここでは、商品群の中から商品コードや商品名で検索を行って絞り込まれた商品の一覧から、顧客２２もしくは販売員２１によって選択された１つ以上の購入対象の商品の情報を受け付ける。

図３９は、「購入商品選択」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「購入商品選択」画面に遷移中であることを示す“商品選択”という内容を示すコード値等に更新され、また、「ステータス」の項目が“商品選択中”という内容を示すコード値等に更新されている。

図３８の「購入商品選択」画面において「戻る」ボタンが押下された場合は、後述する「商品指定」が行われている場合、もしくは後述するように２つ目以降の商品についての面談である場合を除き、図３０の「購入商品群選択」画面に戻る。一方、「商品指定」が行われている場合、および２つ目以降の商品についての面談である場合は、「戻る」ボタンの押下により画面遷移を戻れないように制御する。このとき、図３８の画面右上の「中断」ボタンも表示しない。なお、「中断」ボタンは、これを押下することで、面談管理ＤＢ１１２の内容を現状のまま保持しつつ、面談を中断できるようにする機能を有する。

図３８の「購入商品選択」画面において「面談終了」ボタンが押下された場合は、図３３（ｂ）と同様の確認のダイアログを表示した上で、面談を終了する。このとき、面談管理ＤＢ１１２の内容は、図示しないが、図３９に示した状況から、図３４に示した場合と同様に、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新され、また、「面談結果」の項目が“面談中断”という内容を示すコード値等に更新される。

図３８の「購入商品選択」画面において、顧客２２もしくは販売員２１が商品を選択した上で「選択」ボタンを押下すると、購入商品の内容の確認を行う。図４０は、購入商品の確認画面の具体例について概要を示した図である。ここでは、図３８の「購入商品選択」画面において選択された商品の内容の確認に加えて、当該商品に対して行われた適合性判定および取引経済合理性判定の結果のサマリーを表示する。図４０の購入商品の確認画面において「戻る」ボタンが押下された場合は、図３８の「購入商品選択」画面に戻る。このとき、面談管理ＤＢ１１２の「商品群」、および「商品種別」と「商品」（商品が既に指定されている場合）の各項目の内容はクリアされる。

図４０の購入商品の確認画面において「確認しました」ボタンが押下された場合は、図１９の画面遷移における「適合性・合理性判定」画面に遷移し、適合性判定および取引経済合理性判定の結果情報を表示する（図１９のＳ１８）。図４１は、「適合性・合理性判定」画面の具体例について概要を示した図である。ここでは、適合性判定および取引経済合理性判定を行った結果、警告もしくはエラーが検出された場合に、メッセージとともにその詳細情報を表示する。警告・エラーがない場合には、図４１の例のようにその旨を表示する。

図４２は、「適合性・合理性判定」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「適合性・合理性判定」画面に遷移中であることを示す“警告・エラー理由”という内容を示すコード値等に更新され、また、「ステータス」の項目が“面談中”という内容を示すコード値等に更新されている。また、「商品種別」および「商品」の各項目には図３８の「購入商品選択」画面で選択された商品の商品種別である“商品種別Ｂ”および当該商品を示す“商品Ｃ”が設定されている。

上述したように、適合性判定は、図１２に示した適合性判定方法ＤＢ１６１に予め登録された内容に基づいて、顧客２２の属性情報（お客様カードの情報）と、選択された商品との関連によって判定される。また、取引経済合理性判定は、図１４に示した合理性判定方法ＤＢ１６３に予め登録された内容に基づいて、選択された商品と、顧客２２の過去の取引との関連によって判定される。

図４３は、適合性判定の条件を予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、商品マスタＤＢ１４０における各商品の属性情報と、顧客マスタＤＢ１３０（「お客様カード」）における顧客２２の基本属性および任意属性の各項目のうち１つ以上について、不適合（もしくはその可能性がある）と判定する条件を指定することができる。

図４３のシステム画面において表示される設定条件に係る各項目は、各窓販会社２の管理者等が予め商品マスタＤＢ１４０や顧客マスタＤＢ１３０などに設定・登録した内容に基づいて自動的に表示される。すなわち、本実施の形態では、上述したように、商品マスタＤＢ１４０や顧客マスタＤＢ１３０の項目自体についても各窓販会社２が柔軟に設定できることから、各窓販会社２は、適合性判定の条件を独自に設定できるだけではなく、条件に用いる項目やパラメータ等についても独自に設定することができるということを示している。なお、下方の「判定内容」の欄では、上記の判定条件に合致した場合に、警告もしくはエラーのいずれを出力するのか、およびその際に表示するメッセージを選択する。

図４４は、警告メッセージを予め登録するシステム設定画面の具体例について概要を示した図である。また、図４５は、エラーメッセージを予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、警告メッセージやエラーメッセージについて、その内容を設定することができる。設定された内容は、図１３に示したメッセージ設定ＤＢ１６２に登録される。

図４６は、取引経済合理性判定の条件を予め登録するシステム設定画面の具体例について概要を示した図である。ここでは、窓販会社２の管理者等が、商品マスタＤＢ１４０における各商品の属性情報の各項目のうち１つ以上について、取引明細ＤＢ１５０に記録された過去の取引との間でチェックを行う対象とする条件を指定することができる。取引経済合理性の判定条件についても、適合性判定と同様に、各窓販会社２が条件を独自に設定できるだけではなく、条件に用いる項目やパラメータ等についても独自に設定することができることを示している。

図４１の「適合性・合理性判定」画面に戻り、当該画面で「戻る」ボタンが押下された場合は、後述する「商品指定」が行われており、かつ指定された商品が「ノンリスク商品」の場合を除き、図４０の購入商品の確認画面に戻る。このとき、面談管理ＤＢ１１２の「商品群」、および「商品種別」と「商品」の各項目の内容はクリアしないものとする。したがって、「戻る」ボタンの押下により画面遷移を戻った後に、例えば通信断等によりセッションが途切れ、その後面談を再開する場合、商品が選択された状態で再開することになる。一方、「商品指定」が行われており、かつ指定された商品が「ノンリスク商品」の場合は、「戻る」ボタンの押下により画面遷移を戻れないように制御する。

図４１の「適合性・合理性判定」画面で「確認しました」ボタンが押下された場合は、図１９の画面遷移における「重要事項説明」画面に遷移し、販売員２１は、顧客２２に対して画面に表示された重要事項の説明を行う（図１９のＳ１９）。図４７は、「重要事項説明」画面の具体例について概要を示した図である。ここでは、説明が必要な重要事項が図１６に示した説明事項設定ＤＢ１７２に登録されている場合に、その内容を表示し、顧客２２による同意／不同意の選択についての入力を受け付ける。説明事項設定ＤＢ１７２に登録されている説明事項がない場合は、当該画面はスキップする。

図４８は、「重要事項説明」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「重要事項説明」画面に遷移中であることを示す“重要事項説明”という内容を示すコード値等に更新されている。

図４７の「重要事項説明」画面において「戻る」ボタンが押下された場合は、図４１の「適合性・合理性判定」画面に戻る。また、「同意しない」ボタンが押下された場合は、図３３（ｂ）と同様の確認のダイアログを表示した上で、面談を終了する。図４９は、「重要事項説明」画面に遷移している状況で面談が終了した場合の面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新され、また、「面談結果」の項目が“重要事項不同意”という内容を示すコード値等に更新されている。

一方、図４７の「重要説明事項」画面において「同意する」ボタンが押下された場合は、図１９の画面遷移における「説明資料確認」画面に遷移し、販売員２１が顧客２２に対して商品に関連する必要な説明資料の説明を行う（図１９のＳ２０）。図５０は、「説明資料確認」画面の具体例について概要を示した図である。ここでは、対象の商品に関連する説明資料が図１７に示した説明資料ＤＢ１７３に登録されている場合には、その一覧を抽出して表示し、個別にＰＤＦファイル等の内容を参照・閲覧できるようにする。

図５１は、「説明資料確認」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「説明資料確認」画面に遷移中であることを示す“説明資料確認”という内容を示すコード値等に更新されている。

図５０の「説明資料確認」画面において「戻る」ボタンが押下された場合は、図４１の「適合性・合理性判定」画面に戻る。また、「面談終了」ボタンが押下された場合は、図３３（ｂ）に示すような確認のダイアログを表示した上で、面談を終了する。このとき、面談管理ＤＢ１１２の内容は、図示しないが、図４８に示した状況から、図３４に示した場合と同様に、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新され、また、「面談結果」の項目が“面談中断”という内容を示すコード値等に更新される。

図５０の「説明資料確認」画面において「確認しました」ボタンが押下された場合は、図１９の画面遷移における「今後確認」画面に遷移し、販売員２１が顧客２２に対して対象の商品の今後の予想や展開などについて説明し、顧客２２からの確認を得る（図１９のＳ２１）。図５２は、「今後確認」画面の具体例について概要を示した図である。ここでは、例えば、対象の商品が投資信託である場合に、その基準価格の推移をグラフ等によって表示し、矢印の向きによって価格の推移傾向を示すことで、顧客２２が推移傾向を視覚的に把握できるようにする。対象の商品が投資信託以外である場合は、当該画面はスキップする。

図５３は、「今後確認」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が「今後確認」画面に遷移中であることを示す“販売手法確認”という内容を示すコード値等に更新されている。

図５２の「今後確認」画面において「理解しました」ボタンが押下された場合は、図１９の画面遷移における「取引内容確認」画面に遷移し、販売員２１が販売手法について規定に適合しているか（反していないか）を確認する（図１９のＳ２２）。図５４は、「取引内容確認」画面の具体例について概要を示した図である。ここでは、対象の商品や顧客２２に関して、販売手法についての確認事項が図１５に示した質問事項設定ＤＢ１７１などに登録されている場合にはその内容を表示して、販売員２１からの確認の入力を受け付ける。確認事項が登録されていない場合は、当該画面はスキップする。

図５４の「取引内容確認」画面において「面談終了」ボタンが押下された場合は、図３３（ｂ）と同様の確認のダイアログを表示した上で、面談を終了する。図５５は、「取引内容確認」画面に遷移している状況で面談が終了した場合の面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新され、また、「面談結果」の項目が“販売手法確認”という内容を示すコード値等に更新されている。

図５４の「取引内容確認」画面において「面談完了」ボタンが押下された場合は、図１９の画面遷移における「面談完了」画面に遷移し、確認用の書面を出力して取引を完了する（図１９のＳ２３）。図５６は、「面談完了」画面の具体例について概要を示した図である。ここでは、商品名等を表示して面談が完了した旨を表示する。

図５７は、「面談完了」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談進捗」の項目が面談が終了したことを示す“完了”という内容を示すコード値等に更新され、また、「ステータス」の項目が“エラー承認依頼中、確認書待ち、詳細入力中”という内容を示すコード値等に更新されている。

図５６の「面談完了」画面において「確認書出力」ボタンが押下された場合は、面談および取引の内容を示す確認書の帳票を出力する。図５８は、確認書を出力した後の「面談完了」画面の具体例について概要を示した図である。また、図５９は、確認書を出力した状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「ステータス」の項目が“詳細入力中”という内容を示すコード値等に更新されている。図５６もしくは図５８の「面談完了」画面において「面談終了」ボタンが押下された場合は、面談全体を完了する。

上述した一連の処理による面談の後、同じ機会において他の異なる商品についても検討したいという場合もある。この場合、従来技術では、上記の一連の処理を単位としてアプリケーションプログラムが構成されているのが通常であることから、図１９の画面遷移における「手続き確認」画面（図１９のＳ１１）に戻って処理を繰り返すなど、一連の処理を最初から繰り返す必要がある。したがって、例えば、「お客様カード」の確認やリスクプロファイルの実施などの処理を重複して行わなければならない（もしくはスキップするのに手間を要する）という不便さがあった。

そこで本実施の形態では、他の商品についても検討するために面談を継続する場合、一連の処理の最初からではなく、図１９の画面遷移に示すように、「購入商品選択」画面（図１９のＳ１７）に戻って処理を繰り返すよう制御する。すなわち、図５６もしくは図５８の「面談完了」画面において「次の商品手続き」ボタンが押下された場合は、図２０の「手続き確認」画面ではなく、図３８の「購入商品選択」画面に遷移して、商品の選択から処理を繰り返す。

この場合、面談としては新たな面談として取り扱われ、面談管理ＤＢ１１２上では新たなレコードが登録される。顧客２２についての属性情報（「お客様カード」）や、プロファイルの結果については、先の面談時に取得した情報をそのまま用いることができる。そして、複数の商品に係る複数の面談の内容は、案件として案件管理ＤＢ１１１に登録される。

以上に説明した一連の処理は、通常時の基本的な処理の流れであるが、例えば、顧客２２が「火災保険に入りたい」というように、購入対象の商品を最初から希望している場合がある。このような場合、図２１の「購入手続き確認」画面（図１９のＳ１２）で、「当行取扱い商品のお取引（商品指定）」ボタンを押下することで、図１９の画面遷移における「商品指定」画面に遷移し、顧客２２は直ちに火災保険などの商品の指定を行うことができる（図１９のＳ２４）。ここでは、図３８の「購入商品選択」画面と同様の画面を表示して、商品群や商品コード、商品名で検索を行って絞り込まれた商品の一覧から購入対象の商品の情報を受け付ける。

「商品指定」画面で選択された商品が、火災保険や保障性預金などのノンリスク商品の場合は、適合性判定などが不要であることから、図１９に示すように、「お客様カード」の確認や適合性判定などの処理をスキップし、適合性判定、取引経済合理性判定において問題がなかった場合と同様に、図４１の「適合性・合理性判定」画面（図１９のＳ１８）に遷移するものとする。選択された商品がリスク商品の場合は、通常と同様に、図２２の「お客様カード確認・更新」画面（図１９のＳ１３）に遷移する。なお、ノンリスク商品であるために「適合性・合理性判定」画面に遷移した場合は、商品群の選択処理を行っていないため、面談管理ＤＢ１１２の内容は、図４２に示した内容に対して、「商品群」の項目が設定されていない状態となる。

また、顧客２２が保有商品の解約を希望している場合は、図２０の「手続き確認」画面において「お持ちの商品のご解約」ボタンを押下することで、図１９の画面遷移における「解約商品選択」画面に遷移し、顧客２２は、現在保有している商品から解約対象の商品を選択する（図１９のＳ２５）。図６０は、「解約商品選択」画面の具体例について概要を示した図である。ここでは、顧客２２が現在保有している商品の一覧を表示し、顧客２２による解約対象の商品の選択を受け付ける。

図６０の「解約商品選択」画面において「戻る」ボタンが押下された場合は、図２０の「手続き確認」画面に戻る。また、「選択」ボタンが押下された場合は、図１９の画面遷移に示すように、図５４の「取引内容確認」画面（図１９のＳ２２）に遷移する。

図６１は、「取引内容確認」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談番号」の項目に新たに採番された番号が設定され、また、「面談内容」の項目には“解約”という内容を示すコード値等が設定されている。また、「商品種別」および「商品」の各項目には図６０の「解約商品選択」画面で選択された商品の商品種別である“商品種別Ｂ”および当該商品を示す“商品Ｃ”が設定されている。また、「面談進捗」の項目には「取引内容確認」画面に遷移中であることを示す“販売手法確認”という内容を示すコード値等が設定され、「ステータス」の項目には“面談中”という内容を示すコード値等が設定され、「面談結果」の項目には“未登録”という内容を示すコード値等が設定されている。

また、面談完了後の販売員２１が面談の内容を記録する場合は、図２０の「手続き確認」画面において「面談内容の入力」ボタンを押下することで、図１９の画面遷移における「面談内容入力」画面に遷移し、販売員２１は、面談の内容を入力して登録する（図１９のＳ２６）。図６２は、「面談内容入力」画面の具体例について概要を示した図である。ここでは、基本情報や連絡事項、補足事項などに分類して、販売員２１からの面談の内容・結果の情報の入力を受け付ける。

図６３は、「面談内容入力」画面に遷移している状況での面談管理ＤＢ１１２の具体的な内容の例について概要を示した図である。この状況では、「面談番号」の項目に新たに採番された番号が設定され、また、「面談内容」の項目には“その他”という内容を示すコード値等が設定されている。また、「面談進捗」の項目には面談が終了したことを示す“完了”という内容を示すコード値等が設定され、「ステータス」の項目には“詳細入力中”という内容を示すコード値等が設定され、「面談結果」の項目には“未登録”という内容を示すコード値等が設定されている。

以上に説明したように、本発明の一実施の形態である金融商品販売支援システム１によれば、面談の進捗状況や面談内容を面談管理ＤＢ１１２に記録し、画面遷移に応じて内容を更新して管理する。これにより、販売員端末２０上のＷｅｂブラウザを用いた画面表示によって面談の進行を支援するアプリケーションにおいて、画面遷移の戻りや中断時点からの再開などの制御が可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

本発明は、投資信託の窓口販売業務を支援する金融商品販売支援システムおよび金融商品販売支援プログラムに利用可能である。

１…金融商品販売支援システム、２…窓販会社、３…ネットワーク、
１１…面談管理部、１２…案件管理部、１３…設定管理部、
２０…販売員端末、２１…販売員、２２…顧客、
１１１…案件管理ＤＢ、１１２…面談管理ＤＢ、
１２０…会社マスタＤＢ、
１３０…顧客マスタＤＢ、１３１…基本属性設定ＤＢ、１３２…任意属性マスタＤＢ、
１４０…商品マスタＤＢ、１４１…商品設定マスタＤＢ、
１５０…取引明細ＤＢ、
１６１…適合性判定方法ＤＢ、１６２…メッセージ設定ＤＢ、１６３…合理性判定方法ＤＢ、
１７１…質問事項設定ＤＢ、１７２…説明事項設定ＤＢ、１７３…説明資料ＤＢ

Claims (4)

1. 金融機関において販売員による顧客への金融商品の窓口販売に係る業務を支援する金融商品販売支援システムであって、
   対象の前記金融商品の窓口販売に係る前記販売員と前記顧客との面談の状況を含む情報を記録する面談管理情報保持部と、
   前記面談の進行に沿って前記販売員が使用する情報処理端末に所定の画面を表示させるとともに、画面の遷移状況、前記面談のステータス、および前記面談の結果に係る情報を前記面談管理情報保持部に随時記録し、前記情報処理端末から画面の遷移を戻る旨の指示を受けた場合に、前記面談管理情報保持部に記録されている情報に基づく内容によって戻り先に対応する画面を表示させる面談管理部と、を有する、金融商品販売支援システム。
2. 請求項１に記載の金融商品販売支援システムにおいて、
   前記面談管理部は、前記面談が中断され、後に再開する場合に、中断時に前記面談管理情報保持部に記録されていた情報に基づく内容によって、中断時に対応する画面を前記情報処理端末に表示させる、金融商品販売支援システム。
3. 請求項１に記載の金融商品販売支援システムにおいて、
   前記面談管理部は、
   前記面談の進行に沿って、前記面談管理情報保持部に記録する内容に対応する内容を履歴情報として記録し、
   過去の任意の面談について、前記履歴情報に記録されている前記面談管理情報保持部に記録する内容に対応する内容によって、前記任意の面談の際に表示した画面に対応する画面を前記情報処理端末に表示させる、金融商品販売支援システム。
4. 金融機関において販売員による顧客への金融商品の窓口販売に係る業務を支援する金融商品販売支援システムとして機能するようコンピュータに処理を実行させる金融商品販売支援プログラムであって、
   前記金融商品販売支援システムは、対象の前記金融商品の窓口販売に係る前記販売員と前記顧客との面談の状況を含む情報を記録する面談管理情報保持部を有し、
   前記コンピュータに、
   前記面談の進行に沿って前記販売員が使用する情報処理端末に所定の画面を表示させるとともに、画面の遷移状況、前記面談のステータス、および前記面談の結果に係る情報を、前記面談管理情報保持部に随時記録する処理と、
   前記情報処理端末から画面の遷移を戻る旨の指示を受けた場合に、前記面談管理情報保持部に記録されている情報に基づく内容によって戻り先に対応する画面を表示させる処理と、を実行させる、金融商品販売支援プログラム。