JP6350670B2 - 応対支援装置、制御方法、及びプログラム - Google Patents

Description

本発明は、応対支援装置、制御方法、及びプログラムに関する。

製品に関する相談や修理の受付などに、コールセンタが利用されている。コールセンタでは、発生した呼が順次オペレータの端末に接続される。ここで、一度に多くの呼が発生すると、オペレータに空きが出るまでの間、一部の呼は待機させられる。

このようなコールセンタの利便性を向上させるために、コールセンタに関するシステム等が開発されている。特許文献１は、コールセンタの待ち状況を算出してその結果をユーザの端末に表示し、コールセンタへの問い合わる方法をユーザが選択できるようにするシステムを開示している。特許文献２は、コールセンタに接続したユーザに急ぎの要件であるか否かを選択させ、選択結果に応じてユーザへの応対方法を決定するシステムを開示している。特許文献３は、コールセンタへの問い合わせ回数が少ないユーザの呼の優先度を、問い合わせ回数が多いユーザの呼の優先度より高くすることで、ユーザが公平にサポートを受けられるようにするシステムを開示している。

特開２０１２−８０１９８号公報 特許第４８０４３８５号公報 特許第４９９９１９６号公報

コールセンタが混雑すると、オペレータと話をするまでユーザは長時間待たされることになる。ユーザにとって、長時間待たされるコールセンタは使い勝手が悪い。そのため、各ユーザの待ち時間を短くすることが求められる。

特許文献１のシステムにおいて、ユーザは、待ち時間が長い場合にコールバックを予約することができる。しかしこのシステムでは、問い合わせたい事象が発生してから実際に問い合わせを行える（オペレータと話すことができる）までの時間は短くならない。そのため、コールセンタが混雑している場合、ユーザは長時間コールバックを待つこととなる。

特許文献２のシステムの場合、「急ぎの要件」を選択したユーザは、オペレータに空きが出ることを待つことになる。そのため、急ぎの要件があるユーザが多い場合、ユーザの待ち時間は長くなる。

特許文献３のシステムの場合、待ち時間についてユーザ間の公平性を保つことができるものの、コールセンタが混雑すると各ユーザの待ち時間は長くなる。

本発明の目的は、以上の課題に鑑みてなされたものである。本発明の目的は、コールセンタにおけるユーザの待ち時間を短くする技術を提供することである。

本発明が提供する応対支援装置は、呼の積滞数を取得する積滞数取得手段と、オペレータが呼の応対に要する時間の予測値を表す応対予測時間と前記積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する第１予測手段と、前記第１予測手段による予測結果に基づいて、複数のコンテンツを記憶しているコンテンツ記憶手段から送信するコンテンツを特定し、オペレータが利用する端末へ特定したコンテンツを送信するコンテンツ送信手段と、を有する。各コンテンツは、オペレータが呼の応対に用いる情報を含む。前記コンテンツ送信手段は、前記第１予測手段によって呼の積滞があると予測された場合、呼の積滞がないと予測された場合に取得する前記コンテンツよりも少ない量の前記コンテンツを送信する。

本発明が提供する制御方法は、コンピュータによって実行される。当該制御方法は、呼の積滞数を取得する積滞数取得ステップと、オペレータが呼の応対に要する時間の予測値を表す応対予測時間と前記積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する第１予測ステップと、前記第１予測ステップによる予測結果に基づいて、複数のコンテンツを記憶しているコンテンツ記憶手段から送信するコンテンツを特定し、オペレータが利用する端末へ特定したコンテンツを送信するコンテンツ送信ステップと、を有する。各コンテンツは、オペレータが呼の応対に用いる情報を含む。前記コンテンツ送信ステップは、前記第１予測ステップによって呼の積滞があると予測された場合、呼の積滞がないと予測された場合に取得する前記コンテンツよりも少ない量の前記コンテンツを送信する。

本発明が提供するプログラムは、コンピュータに、本発明が提供する応対支援装置として動作する機能を持たせる。

本発明によれば、コールセンタにおけるユーザの待ち時間を短くする技術が提供される。

上述した目的、およびその他の目的、特徴および利点は、以下に述べる好適な実施の形態、およびそれに付随する以下の図面によってさらに明らかになる。

実施形態１に係る応対支援装置をその使用環境と共に例示するブロック図である。 実施形態１の応対支援装置２０００によって実行される処理の流れを例示するフローチャートである。 応対支援装置を実現する計算機のハードウエア構成を例示するブロック図である。 呼の状態をテーブル形式で例示する図である。 コンテンツ記憶部に記憶されているコンテンツをテーブル形式で例示する第１の図である。 コンテンツ記憶部に記憶されているコンテンツをテーブル形式で例示する第２の図である。 コンテンツを取得したオペレータ端末によって表示される画面を例示する図である。 実施形態２に係る応対支援装置をその使用環境と共に例示するブロック図である。 実施形態２の応対支援装置によって実行される処理の流れを例示するフローチャートである。 実施形態２の変形例の応対支援装置２０００によって実行される処理の流れを例示するフローチャートである。 実施形態３に係る応対支援装置をその使用環境と共に例示するブロック図である。 実施形態３の応対支援装置によって実行される処理の流れを例示するフローチャートである。 実施形態４に係る応対支援装置をその使用環境と共に例示するブロック図である。 積滞が発生すると予測された場合における呼への応対の流れを概念的に例示する図である。

以下、本発明の実施の形態について、図面を用いて説明する。尚、すべての図面において、同様な構成要素には同様の符号を付し、適宜説明を省略する。

［実施形態１］
図１は、実施形態１に係る応対支援装置２０００をその使用環境と共に例示するブロック図である。図１において、矢印は情報の流れを示している。また図１において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。

応対支援装置２０００は、オペレータ端末１０００を用いるオペレータによる呼への応対を支援する装置である。オペレータ端末１０００は、交換機４０２０と接続されている。交換機４０２０は、顧客等からの発信された呼を受け付ける。交換機４０２０は、受け付けた呼をオペレータ端末１０００へ接続する。ここで、交換機４０２０において、呼をオペレータ端末１０００に接続させたり、オペレータ端末１０００に空きがない場合に呼を待ち行列で待機させたりするといった技術は既知の技術である。そのため、交換機４０２０の動作の詳細については省略する。

さらにオペレータ端末１０００は、顧客等からの電話に応対するオペレータが、応対に用いる情報（コンテンツ）を取得するために利用される。ここで、応対支援装置２０００が支援する対象となるオペレータ端末１０００の数は、１つであってもよいし、複数であってもよい。

応対支援装置２０００は、積滞数取得部２０２０、第１予測部２０４０、及びコンテンツ送信部２０６０を有する。積滞数取得部２０２０は、交換機４０２０が受け付けた呼の積滞数を取得する。ここで、積滞数は、交換機４０２０においてオペレータ端末１０００への接続を待っている呼の数である。第１予測部２０４０は、応対予測時間と積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する。ここで、応対予測時間とは、オペレータが呼への応対に要する時間の予測値である。コンテンツ送信部２０６０は、オペレータ端末１０００に対して、コンテンツ記憶部４０４０に記憶されているコンテンツを送信する。ここで、コンテンツ記憶部４０４０に記憶されているコンテンツは、オペレータ端末１０００を利用するオペレータが呼への応対に利用する情報である。例えばこの情報は、顧客とのやりとりの内容や手順を表す情報などを含んでいる。

所定時間後に呼の積帯があると予測された場合にオペレータ端末１０００へ送信されるコンテンツは、所定時間後に呼の積帯が無いと予測された場合にオペレータ端末１０００へ送信されるコンテンツと比較し、オペレータが顧客の応対に要する時間が短くなるように構成される。例えば、コンテンツ送信部２０６０が送信するコンテンツの量が、第１予測部２０４０によって呼の積滞があると予測された場合と、呼の積滞がないと予測された場合とで異なる。具体的には、呼の滞積があると予測された場合にコンテンツ送信部２０６０が送信するコンテンツの量は、呼の滞積がないと予測された場合にコンテンツ送信部２０６０が送信するコンテンツの量よりも少ない。以下、呼の滞積がないと予測された場合にコンテンツ送信部２０６０が送信するコンテンツを通常時コンテンツと表記し、呼の滞積があると予測された場合にコンテンツ送信部２０６０が送信するコンテンツを積滞時コンテンツと表記する。例えば積滞時コンテンツは、通常時コンテンツの一部を省略した情報である。なお、コンテンツ送信部２０６０が送信するコンテンツの量を異ならせる具体的な方法については後述する。

なお、コンテンツ記憶部４０４０は、応対支援装置２０００の内部に設けられていてもよいし、応対支援装置２０００の外部に設けられていてもよい。

＜処理の流れ＞
図２は、実施形態１の応対支援装置２０００によって実行される処理の流れを例示するフローチャートである。積滞数取得部２０２０は、積滞数を取得する（Ｓ１０２）。第１予測部２０４０は、応対予測時間と積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する（Ｓ１０４）。第１予測部２０４０によって呼の積滞がないと予測された場合（Ｓ１０６：ＮＯ）、図２の処理はステップＳ１０８に進む。ステップＳ１０８において、コンテンツ送信部２０６０は、通常時コンテンツを送信する。一方、第１予測部２０４０によって呼の積滞があると予測された場合（Ｓ１０６：ＹＥＳ）、図２の処理はステップＳ１１０に進む。ステップＳ１１０において、コンテンツ送信部２０６０は、積滞時コンテンツを送信する。ここで、積滞時コンテンツは、Ｓ１０８で送信する通常時コンテンツよりも少ない量のコンテンツである。

＜作用・効果＞
本実施形態によれば、所定時間後に呼の積滞があると予測された場合に、呼の積滞がないと予測された場合と比較し、オペレータ端末１０００がコンテンツ記憶部４０４０から取得するコンテンツの量が少なくなる。例えばオペレータが顧客とのやりとりの内容や手順をコンテンツとして取得する場合、所定時間後に呼の積滞が予測されると、オペレータが顧客との間で行うやりとりの内容や手順の一部が省略された情報が取得される。こうすることで、オペレータが顧客に対する応対に要する時間を短くすることができる。その結果、オペレータの応対を待っている顧客の待ち時間を短くすることができる。

以下、本実施形態の応対支援装置２０００やオペレータ端末１０００についてさらに詳細に説明する。

＜ハードウエア構成例＞
オペレータ端末１０００や応対支援装置２０００の各機能構成部は、各機能構成部を実現するハードウエア（例：ハードワイヤードされた電子回路など）で実現されてもよいし、ハードウエアとソフトウエアとの組み合わせ（例：電子回路とそれを制御するプログラムの組み合わせなど）で実現されてもよい。以下、各機能構成部をハードウエアとソフトウエアとの組み合わせで実現する場合について、その構成を具体的に例示する。

オペレータ端末１０００や応対支援装置２０００は、携帯型端末、PC（Personal Computer）、又はサーバなどの種々の計算機で実現される。ここでオペレータ端末１０００や応対支援装置２０００は、オペレータ端末１０００や応対支援装置２０００を実現するための専用の計算機で実現されてもよいし、その他のアプリケーション等も動作させる汎用の計算機で実現されてもよい。

＜＜応対支援装置２０００のハードウエア構成例＞＞
図３は、応対支援装置２０００を実現する計算機５０００のハードウエア構成を例示するブロック図である。計算機５０００は、バス５０２０、プロセッサ５０４０、メモリ５０６０、ストレージ５０８０、及び入出力インタフェース５１００を有する。バス５０２０は、プロセッサ５０４０、メモリ５０６０、ストレージ５０８０、及び入出力インタフェース５１００が、相互にデータを送受信するためのデータ伝送路である。ただし、プロセッサ５０４０などを互いに接続する方法は、バス接続に限定されない。プロセッサ５０４０は、例えば CPU (Central Processing Unit) や GPU (Graphics Processing Unit) などの演算処理装置である。メモリ５０６０は、例えば RAM (Random Access Memory) や ROM (Read Only Memory) などのメモリである。ストレージ５０８０は、例えばハードディスク、SSD (Solid State Drive)、又はメモリカードなどの記憶装置である。また、ストレージ５０８０は、RAM や ROM 等のメモリであってもよい。

入出力インタフェース５１００は、計算機５０００が外部の装置等との間でデータを送受信するための入出力インタフェースである。例えば応対支援装置２０００が交換機４０２０から積滞数を取得する場合、応対支援装置２０００を実現する計算機５０００は、入出力インタフェース５１００を介して交換機４０２０と接続されている。なお、入出力インタフェースを介して計算機５０００と外部の装置とを接続する方法は様々である。例えばこの接続は、バス回線（例えばUSB (Universal Serial Bus) 回線）を介したバス接続や、ネットワーク回線を介したネットワーク接続（例えばLAN (Local Area Network））などである。なお、ネットワーク回線は無線回線であってもよいし有線回線であってもよい。

ストレージ５０８０は、応対支援装置２０００の機能を実現するためのプログラムを記憶している。具体的には、積滞数取得部２０２０、第１予測部２０４０及びコンテンツ送信部２０６０の機能をそれぞれ実現するプログラムモジュールを記憶している。プロセッサ５０４０は、これら各プログラムモジュールを実行することで、積滞数取得部２０２０、第１予測部２０４０、及びコンテンツ送信部２０６０の機能をそれぞれ実現する。ここでプロセッサ５０４０は、上記各モジュールを実行する際、これらのモジュールをメモリ５０６０上に読み出してから実行してもよいし、メモリ５０６０上に読み出さずに実行してもよい。

コンテンツ記憶部４０４０が応対支援装置２０００の内部に設けられる場合、コンテンツ記憶部４０４０は、メモリ５０６０又はストレージ５０８０によって実現される。具体的には、メモリ５０６０又はストレージ５０８０がコンテンツを記憶する。一方、コンテンツ記憶部４０４０が応対支援装置２０００の外部に設けられる場合、応対支援装置２０００は、入出力インタフェース５１００を介してコンテンツ記憶部４０４０と接続されている。

なお、応対支援装置２０００を実現する計算機５０００のハードウエア構成は図３に示した構成に限定されない。例えば、各プログラムモジュールはメモリ５０６０に格納されてもよい。この場合、計算機５０００はストレージ５０８０を備えていなくてもよい。

また、応対支援装置２０００は、複数の計算機を用いて実現されてもよい。例えば、応対支援装置２０００は、積滞数取得部２０２０及び第１予測部２０４０の機能を実現する計算機と、コンテンツ送信部２０６０の機能を実現する計算機の組み合わせで実現される。積滞数取得部２０２０及び第１予測部２０４０の機能を持つ計算機は、呼の積滞を予測する装置といえる。また、コンテンツ送信部２０６０の機能を持つ計算機は、第１予測部２０４０による予測結果に基づくコンテンツをオペレータ端末１０００へ送信する装置といえる。後者の計算機は、例えばオペレータ端末１０００からコンテンツの送信依頼を受け付け、コンテンツを返信するデータベースサーバとして実現される。このデータベースサーバは、オペレータ端末１０００からの依頼に合致し、かつ第１予測部２０４０による予測結果に基づいて特定されるコンテンツを返信する。

＜＜オペレータ端末１０００のハードウエア構成例＞＞
オペレータ端末１０００を実現する計算機のハードウエア構成は、例えば応対支援装置２０００を実現する計算機と同様に図３で表される。オペレータ端末１０００を実現する計算機５０００は、入出力インタフェース５１００を介して応対支援装置２０００や交換機４０２０と接続されている。

オペレータ端末１０００を実現する計算機５０００において、ストレージ５０８０は、オペレータ端末１０００の機能を実現するためのプログラムを記憶している。具体的には、呼を受け付ける機能（電話としての機能）を実現するプログラムモジュール、及びコンテンツ送信部２０６０によって送信されるコンテンツを取得する機能を実現するプログラムモジュールを有する。プロセッサ５０４０は、これらのプログラムモジュールを実行する。

なお、オペレータ端末１０００のうち、呼を受け付ける機能（電話としての機能）を実現する計算機と、コンテンツを取得する機能を実現する計算機とは、それぞれ異なる計算機で実現されていてもよい。ここで、電話としての機能を実現する計算機は、例えば一般の電話端末でもよい。

＜積滞数取得部２０２０の詳細＞
積滞数取得部２０２０が積滞数を取得する方法は様々である。例えば積滞数取得部２０２０は、呼を制御する交換機（図１における交換機４０２０など）から積滞数を取得する。また例えば、交換機が積滞数を外部の記憶装置に記憶している場合、積滞数取得部２０２０は、この記憶装置から積滞数を取得してもよい。なお、積滞数取得部２０２０が積滞数を取得する処理は、積滞数取得部２０２０がある装置へアクセスして情報を読み出す処理であってもよいし、積滞数取得部２０２０がある装置から送信される情報を受信する処理であってもよい。

また、応対支援装置２０００は、接続待ちの呼と、現在オペレータ端末１０００に接続されている呼との総数（交換機４０２０に発生している呼の総数）を取得してもよい。この場合、応対支援装置２０００は、取得した呼の総数から応対中の呼の数（応対中のオペレータ端末１０００の数）を引くことで、積滞数を算出する。そして積滞数取得部２０２０は、算出された積滞数を取得する。

＜応対予測時間の詳細＞
応対予測時間は、オペレータが呼に応対するために要する時間の予測値である。ここで、オペレータが行う応対には、顧客への電話応対以外の処理が含まれる場合がある。例えば製品の故障に関する問い合わせを受けた場合、オペレータは、顧客との電話応対を終えた後、保守会社等に製品の修理を依頼する必要がある。このような場合、保守会社等に修理の依頼をする時間も、「オペレータが呼に応対するために要する時間」に含まれる。このように、「オペレータが呼に応対するために要する時間」には、顧客との電話応対に要する時間だけでなく、その電話応対が終了した後にオペレータがその呼に関して行う処理に要する時間も含まれてもよい。

＜＜応対予測時間の算出方法＞＞
例えば応対予測時間は、これまでにオペレータが呼への応対に要した時間の統計値（平均値など）である。例えば、オペレータが各呼への応対に要した時間を所定期間（一ヶ月など）記録し、その所定期間の記録から統計値を算出する。

応対予測時間は、全てのオペレータについて共通の値であってもよいし、オペレータごとに異なる値であってもよい。前者の場合、例えば全てのオペレータについて、各呼への応対に要した時間を記録しておき、その時間を統計処理した値を応対予測時間とする。一方後者の場合、各呼への応対に要した時間をオペレータごとに記録しておき、応対に要した時間の統計値（応対予測時間）をオペレータごとに算出する。

なお、応対予測時間の算出は、応対支援装置２０００によって行われてもよいし、応対支援装置２０００とは異なる装置によって行われてもよい。

また応対予測時間は、応対支援装置２０００の管理者等によって手動で定められる値であってもよい。例えば応対支援装置２０００の管理者等は、経験に基づいて応対予測時間を定める。

＜＜応対予測時間の取得方法＞＞
第１予測部２０４０は、応対予測時間が記憶されている記憶部から応対予測時間を取得する。この記憶部は、応対支援装置２０００の内部に設けられていてもよいし、外部に設けられていてもよい。

ここで、上記記憶部に応対予測時間を記憶する方法は様々である。例えば、応対予測時間は、前述した応対予測時間を算出する装置によって上記記憶部に記憶される。また例えば、応対予測時間は、応対支援装置２０００の管理者等によって手動で入力される。手動で応対予測時間を入力する方法は、例えばキー入力やファイル入力などである。

＜第１予測部２０４０の詳細＞
前述したように、第１予測部２０４０は、所定時間後における呼の積滞状態の有無を予測する。ここで、この所定時間は任意の値に設定可能であり、予め応対支援装置２０００の内部又は外部に設けられている記憶部に記憶されている。例えばこの所定時間は、応対支援装置２０００の管理者等によって設定される。この管理者等は、キー入力やファイル入力などによってこの所定時間を設定する。

例えば第１予測部２０４０は、積滞数及び応対中の呼の状態に基づいて呼の積滞を予測する。呼の状態は、その呼に対して応対が行われたか否かや、その呼に対する応対が開始された日時などによって表される。

図４は、呼の状態をテーブル形式で例示する図である。図４に示されているテーブルを、呼状態テーブル２００と表記する。呼ＩＤ２０２は、呼のＩＤを示す。応対開始日時２０４は、呼に対する応対が開始された日時である。応対終了予測日時２０６は、呼に対する応対が終了すると予測される日時である。具体的には、応対終了予測日時２０６は、応対開始日時２０４に応対予測時間を加算した日時となる。終了日時２０８は、呼ＩＤ２０２で特定される呼に対する応対が終了している場合に、その終了日時を示す。

応対開始日時２０４が示されていない呼は、まだ応対が開始されていない呼（交換機４０２０で待ち状態となっている呼）である。また、終了日時２０８に終了日時が示されている呼は、既に応対が終了している呼である。そして、応対開始日時２０４に値が示されており、かつ終了日時２０８に値が示されていない呼は、現在応対中の呼である。

第１予測部２０４０は、交換機４０２０の待ち行列の先頭の呼から順に、所定時間後までにその呼に対して応対が開始されるか否かを予測する。そして第１予測部２０４０は、積滞している全ての呼について所定時間後までに応対が開始されると予測した場合、所定時間後に積滞はないと予測する。一方、第１予測部２０４０は、１つ以上の呼について所定時間後までに応対が開始されないと予測した場合、所定時間後に積滞があると予測する。

待ち行列の先頭の呼に対して所定時間後までに応対が開始されるか否かは、所定時間後までにオペレータに空きが生じるか否かによる。具体的には、現在応対中の呼のうち、応対終了予測日時２０６が最も早い呼について、「現在日時＋所定時間＞応対終了予測日時２０６」となれば、所定時間後までにその応対中の呼への応対が終了すると予測される。そのため、応対を終了したオペレータは、待ち行列の先頭の呼の応対をすることができる。

第１予測部２０４０は、待ち行列の各呼に対して、同様の処理を行う。具体的には、第１予測部２０４０は、次に待ち行列の２番目の呼について、待ち行列の先頭の呼の応対が開始された後かつ現在から所定時間経過後までの間に、いずれかの呼の応対が終了するか否かを予測する。そして、いずれかの呼の応対が終了すると予測した場合、第１予測部２０４０は、待ち行列の２番目の呼への応対が所定時間後までに行われると予測する。第１予測部２０４０は、待ち行列の全ての呼について同様の予測を行っていく。

＜＜具体例＞＞
第１予測部２０４０の動作について、具体例を通じてさらに説明する。本具体例では、前提として、コールセンタに３人のオペレータがいるとする。また、現在日時が 10:10:55 であるとする。さらに、図４の呼状態テーブル２００が、現在の各呼の状態を表しているとする。そして、第１予測部２０４０が用いる「所定時間」は、５秒であるとする。つまり第１予測部２０４０は、５秒後における呼の積滞の有無を予測する。

まず、積滞数取得部２０２０が取得した積滞数が１であるとする。そのため、第１予測部２０４０は、この積滞している１つの呼の応対が５秒後までに開始されるか否かを予測する。第１予測部２０４０は、「現在日時＋５秒」と、各呼の応対終了予測日時２０６とを比較する。その結果、いずれの呼についても「現在日時＋５秒」よりも応対終了予測日時２０６の方が後であることが分かる。よって、現在から５秒後の時点では、全てのオペレータがまだ呼に応対中であり、５秒後までに積滞している呼の応対は開始されない。よって、第１予測部２０４０は、所定時間（５秒）後に呼の積滞があると予測する。

＜＜第１予測部２０４０が予測処理を行うタイミング＞＞
第１予測部２０４０が積滞の有無の予測を行うタイミングは任意である。例えば第１予測部２０４０は、所定の頻度（５秒に１回など）で積滞の有無を予測する。以下、第１予測部２０４０が積滞の有無を予測する処理を実行する頻度を、第１予測頻度と表記する。

第１予測部２０４０は、第１予測頻度を動的に変更してもよい。例えば、積滞が発生していない状況が所定時間以上続いた場合、第１予測部２０４０は第１予測頻度を低くする。積滞が発生していない状況が長く続いている場合、その後も積滞が発生しない状況が続くと予想されるためである。第１予測頻度を低くすることで、応対支援装置２０００の処理負荷や消費電力を小さくすることができる。一方、第１予測部２０４０は、呼の積滞が発生した場合、第１予測頻度を高くする。こうすることで、第１予測部２０４０によって「積滞がない」と予測されるタイミングがより早くなる。その結果、オペレータ端末１０００が取得するコンテンツの量が通常時より少なくなる期間が短くなるため、できる限り顧客に対する応対を充実させることができる。

なお、第１予測部２０４０が積滞の有無を予測するタイミングは、不定期であってもよい。例えば、第１予測部２０４０は、応対支援装置２０００が管理者等から指示を受け付けたタイミングで予測を行う。

＜コンテンツ送信部２０６０の詳細＞
コンテンツは、オペレータが呼の応対に用いる情報である。例えば、製品の故障に関する問い合わせを受け付ける場合、コンテンツは、その製品について「症状、考えられる故障、解決方法」の組み合わせを示す情報である。オペレータはこの情報を利用して、顧客に対して適切な情報を提供したり、顧客から適切な情報を聞き出す。例えば、顧客からある製品が故障しているかもしれないという問い合わせを受けた場合、オペレータは、考えられる故障及びその解決方法を顧客に提供する。それでも問題が解決しない場合、オペレータは、顧客との電話応対を終了し、保守会社へ製品の修理を依頼するといった対応をする。

ここで、オペレータが考えられる全ての故障及び全ての解決方法を顧客へ提供すると、電話応対に長い時間を要する。そこで例えば、オペレータ端末１０００を利用するオペレータは、呼が積滞すると予測される場合（コールセンタ等の混雑が予想される場合）、全ての解決方法を提供するのではなく、優先度の高い代表的な解決方法のみを顧客に提供し、その解決方法で解決しない場合は電話応対を終了して保守会社等に修理を依頼するという応対をするようにする。こうすることで、電話応対にかかる時間を短くすることができ、呼が積滞することを防ぐことができる。この場合、コンテンツ送信部２０６０は、全ての解決方法を示すコンテンツ（通常時コンテンツ）ではなく、上述の代表的な解決方法のみを示すコンテンツ（積滞時コンテンツ）を送信する。

例えばコンテンツ送信部２０６０は、２つの状態をとりうる。第１の状態は、第１予測部２０４０によって所定時間後に積滞がないと予測された後の状態である。この状態を、通常モードと呼ぶ。一方、第２の状態は、第１予測部２０４０によって所定時間後に積滞があると予測された後の状態である。第２の状態を積滞モードと呼ぶ。前述した通常時コンテンツは、通常モードのコンテンツ送信部２０６０がオペレータ端末１０００へ送信するコンテンツである。一方、積滞時コンテンツは、積滞モードのコンテンツ送信部２０６０がオペレータ端末１０００へ送信するコンテンツである。

＜＜送信するコンテンツの特定方法＞＞
コンテンツ送信部２０６０が送信するコンテンツを特定する方法は様々である。例えばコンテンツ記憶部４０４０は、コンテンツに対して、１）第１予測部２０４０によって呼の積帯があると予測された場合にそのコンテンツを取得するか否かを示す情報、及び２）呼の積帯がないと予測された場合にそのコンテンツを取得するか否かを示す情報を対応づけて記憶する。

図５は、上記１）及び２）の情報と対応づけてコンテンツ記憶部４０４０に記憶されているコンテンツをテーブル形式で例示する図である。図５が示すテーブルを、コンテンツテーブル３００と表記する。ここで、図５が示すコンテンツテーブル３００は、設備の故障に関する問い合わせへ応対するオペレータによって利用されるコンテンツを示している。

コンテンツテーブル３００は、コンテンツＩＤ３０２、設備名３０４、概要３０６、コンテンツ３０８、通常時区分３１０、及び積滞時区分３１２という列を有する。コンテンツＩＤ３０２は、各コンテンツのＩＤを示す。設備名３０４は、コンテンツ３０８が対象とする設備の名前を示す。概要３０６は、コンテンツ３０８の概要を示す。コンテンツ３０８は、オペレータが応対に利用する情報を示す。ここで、コンテンツ３０８はHTML 形式で情報を示している。

通常時区分３１０と積滞時区分３１２はそれぞれ、上述の１）と２）に相当する情報を示す。具体的には、通常時区分３１０に数値が示されているレコードのコンテンツ３０８は、通常モードのコンテンツ送信部２０６０が送信するコンテンツである。一方、通常時区分３１０に数値が示されていないレコードのコンテンツ３０８は、通常モードのコンテンツ送信部２０６０が送信しないコンテンツである。つまり、通常時区分３１０に数値が示されているレコードのコンテンツ３０８は、前述した通常時コンテンツである。なお、通常時区分３１０に示されている数値は、各コンテンツを表示画面等に出力する順序を表す。図５に示す例の場合、上のレコードのコンテンツ３０８から順に出力される。

一方、積滞時区分３１２に数値が示されているレコードのコンテンツ３０８は、積滞モードのコンテンツ送信部２０６０が送信するコンテンツである。一方、積滞時区分３１２に数値が示されていないレコードのコンテンツ３０８は、積滞モードのコンテンツ送信部２０６０が送信しないコンテンツである。つまり、積滞時区分３１２に数値が示されているレコードのコンテンツは、前述した積滞時コンテンツである。なお、積滞時区分３１２に示されている数値は、通常時区分３１０に示されている数値と同様の意味を持つ。

図５の場合、通常時コンテンツは全てのレコードのコンテンツ３０８であり、積滞時コンテンツは３行目以外のレコードのコンテンツ３０８である。したがって、積滞モードのコンテンツ送信部２０６０は、３行目以外のレコードによって示されるコンテンツをオペレータ端末１０００へ送信する。

ここで図５の例では、全ての積滞時コンテンツが、通常時コンテンツにも含まれている。しかし、積滞時コンテンツは、通常時コンテンツに含まれなくてもよい。例えば図５の例において、通常時コンテンツを１行目から３行目のレコードのコンテンツ３０８とし、積滞時コンテンツを４行目と５行目のレコードのコンテンツ３０８としてもよい。

＜＜優先度の利用＞＞
また例えば、各コンテンツは、そのコンテンツの優先度と対応づけられてコンテンツ記憶部４０４０に記憶されていてもよい。図６は、優先度と対応付けてコンテンツ記憶部４０４０に記憶されているコンテンツを例示する図である。図６に示すテーブルをコンテンツテーブル４００と表記する。通常時区分３１０及び積滞時区分３１２の代わりに優先度４０２を有する点を除き、コンテンツテーブル４００はコンテンツテーブル３００と同様である。優先度４０２は、例えばコンテンツの優先度を３段階で示す。図６では、３が最も高い優先度を示し、１が最も低い優先度を示す。

コンテンツ送信部２０６０は、第１予測部２０４０による予測結果に応じて、予め定められた所定値以上の優先度のコンテンツをオペレータ端末１０００へ送信する。例えば、３段階の優先度が設定されている場合、通常モードの場合の所定値を１、積滞モードの場合の所定値を３に設定する。この場合、積滞モードのコンテンツ送信部２０６０は優先度が３以上のコンテンツを送信し、通常モードのコンテンツ送信部２０６０は優先度が１以上のコンテンツ（全てのコンテンツ）を送信する。

このようにコンテンツに対して段階的な優先度を設ける場合、第１予測部２０４０による予測結果ごとに、どの優先度以上のコンテンツを送信するのかを表す上記所定値を定めておく必要がある。例えばこの所定値は、応対支援装置２０００の管理者等が手動で定める。

また、このように複数段階の優先度を用いる場合、コンテンツ送信部２０６０が送信するコンテンツの量は、呼の積帯の有無だけではなく、呼の積帯の程度によって異なってもよい。積滞の程度は、所定時間後に積滞する呼の数の予測値などによって定まる。例えば積滞の程度を、１）所定時間後の積滞数が０である（積滞がない）、２）積滞数が０以上５以下である、及び３）積滞数が５以上であるという３つの程度に分類する。

この場合、コンテンツ送信部２０６０は、通常モードと積滞モードという２つの状態ではなく、予測された積滞の程度ごとに異なる状態をとる。例えば、コンテンツ送信部２０６０は、予測された積滞の程度が１）の場合、２）の場合、３）の場合それぞれで、第１のモード、第２のモード、第３のモードに遷移する。そして、第１のモードのコンテンツ送信部２０６０は優先度１以上のコンテンツ（全てのコンテンツ）を送信し、第２のモードのコンテンツ送信部２０６０は優先度２以上のコンテンツを送信し、第３のモードのコンテンツ送信部２０６０は優先度３以上のコンテンツを送信する。このようにすることで、オペレータ端末１０００が取得するコンテンツの量をより細かく調整することができる。

＜コンテンツの利用方法＞
コンテンツの利用方法を具体的に説明する。ここで、図５や図６に示されているコンテンツテーブルはアイスケースの故障に関するコンテンツのみを示しているが、実際のコンテンツテーブルは、その他にも様々なコンテンツを含んでいる。オペレータは、顧客からの問い合わせを受けてオペレータ端末１０００を操作し、必要なコンテンツの送信をコンテンツ送信部２０６０へ依頼する。コンテンツ送信部２０６０は、オペレータ端末１０００からの依頼に合致するコンテンツであり、かつ第１予測部２０４０に予測結果に応じて特定されるコンテンツを、オペレータ端末１０００へ送信する。

例えば「アイスケースが正常に動作しない」という問い合わせを受けたオペレータは、オペレータ端末１０００を操作して、アイスケースの故障に関するコンテンツの送信を応対支援装置２０００へ依頼する。例えばオペレータ端末１０００は、表示画面上に、コンテンツを閲覧するための Web ページを表示する。オペレータは、必要なコンテンツを取得するためにリンクをクリックしていく。そして、リンクをクリックした結果として、そのリンクに対応するコンテンツの送信を要求するリクエストが、応対支援装置２０００へ送信される。コンテンツ送信部２０６０は、このリクエストへの応答としてコンテンツを送信する。

図７は、図５に示すコンテンツテーブル３００からコンテンツを取得したオペレータ端末１０００によって表示される画面を例示する図である。具体的には、この画面には、「アイスケースが作動しない」という問い合わせを顧客から受けた場合にオペレータがすべき応対が表示されている。図７（ａ）は通常時コンテンツが表示されている画面を表し、図７（ｂ）は積滞時コンテンツが表示されている画面を表す。

図７（ａ）に示す画面に従って応対する場合、オペレータはまず顧客に対して１）エラーと温度の確認、２）運転スイッチの確認、及び３）動力分電盤のブレーカーの確認を順に促す。１）から３）のいずれかを顧客が行った結果、問題が解決すれば、電話応対は終了する。一方、１）から３）を行っても問題が解決しない場合、オペレータは、４）保守依頼情報の聞き出しを行う。４）を終えたオペレータは、５）保守パートナーへの依頼を行う。ここで、５）は顧客に対する電話応対を終えた後に行われる事後処理であり、アイスケースの保守を担当する会社等へ修理等を依頼する処理である。

一方、図７（ｂ）に示す画面に従って行動する場合、オペレータは、上述の３）を行わない。オペレータは、上述の１）と２）を行っても問題が解決しない場合、４）を行って電話応対を終了する。よって、積滞時コンテンツを利用する場合、３）が省略された分だけ電話応対にかかる時間が短くなる。このように応対にかかる時間を短くすることで、呼の積滞の発生を防ぐことができる。

［実施形態２］
図８は、実施形態２に係る応対支援装置２０００をその使用環境と共に例示するブロック図である。図８において、矢印は情報の流れを表している。さらに、図８において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。以下で説明する点を除き、実施形態２の応対支援装置２０００が有する機能は、実施形態１の応対支援装置２０００が有する機能と同様である。

実施形態２の応対支援装置２０００は、第２予測部２０８０をさらに有する。第２予測部２０８０は、積滞数及び応対予測時間に基づいて、応対条件が満たされるか否かを判定する。応対条件は、ある呼の着信があってからその呼への応対が開始されるまでに許容される時間（以下、許容待ち時間）に関する条件を含む。例えば応対条件は、SLA（Service Level Agreement）によって定まる。そして、実施形態２の第１予測部２０４０は、第２予測部２０８０によって応対条件を満たすことができると予測された場合に動作する。

例えば応対条件が「許容待ち時間≦３０秒」であるとする。この場合、ある呼の着信があってから３０秒以内にその呼への応対を開始しなければ、応対条件が満たされない。ここで、第２予測部２０８０が予測を行う際に、ある呼の着信があってから５秒経過しているとする。この場合、第２予測部２０８０は、２５秒以内にいずれかのオペレータがその呼に対する応対を開始できるか否かを予測する。そして、２５秒以内にいずれかのオペレータがその呼に対する応対を開始できると予測した場合、第２予測部２０８０は、応対条件が満たされると判定する。一方、２５秒以内にどのオペレータもその呼に対して応対できないと予測した場合、第２予測部２０８０は、応対条件が満たされないと判定する。なお、待ち状態の呼に対する応対を決められた時間内に開始できるか否かを予測する方法は、実施形態１の第１予測部２０４０に関する説明において既に述べたため、ここでは省略する。

＜応対条件に含まれるその他の条件＞
応対条件は、許容待ち時間以外の条件をさらに含んでいてもよい。例えば応対条件は、許容待ち率を含む。許容待ち率は、「どの程度の数の呼について許容待ち時間以内に応対を開始すればよいか」を表す。例えば許容待ち率が８０％である場合、応対条件を満たすためには、全体の呼の８０％以上に対し、許容待ち時間以内に応対を開始しなければならない。言い換えると、許容待ち時間以内に応対を開始できない呼の数が全体の２０％未満であれば、応対条件が満たされる。

＜応対条件の取得方法＞
第２予測部２０８０は、応対支援装置２０００の内部又は外部の記憶部に記憶されている応対条件を取得する。この記憶部は、例えば応対支援装置２０００の管理者等によって手動で入力された応対条件を記憶している。ここで、手動で応対条件を入力する方法は、例えばキー入力やファイル入力などである。

＜処理の流れ＞
図９は、実施形態２の応対支援装置２０００によって実行される処理の流れを例示するフローチャートである。図９において、図２に同じ符号のステップがあるステップは、図２の同符号のステップと同様の処理を表す。そのため、図２に同符号のステップがあるステップについての説明は省略する。

ステップＳ２０２において、第２予測部２０８０は、積滞数及び応対予測時間に基づいて、応対条件を満たすことができるか否かを予測する。応対条件が満たされると予測された場合、図９の処理はステップＳ２０４からＳ１０４に進む。

一方、応対条件が満たされないと予測された場合、図９の処理はステップＳ２０４からＳ２０６に進む。ステップＳ２０６において、コンテンツ送信部２０６０は、ステップＳ１１０で送信するコンテンツよりも少ない量のコンテンツを送信する。

ここで図９において、応対条件が満たされないと予測された場合に送信されるコンテンツの量は、応対条件が満たされると予測された場合に送信されるコンテンツの量より少なくなっている。応対条件が満たされない場合とは、例えば SLA を満たせない場合であり、契約上の問題などが生じうる。そのため、応対条件が満たされないと予測された場合、応対に要する時間をできる限り短くすることが好ましい。

そこで図９では、コンテンツ送信部２０６０が送信するコンテンツの量が少ない順に、１）応対条件が満たせないと予測されたとき、２）応対条件が満たされると予測されたものの所定時間後に呼の積帯があると予測されたとき、３）応対条件が満たされると予測され、かつ所定時間後に呼の積帯がないと予測されたとき、となっている。しかし、２）の場合に（ステップＳ１０８で）コンテンツ送信部２０６０が送信するコンテンツの量と、３）の場合に（ステップＳ２０６で）コンテンツ送信部２０６０が送信するコンテンツの量は、同じであってもよい。

＜作用・効果＞
本実施形態の応対支援装置２０００によれば、所定時間後に呼の積滞があるか否かに加え、応対条件（SLA など）が満たされるか否かがさらに予測され、その予測結果に応じた量のコンテンツがオペレータ端末１０００によって取得される。そのため発生している呼の状態がより詳細に把握され、その把握結果に応じた量のコンテンツをオペレータ端末１０００が取得できるようになる。よって、応対を待つ顧客の待ち時間をより適切に短くすることができる。

＜変形例＞
コンテンツ送信部２０６０が送信するコンテンツの量を決定する方法は、上述の方法に限定されない。例えば応対支援装置２０００は、第１予測部２０４０を利用せず、第２予測部２０８０による予測結果に応じてコンテンツ送信部２０６０が送信するコンテンツの量を異ならせてもよい。

図１０は、実施形態２の変形例の応対支援装置２０００によって実行される処理の流れを例示するフローチャートである。積滞数取得部２０２０は、呼の積滞数を取得する（Ｓ３０２）。第２予測部２０８０は、積滞数と応対条件とに基づいて、応対条件を満たせるか否かを予測する（Ｓ３０４）。第２予測部２０８０によって応対条件が満たされると予測された場合（ステップＳ３０６：ＹＥＳ）、図１０の処理はステップＳ３０８に進む。ステップＳ３０８において、コンテンツ送信部２０６０は、コンテンツを送信する。一方、第２予測部２０８０によって応対条件が満たされないと予測された場合（ステップＳ３０６：ＮＯ）、図１０の処理はステップＳ３１０に進む。ステップＳ３１０において、コンテンツ送信部２０６０は、Ｓ３０８で送信するコンテンツよりも少ない量のコンテンツを取得する。

［実施形態３］
図１１は、実施形態３に係る応対支援装置２０００をその使用環境と共に例示するブロック図である。図１１において、矢印は情報の流れを表している。さらに、図１１において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。なお、以下で説明する点を除き、実施形態３の応対支援装置２０００が有する機能は、実施形態２の応対支援装置２０００が有する機能と同様である。

実施形態３の応対支援装置２０００は表示部２１００を有する。表示部２１００は、以下の３つのケースそれぞれにおいて、異なる表示を行う。第１のケースは、第２予測部２０８０によって応対条件が満たされないと予測されたケースである。第２のケースは、第１予測部２０４０によって呼の積滞があると予測されたケースである。第３のケースは、第１予測部２０４０によって呼の積滞がないと予測されたケースである。なお、実施形態２で説明した通り、第１予測部２０４０が動作するケース（第２及び第３のケース）では、前提として、第２予測部２０８０によって応対条件が満たされると予測されている。

例えば表示部２１００は、パトランプである。例えばこのパトランプは、第１のケースで赤色のランプを点灯し、第２のケースで黄色のランプを点灯し、第３のケースで青色のランプを点灯する。ただし、表示部２１００は上記第１のケースから第３のケースのそれぞれを区別できるような表示ができればよく、表示部２１００はパトランプに限定されない。例えば表示部２１００は、第１のケースから第３のケースそれぞれで異なるメッセージを表示する表示画面であってもよい。

＜処理の流れ＞
図１２は、実施形態３の応対支援装置２０００によって実行される処理の流れを例示するフローチャートである。図１２のフローチャートは、ステップＳ２０６の代わりにステップＳ４０２、ステップＳ１１０の代わりにＳ４０４、及びステップＳ１０８の代わりにステップＳ４０４をそれぞれ有する点を除き、図９に示すフローチャートと同様である。ステップＳ４０２において、表示部２１００は第１の表示を行う。ステップＳ４０４において、表示部２１００は第２の表示を行う。ステップＳ４０４において、表示部２１００は第２の表示を行う。

＜作用・効果＞
本実施形態によれば、１）第２予測部２０８０によって応対条件が満たされないと予測された場合、２）第１予測部２０４０によって呼の積滞があると予測された場合、及び３）第１予測部２０４０によって呼の積滞がないと予測された場合のそれぞれについて異なる表示が行われる。そのため、オペレータ端末１０００を利用するオペレータが、呼の発生状況（コールセンタ等の混雑状況）を容易に把握できるようになる。その結果、オペレータは、呼の発生状況に応じた適切な処理を行えるようになる。

［実施形態４］
図１３は、実施形態４に係る応対支援装置２０００をその使用環境と共に例示するブロック図である。図１３において、矢印は情報の流れを表している。さらに、図１３において、各ブロックは、ハードウエア単位の構成ではなく、機能単位の構成を表している。なお、以下で説明する点を除き、実施形態４の応対支援装置２０００は、実施形態１から実施形態３のいずれかと同様の機能を有する。

実施形態４の応対支援装置２０００は通知部２１２０を有する。通知部２１２０は、第１予測部２０４０によって呼の積滞があると予測された後にオペレータが着呼に応対した場合、そのオペレータが着呼に応対していないときにオペレータ端末１０００へ通知を行う。

具体例を用いて、本実施形態の応対支援装置２０００の利用方法を説明する。コールセンタなどで顧客等に応対する一連の処理は、例えば１）電話応対、２）事後処理、３）アクションに分類できる。電話応対は、顧客に対して電話で応対する処理である。事後処理は、電話応対の後、その電話応対に関する情報（顧客に関する情報、顧客から受けた問い合わせの内容、及びそれに対してどのように応対したかなど）を記録する処理である。アクションは、電話応対では顧客の問題が解決できなかった場合に、顧客の問題を解決するために行う処理である。例えば実施形態１の図７の例では、顧客との電話応対で保守依頼情報を聞き出して電話応対を終了した後、保守パートナーへ連絡をして修理の依頼をする。この修理が行われなければ顧客の問題は解決しないため、オペレータは修理の依頼を行う必要がある。なお、電話応対で問題が解消した場合など、アクションが発生しない場合もある。

ここで、修理を早急に依頼しなくても問題がない場合など、アクションを行うタイミングが事後処理の直後でなくてもよい場合がある。このような場合、例えばオペレータは、事後処理において後で行う必要があるアクションの内容を記録しておき、後でそのアクションを行ってもよい。そこで、コールセンタが混雑している場合、オペレータは、各呼についてアクションを後回しにして、より多くの呼に応対することが好ましい。こうすることで、呼の積滞が発生することを防ぐことができる。また、前述の応対条件が満たされる確率が高くなる。

しかし、オペレータは、後回しにしたアクションを後で忘れずに行う必要がある。そのため、応対支援装置２０００は、オペレータ端末１０００に対して通知を行うことで、オペレータがこの処理を忘れることを防止する。

具体的には、応対支援装置２０００は、第１予測部２０４０によって着呼の積帯があると予測された後にオペレータが呼へ応対した場合、オペレータが呼に応対していないときに通知を行う。これにより、オペレータが上述のアクションのような処理を後回しにした場合であっても、そのオペレータの手が空いた時に通知が行われる。その結果、オペレータがアクションのような処理を忘れることを防ぐことができる。なお、オペレータが行う処理の分類は、上述の１）から３）の分類に限定されない。

図１４を使って、実施形態４の利用方法をより具体的に説明する。図１４は、積滞が発生すると予測された場合における呼への応対の流れを概念的に例示する図である。ここで、オペレータ端末１０００の利用者として、２人のオペレータと１人のサブリーダがいる。サブリーダは、通常時は電話応対を行わず、オペレータでは対処しきれない問い合わせが発生した場合や緊急時などに応対を行う者である。

図１４において、積滞が発生すると予測されてからオペレータの手が空くまでは、アクションが後回しにされている。そして、オペレータの手が空いたら、通知部２１２０が各オペレータに対して通知を行う。通知を受けたオペレータは、後回しにしていた各アクションを行う。

図１４の例ではさらに、後回しにされてからしばらく時間が経過しても処理が開始されてないアクションがある場合、応対支援装置２０００はサブリーダのオペレータ端末１０００に対して通知を行う。この場合、サブリーダがオペレータに代わってこのアクションを行う。図１４において、サブリーダは、アクション２の処理をオペレータ２に代わって行っている。

本実施形態の応対支援装置２０００の具体的な実現方法は、例えば次のようになる。まず第１予測部２０４０は、積滞モードの応対支援装置２０００は、オペレータ端末１０００へ接続した呼の呼ＩＤを記録する。ただしこの記録は、通常モードにおいても行われてよい。

通知部２１２０は、オペレータの手が空いた時、積滞モードの間に記録した呼ＩＤをオペレータへ通知する。ここで、「オペレータの手が空いた時」は、例えば積滞モードが終了して通常モードに遷移した後に、そのオペレータのオペレータ端末１０００へ接続される呼が無くなった時である。

＜作用・効果＞
本実施形態によれば、「呼の積滞があると予測された場合にオペレータが一部の処理を後回しにする」といった運用が行われる場合に、後回しにした処理をオペレータが忘れることを防ぐことができる。

以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、上記以外の様々な構成を採用することもできる。

例えば上述の各実施形態では、第１予測部２０４０や第２予測部２０８０による予測の結果に基づいてコンテンツを特定する機能は、応対支援装置２０００（コンテンツ送信部２０６０）に設けられている。しかし、この機能はオペレータ端末１０００に設けられてもよい。

この場合、第１予測部２０４０は、所定時間後における呼の積滞の有無の予測結果を、オペレータ端末１０００へ送信する。オペレータ端末１０００は、第１予測部２０４０によって所定時間後に呼が積滞すると予測された場合、積滞モードに遷移する。一方、オペレータ端末１０００は、第１予測部２０４０によって所定時間後に呼が積滞しないと予測された場合、通常モードに遷移する。そして、積滞モードのオペレータ端末１０００は積滞コンテンツの送信をコンテンツ送信部２０６０へ依頼し、通常モードのオペレータ端末１０００は通常コンテンツの送信をコンテンツ送信部２０６０へ依頼する。コンテンツ送信部２０６０は、オペレータ端末１０００からの依頼に合致するコンテンツをオペレータ端末１０００へ送信する。

同様に、第２予測部２０８０は、応対条件が満たされるか否かの予測結果を、オペレータ端末１０００へ送信する。オペレータ端末１０００は、第１予測部２０４０による予測結果及び第２予測部２０８０による予測結果に基づいて取得するコンテンツを特定し、そのコンテンツの送信をコンテンツ送信部２０６０へ依頼する。

また、実施形態４の応対支援装置２０００が持つ通知部２１２０の機能は、オペレータ端末１０００に設けられてもよい。この場合、例えばオペレータ端末１０００は、上述のように、第１予測部２０４０による予測結果に応じて通常モード又は積滞モードに遷移する。そして、オペレータ端末１０００は、その状態に応じて、実施形態４で説明した通知部２１２０と同様の処理を行う。

また、コンテンツ送信部２０６０は、呼の積帯以外に基づいて送信するコンテンツを異ならせてもよい。以下に、代表的な例を記載する。

例えばコンテンツ送信部２０６０は、天気に応じたコンテンツを送信する。この場合、コンテンツ記憶部４０４０は、コンテンツを、そのコンテンツを取得する場合の天気と対応付けて記憶する。そしてコンテンツ送信部２０６０は、天気に関する情報を取得し、取得した情報に示される天気と対応付けられているコンテンツを送信する。例えば天気に関する情報は、天気予報を提供するサーバ等から取得できる。

また例えばコンテンツ送信部２０６０は、停電時と通常時で異なるコンテンツを送信してもよい。この場合、コンテンツ記憶部４０４０は、コンテンツを、停電時にそのコンテンツを取得するか否かを示す情報、及び通常時にそのコンテンツを取得するか否かを示す情報と対応付けて記憶する。そしてコンテンツ送信部２０６０は、応対の対象となる製品等（例えば図５におけるアイスケース）が設置されている場所が停電しているか否かの情報を取得し、その情報に基づいてオペレータ端末１０００へ送信するコンテンツを特定する。

なお、製品等が設置されている場所が停電しているか否かの情報は、例えば顧客からその情報を聞き出したオペレータによって、オペレータ端末１０００に対して手動で入力され、その情報が応対支援装置２０００へ送信される。また例えば、コンテンツ送信部２０６０が、オペレータ端末１０００へ接続された呼の電話番号を用いて、その電話番号から特定される地域が停電しているか否かの情報を取得してもよい。

また例えばコンテンツ送信部２０６０は、問い合わせ対象の製品の使用電力量に応じたコンテンツを取得してもよい。例えば、定期的な清掃を要する製品（アイスケースなど）の場合、清掃が行われていない場合の消費電力が、清掃が行われている場合の消費電力より大きくなる場合がある。また、清掃が行われていないことが原因で製品が異常な状態になることがあり、その異常について顧客から問い合わせがある場合がある。このような場合、オペレータは、製品の清掃を顧客に提案するという応対を行う。

そこでコンテンツ送信部２０６０は、オペレータ端末１０００が製品に関する問い合わせを受けた場合に、対象の製品の消費電力を取得する。次にコンテンツ送信部２０６０は、取得した製品の消費電力に基づき、その製品の清掃が行われているか否かを判定する。そして、コンテンツ送信部２０６０は、その製品の清掃が行われていないと判定した場合、その製品の清掃を提案するという内容を含むコンテンツを送信する。

なお、製品の消費電力に関する情報は、例えば顧客から情報を聞き出したオペレータによってオペレータ端末１０００に入力され、応対支援装置２０００へ送信される。また例えば、コンテンツ送信部２０６０は、顧客の製品に設けられている電力測定器などから、ネットワークなどを介して消費電力を取得してもよい。

なお、製品の清掃がされているか否かの判定などに用いる消費電力の閾値は、予め応対支援装置２０００の内部又は外部に設けられている記憶部に記憶しておく。コンテンツ送信部２０６０は、この記憶部から上記閾値を取得する。

この出願は、２０１４年９月２６日に出願された日本出願特願２０１４−１９６５３７号を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１． 呼の積滞数を取得する積滞数取得手段と、
オペレータが呼の応対に要する時間の予測値を表す応対予測時間と前記積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する第１予測手段と、
前記第１予測手段による予測結果に基づいて、複数のコンテンツを記憶しているコンテンツ記憶手段から送信するコンテンツを特定し、特定したコンテンツを送信するコンテンツ送信手段と、
を有する応対支援装置。
２． 前記コンテンツ送信手段は、前記第１予測手段によって呼の積滞があると予測された場合、呼の積滞がないと予測された場合に取得する前記コンテンツよりも少ない量の前記コンテンツを送信する１．に記載の応対支援装置。
３． 前記積滞数及び前記応対予測時間に基づいて、呼への応対を開始するまでに許容される時間に関する条件を含む応対条件を満たすことができるか否かを予測する第２予測手段を有し、
前記第１予測手段は、前記第２予測手段によって前記応対条件を満たすことができると予測された場合に動作する、
１．又は２．に記載の応対支援装置。
４． 前記第２予測手段によって応対条件が満たされないと予測された場合、前記第１予測手段によって呼の積滞があると予測された場合、及び前記第１予測手段によって呼の積滞がないと予測された場合において、それぞれ異なる表示を行う表示手段を有する３．に記載の応対支援装置。
５． 呼の積滞があると予測された後にオペレータが呼に応対した場合に、そのオペレータが呼に応対していないときに通知を行う通知手段を有する１．乃至４．いずれか一つに記載の応対支援装置。
６． コンピュータによって実行される制御方法であって、
呼の積滞数を取得する積滞数取得ステップと、
オペレータが呼の応対に要する時間の予測値を表す応対予測時間と前記積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する第１予測ステップと、
前記第１予測ステップによる予測結果に基づいて、複数のコンテンツを記憶しているコンテンツ記憶手段から送信するコンテンツを特定し、特定したコンテンツを送信するコンテンツ送信ステップと、
を有する制御方法。
７． 前記コンテンツ送信ステップは、前記第１予測ステップによって呼の積滞があると予測された場合、呼の積滞がないと予測された場合に取得する前記コンテンツよりも少ない量の前記コンテンツを送信する６．に記載の制御方法。
８． 前記積滞数及び前記応対予測時間に基づいて、呼への応対を開始するまでに許容される時間に関する条件を含む応対条件を満たすことができるか否かを予測する第２予測ステップを有し、
前記第１予測ステップは、前記第２予測ステップで前記応対条件を満たすことができると予測された場合に動作する、
６．又は７．に記載の制御方法。
９． 前記第２予測ステップで応対条件が満たされないと予測された場合、前記第１予測ステップで呼の積滞があると予測された場合、及び前記第１予測ステップで呼の積滞がないと予測された場合において、それぞれ異なる表示を行う表示ステップを有する８．に記載の制御方法。
１０． 呼の積滞があると予測された後にオペレータが呼に応対した場合に、そのオペレータが呼に応対していないときに通知を行う通知ステップを有する６．乃至９．いずれか一つに記載の制御方法。
１１． コンピュータを、１．乃至５．いずれか一つに記載の応対支援装置として動作させるプログラム。

Claims (9)

1. 呼の積滞数を取得する積滞数取得手段と、
   オペレータが呼の応対に要する時間の予測値を表す応対予測時間と前記積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する第１予測手段と、
   前記第１予測手段による予測結果に基づいて、複数のコンテンツを記憶しているコンテンツ記憶手段から送信するコンテンツを特定し、オペレータが利用する端末へ前記特定したコンテンツを送信するコンテンツ送信手段と、
   を有し、
   各前記コンテンツは、オペレータが呼の応対に用いる情報を含み、
   前記コンテンツ送信手段は、前記第１予測手段によって呼の積滞があると予測された場合、呼の積滞がないと予測された場合に取得する前記コンテンツよりも少ない量の前記コンテンツを送信する、応対支援装置。
2. 前記積滞数及び前記応対予測時間に基づいて、呼への応対を開始するまでに許容される時間に関する条件を含む応対条件を満たすことができるか否かを予測する第２予測手段を有し、
   前記第１予測手段は、前記第２予測手段によって前記応対条件を満たすことができると予測された場合に動作する、
   請求項１に記載の応対支援装置。
3. 前記第２予測手段によって応対条件が満たされないと予測された場合、前記第１予測手段によって呼の積滞があると予測された場合、及び前記第１予測手段によって呼の積滞がないと予測された場合において、それぞれ異なる表示を行う表示手段を有する請求項２に記載の応対支援装置。
4. 呼の積滞があると予測された後にオペレータが呼に応対した場合に、そのオペレータが呼に応対していないときに通知を行う通知手段を有する請求項１乃至３いずれか一項に記載の応対支援装置。
5. コンピュータによって実行される制御方法であって、
   呼の積滞数を取得する積滞数取得ステップと、
   オペレータが呼の応対に要する時間の予測値を表す応対予測時間と前記積滞数とに基づいて、所定時間後における呼の積滞の有無を予測する第１予測ステップと、
   前記第１予測ステップによる予測結果に基づいて、複数のコンテンツを記憶しているコンテンツ記憶手段から送信するコンテンツを特定し、オペレータが利用する端末へ前記特定したコンテンツを送信するコンテンツ送信ステップと、
   を有し、
   各前記コンテンツは、オペレータが呼の応対に用いる情報を含み、
   前記コンテンツ送信ステップは、前記第１予測ステップによって呼の積滞があると予測された場合、呼の積滞がないと予測された場合に取得する前記コンテンツよりも少ない量の前記コンテンツを送信する、制御方法。
6. 前記積滞数及び前記応対予測時間に基づいて、呼への応対を開始するまでに許容される時間に関する条件を含む応対条件を満たすことができるか否かを予測する第２予測ステップを有し、
   前記第１予測ステップは、前記第２予測ステップで前記応対条件を満たすことができると予測された場合に動作する、
   請求項５に記載の制御方法。
7. 前記第２予測ステップで応対条件が満たされないと予測された場合、前記第１予測ステップで呼の積滞があると予測された場合、及び前記第１予測ステップで呼の積滞がないと予測された場合において、それぞれ異なる表示を行う表示ステップを有する請求項６に記載の制御方法。
8. 呼の積滞があると予測された後にオペレータが呼に応対した場合に、そのオペレータが呼に応対していないときに通知を行う通知ステップを有する請求項５乃至７いずれか一項に記載の制御方法。
9. コンピュータを、請求項１乃至４いずれか一項に記載の応対支援装置として動作させるプログラム。

Images