JP5791588B2 - 代理店アラームシステム、及び代理店アラーム通知方法 - Google Patents

Description

本発明は、代理店アラームシステムに関し、特に代理店の販促活動を評価する代理店アラームシステムに関する。

現状では、企業の商品やサービスを、その企業の代理で販売や会員勧誘、営業活動を顧客に行う代理店に関して、企業が代理店と契約する際には、事前に審査を行っていた。

しかし、企業が代理店と契約する際の事前審査では問題がなくても、代理店が販売等を実施・継続しているうちに、顧客への説明不足や混乱等が起きる可能性がある。例えば、代理店が、顧客に対して実際の商品やサービスと異なる内容を説明して商品やサービスの提供の契約申込を獲得することや、商品やサービスを提供できない相手（対象地域外の相手等）に対して商品やサービスの提供の契約申込を獲得することが起こり得る。

このような場合、契約者は不満を感じてしまい、企業イメージやブランド価値を著しく毀損してしまう恐れがある。

また、正式に契約を締結する前や、決済方法を登録する前であっても、企業側では、契約申込があった時点で、顧客情報の管理を始め、正式な契約締結及びその後に向けての準備や事務処理を開始しており、そのコスト（費用）が発生している。したがって、顧客が決済方法を登録せずに早期に契約解除を行った場合、そのコストを回収できなくなり、損失が発生する。

また、一口に代理店といっても、実際には企業と代理店契約を直接締結した一次代理店（商社等）に限らず、一次代理店と代理店契約を締結した二次代理店等も存在する。更に、代理店の数も膨大であることが多い。代理店により品質に差が出ることは当然に起こり得ることであり、これら全ての代理店に対して、均等な顧客満足度の実現／維持を要求することは困難であった。

［公知技術］
現状における公知技術として、特許文献１（特開２００２−１０９１９４号公報）に、セールス及びサポート・システム及びセールス及びサポート方法が開示されている。この公知技術では、インターネットを介して、販売店、代理店、メーカー間でセールス及びサポートに関する情報を共有することにより、顧客、販売店、代理店に対して商品に関わる注文受付、問い合わせ、各種サポート、クレーム処理を迅速に行うことができ、販売店、代理店が負担する投資費用はインターネットに関わる通信費用のみに抑えることができる。

このように、代理店も含めたセールスやサポートを行うシステムはあったが、注意や教育の必要がある代理店を早期に発見するシステムはなかった。

特開２００２−１０９１９４号公報

企業が代理店と契約する際の事前審査では問題がなくても、代理店が販売等を行っていくうちに、顧客への説明不足や混乱等が起きる可能性がある。

本発明に係る代理店アラームシステムは、代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢと、顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢと、顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢと、該サポートＤＢに格納された該連絡内容区分が、申込済のサービスへの基本的な説明依頼、又は、契約申込から所定期間以内の契約解除の内、少なくとも１つを含むカウント対象区分か否か判定し、該連絡内容区分がカウント対象区分であれば、該顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出し、該代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算し、該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う管理装置を含む。

本発明に係る管理装置は、代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢを管理する機構と、顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢを管理する機構と、顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢを管理する機構と、該サポートＤＢに格納された該連絡内容区分が、申込済のサービスへの基本的な説明依頼、又は、契約申込から所定期間以内の契約解除の内、少なくとも１つを含むカウント対象区分か否か判定する機構と、該連絡内容区分がカウント対象区分であれば、該顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出する機構と、該代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算する機構と、該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う機構を備える。

本発明に係るアラーム通知方法は、計算機により実施される。このアラーム通知方法では、代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢを管理する。また、顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢを管理する。また、顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢを管理する。また、該サポートＤＢに格納された該連絡内容区分が、申込済のサービスへの基本的な説明依頼、又は、契約申込から所定期間以内の契約解除の内、少なくとも１つを含むカウント対象区分か否か判定する。また、該連絡内容区分がカウント対象区分であれば、該顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出する。また、該代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算する。また、該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う。

本発明に係るプログラムは、上記のアラーム通知方法における処理を、計算機に実行させるためのプログラムである。なお、本発明に係るプログラムは、記憶装置や記憶媒体に格納することが可能である。

本発明では、顧客からのサポートセンタへの電話等の内容や時期で区分けし、顧客から特定の区分に該当する連絡があった場合、顧客ＤＢから、その顧客を担当した代理店を抽出し、代理店ＤＢに対し、その抽出した代理店のカウント数に１を加算する。代理店ＤＢ内の代理店の中で、カウント数が、特定の閾値以上になった場合（特定の閾値に達した場合）、その代理店についてのアラーム（警告）を管理者に送信する。

注意や教育の必要がある代理店を早期に発見することが可能になる。

本発明に係る代理店アラームシステムの構成例を示す図である。 管理装置の構成例を示す図である。 代理店ＤＢのテーブルの構成例を示す図である。 顧客ＤＢのテーブルの構成例を示す図である。 サポートＤＢのテーブルの構成例を示す図である。 連絡内容区分と連絡内容との関係を示す図である。 カウント対象区分とカウント対象との関係を示す図である。

＜実施形態＞
以下に、本発明の実施形態について添付図面を参照して説明する。

［システム構成］
図１Ａを参照して、本発明に係る代理店アラームシステムの構成例について説明する。

本発明に係る代理店アラームシステムは、管理装置１０と、代理店ＤＢ２０と、顧客ＤＢ３０と、サポートＤＢ４０を含む。

管理装置１０は、各種のデータベース装置を管理するサーバ装置である。代理店ＤＢ２０は、代理店に関する情報を登録するためのデータベース装置である。顧客ＤＢ３０は、顧客に関する情報を登録するためのデータベース装置である。サポートＤＢ４０は、顧客からの連絡内容に関する情報を登録するためのデータベース装置である。

ここでは、管理装置１０は、随時、代理店ＤＢ２０、顧客ＤＢ３０、及びサポートＤＢ４０にアクセス可能である。

管理装置１０は、代理店契約を締結した代理店を示す代理店コードと、その代理店の連絡先に関する情報を、代理店ＤＢ２０に登録する機能を有していても良い。

また、管理装置１０は、顧客と代理店との間で商品やサービスの提供の契約申込があった場合、代理店からの連絡に基づいて、その顧客を示す顧客ＩＤと、その代理店を示す代理店コードを、顧客ＤＢ３０に登録する機能を有していても良い。

また、管理装置１０は、サポートセンタ等に対する顧客からの連絡に基づいて、連絡してきた顧客を示す顧客ＩＤと、その連絡内容に関する情報を、サポートＤＢ４０に登録する機能を有していても良い。

なお、管理装置１０、代理店ＤＢ２０、顧客ＤＢ３０、及びサポートＤＢ４０の各々は、同一の装置でも良いし、それぞれ独立した装置でも良い。また、クラウドコンピューティング（ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ）におけるクラウドでも良い。

また、管理装置１０は、随時、サポート担当者端末５０や管理者端末６０と通信可能である。

サポート担当者端末５０は、サポート担当者（サポート担当者端末５０のオペレータ）により使用される端末装置である。なお、サポート担当者端末５０は、サポートＤＢ４０と共に、サポートセンタ等に設置されていても良い。

管理者端末６０は、管理者により使用される端末装置である。

実際には、管理装置１０がサポート担当者端末５０や管理者端末６０としての役割も担当していても良い。また、サポート担当者端末５０や管理者端末６０がシンクライアント（Ｔｈｉｎ ｃｌｉｅｎｔ）端末で、管理装置１０がシンクライアント端末にクライアント環境を提供するサーバである事例も考えられる。

また、代理店が個人営業である場合や、代理店の営業担当者を個人レベルで管理する場合には、代理店を代理人又は営業員と読み替えても良い。

［管理装置の詳細］
図１Ｂを参照して、管理装置１０の構成例について説明する。

管理装置１０は、統括制御部１１と、代理店ＤＢ管理部１２と、顧客ＤＢ管理部１３と、サポートＤＢ管理部１４と、サポート担当者端末用通信部１５と、管理者端末用通信部１６を備える。

統括制御部１１は、管理装置１０の動作や処理の全般を制御する。例えば、統括制御部１１は、代理店ＤＢ管理部１２、顧客ＤＢ管理部１３、及びサポートＤＢ管理部１４を介して、代理店ＤＢ２０、顧客ＤＢ３０、及びサポートＤＢ４０の連携を制御する。また、統括制御部１１は、サポート担当者端末用通信部１５や管理者端末用通信部１６を介して、サポート担当者端末５０や管理者端末６０と通信する。

代理店ＤＢ管理部１２は、代理店ＤＢ２０のテーブルのレコードの登録・更新・参照・削除を管理し、そのために必要な処理を行う。代理店ＤＢ管理部１２は、代理店ＤＢ２０と連携していても良いし、代理店ＤＢ２０を有していても良い。

顧客ＤＢ管理部１３は、顧客ＤＢ３０のテーブルのレコードの登録・更新・参照・削除を管理し、そのために必要な処理を行う。顧客ＤＢ管理部１３は、顧客ＤＢ３０と連携していても良いし、顧客ＤＢ３０を有していても良い。

サポートＤＢ管理部１４は、サポートＤＢ４０のテーブルのレコードの登録・更新・参照・削除を管理し、そのために必要な処理を行う。サポートＤＢ管理部１４は、サポートＤＢ４０と連携していても良いし、サポートＤＢ４０を有していても良い。

サポート担当者端末用通信部１５は、サポート担当者端末５０と通信するための機構である。サポート担当者端末用通信部１５は、サポート担当者端末５０からの通知を受信する。また、必要に応じて、サポート担当者端末５０に連絡入力画面を提供／表示する。

管理者端末用通信部１６は、管理者端末６０と通信するための機構である。管理者端末用通信部１６は、管理者端末６０にアラーム通知を送信する。また、必要に応じて、管理装置１０や各データベース装置に対する管理者端末６０からの操作指示を受け付ける。

実際には、サポート担当者端末用通信部１５と管理者端末用通信部１６は、同一の機構（共通）でも良い。

ここでは、統括制御部１１は、サポートＤＢ管理部１４を介して、サポートＤＢ４０に新規に連絡の登録があったか確認する。新規の連絡の登録がある場合は、その連絡の連絡内容区分が、カウント対象の連絡か判断する。

また、統括制御部１１は、サポート担当者端末用通信部１５を介して、サポート担当者端末５０からの通知内容を受信し、サポートＤＢ管理部１４を介して、サポートＤＢ４０に、連絡内容に含まれる連絡してきた顧客とその連絡内容区分を登録するようにすることも可能である。顧客とその連絡内容区分を登録する場合は、その連絡内容区分が、カウント対象の連絡か判断する。

カウント対象の連絡であった場合、その連絡をした顧客を基に、顧客ＤＢ管理部１３を介して、顧客ＤＢ３０から、その連絡のあった顧客に対応する代理店を抽出する。代理店ＤＢ管理部１２を介して、代理店ＤＢ２０にて、その抽出された代理店のレコードに対応するカウント数に１を加算する。このとき、連絡内容区分毎にカウント数に１を加算しても良い。

また、統括制御部１１は、顧客ＤＢ管理部１３を介して、顧客ＤＢ３０に登録されている顧客の契約等に関する２種類の項目（月日情報項目や空白のある情報項目）を比較し、既定の要因毎の所定条件に合致する顧客情報があるか確認する。合致する顧客情報がある場合は、その顧客に対応する代理店を抽出する。代理店ＤＢ管理部１２を介して、代理店ＤＢ２０にて、その抽出された代理店のレコードに対応するカウント数に１を加算する。このとき、要因毎にカウント数に１を加算しても良い。

また、カウント数が所定の閾値に達した場合には、管理者端末用通信部１６を介して、管理者端末６０にアラームを通知する。このとき、統括制御部１１は、カウント数が別の閾値に達した場合に、インターネットの掲示板やブログから、その代理店名称を含む文章を抽出し、その文章を基に評判分析を実施するようにしても良い。

なお、統括制御部１１、代理店ＤＢ管理部１２、顧客ＤＢ管理部１３、サポートＤＢ管理部１４、サポート担当者端末用通信部１５、及び管理者端末用通信部１６の各々は、同一の装置でも良いし、それぞれ独立した装置でも良い。また、クラウドコンピューティング（ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ）におけるクラウドでも良い。また、統括制御部１１、代理店ＤＢ管理部１２、顧客ＤＢ管理部１３、サポートＤＢ管理部１４、サポート担当者端末用通信部１５、及び管理者端末用通信部１６の各々の機能は、モジュール（ｍｏｄｕｌｅ）、コンポーネント（ｃｏｍｐｏｎｅｎｔ）、或いは専用デバイス、又はこれらの起動（呼出）プログラムにより実現しても良い。

［代理店ＤＢの詳細］
図２を参照して、代理店ＤＢ２０のテーブルの構成例について説明する。

例えば、代理店ＤＢ２０は、代理店名称と、代理店コードと、カウント数と、代理店連絡先等の各々を格納するための領域（フィールド）を有する。なお、各領域については、全てが必要というわけではなく、これらのうち必要な情報を格納するための領域のみ設ければ良い。

代理店名称は、顧客等が代理店を識別するための識別情報を示す。代理店コードは、管理者等が代理店を特定するための識別子を示す。カウント数は、顧客からの連絡内容等に挙げられた回数を示す。代理店連絡先は、代理店の連絡先を示す情報を示す。

なお、カウント数については、連絡内容区分や要因区分毎に、カウントした回数を格納するための領域を設けても良い。無論、連絡内容区分や要因区分の各々をその内容に応じて分類し、同じ分類のものをグループ化し、グループ単位でカウントした回数を格納するための領域を設けても良い。また、連絡内容区分や要因区分毎ではなく、後述するカウント対象区分毎でも良い。ここでは、一例として、連絡内容区分や要因区分毎に、カウントした回数を格納するための領域を設ける事例について説明する。

連絡内容区分は、顧客からの連絡があった場合にその連絡内容の種類を識別する識別子であるのに対し、要因区分は、顧客からの連絡がなかった場合にその問題の要因の種類を識別する識別子である。例えば、何らかの理由で商品やサービスの提供の準備が完了しなかった場合や、顧客が決済方法を登録しなかった場合（契約申込日から所定期間が経過した時点で、準備完了日や決済登録日が空白である場合）には、連絡内容区分の代わりに要因区分を使用する。但し、実際には、要因区分も、連絡内容区分の１つとして使用しても良い。

また、代理店連絡先については、連絡先情報の種類毎に、情報を格納するための領域を設けても良い。例えば、電話番号を格納するための領域と、メールアドレスを格納するための領域を別々に設けても良い。

更に、図示しないが、代理店ＤＢ２０は、必要に応じて、代理店教育日と、代理店教育回数の少なくとも一方を格納するための領域を有していても良い。或いは、これらの情報については、備考として、備考を格納するための領域に格納しても良い。代理店教育日は、代理店に対して注意や教育等が行われた際の最新の日時を示す。代理店教育回数は、これまで代理店に対して注意や教育等が行われた回数を示す。例えば、代理店教育日を参照することで、最後にいつ注意や教育等が行われたか確認できるようになる。また、代理店教育回数を参照することで、その代理店がどれくらいの頻度で注意や教育等を受けているか確認できるようになる。

また、図示しないが、代理店ＤＢ２０は、必要に応じて、代理店代表者と、代理店所在地の少なくとも一方を格納するための領域を有していても良い。或いは、これらの情報については、備考として、備考を格納するための領域に格納しても良い。代理店代表者は、代理店の代表者や責任者を示す。代理店所在地は、代理店の所在地に関する情報（住所等）を示す。例えば、代理店によっては、代理店名称を変更する可能性も考えられる。代理店名称を変更した場合、代理店コードも同時に変更となってしまう。この場合でも、代理店代表者又は代理店所在地が同じであれば、代理店名称を変更する前の情報を引き継ぐようにすることが可能になる。

［顧客ＤＢの詳細］
図３を参照して、顧客ＤＢ３０のテーブルの構成例について説明する。

例えば、顧客ＤＢ３０は、顧客ＩＤと、顧客連絡先と、代理店コードと、契約申込日と、準備完了日と、決済登録日と、契約解除日等の各々を格納するための領域を有する。なお、各領域については、全てが必要というわけではなく、これらのうち必要な情報を格納するための領域のみ設ければ良い。

顧客ＩＤは、管理者等が顧客を特定するための識別子を示す。顧客連絡先は、当該顧客の連絡先を示す情報を示す。代理店コードは、管理者等が代理店を特定するための識別子であって、当該顧客から契約申込を獲得した代理店を特定するための識別子を示す。契約申込日は、当該顧客が契約申込を行った日時を示す。準備完了日は、当該顧客に対し、契約した商品やサービス等に関する何らかの準備が完了した日時を示す。決済登録日は、契約した商品やサービス等の決済方法を当該顧客が登録した日時を示す。契約解除日は、当該顧客に対して契約解除を行った日時を示す。

なお、顧客連絡先については、連絡先情報の種類毎に、情報を格納するための領域を設けても良い。例えば、電話番号を格納するための領域と、メールアドレスを格納するための領域を別々に設けても良い。

［サポートＤＢの詳細］
図４を参照して、サポートＤＢ４０のテーブルの構成例について説明する。

例えば、サポートＤＢ４０は、顧客ＩＤと、連絡日時と、連絡内容区分と、連絡内容等の各々を格納するための領域を有する。なお、各領域については、全てが必要というわけではなく、これらのうち必要な情報を格納するための領域のみ設ければ良い。

顧客ＩＤは、管理者やサポート担当者等が顧客を特定するための識別子を示す。連絡日時は、当該顧客がサポートセンタ等に連絡してきた日時を示す。連絡内容区分は、連絡内容を分類・特定するための識別子を示す。連絡内容は、当該顧客がサポートセンタ等に連絡してきた内容を示す。

なお、連絡内容区分及び連絡内容を格納するための領域については、要因区分及び要因に関する情報を格納しても良い。例えば、顧客からの連絡はないが、管理者やサポート担当者等が代理店について気付いた点や気掛かりな点があれば、それに該当する要因区分及び要因を格納できるようにしても良い。このとき、連絡内容区分及び連絡内容を格納するための領域と、要因区分及び要因を格納するための領域を別々に設けても良い。

［ＤＢ間で共通の情報］
代理店ＤＢ２０の代理店コードと、顧客ＤＢ３０の代理店コードは、共通している。また、顧客ＤＢ３０の顧客ＩＤと、サポートＤＢ４０の顧客ＩＤは、共通している。これらの共通する情報は、リレーショナルデータベースにおける候補キー（ｃａｎｄｉｄａｔｅ ｋｅｙ）として使用することができる。無論、主キー（ｐｒｉｍａｒｙ ｋｅｙ）として使用することも可能である。また、顧客から契約解除の連絡があった場合、顧客ＤＢ３０の契約解除日は、サポートＤＢ４０の連絡日時でも良い。

［システム動作］
以下に、本発明に係る代理店アラームシステムの動作例について説明する。

管理装置１０は、サポートセンタ等に設置されたサポート担当者端末５０に対し、サポート担当者が顧客からの連絡内容を入力するためのユーザインターフェースとして、連絡入力画面を提供／表示する。

サポート担当者は、サポート担当者端末５０が顧客からの電話、メール、又は掲示板等での連絡を受信した際、サポート担当者端末５０の入力装置を用いて、連絡入力画面に、連絡を受けた顧客の顧客ＩＤ、連絡内容区分等を入力する。サポート担当者端末５０は、連絡入力画面に対する入力が行われた際に、顧客ＩＤ、連絡内容区分、及び連絡内容に受信日時を付加して、管理装置１０に通知する。

また、連絡内容区分等の入力は、サポート担当者が行うのではなく、サポート担当者の入力等で記録された顧客からの連絡内容の文章データを基に、サポート担当者端末５０が、自動的に、単語抽出や文章解析をし、解析結果を基に、連絡内容の種類分けをして、該当する区分を決定し、顧客ＩＤ、連絡内容区分、及び連絡内容に受信日時を付加して、管理装置１０に通知するようにしても良い。

或いは、サポート担当者端末５０は、顧客からの電話、メール、又は掲示板等での連絡を受信した際、音声解析や文章解析等を行い、自動的に、連絡を受けた顧客の顧客ＩＤ、連絡内容区分等を抽出し、顧客ＩＤ、連絡内容区分、及び連絡内容に受信日時を付加して、管理装置１０に通知するようにしても良い。

管理装置１０は、通知された内容をサポートＤＢ４０に登録する。

なお、実際には、サポート担当者端末５０は、管理装置１０に通知せず、直接サポートＤＢ４０に登録しても良い。例えば、サポートＤＢ４０がサポート担当者端末５０と同じサポートセンタ内に設置され、管理装置１０が外部に設置されている場合、サポート担当者端末５０は、直接サポートＤＢ４０に登録すると考えられる。

また、管理装置１０がサポート担当者端末５０としての役割も担当している場合にも、サポート担当者端末５０（に相当する管理装置１０）は、直接サポートＤＢ４０に登録すると考えられる。

顧客ＩＤは、企業から割り当てられた専用のＩＤ（識別子）でなくとも、顧客の電話番号、又は、氏名、メールアドレス等の顧客が特定できるものを用いても良い。すなわち、顧客連絡先の情報を利用することができる。

連絡内容区分は、連絡内容の種類を識別する識別子であれば良い。連絡内容の例として、商品やサービスの提供の契約申込、個人情報の変更、契約解除等が考えられる。なお、連絡内容区分と連絡内容との関係については、図５に示すような連絡内容区分テーブルの形式で予め設定していても良い。但し、実際には、これらの例に限定されない。

例えば、管理装置１０は、契約申込から所定期間以内の契約解除（＝早期契約解除）の区分を登録する場合、サポート担当者端末５０から契約解除の旨及び契約解除日が通知された際に、顧客ＤＢ３０を参照し、その顧客ＩＤの契約申込日を抽出し、契約申込日と契約解除日とを比較し、契約申込日から契約解除日までの期間が、所定期間以内に合致すれば、サポートＤＢ４０の連絡内容区分に、早期契約解除の識別子を登録する。

契約申込日から契約解除日までの期間が、所定期間以内に合致しなければ、サポートＤＢ４０の連絡内容区分に、契約解除の識別子（早期契約解除の識別子とは異なる）を登録する。他の例としては、管理装置１０は、サポートＤＢ４０の連絡内容区分に、契約解除の識別子が登録されたことを検出し、顧客ＤＢ３０を参照し、その顧客ＩＤの契約申込日を抽出し、契約申込日と契約解除日とを比較し、契約申込日から契約解除日までの期間が、所定期間以内に合致すれば、サポートＤＢ４０の連絡内容区分に登録された契約解除の識別子を、早期契約解除の識別子に変更しても良い。

契約申込日の例として、商品やサービスの予約日、会員制サービスの入会日等が考えられる。また、契約解除日の例として、商品やサービスの予約のキャンセル日、会員制サービスの退会日等が考えられる。

管理装置１０は、定期的に、もしくは、サポートＤＢ４０への登録毎に、サポートＤＢ４０を参照し、前回抽出した以降に登録された分のデータで、連絡内容区分がカウント対象区分に属するデータがあるか判定し、カウント対象区分に属するデータがある場合、そのデータの顧客ＩＤを抽出する。

カウント対象区分とは、連絡内容区分のうち、カウント対象となる特定の連絡内容を示す識別子であれば良い。特定の連絡内容の例として、サービス対象範囲（地域等）外からの顧客の契約申込や、申込済のサービスへの基本的な説明依頼や問い合わせ（○○サービスを申込済の顧客から「○○サービスとはどのようなサービスか？」や、「○○サービスの契約書（又は、決済登録書）が届いたが、何の書類か？」等）、契約申込から所定期間以内の契約解除（早期契約解除）依頼等、代理店への教育や注意が直ちに（即座に）必要とまでは言えないが、多いと必要となる内容が考えられる。なお、カウント対象区分とカウント対象との関係については、図６に示すようなカウント対象区分テーブルの形式で予め設定していても良い。但し、実際には、これらの例に限定されない。

管理装置１０は、顧客ＤＢ３０を参照し、抽出された顧客ＩＤの代理店コードを抽出し、代理店ＤＢ２０のその代理店コードに対応するカウント数に１を加算する。ここで、カウント数は、連絡内容区分や要因区分毎に管理しても良い。

このとき、管理装置１０は、顧客ＤＢ３０を参照する際に、抽出された顧客ＩＤの契約申込日を抽出し、契約申込日と現在日とを比較し、契約申込日から現在日までの期間が、所定期間以内の顧客については、その代理店コードを抽出し、所定期間より長い顧客については、その代理店コードを抽出の対象としなくても良い。

また、管理装置１０は、定期的に、もしくは、顧客ＤＢ３０に、商品やサービスの提供の準備完了日／決済登録日／契約解除日を登録する毎に、前回抽出した以降に登録された分の顧客データで、契約申込日と準備完了日／契約申込日と決済登録日／契約申込日と契約解除日を比較し、それぞれの要因毎の所定条件に合致すれば、顧客ＤＢ３０から、その顧客ＩＤを抽出する。なお、契約申込日と契約解除日を比較することで、早期契約解除の要因区分の要因を抽出することができる。

準備完了日の例として、正式な契約書の発送日／受領日、初回の商品や試供品等の発送日／受領日、顧客との面談日、顧客宅への訪問日、通信回線の開通日等が考えられる。また、決済登録日の例として、正式な決済登録書の発送日／受領日、決済方法の登録日等が考えられる。

上記の要因毎の所定条件の例として、準備完了日と決済登録日の場合は、「準備完了日と決済登録日の間が所定期間より長い」等が考えられる。また、契約申込日と契約解除日の場合は、「契約申込日と契約解除日の間が所定期間以内」等が考えられる。更に、上記の所定条件の他の例として、日時の比較ではなく、「契約申込日から所定期間が経過し、準備完了日や決済登録日が空白である」等も考えられる。すなわち、管理装置１０は、契約申込日から所定期間が経過した時点で、準備完了日や決済登録日が空白である場合、要因区分をそれぞれ、準備未完了、決済未登録として、その顧客ＩＤを抽出しても良い。但し、実際には、これらの例に限定されない。

次に、管理装置１０は、顧客ＤＢ３０から、抽出された顧客ＩＤに関連付けられている代理店コードを抽出し、代理店ＤＢ２０のその代理店コードに対応するカウント数に１を加算（ｉｎｃｒｅｍｅｎｔ）する。ここで、カウント数は、準備未完了、決済未登録、早期契約解除等の各要因の要因区分毎に管理しても良い。

管理装置１０は、カウント数が加算された後、そのカウント数と第１の閾値とを比較し、そのカウント数が第１の閾値以上（第１の閾値に達した）か判定する。第１の閾値以上の場合は、そのカウント数に対応する代理店コード等を代理店ＤＢ２０から抽出し、その代理店コード等を含むアラーム通知を管理者端末６０に送信する。アラーム通知には、管理者端末６０側で代理店を特定できるように、代理店名称及び代理店コードの少なくとも一方が含まれているものとする。他にも、アラーム通知には、その代理店について、代理店ＤＢ２０に格納されている任意の情報が含まれていても良い。例えば、管理装置１０は、代理店ＤＢ２０から、その代理店コードに対応する代理店連絡先を抽出し、その代理店コードと代理店連絡先を含むアラーム通知を管理者端末６０に送信するようにしても良い。

更に、管理装置１０は、上記の第１の閾値よりも小さな値である第２の閾値を設定し、カウント数が加算された後、そのカウント数と第２の閾値とを比較し、そのカウント数が第２の閾値以上（第２の閾値に達した）か判定しても良い。例えば、第２の閾値以上、第１の閾値未満の場合は、そのカウント数に対応する代理店名称等をキーにして、インターネットの掲示板やブログから、その代理店名称を含む文章を抽出し、その文章を基に評判分析を実施する。もし、悪い評判の件数や比率が多い場合は、その代理店名称に対応する代理店コード等を代理店ＤＢ２０から抽出し、その代理店コード等を含むアラーム通知を管理者端末６０に送信する。悪い評判の判定条件については、「文章中に所定のキーワードが含まれている」等が考えられる。

インターネットの掲示板やブログについては、事前に（予め）検索対象のＷｅｂページを指定しておいても良いし、代理店名称を検索キーとして検索エンジンを利用しても良い。また、インターネットから自動的にＷｅｂページを収集（ｃｒａｗｌｉｎｇ）するようにしても良い。

代理店名称に関する評判の内容については、図示しないが、代理店ＤＢ２０に、評判の内容を格納するための領域を設けて、その領域に格納しても良い。或いは、備考として、備考を格納するための領域に格納しても良い。管理装置１０は、代理店コード等を含むアラーム通知を管理者端末６０に送信する際、アラーム通知に評判の内容を挿入するようにしても良い。また、管理装置１０は、このアラーム通知に、更に、代理店名称や代理店連絡先、連絡内容区分や要因区分等を挿入するようにしても良い。これにより、管理者端末６０側で、代理店名称や代理店連絡先、連絡内容区分や要因区分等を表示／認識できるようになる。

なお、カウント数と閾値との比較については、連絡内容区分や要因区分毎に個別にカウント数と閾値とを比較しても良いし、連絡内容区分や要因区分毎のカウント数の合計値と閾値とを比較しても良い。また、連絡内容区分や要因区分毎に個別にカウント数と閾値とを比較する場合は、連絡内容区分や要因区分別に複数の閾値を用意しておいても良い。

管理者端末６０は、アラーム通知を受信すると、アラーム通知に基づいて、代理店コード等を含むアラーム画面を表示する。このとき、管理者端末６０は、代理店ＤＢ２０から、この代理店コードに対応する代理店連絡先を抽出して表示するようにしても良い。

管理者は、この代理店連絡先に基づいて、この代理店との連絡を取り、代理店に対する注意や教育等を行う。このとき、代理店に対する注意や教育等は、管理装置１０や管理者端末６０が自動的に行うようにしても良い。例えば、管理装置１０や管理者端末６０は、所定のメッセージを示す音声データや文章データを予め用意しておき、代理店に対する注意や教育が必要となった時に、電話、メール、又は掲示板等を用いて、これらの音声データや文章データを代理店に伝えるようにしても良い。

なお、管理装置１０が管理者端末６０としての役割も担当している場合、管理装置１０は、管理者端末６０ではなく、自身に接続／搭載された表示装置にアラーム画面を表示する。また、管理者端末６０は、表示装置でも良い。

管理装置１０は、定期的（例：１年毎）、或いは最初又は最後のカウントアップ日から所定日数（例：１００日）後、又はアラーム通知後に、カウント数をリセット（初期化）しても良い。或いは、代理店ＤＢ２０が、定期的に、カウント数をリセットしても良い。

［本実施形態固有の作用・効果］
注意や教育の必要のある代理店を早期に特定できるため、その代理店に対する注意や教育等が早い段階で実施できる。これにより、顧客への説明不足や混乱等の拡大を防ぐことができる。また、問い合わせ件数の削減や早期契約解除の抑止によりコストを改善することができる。また、企業イメージの悪化を防ぐこともできる。

＜ハードウェアの例示＞
以下に、本発明に係る代理店アラームシステムを実現するための具体的なハードウェアの例について説明する。

ここでは、管理装置１０、代理店ＤＢ２０、顧客ＤＢ３０、サポートＤＢ４０の各々の例として、ＰＣ（パソコン）、アプライアンス（ａｐｐｌｉａｎｃｅ）、シンクライアント用サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等の計算機を想定している。なお、端末やサーバに限らず、中継機器や周辺機器でも良い。また、計算機等に搭載される拡張ボードや、物理マシン上に構築された仮想マシン（ＶＭ：Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）でも良い。

図示しないが、上記のような計算機は、プログラムに基づいて駆動し所定の処理を実行するプロセッサと、当該プログラムや各種データを記憶するメモリと、ネットワークとの通信に用いられるインターフェースによって実現される。

上記のプロセッサの例として、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ネットワークプロセッサ（ＮＰ：Ｎｅｔｗｏｒｋ Ｐｒｏｃｅｓｓｏｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、或いは、専用の機能を有する半導体集積回路（ＬＳＩ：Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）等が考えられる。

上記のメモリの例として、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフラッシュメモリ等の半導体記憶装置、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の補助記憶装置、又は、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のリムーバブルディスクや、ＳＤメモリカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ ｍｅｍｏｒｙ ｃａｒｄ）等の記憶媒体（メディア）等が考えられる。また、バッファ（ｂｕｆｆｅｒ）やレジスタ（ｒｅｇｉｓｔｅｒ）等でも良い。或いは、ＤＡＳ（Ｄｉｒｅｃｔ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）、ＦＣ−ＳＡＮ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ − Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）、ＩＰ−ＳＡＮ（ＩＰ − Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等を用いたストレージ装置でも良い。

なお、上記のプロセッサ及び上記のメモリは、一体化していても良い。例えば、近年では、マイコン等の１チップ化が進んでいる。したがって、電子機器等に搭載される１チップマイコンが、上記のプロセッサ及び上記のメモリを備えている事例も考えられる。

上記のインターフェースの例として、ネットワーク通信に対応した基板（マザーボード、Ｉ／Ｏボード）やチップ等の半導体集積回路、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等のネットワークアダプタや同様の拡張カード、アンテナ等の通信装置、接続口（コネクタ）等の通信ポート等が考えられる。

また、ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ ＬＡＮ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ（ＩＥＥＥ ８０２．１６ａ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、専用線（ｌｅａｓｅ ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線、データバス等が考えられる。

但し、実際には、これらの例に限定されない。

＜備考＞
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。

１０… 管理装置
１１… 統括制御部
１２… 代理店ＤＢ管理部
１３… 顧客ＤＢ管理部
１４… サポートＤＢ管理部
１５… サポート担当者端末用通信部
１６… 管理者端末用通信部
２０… 代理店ＤＢ
３０… 顧客ＤＢ
４０… サポートＤＢ
５０… サポート担当者端末
６０… 管理者端末

Claims (13)

1. 代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢと、
   顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢと、
   顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢと、
   前記サポートＤＢに格納された該連絡内容区分が、申込済のサービスへの基本的な説明依頼、又は、契約申込から所定期間以内の契約解除の内、少なくとも１つを含むカウント対象区分か否か判定し、該連絡内容区分がカウント対象区分であれば、前記顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出し、前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算し、該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う管理装置と
   を含む
   代理店アラームシステム。
2. 代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢと、
   顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢと、
   顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢと、
   前記サポートＤＢに格納された該連絡内容区分がカウント対象区分か否か判定し、該連絡内容区分がカウント対象区分であれば、前記顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出し、前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算し、該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う管理装置と
   を含み、
   前記代理店ＤＢは、連絡内容区分又はカウント対象区分毎にカウント数を記憶し、
   前記管理装置は、前記代理店ＤＢに対し、連絡内容区分又はカウント対象区分に対応するカウント数に１を加算する
   代理店アラームシステム。
3. 請求項２に記載の代理店アラームシステムであって、
   前記顧客ＤＢは、更に、顧客の契約に関する２種類の項目を対応付けて格納する領域を持ち、
   前記代理店ＤＢは、既定の要因区分毎にカウント数を記憶し、
   前記管理装置は、前記顧客ＤＢに対し、前記２種類の項目と既定期間を比較し、要因毎の所定条件に合致するか判定し、判定結果に応じて、顧客の識別情報に対応する代理店の識別情報を抽出し、前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算する
   代理店アラームシステム。
4. 請求項２又は３に記載の代理店アラームシステムであって、
   前記第１の閾値は、連絡内容区分別、又は、要因区分別に複数の閾値があり、
   前記管理装置が、連絡内容区分毎、又は要因区分毎に個別にカウント数と各閾値とを比較する
   代理店アラームシステム。
5. 請求項１乃至４のいずれか一項に記載の代理店アラームシステムであって、
   前記顧客ＤＢは、更に、顧客の契約申込日を対応付けて格納する領域を持ち、
   前記管理装置は、顧客から契約解除の連絡があった際に、前記顧客ＤＢから該顧客の契約申込日を抽出し、該顧客の契約申込から契約解除までの期間が所定期間以内である場合、該顧客の識別情報に対応する代理店の識別情報を抽出し、前記サポートＤＢに該顧客の識別情報と早期契約解除を示す連絡内容区分とを格納し、前記代理店ＤＢに対し、該代理店の識別情報と早期契約解除を示す連絡内容区分とに応じたカウント数に１を加算し、該カウント数に基づく値が前記第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う
   代理店アラームシステム。
6. 請求項１乃至５のいずれか一項に記載の代理店アラームシステムであって、
   前記顧客ＤＢは、更に、顧客の決済登録日又は準備完了日を対応付けて格納する領域を持ち、
   前記管理装置は、定期的に、前記顧客ＤＢを参照し、顧客の契約申込から所定期間が経過しても決済登録日又は準備完了日が格納されていない場合、該顧客の識別情報に対応する代理店の識別情報を抽出し、前記代理店ＤＢに対し、該代理店の識別情報と決済未登録又は準備未完了を示す要因内容区分とに対応するカウント数に１を加算し、該カウント数に基づく値が前記第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う
   代理店アラームシステム。
7. 請求項１乃至６のいずれか一項に記載の代理店アラームシステムであって、
   前記管理装置は、前記カウント数に基づく値が、前記第１の閾値よりも小さい値である第２の閾値に達した場合、インターネット上の情報から前記代理店の名称を含む文章を抽出し、該文章を基に評判分析を実施し、実施結果に応じて、前記代理店の識別情報を含むアラーム通知を行う
   代理店アラームシステム。
8. 請求項１乃至７のいずれか一項に記載の代理店アラームシステムであって、
   顧客の識別情報と該顧客からの連絡内容とを入力し、該顧客からの連絡内容の入力データを解析し、解析結果を基に、連絡内容区分を決定するサポート担当者端末を更に含む
   代理店アラームシステム。
9. 代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢを管理する手段と、
   顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢを管理する手段と、
   顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢを管理する手段と、
   前記サポートＤＢに格納された該連絡内容区分が、申込済のサービスへの基本的な説明依頼、又は、契約申込から所定期間以内の契約解除の内、少なくとも１つを含むカウント対象区分か否か判定する手段と、
   該連絡内容区分がカウント対象区分であれば、前記顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出する手段と、
   前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算する手段と、
   該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う手段と
   を具備する
   管理装置。
10. 代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢを管理する手段と、
    顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢを管理する手段と、
    顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢを管理する手段と、
    前記サポートＤＢに格納された該連絡内容区分がカウント対象区分か否か判定する手段と、
    該連絡内容区分がカウント対象区分であれば、前記顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出する手段と、
    前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算する手段と、
    該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行う手段と、
    前記代理店ＤＢに、連絡内容区分又はカウント対象区分毎にカウント数を記憶する手段と、
    前記代理店ＤＢに対し、連絡内容区分又はカウント対象区分に対応するカウント数に１を加算する手段と
    を具備する
    管理装置。
11. 計算機により実施される代理店アラーム通知方法であって、
    代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢを管理するステップと、
    顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢを管理するステップと、
    顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢを管理するステップと、
    前記サポートＤＢに格納された該連絡内容区分が、申込済のサービスへの基本的な説明依頼、又は、契約申込から所定期間以内の契約解除の内、少なくとも１つを含むカウント対象区分か否か判定するステップと、
    該連絡内容区分がカウント対象区分であれば、前記顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出するステップと、
    前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算するステップと、
    該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行うステップと
    を含む
    代理店アラーム通知方法。
12. 計算機により実施される代理店アラーム通知方法であって、
    代理店の識別情報とカウント数とを対応付けて格納する領域を持つ代理店ＤＢを管理するステップと、
    顧客の識別情報と該顧客から契約申込を獲得した代理店の識別情報とを対応付けて格納する領域を持つ顧客ＤＢを管理するステップと、
    顧客の識別情報と該顧客からの連絡内容区分とを対応付けて格納する領域を持つサポートＤＢを管理するステップと、
    前記サポートＤＢに格納された該連絡内容区分がカウント対象区分か否か判定するステップと、
    該連絡内容区分がカウント対象区分であれば、前記顧客ＤＢから顧客の識別情報に対応する代理店の識別情報を抽出するステップと、
    前記代理店ＤＢに対し、該代理店の識別情報に対応するカウント数に１を加算するステップと、
    該カウント数に基づく値が第１の閾値に達した場合、該代理店の識別情報を含むアラーム通知を行うステップと、
    前記代理店ＤＢに、連絡内容区分又はカウント対象区分毎にカウント数を記憶するステップと、
    前記代理店ＤＢに対し、連絡内容区分又はカウント対象区分に対応するカウント数に１を加算するステップと
    を含む
    代理店アラーム通知方法。
13. 請求項１１又は１２に記載の代理店アラーム通知方法の各ステップを計算機に実行させるためのプログラム。

Images