(57)【要約】【課題】従来のファミリー把握の手法では正しくファミリーとして把握できない顧客についても、論理的に関連付けてファミリーとして管理する。【解決手段】顧客の属性および口座の情報を含む顧客情報を保持する顧客ＤＢ１３と、複数の顧客のグループからなるファミリーの情報を保持するファミリー管理ＤＢ１４と、営業担当者が有する営業支援端末４０からの要求に応じて、顧客情報を顧客ＤＢ１３に登録し、もしくはファミリーに係る情報をファミリー管理ＤＢ１４に登録し、もしくは顧客ＤＢ１３に登録された顧客情報、およびファミリー管理ＤＢ１４に登録された、顧客が属するファミリーに係る情報を取得して、営業支援端末４０上に表示させる顧客情報管理部１１とを有し、ファミリー管理ＤＢ１４は、ファミリーと、これに属する１つ以上の顧客の口座を特定する情報とを関連付けて保持する。【選択図】図１
2015060344.tif 000002
【特許請求の範囲】
【請求項１】
金融機関の営業担当者による顧客への営業活動を支援する営業支援システムであって、
顧客の属性および口座の情報を含む顧客情報を保持する顧客情報保持部と、
複数の顧客のグループからなるファミリーの情報を保持するファミリー管理情報保持部と、
前記営業担当者が有する営業支援端末からの要求に応じて、前記顧客情報を前記顧客情報保持部に登録し、もしくは前記ファミリーに係る情報を前記ファミリー管理情報保持部に登録し、もしくは前記顧客情報保持部に登録された前記顧客情報、および前記ファミリー管理情報保持部に登録された、当該顧客が属する前記ファミリーに係る情報を取得して、前記営業支援端末上に表示させる顧客情報管理部と、を有し、
前記ファミリー管理情報保持部は、前記ファミリーと、これに属する１つ以上の顧客の口座を特定する情報とを関連付けて保持する、営業支援システム。
【請求項２】
請求項１に記載の営業支援システムにおいて、
前記ファミリー管理情報保持部に保持される、前記ファミリーに属する前記各顧客の口座の情報は、前記顧客の自宅の住所に係る情報、電話番号、姓に係る情報、および前記口座の支店に係る情報のうちいずれか１つ以上が一致していないものが含まれる、営業支援システム。
【請求項３】
請求項１または２に記載の営業支援システムにおいて、
前記顧客情報管理部は、前記営業支援端末から受けた前記顧客情報の参照に係る要求において、前記ファミリーを特定する情報が指定された場合に、指定された前記ファミリーに属する前記各顧客の口座の情報を合算して、前記顧客情報として前記営業支援端末上に表示させる、営業支援システム。
【請求項４】
請求項１〜３のいずれか１項に記載の営業支援システムにおいて、
前記顧客情報管理部は、前記金融機関に口座を有さない者について、見込客として前記顧客情報保持部に登録する、営業支援システム。
【請求項５】
請求項１〜４のいずれか１項に記載の営業支援システムにおいて、
前記顧客情報管理部は、前記顧客情報に含まれる前記顧客の家系図の情報に基づいて、前記顧客が属する前記ファミリーに属する他の顧客の情報を登録する、営業支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、営業担当者の営業活動を支援する技術に関し、特に、証券会社等の金融機関における営業活動を支援する営業支援システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
例えば、証券会社等の金融機関では、営業担当者の営業活動に際して、ＣＲＭ（Customer Relationship Management：顧客関係管理）システム等を用いて顧客情報を管理するとともに、営業担当者が営業活動に携行するタブレット端末などの携帯型端末によって顧客情報や営業資料等を外出先においても参照可能としたり、営業実績を記録したり等の処理を行うＳＦＡ（Sales Force Automation：営業支援システム）が活用され、営業活動の効率化が図られている。
【０００３】
このような分野での技術として、例えば、特開２０１３−１４０６３２号公報（特許文献１）には、指定された条件に基づいて、顧客情報記憶部に記憶されている情報を検索することにより、「大口入金」や「定期満期」等のイベントを検出するイベント情報検出部と、イベントに関する顧客の位置に、そのイベントを示すマークを配置させて、イベント配置地図を作成して営業担当者の端末に表示させるイベント配置地図生成部と、法人顧客とその法人の社員である個人顧客のイベントとの関係を検出し、イベント配置地図のイベント説明部に表示させるイベント関係検出部とを有し、顧客に生じたイベントを地図上に配置させることにより、営業活動の効率を高める営業活動支援システムが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１３−１４０６３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
証券会社では、銀行等とは異なり、例えば、顧客の「大口入金」や「定期満期」などのイベント発生時に当該顧客に対して営業活動を行うだけに限らず、その家族、親族、一族などの一定範囲の近親者（以下ではこれらを「ファミリー」と総称する場合がある）に対して家族営業をするケースも多い。例えば、家族や親族内での「誕生日」や「進学」、「就職」、「結婚」、「出産」等のイベントに際して、兄弟や配偶者、親などに対しても商品購入（口座を有さない場合は口座開設も含む）を勧めたり、相続の際の対応をアドバイスしたりなどの営業活動を行う場合がある。特に、証券会社が顧客の対象とするような富裕層では、例えば、一族経営の企業などの場合には、住所や姓が異なっていても「一族」と認識して営業活動したい場合も多い。
【０００６】
従来、上記のような営業活動の便宜のため、ファミリーとして管理すべき複数の顧客の口座の情報を関連付けて管理するには、例えば、バックオフィスシステムにおいて、口座を保有する顧客の情報のうち、住所や姓、口座の部店や支店（以下ではこれらを「支店」と総称する場合がある）など、通常はファミリー毎に固有であると考えられる各種属性情報がそれぞれ一致していることなどの条件を設定し、当該条件に基づいてファミリーとして管理すべき顧客を判定・抽出して管理するというのが一般的であった。
【０００７】
しかしながら、上記のような従来の手法の場合、ファミリーを正確に把握しようとして条件を詳細に設定すると、判定の際に比較する属性やパラメータが多くなって処理負荷が大きくなるとともに、ファミリーとして把握される条件が厳しくなるため、ファミリーとして管理すべき顧客に漏れが生じてしまう可能性が高くなる。一方で、条件を緩く設定すると、ファミリーとして管理すべきではない顧客までファミリーとして判定されてしまうなどノイズが大きくなってしまう。このように、従来は、顧客について上記のように「一族」などのファミリーとして把握したくても、バックオフィスシステムなどのシステムにより対応することは非常に困難であった。
【０００８】
そこで本発明の目的は、従来のファミリー把握の手法では正しくファミリーとして把握できない顧客についても、論理的に関連付けてファミリーとして管理する営業支援システムを提供することにある。
【０００９】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１０】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１１】
本発明の代表的な実施の形態による営業支援システムは、金融機関の営業担当者による顧客への営業活動を支援するシステムであって、顧客の属性および口座の情報を含む顧客情報を保持する顧客情報保持部と、複数の顧客のグループからなるファミリーの情報を保持するファミリー管理情報保持部と、前記営業担当者が有する営業支援端末からの要求に応じて、前記顧客情報を前記顧客情報保持部に登録し、もしくは前記ファミリーに係る情報を前記ファミリー管理情報保持部に登録し、もしくは前記顧客情報保持部に登録された前記顧客情報、および前記ファミリー管理情報保持部に登録された、当該顧客が属する前記ファミリーに係る情報を取得して、前記営業支援端末上に表示させる顧客情報管理部と、を有し、前記ファミリー管理情報保持部は、前記ファミリーと、これに属する１つ以上の顧客の口座を特定する情報とを関連付けて保持するものである。
【発明の効果】
【００１２】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１３】
すなわち、本発明の代表的な実施の形態によれば、従来のファミリー把握の手法では正しくファミリーとして把握できない顧客についても、論理的に関連付けてファミリーとして管理することが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施の形態である営業支援システムの構成例について概要を示した図である。
【図２】本発明の一実施の形態における顧客ＤＢのデータ構成の例について概要を示した図である。
【図３】（ａ）、（ｂ）は、本発明の一実施の形態におけるファミリー管理ＤＢのデータ構成の例について概要を示した図である。
【図４】本発明の一実施の形態における営業支援端末上に表示される画面例について概要を示した図である。
【図５】本発明の一実施の形態における営業支援端末上に表示される画面例について概要を示した図である。
【図６】本発明の一実施の形態における顧客を検索するための検索条件を入力する画面例について概要を示した図である。
【図７】本発明の一実施の形態における顧客が属するファミリーの情報を表示する画面例について概要を示した図である。
【図８】本発明の一実施の形態における顧客が属するファミリーの情報を表示する画面例について概要を示した図である。
【図９】本発明の一実施の形態におけるファミリーに対して顧客を直接追加する際の登録画面の例について概要を示した図である。
【図１０】本発明の一実施の形態における顧客の家系情報を表示する画面例について概要を示した図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１６】
本発明の一実施の形態である営業支援システムは、証券会社等の金融機関において、営業担当者の営業活動を支援するためのＣＲＭシステムやＳＦＡとしての機能を有する情報処理システムであり、顧客情報を管理するとともに、営業担当者が営業活動に携行するタブレット端末などの携帯型端末によって顧客情報や営業資料等を外出先においても参照可能としたり、営業実績を記録したり等の処理を行うことによって営業活動の効率化を図るシステムである。
【００１７】
本実施の形態では、顧客情報において、バックオフィスシステムにおける顧客管理の体系に関わらず、営業上、ファミリーとして管理すべき複数の顧客の情報を、論理的に関連付けたグループとして管理する。これにより、家族営業等の営業活動を効果的かつ効率的に行うことを可能とするものである。
【００１８】
＜システム構成＞
図１は、本発明の一実施の形態である営業支援システムの構成例について概要を示した図である。営業支援システム１０は、セキュアなネットワークを介して証券会社等において取引処理などの基幹業務を行うバックオフィスシステム２０と接続されている。また、インターネットやイントラネットなどのネットワーク３０を介して証券会社等の営業担当者が保有する情報処理端末である営業支援端末４０が接続されている。
【００１９】
営業支援システム１０は、例えば、サーバ機器や、クラウドコンピューティングサービス上に構築された仮想サーバなどのサーバシステムにより構成され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System：データベース管理システム）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムによって実装される顧客情報管理部１１や営業活動管理部１２などの各部を有する。また、データベースなどにより実装される顧客データベース（ＤＢ）１３、ファミリー管理ＤＢ１４、営業担当者ＤＢ１５、および活動管理ＤＢ１６などの各テーブルを有する。これらの各部やテーブル以外にも図示しない構成を有していてもよく、全体として、証券会社等におけるＣＲＭやＳＦＡとしての各種機能やサービスを実現している。
【００２０】
顧客情報管理部１１は、例えば、バックオフィスシステム２０から得ることができる顧客の基本的な情報の他に、各種の営業上有用な情報についても登録や参照を可能とし、ＣＲＭとしての機能を提供する。これらの顧客情報は、顧客ＤＢ１３に登録されて管理される。各営業担当者は、営業支援端末４０を利用して当該営業支援システム１０上の図示しないＷｅｂサーバプログラム等を介して顧客情報管理部１１にアクセスし、自身もしくは自身が属する組織内の営業担当者がアクセス権を有する顧客について、顧客情報を参照したり、営業支援端末４０にダウンロードして持ち出したり、また、収集・入力した顧客情報を新たに登録したりすることができる。
【００２１】
本実施の形態では、上述したように、家族営業等の営業活動を効果的かつ効率的に行うことを可能とするため、顧客ＤＢ１３において管理する顧客について、営業上、ファミリーとして管理すべき複数の顧客について、論理的に関連付けたグループとして管理する。本実施の形態では、当該グループ（ファミリー）の情報をファミリー管理ＤＢ１４に登録して管理する。
【００２２】
営業活動管理部１２は、営業担当者の営業活動についての予定および実績を管理する機能を有する。営業担当者のマスタ情報は営業担当者ＤＢ１５に登録され管理されており、各営業担当者の活動の予実管理は活動管理ＤＢ１６に登録され管理される。各営業担当者は、営業支援端末４０を利用して当該営業支援システム１０上の図示しないＷｅｂサーバプログラム等を介して営業活動管理部１２にアクセスし、自身もしくは自身が属する組織内の営業担当者の活動予定や実績を参照したり、自身の活動予定や実績を登録したりすることができる。
【００２３】
バックオフィスシステム２０は、証券会社等において取引処理などの基幹業務を行う既存の情報処理システムであり、詳細な説明は省略するが、例えば、ＯＳやＤＢＭＳなどのミドルウェア上で稼働するソフトウェアプログラムによって実装される口座管理部２１、アクセス制御部２２、および取引処理部２３などの各部を有する。また、データベースなどにより実装される口座ＤＢ２４、および取引履歴ＤＢ２５などの各テーブルを有する。これらの各部やテーブル以外にも図示しない構成を有していてもよく、全体として、証券会社等におけるバックオフィスシステムとしての各種機能やサービスを実現している。
【００２４】
口座管理部２１は、顧客の口座についてのマスタ情報を保持する口座ＤＢ２４に対して、口座の情報の登録や更新等の管理を行う機能や参照のための機能を有する。アクセス制御部２２は、営業担当者等が口座ＤＢ２４や取引履歴ＤＢ２５などに保持されている顧客に係る情報にアクセスする際に、営業担当者等の属性や所属する組織などに基づいて設定・決定されるアクセス権に基づいてアクセス制御を行う機能を有する。取引処理部２３は、証券会社における有価証券の売買などの取引処理やその他の基幹業務に係る処理を行う機能を有する。顧客による取引の履歴は、取引履歴ＤＢ２５にログとして記録され、営業支援システム１０から営業情報として参照することが可能である。
【００２５】
営業支援端末４０は、例えば、ノート型ＰＣ（Personal Computer）やタブレット端末などの携帯型端末からなり、営業担当者が営業先などへの外出時に携行して、当該営業支援端末４０に予め営業支援システム１０等からダウンロードしておいた営業情報を参照したり、図示しないＷｅｂブラウザにより外出先からネットワーク３０を介して営業支援システム１０等にアクセスして営業情報を参照したりすることができる。これにより、営業先で顧客に対して状況に応じて様々な営業資料を提示したり、営業担当者が外出先で活動予定や訪問する営業先の情報を確認したり、営業活動の実績を登録して報告したりなどの作業を行うことができ、効果的かつ効率的な営業活動が可能となる。
【００２６】
＜データ構成＞
以下では、本実施の形態において、顧客をファミリーとして管理することを可能とするためのデータ構成について説明する。図２は、営業支援システム１０の顧客ＤＢ１３のデータ構成の例について概要を示した図である。顧客ＤＢ１３は、顧客に係る情報を保持するマスタテーブルであり、例えば、顧客ＩＤ、顧客姓、顧客名、法人フラグ、部店コード、口座番号、口座種別、担当営業担当者ＩＤ、住所、電話番号、生年月日、職業、および家系情報などの各項目を有する。
【００２７】
顧客ＩＤの項目は、保有する口座毎に各顧客を一意に識別するためのＩＤ等の情報を保持する。顧客姓および顧客名の項目は、対象の顧客の姓および名の情報をそれぞれ漢字およびカナによって保持する。法人フラグの項目は、対象の顧客が法人顧客であるか否かを識別するフラグ情報を保持する。法人顧客の場合は、上記の顧客姓の項目に法人の名称を保持する。
【００２８】
部店コードおよび口座番号の各項目は、対象の顧客が保有する口座が管理される部店コードおよび口座番号の情報をそれぞれ保持する。本実施の形態では、営業活動の便宜のために見込み客についても顧客として登録可能とし、その場合はまだ口座を有していないため、これらの項目にはブランク等が設定されるものとする。口座種別の項目は、対象の口座の種別を特定するコード値等の情報を保持する。例えば、いわゆる一般口座か特定口座か、さらに、いわゆるファンドラップサービス等のための専用口座であるか等を特定するコード値等の情報を保持する。一人の顧客は、支店の口座の他に、ＳＭＡ（Separated Managed Account）やファンドラップ口座等の専用口座も含めて複数の口座を保有することができる。
【００２９】
担当営業担当者ＩＤの項目は、対象の顧客および口座について取り扱う担当の営業担当者を特定するＩＤ情報を保持する。このＩＤ情報に基づいて営業担当者ＤＢ１５を参照することで、当該営業担当者に係る各種の情報を得ることができる。住所、電話番号、生年月日、および職業の各項目は、対象の顧客の属性情報として、把握できる限りで、住所、電話番号、生年月日、および職業の情報をそれぞれ保持する。住所には、郵便番号や住所コードの情報を含んでいてもよい。職業についても、コード値等の情報により保持することができる。
【００３０】
家系情報の項目は、対象の顧客を中心とした家系の情報を保持する。例えば、対象の顧客から一定範囲の親等の親族で、当該顧客ＤＢ１３に登録されている顧客についての続柄と顧客ＩＤの項目を保持する。この情報に基づいて、例えば、図１０に示すような家系図を営業支援端末４０上に表示させ、相続の際の対応などを含む家族営業を行う際の営業情報とすることができる。なお、家系情報は参考情報であり、必ずしも正確である必要はなく、全てが網羅されている必要もない。
【００３１】
図３は、営業支援システム１０のファミリー管理ＤＢ１４のデータ構成の例について概要を示した図である。ファミリー管理ＤＢ１４は、ファミリーとして管理すべき複数の顧客を論理的に関連付けたグループとして管理するテーブルであり、例えば、図３（ａ）に示すファミリーマスタＤＢ１４ａと、図３（ｂ）に示すファミリー所属ＤＢ１４ｂの各テーブルからなる。
【００３２】
図３（ａ）のファミリーマスタＤＢ１４ａは、ファミリーのマスタ情報を保持するテーブルであり、例えば、ファミリーＩＤ、ファミリー名、代表口座部店コード、および代表口座番号などの各項目を有する。ファミリーＩＤの項目は、各ファミリーを一意に識別するためのＩＤ等の情報を保持する。ファミリー名の項目は、対象のファミリーの名称やタイトルなどの表示情報を保持する。
【００３３】
代表口座部店コードおよび代表口座番号の各項目は、対象のファミリーにおいて代表となる口座を特定する部店コードおよび口座番号の情報をそれぞれ保持する。例えば、世帯主や、経営者、管理者、その他のファミリーやグループ内での営業上の主要人物を代表者として、当該代表者が保有する代表口座を特定する部店コードおよび口座番号の情報をそれぞれ保持する。ファミリーに属する各顧客のうち誰を代表者とし、代表者が保有する口座のうちいずれを代表口座とするかは、営業上支障がない範囲で営業担当者等が自由に設定することができる。代表者の部店コードおよび口座番号に替えて、図２の顧客ＤＢの例に示した顧客ＩＤによって代表者を特定するようにしてもよい。
【００３４】
図３（ｂ）のファミリー所属ＤＢ１４ｂは、ファミリーに所属する顧客の口座の情報を保持するテーブルであり、例えば、ファミリーＩＤ、部店コード、および口座番号などの各項目を有する。
【００３５】
ファミリーＩＤの項目は、対象のファミリーを特定するファミリーＩＤの情報を保持する。これは、図３（ａ）のファミリーマスタＤＢの例に示したファミリーＩＤと同内容である。部店コードおよび口座番号の各項目は、対象のファミリーに属する顧客の口座を特定する部店コードおよび口座番号の情報をそれぞれ保持する。ファミリーにどの顧客が属するかについても、営業上支障がない範囲で営業担当者等が自由に設定することができる。顧客の部店コードおよび口座番号に替えて、顧客ＩＤによって顧客を特定するようにしてもよい。
【００３６】
このように、本実施の形態では、複数の顧客の口座からなる論理的なグループとしてファミリーを管理するため、従来、バックオフィスシステムにおいてファミリーを管理する際に条件として要求された、住所や姓、口座の支店などの属性情報が不一致であっても、適切にかつ簡易な仕組みでファミリーとして管理することが可能となる。具体的には、例えば、顧客姓（漢字、カナ）、自宅の住所（郵便番号、住所コード、住所）、自宅電話番号、口座の部店コードなど、家族であれば一致していることが多いと考えられる上記の各属性情報のうち、少なくとも１つ以上が不一致であっても、容易にファミリーとして管理することが可能となる。
【００３７】
ファミリー管理ＤＢ１４へのデータの登録、すなわち、グループとしてのファミリーの作成と、これに属する顧客の口座の追加・登録などの操作は、後述するように、例えば、顧客情報管理部１１によって営業支援端末４０上に表示された画面を介して営業担当者等が行うことができる。この場合、営業担当者が直接担当する顧客など、自身がバックオフィスシステム２０においてアクセス権を有する顧客の口座については、当該営業担当者が直接ファミリーに登録することが可能である。アクセス権を有さない顧客の口座については、例えば、管理者権限を有するようなスタッフ部門の担当者やシステム管理者などに依頼して登録してもらうようにしてもよい。
【００３８】
なお、上述の図２、図３で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。その他のテーブルは一般的な内容を保持するものであるため、具体的なデータ構成については説明を省略する。
【００３９】
＜画面および処理の概要＞
図４および図５は、営業担当者の営業活動を支援するために、営業支援システム１０により営業支援端末４０上に表示される画面例について概要を示した図である。営業支援端末４０上では、例えば、画面上部のタブにより、営業担当者単位での情報集約画面（“Dash board”タブ）と、顧客単位での情報集約画面（“Client360”タブ）を切り替えて表示することができる。図４では、“Dash board”タブの画面例を示しており、また、図５では、“Client360”タブの画面例を示している。
【００４０】
“Dash board”タブでは、対象の営業担当者の営業活動全般を支援するための情報を複数のタブによって切り替え可能な画面で表示する。図４の例では、“サマリー”タブの画面例を示しており、サマリー情報として、例えば、各種のイベントが発生している顧客の件数や、該当する顧客のサマリー情報を一覧表示する“リード”欄、現在営業活動中の案件の内容や進捗状況の概要を一覧表示する“案件一覧”欄、営業担当者の活動状況をグラフ表示した“活動状況”欄、および営業担当者の営業日誌のサマリー情報を一覧表示する“営業日誌”欄などを表示している。また、“顧客一覧”や“案件一覧”、“営業日誌”などのタブでは、それぞれ、より詳細な内容を一覧表示する。
【００４１】
このような画面により、営業担当者は、自身が担当する複数の顧客に対する営業活動のために有用な情報の提供を受けたり、営業活動の予実を管理したりすることができる。なお、特定の営業担当者についての情報に限らず、例えば、アクセス権を有する一定範囲の組織（課やグループなど）に属する他の営業担当者についての情報も、個別もしくはサマリーの情報として表示して参照可能としてもよい。
【００４２】
“Client360”タブでは、検索等により選択された顧客、もしくは“Dash board”タブの画面において選択された特定の顧客についての営業活動を支援するための情報を複数のタブによって切り替え可能な画面として表示する。図５の例では、“サマリー”タブの画面例を示しており、サマリー情報として、例えば、対象の顧客の口座番号や氏名や住所等の基本的な属性情報を表示する“基本属性”欄、対象の顧客の保有資産のサマリー情報を一覧表示する“資産”欄、対象の顧客について発生しているイベントの概要を一覧表示する“リード”欄、対象の顧客について現在活動中の案件の概要を一覧表示する“案件一覧”欄、および対象の顧客に対する営業担当者の営業活動の履歴のサマリー情報を一覧表示する“接触履歴”欄などを表示している。また、“収集情報”や“預り資産”、“投資状況”などのタブでは、それぞれ、より詳細な内容を表示する。
【００４３】
このような画面により、営業担当者は、特定の顧客に対する営業活動のために有用な情報の提供を受けたり、当該顧客に係る詳細なデータを参照したりすることができる。
【００４４】
“Client360”タブにおいて参照する顧客は、“Dash board”タブの画面において一覧表示された顧客から選択してもよいし、条件を指定して検索を行って選択してもよい。図６は、顧客を検索するための検索条件を入力する画面例について概要を示した図である。当該画面および図示しない検索結果の一覧を表示する画面は、例えば、図４や図５に示した画面のサイドメニュー等として表示しておいてもよいし、営業担当者の操作によりサブウィンドウとして表示するようにしてもよい。
【００４５】
上述したように、証券会社等においては、特定の顧客について、さらにその家族、親族、一族などのファミリーに対して、「誕生日」や「進学」、「就職」、「結婚」、「出産」等のイベントに際して商品購入を勧めたり、相続の際の対応をアドバイスしたりなどの家族営業を行う場合がある。本実施の形態では、上述の図３で示したファミリー管理ＤＢ１４により、バックオフィスシステム２０における顧客管理体系とは独立して、論理的なグループとして複数の顧客が属するファミリーを登録し管理している。
【００４６】
図７および図８は、顧客が属するファミリーの情報を表示する画面例について概要を示した図である。これらの画面は、例えば、図５に示した“Client360”タブの画面のサイドメニュー等として、“Client360”タブで表示されている顧客が属するファミリーの情報をファミリー管理ＤＢ１４から取得して表示しておいてもよいし、営業担当者の操作によりサブウィンドウとして表示するようにしてもよい。
【００４７】
図７では、一定範囲の家族・親族・一族等をファミリーとして登録している場合の例を示している。ここでは、“鈴木家  顧客”という名称のファミリーに“鈴木  一郎”、“鈴木  花子”、“鈴木  太郎”、…の計６名の顧客が属していることをツリー状の表示により示している。“鈴木  一郎”には星印のマークが付されており、当該ファミリーの代表者であることを示している。また、“鈴木  一郎”は、現在“Client360”タブにおいて選択されて表示されている顧客であり、ファミリー内の他の顧客、およびファミリー名の表示には、これらの顧客の情報を“Client360”タブにおいて直接参照可能とするためにハイパーリンクが設定されていることを示している。
【００４８】
通常、顧客の口座は支店単位で管理されており、セキュリティの観点から、ある支店において管理されている口座の情報は、他の支店から参照することができないようアクセス制限がされる。しかしながら、例えば、ファミリー全員が同じ支店で口座を開設するとは限らず、それぞれが異なる支店で口座を有している場合もあり得る。この場合、複数の顧客について、同じ支店であれば保有資産の状況等についてより詳細な情報を得ることができるが、他の支店であっても、そこに口座を有していて、預かり資産の総額がいくらか程度の情報は把握したいというニーズがある。
【００４９】
そこで、本実施の形態では、例えば、ファミリー名称の“鈴木家  顧客”のハイパーリンクを選択した場合、“Client360”タブでは、個別の顧客の情報に替えて、当該ファミリーに属する顧客（口座）全体での合算の情報を算出して表示するものとする。例えば、“サマリー”タブの“資産”欄では、ファミリー全体での預り資産や保有資産の合算情報を一覧表示する。一覧表示中の個別の項目を選択した場合、各顧客についての詳細な内訳を表示するようにしてもよい。
【００５０】
このとき、営業担当者がファミリー内の他の顧客の口座の情報に対して、バックオフィスシステム２０上アクセス権を有していない場合がある。この場合でも、通常は、対象の口座の詳細な情報については参照することができなくても、口座の有無と預かり資産の総額などの概要情報は参照することができるため、上記のような合算情報を取得して表示することが可能である。営業担当者がアクセス権を有していない口座については、“サマリー”タブにおける一覧表示の各項目を選択不可とし、詳細情報の参照ができないように制御してもよい。資産の合算情報と同様に、“サマリー”タブにおける“リード”欄や“案件一覧”欄についても、ファミリーに属する各顧客についてのイベントや案件の情報を全体でマージして表示する。
【００５１】
一方、同一の顧客であっても、支店の口座と、ＳＭＡやファンドラップ口座などの専用口座を有している場合がある。これらの専用口座は、通常、支店からは把握することができないが、顧客からすると、いずれも同じ証券会社に預けている金銭であり、支店の営業担当者がＳＭＡなどの専用口座の存在を知らないというのでは顧客満足度の低下につながりかねない。そこで、上記の他の支店の口座の場合と同様に、詳細内容まで参照できなくても、専用口座を有していることと、資産総額の情報程度は把握したいというニーズがある。
【００５２】
そこで、本実施の形態では、同一の顧客が複数の口座を有する場合に、これらの口座についても「ファミリー」として管理する。図８では、特定の顧客が保有する複数の口座をファミリーとして登録している場合の例を示している。ここでは、“鈴木家  顧客”という名称のファミリーに、同じ“鈴木  一郎”という顧客名で２つの口座が登録されている。これらの口座は、一方が“特定口座”であり、もう一方が“ファンドラップ口座”であることを示している。以上に示したように、本実施の形態では、ある顧客の口座は、家族・親族・一族等から構成されるファミリーに属する場合と、同一顧客が有する複数種類の口座からなるファミリーに属する場合とがある。
【００５３】
ファミリーに対して顧客（口座）を追加・登録するにはいくつかの手法をとることができる。例えば、上述の図６に示した検索画面により検索した顧客について、ドラッグ操作により図７や図８に示した画面上に移動させてドロップすることで、対象のファミリーに追加することができる。また、図７や図８に示した画面上部に有する登録ボタンにより登録用画面を表示させ、顧客や口座の情報を入力して直接登録するようにしてもよい。図９は、ファミリーに対して顧客を直接追加する際の登録画面の例について概要を示した図である。直接追加できるようにすることにより、例えば、顧客ＤＢ１３に登録されていない見込み客などについてもファミリーとして管理し、営業活動の対象とすることが可能となる。
【００５４】
また、対象の顧客の家系情報に基づいて営業活動の対象とする親族を選択し、ファミリーとして登録することも可能である。図１０は、顧客の家系情報を表示する画面例について概要を示した図である。この画面は、例えば、図５に示した“Client360”タブの画面において、営業担当者の指示に基づいて、新たなタブもしくはサブウィンドウとして表示される。ここでは、顧客ＤＢ１３に保持する当該顧客の家系情報に基づいて、対象の顧客を本人としてグラフィカルに家系図を作成して表示する。
【００５５】
ここで、例えば、グラフィカルに表示されたツリー形式の家系図の各ノードに対応する顧客を、図７や図８に示したファミリーの表示画面にドラッグアンドドロップすることで、対象の顧客をファミリーに追加することができる。また、家系情報に新たなノードを追加したり更新したりする際に、対象のノードを同時にファミリーにも追加等するようにしてもよい。このように、家系図の表示、および家系情報のメンテンナス操作のインタフェースを、ファミリーへの追加や変更などの操作のインタフェースと共用することも可能である。
【００５６】
以上に説明したように、本発明の一実施の形態である営業支援システム１０によれば、顧客情報において、バックオフィスシステム２０における顧客情報の管理体系に関わらず、営業上、ファミリーとして管理すべき複数の顧客の情報を、論理的に関連付けたグループとして管理する。これにより、従来、バックオフィスシステムにおいてファミリーを管理する際に条件として要求された、住所や姓、口座の支店などの属性情報が不一致であっても、適切にかつ簡易な仕組みでファミリーとして管理することが可能となり、営業担当者が家族営業等の営業活動を効果的かつ効率的に行うことが可能となる。
【００５７】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【００５８】
また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【産業上の利用可能性】
【００５９】
本発明は、証券会社等の金融機関における営業活動を支援する営業支援システムに利用可能である。
【符号の説明】
【００６０】
１０…営業支援システム、１１…顧客情報管理部、１２…営業活動管理部、１３…顧客データベース（ＤＢ）、１４…ファミリー管理ＤＢ、１４ａ…ファミリーマスタＤＢ、１４ｂ…ファミリー所属ＤＢ、１５…営業担当者ＤＢ、１６…活動管理ＤＢ、
２０…バックオフィスシステム、２１…口座管理部、２２…アクセス制御部、２３…取引処理部、２４…口座ＤＢ、２５…取引履歴ＤＢ、
３０…ネットワーク、
４０…営業支援端末。
【図１】
2015060344.tif 000003
【図２】
2015060344.tif 000004
【図３】
2015060344.tif 000005
【図４】
2015060344.tif 000006
【図５】
2015060344.tif 000007
【図６】
2015060344.tif 000008
【図７】
2015060344.tif 000009
【図８】
2015060344.tif 000010
【図９】
2015060344.tif 000011
【図１０】
2015060344.tif 000012