(57)【要約】【課題】顧客からの問い合わせに応対する際に将来さらに発生しうるコストを効果的に削減する。【解決手段】顧客のIDと当該顧客からの問い合わせに応じて特定される第1状態と当該第1状態の後に発生した問い合わせに応じて特定される第2状態とを対応付けて格納する対応履歴格納部から、現問い合わせを行っている現顧客の現状態と同一の状態が第1状態として登録されているレコードを読み出し、読み出されたレコードを第2状態で分類し、上記分類毎に、当該分類に属するレコードに含まれる顧客及び現顧客の所定属性の属性値を取得し、各顧客の属性値と現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、属性指標の総和と当該分類に対応する応対コストとの積を抽出レコード数で除した値に比例する予測コスト値を算出し、予測コスト値の降順に第2状態をソートして、ソート結果を出力する。【選択図】図１
2011113383.tif 000002
【特許請求の範囲】
【請求項１】
顧客の識別情報と当該顧客からの問い合わせを含むアクションに応じて特定される第１の状態の第１状態コードと当該第１の状態の後に発生したアクションに応じて特定される第２の状態の第２状態コードとを対応付けて格納する対応履歴データ格納部から、現問い合わせを行っている現顧客の現状態の状態コードと同一の状態コードが前記第１状態コードとして登録されているレコードを読み出すステップと、
読み出された前記レコードを前記第２状態コードで分類するステップと、
前記分類毎に、当該分類に属するレコードに含まれる前記顧客の識別情報及び前記現顧客の識別情報で会員データ格納部から所定属性の属性値を読み出し、各前記顧客の属性値と前記現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、状態コード毎に応対コストが登録されている応対コスト格納部から当該分類についての前記第２状態コードに対応付けられている応対コストを読み出し、前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値に比例する予測コスト値を算出し、当該分類についての前記第２状態コードに対応付けて、予測コスト値格納部に格納する予測コスト値算出ステップと、
前記予測コスト値格納部に格納されている前記第２状態コードを前記予測コスト値の降順にソートして、当該ソート結果を出力データ格納部に格納するステップと、
を含み、コンピュータに実行される先回り案内推奨方法。
【請求項２】
前記対応履歴データ格納部が、前記第１の状態と前記第２の状態との間隔を特定するための情報をさらに格納しており、
前記予測コスト値算出ステップが、
前記分類に属するレコードについて、前記第１の状態と前記第２の状態との間隔の平均値を算出するステップと、
前記第１の状態と前記第２の状態との間隔の平均値に応じて、前記第１の状態から前記第２の状態への状態遷移がより近い将来に発生する蓋然性を表す第１の係数値を算出するステップと、
を含み、
前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値に対して、前記第１の係数値が乗じられる
ことを特徴とする請求項１記載の先回り案内推奨方法。
【請求項３】
前記予測コスト値算出ステップが、
前記分類に属するレコードについて、前記第１の状態と前記第２の状態との間隔の標準偏差を算出するステップと、
前記第１の状態と前記第２の状態との間隔の標準偏差に応じて、前記第１の状態と前記第２の状態との間隔の信頼性を表す第２の係数値を算出するステップと、
をさらに含み、
前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値と前記第１の係数値の積に対して、前記第２の係数値が乗じられる
ことを特徴とする請求項２記載の先回り案内推奨方法。
【請求項４】
前記対応履歴データ格納部が、前記第２の状態の発生日をさらに格納しており、
前記予測コスト値算出ステップが、
前記分類に属するレコードについて、前記第２の状態の発生日から現日付までの間隔の平均値を算出するステップと、
前記第２の状態の発生日から現日付までの間隔の平均値に応じて、前記分類に属するレコードの鮮度に応じた信頼性を表す第３の係数値を算出するステップと、
をさらに含み、
前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値と前記第１及び第２の係数値の積に対して、前記第３の係数値が乗じられる
ことを特徴とする請求項３記載の先回り案内推奨方法。
【請求項５】
請求項１乃至４のいずれか１つ記載の先回り案内推奨方法をコンピュータに実行させるためのプログラム。
【請求項６】
顧客の識別情報と当該顧客からの問い合わせを含むアクションに応じて特定される第１の状態の第１状態コードと当該第１の状態の後に発生したアクションに応じて特定される第２の状態の第２状態コードとを対応付けて格納する対応履歴データ格納部から、現問い合わせを行っている現顧客の現状態の状態コードと同一の状態コードが前記第１状態コードとして登録されているレコードを読み出す手段と、
読み出された前記レコードを前記第２状態コードで分類する手段と、
前記分類毎に、当該分類に属するレコードに含まれる前記顧客の識別情報及び前記現顧客の識別情報で会員データ格納部から所定属性の属性値を読み出し、各前記顧客の属性値と前記現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、状態コード毎に応対コストが登録されている応対コスト格納部から当該分類についての前記第２状態コードに対応付けられている応対コストを読み出し、前記属性指標の総和と前記応対コストとの積を読み出された全レコードの数で除した値に比例する予測コスト値を算出し、当該分類についての前記第２状態コードに対応付けて、予測コスト値格納部に格納する予測コスト値算出手段と、
前記予測コスト値格納部に格納されている前記第２状態コードを前記予測コスト値の降順にソートして、当該ソート結果を出力データ格納部に格納する手段と、
を有する先回り案内推奨装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サポートセンタなどにおいて顧客からの問い合わせに応対するための技術に関する。
【背景技術】
【０００２】
多くの企業が自社製品又はサービスについての問い合わせに答えるため、サポートセンタ（コールセンタとも呼ぶ）を設けている。サポートセンタでは、日々膨大な問い合わせに対して応対しているが、問い合わせの件数が増加するにつれコストも増加している。
【０００３】
例えば特開２００４−１９２５２１号公報には、通信ネットワークを介して受け付けたユーザの問合せに対して、迅速で的確な回答をするための技術が開示されている。具体的には、問合せと回答とを対応づけたデータベースを用意し、ユーザからの問合せから抽出された情報を用いて関連する回答をデータベースから検索して自動的に返信する。データベースに回答が無い場合は、ユーザからの問合せから抽出された情報を用いて関連する関連部門のリストを作成する。リストは、ユーザからの問合せとの一致度が高い関連部門ほど上位になるように作成され、所定の条件を超えて忙しい関連部門は下位に回される。ユーザからの問合せは、リストの上位から順に自動的に転送される。関連部門のいずれかから回答が得られたとき、回答はユーザが希望する通信手段で配信される。しかしながら、問い合わせ自体を削減するようなことは検討されていない。
【０００４】
例えば、特開２００９−１９３４５７号公報には、ユーザと対話の中で、ユーザの優先度や現在のマッチング状況を的確に判断し、最適なマッチング結果を取得することができ、そのマッチング結果を参照して、的確な検索結果を得ることができるようにするための技術が開示されている。具体的には、情報検索装置は、ユーザとの対話により各属性に対する属性値を解析するユーザ発話解析手段と、ユーザ発話解析手段による解析結果として、複数の属性と各属性に対するユーザの属性値とを対応付けたユーザデータを保持するユーザデータ保持手段と、ユーザデータを参照して回答の得られた属性値の取得割合が所定値以上である場合に、複数の対象データから、ユーザデータの各属性及び各属性値にマッチする１又は複数の対象データ候補を選出するマッチング手段と、マッチング手段により選出された各対象データ候補をユーザ側に出力する対話制御手段とを備える。この技術でも、問い合わせ自体を削減するようなことは検討されていない。
【０００５】
さらに、特開２００６−６５３６６号公報には、問い合わせ窓口担当者が過去の類似問い合わせ事例を効率的に探したり、マーケティング担当者が、問い合わせデータを分類してパレート図を効率的に作成できるようにするための、データの全体像把握が可能なキーワード分類装置が開示されている。具体的には、キーワード抽出部によって抽出された名詞句で分類されたカテゴリ内に、共起表現抽出部によって抽出された名詞句に対する述語句で文書を分類したサブカテゴリを作成する分類部を備える。さらに、キーワード抽出部によって抽出された名詞句のキーワードにあわせて、類似キーワード検索部によって検索された類似キーワードをまとめて閲覧できるように表示する分類部を備える。また、キーワード抽出部によって抽出された名詞句で分類されたカテゴリ内に、共起表現抽出部によって抽出された名詞句に対する述語句で文書を分類したサブカテゴリを作成する分類部を備える。この技術でも、問い合わせ自体を削減するようなことは検討されていない。
【０００６】
また、特開２００１−２２２４５２号公報には、リレーショナルデータベースシステムにおいて、ユーザが求める基準における最適な処理手順の選択を可能にするための技術が開示されている。具体的には、リレーショナルデータベースシステムにおける問い合わせ処理最適化装置は、データをノード、データ間の依存関係をエッジとする有向グラフで問い合わせを表現して保持するアクセスプラン保持手段と、有向グラフのあるノードの近傍におけるノードの追加、削除、エッジの追加、削除の操作による変形ルールを変形前と後のノードとエッジの関係を提示することによって指示するルール指示手段と、有向グラフにルールを繰り返し適用して等価な有向グラフを列挙するルール適用手段と、列挙された有向グラフの中で見積もられるコストが最小であるアクセスプランを選択するアクセスプラン選択手段とを有する。コストについては、処理に必要なコストであり、次回問い合わせに回答するためのコストではない。
【０００７】
さらに、特開平９−３０５４０６号公報には、複数の関連するタスクの問題解決プロセスを関連付けて一貫性を持った形で、しかも利用者の負担を要することなく解を導くことができ、利用者の予期しない複数のタスク間の関連付けを利用者に指摘するなどして利用者の業務効率や成果を向上させることができるようにするための技術が開示されている。具体的には、１つ以上のタスクについて管理し、関連するタスクどうしの連関性を管理する機能を持ち、所定のもしくは利用者が指定した初期タスクの解決から開始し、あるタスクについての問題解決の状況が所定の状態になると、次の関連するタスクを探索しその個別タスク実行を指示する機能を持つ手段を設けることで、例えば医師のスケジューリングタスクと看護婦のスケジューリングタスクを連関させて連続して問題解決を行うなど、複数の関連するタスクについてタスク間の一貫性を失うことなく、また利用者に多大な負担をかけることなく順に問題解決を行うことができる。さらに、タスク連鎖モデルを用いて上記のタスク同士の連関を管理し、実行するタスクを探索する手段を設けることで、例えば医師のスケジューリングタスクが終了し次のタスクを探索する際に、例えば前回の懇親会から１ヵ月以上経過していると、次のタスクとして懇親会スケジューリングを探索結果として得て利用者に提案することで、利用者の予期しないタスクを利用者に提案して利用者の業務効率や成果を向上させることができるようになっている。しかしながら、次に発生するであろうタスクを削減してコストを削減するようなことは検討されていない。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−１９２５２１号公報
【特許文献２】特開２００９−１９３４５７号公報
【特許文献３】特開２００６−６５３６６号公報
【特許文献４】特開２００１−２２２４５２号公報
【特許文献５】特開平９−３０５４０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上で述べたように、現在存在する技術には、顧客からの問い合わせに応対するコストを効果的に削減するような観点がない。
【００１０】
従って、本発明の目的は、サポートセンタなどにおいて顧客からの問い合わせに応対する際に将来さらに発生しうるコストを効果的に削減するための技術を提供することである。
【課題を解決するための手段】
【００１１】
本先回り案内推奨方法は、（Ａ）顧客の識別情報と当該顧客からの問い合わせを含むアクションに応じて特定される第１の状態の第１状態コードと当該第１の状態の後に発生したアクションに応じて特定される第２の状態の第２状態コードとを対応付けて格納する対応履歴データ格納部から、現問い合わせを行っている現顧客の現状態の状態コードと同一の状態コードが第１状態コードとして登録されているレコードを読み出すステップと、（Ｂ）読み出されたレコードを第２状態コードで分類するステップと、（Ｃ）上記分類毎に、当該分類に属するレコードに含まれる顧客の識別情報及び現顧客の識別情報により会員データ格納部から所定属性の属性値を読み出し、各顧客の属性値と現顧客の属性値との重み付けされた一致度合いを表す属性指標の総和を算出し、状態コード毎に応対コストが登録されている応対コスト格納部から当該分類についての第２状態コードに対応付けられている応対コストを読み出し、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値に比例する予測コスト値を算出し、当該分類についての第２状態コードに対応付けて、予測コスト値格納部に格納する予測コスト値算出ステップと、（Ｄ）予測コスト値格納部に格納されている第２の状態を予測コスト値の降順にソートして、当該ソート結果を出力データ格納部に格納するステップとを含む。
【００１２】
このように次に発生する可能性のある問い合わせの予測コスト値を算出すれば、例えばサポートセンタのオペレータは、コスト削減効果が高い問い合わせを把握できるようになる。従って、オペレータが、今回の問い合わせへの応対で、可能性のある次の問い合わせに対する応対（すなわち先回り案内）をも併せて行えば、効果的に次回問い合わせを削減することができ、コスト削減効果を得ることができる。また、顧客側も利便性が向上し、問い合わせに対する満足感が高くなる。
【００１３】
また、上で述べた対応履歴データ格納部が、第１の状態と第２の状態との間隔を特定するための情報（たとえば間隔そのもの又は第１及び第２の状態の発生日付）をさらに格納している場合もある。この場合、上で述べた予測コスト値算出ステップが、上記分類に属するレコードについて、第１の状態と第２の状態との間隔の平均値を算出するステップと、第１の状態と第２の状態との間隔の平均値に応じて、第１の状態から第２の状態への状態遷移がより近い将来に発生する蓋然性を表す第１の係数値を算出するステップとを含むようにしてもよい。そして、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値に対して、第１の係数値が乗じられるようにしてもよい。
【００１４】
例えば間隔が短い、すなわち近い将来起こりやすい状態遷移に比較的大きな係数値を設定することで、適切な予測コスト値を得ることができるようになる。
【００１５】
さらに、上で述べた予測コスト値算出ステップが、分類に属するレコードについて、第１の状態と第２の状態との間隔の標準偏差を算出するステップと、第１の状態と第２の状態との間隔の標準偏差に応じて、第１の状態と第２の状態との間隔の信頼性を表す第２の係数値を算出するステップとをさらに含むようにしてもよい。そして、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値と第１の係数値の積に対して、第２の係数値が乗じられるようにしてもよい。間隔のばらつきが大きい状態遷移についてはあまりその間隔の平均値を信用できず、間隔のばらつきが小さい状態遷移については間隔の平均値を信用できるので、そのような信頼度を反映させることで、適切な予測コスト値を得ることができるようになる。
【００１６】
また、上で述べた対応履歴データ格納部が、第２の状態の発生日をさらに格納するようにしてもよい。この場合、上で述べた予測コスト値算出ステップが、上記分類に属するレコードについて、第２の状態の発生日から現日付までの間隔の平均値を算出するステップと、第２の状態の発生日から現日付までの間隔の平均値に応じて、上記分類に属するレコードの鮮度に応じた信頼性を表す第３の係数値を算出するステップとをさらに含む。そして、属性指標の総和と応対コストとの積を読み出された全レコードの数で除した値と第１及び第２の係数値の積に対して、第３の係数値が乗じられるようにしてもよい。状態遷移が最近頻繁に発生しているのか過去良く発生していたものかでは、より最近頻繁に発生している方が信頼性が高い。従って、上で述べたような演算により、適切な予測コスト値を算出することができるようになる。
【００１７】
本発明に係る方法は、コンピュータ・ハードウエアとプログラムとの組み合わせにより実施される場合があり、本発明に係るプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
【発明の効果】
【００１８】
本発明によれば、サポートセンタなどにおいて顧客からの問い合わせに応対する際に将来さらに発生しうるコストを効果的に削減することができる。
【図面の簡単な説明】
【００１９】
【図１】図１は、本発明の実施の形態におけるシステム概要図である。
【図２】図２は、問い合わせ予測サーバの機能ブロック図である。
【図３】図３は、時系列の問い合わせの一例を示す図である。
【図４】図４は、本実施の形態の概要を表す図である。
【図５】図５は、入会データ取得部の処理フローを示す図である。
【図６】図６は、会員ＤＢに格納されるデータの一例を示す図である。
【図７】図７は、対応履歴ＤＢに格納されるデータの一例を示す図である。
【図８】図８は、問い合わせデータ取得部の処理フローを示す図である。
【図９】図９は、有向グラフデータ格納部に格納されるデータの一例を示す図でる。
【図１０】図１０は、問い合わせ予測部の処理フローを示す図である。
【図１１】図１１は、スコア計算処理の処理フローを示す図である。
【図１２】図１２は、コストデータ格納部６４に格納されるデータの一例を示す図である。
【図１３】図１３は、予測結果格納部に格納されるデータの一例を示す図である。
【図１４】図１４は、オペレータ端末における出力表示画面を示す図である。
【図１５】図１５は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００２０】
図１に、本発明の実施の形態に係るシステム概要を示す。例えば、サポートセンタでは、オペレータ毎に、オペレータ端末と電話機１１とが用意される。なお、オペレータ端末と電話機とが一体化されている場合もある。例えばオペレータ端末Ａ乃至Ｅは、ＬＡＮ（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）の総和を算出するようにしてもよい。
【００４１】
ここで関数ｓｉｍ（ｉｄ１，ｉｄ２）は以下のように定義される。
【００４２】
【数１】
2011113383.tif 000003
ここでａｔｔｒ（ｉｄ，ａ）は、会員ＩＤ「ｉｄ」の顧客のａという属性の属性値を表す。「ａ」という属性は、図６に示したように、本実施の形態では、ａ１が性別であり、ａ２は年齢であり、ａ３は婚姻の有無であり、ａ４は住居の有無であり、ａ５は子供の人数であり、ａ６は職業であり、ａ７は住所であり、ａ８は料金コースであり、ａ９は入会年月日であり、ａ１０は支払方法である。但し、このような属性に限定するものではなく、会員属性のうち特に問い合わせに関連する会員属性を抽出できればよい。また、ここでは属性を１０個用いる例を示しているが、１０に限定するものではなく他の個数であっても良い。
【００４３】
さらに、ｍａｔｃｈ（ｂ１，ｂ２）は、以下のように定義される。
【００４４】
【数２】
2011113383.tif 000004
このように一致していれば「１」で、不一致であれば「０」であるが、属性によっては区分が一致しているか否かで「１」か「０」を分けても良い。例えば、入会年月日については、入会年月日の入会年月だけを用いるようにしても良い。さらに住所についても例えば県より下の行政区画までを比較するようにしても良い。
【００４５】
また、ｗiは、ｉ番目の属性の重み値であり、（１）式の分母は、重み値の総和を表している。
【００４６】
そして、問い合わせ予測部５７は、コストデータ格納部６４から処理対象のサブセットＳjについての状態１の状態コードｓjに対応付けられているコストｃ（ｓj）を読み出し、予測コスト値Ｃｏｓｔ（ｉｄc，ｓc，Ｓj，ｓj）を算出し、状態２の状態コードに対応付けて予測結果格納部６１に格納する（ステップＳ４３）。図１２に、コストデータ格納部６４に格納されるデータの一例を示す。図１２の例では、状態コードに対応付けて応対のコスト（例えば「分」単位）が登録されるようになっている。本実施の形態では、状態コードに対応する問い合わせについて１回応対するのに必要な時間をコストとして採用する。
【００４７】
そしてＣｏｓｔ（ｉｄc，ｓc，Ｓj，ｓj）は、以下のように定義される。
【００４８】
【数３】
2011113383.tif 000005
（２）式で、｜Ｓ｜は、集合Ｓのレコード数を表す。また、上でも述べたが、Ｓ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）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【符号の説明】
【００６４】
１  ネットワーク    ５  問い合わせ予測サーバ
７  ＣＴＩシステム    ９  会員管理サーバ
１３  サポートセンタサーバ    ９１  会員ＤＢ
５１  問い合わせデータ取得部    ５２  状態定義データ格納部
５３  入会データ取得部    ５４  対応履歴ＤＢ
５５  有向グラフ生成部    ５６  有向グラフデータ格納部
５７  問い合わせ予測部    ５９  会員データ取得部
６１  予測結果格納部    ６２  会員データ格納部
６３  出力部    ６４  コストデータ格納部
【図１】
2011113383.tif 000006
【図２】
2011113383.tif 000007
【図３】
2011113383.tif 000008
【図４】
2011113383.tif 000009
【図５】
2011113383.tif 000010
【図６】
2011113383.tif 000011
【図７】
2011113383.tif 000012
【図８】
2011113383.tif 000013
【図９】
2011113383.tif 000014
【図１０】
2011113383.tif 000015
【図１１】
2011113383.tif 000016
【図１２】
2011113383.tif 000017
【図１３】
2011113383.tif 000018
【図１４】
2011113383.tif 000019
【図１５】
2011113383.tif 000020