JP2011113383A

JP2011113383A - 先回り案内推奨方法、プログラム及び装置

Info

Publication number: JP2011113383A
Application number: JP2009270422A
Authority: JP
Inventors: Takao Aoki; 隆夫青木; Tetsuro Takahashi; 哲朗高橋
Original assignee: Nifty Corp
Current assignee: Nifty Corp
Priority date: 2009-11-27
Filing date: 2009-11-27
Publication date: 2011-06-09
Anticipated expiration: 2029-11-27
Also published as: JP5368953B2

Abstract

【課題】顧客からの問い合わせに応対する際に将来さらに発生しうるコストを効果的に削減する。
【解決手段】顧客のIDと当該顧客からの問い合わせに応じて特定される第1状態と当該第1状態の後に発生した問い合わせに応じて特定される第2状態とを対応付けて格納する対応履歴格納部から、現問い合わせを行っている現顧客の現状態と同一の状態が第1状態として登録されているレコードを読み出し、読み出されたレコードを第2状態で分類し、上記分類毎に、当該分類に属するレコードに含まれる顧客及び現顧客の所定属性の属性値を取得し、各顧客の属性値と現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、属性指標の総和と当該分類に対応する応対コストとの積を抽出レコード数で除した値に比例する予測コスト値を算出し、予測コスト値の降順に第2状態をソートして、ソート結果を出力する。
【選択図】図１

Description

本発明は、サポートセンタなどにおいて顧客からの問い合わせに応対するための技術に関する。

多くの企業が自社製品又はサービスについての問い合わせに答えるため、サポートセンタ（コールセンタとも呼ぶ）を設けている。サポートセンタでは、日々膨大な問い合わせに対して応対しているが、問い合わせの件数が増加するにつれコストも増加している。

例えば特開２００４−１９２５２１号公報には、通信ネットワークを介して受け付けたユーザの問合せに対して、迅速で的確な回答をするための技術が開示されている。具体的には、問合せと回答とを対応づけたデータベースを用意し、ユーザからの問合せから抽出された情報を用いて関連する回答をデータベースから検索して自動的に返信する。データベースに回答が無い場合は、ユーザからの問合せから抽出された情報を用いて関連する関連部門のリストを作成する。リストは、ユーザからの問合せとの一致度が高い関連部門ほど上位になるように作成され、所定の条件を超えて忙しい関連部門は下位に回される。ユーザからの問合せは、リストの上位から順に自動的に転送される。関連部門のいずれかから回答が得られたとき、回答はユーザが希望する通信手段で配信される。しかしながら、問い合わせ自体を削減するようなことは検討されていない。

例えば、特開２００９−１９３４５７号公報には、ユーザと対話の中で、ユーザの優先度や現在のマッチング状況を的確に判断し、最適なマッチング結果を取得することができ、そのマッチング結果を参照して、的確な検索結果を得ることができるようにするための技術が開示されている。具体的には、情報検索装置は、ユーザとの対話により各属性に対する属性値を解析するユーザ発話解析手段と、ユーザ発話解析手段による解析結果として、複数の属性と各属性に対するユーザの属性値とを対応付けたユーザデータを保持するユーザデータ保持手段と、ユーザデータを参照して回答の得られた属性値の取得割合が所定値以上である場合に、複数の対象データから、ユーザデータの各属性及び各属性値にマッチする１又は複数の対象データ候補を選出するマッチング手段と、マッチング手段により選出された各対象データ候補をユーザ側に出力する対話制御手段とを備える。この技術でも、問い合わせ自体を削減するようなことは検討されていない。

さらに、特開２００６−６５３６６号公報には、問い合わせ窓口担当者が過去の類似問い合わせ事例を効率的に探したり、マーケティング担当者が、問い合わせデータを分類してパレート図を効率的に作成できるようにするための、データの全体像把握が可能なキーワード分類装置が開示されている。具体的には、キーワード抽出部によって抽出された名詞句で分類されたカテゴリ内に、共起表現抽出部によって抽出された名詞句に対する述語句で文書を分類したサブカテゴリを作成する分類部を備える。さらに、キーワード抽出部によって抽出された名詞句のキーワードにあわせて、類似キーワード検索部によって検索された類似キーワードをまとめて閲覧できるように表示する分類部を備える。また、キーワード抽出部によって抽出された名詞句で分類されたカテゴリ内に、共起表現抽出部によって抽出された名詞句に対する述語句で文書を分類したサブカテゴリを作成する分類部を備える。この技術でも、問い合わせ自体を削減するようなことは検討されていない。

また、特開２００１−２２２４５２号公報には、リレーショナルデータベースシステムにおいて、ユーザが求める基準における最適な処理手順の選択を可能にするための技術が開示されている。具体的には、リレーショナルデータベースシステムにおける問い合わせ処理最適化装置は、データをノード、データ間の依存関係をエッジとする有向グラフで問い合わせを表現して保持するアクセスプラン保持手段と、有向グラフのあるノードの近傍におけるノードの追加、削除、エッジの追加、削除の操作による変形ルールを変形前と後のノードとエッジの関係を提示することによって指示するルール指示手段と、有向グラフにルールを繰り返し適用して等価な有向グラフを列挙するルール適用手段と、列挙された有向グラフの中で見積もられるコストが最小であるアクセスプランを選択するアクセスプラン選択手段とを有する。コストについては、処理に必要なコストであり、次回問い合わせに回答するためのコストではない。

さらに、特開平９−３０５４０６号公報には、複数の関連するタスクの問題解決プロセスを関連付けて一貫性を持った形で、しかも利用者の負担を要することなく解を導くことができ、利用者の予期しない複数のタスク間の関連付けを利用者に指摘するなどして利用者の業務効率や成果を向上させることができるようにするための技術が開示されている。具体的には、１つ以上のタスクについて管理し、関連するタスクどうしの連関性を管理する機能を持ち、所定のもしくは利用者が指定した初期タスクの解決から開始し、あるタスクについての問題解決の状況が所定の状態になると、次の関連するタスクを探索しその個別タスク実行を指示する機能を持つ手段を設けることで、例えば医師のスケジューリングタスクと看護婦のスケジューリングタスクを連関させて連続して問題解決を行うなど、複数の関連するタスクについてタスク間の一貫性を失うことなく、また利用者に多大な負担をかけることなく順に問題解決を行うことができる。さらに、タスク連鎖モデルを用いて上記のタスク同士の連関を管理し、実行するタスクを探索する手段を設けることで、例えば医師のスケジューリングタスクが終了し次のタスクを探索する際に、例えば前回の懇親会から１ヵ月以上経過していると、次のタスクとして懇親会スケジューリングを探索結果として得て利用者に提案することで、利用者の予期しないタスクを利用者に提案して利用者の業務効率や成果を向上させることができるようになっている。しかしながら、次に発生するであろうタスクを削減してコストを削減するようなことは検討されていない。

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

上で述べたように、現在存在する技術には、顧客からの問い合わせに応対するコストを効果的に削減するような観点がない。

従って、本発明の目的は、サポートセンタなどにおいて顧客からの問い合わせに応対する際に将来さらに発生しうるコストを効果的に削減するための技術を提供することである。

本先回り案内推奨方法は、（Ａ）顧客の識別情報と当該顧客からの問い合わせを含むアクションに応じて特定される第１の状態の第１状態コードと当該第１の状態の後に発生したアクションに応じて特定される第２の状態の第２状態コードとを対応付けて格納する対応履歴データ格納部から、現問い合わせを行っている現顧客の現状態の状態コードと同一の状態コードが第１状態コードとして登録されているレコードを読み出すステップと、（Ｂ）読み出されたレコードを第２状態コードで分類するステップと、（Ｃ）上記分類毎に、当該分類に属するレコードに含まれる顧客の識別情報及び現顧客の識別情報により会員データ格納部から所定属性の属性値を読み出し、各顧客の属性値と現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、状態コード毎に応対コストが登録されている応対コスト格納部から当該分類についての第２状態コードに対応付けられている応対コストを読み出し、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値に比例する予測コスト値を算出し、当該分類についての第２状態コードに対応付けて、予測コスト値格納部に格納する予測コスト値算出ステップと、（Ｄ）予測コスト値格納部に格納されている第２の状態を予測コスト値の降順にソートして、当該ソート結果を出力データ格納部に格納するステップとを含む。

このように次に発生する可能性のある問い合わせの予測コスト値を算出すれば、例えばサポートセンタのオペレータは、コスト削減効果が高い問い合わせを把握できるようになる。従って、オペレータが、今回の問い合わせへの応対で、可能性のある次の問い合わせに対する応対（すなわち先回り案内）をも併せて行えば、効果的に次回問い合わせを削減することができ、コスト削減効果を得ることができる。また、顧客側も利便性が向上し、問い合わせに対する満足感が高くなる。

また、上で述べた対応履歴データ格納部が、第１の状態と第２の状態との間隔を特定するための情報（たとえば間隔そのもの又は第１及び第２の状態の発生日付）をさらに格納している場合もある。この場合、上で述べた予測コスト値算出ステップが、上記分類に属するレコードについて、第１の状態と第２の状態との間隔の平均値を算出するステップと、第１の状態と第２の状態との間隔の平均値に応じて、第１の状態から第２の状態への状態遷移がより近い将来に発生する蓋然性を表す第１の係数値を算出するステップとを含むようにしてもよい。そして、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値に対して、第１の係数値が乗じられるようにしてもよい。

例えば間隔が短い、すなわち近い将来起こりやすい状態遷移に比較的大きな係数値を設定することで、適切な予測コスト値を得ることができるようになる。

さらに、上で述べた予測コスト値算出ステップが、分類に属するレコードについて、第１の状態と第２の状態との間隔の標準偏差を算出するステップと、第１の状態と第２の状態との間隔の標準偏差に応じて、第１の状態と第２の状態との間隔の信頼性を表す第２の係数値を算出するステップとをさらに含むようにしてもよい。そして、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値と第１の係数値の積に対して、第２の係数値が乗じられるようにしてもよい。間隔のばらつきが大きい状態遷移についてはあまりその間隔の平均値を信用できず、間隔のばらつきが小さい状態遷移については間隔の平均値を信用できるので、そのような信頼度を反映させることで、適切な予測コスト値を得ることができるようになる。

また、上で述べた対応履歴データ格納部が、第２の状態の発生日をさらに格納するようにしてもよい。この場合、上で述べた予測コスト値算出ステップが、上記分類に属するレコードについて、第２の状態の発生日から現日付までの間隔の平均値を算出するステップと、第２の状態の発生日から現日付までの間隔の平均値に応じて、上記分類に属するレコードの鮮度に応じた信頼性を表す第３の係数値を算出するステップとをさらに含む。そして、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値と第１及び第２の係数値の積に対して、第３の係数値が乗じられるようにしてもよい。状態遷移が最近頻繁に発生しているのか過去良く発生していたものかでは、より最近頻繁に発生している方が信頼性が高い。従って、上で述べたような演算により、適切な予測コスト値を算出することができるようになる。

本発明に係る方法は、コンピュータ・ハードウエアとプログラムとの組み合わせにより実施される場合があり、本発明に係るプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

本発明によれば、サポートセンタなどにおいて顧客からの問い合わせに応対する際に将来さらに発生しうるコストを効果的に削減することができる。

図１は、本発明の実施の形態におけるシステム概要図である。図２は、問い合わせ予測サーバの機能ブロック図である。図３は、時系列の問い合わせの一例を示す図である。図４は、本実施の形態の概要を表す図である。図５は、入会データ取得部の処理フローを示す図である。図６は、会員ＤＢに格納されるデータの一例を示す図である。図７は、対応履歴ＤＢに格納されるデータの一例を示す図である。図８は、問い合わせデータ取得部の処理フローを示す図である。図９は、有向グラフデータ格納部に格納されるデータの一例を示す図でる。図１０は、問い合わせ予測部の処理フローを示す図である。図１１は、スコア計算処理の処理フローを示す図である。図１２は、コストデータ格納部６４に格納されるデータの一例を示す図である。図１３は、予測結果格納部に格納されるデータの一例を示す図である。図１４は、オペレータ端末における出力表示画面を示す図である。図１５は、コンピュータの機能ブロック図である。

図１に、本発明の実施の形態に係るシステム概要を示す。例えば、サポートセンタでは、オペレータ毎に、オペレータ端末と電話機１１とが用意される。なお、オペレータ端末と電話機とが一体化されている場合もある。例えばオペレータ端末Ａ乃至Ｅは、ＬＡＮ（Local Area Network）などのネットワーク１に接続されており、当該ネットワーク１には、本実施の形態における主要な処理を実施する問い合わせ予測サーバ５と、会員管理サーバ９と、ＣＴＩ（Computer Telephony Integration）システム７と、サポートセンタサーバ１３も接続されている。ＣＴＩシステム７については、従来と同様であり、例えば自動音声応答にて、問い合わせを行ってきた顧客の識別子（ＩＤ）を特定し、問い合わせの内容（又はその一部）を尋ねて特定するなどの処理を実施し、さらに空いている又は適切なオペレータに割り振る処理も実施する。会員管理サーバ９も、従来と同様で、顧客の入会や退会のための処理を実施する。サポートセンタサーバ１３についても、従来と同様であり、オペレータ端末Ａ乃至Ｅと連携して、顧客からの問い合わせの応対に必要なデータ、例えば応対に必要な情報や過去の問い合わせ履歴などをオペレータ端末Ａ乃至Ｅに出力する。オペレータ端末Ａ乃至Ｅは、サポートセンタサーバ１３やＣＴＩシステム７と連携するためのプログラムがインストールされて実行されているものとする。そして、会員管理サーバ９には、会員ＤＢ９１が接続されており、会員管理サーバ９及びネットワーク１を介して他の装置から会員ＤＢ９１にアクセス可能となっている。

次に、問い合わせ予測サーバ５の機能ブロック図を図２に示す。問い合わせ予測サーバ５は、状態定義データ格納部５２と、状態定義データ格納部５２に格納されているデータを用いて処理を行う問い合わせデータ取得部５１と、会員管理サーバ９から会員の入会に関するデータを取得する入会データ取得部５３と、入会データ取得部５３及び問い合わせデータ取得部５１の出力を格納する対応履歴ＤＢ５４と、対応履歴ＤＢ５４に格納されているデータを用いて処理を行う有向グラフ生成部５５と、有向グラフ生成部５５によって生成された有向グラフデータを格納する有向グラフデータ格納部５６と、コストデータを格納するコストデータ格納部６４と、問い合わせデータ取得部５１からの出力に応じて有向グラフデータ格納部５６とコストデータ格納部６４とに格納されているデータを用いて処理を実施する問い合わせ予測部５７と、問い合わせ予測部５７からの指示に応じて会員データを会員管理サーバ９から取得する会員データ取得部５９と、会員データ取得部５９が取得した会員データを格納する会員データ格納部６２と、問い合わせ予測部５７の処理結果を格納する予測結果格納部６１と、状態定義データ格納部５２に格納されているデータを用いて予測結果格納部６１に格納されているデータを処理して出力する出力部６３とを有する。なお、問い合わせ予測部５７は、会員データ格納部６２に格納されているデータをも用いて処理を行う。

本実施の形態では、以下のような状況を想定する。すなわち、図３に示すように、特定のプロバイダに入会した顧客が、２００９年９月１日に「接続」についての問い合わせを行った後、同年９月８日には「メール」について質問を行っている。さらに、同年９月３０日には「ブログ」について質問を行って、さらに２０１０年９月１日には「解約」についての問い合わせを行っている。このように、顧客は、インターネット接続サービスの利用進捗状況に応じて時系列に問い合わせを行っている場合が多い。このような問い合わせの履歴については、サポートセンタサーバ１３に蓄積して、過去の問い合わせ状況を統計的に分析したり、個別に参照するような処理に用いているだけであった。

そこで、本実施の形態では、図４中央に示すように、問い合わせを１つの状態として取り扱い、問い合わせの履歴を状態遷移としてとらえて有向グラフを仮想的に構成する。図４中央に示すように、どの問い合わせの後に、どのような問い合わせが発生する可能性があるかについてや、例えば「接続」の問い合わせの後に「メール」の問い合わせを行う確率や「ブログ」の問い合わせを行う確率は、複数の顧客の問い合わせの履歴から導出することができる。但し、完全な有向グラフを生成する必要はなく、各状態遷移を把握することができれば十分である。そして、本実施の形態では以下でも述べるが、問い合わせを行ってきた顧客の属性情報（図４左側）と、コスト削減効果（図４右側）とを併せて考慮した上で、オペレータに、次の問い合わせを効果的に防止又は低減するための先回り案内の候補を提示する。

以下、このような先回り案内の候補を提示するために必要な処理について図５乃至図１４を用いて説明する。最初に、前処理として有向グラフデータの生成までを説明する。

最初に、問い合わせ予測サーバ５における入会データ取得部５３の処理について図５を用いて説明する。入会データ取得部５３は、例えば所定の周期又は任意のタイミングで、会員管理サーバ９に対して、新規会員のＩＤ及び入会日のデータを要求する。会員管理サーバ９は、会員ＤＢ９１から該当する会員のＩＤ及び入会日のデータを読み出し、問い合わせ予測サーバ５の入会データ取得部５３に送信する。会員ＤＢ９１には、例えば図６に示すようなデータが格納されている。図６の例では、会員のＩＤと、性別と、年齢（具体的には年代）と、婚姻の有無と、住居の種別と、子供の人数と、職業と、住所と、料金コースと、入会年月日と、支払方法とを、各会員について登録するようになっている。

そして、入会データ取得部５３は、会員管理サーバ９から、会員ＩＤ及び入会日のデータを取得し（ステップＳ１）、状態コード「０」と会員ＩＤ及び入会日を含むレコードを、対応履歴ＤＢ５４に登録する（ステップＳ３）。例えば対応履歴ＤＢ５４には、図７に示すようなデータが格納される。図７の例では、会員のＩＤと、日付と、状態コードとが登録されるようになっている。ステップＳ３では、状態コード「０」のレコードを登録する。

図５の処理については、例えば会員管理サーバ９が新規会員登録のための処理を実施した際に、会員ＩＤ及び入会日のデータを自発的に入会データ取得部５３に通知するようにして、通知に応じて実施するようにしても良い。さらに、既に会員ＤＢ９１に登録されている既存の顧客については、会員ＩＤ及び入会日のデータを一括して取得して対応履歴ＤＢ５４に登録するようにしても良い。

次に、図８を用いて、問い合わせデータ取得部５１により実施される前処理について説明する。問い合わせデータ取得部５１は、例えばＣＴＩシステム７又はオペレータ端末から、今回問い合わせを行ってきた顧客のＩＤを取得する（ステップＳ１１）。例えば、ＣＴＩシステム７が出力した音声ガイダンスに対して、顧客がプッシュ音等にてＩＤを入力した場合には、ＣＴＩシステム７からその会員のＩＤを取得する。また、ＣＴＩシステム７が音声認識機能を有しており、顧客が会員ＩＤを発声した場合にも、ＣＴＩシステム７から音声認識結果に含まれる会員ＩＤを取得する。場合によっては、オペレータが顧客から会員ＩＤを聞き出して、オペレータ端末に入力する場合もある。その場合には、オペレータ端末から、会員ＩＤを取得する。

また、問い合わせデータ取得部５１は、例えばＣＴＩシステム７又はオペレータ端末から、現在の状態コードを取得する（ステップＳ１３）。ステップＳ１１と同様に、ＣＴＩシステム７が、問い合わせを行ってきた顧客に対して１又は複数の質問を出力し、それら質問の回答の結果として問い合わせの内容を表す状態コードが特定される場合には、ＣＴＩシステム７から取得する。また、オペレータが顧客から問い合わせの内容を聞き出して、当該問い合わせの内容を表す状態コードをオペレータ端末に入力した場合には、当該オペレータ端末から取得する。

そして、問い合わせデータ取得部５１は、本日の日付と共に顧客のＩＤ及び状態コードを、対応履歴ＤＢ５４に登録する（ステップＳ１５）。図７に示したように、問い合わせ毎にレコードが追加される。

なお、ステップＳ１１乃至Ｓ１５は、新規に問い合わせを行ってきた場合に実施されるが、例えばサポートセンタサーバ１３に蓄積されている過去の応対データからデータを取得した場合にも類似の処理を実施する。通常、サポートセンタサーバ１３に蓄積されている過去の応対データには、問い合わせを行ってきた顧客の会員ＩＤ及び日付に加えて、問い合わせの内容及び回答の内容についてのデータを含む。問い合わせの内容及び回答の内容についてのデータについては、自由文で記載されている場合もあれば、所定のフォーマットで問い合わせ内容及び回答の内容が整理されている場合もある。従って、例えば状態定義データ格納部５２に、サポートセンタサーバ１３に蓄積されているデータの形態に応じて状態コードを付与するルールや定義データを用意しておき、問い合わせデータ取得部５１が、当該状態定義データ格納部５２に格納されているルールや定義データに従って状態コードを付与するものとする。このようなテキスト解析については従来から存在しているものであるから、ここではこれ以上述べない。

また、ステップＳ１１及びＳ１３で取得したデータについては、問い合わせ予測部５７に出力する。問い合わせ予測部５７は、データを受け取ると、図１０に示すような処理を実施して、担当オペレータに、先回り案内についての推奨データを提示する。

次に、有向グラフ生成部５５は、例えば所定の周期又は任意のタイミング（例えば新たにレコードが登録される毎）で、対応履歴ＤＢ５４に蓄積された新規レコードの各々について、同一会員ＩＤについて直前のレコードを抽出する（ステップＳ１７）。図７の例で最後のレコードが処理対象であるとすると、ＩＤ「ａｂｃ１２３４５」と同一のＩＤを含む直前のレコードは、最後から２番目のレコードである。この最後から２番目のレコードが処理対象であるとすると、ＩＤ「ａｂｃ１２３４５」と同一のＩＤを含む直前のレコードは、処理対象レコードの２行上のレコードである。

そして、有向グラフ生成部５５は、処理対象のレコードと抽出レコードとの対にて状態遷移データを生成して、有向グラフデータ格納部５６に登録する（ステップＳ１９）。本実施の形態に係る状態遷移データは、会員ＩＤと、抽出レコードの状態コードと、処理対象レコードの状態コードと、処理対象レコードに含まれる日付と抽出レコードに含まれる日付との差である間隔と、処理対象レコードに含まれる日付とを含む。図９に有向グラフデータ格納部５６に格納されるデータの一例を示す。図９の例では、会員ＩＤと、抽出レコードの状態コード（状態１）と、処理対象レコードの状態コード（状態２）と、処理対象レコードに含まれる日付と抽出レコードに含まれる日付との差である間隔と、処理対象レコードに含まれる日付（日付２）とが登録されるようになっている。

このように本実施の形態では、有向グラフ全体を生成するのではなく、２つの状態間の状態遷移のデータを用意しておく。なお、２つの状態間の状態遷移ではなく、３つ以上の状態の状態遷移によって１レコードを生成するようにしても良い。

有向グラフデータ格納部５６に格納されたデータによれば、誰がどのような問い合わせを行った後にさらにどのような問い合わせを行ったかが分かる。さらに、問い合わせの間の日数及び本レコードの鮮度を表す後の問い合わせを行った日付をも得ることができる。なお、日付２だけではなく、日付１も登録することによって、間隔をその都度計算するようにしてもよい。

次に、問い合わせ予測部５７等の処理について図１０乃至図１４を用いて説明する。問い合わせ予測部５７は、問い合わせデータ取得部５１から、問い合わせ顧客の会員ＩＤ（ここではｉｄ_cと記す）及び現在の状態コードｓ_cを取得する（ステップＳ２１）。そして、問い合わせ予測部５７は、状態１の状態コード（すなわち遷移元の状態の状態コード）が現在の状態コードｓ_cと一致するレコードを、有向グラフデータ格納部５６から抽出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ２３）。例えば本ステップでレコード数をカウントしておく。すなわち、状態コードｓ_cで「状態１」の列を検索して該当するレコードを抽出する。そして、スコア計算処理を実施する（ステップＳ２５）。

スコア計算処理については図１１を用いて説明する。まず、問い合わせ予測部５７は、抽出レコード集合Ｓを、状態２の状態コードｓ_jによってサブセットＳ_jに分類する（ステップＳ３１）。状態１の状態コードはステップＳ２３からして全て同じであるから、状態２の状態コードに応じて分類する。状態２の状態コードによって、次になされる可能性のある問い合わせが特定される。

そして、問い合わせ予測部５７は、全てのサブセットＳ_jについて処理したか判断する（ステップＳ３３）。未処理のサブセットＳ_jが存在する場合には、問い合わせ予測部５７は、未処理のサブセットＳ_jを１つ特定する（ステップＳ３５）。そして、問い合わせ予測部５７は、サブセットＳ_jに含まれるレコードの間隔の平均値を算出すると共に、標準偏差についても算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ３７）。平均値及び標準偏差については周知であるから、これ以上述べない。ここで間隔の平均値をｉ_meanと記し、標準偏差をｉ_SDと記すものとする。

また、問い合わせ予測部５７は、サブセットＳ_jに含まれる日付２の日付から現在日付（例えばシステム時計から取得）までの日数の平均値ｒを算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ３９）。そして、問い合わせ予測部５７は、サブセットＳ_jに含まれるＩＤを会員データ取得部５９に出力し、会員データの取得を要求する。会員データ取得部５９は、問い合わせ予測部５７から受け取ったＩＤを含む検索要求を会員管理サーバ９に出力し、会員管理サーバ９は、受信した検索要求に含まれるＩＤで会員ＤＢ９１を検索して該当するレコードを読み出し、問い合わせ予測サーバ５の会員データ取得部５９に送信する。会員データ取得部５９は、会員管理サーバ９から該当レコードを受信し、会員データ格納部６２に格納する。そうすると、問い合わせ予測部５７は、会員データ格納部６２に格納されているデータを用いて、ｓｉｍ（ｉｄ_c，ｉｄ_d）（ｉｄ_dはサブセットＳ_jに含まれるレコード内の各ＩＤであり、ｉｄ_cは問い合わせデータ取得部５１から受け取ったＩＤである。）を算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ４１）。なお、本ステップにおいてｓｉｍ（ｉｄ_c，ｉｄ_d）の総和を算出するようにしてもよい。

ここで関数ｓｉｍ（ｉｄ１，ｉｄ２）は以下のように定義される。

ここでａｔｔｒ（ｉｄ，ａ）は、会員ＩＤ「ｉｄ」の顧客のａという属性の属性値を表す。「ａ」という属性は、図６に示したように、本実施の形態では、ａ１が性別であり、ａ２は年齢であり、ａ３は婚姻の有無であり、ａ４は住居の有無であり、ａ５は子供の人数であり、ａ６は職業であり、ａ７は住所であり、ａ８は料金コースであり、ａ９は入会年月日であり、ａ１０は支払方法である。但し、このような属性に限定するものではなく、会員属性のうち特に問い合わせに関連する会員属性を抽出できればよい。また、ここでは属性を１０個用いる例を示しているが、１０に限定するものではなく他の個数であっても良い。

さらに、ｍａｔｃｈ（ｂ１，ｂ２）は、以下のように定義される。

このように一致していれば「１」で、不一致であれば「０」であるが、属性によっては区分が一致しているか否かで「１」か「０」を分けても良い。例えば、入会年月日については、入会年月日の入会年月だけを用いるようにしても良い。さらに住所についても例えば県より下の行政区画までを比較するようにしても良い。

また、ｗ_iは、ｉ番目の属性の重み値であり、（１）式の分母は、重み値の総和を表している。

そして、問い合わせ予測部５７は、コストデータ格納部６４から処理対象のサブセットＳ_jについての状態１の状態コードｓ_jに対応付けられているコストｃ（ｓ_j）を読み出し、予測コスト値Ｃｏｓｔ（ｉｄ_c，ｓ_c，Ｓ_j，ｓ_j）を算出し、状態２の状態コードに対応付けて予測結果格納部６１に格納する（ステップＳ４３）。図１２に、コストデータ格納部６４に格納されるデータの一例を示す。図１２の例では、状態コードに対応付けて応対のコスト（例えば「分」単位）が登録されるようになっている。本実施の形態では、状態コードに対応する問い合わせについて１回応対するのに必要な時間をコストとして採用する。

そしてＣｏｓｔ（ｉｄ_c，ｓ_c，Ｓ_j，ｓ_j）は、以下のように定義される。

（２）式で、｜Ｓ｜は、集合Ｓのレコード数を表す。また、上でも述べたが、Ｓ_jは処理に係るサブセットを表し、Ｃ（ｓ_j）は、コストデータ格納部６４から読み出した状態コードｓ_jに対応するコスト値である。また、ｉｄ_dはサブセットＳ_jに含まれるレコード内のＩＤであり、ｉｄ_cは問い合わせ顧客の会員ＩＤであり、ｉ_meanはサブセットＳ_jに含まれるレコード内の間隔の平均値であり、ｉ_SDはサブセットＳ_jに含まれるレコード内の間隔の標準偏差であり、ｒはサブセットＳ_jに含まれるレコードの日付２の日付から現在日付までの平均値である。

ｉ_meanの値が大きいということは、状態コードｓ_jの状態になるまでの平均的な間隔が長いということである。従って、より短い間隔で発生しそうな問い合わせを優先するため、ｉ_meanが大きいほど、予測コスト値Ｃｏｓｔの値が小さくなるように、ｅｘｐ｛−ｉ_mean／α｝（αは例えば「５」あたりが適切。）という値を乗じている。

また、ｉ_SDの値が大きいということは、１つ前の状態からこの状態になる間隔にばらつきが大きいということである。従って、それだけ間隔を予測しづらいということであり、間隔の平均値の信頼性が低いということを表している。そのため、この値が大きいほど、コスト予測値Ｃｏｓｔの値が小さくなるように、ｅｘｐ｛−ｉ_SD／β｝（βは例えば「１」あたりが適切。）という値を乗じている。

さらに、ｒの値が大きいということは、次の状態を予測するために使ったデータが古いということである。従って、現在の問い合わせのトレンドとはずれが生じている場合があり、信頼性が低い。従って、より新しいデータを使った予測を優先するために、ｒが大きいほど予測コスト値Ｃｏｓｔの値が小さくなるように、ｅｘｐ｛−ｒ／γ｝（γは例えば「１０」あたりが適切。）という値を乗じている。

なお、ｅｘｐ｛−ｘ／ｙ｝は、０から１の値を取り、ｘが大きいほど０に近づき、ｙが大きいほど、緩やかに減衰する関数である。

予測結果格納部６１に格納されるデータの一例を図１３に示す。図１３の例では、状態２についての状態コードｓ_jに対応付けて、ステップＳ４３で算出された予測コスト値Ｃｏｓｔが登録されるようになっている。

ステップＳ４３が終了するとステップＳ３３に戻り、問い合わせ予測部５７は、全てのサブセットＳ_jについて処理したか判断し、全てのサブセットＳ_jについて処理が完了した場合には、問い合わせ予測部５７は、予測コスト値Ｃｏｓｔの値で状態２の状態コードｓ_jを降順にソートし、ソート結果を予測結果格納部６１に格納する（ステップＳ４５）。そして元の処理に戻る。

このように予測コスト値が高いものから低いものへ並べ替えて、予測コスト値が高い状態コードを優先する。すなわち、先回り案内を行うことによって、次の問い合わせを防止及び削減して、コスト削減効果が大きくなるようなものを優先するということである。より具体的には、今回の応対にかかる時間は多少長くなるが、問い合わせの件数が多くなる方がコストが高くなる場合に有効である。

図１０の処理の説明に戻って、出力部６３は、予測結果格納部６１から問い合わせ予測部５７の処理結果を読み出し、担当するオペレータのオペレータ端末に送信する（ステップＳ２７）。担当するオペレータのオペレータ端末については、例えばＣＴＩシステム７等、担当オペレータの割り当てを行う装置から割り当て情報を取得して特定する。この際、例えば状態定義データ格納部５２の状態定義データを参照して、状態コードに対応する問い合わせ内容データを抽出して、予測結果格納部６１から読み出した処理結果に含まれる状態コードを問い合わせ内容に置換して出力する。ネットワーク１を介してオペレータ端末は、問い合わせ予測サーバ５からデータを受信して表示装置に表示する。例えば、図１４に示すようなデータが表示される。図１４の例では、併せてご案内するとよい事項として、「１．ブログ・・・」「２．セキュリティ・・・」「３．スパム・・・」というような予測問い合わせ内容が列挙される。このような次の問い合わせを防止することによって、コスト削減を行う。さらに、顧客にとっても、何度も問い合わせを行わずにすみ、さらに付加的な情報をもらうことになるので、利便性が向上し、顧客満足度が向上する。なお、図１４で表示される内容に、予測コスト値を含めるようにしても良い。さらに、例えばサポートセンタサーバ１３から、問い合わせ内容に対応する応対内容についてのデータを取得して、併せて提示するようにしても良い。

以上のような処理を実施することによって、サポートセンタ等において顧客からの問い合わせの件数を効果的に削減することができるようになる。すなわち、コストの削減が可能となる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１には様々なコンピュータで上で述べたような機能を実現する例を示したが、より少ないコンピュータ又はより多くのコンピュータで同様の機能を実現するようにしても良い。さらに、図２に示した問い合わせ予測サーバ５の機能ブロック図は一例であって、実際のプログラムモジュール構成とは一致しない場合もある。また、処理フローについても、処理結果が変わらない限り、処理順番を入れ替えたり、並列実施することも可能である。例えば、予測コスト値を計算するのに必要な値を算出する処理については、順番を入れ替えたり並列実行してもよい。また、問い合わせ予測サーバ５の全部又は一部の機能を、オペレータ端末で実施するようにしてもよい。

また、予測コスト値Ｃｏｓｔの計算式（２）については、変形が可能である。すなわち、ｉ_mean、ｉ_SDやｒについての減衰カーブについては、他の減衰カーブを採用しても良い。さらに、現在の計算式（２）では、属性値のみ個別レコードの値を反映させているが、例えば個別レコードの間隔や日付２の日付から現在日付までの日数を、上で述べたように大きな値ほど小さく減衰させるような関数で変換して例えば分子のΣの内部に反映させるようにしてもよい。

さらに、上の例では問い合わせ１件ごとのコストが高いため、２件を１件にまとめて１件あたりの応対時間が長くなっても良いというポリシーで状態２の状態コードをソートしていた。しかし、別のポリシーを採用する場合もある。例えば、少しの手間で先回り案内できる問い合わせについて優先するというポリシーである。この場合には、応対時間の短いものほど予測コスト値が高くなるようにＣｏｓｔの計算式を変形する必要がある。

また、サポートセンタの例を示したが、顧客からの問い合わせに応対する必要があり、問い合わせ件数を削減する必要がある他のサービスにも本発明は、適用可能である。

なお、上では述べていないが、状態２が「解約」を表す状態でありそのような状態が予測結果において比較的上位にランキングされる場合がある。この場合には、オペレータに特別に警告を発して、解約防止のための応対を必ず行うように依頼するようにしても良い。なお、解約などの重大な状態については、コストデータ格納部６４においてコストを非常に大きな値に設定するなどの工夫も行いうる。

なお、問い合わせ予測サーバ５、ＣＴＩシステム７、会員管理サーバ９、サポートセンタサーバ１３及びオペレータ端末は、コンピュータ装置であって、図１５に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

１ネットワーク５問い合わせ予測サーバ
７ＣＴＩシステム９会員管理サーバ
１３サポートセンタサーバ９１会員ＤＢ
５１問い合わせデータ取得部５２状態定義データ格納部
５３入会データ取得部５４対応履歴ＤＢ
５５有向グラフ生成部５６有向グラフデータ格納部
５７問い合わせ予測部５９会員データ取得部
６１予測結果格納部６２会員データ格納部
６３出力部６４コストデータ格納部

Claims

顧客の識別情報と当該顧客からの問い合わせを含むアクションに応じて特定される第１の状態の第１状態コードと当該第１の状態の後に発生したアクションに応じて特定される第２の状態の第２状態コードとを対応付けて格納する対応履歴データ格納部から、現問い合わせを行っている現顧客の現状態の状態コードと同一の状態コードが前記第１状態コードとして登録されているレコードを読み出すステップと、
読み出された前記レコードを前記第２状態コードで分類するステップと、
前記分類毎に、当該分類に属するレコードに含まれる前記顧客の識別情報及び前記現顧客の識別情報で会員データ格納部から所定属性の属性値を読み出し、各前記顧客の属性値と前記現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、状態コード毎に応対コストが登録されている応対コスト格納部から当該分類についての前記第２状態コードに対応付けられている応対コストを読み出し、前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値に比例する予測コスト値を算出し、当該分類についての前記第２状態コードに対応付けて、予測コスト値格納部に格納する予測コスト値算出ステップと、
前記予測コスト値格納部に格納されている前記第２状態コードを前記予測コスト値の降順にソートして、当該ソート結果を出力データ格納部に格納するステップと、
を含み、コンピュータに実行される先回り案内推奨方法。
前記対応履歴データ格納部が、前記第１の状態と前記第２の状態との間隔を特定するための情報をさらに格納しており、
前記予測コスト値算出ステップが、
前記分類に属するレコードについて、前記第１の状態と前記第２の状態との間隔の平均値を算出するステップと、
前記第１の状態と前記第２の状態との間隔の平均値に応じて、前記第１の状態から前記第２の状態への状態遷移がより近い将来に発生する蓋然性を表す第１の係数値を算出するステップと、
を含み、
前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値に対して、前記第１の係数値が乗じられる
ことを特徴とする請求項１記載の先回り案内推奨方法。
前記予測コスト値算出ステップが、
前記分類に属するレコードについて、前記第１の状態と前記第２の状態との間隔の標準偏差を算出するステップと、
前記第１の状態と前記第２の状態との間隔の標準偏差に応じて、前記第１の状態と前記第２の状態との間隔の信頼性を表す第２の係数値を算出するステップと、
をさらに含み、
前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値と前記第１の係数値の積に対して、前記第２の係数値が乗じられる
ことを特徴とする請求項２記載の先回り案内推奨方法。
前記対応履歴データ格納部が、前記第２の状態の発生日をさらに格納しており、
前記予測コスト値算出ステップが、
前記分類に属するレコードについて、前記第２の状態の発生日から現日付までの間隔の平均値を算出するステップと、
前記第２の状態の発生日から現日付までの間隔の平均値に応じて、前記分類に属するレコードの鮮度に応じた信頼性を表す第３の係数値を算出するステップと、
をさらに含み、
前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値と前記第１及び第２の係数値の積に対して、前記第３の係数値が乗じられる
ことを特徴とする請求項３記載の先回り案内推奨方法。
請求項１乃至４のいずれか１つ記載の先回り案内推奨方法をコンピュータに実行させるためのプログラム。
顧客の識別情報と当該顧客からの問い合わせを含むアクションに応じて特定される第１の状態の第１状態コードと当該第１の状態の後に発生したアクションに応じて特定される第２の状態の第２状態コードとを対応付けて格納する対応履歴データ格納部から、現問い合わせを行っている現顧客の現状態の状態コードと同一の状態コードが前記第１状態コードとして登録されているレコードを読み出す手段と、
読み出された前記レコードを前記第２状態コードで分類する手段と、
前記分類毎に、当該分類に属するレコードに含まれる前記顧客の識別情報及び前記現顧客の識別情報で会員データ格納部から所定属性の属性値を読み出し、各前記顧客の属性値と前記現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、状態コード毎に応対コストが登録されている応対コスト格納部から当該分類についての前記第２状態コードに対応付けられている応対コストを読み出し、前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値に比例する予測コスト値を算出し、当該分類についての前記第２状態コードに対応付けて、予測コスト値格納部に格納する予測コスト値算出手段と、
前記予測コスト値格納部に格納されている前記第２状態コードを前記予測コスト値の降順にソートして、当該ソート結果を出力データ格納部に格納する手段と、
を有する先回り案内推奨装置。