JP2019149649A - 処理装置、プログラムおよび処理方法 - Google Patents

Abstract

【課題】コンタクトセンタにおいてオペレータの効率的な人員配置を行うことができる。【解決手段】顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理部としての業務別蓄積データ部１１４と、チャットの数の情報と、前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得し、取得した情報から得られる、前記エスカレーションの割合の情報より、第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理部としての蓄積データ管理部１１６とを有する。【選択図】図１

Description

本発明は、処理装置、プログラムおよび処理方法に関し、例えばチャットによる接続と音声による接続の２つのチャネルを持つコンタクトセンタシステムにおいて、要員の配置を最適化する処理に関する。

従来、コンタクトセンタに関して、呼量を基にオペレータの人員配置を行う技術があった（特許文献１参照）。

また、近年、バーチャルオペレータがチャット機能を用いて自動で問い合わせを受け、チャットで対応できない難しい問い合わせのみを人間のオペレータにつなぐことで、コンタクトセンタの人員不足を解消する技術が開発されている（非特許文献１参照）。

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

"コールセンターの問い合わせにAIがチャットで自動応答するサービスを販売開始"、[online]、富士通株式会社、[平成３０年２月６日検索]、インターネット、＜http://pr.fujitsu.com/jp/news/2017/05/16-1.html＞

しかしながら、特許文献１に記載される技術では、呼量を基にオペレータの人員配置を行っているので、非特許文献１に記載されるようなチャット機能を併用したコンタクトセンタシステムでは最適な人員配置が行えないという問題があった。

また、問題を解決するのに適したオペレータとのビデオチャットを自動で開始可能にする技術が提案されている（特許文献２参照）。この技術では、ビデオチャット端末が利用者から入力を受け付けた質問内容をデータセンタへ送信し、データセンタがビデオチャット端末から送信された質問内容と対応するオペレータ端末の接続先を前記ビデオチャット端末に送信する。そして、ビデオチャット端末は、データセンタから送信された前記接続先から特定されるオペレータ端末との通信を確立し、ビデオチャットを開始する方法が示されている。

しかしながら、特許文献２に記載される技術は、単一のオペレータにチャット接続が行われるため、チャットの時間間隔が長いと、対応オペレータの待機時間がその分長くなるという問題点があった。

本発明は、前記課題に鑑みてなされたものであり、コンタクトセンタにおいてオペレータの効率的な人員配置を行える、処理装置、プログラムおよび処理方法を提供するものである。

また、本発明は、オペレータの待機時間を短くし、効率的にオペレータの業務を行える、処理装置、プログラムおよび処理方法を提供するものである。

前記課題を解決するため、本発明に係る処理装置は、顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理部と、チャットの数の情報と、前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得する取得処理部と、前記取得処理部で取得した情報から得られる、前記エスカレーションの割合の情報より、第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理部とを有することを特徴とする。

また、本発明に係るプログラムは、コンピュータを、顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理部、チャットの数の情報と、前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得する取得処理部、前記取得処理部で取得した情報から得られる、前記エスカレーションの割合の情報より、第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理部として機能させる。

また、本発明に係る処理方法は、処理装置の処理方法であって、前記処理装置は、顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理ステップと、チャットの数の情報と、前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得する取得処理ステップと、前記取得処理ステップで取得した情報から得られる、前記エスカレーションの割合の情報より、第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理ステップとを有することを特徴とする。

また、本発明に係る処理装置は、顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御部を有することを特徴とする。

また、本発明に係るプログラムは、コンピュータを、顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御部として機能させる。

また、本発明に係る処理方法は、処理装置の処理方法であって、前記処理装置は、顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御ステップを有することを特徴とする。

本発明によれば、コンタクトセンタにおいてオペレータの効率的な人員配置を行うことができる。
また、本発明によれば、オペレータの待機時間を短くし、効率的にオペレータの業務を行える。

本発明の第１実施形態に係るコンタクトセンタシステムの概略構成図である。 業務識別データテーブルの例示である。 エスカレーション率算出用テーブルの例示である。 エスカレーション予測量算出用テーブルの例示である。 所属グループ変更用テーブルの例示である。 本発明の第１実施形態に係るコンタクトセンタシステムの動作を示すフローチャートである。 本発明の第１実施形態に係るコンタクトセンタシステムの動作を示すフローチャートである。 本発明の第２実施形態に係るコンタクトセンタシステムの概略構成図である。 属性情報テーブルの例示である。 提示情報テーブルの例示である。 オペレータグループ情報テーブルの例示である。 顧客チャット情報テーブルの例示である。 属性抽出ニューラルネットワークの例示である。 本発明の第２実施形態に係るコンタクトセンタシステムの動作を示すフローチャートである。

以下、本発明の実施するための形態を、適宜図面を参照しながら詳細に説明する。ここで、本発明の実施するための形態において、一例として、処理装置、プログラムおよび処理方法を含むコンタクトシステムを用いて説明する。
各図は、本発明を十分に理解できる程度に、概略的に示してあるに過ぎない。よって、本発明は、図示例のみに限定されるものではない。また、本実施形態では、本発明と直接的に関連しない構成や周知な構成については、説明を省略する場合がある。なお、各図において、共通する構成要素や同様な構成要素については、同一の符号を付し、それらの重複する説明を省略する。

［第１実施形態］
≪第１実施形態に係るコンタクトセンタシステムの構成について≫
図１を参照して、第１実施形態に係るコンタクトセンタシステム１００の構成について説明する。図１は、第１実施形態に係るコンタクトセンタシステム１００の構成図である。

コンタクトセンタシステム１００は、音声による通信が可能な端末とチャットによる通信が可能な端末とが接続可能なコンタクトセンタシステムである。
公衆網１０２には、コンタクトセンタ１２０と、音声通話でコンタクトセンタ１２０を利用する顧客電話機１０１とが接続されている。
ＩＰ（Internet Protocol）網１０３には、コンタクトセンタ１２０と、チャットによる通信でコンタクトセンタ１２０を利用する顧客の顧客端末１０４とが接続されている。

コンタクトセンタ１２０は、公衆網ゲートウェイ装置１０７を介して公衆網１０２と、ＩＰゲートウェイ装置１０６を介してＩＰ網１０３とに接続されている。
公衆網ゲートウェイ装置１０７は、通話データ（音声など）や呼制御手順を中継する処理を行う。
ＩＰゲートウェイ装置１０６は、主に、通信データ（文字など）の処理を行う。

また、コンタクトセンタ１２０は、呼制御装置１０９およびチャット制御装置１１０を含んだコンタクトセンタサーバ１３０を備えている。ここで、コンタクトセンタサーバ１３０が備える機能は、コンタクトセンタ１２０内における個別の装置として構成されてもよい。
呼制御装置１０９は、呼の振り分けを始めとして、コンタクトセンタ１２０の音声通話に関する制御を行う。チャット制御装置１１０は、コンタクトセンタ１２０のチャット接続に関する制御を行う。

コンタクトセンタ１２０には、通信網１０５がある。コンタクトセンタ１２０内の装置は、この通信網１０５に接続されており、これを経由して他の装置と通信を行う。通信網１０５の構成は様々な形態が考えられるが、本発明には大きな影響がないため、第１実施形態では最も単純な構成で記述する。

コンタクトセンタ１２０には、オペレータが使用するオペレータ端末１１９が複数存在する。オペレータは、オペレータ端末１１９を使って通話や情報処理の業務を行う。コンタクトセンタ１２０には複数の業務別グループ１１８が存在し、オペレータは担当する業務別のグループに分けられている。また、コンタクトセンタ１２０には、各業務を担当するオペレータとは別に、それを管理する管理者が使用する管理者端末１１７が存在する。

言語データ認識装置１１１は、チャット制御装置１１０で受けたチャットのテキストデータの処理を行い、そのデータを蓄積、処理する装置である。テキストデータ処理部１１５は、顧客端末１０４から送信されたテキストデータを処理し、データ蓄積部１１２の業務識別データ部１１３を参照し、どの業務に関する問い合わせであるかを判断し、業務別蓄積データ部１１４に記録する。蓄積データ管理部１１６は、データ蓄積部１１２の業務別蓄積データ部１１４の蓄積量を定期的にチェックし、各業務ごとに蓄積量を管理する。

業務識別データ部１１３には、顧客からの問い合わせに関連する業務を識別するための情報が格納されており、例えば、各業務に関連する単語が表となった業務識別データテーブル１１３ａ（図２参照）が格納されている。

業務別蓄積データ部１１４には、業務別（業務別グループごと）に問合せデータが格納されている。問合せデータは、例えば、問い合わせを行った顧客の情報、問合せがあった時刻、問合せの方法、エスカレーションの有無などの情報を含むものであってよい。問合せデータは、例えば、顧客からの問い合わせがある度に作成される。

なお、言語データ認識装置１１１は、「処理装置」の一例であり、「処理装置」の一例は、言語データ認識装置１１１に限るものではない。
また、「問合せデータ」は、「問い合わせ情報」の一例であり、「問い合わせ情報」の一例は、「問合せデータ」に限るものではない。
また、「業務別グループ」は、「所属グループ情報」の一例であり、「所属グループ情報」の一例は、「業務別グループ」に限るものではない。
また、業務別蓄積データ部１１４は、「蓄積処理部」の一例であり、「蓄積処理部」の一例は、業務別蓄積データ部１１４に限るものではない。

「エスカレーション」は、第１の対応（または第１の対応者）から第２の対応（または第２の対応者）に切り替えること（第１の対応者から第２の対応者への転送）を意図し、ここでは特に「チャット」の対応から人間のオペレータによる「通話」の対応への切り替えを意味する。

また、業務別蓄積データ部１１４には、エスカレーション率算出用テーブル１１４ａ（図３参照）と、エスカレーション予測量算出用テーブル１１４ｂ（図４参照）と、所属グループ変更用テーブル１１４ｃ（図５参照）と、を有している。これらのテーブルは、蓄積データ管理部１１６によって、それぞれの処理時に作成や更新される。詳細は後記する。

≪第１実施形態に係るコンタクトセンタシステムの動作について≫
図６Ａ，図６Ｂを参照（適宜、図１ないし図５を参照）して、第１実施形態に係るコンタクトセンタシステム１００の動作について説明する。図６Ａは、第１実施形態に係るコンタクトセンタシステム１００の問合せデータの蓄積処理を示すフローチャートである。図６Ｂは、第１実施形態に係るコンタクトセンタシステム１００の所属グループ（業務グループ）の変更処理を示すフローチャートである。

＜問合せデータの蓄積処理＞
初めに、顧客端末１０４からコンタクトセンタ１２０に質問文が送信される（ステップＳ２０１）。顧客端末１０４から受けた質問文は、コンタクトセンタ１２０内のチャット制御装置１１０にて回答文が作成され、顧客端末１０４に送信される（ステップＳ２０２）。

次に、テキストデータ処理部１１５は、顧客端末１０４からの質問文から業務識別データテーブル１１３ａに一致するデータ（例えば、単語）を抽出する（ステップＳ２０３）。そして、テキストデータ処理部１１５は、抽出したデータ（例えば、単語）から顧客端末１０４からの質問文がどの業務に関連する質問なのかを判断し、業務別蓄積データ部１１４に質問文に基づく問合せデータ（チャットによる問い合わせ件数に関わるデータを含む）を保存する（ステップＳ２０４）。例えば、業務識別データテーブル１１３ａには、各業務に関連する単語が表となって格納されており、テキストデータ処理部１１５は、その単語がより多く顧客端末１０４からの質問文に含まれる業務を選択し、顧客からの問い合わせがその業務に関するものであると判断する。つまり、どの業務に関する質問なのかの判断は、業務識別データ部１１３に格納されている業務識別データテーブル１１３ａを用いて行う。

なお、蓄積データ管理部１１６は、「問合せデータの蓄積処理」によってある程度の問合せデータが蓄積された後で、過去のチャットによる問い合わせ件数とオペレータへのエスカレーション数とを業務グループ（所属グループ）ごとに集計し、以下の式（１）［除算を使用した演算］を用いて、そのエスカレーション率を求める。
・エスカレーション率＝（オペレータへのエスカレーション数）／（チャットによる問合せ件数） ・・式（１）

蓄積データ管理部１１６は、例えば、コンタクトセンタシステム１００の管理者による期間の指定を受け付け、業務別蓄積データ部１１４から指定された期間の問合せデータを抽出する。そして、蓄積データ管理部１１６は、チャットによる問い合わせ件数とオペレータへのエスカレーション数とを業務グループ（所属グループ）ごとに集計し、エスカレーション率を計算する。蓄積データ管理部１１６によるエスカレーション率の計算は、例えば、エスカレーション率算出用テーブル１１４ａを用いて行われ、計算されたエスカレーション率は、エスカレーション率算出用テーブル１１４ａに格納される。

エスカレーション率を算出する基になる問合せデータを集計する集計期間Ｔは、特に限定されるものではなく、任意の期間（１日、１週間、１ヶ月など）であってよい。ただし、エスカレーションの発生に周期的な傾向がある場合には、その傾向がエスカレーション率に反映されるように集計期間Ｔを設定するのがよい。例えば、１日の中で特定の時間にエスカレーションが多く発生するような場合には、その特定の時間とそれ以外の時間とのエスカレーション率を算出してもよい。また、１週間の中で週末にエスカレーションが多く発生するような場合には、週末と平日とのエスカレーション率を算出してもよい。そのため、エスカレーション率算出用テーブル１１４ａは複数あってもよい。これにより、エスカレーション率は、統計的なデータ（統計量）となる。

ここでは、集計期間Ｔを「１週間」とするエスカレーション率を算出したことにする。
その結果、図３に示すように、「業務Ａ」のエスカレーション率は「０．１５」であり、「業務Ｂ」のエスカレーション率は「０．０３」であり、「業務Ｃ」のエスカレーション率は「０．５」であった。

なお、蓄積データ管理部１１６は、「取得処理部」の一例であり、「取得処理部」の一例は、蓄積データ管理部１１６に限るものではない。

＜所属グループ（業務グループ）の変更処理＞
次に、図６Ｂを参照して、第１実施形態に係るコンタクトセンタシステム１００の所属グループの変更処理について説明する。この処理を実行するタイミングは特に限定されず、例えば、業務中の特定の時刻になった場合に処理が実行される。ここでは、「０時」から業務が開始され、３０分間隔でオペレータの「所属グループの変更処理」を行う場合を想定して説明する。

なお、ここでは、コンタクトセンタ１２０における、総オペレータ数は「６００人」であり、「６００人」のうち「１５０人」を業務グループＡ，Ｂ，Ｃそれぞれに「５０人」ずつ所属させ、残りの「４５０人」を後記するエスカレーション予測量に基づいて振り分けることにする。また、初めの時間帯「０：００」〜「０：３０」では、業務グループＡ，Ｂ，Ｃに所属する人数が同じになるように振り分け、それ以降の時間帯（例えば、「０：３０」〜「１：００」）では、直前の時間帯を基に算出したエスカレーション予測量に合わせて振り分ける。

そのため、開始直後（時刻「０：００」〜「０：３０」）においては、図５に示すように、業務グループＡ，Ｂ，Ｃに所属するオペレータは「２００人」である。

（時刻「０：３０」における処理）
最初に、蓄積データ管理部１１６は、業務別蓄積データ部１１４に一定時間内に蓄積したデータ量を各業務ごとに調べ、以下の式（２）［乗算を使用した演算］を用いて、各業務ごとに蓄積した一定時間のデータ量に予め求めたエスカレーション率をかけて、エスカレーション予測量を算出する（ステップＳ２０５）。エスカレーション率は、「データの蓄積処理」で、事前に蓄積した問い合わせのデータ（例えば、前日［開始直前「０：００」までの２４時間］に蓄積した問合せデータ、業務前日より前に蓄積した問合せデータなど）を基にして算出した値である（図３参照）。
・エスカレーション予測量＝（チャットによる問合せ件数）×（エスカレーション率） ・・式（２）

ここでは、時間帯「０：００」〜「０：３０」における、業務Ａのチャットによる問合せ件数が「１０００件」であり、業務Ｂのチャットによる問合せ件数が「３０００件」であり、業務Ｃのチャットによる問合せ件数が「５００件」であったとする。
そのため、図４に示すように、「業務Ａ」のエスカレーション予測量は「１５０件」であり、「業務Ｂ」のエスカレーション予測量は「９０件」であり、「業務Ｃ」のエスカレーション予測量は「２５０件」になった。

また、蓄積データ管理部１１６は、全体のエスカレーション予測量に対する各業務におけるエスカレーション予測量の割合を計算する（図４の括弧内のパーセント表記であり、なお、小数点以下は切り捨てる）。
ここでは、全体のエスカレーション予測量「１５０＋９０＋２５０＝４９０件」に対する業務Ａ，Ｂ，Ｃのエスカレーション予測量「１５０」，「９０」，「２５０」の割合である。そのため、「業務Ａ」の割合は「３０％」であり、「業務Ｂ」の割合は「１８％」であり、「業務Ｃ」の割合は「５１％」である。

次に、蓄積データ管理部１１６は、ステップＳ２０５で算出した各業務におけるエスカレーション予測量の割合に合わせて、各業務グループに所属するオペレータの数を変更する（ステップＳ２０６）。

ここでは、総オペレータ数「６００人」の内の「４５０人」をエスカレーション予測量に基づいて振り分けることにしているので、「４５０人」に各業務におけるエスカレーション予測量の割合を乗算した値が、次の時間帯「０：３０」〜「１：００」におけるオペレータの振り分けになる（小数点以下は切り捨てる）。
つまり、「業務Ａ」の次の時間帯の振り分け人数は、「４５０×０．３＝１５０人」に固定で配属される「５０人」を加算した「２００人」である。また、「業務Ｂ」の次の時間帯の振り分け人数は、「４５０×０．１８＝８１人」に固定で配属される「５０人」を加算した「１３１人」である。また、「業務Ｃ」の次の時間帯の振り分け人数は、「４５０×０．５１＝２２９人」に固定で配属される「５０人」を加算した「２７９人」である。

なお、蓄積データ管理部１１６は、「変更処理部」の一例であり、「変更処理部」の一例は、蓄積データ管理部１１６に限るものではない。

次に、蓄積データ管理部１１６は、ステップＳ２０６で求めたオペレータの振り分けの結果に合わせてオペレータの所属グループを変更し、結果を管理者に通知する（ステップＳ２０７）。なお、エスカレーション量の割合を求める際、小数点以下を切り捨てているため、業務に割り当てられないオペレータが存在する場合がある。そのオペレータは、管理者が状況に合わせてグループに所属させてもよい。

オペレータの所属グループを変更する方法は、種々のものが考えられ、特に限定されるものではない。例えば、蓄積データ管理部１１６は、オペレータに対して業務の変更の通知（例えば、「業務Ｂの対応が集中しているので、業務を変更してください。」など）を送信し、オペレータ自身が現在行っている対応が終わった後で業務の変更の手続きを行う。業務の変更を依頼する対象は、例えば、オペレータのスキルレベルを参考にして抽出される。つまり、蓄積データ管理部１１６は、オペレータに対応付けてオペレータが対応可能な業務の情報（スキル情報）を予め記憶しておき、その情報を参照して変更後の業務を対応可能なオペレータを抽出し、通知を送信する。なお、蓄積データ管理部１１６は、変更の依頼を行ったオペレータから業務の変更の可否を受信し、その結果を管理者に通知するようにしてもよい。その場合、管理者が、オペレータにさらなる業務変更の依頼を行い、算出した振り分け人数になるように調整するのがよい。

以上のように、第１実施形態におけるコンタクトセンタシステム１００（特に、言語データ認識装置１１１）では、チャットで受けたテキストデータを業務別に分類して保存し、そのチャットでの問い合わせからオペレータへエスカレーションした数から統計量としてのエスカレーション率を予め求める。そして、業務当日において一定期間ごとに集計した業務別のチャット問い合わせ数に統計量としてのエスカレーション率をかけ、その割合を計算し、それに合わせて業務ごとのグループに所属するオペレータの人数を変更する。また、その結果を管理者に通知する。そのため、各業務に関する問い合わせ量の増減に合わせ、オペレータの業務グループの変更を行うことができる。

第１実施形態におけるコンタクトセンタシステム１００（特に、言語データ認識装置１１１）では、特に、統計量としてのエスカレーション率を用いて業務当日のオペレータの業務グループを変更するので、ある特定の時間帯だけ偶発的にエスカレーション数が増えた（実際のエスカレーション率が上がった）場合でも、その一時的な傾向の影響を小さくすることができる。

一方、業務当日の特定の時間に急激にチャットによる問合せが増加した場合（例えば、テレビである商品が取り上げられ、その商品に関する問合せが増えた場合）には、問合せの増加に付随してエスカレーション数も増えることが考えられる（実際のエスカレーション率は同じ）。第１実施形態におけるコンタクトセンタシステム１００（特にコンタクトセンタ１２０）では、統計量としてのエスカレーション率に業務当日のチャットの問い合わせ数をかけているので、このような急激なチャットの問合せ数の変化に対応することができる。

なお、本実施形態の「業務」は特定のものを想定したものでないが、一問一答で答えづらいもの（保険勧誘、機械の故障）や、最後に人が必ず対応しないといけない業務（交通事故など）において特に有効である。

＜第１実施形態の変形例＞
以上、本発明の第１実施形態について説明したが、本発明はこれに限定されるものではなく、特許請求の範囲の趣旨を変えない範囲で実施することができる。第１実施形態の変形例を以下に示す。

第１実施形態では、一日を通して同じエスカレーション率を使用していたが、時刻によってエスカレーション率を変更してもよい。その場合、各時間帯ごとのエスカレーション率を予め算出しておくようにする。

また、第１実施形態では、業務グループに所属するオペレータを「０人」にしないために、全体のオペレータの内の一部を業務グループに所属させ、残りのオペレータを後記するエスカレーション予測量に基づいて振り分けることにしていた。しかしながら、例えば、全員をエスカレーション予測量に基づいて振り分けてもよい。

また、第１実施形態では、顧客電話機１０１と顧客端末１０４は、別々の装置として記載したが、１つの装置（例えば、スマートフォン、ソフトフォンが搭載されたパーソナルコンピュータなど）でもよい。

［第２実施形態］
≪第２実施形態に係るコンタクトセンタシステムの構成について≫
図７を参照して、第２実施形態に係るコンタクトセンタシステム１００Ａの構成について説明する。図７は、第２実施形態に係るコンタクトセンタシステム１００Ａの構成図である。

コンタクトセンタシステム１００Ａは、第１実施形態と同様に、音声による通信が可能な端末とチャットによる通信が可能な端末とが接続可能なコンタクトセンタシステムである。第２実施形態では、コンタクトセンタ１２０Ａの構成が第１実施形態と相違するため、相違する部分を中心に説明する。

オペレータ端末１１９は、通信部１１９ａと、表示部１１９ｂと、操作部１１９ｃと、を備えている。
通信部１１９ａは、コンタクトセンタサーバ１３０と通信を行う。表示部１１９ｂは、オペレータに対してテロップなどの表示を行う。操作部１１９ｃは、オペレータからの操作を受け付ける。

また、第２実施形態に係るコンタクトセンタシステム１００Ａは、第１実施形態における呼制御装置１０９およびチャット制御装置１１０を含んだコンタクトセンタサーバ１３０を備えている。
コンタクトセンタサーバ１３０は、さらに、通信部１３１と、表示制御部１３２と、呼制御部１３３と、チャット制御部１３４と、を備えている。なお、第１実施形態と同様に、コンタクトセンタサーバ１３０が備える機能は、コンタクトセンタ１２０Ａにおける個別の装置として構成されてもよい。

なお、コンタクトセンタサーバ１３０は、「処理装置」の一例であり、「処理装置」の一例は、コンタクトセンタサーバ１３０に限るものではない。

通信部１３１は、顧客電話機１０１および顧客端末１０４と情報通信を行う。
表示制御部１３２は、顧客電話機１０１および顧客端末１０４の表示を制御する。
呼制御部１３３は、第１実施形態における呼制御装置１０９に対応し、呼制御装置１０９が有する機能を備える。
チャット制御部１３４は、第１実施形態におけるチャット制御装置１１０に対応し、チャット制御装置１１０が有する機能を備える。また、チャット制御部１３４は、人工知能として顧客とチャットを行い、チャットテキストを元に属性抽出を行う。チャット制御部１３４の処理の詳細については後記する。

また、第２実施形態に係るコンタクトセンタ１２０Ａは、制御データベース１４０をさらに備えている。ここでの制御データベース１４０は、属性情報テーブル１４１（図８参照）と、提示情報テーブル１４２（図９参照）と、オペレータグループ情報テーブル１４３（図１０参照）と、顧客チャット情報テーブル１４４（図１１参照）とを格納している。
なお、ここではコンタクトセンタ１２０Ａ内に制御データベース１４０を配置する構成を示しているが、制御データベース１４０が格納される場所は特に限定されない。例えば、コンタクトセンタ１２０Ａの外部に通信可能に配置してもよい。また、コンタクトセンタ１２０Ａ内のコンタクトセンタサーバ１３０と制御データベース１４０とを一体の装置として構成することも可能である。コンタクトセンタサーバ１３０と制御データベース１４０とを合わせて、例えば「処理装置」であってもよい。

図８を参照して、制御データベース１４０に格納される属性情報テーブル１４１の構成について説明する。図８は、属性情報テーブル１４１の構成例である。属性情報テーブル１４１は、顧客とコンタクトセンタサーバ１３０とがチャットを行い、後記する「属性の抽出処理」によって更新される。
属性情報テーブル１４１は、センタ側テキスト１４１ａと、センタ側テキストバイナリ１４１ｂと、顧客側テキスト１４１ｃと、顧客側テキストバイナリ１４１ｄと、属性１４１ｅと、属性バイナリ１４１ｆと、属性ＩＤ１４１ｇとからなる。

センタ側テキスト１４１ａは、コンタクトセンタ１２０Ａ側からのチャットテキスト例であり、ここでは、「何かお困りですか？」を例示している。
センタ側テキストバイナリ１４１ｂは、コンタクトセンタ１２０Ａ側からのチャットテキスト例をバイナリデータに変換した物である。ここでは、「1010」、「0000」を例示している。バイナリデータへの変換については後記する。

顧客側テキスト１４１ｃは、顧客側からのチャットテキスト例であり、ここでは、「製品Ｘが壊れた」、「製品Ｙについて教えてください」を例示している。
顧客側テキストバイナリ１４１ｄは、顧客側からのチャットテキスト例をバイナリデータに変換した物である。ここでは、「1010」、「0101」を例示している。

属性１４１ｅは、センタ側テキスト１４１ａと顧客側テキスト１４１ｃに紐付く属性である。ここでは、「製品Ｘの修理」、「製品Ｙの紹介」を例示している。
属性バイナリ１４１ｆは、属性１４１ｅをバイナリデータに変換した物であり、ここでは、「１０１０」、「０１０１」を例示している。
属性ＩＤ１４１ｇは、属性１４１ｅを一意に識別する情報であり、ここでは数字を例示している。

＜属性の抽出処理＞
属性の抽出処理は、チャット制御部１３４が有する属性抽出ニューラルネットワーク１５０（図１２参照）を用いて行われる。以下では、属性の抽出処理の一例を説明する。
図１２に示す属性抽出ニューラルネットワーク１５０は、入力層１５１と、中間層１５２と、出力層１５３とを有する。

入力層１５１は、センタ側入力１５１ａと顧客側入力１５１ｂとに分類されている。センタ側入力１５１ａにはコンタクトセンタ１２０Ａが顧客に送信したチャットテキストの内容が入力され、また、顧客側入力１５１ｂには顧客がコンタクトセンタ１２０Ａに送信したチャットテキストの内容が入力される。入力層１５１の各入力は、特定の文節に対応付けられており、テキストチャットのバイナリデータ化とは、テキストチャットの内容を属性抽出ニューラルネットワーク１５０の入力層１５１の形式に変換することを意味している。

例えば、センタ側から「何かお困りですか？」を質問し、顧客側から「製品Ｘが壊れた」との回答があった場合を想定する。
まず、「何かお困りですか？」を文節に分解して意味を解釈すると、「質問」と「困っているか？」とを取得することができる。そのため、センタ側入力１５１ａの項目「質問」に対応する入力が「１」となり、また項目「困っているか？」に対応する入力が「１」となり、それ以外の項目の入力が「０」となる。つまり、「何かお困りですか？」のバイナリデータは「1010」となり、このバイナリデータ「1010」がセンタ側入力１５１ａに入力される。

また、「製品Ｘが壊れた」を文節に分解して意味を解釈すると、「製品Ｘ」と「壊れた」とを取得することができる。そのため、顧客側入力１５１ｂの項目「製品Ｘ」に対応する入力が「１」となり、また、項目「壊れた」に対応する入力が「１」となり、それ以外の項目の入力が「０」となる。つまり、「製品Ｘが壊れた」のバイナリデータは「1010」となり、このバイナリデータ「1010」が顧客側入力１５１ｂに入力される。

中間層１５２は、入力層１５１から入力された情報に基づき中間演算を行う。中間層１５２の構成（例えば、階層数）は特に限定されない。
ここで、例えば、中間層１５２が３つの階層を有するならば、中間層１５２の構成は、図１２に示されるように、中間層（第１階層）１５２−１、中間層（第２階層）１５２−２、中間層（第３階層）１５２−３を有する。
各階層における中間層１５２は、当該中間層の左側から複数の入力信号を入力して、当該中間層の右側に複数の出力信号を出力する。
複数の出力信号における各出力信号は、複数の入力信号における各入力信号に対して、各入力信号に対応する重みが掛けられた上で、重みが掛けられた各入力信号を加算した信号である。
なお、最終階層の中間層における出力信号の数は、出力層１５３（後記）で出力される属性に関する情報の数（属性バイナリにおけるバイナリの桁数［例えば、図１２であれば「４」］）である。また、最終階層以外の中間層における出力信号の数は、任意の数（正の整数）である。

出力層１５３の各出力は、特定の文節に対応付けられており、出力層１５３からは属性に関する情報（属性バイナリ）が出力される。
例えば、センタ側から「何かお困りですか？」を質問し、顧客側から「製品Ｘが壊れた」との回答があった場合を想定する。この場合、中間層１５２での処理によって、項目「製品Ｘ」に対応する出力が「１」となり、また、項目「修理」に対応する出力が「１」となり、それ以外の項目の出力が「０」となる。つまり、この場合の属性のバイナリは「1010」となる。そして、属性バイナリ「1010」と属性「製品Ｘの修理」とを関連づけておくことで、入力層１５１に「何かお困りですか？」および「製品Ｘが壊れた」を入力した場合の出力として属性「製品Ｘの修理」を得ることができる。

図９を参照して、制御データベース１４０に格納される提示情報テーブル１４２の構成について説明する。図９は、提示情報テーブル１４２の構成例である。提示情報テーブル１４２は、コンタクトセンタシステム１００Ａの管理者によって予め作成されるものである。
提示情報テーブル１４２は、属性ＩＤ１４２ａと、属性１４２ｂと、提示する情報１４２ｃとからなる。

属性ＩＤ１４２ａは、属性情報テーブル１４１（図８参照）の属性ＩＤ１４１ｇと同じであり、属性１４２ｂを一意に識別する情報である。
属性１４２ｂは、属性情報テーブル１４１（図８参照）の属性１４１ｅと同じであり、センタ側テキスト１４１ａと顧客側テキスト１４１ｃに紐付く属性である。
提示する情報１４２ｃは、属性１４２ｂに紐付いており、顧客に提示する情報である。ここでは、提示する情報１４２ｃをＸＭＬ（Extensible Markup Language）で表現しているが、他の表現方法であってもよい。

図１０を参照して、制御データベース１４０に格納されるオペレータグループ情報テーブル１４３の構成について説明する。図１０は、オペレータグループ情報テーブル１４３の構成例である。オペレータグループ情報テーブル１４３は、コンタクトセンタシステム１００Ａの管理者によって予め作成されるものである。
オペレータグループ情報テーブル１４３は、オペレータＩＤ（Identification）１４３ａと、オペレータグループＩＤ１４３ｂと、属性バイナリ１４３ｃとからなる。

オペレータＩＤ１４３ａは、オペレータを一意に識別する情報であり、ここでは、「オペレータα」、「オペレータβ」を例示している。
オペレータグループＩＤ１４３ｂは、オペレータの集団を一意に識別する情報であり、ここでは、「グループ１」、「グループ２」を例示している。オペレータグループは、例えば、業務で分類されており、「グループ１」に所属するオペレータは「製品Ｘ」に関する業務を行い、「グループ２」に所属するオペレータは「製品Ｙ」に関する業務を行う。なお、「オペレータグループ」は、「所属グループ」の一例である。

属性バイナリ１４３ｃは、属性情報テーブル１４１（図８参照）の属性バイナリ１４１ｆと同じである。ここでは、「10XX」、「01XX」を例示している（なお、「X」は「0」,「1」のどちらでもよいことを意味する）。つまり、属性バイナリ１４１ｆが「10XX」は、「1000」、「1001」、「1010」、「1011」を含み、「製品Ｘ」に関する属性であることを意味する。また、属性バイナリ１４１ｆが「01XX」は、「0100」、「0101」、「0110」、「0111」を含み、「製品Ｙ」に関する属性であることを意味する。属性バイナリ１４３ｃとオペレータグループＩＤ１４３ｂとは１対１の関係になっている。

図１１を参照して、制御データベース１４０に格納される顧客チャット情報テーブル１４４の構成について説明する。図１１は、顧客チャット情報テーブル１４４の構成例である。顧客チャット情報テーブル１４４は、顧客とオペレータとがチャットを行うことによって更新される。
顧客チャット情報テーブル１４４は、顧客ＩＤ１４４ａと、オペレータＩＤ１４４ｂと、チャット回数１４４ｃとからなる。

顧客ＩＤ１４４ａは、顧客を一意に識別する情報であり、ここでは、「顧客Ａ」、「顧客Ｂ」、「顧客Ｃ」を例示している。
オペレータＩＤ１４４ｂは、オペレータグループ情報テーブル１４３（図１０参照）のオペレータＩＤ１４３ａと同じであり、オペレータを一意に識別する情報である。
チャット回数１４４ｃは、顧客とオペレータとの間で行ったチャットの回数である。

≪第２実施形態に係るコンタクトセンタシステムの動作について≫
図１３を参照（適宜、図７ないし図１１を参照）して、第２実施形態に係るコンタクトセンタシステム１００Ａの動作（図６ＡのステップＳ２０１，Ｓ２０２の処理を応用したものである）について説明する。図１３は、第２実施形態に係るコンタクトセンタシステム１００Ａの動作（図６ＡのステップＳ２０１，Ｓ２０２の処理を応用したものである）を示すフローチャートである。

最初に、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）が、顧客端末１０４に質問文を送信する（ステップＳ４０１）。また、属性情報テーブル１４１（図８参照）のセンタ側テキスト１４１ａに送信した質問文の内容が格納される。
それに対して、顧客端末１０４が、コンタクトセンタサーバ１３０に質問文の回答文を送信する（ステップＳ４０２）。また、属性情報テーブル１４１（図８参照）の顧客側テキスト１４１ｃに送信された回答文の内容が格納される。
なお、顧客端末１０４から先にテキストチャットを送信してもよい。その場合、属性情報テーブル１４１（図８参照）のセンタ側テキスト１４１ａには何も格納されない。

次に、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）が、チャットテキストをバイナリ化して、そのバイナリデータを元に属性抽出を行う（ステップＳ４０３）。このバイナリ化は、予め決められたルール（属性抽出ニューラルネットワーク１５０（図１２参照）の入力層１５１に対応）に従って行われる。属性情報テーブル１４１（図８参照）のセンタ側テキストバイナリ１４１ｂに、送信した質問文のバイナリデータが格納され、また、属性情報テーブル１４１（図８参照）の顧客側テキストバイナリ１４１ｄに、送信された回答文のバイナリデータが格納される。属性抽出は、チャット制御部１３４の属性抽出ニューラルネットワーク１５０（図１２参照）を用いて行われ、抽出された属性バイナリ１４１ｆ、属性１４１ｅおよび属性ＩＤ１４１ｇは、属性情報テーブル１４１（図８参照）に格納される。

その後、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、属性が定まっているか否かを確認する(ステップＳ４０４)。この確認は、提示情報テーブル１４２（図９参照）を用いて提示する情報が用意できるかを確認するものであり、例えば、ステップＳ４０３で抽出した属性（属性情報テーブル１４１（図８参照）の属性ＩＤ１４１ｇ）が提示情報テーブル１４２の属性ＩＤ１４２ａと合致したか否かを確認する。なお、属性の抽出方法によっては、属性の一致が完全一致でなく、属性が同じとみなされるものであってもよい。

抽出した属性が定まっている場合（ステップＳ４０４で“Ｙｅｓ”）、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、抽出した属性を元にして顧客に提示する情報を作成してから（ステップＳ４２１）、作成した情報をチャットを介して顧客に提示する（ステップＳ４２２）。提示する情報は、提示情報テーブル１４２（図９参照）の提示する情報１４２ｃを用いる。これにより、顧客は、コンタクトセンタ１２０Ａに問い合わせたことに対する回答を得ることになる。

一方、抽出した属性が定まっていない場合（ステップＳ４０４で“Ｎｏ”）、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、チャットを開始してから一定時間が経過しているか否かを確認する（ステップＳ４０５）。なお、この判定は、顧客とコンタクトセンタサーバ１３０との間のチャットの回数が所定回数を超えたか否かであってもよい。チャットを開始してから一定時間が経過していない場合（ステップＳ４０５で“Ｎｏ”）に、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、顧客端末１０４に質問文を再度送信する（ステップＳ４０１）。そして、ステップＳ４０２〜ステップＳ４０４の処理を再び行う。

チャットを開始してから一定時間が経過している場合（ステップＳ４０５で“Ｙｅｓ”）に、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、ステップＳ４０３で抽出した属性に関連すると考えられるオペレータグループ（例えば、属性が近いオペレータグループ）に通知する（ステップＳ４０６）。このオペレータグループへの通知は、オペレータグループ情報テーブル１４３（図１０参照）を用いる。例えば、「製品Ｘ」に関する業務（属性バイナリ「10XX」）については、「グループ１」に所属するオペレータに通知し、また、「製品Ｙ」に関する業務（属性バイナリ「01XX」）については、「グループ２」に所属するオペレータに通知する。なお、どの製品に関するものであるか分からない場合（例えば、属性バイナリ「0010」や「0001」など）には、例えば、「グループ１」および「グループ２」に所属するオペレータに通知する。

次に、オペレータグループが質問文を作成する（ステップＳ４０７）。この質問文の作成は、例えば、通知を受けたオペレータグループに属する全てのオペレータが行う。そして、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、オペレータグループの質問文を選択して顧客に質問文を送信する（ステップＳ４０８）。この質問文の選択は、例えば先着順で良い。その際、顧客チャット情報テーブル１４４（図１１参照）にて、質問文が選択されたオペレータのチャット回数１４４ｃを「＋１」する。

それに対して、顧客端末１０４が、コンタクトセンタサーバ１３０に質問文の回答文を送信する（ステップＳ４０９）。そして、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）が、ステップＳ４０８およびステップＳ４０９で送信されたチャットテキストを元に属性を抽出（作成）する（ステップＳ４１０）。このステップＳ４１０の処理は、先に説明したステップＳ４０３の処理と同様である。なお、ステップＳ４０８およびステップＳ４０９で送信されたチャットテキストを参考にして、オペレータ自身が属性を入力（作成）してもよい。

その後、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、属性が定まっているか否かを確認する（ステップＳ４１１）。このステップＳ４１１の処理は、先に説明したステップＳ４０４の処理と同様である。

抽出した属性が定まっている場合（ステップＳ４１１で“Ｙｅｓ”）、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、抽出した属性を元にして顧客に提示する情報（例えば、ＵＲＬを含んだメッセージ）を作成してから（ステップＳ４２１）、作成した情報をチャットを介して顧客に提示する（ステップＳ４２２）。提示する情報は、提示情報テーブル１４２（図９参照）の提示する情報１４２ｃを用いる。

一方、抽出した属性が定まっていない場合（ステップＳ４１１で“Ｎｏ”）、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、オペレータとの間でチャットを開始してから一定時間が経過しているか否かを確認する（ステップＳ４１２）。ここでの一定時間は、ステップＳ２０５の判定で用いた一定時間よりも長い値（一定時間よりも長い時間）を用いるのがよい。なお、この判定は、顧客とコンタクトセンタサーバ１３０との間のチャットの回数が所定回数を超えたか否かであってもよい。チャットを開始してから一定時間が経過していない場合（ステップＳ４１２で“Ｎｏ”）に、オペレータグループは、質問文を再度作成する（ステップＳ４０７）。そして、ステップＳ４０８〜ステップＳ４１１の処理を再び行う。

チャットを開始してから一定時間が経過している場合（ステップＳ４１２で“Ｙｅｓ”）に、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、顧客端末１０４が音声通話可能か確認する（ステップＳ４１３）。この確認方法は特に限定されず、例えば、顧客から電話番号が通知されてきたか否かであってもよいし、顧客に対して電話番号を聞いた結果であってもよい。

顧客端末１０４が音声通話不可能である場合（ステップＳ４１３で“Ｎｏ”）、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、チャットを介して、顧客に音声通話先の電話番号と一意タグを提示する（ステップＳ４２３）。この一意タグは、コンタクトセンタ１２０Ａの通話番号であっても良いし、顧客ＩＤや顧客ＩＤに紐付く文字列であっても良い。その後、顧客がコンタクトセンタサーバ１３０に電話を行う際に一意タグを入力する（ステップＳ４２４）。この一意タグの入力は、電話発信時に行っても良いし、通話開始後に入力しても良い。

一方、顧客端末１０４が音声通話可能である場合（ステップＳ４１３で“Ｙｅｓ”）、コンタクトセンタサーバ１３０（特に、チャット制御部１３４）は、チャットを行っているオペレータグループ（チャットオペレータグループ）からチャット回数の多いオペレータを選択する（ステップＳ４１４）。チャット回数の多いオペレータの選択には、顧客チャット情報テーブル１４４（図１１参照）を用いる。そして、コンタクトセンタサーバ１３０（特に、呼制御部１３３）は、選択したオペレータに呼を転送し、顧客端末１０４を操作する顧客と選択されたオペレータとが音声通話を開始する（ステップＳ４１５）。

以上のように、第２実施形態におけるコンタクトセンタシステム１００Ａ（特に、コンタクトセンタサーバ１３０）では、質問文をセンタ側テキスト、回答文を顧客側テキストとして属性抽出を行う。そして、属性が定まっていない場合かつチャットを開始してから一定時間が経過または所定回数を超えている場合のみオペレータグループへの通知を行う。そのため、管理者が対応状況を的確にモニタリングしなくても、チャットをオペレータグループに引き継ぐことができる。

また、第２実施形態におけるコンタクトセンタシステム１００Ａ（特に、コンタクトセンタサーバ１３０）は、オペレータグループにチャットを引き継ぎ、オペレータグループが質問文を作成してから、オペレータグループの質問文を先着順等の方法で選択し顧客に質問文を送信する。そのため、複数のオペレータが同時に複数の顧客に対応することができる。

加えて、第２実施形態におけるコンタクトセンタシステム１００Ａ（特に、コンタクトセンタサーバ１３０）は、顧客端末１０４が音声通話不可能である場合、顧客に音声通話先の電話番号と一意タグを提示する。そして、顧客が電話時に一意タグを入力することで、顧客が別の電話機から電話発信を行っても、チャットを行った顧客と同一であることをコンタクトセンタ１２０Ａ側で判断できる。そのため、顧客が後で電話をかけてきた場合に、オペレータは、顧客の情報やチャットの内容を予め把握することが可能であり、適切な対応を行うことが可能である。

以上、本発明の第２実施形態について説明したが、本発明はこれに限定されるものではなく、特許請求の範囲の趣旨を変えない範囲で実施することができる。

第２実施形態では、顧客電話機１０１と顧客端末１０４は、別々の装置として記載したが、１つの装置（例えば、スマートフォン、ソフトフォンが搭載されたパーソナルコンピュータなど）でもよい。

１００，１００Ａ コンタクトセンタシステム
１０１ 顧客電話機
１０４ 顧客端末
１０９ 呼制御装置
１１０ チャット制御装置
１１１ 言語データ認識装置
１１２ データ蓄積部
１１３ 業務識別データ部
１１３ａ 業務識別データテーブル
１１４ 業務別蓄積データ部
１１４ａ エスカレーション率算出用テーブル
１１４ｂ エスカレーション予測量算出用テーブル
１１４ｃ 所属グループ変更用テーブル
１１５ テキストデータ処理部
１１６ 蓄積データ管理部
１１７ 管理者端末
１１８ 業務別グループ
１１９ オペレータ端末
１２０，１２０Ａ コンタクトセンタ
１３０ コンタクトセンタサーバ
１３１ 通信部
１３２ 表示制御部
１３３ 呼制御部
１３４ チャット制御部
１４０ 制御データベース
１４１ 属性情報テーブル
１４２ 提示情報テーブル
１４３ オペレータグループ情報テーブル
１４４ 顧客チャット情報テーブル

Claims (12)

1. 顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理部と、
   チャットの数の情報と、
   前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得する取得処理部と、
   前記取得処理部で取得した情報から得られる、前記エスカレーションの割合の情報より、
   第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理部と
   を有することを特徴とする処理装置。
2. 前記取得処理部は、第１の期間における前記エスカレーションの数の情報を取得し、
   前記変更処理部は、前記エスカレーションの割合の情報と第２の期間における問い合わせ件数の情報を用いて、前記第２の期間における所属グループごとのエスカレーション予測量の情報を求め、全体のエスカレーション予測量に対する各所属グループのエスカレーション予測量の割合の情報を求める
   ことを特徴とする請求項１に記載の処理装置。
3. 前記変更処理部は、前記オペレータの人数の情報と各所属グループのエスカレーション予測量の割合の情報を用いて、前記第１所属グループから前記第２所属グループに変更する数を決定する
   ことを特徴とする請求項２に記載の処理装置。
4. 前記第１の期間は、前記エスカレーションの発生の傾向が反映される周期的な期間であり、
   前記第２の期間は、前記周期的な期間のうちの一つである
   ことを特徴とする請求項２または請求項３に記載の処理装置。
5. 前記顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、
   抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御部をさらに有する
   ことを特徴とする請求項１に記載の処理装置。
6. 顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、
   抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御部を有する
   ことを特徴とする処理装置。
7. 前記チャット制御部は、
   通知を受けた前記特定の所属グループに属するオペレータが作成した質問文を選択して前記顧客に送信する
   ことを特徴とする請求項６に記載の処理装置。
8. 前記チャット制御部は、
   前記オペレータが作成した質問文の送信後に行ったチャットから属性の抽出を再度行い、再度抽出した前記属性が予め設定したものと一致しない場合、かつ、前記顧客が操作する顧客端末が音声通話不可能である場合に、音声通話先の識別情報および第１識別情報を前記顧客に送信する
   ことを特徴とする請求項７に記載の処理装置。
9. コンピュータを、
   顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理部、
   チャットの数の情報と、
   前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得する取得処理部、
   前記取得処理部で取得した情報から得られる、前記エスカレーションの割合の情報より、
   第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理部
   として機能させるためのプログラム。
10. 処理装置の処理方法であって、
    前記処理装置は、
    顧客から受信したチャットにおける問い合わせ情報について、オペレータの所属グループ情報と紐付けして蓄積する蓄積処理ステップと、
    チャットの数の情報と、
    前記所属グループ情報におけるオペレータへのエスカレーションの数の情報を取得する取得処理ステップと、
    前記取得処理ステップで取得した情報から得られる、前記エスカレーションの割合の情報より、
    第１オペレータにおける第１所属グループの情報を、第２所属グループの情報に変更する変更処理ステップと
    を有することを特徴とする処理方法。
11. コンピュータを、
    顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、
    抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御部
    として機能させるためのプログラム。
12. 処理装置の処理方法であって、
    前記処理装置は、
    顧客に送信および前記顧客から受信したチャットから属性の抽出を行い、抽出した前記属性が予め設定したものと一致した場合に、前記顧客に対して当該属性に関する情報を送信し、
    抽出した前記属性が予め設定したものと一致しない場合、かつ、前記チャットを開始してから所定時間が経過または所定回数を超えた場合に、特定の所属グループへの通知を行うチャット制御ステップを有する
    ことを特徴とする処理方法。

Images