代理店向け保険契約支援システム
【課題】
取引対象の商品（サービス）を提供する場合、顧客ニーズを把握することが困難であった。特に、複数の保険を組み合わせて販売する場合や、複数の特約の組み合わせにおいて、顧客ニーズと適合させることが難しくなる。
【解決手段】
本発明では、対話形式で商品に関わるカルテを作成し、その際、カルテには会話などの履歴を対応付けて記憶するものである。また、本発明には、顧客における商品の各項目（性質、側面）に対するニーズの大きさを示す情報と当該取引等の対象となる商品各項目に対するニーズの示す情報を比較して、顧客のそれが大きいものを抽出することも含まれる。この比較は、指定された項目につき、それぞれ顧客のニーズが大きいものを抽出してもよいし、各項目の総和が大きいものを抽出してもよい。また、この際、抽出されたことを端末に出力してもよい。
取引対象の商品（サービス）を提供する場合、顧客ニーズを把握することが困難であった。特に、複数の保険を組み合わせて販売する場合や、複数の特約の組み合わせにおいて、顧客ニーズと適合させることが難しくなる。
【解決手段】
本発明では、対話形式で商品に関わるカルテを作成し、その際、カルテには会話などの履歴を対応付けて記憶するものである。また、本発明には、顧客における商品の各項目（性質、側面）に対するニーズの大きさを示す情報と当該取引等の対象となる商品各項目に対するニーズの示す情報を比較して、顧客のそれが大きいものを抽出することも含まれる。この比較は、指定された項目につき、それぞれ顧客のニーズが大きいものを抽出してもよいし、各項目の総和が大きいものを抽出してもよい。また、この際、抽出されたことを端末に出力してもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、契約や取引等に関する履歴を記録することでの当該契約や取引を支援するための技術に関する。その中でも特に、保険代理店における保険相談、契約に関する。
【背景技術】
【０００２】
保険代理店になどにおける取引、契約においては、法的な義務や契約後のクレームを防止する意味合いから、その商品(サービス)についての十分な説明が求められている。また、保険等では様々な商品を揃えられていることから顧客のニーズに即した商品説明も重要になっている。これらの前提に取引や契約を支援するシステムが提案されている。
【０００３】
例えば、特許文献１では、保険の販売業務に関して紙文書の発生を抑制できると共に、各保険会社及び代理店の業務を実際的に効率化することが可能だという技術として、センターサーバと、センターサーバと接続された複数の保険会社サーバ及び複数の代理店端末とを備え、センターサーバは、各保険会社サーバから送信された保険商品に関する情報を格納しておく記憶手段と、各代理店端末に対して保険商品に関する情報を送信する手段と、代理店端末から特定の保険商品に対する加入リクエストが送信された場合に、当該保険商品の申込書フォームを送信し、必要な顧客情報の入力を促す手段と、代理店端末から送信された申込情報を保険会社サーバに転送し、保険申込の可否を照会する手段と、保険会社サーバから送信された結果情報を代理店端末に転送する手段とを備えた保険業務支援システム、が提供されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１００２０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
近年、銀行等、従来保険代理店ではなかった業者が保険代理店となり、保険を販売できるようになった。その場合、必ずしも保険販売が専門という担当者によって保険商品が販売されるわけではない。よって、窓口担当者の保険商品知識も限られたものとなる場合もありうる。このように窓口担当者が限られた保険商品知識しか持っていない場合、窓口担当者が顧客に勧めた保険が、必ずしも顧客ニーズに適合しているとは限らないという課題がある。特に、複数の保険を組み合わせて販売する場合や、複数の特約の組み合わせにおいて、顧客ニーズと適合させることが難しくなる。
【０００６】
このような課題に対し、現在、制度的な解決策として意向確認書面が保険販売において導入されている。意向確認書面は、購入しようとする保険商品が顧客のニーズに適合しているものかどうかを顧客が契約締結前に最終的に確認することが目的の書面である。しかしながら、最初から窓口担当者が顧客に勧める保険が顧客のニーズに適合していることが、当然ながら望ましい。また、最終的に確認する際に顧客のニーズに適合していない場合、どのような保険であれば顧客のニーズに適合するかを支援できることが望ましい。
【０００７】
前記特許文献１で開示されている、保険代理店における保険契約を支援するシステムは、保険代理店において業務の効率化が主眼となっており、前記したような課題が残っている。
本発明では、上記のような課題を解決可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
この目的を達成するために、本発明では、対話形式で商品に関わるカルテを作成し、その際、カルテには会話などの履歴を対応付けて記憶するものである。また、本発明には、顧客における商品の各項目（性質、側面）に対するニーズの大きさを示す情報と当該取引等の対象となる商品各項目に対するニーズの示す情報を比較して、顧客のそれが大きいものを抽出することも含まれる。この比較は、指定された項目につき、それぞれ顧客のニーズが大きいものを抽出してもよいし、各項目の総和が大きいものを抽出してもよい。また、この際、抽出されたことを端末に出力してもよい。
【０００９】
より詳細な以下の態様も本発明に含まれる。
保険代理店において窓口担当者が操作する代理店窓口端末と、
保険会社もしくはその代理人等が運用する商品データサーバと、
保険会社もしくはその代理人等が運用する契約サーバとが、
ネットワークによって接続され、
前記商品データサーバにネットワーク等によって接続された商品データベースに、保険商品が充足するニーズを数値で表現した保険ニーズテーブルが保存されており、
前記窓口担当者の要求に応じて前記代理店窓口端末が備えるメモリもしくは２次記憶装置に、顧客のニーズを数値で表現した顧客保険ニーズを生成し、
前記代理店窓口端末は、前記保険ニーズテーブルより契約しようとする保険の各項目のニーズの大きさを記録したニーズテーブルを作成し、
前記顧客保険ニーズと前記契約しようとする保険のニーズテーブルとを比較した結果、前記顧客保険ニーズが前記契約しようとする保険のニーズテーブルよりも大きかった場合に、その旨を表示する。
【発明の効果】
【００１０】
本発明によれば窓口担当者が顧客に勧めた商品が、顧客ニーズに適合しているかどうかの参考情報を窓口担当者に提示することができるため、窓口担当者が顧客に勧めた保険が、顧客ニーズに適合していないという状況を減らすことができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態を適用したシステムの概要を例示する図である
【図２】一般的なＰＣの内部構成の一例を示す図である
【図３】本発明の実施の形態の保険代理店契約支援システムの処理の概略を示すフローチャートである
【図４】本発明の実施の形態のニーズ把握支援処理の概略を示すフローチャートである
【図５】本発明の実施の形態の保険設計支援処理の概略を示すフローチャートである
【図６】本発明の実施の形態の設計保険のニーズ充足判定処理の概略を示すフローチャートである
【図７】本発明の実施の形態の簡易意向確認処理の概略を示すフローチャートである
【図８】本発明の実施の形態の詳細意向確認処理の概略を示すフローチャートである
【図９】本発明の実施の形態の保険契約支援処理の概略を示すフローチャートである
【図１０】保険ニーズテーブルを例示した図である
【図１１】顧客保険ニーズ、保険充足ニーズ、保険不足ニーズを例示した図である
【図１２】ニーズ把握支援処理における画面の一例を示した図である
【図１３】保険設計支援処理における画面の一例を示した図である
【図１４】簡易意向確認処理における画面の一例を示した図である
【図１５】詳細意向確認処理における画面の一例を示した図である
【図１６】保険契約支援処理における画面の一例を示した図である
【発明を実施するための形態】
【００１２】
以下、発明を実施するための形態について、図面を用いて説明する。
図１は、システムの概要を例示する図である。
この図において、符号１０１は代理店窓口端末、符号１０２は顧客保険ニーズ、符号１０３は保険充足ニーズ、符号１０４は保険不足ニーズ、符号１０５はネットワーク、符号１０６は商品データサーバ、符号１０７は商品ＤＢ（Ｄａｔａｂａｓｅ）、符号１０８は保険ニーズテーブル、符号１０９は契約サーバである。
【００１３】
代理店窓口端末１０１は代理店窓口の近辺に設置され、窓口担当者が操作することによって、窓口担当者による保険説明、契約業務を支援する端末であり、ネットワーク１０５と接続されている。後記するように、代理店窓口端末１０１にはメモリが備えられている。そして、後記するように、窓口担当者の操作により、顧客保険ニーズ１０２、保険充足ニーズ１０３、保険不足ニーズ１０４がメモリに生成される。顧客保険ニーズ１０２は顧客の保険ニーズを表現するデータである。保険充足ニーズ１０３は提案中の保険がカバーするニーズである。保険不足ニーズ１０４は顧客の保険ニーズと、提案中の保険がカバーするニーズとの差を表現するデータである。ネットワーク１０５は代理店内ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、および代理店と保険会社を接続する回線からなるネットワークであり、代理店窓口端末１０１、商品データサーバ１０６、契約サーバ１０９と接続されている。商品データサーバ１０６は保険会社もしくはその代理人等の敷地内に設置され、代理店窓口端末１０１の要求に応じて保険商品データが格納されている商品ＤＢ１０７にアクセスし、商品に関するデータを代理店窓口端末１０１に返す機能を持つサーバであり、ネットワーク１０５、商品ＤＢ１０７と接続されている。商品ＤＢ１０７は保険商品に関するデータを保管するＤＢであり、保険ニーズテーブル１０８から構成されており、商品データサーバ１０６と接続されている。保険ニーズテーブル１０８は保険ニーズを格納するテーブルである。契約サーバ１０９は保険会社内に設置され、代理店窓口端末１０１の要求に応じ、契約データを受け付けるサーバであり、ネットワーク１０５と接続されている。
【００１４】
代理店窓口端末１０１、商品データサーバ１０６、商品ＤＢ１０７、契約サーバ１０９は一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）によって実現できる。なお、代理店窓口端末１０１は後述するような処理を行うプログラムを一般的なＰＣで実行することによって実現できる。商品データサーバ１０６は代理店窓口端末１０１からの接続を受け付ける一般的なサーバプログラムを一般的なＰＣで実行することによって実現できる。商品ＤＢ１０７は一般的なデータベースプログラムを一般的なＰＣで実行することによって実現できる。契約サーバは一般的なサーバプログラムを一般的なＰＣで実行することによって実現できる。
【００１５】
図２は、一般的なＰＣすなわち、代理店窓口端末１０１等の内部構成の一例を示す図である。
この図において、符号２０１はＣＰＵ、符号２０２はメモリ、符号２０３はネットワークインタフェース、符号２０４はキーボード、符号２０５は時計、符号２０６はスピーカ、符号２０７はディスプレイ、符号２０８はマイク、符号２０９は動画カメラ、符号２１０はハードディスク、符号２１１はインターフェースである。
【００１６】
ＣＰＵ２０１は中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であり、メモリ２０２に記録されているプログラム、またはハードディスク２１０からメモリ２０２に読み出されたプログラムを実行する。なお、プログラムは、必要に応じて、ＰＣが利用可能であり、着脱可能な記憶媒体によって導入されてもよい。この場合、前記記憶媒体を読み取るための装置をインターフェース２１１に接続する。なお、このような前記記憶媒体及びそれを読み取るための装置としては、光ディスクを用いるものが一般に知られており、これを用いることができる。
【００１７】
また、プログラムは、必要に応じて、ネットワークインタフェース２０３によって、通信媒体（通信回線又は通信回線上の搬送波）を介して、ＰＣに導入されてもよい。メモリ２０２はＣＰＵ２０１に実行されるプログラム及びデータを一時的に記録しておくための装置である。ネットワークインタフェース２０３は他のＰＣ等，ＰＣ外にある装置と通信するための装置である。キーボード２０４はＰＣへの指令やデータ入力を行うために、ＰＣの操作者が操作する装置である。時計２０５はＣＰＵ２０１が現在のおよその時間を知るための装置である。スピーカ２０６は信号を音として再生する装置である。ディスプレイ２０７は処理結果等を表示するための装置である。マイク２０８は音を信号としてＰＣ内部に入力する装置である。動画カメラ２０９は動画像を信号としてＰＣ内部に入力する装置である。ハードディスク２１０はプログラム及びデータを格納する装置であり、例えば、不揮発性メモリ等によって構成することができる。この場合、ハードディスク２１０に格納されたプログラム及びデータは、電源がＯＦＦとなった後にＯＮになった場合でも、通常保持される。なお、ハードディスク２１０には、予めオペレーティングシステムが導入されていても良い。このようにすることで、ファイル名を用いてプログラムを指定することなどができるようになる。ここで、オペレーティングシステムとは、計算機の基本ソフトウェアのことであり、一般に広く知られたオペレーティングシステムを用いることができる。インターフェース２１１はＰＣ内の装置を接続するためのものであり、ＣＰＵ２０１、ネットワークインタフェース２０３、キーボード２０４、時計２０５、スピーカ２０６、ディスプレイ２０７、マイク２０８、動画カメラ２０９、ハードディスク２１０がインターフェース２１１を介して接続されている。なお、ＣＰＵ２０１とメモリ２０２は通常インターフェース２１１を介さずに直接接続されているが、インターフェース２１１を介して接続しても良い。
【００１８】
次に、本発明の実施の形態の保険代理店契約支援システムの処理の概略を、フローチャートを用いて説明する。
図３は、保険代理店契約支援システムの処理の概略を示すフローチャートである。図３において、まずステップ３０１で、ニーズ把握支援を行う。この処理の詳細は、図４のニーズ把握支援処理フローを示す図を用いて後記する。
次に、ステップ３０２で保険設計支援を行う。この処理の詳細は、図５の保険設計支援処理フローを示す図を用いて後記する。
【００１９】
次に、ステップ３０３でニーズを充足したかどうか調べる。もしニーズを充足した場合は、ステップ３０４へ進む。もしニーズを充足していない場合は、ステップ３０５へ進む。この処理の詳細は、図６の設計保険のニーズ充足判定処理フローを示す図を用いて後記する。
【００２０】
ステップ３０４は、簡易意向確認を行うための処理である。この処理の詳細は、図７の簡易意向確認処理フローを示す図を用いて後記する。
ステップ３０５は、詳細意向確認を行うための処理である。この処理の詳細は、図８の詳細意向確認処理フローを示す図を用いて後記する。
【００２１】
ステップ３０４もしくはステップ３０５の処理の後、ステップ３０６に進む。ステップ３０６では、ステップ３０４もしくはステップ３０５の処理において顧客同意を得られたかどうか調べる。もし顧客同意を得られなかった場合は、ステップ３０２へ戻る。もし顧客同意を得られた場合は、ステップ３０７へ進む。
【００２２】
ステップ３０７は保険契約処理支援をする処理である。この処理の詳細は、図９の保険契約支援処理フローを示す図を用いて後記する。
以上のステップにより、保険代理店契約支援システムの処理の概略が行われる。
【００２３】
次に、保険代理店契約支援システムの処理の詳細について述べる。
まず、ニーズ把握支援処理について、図４と図１２を用いて述べる。図４はニーズ把握支援処理の概略を示すフローチャートであり、ステップ３０１で行われる処理を詳細に説明したものである。また、図１２はニーズ把握支援処理における画面の一例を示した図である。
【００２４】
先に、図１２について説明する。この図において、符号１２０１はクリック領域（現在の健康）、符号１２０２はクリック領域（将来の健康）、符号１２０３はクリック領域（万一の場合）、符号１２０４はクリック領域（老後の生活）、符号１２０５は終了ボタン、符号１２０６はポインタである。
【００２５】
クリック領域（現在の健康）１２０１は現在の健康に関する保障ニーズを高めるボタンである。クリック領域（将来の健康）１２０２は将来の健康に関する保障ニーズを高めるボタンである。クリック領域（万一の場合）１２０３は万一の場合、すなわち死亡に関する保障ニーズを高めるボタンである。クリック領域（老後の生活）１２０４は老後の生活に関する保障ニーズを高めるボタンである。終了ボタン１２０５はニーズ把握支援を終了する際にクリックするボタンである。ポインタ１２０６はクリックする対象を決定するポインタである。
【００２６】
次に、図４を用いてニーズ把握支援処理について述べる。
ステップ４０１はクリックカウンタを初期化する処理である。ここでクリックカウンタとはクリック領域（現在の健康）１２０１等のクリック領域を何回クリックしたかを計測するためのカウンタであり、クリック領域の個数分ある。図１２の例では４つ存在し、それぞれクリックカウンタ（現在の健康）が３、クリックカウンタ（将来の健康）が６、クリックカウンタ（万一の場合）が１５、クリックカウンタ（老後の生活）が９となっている。クリックカウンタは図１２に示すように対応するクリック領域の近辺、あるいは中に表示しても良い。
ステップ４０２はキーワード表示する処理である。この処理によって、図１２のような画面が表示される。
ステップ４０３からステップ４０５は、図１２の終了ボタン１２０５が押されるまで繰り返される。
【００２７】
ステップ４０３は、終了ボタンがクリックされていないかどうか調べる処理である。もし終了ボタンがクリックされた場合は、ステップ４０６へ進む。そうでなければステップ４０４に進む。
【００２８】
ステップ４０４は、クリック受付をする処理である。図１２のような画面を表示し、クリック領域（現在の健康）１２０１等のクリック領域がクリックされるのを待つ。窓口担当者は、顧客がどのような不安を感じており、どのような保険に入りたがっているのかをヒアリングする。そして、ヒアリングの最中あるいは直後等に、その不安や入りたがっている保険が関連するキーワードが表示されているクリック領域をクリックする。このクリックを受付けるのが、本ステップ４０４である。
【００２９】
ステップ４０５は、クリックされたキーワードのクリックカウンタに１を加算する処理である。この処理の後、ステップ４０３に戻る。
【００３０】
ステップ４０６は、各クリックカウンタを正規化し、顧客保険ニーズとしてメモリに登録する処理である。ここで、正規化とは、例えば最大値を５０とし、それに比例するように各クリックカウンタの値を増減させることである。一例として、図１２のように、クリックカウンタ（現在の健康）が３、クリックカウンタ（将来の健康）が６、クリックカウンタ（万一の場合）が１５、クリックカウンタ（老後の生活）が９であるときに、終了ボタン１２０５をクリックしたとする。クリックカウンタの最大値はクリックカウンタ（万一の場合）であるから、これを５０にするために、各クリックカウンタを５０／１５倍する。すると、クリックカウンタ（現在の健康）は１０、クリックカウンタ（将来の健康）は２０、クリックカウンタ（万一の場合）は５０、クリックカウンタ（老後の生活）は３０となる。これを顧客保険ニーズとしてメモリに登録する。
【００３１】
図１１に、顧客保険ニーズを示す。なお、これは後述する保険充足ニーズと保険不足ニーズも例示した図である。
この図において、符号１１０１は現在の健康、符号１１０２は将来の健康、符号１１０３は万一の場合、符号１１０４は老後の生活、符号１０２は顧客保険ニーズ、符号１０３は保険充足ニーズ、符号１０４は保険不足ニーズである。
現在の健康１１０１は現在の健康に関する保障ニーズの高さを表すフィールドである。将来の健康１１０２は将来の健康に関する保障ニーズの高さを表すフィールドである。万一の場合１１０３は万一の場合、すなわち死亡に関する保障ニーズの高さを表すフィールドである。老後の生活１１０４は老後の生活に関する保障ニーズの高さを表すフィールドである。このように顧客保険ニーズが、各フィールドと関連づけられた形式で、代理店窓口端末のメモリ２０２に記録される。なお、顧客保険ニーズは代理店窓口端末のハードディスク２１０に記録されても良い。この場合、顧客保険ニーズを使う際には、顧客保険ニーズを適宜ハードディスク２１０からメモリ２０２に読み出す。
【００３２】
次に、保険代理店契約支援システムの処理の、保険設計支援処理の詳細について、図５の保険設計支援処理の概略を示すフローチャートと、図１３の保険設計支援処理画面を示す図を示す図を用いて説明する。なお、この処理はステップ３０２で行われる処理である。
【００３３】
先に、保険設計支援処理画面について、図１３に示した画面例を用いて説明する。
この図において、符号１３０１は契約者情報欄、符号１３０２は現在プラン欄、符号１３０３は保険ニーズ表示欄、符号１３０４はお勧め保険表示欄、符号１３０５は保険設計欄、符号１３０６は更新ボタン、符号１３０７は終了ボタンである。
【００３４】
契約者情報欄１３０１は契約者情報を入力、確認するための欄である。現在プラン欄１３０２は現在申し込もうとしている保険プランの内容概略が表示される欄である。保険ニーズ表示欄１３０３は顧客保険ニーズと、現在までの保険プランにおける保険充足ニーズを表示する欄である。お勧め保険表示欄１３０４はお勧め保険を表示する欄である。保険設計欄１３０５は保険プランに追加する新たな保険を設計する欄である。更新ボタン１３０６は現在までの保険プランに新たに設計した保険を追加する際にクリックするボタンである。終了ボタン１３０７は保険設計支援処理を終了する際にクリックするボタンである。
【００３５】
次に、保険設計支援処理の概略について図５を用いて説明する。
ステップ５０１は、保険不足ニーズに顧客保険ニーズを代入する処理である。保険不足ニーズは図１１の保険不足ニーズ１０４で示すように、顧客保険ニーズ１０２と同じフィールドを持つデータである。まず、初期化処理として、保険不足ニーズの各フィールドを、顧客保険ニーズの各フィールドと同じにしておく。
【００３６】
次に、ステップ５０２で保険充足ニーズを初期化する。保険充足ニーズは図１１の保険充足ニーズ１０３で示すように、顧客保険ニーズ１０２と同じフィールドを持つデータである。まず、初期化処理として、保険充足ニーズの各フィールドを０にしておく。
【００３７】
次に、終了ボタン１３０７をクリックすることによる終了指示があるまで、ステップ５０３からステップ５０７を繰り返す。
ステップ５０３は、終了指示があったかどうか(終了指示を受付けたかどうか)を調べる処理である。もし終了指示があれば、ステップ５０８へ進む。そうでなければ、ステップ５０４の処理に進み、ステップ５０４からステップ５０７の処理を繰り返す。
【００３８】
ステップ５０４は、商品データサーバ１０６にアクセスし、保険ニーズテーブル１０８を参照し、保険不足ニーズ１０４中で値が高いフィールドにおいて、保険ニーズの値が高くなっている保険を表示する処理である。図１１の例では、お勧め保険表示欄１３０４にこの保険ニーズの値が高くなっている保険が表示されている。また、その他図１１に示されているような他の画面要素もこのステップで表示される。
例えば、保険ニーズ表示欄１３０３には顧客保険ニーズ１０２と保険充足ニーズ１０３を表示する箇所があるので、それぞれ表示する。また、契約者情報欄１３０１や現在プラン欄１３０２も表示する。なお、それぞれまだデータが入力されていない場合は空白としても良い。
【００３９】
ステップ５０５は、保険種別、保険金額等の入力を受け付け、保険設計する処理である。入力は、窓口担当者もしくは顧客が代理店窓口端末１０１のキーボード２０４を用いて、保険設計欄１３０５や契約者情報欄１３０１に入力する。 入力後、更新ボタン１３０６が押されると、入力したデータを受け付ける。契約者情報欄１３０１に入力された情報は契約者情報として代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に記録される。また、保険設計欄１３０５に入力された情報は現在プランに追加され、代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に記録される。また、現在プラン欄１３０２に追加された保険を表示する。なお、図示していないが、現在プラン欄１３０２の保険の修正等を行っても良い。これは、現在プラン欄１３０２に表示されている修正したい保険をクリックすると、保険設計欄１３０５にその保険が表示され、その保険の保険ニーズを保険充足ニーズ１０３から減算するようにすればよい。なお、保険ニーズの検索はステップ５０６で述べるような方法をとる。
【００４０】
ステップ５０６は保険不足ニーズ１０４の各フィールドから、利用した保険の保険ニーズの各フィールドを減算する処理である。なお、ステップ５０５、ステップ５０６、ステップ５０７で用いる保険ニーズは、商品データサーバ１０６にネットワーク１０５を介してアクセスし、保険設計欄１３０５に入力された保険名等をもとに、商品ＤＢ１０７を参照して得ることができる。
【００４１】
ステップ５０７は、保険充足ニーズ１０３の各フィールドに、利用した保険の保険ニーズの各フィールドを加算する処理である。ステップ５０７の処理の後、ステップ５０３に戻る。
【００４２】
ステップ５０８は、保険不足ニーズ１０４、保険充足ニーズ１０３をメモリ２０２もしくはハードディスク２１０に記録し、保険設計支援処理後も使えるようにする処理である。
以上で、保険設計支援処理フローの概略を終了する。
【００４３】
次に、ステップ３０３の設計保険のニーズ充足判定処理の概略を、図６の設計保険のニーズ充足判定処理フローを示す図を用いて説明する。
【００４４】
ステップ６０１は、保険不足ニーズ１０４の各フィールドにおいて、閾値を上回るフィールドがあるかどうか調べる処理である。もし保険不足ニーズ１０４の各フィールドにおいて、閾値を上回るフィールドがある場合は、ステップ６０２へ進む。
【００４５】
もし保険不足ニーズ１０４の各フィールドにおいて、閾値を上回るフィールドがない場合は、ステップ６０３へ進む。ここで、閾値はあらかじめ決定しておき、代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておくべきものである。例えば１０から５０までの任意の数値が典型例としてあるが、０もしくは正の他の数値をとっても良い。この数値は、商品データサーバ１０６のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３を実行する前にネットワーク１０５を通じて代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しても良い。
【００４６】
ステップ６０２は、ニーズ充足せずと判定する処理である。すなわち、ステップ６０１で、閾値の方が小さい場合、ニーズ充足せずと判定する。なお、この判定結果は代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３以降の処理で参照できるようにしておく。図３で述べたように、この処理の後、ステップ３０５に進む。
【００４７】
ステップ６０３は、保険充足ニーズ１０３中の最大値を与えるフィールドと顧客保険ニーズ１０２中の最大値を与えるフィールドが異なるかどうか調べる処理である。もし保険充足ニーズ１０３中の最大値を与えるフィールドと顧客保険ニーズ１０２中の最大値を与えるフィールドが異なる場合は、ステップ６０４へ進む。もし保険充足ニーズ１０３中の最大値を与えるフィールドと顧客保険ニーズ１０２中の最大値を与えるフィールドが同一の場合は、ステップ６０５へ進む。
【００４８】
ステップ６０４は、希望に相違している可能性があり、ニーズ充足せずと判定する処理である。すなわち、ステップ６０３で、フィールドが異なる場合、ニーズ充足せずと判定する。なお、この判定結果は代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３以降の処理で参照できるようにしておく。図３で述べたように、この処理の後、ステップ３０５に進む。
【００４９】
ステップ６０５は、ニーズ充足と判定する処理である。すなわち、ステップ６０３で、フィールドが一致する場合、ニーズ充足すると判定する。なお、この判定結果は代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３以降の処理で参照できるようにしておく。図３で述べたように、この処理の後、ステップ３０４に進む。
以上で、ステップ３０３の設計保険のニーズ充足判定処理が、概略終了する。
【００５０】
次に、ステップ３０４の簡易意向確認処理について、概略を図７の簡易意向確認処理フローを示す図と、図１４の簡易意向確認処理画面を示す図を用いて説明する。まず、図１４の簡易意向確認処理画面について説明する。
【００５１】
図１４は、簡易意向確認処理における画面の一例を示した図である。
この図において、符号１４０１は契約者情報欄、符号１４０２は保険ニーズ表示欄、符号１４０３は保険設計欄、符号１４０４はやりなおしボタン、符号１４０５は確認ボタンである。
【００５２】
契約者情報欄１４０１は、契約者情報、被保険者情報を表示する欄である。保険ニーズ表示欄１４０２は顧客保険ニーズ１０２、保険充足ニーズ１０３を表示する欄である。保険設計欄１４０３は保険プランに追加する新たな保険を設計する欄である。やりなおしボタン１４０４は、保険設計をやり直す際に、このやり直しを操作者が指示（クリック）するためのボタンである。確認ボタン１４０５は、操作者が確認処理の終了を、クリックにより指示するためのボタンである。
【００５３】
次に、本発明の実施の形態の簡易意向確認処理の概略を図７に示すフローチャートを用いて説明する。
【００５４】
ステップ７０１は、意向確認画面を表示する処理である。意向確認画面は、例えば、図１４に示すようなものである。この画面を見ながら、窓口担当者と顧客は現在契約しようとしている保険が顧客のニーズを満たしていることを確認することができる。
【００５５】
ステップ７０２は、顧客同意を取得する処理である。顧客の同意は、例えば顧客が意向確認書面に対し署名した内容を受付ける方法や、代理店窓口端末１０１のマイク２０８や動画カメラ２０９で顧客が意向を確認している旨を発言しているのを録画録音する方法や、代理店窓口端末１０１に一般的に市場にて販売されているペンパッドを接続し、そのペンパッドに対し署名した内容を受付ける等の方法で取得できる。意向確認したのち、確認ボタン１４０５をクリックして簡易意向確認処理を終了する。なお、確認ボタン１４０５を顧客にクリックしてもらうことで簡易意向確認とすることもできる。
以上で、簡易意向確認処理が概略終了する。
【００５６】
次に、ステップ３０５の詳細意向確認をする処理について、図８の詳細意向確認処理フローを示す図と、図１５の詳細意向確認処理画面を示す図を用いて説明する。
【００５７】
まず、図１５の詳細意向確認処理における画面の一例を示した図について説明する。この図において、符号１５０１は詳細意向確認欄である。詳細意向確認欄１５０１は顧客保険ニーズ１０２と保険充足ニーズ１０３をもとに、特に確認すべき点を表示する欄である。その他の符号は図１４の符号と同一であり、図１４と同様の欄である。
【００５８】
次に、本発明の実施の形態の詳細意向確認処理の概略について、図８のフローチャートを用いて説明する。
【００５９】
ステップ８０１は、ステップ６０４において希望に相違している可能性ありと判定したかどうか調べる処理である。もし希望に相違している可能性ありと判定した場合は、ステップ８０２へ進む。もし希望に相違している可能性ありと判定していない場合は、ステップ８０３へ進む。
【００６０】
ステップ８０２は、商品データサーバにアクセスし、保険ニーズテーブルを検索し、保険ニーズの各フィールドのうち最大値を与えるフィールドが、顧客保険ニーズの各フィールドのうち最大値を与えるフィールドと一致する保険を再考候補保険とし、その保険ニーズをメモリに記録する処理である。なお、再考候補保険がすでに提案中の保険に含まれている場合は再考候補保険を空とする。
ステップ８０３は保険不足ニーズが正であるフィールド内の各フィールドを取り出す処理である。もし、要素があれば、ステップ８０４へ進む。各要素に対する処理の後、ステップ８０５へ進む
ステップ８０４は、商品データサーバにアクセスし、保険ニーズテーブルを検索し、処理対象フィールドの値が保険不足ニーズよりも大きい保険を再考候補保険に追加し、その保険ニーズをメモリに記録する処理である。なお、追加する保険がすでに提案中の保険に含まれている場合は何もしない。
【００６１】
ステップ８０５は、顧客保険ニーズ１０２、保険充足ニーズ、契約しようとする保険、再考候補保険を表示する処理である。表示画面は、図１５に示すようなものであり、例えば図１５の例では、顧客保険ニーズ１０２の老後の生活が３０であるのに対し、提案中の保険充足ニーズ１０３の老後の生活が１０と下回っているため、保険ニーズ表示欄１４０２で警告が表示されている。そして、詳細意向確認欄で老後の生活ニーズを満たしていない可能性がある旨が表示されている。また、図１５の例では、顧客保険ニーズ１０２の最高値が万一の場合の５０であるのに対し、提案中の保険充足ニーズ１０３では最高値が将来の健康の８０となっているため、詳細意向確認欄でその旨の警告を表示する。窓口担当者と顧客はこれを見ながら、本当に提案中の保険で顧客のニーズを満たせるか、確認することができる。
【００６２】
ステップ８０６は、契約続行意志表示ありかどうか判定する処理である。もし契約続行意志表示ありであれば、ステップ８０７へ進む。もし契約続行意志表示ありでなければ、終了する。
【００６３】
ステップ８０７は顧客同意を取得する処理である。これはステップ７０２と同様の処理で実行できる。
以上で、詳細意向確認処理が概略終了する。
【００６４】
最後に、ステップ３０７の保険契約支援処理の詳細について、図９の保険契約支援処理フローを示す図と、図１６の保険契約支援処理画面を示す図を用いて説明する。まず、図１６の保険契約支援処理における画面の一例について説明する。
この図において、符号１６０１は銀行口座入力欄、符号１６０２は保留ボタン、符号１６０３は契約ボタンである。
銀行口座入力欄１６０１は保険料引き落としのための銀行口座を入力する欄である。保留ボタン１６０２は契約を保留し、終了する際にクリックするボタンである。契約ボタン１６０３は契約し、契約データを契約サーバ１０９に送信する際にクリックするボタンである。
【００６５】
次に、図９の保険契約支援処理の概略を示すフローチャートについて説明する。
ステップ９０１は、契約データの不足部分の入力を要求する処理である。これは、例えば銀行口座入力欄１６０１に保険料引き落としのための銀行口座を入力する等の処理が該当する。
【００６６】
ステップ９０２は、契約サーバ１０９にアクセスし、入力された契約データをネットワーク１０５を介して契約サーバ１０９に送信する処理である。もちろん、この前には顧客の最終確認が必要であり、その確認はステップ７０２で用いたような方法で実行できる。
以上で、保険契約支援処理についての説明を終わる。
【符号の説明】
【００６７】
１０１…代理店窓口端末
１０２…顧客保険ニーズ
１０３…保険充足ニーズ
１０４…保険不足ニーズ
１０５…ネットワーク
１０６…商品データサーバ
１０７…商品ＤＢ
１０８…保険ニーズテーブル
１０９…契約サーバ
２０１…ＣＰＵ
２０２…メモリ
２０３…ネットワークインタフェース
２０４…キーボード
２０５…時計
２０６…スピーカ
２０７…ディスプレイ
２０８…マイク
２０９…動画カメラ
２１０…ハードディスク
２１１…インターフェース
１２０１…クリック領域（現在の健康）
１２０２…クリック領域（将来の健康）
１２０３…クリック領域（万一の場合）
１２０４…クリック領域（老後の生活）
１２０５…終了ボタン
１２０６…ポインタ
１３０１…契約者情報欄
１３０２…現在プラン欄
１３０３…保険ニーズ表示欄
１３０４…お勧め保険表示欄
１３０５…保険設計欄
１３０６…更新ボタン
１３０７…終了ボタン
１４０１…契約者情報欄
１４０２…保険ニーズ表示欄
１４０３…保険設計欄
１４０４…やりなおしボタン
１４０５…確認ボタン
１５０１…詳細意向確認欄
１６０１…銀行口座入力欄
１６０２…保留ボタン
１６０３…契約ボタン
【技術分野】
【０００１】
本発明は、契約や取引等に関する履歴を記録することでの当該契約や取引を支援するための技術に関する。その中でも特に、保険代理店における保険相談、契約に関する。
【背景技術】
【０００２】
保険代理店になどにおける取引、契約においては、法的な義務や契約後のクレームを防止する意味合いから、その商品(サービス)についての十分な説明が求められている。また、保険等では様々な商品を揃えられていることから顧客のニーズに即した商品説明も重要になっている。これらの前提に取引や契約を支援するシステムが提案されている。
【０００３】
例えば、特許文献１では、保険の販売業務に関して紙文書の発生を抑制できると共に、各保険会社及び代理店の業務を実際的に効率化することが可能だという技術として、センターサーバと、センターサーバと接続された複数の保険会社サーバ及び複数の代理店端末とを備え、センターサーバは、各保険会社サーバから送信された保険商品に関する情報を格納しておく記憶手段と、各代理店端末に対して保険商品に関する情報を送信する手段と、代理店端末から特定の保険商品に対する加入リクエストが送信された場合に、当該保険商品の申込書フォームを送信し、必要な顧客情報の入力を促す手段と、代理店端末から送信された申込情報を保険会社サーバに転送し、保険申込の可否を照会する手段と、保険会社サーバから送信された結果情報を代理店端末に転送する手段とを備えた保険業務支援システム、が提供されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１００２０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
近年、銀行等、従来保険代理店ではなかった業者が保険代理店となり、保険を販売できるようになった。その場合、必ずしも保険販売が専門という担当者によって保険商品が販売されるわけではない。よって、窓口担当者の保険商品知識も限られたものとなる場合もありうる。このように窓口担当者が限られた保険商品知識しか持っていない場合、窓口担当者が顧客に勧めた保険が、必ずしも顧客ニーズに適合しているとは限らないという課題がある。特に、複数の保険を組み合わせて販売する場合や、複数の特約の組み合わせにおいて、顧客ニーズと適合させることが難しくなる。
【０００６】
このような課題に対し、現在、制度的な解決策として意向確認書面が保険販売において導入されている。意向確認書面は、購入しようとする保険商品が顧客のニーズに適合しているものかどうかを顧客が契約締結前に最終的に確認することが目的の書面である。しかしながら、最初から窓口担当者が顧客に勧める保険が顧客のニーズに適合していることが、当然ながら望ましい。また、最終的に確認する際に顧客のニーズに適合していない場合、どのような保険であれば顧客のニーズに適合するかを支援できることが望ましい。
【０００７】
前記特許文献１で開示されている、保険代理店における保険契約を支援するシステムは、保険代理店において業務の効率化が主眼となっており、前記したような課題が残っている。
本発明では、上記のような課題を解決可能な技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
この目的を達成するために、本発明では、対話形式で商品に関わるカルテを作成し、その際、カルテには会話などの履歴を対応付けて記憶するものである。また、本発明には、顧客における商品の各項目（性質、側面）に対するニーズの大きさを示す情報と当該取引等の対象となる商品各項目に対するニーズの示す情報を比較して、顧客のそれが大きいものを抽出することも含まれる。この比較は、指定された項目につき、それぞれ顧客のニーズが大きいものを抽出してもよいし、各項目の総和が大きいものを抽出してもよい。また、この際、抽出されたことを端末に出力してもよい。
【０００９】
より詳細な以下の態様も本発明に含まれる。
保険代理店において窓口担当者が操作する代理店窓口端末と、
保険会社もしくはその代理人等が運用する商品データサーバと、
保険会社もしくはその代理人等が運用する契約サーバとが、
ネットワークによって接続され、
前記商品データサーバにネットワーク等によって接続された商品データベースに、保険商品が充足するニーズを数値で表現した保険ニーズテーブルが保存されており、
前記窓口担当者の要求に応じて前記代理店窓口端末が備えるメモリもしくは２次記憶装置に、顧客のニーズを数値で表現した顧客保険ニーズを生成し、
前記代理店窓口端末は、前記保険ニーズテーブルより契約しようとする保険の各項目のニーズの大きさを記録したニーズテーブルを作成し、
前記顧客保険ニーズと前記契約しようとする保険のニーズテーブルとを比較した結果、前記顧客保険ニーズが前記契約しようとする保険のニーズテーブルよりも大きかった場合に、その旨を表示する。
【発明の効果】
【００１０】
本発明によれば窓口担当者が顧客に勧めた商品が、顧客ニーズに適合しているかどうかの参考情報を窓口担当者に提示することができるため、窓口担当者が顧客に勧めた保険が、顧客ニーズに適合していないという状況を減らすことができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態を適用したシステムの概要を例示する図である
【図２】一般的なＰＣの内部構成の一例を示す図である
【図３】本発明の実施の形態の保険代理店契約支援システムの処理の概略を示すフローチャートである
【図４】本発明の実施の形態のニーズ把握支援処理の概略を示すフローチャートである
【図５】本発明の実施の形態の保険設計支援処理の概略を示すフローチャートである
【図６】本発明の実施の形態の設計保険のニーズ充足判定処理の概略を示すフローチャートである
【図７】本発明の実施の形態の簡易意向確認処理の概略を示すフローチャートである
【図８】本発明の実施の形態の詳細意向確認処理の概略を示すフローチャートである
【図９】本発明の実施の形態の保険契約支援処理の概略を示すフローチャートである
【図１０】保険ニーズテーブルを例示した図である
【図１１】顧客保険ニーズ、保険充足ニーズ、保険不足ニーズを例示した図である
【図１２】ニーズ把握支援処理における画面の一例を示した図である
【図１３】保険設計支援処理における画面の一例を示した図である
【図１４】簡易意向確認処理における画面の一例を示した図である
【図１５】詳細意向確認処理における画面の一例を示した図である
【図１６】保険契約支援処理における画面の一例を示した図である
【発明を実施するための形態】
【００１２】
以下、発明を実施するための形態について、図面を用いて説明する。
図１は、システムの概要を例示する図である。
この図において、符号１０１は代理店窓口端末、符号１０２は顧客保険ニーズ、符号１０３は保険充足ニーズ、符号１０４は保険不足ニーズ、符号１０５はネットワーク、符号１０６は商品データサーバ、符号１０７は商品ＤＢ（Ｄａｔａｂａｓｅ）、符号１０８は保険ニーズテーブル、符号１０９は契約サーバである。
【００１３】
代理店窓口端末１０１は代理店窓口の近辺に設置され、窓口担当者が操作することによって、窓口担当者による保険説明、契約業務を支援する端末であり、ネットワーク１０５と接続されている。後記するように、代理店窓口端末１０１にはメモリが備えられている。そして、後記するように、窓口担当者の操作により、顧客保険ニーズ１０２、保険充足ニーズ１０３、保険不足ニーズ１０４がメモリに生成される。顧客保険ニーズ１０２は顧客の保険ニーズを表現するデータである。保険充足ニーズ１０３は提案中の保険がカバーするニーズである。保険不足ニーズ１０４は顧客の保険ニーズと、提案中の保険がカバーするニーズとの差を表現するデータである。ネットワーク１０５は代理店内ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、および代理店と保険会社を接続する回線からなるネットワークであり、代理店窓口端末１０１、商品データサーバ１０６、契約サーバ１０９と接続されている。商品データサーバ１０６は保険会社もしくはその代理人等の敷地内に設置され、代理店窓口端末１０１の要求に応じて保険商品データが格納されている商品ＤＢ１０７にアクセスし、商品に関するデータを代理店窓口端末１０１に返す機能を持つサーバであり、ネットワーク１０５、商品ＤＢ１０７と接続されている。商品ＤＢ１０７は保険商品に関するデータを保管するＤＢであり、保険ニーズテーブル１０８から構成されており、商品データサーバ１０６と接続されている。保険ニーズテーブル１０８は保険ニーズを格納するテーブルである。契約サーバ１０９は保険会社内に設置され、代理店窓口端末１０１の要求に応じ、契約データを受け付けるサーバであり、ネットワーク１０５と接続されている。
【００１４】
代理店窓口端末１０１、商品データサーバ１０６、商品ＤＢ１０７、契約サーバ１０９は一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）によって実現できる。なお、代理店窓口端末１０１は後述するような処理を行うプログラムを一般的なＰＣで実行することによって実現できる。商品データサーバ１０６は代理店窓口端末１０１からの接続を受け付ける一般的なサーバプログラムを一般的なＰＣで実行することによって実現できる。商品ＤＢ１０７は一般的なデータベースプログラムを一般的なＰＣで実行することによって実現できる。契約サーバは一般的なサーバプログラムを一般的なＰＣで実行することによって実現できる。
【００１５】
図２は、一般的なＰＣすなわち、代理店窓口端末１０１等の内部構成の一例を示す図である。
この図において、符号２０１はＣＰＵ、符号２０２はメモリ、符号２０３はネットワークインタフェース、符号２０４はキーボード、符号２０５は時計、符号２０６はスピーカ、符号２０７はディスプレイ、符号２０８はマイク、符号２０９は動画カメラ、符号２１０はハードディスク、符号２１１はインターフェースである。
【００１６】
ＣＰＵ２０１は中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であり、メモリ２０２に記録されているプログラム、またはハードディスク２１０からメモリ２０２に読み出されたプログラムを実行する。なお、プログラムは、必要に応じて、ＰＣが利用可能であり、着脱可能な記憶媒体によって導入されてもよい。この場合、前記記憶媒体を読み取るための装置をインターフェース２１１に接続する。なお、このような前記記憶媒体及びそれを読み取るための装置としては、光ディスクを用いるものが一般に知られており、これを用いることができる。
【００１７】
また、プログラムは、必要に応じて、ネットワークインタフェース２０３によって、通信媒体（通信回線又は通信回線上の搬送波）を介して、ＰＣに導入されてもよい。メモリ２０２はＣＰＵ２０１に実行されるプログラム及びデータを一時的に記録しておくための装置である。ネットワークインタフェース２０３は他のＰＣ等，ＰＣ外にある装置と通信するための装置である。キーボード２０４はＰＣへの指令やデータ入力を行うために、ＰＣの操作者が操作する装置である。時計２０５はＣＰＵ２０１が現在のおよその時間を知るための装置である。スピーカ２０６は信号を音として再生する装置である。ディスプレイ２０７は処理結果等を表示するための装置である。マイク２０８は音を信号としてＰＣ内部に入力する装置である。動画カメラ２０９は動画像を信号としてＰＣ内部に入力する装置である。ハードディスク２１０はプログラム及びデータを格納する装置であり、例えば、不揮発性メモリ等によって構成することができる。この場合、ハードディスク２１０に格納されたプログラム及びデータは、電源がＯＦＦとなった後にＯＮになった場合でも、通常保持される。なお、ハードディスク２１０には、予めオペレーティングシステムが導入されていても良い。このようにすることで、ファイル名を用いてプログラムを指定することなどができるようになる。ここで、オペレーティングシステムとは、計算機の基本ソフトウェアのことであり、一般に広く知られたオペレーティングシステムを用いることができる。インターフェース２１１はＰＣ内の装置を接続するためのものであり、ＣＰＵ２０１、ネットワークインタフェース２０３、キーボード２０４、時計２０５、スピーカ２０６、ディスプレイ２０７、マイク２０８、動画カメラ２０９、ハードディスク２１０がインターフェース２１１を介して接続されている。なお、ＣＰＵ２０１とメモリ２０２は通常インターフェース２１１を介さずに直接接続されているが、インターフェース２１１を介して接続しても良い。
【００１８】
次に、本発明の実施の形態の保険代理店契約支援システムの処理の概略を、フローチャートを用いて説明する。
図３は、保険代理店契約支援システムの処理の概略を示すフローチャートである。図３において、まずステップ３０１で、ニーズ把握支援を行う。この処理の詳細は、図４のニーズ把握支援処理フローを示す図を用いて後記する。
次に、ステップ３０２で保険設計支援を行う。この処理の詳細は、図５の保険設計支援処理フローを示す図を用いて後記する。
【００１９】
次に、ステップ３０３でニーズを充足したかどうか調べる。もしニーズを充足した場合は、ステップ３０４へ進む。もしニーズを充足していない場合は、ステップ３０５へ進む。この処理の詳細は、図６の設計保険のニーズ充足判定処理フローを示す図を用いて後記する。
【００２０】
ステップ３０４は、簡易意向確認を行うための処理である。この処理の詳細は、図７の簡易意向確認処理フローを示す図を用いて後記する。
ステップ３０５は、詳細意向確認を行うための処理である。この処理の詳細は、図８の詳細意向確認処理フローを示す図を用いて後記する。
【００２１】
ステップ３０４もしくはステップ３０５の処理の後、ステップ３０６に進む。ステップ３０６では、ステップ３０４もしくはステップ３０５の処理において顧客同意を得られたかどうか調べる。もし顧客同意を得られなかった場合は、ステップ３０２へ戻る。もし顧客同意を得られた場合は、ステップ３０７へ進む。
【００２２】
ステップ３０７は保険契約処理支援をする処理である。この処理の詳細は、図９の保険契約支援処理フローを示す図を用いて後記する。
以上のステップにより、保険代理店契約支援システムの処理の概略が行われる。
【００２３】
次に、保険代理店契約支援システムの処理の詳細について述べる。
まず、ニーズ把握支援処理について、図４と図１２を用いて述べる。図４はニーズ把握支援処理の概略を示すフローチャートであり、ステップ３０１で行われる処理を詳細に説明したものである。また、図１２はニーズ把握支援処理における画面の一例を示した図である。
【００２４】
先に、図１２について説明する。この図において、符号１２０１はクリック領域（現在の健康）、符号１２０２はクリック領域（将来の健康）、符号１２０３はクリック領域（万一の場合）、符号１２０４はクリック領域（老後の生活）、符号１２０５は終了ボタン、符号１２０６はポインタである。
【００２５】
クリック領域（現在の健康）１２０１は現在の健康に関する保障ニーズを高めるボタンである。クリック領域（将来の健康）１２０２は将来の健康に関する保障ニーズを高めるボタンである。クリック領域（万一の場合）１２０３は万一の場合、すなわち死亡に関する保障ニーズを高めるボタンである。クリック領域（老後の生活）１２０４は老後の生活に関する保障ニーズを高めるボタンである。終了ボタン１２０５はニーズ把握支援を終了する際にクリックするボタンである。ポインタ１２０６はクリックする対象を決定するポインタである。
【００２６】
次に、図４を用いてニーズ把握支援処理について述べる。
ステップ４０１はクリックカウンタを初期化する処理である。ここでクリックカウンタとはクリック領域（現在の健康）１２０１等のクリック領域を何回クリックしたかを計測するためのカウンタであり、クリック領域の個数分ある。図１２の例では４つ存在し、それぞれクリックカウンタ（現在の健康）が３、クリックカウンタ（将来の健康）が６、クリックカウンタ（万一の場合）が１５、クリックカウンタ（老後の生活）が９となっている。クリックカウンタは図１２に示すように対応するクリック領域の近辺、あるいは中に表示しても良い。
ステップ４０２はキーワード表示する処理である。この処理によって、図１２のような画面が表示される。
ステップ４０３からステップ４０５は、図１２の終了ボタン１２０５が押されるまで繰り返される。
【００２７】
ステップ４０３は、終了ボタンがクリックされていないかどうか調べる処理である。もし終了ボタンがクリックされた場合は、ステップ４０６へ進む。そうでなければステップ４０４に進む。
【００２８】
ステップ４０４は、クリック受付をする処理である。図１２のような画面を表示し、クリック領域（現在の健康）１２０１等のクリック領域がクリックされるのを待つ。窓口担当者は、顧客がどのような不安を感じており、どのような保険に入りたがっているのかをヒアリングする。そして、ヒアリングの最中あるいは直後等に、その不安や入りたがっている保険が関連するキーワードが表示されているクリック領域をクリックする。このクリックを受付けるのが、本ステップ４０４である。
【００２９】
ステップ４０５は、クリックされたキーワードのクリックカウンタに１を加算する処理である。この処理の後、ステップ４０３に戻る。
【００３０】
ステップ４０６は、各クリックカウンタを正規化し、顧客保険ニーズとしてメモリに登録する処理である。ここで、正規化とは、例えば最大値を５０とし、それに比例するように各クリックカウンタの値を増減させることである。一例として、図１２のように、クリックカウンタ（現在の健康）が３、クリックカウンタ（将来の健康）が６、クリックカウンタ（万一の場合）が１５、クリックカウンタ（老後の生活）が９であるときに、終了ボタン１２０５をクリックしたとする。クリックカウンタの最大値はクリックカウンタ（万一の場合）であるから、これを５０にするために、各クリックカウンタを５０／１５倍する。すると、クリックカウンタ（現在の健康）は１０、クリックカウンタ（将来の健康）は２０、クリックカウンタ（万一の場合）は５０、クリックカウンタ（老後の生活）は３０となる。これを顧客保険ニーズとしてメモリに登録する。
【００３１】
図１１に、顧客保険ニーズを示す。なお、これは後述する保険充足ニーズと保険不足ニーズも例示した図である。
この図において、符号１１０１は現在の健康、符号１１０２は将来の健康、符号１１０３は万一の場合、符号１１０４は老後の生活、符号１０２は顧客保険ニーズ、符号１０３は保険充足ニーズ、符号１０４は保険不足ニーズである。
現在の健康１１０１は現在の健康に関する保障ニーズの高さを表すフィールドである。将来の健康１１０２は将来の健康に関する保障ニーズの高さを表すフィールドである。万一の場合１１０３は万一の場合、すなわち死亡に関する保障ニーズの高さを表すフィールドである。老後の生活１１０４は老後の生活に関する保障ニーズの高さを表すフィールドである。このように顧客保険ニーズが、各フィールドと関連づけられた形式で、代理店窓口端末のメモリ２０２に記録される。なお、顧客保険ニーズは代理店窓口端末のハードディスク２１０に記録されても良い。この場合、顧客保険ニーズを使う際には、顧客保険ニーズを適宜ハードディスク２１０からメモリ２０２に読み出す。
【００３２】
次に、保険代理店契約支援システムの処理の、保険設計支援処理の詳細について、図５の保険設計支援処理の概略を示すフローチャートと、図１３の保険設計支援処理画面を示す図を示す図を用いて説明する。なお、この処理はステップ３０２で行われる処理である。
【００３３】
先に、保険設計支援処理画面について、図１３に示した画面例を用いて説明する。
この図において、符号１３０１は契約者情報欄、符号１３０２は現在プラン欄、符号１３０３は保険ニーズ表示欄、符号１３０４はお勧め保険表示欄、符号１３０５は保険設計欄、符号１３０６は更新ボタン、符号１３０７は終了ボタンである。
【００３４】
契約者情報欄１３０１は契約者情報を入力、確認するための欄である。現在プラン欄１３０２は現在申し込もうとしている保険プランの内容概略が表示される欄である。保険ニーズ表示欄１３０３は顧客保険ニーズと、現在までの保険プランにおける保険充足ニーズを表示する欄である。お勧め保険表示欄１３０４はお勧め保険を表示する欄である。保険設計欄１３０５は保険プランに追加する新たな保険を設計する欄である。更新ボタン１３０６は現在までの保険プランに新たに設計した保険を追加する際にクリックするボタンである。終了ボタン１３０７は保険設計支援処理を終了する際にクリックするボタンである。
【００３５】
次に、保険設計支援処理の概略について図５を用いて説明する。
ステップ５０１は、保険不足ニーズに顧客保険ニーズを代入する処理である。保険不足ニーズは図１１の保険不足ニーズ１０４で示すように、顧客保険ニーズ１０２と同じフィールドを持つデータである。まず、初期化処理として、保険不足ニーズの各フィールドを、顧客保険ニーズの各フィールドと同じにしておく。
【００３６】
次に、ステップ５０２で保険充足ニーズを初期化する。保険充足ニーズは図１１の保険充足ニーズ１０３で示すように、顧客保険ニーズ１０２と同じフィールドを持つデータである。まず、初期化処理として、保険充足ニーズの各フィールドを０にしておく。
【００３７】
次に、終了ボタン１３０７をクリックすることによる終了指示があるまで、ステップ５０３からステップ５０７を繰り返す。
ステップ５０３は、終了指示があったかどうか(終了指示を受付けたかどうか)を調べる処理である。もし終了指示があれば、ステップ５０８へ進む。そうでなければ、ステップ５０４の処理に進み、ステップ５０４からステップ５０７の処理を繰り返す。
【００３８】
ステップ５０４は、商品データサーバ１０６にアクセスし、保険ニーズテーブル１０８を参照し、保険不足ニーズ１０４中で値が高いフィールドにおいて、保険ニーズの値が高くなっている保険を表示する処理である。図１１の例では、お勧め保険表示欄１３０４にこの保険ニーズの値が高くなっている保険が表示されている。また、その他図１１に示されているような他の画面要素もこのステップで表示される。
例えば、保険ニーズ表示欄１３０３には顧客保険ニーズ１０２と保険充足ニーズ１０３を表示する箇所があるので、それぞれ表示する。また、契約者情報欄１３０１や現在プラン欄１３０２も表示する。なお、それぞれまだデータが入力されていない場合は空白としても良い。
【００３９】
ステップ５０５は、保険種別、保険金額等の入力を受け付け、保険設計する処理である。入力は、窓口担当者もしくは顧客が代理店窓口端末１０１のキーボード２０４を用いて、保険設計欄１３０５や契約者情報欄１３０１に入力する。 入力後、更新ボタン１３０６が押されると、入力したデータを受け付ける。契約者情報欄１３０１に入力された情報は契約者情報として代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に記録される。また、保険設計欄１３０５に入力された情報は現在プランに追加され、代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に記録される。また、現在プラン欄１３０２に追加された保険を表示する。なお、図示していないが、現在プラン欄１３０２の保険の修正等を行っても良い。これは、現在プラン欄１３０２に表示されている修正したい保険をクリックすると、保険設計欄１３０５にその保険が表示され、その保険の保険ニーズを保険充足ニーズ１０３から減算するようにすればよい。なお、保険ニーズの検索はステップ５０６で述べるような方法をとる。
【００４０】
ステップ５０６は保険不足ニーズ１０４の各フィールドから、利用した保険の保険ニーズの各フィールドを減算する処理である。なお、ステップ５０５、ステップ５０６、ステップ５０７で用いる保険ニーズは、商品データサーバ１０６にネットワーク１０５を介してアクセスし、保険設計欄１３０５に入力された保険名等をもとに、商品ＤＢ１０７を参照して得ることができる。
【００４１】
ステップ５０７は、保険充足ニーズ１０３の各フィールドに、利用した保険の保険ニーズの各フィールドを加算する処理である。ステップ５０７の処理の後、ステップ５０３に戻る。
【００４２】
ステップ５０８は、保険不足ニーズ１０４、保険充足ニーズ１０３をメモリ２０２もしくはハードディスク２１０に記録し、保険設計支援処理後も使えるようにする処理である。
以上で、保険設計支援処理フローの概略を終了する。
【００４３】
次に、ステップ３０３の設計保険のニーズ充足判定処理の概略を、図６の設計保険のニーズ充足判定処理フローを示す図を用いて説明する。
【００４４】
ステップ６０１は、保険不足ニーズ１０４の各フィールドにおいて、閾値を上回るフィールドがあるかどうか調べる処理である。もし保険不足ニーズ１０４の各フィールドにおいて、閾値を上回るフィールドがある場合は、ステップ６０２へ進む。
【００４５】
もし保険不足ニーズ１０４の各フィールドにおいて、閾値を上回るフィールドがない場合は、ステップ６０３へ進む。ここで、閾値はあらかじめ決定しておき、代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておくべきものである。例えば１０から５０までの任意の数値が典型例としてあるが、０もしくは正の他の数値をとっても良い。この数値は、商品データサーバ１０６のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３を実行する前にネットワーク１０５を通じて代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しても良い。
【００４６】
ステップ６０２は、ニーズ充足せずと判定する処理である。すなわち、ステップ６０１で、閾値の方が小さい場合、ニーズ充足せずと判定する。なお、この判定結果は代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３以降の処理で参照できるようにしておく。図３で述べたように、この処理の後、ステップ３０５に進む。
【００４７】
ステップ６０３は、保険充足ニーズ１０３中の最大値を与えるフィールドと顧客保険ニーズ１０２中の最大値を与えるフィールドが異なるかどうか調べる処理である。もし保険充足ニーズ１０３中の最大値を与えるフィールドと顧客保険ニーズ１０２中の最大値を与えるフィールドが異なる場合は、ステップ６０４へ進む。もし保険充足ニーズ１０３中の最大値を与えるフィールドと顧客保険ニーズ１０２中の最大値を与えるフィールドが同一の場合は、ステップ６０５へ進む。
【００４８】
ステップ６０４は、希望に相違している可能性があり、ニーズ充足せずと判定する処理である。すなわち、ステップ６０３で、フィールドが異なる場合、ニーズ充足せずと判定する。なお、この判定結果は代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３以降の処理で参照できるようにしておく。図３で述べたように、この処理の後、ステップ３０５に進む。
【００４９】
ステップ６０５は、ニーズ充足と判定する処理である。すなわち、ステップ６０３で、フィールドが一致する場合、ニーズ充足すると判定する。なお、この判定結果は代理店窓口端末１０１のメモリ２０２もしくはハードディスク２１０に保存しておき、ステップ３０３以降の処理で参照できるようにしておく。図３で述べたように、この処理の後、ステップ３０４に進む。
以上で、ステップ３０３の設計保険のニーズ充足判定処理が、概略終了する。
【００５０】
次に、ステップ３０４の簡易意向確認処理について、概略を図７の簡易意向確認処理フローを示す図と、図１４の簡易意向確認処理画面を示す図を用いて説明する。まず、図１４の簡易意向確認処理画面について説明する。
【００５１】
図１４は、簡易意向確認処理における画面の一例を示した図である。
この図において、符号１４０１は契約者情報欄、符号１４０２は保険ニーズ表示欄、符号１４０３は保険設計欄、符号１４０４はやりなおしボタン、符号１４０５は確認ボタンである。
【００５２】
契約者情報欄１４０１は、契約者情報、被保険者情報を表示する欄である。保険ニーズ表示欄１４０２は顧客保険ニーズ１０２、保険充足ニーズ１０３を表示する欄である。保険設計欄１４０３は保険プランに追加する新たな保険を設計する欄である。やりなおしボタン１４０４は、保険設計をやり直す際に、このやり直しを操作者が指示（クリック）するためのボタンである。確認ボタン１４０５は、操作者が確認処理の終了を、クリックにより指示するためのボタンである。
【００５３】
次に、本発明の実施の形態の簡易意向確認処理の概略を図７に示すフローチャートを用いて説明する。
【００５４】
ステップ７０１は、意向確認画面を表示する処理である。意向確認画面は、例えば、図１４に示すようなものである。この画面を見ながら、窓口担当者と顧客は現在契約しようとしている保険が顧客のニーズを満たしていることを確認することができる。
【００５５】
ステップ７０２は、顧客同意を取得する処理である。顧客の同意は、例えば顧客が意向確認書面に対し署名した内容を受付ける方法や、代理店窓口端末１０１のマイク２０８や動画カメラ２０９で顧客が意向を確認している旨を発言しているのを録画録音する方法や、代理店窓口端末１０１に一般的に市場にて販売されているペンパッドを接続し、そのペンパッドに対し署名した内容を受付ける等の方法で取得できる。意向確認したのち、確認ボタン１４０５をクリックして簡易意向確認処理を終了する。なお、確認ボタン１４０５を顧客にクリックしてもらうことで簡易意向確認とすることもできる。
以上で、簡易意向確認処理が概略終了する。
【００５６】
次に、ステップ３０５の詳細意向確認をする処理について、図８の詳細意向確認処理フローを示す図と、図１５の詳細意向確認処理画面を示す図を用いて説明する。
【００５７】
まず、図１５の詳細意向確認処理における画面の一例を示した図について説明する。この図において、符号１５０１は詳細意向確認欄である。詳細意向確認欄１５０１は顧客保険ニーズ１０２と保険充足ニーズ１０３をもとに、特に確認すべき点を表示する欄である。その他の符号は図１４の符号と同一であり、図１４と同様の欄である。
【００５８】
次に、本発明の実施の形態の詳細意向確認処理の概略について、図８のフローチャートを用いて説明する。
【００５９】
ステップ８０１は、ステップ６０４において希望に相違している可能性ありと判定したかどうか調べる処理である。もし希望に相違している可能性ありと判定した場合は、ステップ８０２へ進む。もし希望に相違している可能性ありと判定していない場合は、ステップ８０３へ進む。
【００６０】
ステップ８０２は、商品データサーバにアクセスし、保険ニーズテーブルを検索し、保険ニーズの各フィールドのうち最大値を与えるフィールドが、顧客保険ニーズの各フィールドのうち最大値を与えるフィールドと一致する保険を再考候補保険とし、その保険ニーズをメモリに記録する処理である。なお、再考候補保険がすでに提案中の保険に含まれている場合は再考候補保険を空とする。
ステップ８０３は保険不足ニーズが正であるフィールド内の各フィールドを取り出す処理である。もし、要素があれば、ステップ８０４へ進む。各要素に対する処理の後、ステップ８０５へ進む
ステップ８０４は、商品データサーバにアクセスし、保険ニーズテーブルを検索し、処理対象フィールドの値が保険不足ニーズよりも大きい保険を再考候補保険に追加し、その保険ニーズをメモリに記録する処理である。なお、追加する保険がすでに提案中の保険に含まれている場合は何もしない。
【００６１】
ステップ８０５は、顧客保険ニーズ１０２、保険充足ニーズ、契約しようとする保険、再考候補保険を表示する処理である。表示画面は、図１５に示すようなものであり、例えば図１５の例では、顧客保険ニーズ１０２の老後の生活が３０であるのに対し、提案中の保険充足ニーズ１０３の老後の生活が１０と下回っているため、保険ニーズ表示欄１４０２で警告が表示されている。そして、詳細意向確認欄で老後の生活ニーズを満たしていない可能性がある旨が表示されている。また、図１５の例では、顧客保険ニーズ１０２の最高値が万一の場合の５０であるのに対し、提案中の保険充足ニーズ１０３では最高値が将来の健康の８０となっているため、詳細意向確認欄でその旨の警告を表示する。窓口担当者と顧客はこれを見ながら、本当に提案中の保険で顧客のニーズを満たせるか、確認することができる。
【００６２】
ステップ８０６は、契約続行意志表示ありかどうか判定する処理である。もし契約続行意志表示ありであれば、ステップ８０７へ進む。もし契約続行意志表示ありでなければ、終了する。
【００６３】
ステップ８０７は顧客同意を取得する処理である。これはステップ７０２と同様の処理で実行できる。
以上で、詳細意向確認処理が概略終了する。
【００６４】
最後に、ステップ３０７の保険契約支援処理の詳細について、図９の保険契約支援処理フローを示す図と、図１６の保険契約支援処理画面を示す図を用いて説明する。まず、図１６の保険契約支援処理における画面の一例について説明する。
この図において、符号１６０１は銀行口座入力欄、符号１６０２は保留ボタン、符号１６０３は契約ボタンである。
銀行口座入力欄１６０１は保険料引き落としのための銀行口座を入力する欄である。保留ボタン１６０２は契約を保留し、終了する際にクリックするボタンである。契約ボタン１６０３は契約し、契約データを契約サーバ１０９に送信する際にクリックするボタンである。
【００６５】
次に、図９の保険契約支援処理の概略を示すフローチャートについて説明する。
ステップ９０１は、契約データの不足部分の入力を要求する処理である。これは、例えば銀行口座入力欄１６０１に保険料引き落としのための銀行口座を入力する等の処理が該当する。
【００６６】
ステップ９０２は、契約サーバ１０９にアクセスし、入力された契約データをネットワーク１０５を介して契約サーバ１０９に送信する処理である。もちろん、この前には顧客の最終確認が必要であり、その確認はステップ７０２で用いたような方法で実行できる。
以上で、保険契約支援処理についての説明を終わる。
【符号の説明】
【００６７】
１０１…代理店窓口端末
１０２…顧客保険ニーズ
１０３…保険充足ニーズ
１０４…保険不足ニーズ
１０５…ネットワーク
１０６…商品データサーバ
１０７…商品ＤＢ
１０８…保険ニーズテーブル
１０９…契約サーバ
２０１…ＣＰＵ
２０２…メモリ
２０３…ネットワークインタフェース
２０４…キーボード
２０５…時計
２０６…スピーカ
２０７…ディスプレイ
２０８…マイク
２０９…動画カメラ
２１０…ハードディスク
２１１…インターフェース
１２０１…クリック領域（現在の健康）
１２０２…クリック領域（将来の健康）
１２０３…クリック領域（万一の場合）
１２０４…クリック領域（老後の生活）
１２０５…終了ボタン
１２０６…ポインタ
１３０１…契約者情報欄
１３０２…現在プラン欄
１３０３…保険ニーズ表示欄
１３０４…お勧め保険表示欄
１３０５…保険設計欄
１３０６…更新ボタン
１３０７…終了ボタン
１４０１…契約者情報欄
１４０２…保険ニーズ表示欄
１４０３…保険設計欄
１４０４…やりなおしボタン
１４０５…確認ボタン
１５０１…詳細意向確認欄
１６０１…銀行口座入力欄
１６０２…保留ボタン
１６０３…契約ボタン
【特許請求の範囲】
【請求項１】
保険代理店において主に保険代理店の窓口担当者が操作する代理店窓口端末と、
保険会社もしくはその代理人等が運用する商品データサーバと、
保険会社もしくはその代理人等が運用する契約サーバとが、
ネットワークによって接続された保険代理店契約支援システムにおいて、
前記商品データサーバにネットワーク等によって接続された商品データベースに、保険商品が充足するニーズを数値で表現した保険ニーズテーブルを保存しておき、
前記窓口担当者の要求に応じて前記代理店窓口端末が備えるメモリもしくは２次記憶装置において、顧客のニーズを数値で表現した顧客保険ニーズを生成し、
前記代理店窓口端末は、前記保険ニーズテーブルより契約しようとする保険のニーズテーブルを作成し、
前記契約サーバは、前記顧客保険ニーズと前記契約しようとする保険のニーズテーブルとを比較した結果、前記顧客保険ニーズが前記契約しようとする保険のニーズテーブルよりも大きかった場合に、その旨を前記代理店窓口端末に送信する
ことを特徴とする保険代理店契約支援システム。
【請求項２】
契約もしくは取引に関する履歴を記録することでの当該契約もしくは取引を支援する契約支援方法において、
予め、契約もしくは取引の対象となる各商品の性質を示す各項目毎に、そのニーズを示すニーズ情報を記録しておき、
前記契約もしくは取引の関与者間の対象となる商品についての対話形式でのやり取りの入力を受付け、
受付けられたやり取りから、前記関与者に含まれる当該商品の購入予定者のニーズ情報を抽出し、
抽出されたニーズ情報と記録されたニーズ情報を比較して、前記購入予定者のニーズが大きい商品を抽出することを特徴とする取引支援方法。
【請求項３】
請求項２に記載の取引支援方法において、
抽出された前記商品の商品情報を、ネットワークを介して送信して、送信された端末装置が、当該商品情報を表示することを特徴とする取引支援方法。
【請求項４】
請求項２または３のいずれかに記載の取引支援方法において、
前記商品の抽出は、指定された項目につき、それぞれ前記購入予定者のニーズが方が大きいものを抽出することを特徴とする取引支援方法。
【請求項５】
請求項２乃至４のいずれかに記載の取引支援方法において、
前記商品の抽出は、各項目の総和が大きいものを抽出することを特徴とする取引支援方法。
【請求項６】
請求項２乃至５のいずれかに記載の取引支援方法において、
前記商品は、保険商品であることを特徴とする取引支援方法。
【請求項１】
保険代理店において主に保険代理店の窓口担当者が操作する代理店窓口端末と、
保険会社もしくはその代理人等が運用する商品データサーバと、
保険会社もしくはその代理人等が運用する契約サーバとが、
ネットワークによって接続された保険代理店契約支援システムにおいて、
前記商品データサーバにネットワーク等によって接続された商品データベースに、保険商品が充足するニーズを数値で表現した保険ニーズテーブルを保存しておき、
前記窓口担当者の要求に応じて前記代理店窓口端末が備えるメモリもしくは２次記憶装置において、顧客のニーズを数値で表現した顧客保険ニーズを生成し、
前記代理店窓口端末は、前記保険ニーズテーブルより契約しようとする保険のニーズテーブルを作成し、
前記契約サーバは、前記顧客保険ニーズと前記契約しようとする保険のニーズテーブルとを比較した結果、前記顧客保険ニーズが前記契約しようとする保険のニーズテーブルよりも大きかった場合に、その旨を前記代理店窓口端末に送信する
ことを特徴とする保険代理店契約支援システム。
【請求項２】
契約もしくは取引に関する履歴を記録することでの当該契約もしくは取引を支援する契約支援方法において、
予め、契約もしくは取引の対象となる各商品の性質を示す各項目毎に、そのニーズを示すニーズ情報を記録しておき、
前記契約もしくは取引の関与者間の対象となる商品についての対話形式でのやり取りの入力を受付け、
受付けられたやり取りから、前記関与者に含まれる当該商品の購入予定者のニーズ情報を抽出し、
抽出されたニーズ情報と記録されたニーズ情報を比較して、前記購入予定者のニーズが大きい商品を抽出することを特徴とする取引支援方法。
【請求項３】
請求項２に記載の取引支援方法において、
抽出された前記商品の商品情報を、ネットワークを介して送信して、送信された端末装置が、当該商品情報を表示することを特徴とする取引支援方法。
【請求項４】
請求項２または３のいずれかに記載の取引支援方法において、
前記商品の抽出は、指定された項目につき、それぞれ前記購入予定者のニーズが方が大きいものを抽出することを特徴とする取引支援方法。
【請求項５】
請求項２乃至４のいずれかに記載の取引支援方法において、
前記商品の抽出は、各項目の総和が大きいものを抽出することを特徴とする取引支援方法。
【請求項６】
請求項２乃至５のいずれかに記載の取引支援方法において、
前記商品は、保険商品であることを特徴とする取引支援方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１１−２３２９００（Ｐ２０１１−２３２９００Ａ）
【公開日】平成２３年１１月１７日（２０１１．１１．１７）
【国際特許分類】
【出願番号】特願２０１０−１０１６０６（Ｐ２０１０−１０１６０６）
【出願日】平成２２年４月２７日（２０１０．４．２７）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【公開日】平成２３年１１月１７日（２０１１．１１．１７）
【国際特許分類】
【出願日】平成２２年４月２７日（２０１０．４．２７）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
[ Back to top ]