JPH09252351A - 発呼制御方法 - Google Patents

Abstract

(57)【要約】 【課題】 アウトバウンド業務システムにてオペレータ
効率向上と接続された被呼者の待ちの改善とを両立可能
な発呼制御方法を提供すること。 【解決手段】 交換機と、該交換機に接続された複数の
電話機と、該交換機に接続されたホストコンピュータ
と、該ホストコンピュータに接続された複数のオペレー
タ端末とを備え、端末ではアウトバウンド業務のための
プログラムが実行され、ホストコンピュータは各オペレ
ータの一人の被呼者に対する通話の終了を予測し該通話
の終了に先だって被呼者リストに従い自動発呼を行い、
応答のあった呼を空き状態となったオペレータに対応す
る電話機に接続するシステムにおける発呼制御方法であ
って、オペレータ端末上のプログラムの特定箇所が実行
されたことを検出して通話の終了を事前に検知し、通話
終了が事前検知されたオペレータ数に基づいて、自動発
呼する呼数を決定することを特徴とする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電話とコンピュー
タとを接続してアウトバウンド業務を行うコールセンタ
ーにおける発呼制御方法に関する。

【０００２】

【従来の技術】近年、電話を用いて販売活動を行うテレ
マーケティングが関心を集めている。テレマーケティン
グを行うために、顧客のリストを計算機上に持ち、多数
のオペレータが顧客のリストを見ながら電話をかけて行
くシステムはコールセンターと呼ばれ、例えば図１７の
ような形態をとる。図１７において、ホストコンピュー
タ３０１は、コールリスト３０２を保持しており、オペ
レータ３０３の端末３０４には、このコールリスト３０
２が表示される。オペレータ３０３は電話機３０５を用
いてコールリストの顧客に電話をかけ、テレマーケティ
ングを行う。ホストコンピュータとＰＢＸが連動してい
るシステムでは、端末３０４からの指示によりＰＢＸ３
０６経由で自動的に電話が発信され、電話機３０５に接
続されるものもある。

【０００３】テレマーケティングでは、個々の顧客に対
して直接電話により会話を行い、顧客の反応を確かめな
がら商品の案内や勧誘を行うことが低コストでできる。
しかし、大規模なシステムにおいては、多数のオペレー
タと多数の電話回線を必要とし、一定時間にできるだけ
多くの顧客と会話を行うためには、電話の発呼をより効
率良く制御する方法が望まれている。

【０００４】コールセンターの業務の中で、センタ側か
ら顧客を呼び出す業務を一般にアウトバウンド業務と呼
ぶ。例えば、有望な顧客をリストアップしておき電話で
注文をとる販売活動や選挙のときに有権者に投票しよう
と考えている候補を尋ねることにより当選者を予測する
アンケート調査などがアウトバウンド業務である。

【０００５】アウトバウンド業務では、多数の顧客（あ
るいは有権者等）に対して電話をかける必要があるた
め、できるだけオペレータを効率良く活用する方式が望
ましい。

【０００６】従来のある種のテレマーケティングシステ
ムにおいては、各オペレータが個別に顧客リストを与え
られ、これに基づいて電話を手動で操作していた。この
ため、顧客の不在時や通話中の場合はオペレータが待つ
必要があり、これによるオペレータの効率の低下が問題
となっている。

【０００７】このため、コンピュータを用いて自動発呼
を行う方式が提案されている。より優れた方式として、
回線の状態をホストコンピュータが監視して、オペレー
タと顧客の会話が終了したことを検知して、その時点で
ホストコンピュータがコールリストから適切な顧客を選
択し自動的にダイヤルする、というものが考えられる。
この方式をパワーダイヤリングと呼ぶ。この方式では、
前述の方式に比較してオペレータのダイヤル作業が機械
化されるため、効率が向上する。しかしながら、この方
式においても電話をかけてからそれがつながって相手が
出るまでオペレータが遊んでしまう、という問題点が存
在する。

【０００８】すなわち、ダイヤルした通話は顧客に直ち
に継るわけではない。まず、公衆網上で回線をつなげる
作業（これをセットアップ作業、これに要する時間をセ
ットアップ時間と夫々呼ぶ）がある。さらに、回線が継
っても顧客が話中の場合、通話を切って別の顧客に新た
にかけ直さなければならない。また、顧客が話中ではな
く呼出音が鳴ったとしても、顧客が応答するまではある
程度の時間がかかる（これを呼び出し時間と呼ぶ）。ま
た、呼び出しが始まってから十分時間が経っても応答が
ない場合、顧客が不在であると判断し通話を切って別の
顧客に新たにかけ直さなければならない。これら時間は
全てオペレータの遊び時間として計上される。従って、
状況にも依存するが、パワーダイヤリングでは十分な効
率を得られない場合が多い。

【０００９】これらはオペレータの顧客との会話時間の
終了以前に別の回線を用いて次の顧客の発呼を行い、顧
客の不在や通話中を自動的に判断し、通話がつながった
顧客をオペレータに割り振ることによりオペレータの効
率向上を目指している。これは、プレディクティブダイ
アリングと呼ばれている。プレディクティブダイアリン
グの詳細は、例えば、ＵＳＰ ４，８２９，５６３、
ＵＳＰ ５，３２７，４９１に開示されている。

【００１０】遊び時間を少なくするためにはオペレータ
と顧客の通話が終了するタイミングにちょうど次に通話
が継るように予測して前もってダイヤルしておく必要が
ある。この際、顧客の何％かが不在、または話し中であ
ることを見越してオペレータ数より多くの発信を行う。
これをプレディクティブ・ダイヤリングと呼ぶ。

【００１１】ただし、予測が当たるか当たらないかはあ
くまでも確立の問題であるから、通話がつながって顧客
が応答したものの、対応できるオペレータがいないため
顧客を電話口で待たせるという事態が発生する可能生が
ある。この場合、テープに録音されたメッセージや音楽
を流す、などの緊急的対策はあるものの、こちらから一
方的に電話をかけておいて、出て見るとテープからのメ
ッセージが流れてきたのでは、顧客の感情を害する恐れ
があり、ビジネスにとっては逆効果になりかねない。一
般に予測はセットアップ時間、呼び出し時間、会話時間
（オペレータが一人の顧客との通話に要する時間）など
を考慮して行われるが、これらが確定した値でないた
め、予測のずれが発生するのである。また、顧客が話中
であるか、不在であるかなども事前に予測できないため
予測のはずれの原因になる。プレディクティブ・ダイヤ
リングをする以上、この可能性を０にすることはできな
いが、待ちの発生をできるだけ少なく、また待ち時間を
できるだけ短くする必要がある。

【００１２】しかしながら、従来のプレディクティブダ
イアリングでは、オペレータの会話時間が不確定である
ため、平均会話時間等を用いて会話の終了を予測してい
た。このため、ある通話が平均より大幅に長い場合には
通話の終了を予測していたコールに対して、空いている
オペレータがいないために顧客側の待ちが生じることが
あり、また待ちをなくそうとするとオペレータの効率が
低下するという問題が生じている。

【００１３】パワーダイヤリングの場合は、セットアッ
プ時間は直接オペレータの遊び時間に加算されるし、顧
客が話し中であるためのかけ直しもオペレータの遊び時
間の大きな原因である。また、プレディクティブ・ダイ
ヤリングの場合は、セットアップ時間が不確定であるこ
とと、顧客が話中であることのために、起動した通話に
対していつ応答があるかの予測の不確定性が増し、オペ
レータの遊び、または顧客の待ち時間の原因になる。

【００１４】ところで、今後、携帯電話などが普及して
くると、不在率は低くなり呼び出し時間は短くなる反面
セットアップ時間は長くなると予想され、セットアップ
時間がオペレータの利用効率を上げる上での最大の障害
となると考えられる。

【００１５】このように、セットアップ時間や話し中率
を実質的に小さくすることができれば、上記の各方式の
持つ問題を改善することが可能になり、オペレータの利
用効率を向上させることができる。

【００１６】テレマーケティングにおいて、顧客が不在
であったり話し中の場合は、一旦電話を切ってその後改
めて、それらの顧客に電話をかけ直す必要がある。特に
顧客が不在の場合、オペレータは不在を判定するため
に、一定時間電話の呼出音を聞き続ける必要があり、テ
レマーケティングの効率面での大きな障害となってい
た。

【００１７】また、前述のパワーダイヤリング方式やプ
レディクティブダイアリング方式を採用したコールセン
ターでは、ホストコンピュータ３０１の方で自動発信を
行い、顧客の応答した回線を空きオペレータの電話機３
０５に接続することになるが、これらの場合にも、顧客
の不在や話し中はテレマーケティングの効率面での大き
な問題となっていた。

【００１８】

【発明が解決しようとする課題】

（１）従来のテレマーケティングシステムなどアウトバ
ウンド業務を行うためのコールセンターで自動発呼を行
うプレディクティブダイヤリング方式では、オペレータ
の会話終了を高精度に予測することが困難であるため、
オペレータの効率向上と、接続されたコールに対する顧
客の待ちの発生を少なくすること（あるいは発生した待
ちの時間を短くすること）を両立させることが困難であ
った。

【００１９】本発明は、上記事情を考慮してなされたも
ので、アウトバウンド業務処理システムにおいて、オペ
レータ効率向上と、接続されたコールに対する顧客の待
ちの改善とを両立させることを可能とした発呼制御方法
を提供することを目的とする。

【００２０】（２）従来のアウトバウンド業務を行うた
めのコールセンターで自動発呼を行うパワーダイヤリン
グ方式では、セットアップ時間は直接オペレータの遊び
時間に加算され、顧客が話し中であるためのかけ直しも
オペレータの遊び時間を増加させるので、十分にオペレ
ータ効率向上を図ることが困難であった。

【００２１】本発明は、上記事情を考慮してなされたも
ので、アウトバウンド業務処理システムにおいて、セッ
トアップ時間と話し中率を実質的に小さくすることによ
りオペレータ効率を向上させた発呼制御方法を提供する
ことを目的とする。

【００２２】また、従来のアウトバウンド業務を行うた
めのコールセンターで自動発呼を行うプレディクティブ
ダイヤリング方式では、セットアップ時間や顧客の話し
中率を高精度に予測することが困難であるため、オペレ
ータ効率向上と、接続されたコールに対する顧客の待ち
の発生を少なくすること（あるいは発生した待ちの時間
を短くすること）とを両立させることが困難であった。

【００２３】本発明は、上記事情を考慮してなされたも
ので、アウトバウンド業務処理システムにおいて、セッ
トアップ時間と話し中率を実質的に小さくすることによ
り、オペレータ効率向上と、接続されたコールに対する
顧客の待ちの改善を両立させることを可能とした発呼制
御方法を提供することを目的とする。

【００２４】（３）従来のアウトバウンド業務を行うた
めのコールセンターで自動または手動で発呼を行う種々
の方式において、発呼した先の顧客が不在あるいは話し
中であると、オペレータの遊び時間が増加し、オペレー
タの効率が低下する問題点があった。

【００２５】本発明は、上記事情を考慮してなされたも
ので、アウトバウンド業務処理システムにおいて、不在
あるいは話し中の顧客に電話をかけることを回避するこ
とのできる発呼制御方法を提供することを目的とする。

【００２６】

【課題を解決するための手段】本発明（請求項１）は、
交換機と、該交換機に接続された複数の電話機と、該交
換機に接続されたホストコンピュータと、該ホストコン
ピュータに接続された複数のオペレータ端末とを備え、
オペレータ端末ではアウトバウンド業務のための端末プ
ログラムが実行され、前記ホストコンピュータは各オペ
レータの一人の被呼者に対する通話の終了を予測し該通
話の終了に先だって被呼者リスト（すなわちコールリス
ト）に従い自動発呼を行い、応答のあった呼を空き状態
となったオペレータに対応する電話機に接続するシステ
ムにおける発呼制御方法であって、前記オペレータ端末
上の端末プログラムの特定の箇所が実行されたことを検
出して前記通話の終了を事前に検知し、通話の終了が事
前に検知されたオペレータの数に基づいて、自動発呼す
る呼数を決定することを特徴とする。

【００２７】好ましくは、前記通話の終了の事前の検知
にあたっては、前記オペレータ端末に特定の操作が施さ
れたときに実行されるべき端末プログラムの特定の箇所
が実行されたことを検知することを特徴とする。

【００２８】プログラムの特定の箇所は、例えば、会話
終了に先だって必ず実行される部分とするのが好まし
い。本発明によれば、オペレータが通話業務を行ってい
る端末において、端末上のプログラムがある特定の箇所
を実行したことを検知し、その時点からのオペレータの
会話終了時間をより高精度に予測することができ、これ
により自動発呼する数を精度良く算出することができる
ので、より正確なプレディクティブダイアリングを実現
することができる。すなわち、接続されたコールに対す
る被呼者（すなわち顧客）の待ちの発生を少なくしつ
つ、あるいは発生した待ちの時間を短くしつつ、オペレ
ータ効率向上を図ることができる。

【００２９】本発明（請求項３）は、全オペレータ数を
越える数の回線を収容する交換機と、該交換機に接続さ
れた複数の電話機と、該交換機に接続されたホストコン
ピュータと、該ホストコンピュータに接続された複数の
オペレータ端末とを備え、前記ホストコンピュータは各
オペレータの一人の被呼者に対する通話の終了に応じ
て、自動発呼に応答した呼を空き状態となったオペレー
タに対応する電話機に接続するシステムにおける発呼制
御方法であって、被呼者の情報を登録した被呼者リスト
に従い発呼と切断を繰り返して、所定数のセットアップ
状態にある呼を保持し、呼び出し状態にある呼が前記電
話機に接続されもしくは一定時間経過後に切断されまた
は通話中状態にある呼が切断された場合、呼び出し状態
にある呼数と通話中状態にある呼数との和が、全オペレ
ータ数と同数になるように、前記セットアップ状態にあ
る呼を呼び出し状態にし、空き状態にあるオペレータを
登録したオペレータリストに従い、前記呼び出し状態に
した呼で一定時間内に被呼者から応答のあったものを、
空き状態にあるオペレータに対応する電話機に接続する
ことを特徴とする。

【００３０】本発明（請求項４）は、全オペレータ数を
越える数の回線を収容する交換機と、該交換機に接続さ
れた複数の電話機と、該交換機に接続されたホストコン
ピュータと、該ホストコンピュータに接続された複数の
オペレータ端末とを備え、前記ホストコンピュータは各
オペレータの一人の被呼者に対する通話の終了を予測し
該通話の終了に先だって被呼者リストに従い自動発呼を
行うとともに、待ち状態にある呼または自動発呼に応答
した呼を空き状態となったオペレータに対応する電話機
に接続しまたは自動発呼に応答した呼を待ち状態とする
システムにおける発呼制御方法であって、被呼者の情報
を登録した被呼者リストに従い発呼と切断を繰り返し
て、所定数のセットアップ状態にある呼を保持し、待ち
状態にある呼が前記電話機に接続されまたは呼び出し状
態にある呼が前記電話機に接続されもしくは一定時間経
過後に切断されまたは通話中状態にある呼が切断された
場合、呼び出し状態にある呼数と待ち状態にある呼数と
通話中状態にある呼数との和が、予め定められた待ちの
状態の呼の発生率の上限値をもとにして、予め収集した
統計情報に基づいた待ち行列モデルにより決定される、
全オペレータ数より大きい所定数と同数になるように、
前記セットアップ状態にある呼を呼び出し状態にし、空
き状態にあるオペレータを登録したオペレータリストに
従い、前記呼び出し状態にした呼で一定時間内に被呼者
から応答のあったものを、空き状態にあるオペレータに
対応する電話機に接続しまたは待ち状態とすることを特
徴とする。

【００３１】本発明（請求項３、４）によれば、所定数
の回線、例えば利用できる限りの回線に対してセットア
ップ状態にある通話を絶え間なく供給し続けるようにし
ている。そして、通話数の調整は接続イベント時に、前
述の基準に従って、そのセットアップ状態にある通話を
継続するか、そこで中断するかの判断だけ行う。これに
より、接続イベントの一歩手前にある通話を十分な数だ
け維持できるので、実質的なセットアップ時間をほとん
ど０に短縮できる。また、話中である被呼者（すなわち
顧客）は接続イベント時に取り除かれるが、本発明では
話中であるために除外される通話よりも十分に多い数の
他の通話がセットアップ状態に控えているため、話中で
あることによる問題点もほぼ回避することができる。

【００３２】このように本発明によれば、セットアップ
時間と話し中率を実質的に小さくすることにより、パワ
ーダイヤリングでは、オペレータ効率を向上させること
ができる。また、プレディクティブダイヤリングでは、
接続されたコールに対する顧客の待ちの発生を少なくし
つつ、あるいは発生した待ちの時間を短くしつつ、オペ
レータ効率向上を図ることができる。

【００３３】本発明（請求項５）は、交換機と、該交換
機に接続された複数の電話機と、該交換機に接続された
ホストコンピュータと、該ホストコンピュータに接続さ
れた複数のオペレータ端末とを備え、被呼者リストに従
って発呼を行い、応答のあった呼を該電話機に接続する
システムにおいて、発呼した被呼者が応答不能な状態
（例えば不在および／または話し中の状態）にあると判
断した場合、該システムから他のシステムに該被呼者の
不応答情報を通知し、前記不応答情報を受け取った前記
他のシステムは、該不応答情報が通知された前記被呼者
については、少なくとも一定時間経過するまで発呼しな
いよう制御することを特徴とする。

【００３４】本発明（請求項６）は、請求項５におい
て、一方のシステムが、応答不能な状態にあると判断さ
れた前記被呼者に発呼し、該被呼者が一定期間内に応答
した場合、該一方のシステムは、他方のシステムに該被
呼者が応答可能な状態（例えば在宅かつ話し中でない状
態）にあることを示す応答可能情報を通知することを特
徴とする。

【００３５】本発明によれば、複数のコールセンター間
で、被呼者（すなわち顧客）の不在・話し中の情報を互
いに通知し共有することにより、不在・話し中の被呼者
に電話をかけることを回避することができる。すなわ
ち、あるコールセンターである被呼者の不在・話し中を
検知した場合、その顧客が不在・話中である旨の情報を
他のコールセンターに伝えることにより、他のコールセ
ンターでは、その時点でその顧客に電話をかけても通話
が繋がらないことを予測でき、ある一定時間後にかける
ようにスケジュールし直すことが可能となる。これによ
って、オペレータ効率向上を図ることができる。

【００３６】

【発明の実施の形態】以下、図面を参照しながら発明の
実施の形態を説明する。本実施形態において、顧客と
は、アウトバウンド業務の対象者を意味し、マーケティ
ング等の対象となる消費者だけではなく、アンケート調
査における調査対象者など狭い意味での顧客でない者も
含むものとする。

【００３７】なお、本実施形態ではアウトバウンド業務
の一例としてはマーケティングを取り上げるが、本発明
は種々のアウトバウンド業務処理システムに適用可能で
ある。

【００３８】（実施形態１）図１に、本実施形態のコー
ルセンター・システム（アウトバウンド業務処理システ
ム）の基本構成を示す。

【００３９】図１のように、オペレータ一人あたり１台
の端末３０と電話機４０が設置され、各端末４０はホス
トコンピュータ２０に接続されている。また、各電話機
４０は交換機１０を経由して外線と接続される。交換機
１０はホストコンピュータ２０と接続されている。

【００４０】各オペレータは、接続された顧客と電話機
４０により必要な会話を行う。端末３０上では業務プロ
グラムが起動されており、例えば画面上に顧客ファイル
から読み出された該顧客に関する情報が表示され、また
必要な入力フィールドが提供される。オペレータにより
入力されたデータは、例えば図示しない顧客ファイルあ
るいは注文ファイルなどに格納される。オペレータが一
人の顧客に対する業務等を終え、端末３０に終了を入力
し、あるいは電話機４０を切ると、例えば端末３０が初
期画面になるとともに、電話機４０が次の顧客と接続さ
れる。

【００４１】図２に本コールセンター・システムのより
詳細な構成を示す。図２中では、端末３０は１台のみ示
し、電話機４０は省略してある。ホストコンピュータ２
０は、交換機１０から各発呼に対する結果が応答であっ
たか非応答であったかの情報を受け、発呼に対する応答
率を計測する応答計測部２１、通話起動された時刻と交
換機１０からセットアップ完了信号を受けた時刻から平
均セットアップ時間を計測するセットアップ時間計測部
２２、プレディクティブダイアリング・プログラム２
３、終了予測キュー２４を備えている。また、端末３０
は、終了予測信号を発生する終了予測信号発生部３１、
テレマーケティング業務に関する業務プログラム（端末
プログラム）３２を備えている。

【００４２】プレディクティブダイアリングは、ホスト
コンピュータ２０上のソフトウェア２３として実現され
る。各端末３０上では、テレマーケティング業務に関す
る業務プログラム３２が動作している。この業務プログ
ラム３２中の特定の箇所が実行されたときにホストコン
ピュータ２０に通知する機構として、終了予測信号発生
部３１を設定する。ホストコンピュータ２０上のプレデ
ィクティブダイアリングを行うプログラム２３では、こ
の終了予測信号発生部３１からの通知と、その通知が発
生した時刻とを記録し、これを反映してプレディクティ
ブダイアリングを行う。

【００４３】終了予測信号発生部３１は、例えば、以下
のように実現する。 （１）オペレータは通話を終了する場合に、端末３０に
対し例えば特定のキーを入力しあるいは画面上の特定項
目を選択するなど、端末３０に特定の操作を施し、これ
に対応する処理が実行されると考えられる。そこで、例
えば、図３のように業務プログラム３２中でオペレータ
が一人の顧客を対応し終えるときに必ず実行される後処
理ルーチンの部分２３１中に、イベントを発生するルー
チンを埋め込んでおく。終了予測信号発生部３１は、こ
の部分の実行により発生されたイベントに応答して、特
定の箇所の実行を示す通知をストコンピュータ２０側の
プレディクティブダイアリング・プログラム２３に通知
する。

【００４４】（２）上記の後処理ルーチン２３１の実行
を間接的に検出する。例えば、オペレータが一人の顧客
への対応を開始した以後は、端末３０から図示しない外
部記憶装置へのデータ書き込みが後処理ルーチン２３１
によってのみ行われるような場合、端末３０から外部記
憶装置へのデータ書き込みを検出することにより、後処
理ルーチン２３１が実行されたものとみなす。終了予測
信号発生部３１は、端末３０から外部記憶装置へのデー
タ書き込みの検出に応答して、特定の箇所の実行を示す
通知をストコンピュータ２０側のプレディクティブダイ
アリング・プログラム２３に通知する。

【００４５】なお、これらの他にも種々の方法が考えら
れる。このように本実施形態によれば、オペレータ端末
上の業務プログラムの特定の箇所を実行した時刻が通知
されるため、ホストコンピュータ上のプレディクティブ
ダイアリングプログラムでは、各通話の進行状況をより
詳しく把握することができ、通話の終了時刻をより正確
に予測することができる。これにより、プレディクティ
ブダイアリングの性能を向上させることができ、ひいて
はオペレータの効率向上と、接続されたコールに対する
待ちを発生させないことを両立させることができる。

【００４６】以下では、本実施形態についてより詳しく
説明する。ここで本実施形態の説明に先だって、図４に
示す代表的なプレディクティブダイアリング処理を参照
しながら、従来のコールセンター・システムについて説
明しておく。

【００４７】プレディクティブダイアリングプログラム
は、イベントの発生により対応する機能が起動されるも
のである。イベントは、交換機やオペレータ端末から通
知される。

【００４８】まず、システムの初期化を行う（ステップ
Ｓ２１）。この時点で例えばオペレータ数分の発呼が行
われる。続いて、全体の動きはイベント発生に従い、制
御される（ステップＳ２２）。

【００４９】イベントとしては、「電話の接続」、「発
呼に対する応答」、「通話の終了」、「呼出しのタイム
アウト」等がある。また、本方式は一定の時間間隔にお
いて通話状況を調べながら発呼を制御するものとする。
従って、一定の時間が経過するとタイマ割込みによるイ
ベントがシステムに通知され、システムはそのときの状
況により発呼数を決定して発呼する。

【００５０】まず、接続イベントが発生すると、接続先
が話中であるか否かが判別される。話中の場合は回線の
切断を行い（ステップＳ２３）、話中でなければ呼出し
音をならし、顧客が電話に出るのを一定時間待つ。ここ
では、一定時間を３０秒とする（ステップＳ２４）。

【００５１】顧客からの応答があった場合は、まず空き
オペレータを調べる（ステップＳ２５）。空きオペレー
タが見つかった場合にはそのオペレータに通話を割り当
てる（ステップＳ２６）。空きオペレータが見つからな
かった場合には通話を待ち行列に登録する（ステップＳ
２７）。

【００５２】オペレータが通話を終了した場合は、この
待ち行列を調べ、待ち行列に登録されている通話がある
ならば、それをオペレータに割り当てる（ステップＳ２
８）。待ち行列に登録された通話がないならば、オペレ
ータには割り当てられる通話がないのでそのまま待機す
る。

【００５３】タイムアウトとは、３０秒呼出し音をなら
しても顧客が電話に出ない場合に発生するイベントであ
る。この場合は顧客不在とみなし、発呼を中断する（ス
テップＳ２９）。

【００５４】ここでのプレディクティブダイアリングで
は、発呼は一定間隔で行われる。プレディクティブダイ
アリングにおいては、空きオペレータ数と呼出し中の呼
数を調べ（ステップＳ３０，Ｓ３１）、適切な発呼数を
予測する。このとき、発呼に対する応答率を考慮して、
計算が行われる（ステップＳ３２）。

【００５５】例えば、空きオペレータ数をＯＰ、呼出し
中の呼数をＮ_inprogress、応答率をＡ_ratio とすると、
発呼数は、 ＯＰ／Ａ_ratio −Ｎ_inprogress で計算する。すなわち、ＯＰ／Ａ_ratio は、平均的にＯ
Ｐに対応する発呼数を表し、これからＮ_inprogressを減
じることにより、新たに発呼すべき数を求めている。

【００５６】上記値が正の場合にはその発呼数分だけ新
たに発呼を行い（ステップＳ３３）、上記値が負の場合
には発呼は行わない（ステップＳ３４）。この従来のコ
ールセンター・システムにおける問題点として、空きオ
ペレータがいない場合には発呼が行われないため、すべ
てのオペレータが会話中に、あるオペレータの通話が終
了したときには必ず空き状態となるため、オペレータ効
率があまり向上しないことが挙げられる。

【００５７】このため、通話中のオペレータの中で、通
話時間が平均値よりも大きいものを通話が即時終了する
ものと考え、空きオペレータとして算出する方法もあ
る。しかし、これではその通話が終了しない場合に、顧
客が応答した呼に対して空きオペレータがいないことが
生じる確立が高くなる。

【００５８】そこで、本実施形態では、会話が終了しそ
うなオペレータを予め検知し、これを利用して、発呼を
行うようにしている。以下、本実施形態についてより詳
しく説明する。なお、ここでは、本実施形態が図４を用
いて説明した従来のコールセンター・システムと相違す
る点を主として説明する。

【００５９】図５に、本実施形態に係るコールセンター
・システムにおけるプレディクティブダイアリング処理
の手順を示す。図５の処理は、図４と同様にイベントの
発生により対応する機能が起動されるものである。

【００６０】本実施形態における、ステップＳ２１の発
信、全体の動きをイベント発生に従い制御する機能（ス
テップＳ２２）、接続イベントに対応する機能（ステッ
プＳ２３，Ｓ２４）、顧客からの応答イベントに対応す
る機能（ステップＳ２５〜Ｓ２７）、オペレータの通話
の終了イベントに対応する機能（ステップＳ２８）、タ
イムアウトイベントに対応する機能（ステップＳ２９）
については、図４の場合と同様である。

【００６１】本実施形態のプレディクティブダイアリン
グの特徴は、図２の端末３０内の終了予測信号発生部３
１により与えられる終了予測信号をイベントとして取り
扱う点にある。この仕組みは、前述のようにオペレータ
の端末３０上で動く業務プログラム３０中に特定の箇所
を実行したときホストコンピュータ２０に通知する機能
を組み込むことにより実現できる。

【００６２】この終了予測信号に対応するイベントが発
生した場合には、まず、残り時間と、セットアップ時間
計測部２２により与えられる平均セットアップ時間とを
比較し、残り時間の方が大きい場合には、（残り時間）
−（平均セットアップ時間）後にイベントが発生するよ
うにタイマ（図示せず）を設定する（ステップＳ６
０）。残り時間の方が小さい場合には、ただちにその終
了予測信号に係るオペレータを終了予測キュー２４に登
録する（ステップＳ６１）。このタイマ（図示せず）に
よるイベントが発生すれば、同様に該当するオペレータ
を終了予測キュー２４に登録する（ステップＳ６２）。
これは、平均セットアップ時間だけ先回りしてオペレー
タが空になることを予測することに相当する。

【００６３】次に、終了予測キュー２４により与えられ
る情報を利用して発呼を行う方法について述べる。発呼
は図４と同様に一定間隔で行われる。図４との違いは、
ステップＳ８１の発呼数の計算である。

【００６４】本実施形態では、空きオペレータの数をＯ
Ｐ、終了予測キュー２４に登録されたオペレータの数を
ＣＡＮＤＩＤＡＴＥ、呼出し中の呼数をＮ_inprogress、
応答率計測部２１により与えられる応答率をＡ_ratio と
し、発呼数を、 （ＯＰ＋ＣＡＮＤＩＤＡＴＥ）／Ａ_ratio −Ｎ
_inprogress で計算する。すなわち、平均セットアップ時間後に空き
そうなオペレータ数（これはＣＡＮＤＩＤＡＴＥに相当
する）を加味して発呼数を計算する。

【００６５】上記値が正の場合には、図示しないコール
リストなどに従い、その発呼数分だけ新たに発呼を行い
（ステップＳ８２）、上記値が負の場合には発呼は行わ
ない（ステップＳ８３）。

【００６６】この結果、図４の場合に欠点として挙げら
れた状況、すなわち「すべてのオペレータが会話中に、
あるオペレータの通話が終了したときには必ず空き状態
となること」が解消され、オペレータ効率が向上する。

【００６７】このように本実施形態によれば、オペレー
タの会話終了をより高精度に予測することが可能となる
ため、接続されたコールに対する顧客の待ちの発生を少
なくしつつ、あるいは発生した待ちの時間を短くしつ
つ、オペレータ効率向上を図ることができる。

【００６８】（実施形態２−１）図６に本実施形態のコ
ールセンター・システム（アウトバウンド業務処理シス
テム）の構成を示す。本実施形態のコールセンター・シ
ステムはパワーダイヤリングを行うものである。

【００６９】図６のように、オペレータ一人あたり１台
の端末１３０および図示しない電話機が設置され、各端
末１３０はホストコンピュータ１２０に接続されてい
る。また、各電話機は交換機１１０を経由して外線と接
続される。交換機１１０はホストコンピュータ１２０と
接続されている。

【００７０】各オペレータは、接続された顧客と電話機
により必要な会話を行う。端末１３０上では業務プログ
ラムが起動されており、例えば画面上に顧客ファイルか
ら読み出された該顧客に関する情報が表示され、また必
要な入力フィールドが提供される。オペレータにより入
力されたデータは、例えば図示しない顧客ファイルある
いは注文ファイルなどに格納される。オペレータが一人
の顧客に対する業務等を終え、端末１３０に終了を入力
し、あるいは電話機を切ると、例えば端末１３０が初期
画面になるとともに、電話機が次の顧客と接続される。

【００７１】図６のように、ホストコンピュータ１２０
は、スケジューラ１２１、ダイヤラー１２２、タイマ１
２３、次顧客選択部１２４、かけ直しリスト１２５、コ
ールリスト１２６、実行接続判定部１２７、空きオペレ
ータリスト１２８を備えている。また、交換機１１０
は、接続状態検出器１１１を備えている。

【００７２】スケジューラ１２１は、アウトバウンド業
務全体を管理するプログラムである。本実施形態では、
ホストコンピュータ１２０に存在する。ダイヤラー１２
２は、スケジューラ１２１の指示により指定された顧客
に対して通話を起動する機能、通話を中断する機能など
を有する。

【００７３】コールリスト１２６は、アウトバウンド業
務の対象となる顧客のリストである。タイマ１２３は、
ある通話が呼び出し状態になってから指定した時間が経
過したことをスケジューラ１２１に知らせる働きを持
つ。この場合、スケジューラ１２１は、顧客が不在であ
ると判断して通話を中断する。

【００７４】実行継続判定部１２７は、接続イベント時
に、通話が呼び出し状態にある場合に、その通話を継続
するかその場で中断するかを判断する。かけ直しリスト
１２５は、実行継続判定部１２７が中断した通話の顧客
を登録する。

【００７５】次顧客選択部１２４は、次に通話をかける
顧客をコールリスト１２６またはかけ直しリスト１２５
から選択する。空きオペレータリスト１２８は、空き状
態にあるオペレータのリストである。

【００７６】接続状態検出器１１１は、回線の状態を常
に監視している。接続状態検出器１１１は、その応答音
により回線の状態を識別する。すなわち、話し中音がな
っていれば顧客は話し中状態にあると判断し、呼び出し
音がなっていれば顧客は呼び出し状態にあると判断す
る。接続状態検出器１１１は、この音を識別することに
より回線の状態が変化したイベントとその変化後の状態
をスケジューラ１２１に通知する。

【００７７】ここで、本実施形態のスケジューラ１２１
は、個々の通話に関するイベントを検知し、それに伴う
通話の状態遷移を管理している。本実施形態には、起動
イベント、接続イベント、タイムアウトイベント、応答
イベント、会話終了イベントがある。

【００７８】起動イベントは、スケジューラ１２１自身
がダイヤラー１２２に対して通話開始を要求した場合に
発生するイベントである。接続イベントは、セットアッ
プ処理が終了して通話が顧客に接続された場合に発生す
るイベントである。接続イベントは、接続状態検出器１
１１より通知される。

【００７９】タイムアウトイベントは、呼出音が鳴って
いる状態で、指定された時間が経過した場合に発生する
イベントである。この場合、顧客は不在と判断される。
タイムアウトイベントは、タイマ１２３より通知され
る。

【００８０】応答イベントは、顧客が応答した場合に発
生するイベントである。応答イベントは、接続状態検出
器１１１より通知される。会話終了イベントは、顧客と
オペレータの会話が終了した場合に発生するイベントで
ある。会話終了イベントは、端末１３０より通知され
る。

【００８１】本実施形態では、通話の状態は、ダイヤル
してから終了するまでイベントの発生に応じて図７に示
すような状態遷移を行う。ここで、セットアップ状態は
公衆回線で接続中の状態である。

【００８２】呼び出し状態は、通話が接続し呼出音が鳴
っている状態である。話し中状態は、顧客が話し中の状
態である。待ち状態は、（応答した）顧客がオペレータ
の空きを待っている状態である。ただし、パワーダイヤ
リングではこの状態は発生しない。

【００８３】会話中状態は、顧客がオペレータと会話中
の状態である。終了状態は、通話が中断または終了した
状態である。図７のように、起動イベントによりセット
アップ状態（図中Ｓ１０１）に遷移した後、呼び出し状
態（Ｓ１０２）または話し中状態（Ｓ１０３）に遷移す
る。

【００８４】話し中状態（Ｓ１０３）の後は、終了状態
（Ｓ１０６）に遷移する。呼び出し状態（Ｓ１０２）の
後は、直ちにまたは待ち状態（Ｓ１０３）を経て会話中
状態（Ｓ１０４）に遷移し、そして終了状態（Ｓ１０
６）に遷移する。あるいは、タイムアウトにより終了状
態（Ｓ１０６）に遷移する。

【００８５】後述するように本実施形態においては、接
続した後の状態（つまり呼び出し状態、待ち状態および
会話中状態を合わせたもの）にある通話数が重要になっ
てくる。そこで、以下ではこの状態を有効状態と呼ぶこ
ととする。有効状態にある通話の数を有効状態呼数とす
ると、 有効状態呼数＝呼び出し状態呼数＋会話中状態呼数 となる。

【００８６】なお、後述するプレディクティブダイヤリ
ングを行う実施形態２−２では、 有効状態呼数＝呼び出し状態呼数＋待ち状態呼数＋会話
中状態呼数 となる。

【００８７】さて、本実施形態のスケジューラ１２１
は、利用可能な回線が常に利用されているように管理す
る。まず、初期化時にスケジューラ１２１は利用可能な
回線数と同じ数だけコールリスト１２６から顧客を選び
出し通話を起動するようにダイヤラー１２２に要求す
る。従来のパワーダイヤリングでは、オペレータに対す
る待ちを発生しないようにオペレータの数以上に通話を
かけることはなかった。これに対して、本実施形態で
は、コールセンターに継る回線の数をオペレータの数よ
りも多くし、オペレータ数以上の通話を同時にかけるよ
うにしている。

【００８８】通話が顧客に繋がったときに、顧客が話中
ならば話中音が、そうでない場合は呼出音が鳴る。接続
状態検出器１１１は通話が繋がった瞬間にこの音を識別
し、スケジューラ１２１に対して通話が話し中状態、ま
たは呼び出し状態かの通知を行う。

【００８９】スケジューラ１２１は該通話が呼び出し状
態にあるとの通知を受けると、実行継続判定部１２７に
判断を依頼する。実行継続判定部１２７は現在の有効状
態呼数をオペレータ数と比較する。有効状態呼数がオペ
レータ数よりも小さい場合は、そのまま通話を継続す
る。ただし、顧客が不在かもしれないので、タイマに対
１２３して、指定した時間後になっても応答が無い場合
は通話を中断するように設定する。

【００９０】もし、有効状態呼数がオペレータ数と等し
いか、または大きい場合は該通話が有効状態に遷移した
場合、オペレータが処理できない数の通話の応答が発生
する可能性がある。従って、実行継続判定部１２７は該
通話を中断するとの判断を下し、これを受けてスケジュ
ーラ１２１が該通話を直ちに中断する。該通話の顧客
は、また後で通話をかけるためかけ直しリスト１２５に
登録する。

【００９１】タイムアウトイベントまたは会話終了イベ
ントの場合、スケジューラ１２１は通話を終了するの
で、回線に空きができる。このとき、スケジューラ１２
１はかけ直しリスト１２５またはコールリスト１２６か
ら新たな顧客を選択し通話を起動する。

【００９２】以下、本実施形態のスケジューラの処理の
流れについてより詳しく説明する。図８に、本スケジュ
ーラの処理の主要な流れを示す。まず、初期化処理を行
う（ステップＳ１１１）。図９に、初期化処理の詳細を
示す。まず、コールリスト１２６を設定し（ステップＳ
１２１）、空きオペレータリスト１２８を初期化して
（ステップＳ１２２）、アウトバウンド業務の立ち上げ
時に行われる一連の準備を行った後、顧客への通話を開
始する（ステップＳ１２３）。

【００９３】本実施形態では、ステップＳ１２３の通話
の起動に先だって、あらかじめアウトバウンド業務に用
いることのできる回線数をスケジューラ１２１に対して
通知しておく。スケジューラ１２１は次顧客選択部１２
４を用いて回線数だけコールリスト１２４から顧客の電
話番号を取り出す。スケジューラ１２１は、それらの電
話番号をダイヤラー１２２に引渡し、ちょうど回線数の
数だけ通話を起動する（ステップＳ１２３）。その後、
スケジューラ１２１は、イベントを待って待機し（ステ
ップＳ１１２）、発生したイベントに応じ（ステップＳ
１１３，Ｓ１１５，Ｓ１１７，Ｓ１１９）、各イベント
に対応する処理を行う（ステップＳ１１４，Ｓ１１６，
Ｓ１１８，Ｓ１２０）。

【００９４】上記のようにスケジューラ１２１は、発生
したイベントに応じた処理を行う。通話を起動した後、
最初に受け取るのは接続イベント（ステップＳ１１３）
であり、またこの接続イベントに対する処理（ステップ
Ｓ１１４）が本実施形態の最も特徴的な部分の一つであ
る。最初にこの接続イベントに対する処理について説明
する。

【００９５】図１０は、接続イベントが発生したときの
スケジューラの処理である。まずスケジューラ１２１
は、接続状態検出器１１１から通話の状態を受け取る
（ステップＳ１３１）。もしそれが話し中である場合、
通話を切断し（ステップＳ１３５）、新しい通話を開始
する（ステップＳ１３６）。通話の状態が呼び出し状態
の場合は、実行継続判定部１２７がこの通話を継続する
かどうかの判断を行う（ステップＳ１３２）。

【００９６】実行継続判定部１２７は、有効状態になっ
た通話の数と、中断または終了した通話の数を計測する
ことにより有効状態にある通話の数を絶えず把握してい
る。新たな通話が呼び出し状態に入るときに、実行継続
判定部１２７は現在の有効状態呼数とオペレータ数とを
比較する。

【００９７】有効状態呼数がオペレータ数よりも小さい
場合、この通話をこのまま継続してもオペレータが不足
することはない。したがって、そのまま実行継続判定部
１２７は通話を継続する判断を下す。スケジューラ１２
１は実行継続判定部１２７の判断に従って該通話をその
まま継続し、顧客の呼び出しを続ける。ただし、顧客が
不在である場合のために、スケジューラ１２１はタイマ
１２３に対して、ある時間を指定して、その時間経過し
たらタイムアウトイベントを発生するようにプログラム
する（ステップＳ１３４）。

【００９８】逆に、有効状態呼数がオペレータ数より大
きい場合は、該通話が有効状態に遷移した場合、オペレ
ータが処理できない数の通話があるという事態が発生す
る可能性がある。このため実行継続判定部１２７は該通
話を中断する判断を下す。スケジューラ１２１は実行継
続判定部１２７から「中断」の判断を受け取ると、該通
話の顧客をかけ直しリスト１２５に登録する（ステップ
Ｓ１３３）。これは該顧客に対して連絡がとれたのでも
ないし、不在であると判断されたわけでもないので、も
う一度ダイヤルする必要があるからである。その後、ス
ケジューラ１２１は該通話を中断する（ステップＳ１３
５）。中断すると回線に空きができるので、スケジュー
ラ１２１は新しい通話を開始する（ステップＳ１３
６）。

【００９９】次に、図１１に新たに通話を開始するとき
の処理（図１０のステップＳ１３６、図１３のステップ
Ｓ１９３、図１４のステップＳ１６２）の流れを示す。
スケジューラ１２１は、次顧客選択部１２４に次にダイ
ヤルすべき顧客を取り出すように依頼する。このとき、
次顧客選択部１２４は、コールリスト１２６からまだい
一度も試していない顧客を選ぶ選択肢と、かけ直しリス
ト１２５から顧客を選ぶ選択肢の２つの選択肢がある。
いずれを選択するかは任意に設定可能であるが、例え
ば、元々コールリストが重要な顧客の順に並んでいる場
合などであれば、既に試みたかけ直しリスト１２５の方
から選ぶことを優先することが考えられる。図１１で
は、そのような場合を例に取り上げ、かけ直しリスト１
２５が空でない限りはかけ直しリスト１２５から顧客を
選び、そうでない場合のみコールリスト１２６から顧客
を選択するように記述してある。いずれにしても、スケ
ジューラ１２１は、次顧客選択部１２４によって選ばれ
た顧客に対してダイヤルするようにダイヤラー１２２に
指示する。

【０１００】次に、図８のステップＳ１１６に示した応
答イベントに対応する処理について説明する。図１２に
応答イベントに対応する処理の流れを示す。スケジュー
ラ１２１は、空いているオペレータを選び出し、該オペ
レータに対して電話をつなぐ。ここで、実行継続判定部
１２７が有効状態呼数がオペレータ数を上回らないよう
に判断しているので、必ず空いているオペレータが見つ
かる。選ばれたオペレータは、空きオペレータリスト１
２８から取り除く。また、スケジューラ１２１は、該通
話に対して設定されていたタイマをキャンセルする。

【０１０１】次に、図８のステップＳ１１８に示した会
話終了イベントに対応する処理について説明する。図１
３に応答イベントに対応する処理の流れを示す。会話が
終了したので、スケジューラ１２１は通話を終了し（ス
テップＳ１９１）。会話を終了したオペレータを空きオ
ペレータリスト１２８に登録する。また、回線が空くの
で、スケジューラ１２１は図１１に示した通話の起動処
理を行う（ステップＳ１９３）。

【０１０２】次に、図８のステップＳ１２０に示したタ
イムアウトイベントに対応する処理について説明する。
図１４にタイムアウトイベントに対応する処理の流れを
示す。

【０１０３】この場合、タイマ１２３はスケジューラ１
２１にタイムアウトイベントに対して起動されたときの
通話を通知する。スケジューラ１２１は該通話を中断す
る（ステップＳ１６１）。ここで、回線が空くので、ス
ケジューラは図１１に示した通話の起動処理を行う（ス
テップＳ１６２）。

【０１０４】既に説明したように従来のパワーダイヤリ
ングでは、セットアップ時間がオペレータ使用効率向上
の１つの多きな障害になっている。これを改善するため
に、本実施形態では、利用できる限りの回線に対してセ
ットアップ状態にある通話を絶え間なく供給し続けるよ
うにしている。そして、通話数の調整は接続イベント時
に、そのセットアップ状態にある通話を継続するか、そ
こで中断するかの判断だけ行う。これにより、接続イベ
ントの一歩手前にある通話を十分な数だけ維持できるの
で、実質的なセットアップ時間をほとんど０に短縮でき
る。また、話中である顧客は接続イベント時に取り除か
れるが、本実施形態では話中であるために除外される通
話よりも十分に多い数の他の通話がセットアップ状態に
控えているため、話中であることによる問題点もほぼ回
避することができる。

【０１０５】このように本実施形態によれば、パワーダ
イヤリングによるアウトバウンド業務システムにおい
て、セットアップ時間と話し中率を実質的に小さくする
ことにより、オペレータ効率を向上させることができ
る。

【０１０６】（実施形態２−２）図１５に本実施形態の
コールセンター・システム（アウトバウンド業務処理シ
ステム）の構成を示す。

【０１０７】本実施形態のコールセンター・システムは
プレディクティブ・ダイヤリングを行うものであり、パ
ワーダイヤリングを行う図６の構成にさらに、動作予測
部１２７２、統計情報収集部１２７１、待ち行列１２９
を設けている。以下では、本実施形態が実施形態２−１
と相違する点を主として説明する。

【０１０８】プレディクティブ・ダイヤリングでは、オ
ペレータが遊ぶことを予測して通話を起動するので、予
測が外れた場合には一時的にオペレータが不足すること
もあり得る。待ち状態にある通話を登録しておくのが待
ち行列１２９であり、オペレータに空きができたときに
は、待ち行列にある通話を優先的に割り当てる。

【０１０９】動作予測部１２７２は、システムの動作モ
デルを持っており、そのモデルに基づいて今後のシステ
ムの振舞い、例えばオペレータ遊びが出そうであると
か、逆にオペレータが不足して待ち行列に通話が溜りそ
うだ、などを予測する。

【０１１０】統計情報収集部１２７１は、動作予測部１
２７２がシステムの動作を予測するために必要な様々な
統計データを収集する。本実施形態は、基本的な動作は
実施形態２−１と同様であるが、プレディクティブ・ダ
イヤリングを行うことから、接続イベントの際に、通話
が呼び出し状態になったときの実行継続判定部１２７の
判断の方法が相違している。パワーダイヤリングを行う
実施形態２−１の場合、有効状態呼数をオペレータ数と
比較するだけの比較的単純な判断をしていたが、プレデ
ィクティブ・ダイヤリングを行う本実施形態の場合、動
作予測部１２７２が現在のオペレータの利用状況と通話
の待機状況および統計情報収集部１２７１が収集した過
去の履歴から、オペレータが遊ぶ状況が発生するかどう
かの判断を下す。オペレータが遊ぶと予測された場合は
この通話が継続される。そうでない場合は中断され、通
話相手の顧客はかけ直しリスト１２５に登録される。プ
レディクティブ・ダイヤリングの場合、顧客が応答した
ときに全てのオペレータが他の顧客と会話中という場合
もあり得る。この場合は、通話は待ち行列１２９に登録
される。オペレータの会話が終了した時点で、つまりス
ケジューラ１２１が会話終了イベントを通知されたとき
に待ち行列１２９から通話を取り出し空いたオペレータ
に割り当てる。

【０１１１】動作予測部１２７２は、このアウトバウン
ド業務処理システム全体を図１６に示すような待ち行列
としてモデル化している。このモデルでは、各通話が呼
に相当し、各オペレータが窓口に相当する。ここでは、
動作予測部１２７２は、呼数一定の制御方式をとるもの
とする。呼数一定方式では、待ち行列網全体を１つのシ
ステムとみなし、まず予め決められた数の呼をそのシス
テムに投入する。いずれかの呼がシステムから退出した
ら、直ちに新たに呼をシステムに投入する。このように
して、システムの内の呼の数を一定に保つような制御が
呼数一定方式である。

【０１１２】ここでは、通話が有効状態にあるとき、呼
がシステム内にあるものとみなす。本実施形態によれ
ば、セットアップ状態呼数を十分に大きい数に保つこと
ができるため、通話がタイムアウトイベントまたは会話
終了イベントによりシステム外に出た場合に、直ちにシ
ステムに通話を供給できる。従って、近似的に呼数一定
の制御を行うことが可能となる。

【０１１３】さて、呼数一定方式で制御されたシステム
は待ち行列理論でいわゆる閉じた待ち行列網としてモデ
ル化ができる。以下のように定義する。 Ｎ_s ： 呼び出し状態呼数 Ｎ_q ：待ち状態呼数 Ｎ_a ：会話中状態呼数 システム内の呼数（有効状態呼数）Ｎは次のように書け
る。 Ｎ＝Ｎ_s ＋Ｎ_q ＋Ｎ_a （１） また、 Ｐ_k ： システムがＮ_q ＋Ｎ_a ＝ｋ（０≦ｋ≦Ｎ）の
状態にある確率 とする。

【０１１４】λ_s ： 呼び出し状態の会話が継るレー
ト（１／ｓｅｃ） λ_T ： 会話の終了レート（１／ｓｅｃ） とすると、Ｐ_k は式（２）、（３）のようになる。ただ
し、Ｐ₀ は式（４）で示される。ここで、Ｓはオペレー
タ数である。

【０１１５】

【数１】

【０１１６】ここで、顧客が待たされるのは、Ｎ_q ＋Ｎ
_a ＞Ｓの場合である。したがって、待ちの発生する確率
は次のように書ける。 Ｐｗ＝Ｐ_S+1 ＋…＋Ｐ_N （５） 動作予測部１２７２には予め許容される待ちの発生率θ
を与えておく。動作予測部１２７２は、 Ｐｗ≦θ （６） を実現するような最大のＮを計算する。

【０１１７】動作予部１２７２の行う計算に必要なパラ
メータはλ_S ，λ_T の２つである。これらのパラメータ
は平均呼び出し時間、平均会話時間、不在等から計算す
ることができる。このため、統計情報収集部１２７１は
アウトバウンド業務を開始してからの通話の履歴を収集
する。

【０１１８】履歴の収集の仕方には種々の方法が考えら
れるが、例えば、以下のようにすると好ましい。すなわ
ち、ある一日の業務でも朝と夜など時間帯が相違すると
状況が異なるため、平均値の計算はある区切られた区
間、例えば一時間で行うのが良い。そこで、例えば、統
計情報収集部１２７１には予めデータを集計する時間間
隔Ｔ_spanを指定しておき、統計情報収集部１２７１は
［現在時刻−Ｔ_span，現在時刻］の区間に行われた会話
の中で有効状態に入ったものの履歴を保持しているよう
にする。

【０１１９】これにより、 平均呼び出し時間＝全会話の呼び出し時間の合計／全通
話数 平均会話時間＝応答があった会話の会話時間の合計／応
答があった通話数 不在率＝タイムアウトした通話数／全通話数 を計算する。

【０１２０】λ_S およびλ_T は、 λ_S ＝（１−不在率）／平均呼び出し時間 λ_T ＝１／平均会話時間 により求める。

【０１２１】実行継続判定部１２７は、有効状態呼数の
値がＮよりも小さい場合に通話の継続を許し、そうでな
い場合は通話を中断する。既に説明したように従来のプ
レディクティブ・ダイヤリングでは、セットアップ時間
がオペレータ使用効率向上の１つの多きな障害になって
いる。これを改善するために、本実施形態では、上記の
ようにして利用できる限りの回線に対してセットアップ
状態にある通話を絶え間なく供給し続けるようにしてい
る。そして、通話数の調整は接続イベント時に、そのセ
ットアップ状態にある通話を継続するか、そこで中断す
るかの判断だけ行う。これにより、接続イベントの一歩
手前にある通話を十分な数だけ維持できるので、実質的
なセットアップ時間をほとんど０に短縮できる。また、
話中である顧客は接続イベント時に取り除かれるが、本
実施形態では話中であるために除外される通話よりも十
分に多い数の他の通話がセットアップ状態に控えている
ため、話中であることによる問題点もほぼ回避すること
ができる。

【０１２２】このように本実施形態によれば、プレディ
クティブダイヤリングによるアウトバウンド業務処理シ
ステムにおいて、セットアップ時間と話し中率を実質的
に小さくすることにより、接続されたコールに対する顧
客の待ちの発生を少なくしつつ、あるいは発生した待ち
の時間を短くしつつ、オペレータ効率向上を図ることが
できる。

【０１２３】（実施形態３）次に、実施形態３について
説明する。本実施形態の各コールセンター・システム
（アウトバウンド業務処理システム）の構成は、基本的
には図１７と同様である。

【０１２４】すなわち、図１７のように、オペレータ
（図中３０３）一人あたり１台の端末３０４と電話機３
０５が設置され、各端末３０４はホストコンピュータ２
０１に接続されている。また、各電話機３０５は交換機
３０６を経由して外線と接続される。

【０１２５】最も初歩的なシステムでは、コールリスト
２１１に従って端末３０４に顧客の電話番号が表示さ
れ、オペレータが自身で電話をダイヤル操作して発呼を
行う。ホストコンピュータ２０１と交換機３０６が連動
している初歩的なシステムでは、端末３０４からの指示
により交換機３０６経由で（コールリスト２１１に従っ
て）自動的に電話が発信され、電話機３０５に接続され
る。また、パワーダイヤリングやプレディクティブ・ダ
イヤリングを行うシステムでは、交換機３０６はホスト
コンピュータ２０１と接続され、コールリスト２１１に
従って適宜自動発呼される。本発明は、上記のどのシス
テムにも適用可能である。

【０１２６】各オペレータは、接続された顧客と電話機
３０５により必要な会話を行う。端末３０４上では業務
プログラムが起動されており、例えば画面上に顧客ファ
イルから読み出された該顧客に関する情報が表示され、
また必要な入力フィールドが提供される。オペレータに
より入力されたデータは、例えば図示しない顧客ファイ
ルあるいは注文ファイルなどに格納される。オペレータ
が一人の顧客に対する業務等を終え、端末３０４に終了
を入力し、あるいは電話機３０５を切ると、例えば端末
３０４が初期画面になるとともに、電話機３０５が次の
顧客と接続される／あるいは電話機３０５に接続すべき
次の顧客が指示される。

【０１２７】本実施形態では、複数のコールセンター・
システムの連携を考える。図１８には、２つのコールセ
ンター・システムの連携および各コールセンター・シス
テムのホストコンピュータ２０１の内部構成の一例を示
す。

【０１２８】本実施形態のホストコンピュータ２０１
は、コールリスト２１１、顧客選択部２１２、電話発信
部２１３、不在・話し中判定部２１４、顧客情報通知部
２１５、顧客情報受信部２１６を備えている。

【０１２９】本実施形態では、コールセンター・システ
ム（１）（以下、コールセンター１と呼ぶ）とコールセ
ンター・システム（２）（以下、コールセンター２と呼
ぶ）が連携する場合、一方のコールセンター１が情報提
供側となり他方のコールセンター２が情報の受け側とな
る。

【０１３０】コールセンター１とコールセンター２の２
つのコールセンターの連携を考えると、コールセンター
１では、各顧客のデータが入っているコールリスト２１
１（１）から顧客選択部２１２（１）が電話をかける顧
客を選び出し、電話発信部２１３（１）において電話を
かける。その顧客に電話をかけた結果、不在・話し中判
定部２１４（１）により不在又は通話中であることが判
明した場合、顧客情報通知部２１５（１）が、コールセ
ンター２（の顧客情報受信部２１６（２））に不在・話
し中の顧客の情報を通知する。

【０１３１】コールセンター２では、顧客情報受信部２
１６（２）が不在・話し中の顧客の情報を受け取り、顧
客選択部２１２（２）に通知する。顧客選択部２１２
（２）では、コールリスト２１１（２）から電話をかけ
る顧客を選択する際に、不在・話し中であることが判明
した時刻から、一定時間を過ぎた後でないと電話をかけ
ないようにする。

【０１３２】このことにより、コールセンター２では、
明らかに不在・話し中と分かっている顧客に対して電話
をかけることを回避することができる。以下、具体例を
用いて本実施形態について説明する。

【０１３３】図１８に示す形態での２つのコールセンタ
ーで、コールセンター１からコールセンター２に顧客の
不在情報が通知される例を用いる。コールセンター１に
おけるコールリスト１（２１１（１））は、図１９で示
される内容であるとする。この場合、コールセンター１
では、以下の手順で電話をかける。

【０１３４】顧客選択部２１２（１）は、コールリスト
１の最初の顧客Ａ氏の電話番号を取り出し、Ａ氏に電話
をかける。Ａ氏とは電話が繋がり、テレマーケティング
が行われたとする。なお、この時点ではＡ氏に関する不
在等の情報はないものとする。

【０１３５】次に、顧客選択部２１２（１）は、コール
リスト１の次の顧客Ｂ氏の電話番号を取り出し、Ｂ氏に
電話をかける。ここで、Ｂ氏は不在であったとする。こ
の場合、不在か否かは、実際にＢ氏の電話番号に電話を
かけ、一定時間内に応答があるか否かでＢ氏の不在を判
断するので、Ｂ氏に電話をかけてからＢ氏の不在を確認
するまでの時間は無駄な時間となる。

【０１３６】Ｂ氏の不在を確認すると、顧客情報通知部
２１５（１）は、Ｂ氏が不在である旨の情報をコールセ
ンター２に通知する。その際、送られるデータの例を図
２０に示す。この場合は、Ｂ氏が不在である情報、Ｂ氏
の不在を発見した時刻、Ｂ氏の電話番号が送られる。

【０１３７】コールセンター２の顧客情報受信部２１６
（２）は、図２０に示されたデータを受け取る。なお、
Ｂ氏が不在であることおよびこれを検出した時刻等の情
報は、自身の顧客情報受信部２１６（１）に格納する
か、あるいはコールリスト１中にフィールドを設けて記
録しておく。

【０１３８】次に、同時にテレマーケティング業務を行
っているコールセンター２での手順を以下に述べる。コ
ールセンター２におけるコールリスト２（２１１
（２））は、図２１で示される内容であるとする。

【０１３９】顧客選択部２１７（２）は、コールリスト
２の最初の顧客Ｘ氏の電話番号を取り出し、Ｘ氏を発呼
する候補とする。この際、顧客情報受信部２１６（２）
を参照し、Ｘ氏の不在情報が届いていないかチェックす
る。なお、自身で検出したある顧客の不在等の情報をコ
ールリスト中に記録しておく場合、コールリスト２中の
Ｘ氏の不在情報の欄もチェックする。

【０１４０】この場合は、Ｘ氏の不在情報は届いていな
いので、Ｘ氏に電話をかけ、Ｘ氏とは電話がつながり、
テレマーケティングが行われたとする。次に、顧客選択
部２１７（２）は、コールリスト２の次の顧客Ｂ氏の電
話番号を取り出す。そして、顧客情報受信部２１６
（２）を参照し、Ｂ氏の不在情報を届いていないかチェ
ックする。

【０１４１】ここでは、図２０に示されたＢ氏の不在情
報が届けられていたとする。顧客選択部２１７（２）
は、現在の時刻とＢ氏の不在情報の時刻とを比較し、Ｂ
氏の不在が発見された時刻から一定の時間が経過してい
ない場合は、Ｂ氏は不在である確率が大きいと判断し、
Ｂ氏への電話は後に回し、コールリスト２の次の顧客で
あるＹ氏の電話番号を取り出す。

【０１４２】このことにより、不在である確率の大きい
Ｂ氏に電話をかけてから、一定時間内に応答がないこと
を確認し、Ｂ氏の不在を確認するまでの無駄な時間を省
くことができる。

【０１４３】なお、一定時間が経過した後は、該顧客の
不在等の情報は無効にされる。また、不在等の情報が無
効にされた顧客については、その時点で再発呼を行って
も良いし、他のポリシーに従って再発呼するタイミング
を決定しても良い。

【０１４４】また、上記の例において、Ｂ氏が話し中で
あった場合も、コールセンター１からコールセンター２
にＢ氏が話し中である旨の情報が伝えられ、コールセン
ター２では、話し中の確率の大きいＢ氏に電話をかけ、
Ｂ氏の話し中を確認する時間の無駄は省かれる。

【０１４５】不在である旨の情報を通知する発明と話し
中である旨の情報を通知する発明は独立実施可能である
が、好ましくは併用するの良い。この場合、不在と話し
中の区別をせずに通知しても良いし、区別して通知して
も良い。また、不在と話し中の区別をせずに管理しても
良いし、区別して管理しても良い。不在と話し中を区別
する場合、不在のときに次の発呼まで課される経過時間
の長さを、話し中のときに次の発呼まで課される経過時
間の長さより長くしても良い。

【０１４６】上記では、顧客情報通知部２１５（１）か
らの通知は、顧客情報受信部２１６内で保持したが、そ
の通知の内容をコールリストに記録して管理しても良
い。なお、自身で検出したある顧客の不在等の情報をコ
ールリスト中に記録しておく場合、ある顧客の発呼に先
だって、コールリスト中の該顧客の不在情報の欄もチェ
ックする。

【０１４７】上記では、２つのコールセンターの連携に
ついて説明したが、３以上で任意数のコールセンターを
連携させることも可能である。この場合、あるコールセ
ンターは他のコールセンターに対し全ての顧客について
情報を伝えても良いし、各コールセンターに顧客とその
顧客の情報を伝えるべき１または複数の他のコールセン
ターとの対応表を保持しておき、ある顧客の不在または
話し中の情報は対応表で該当するコールセンターにのみ
伝えるようにしても良い。また、情報受け側のコールセ
ンターでは、複数のコールセンターから同一の顧客につ
いての情報が送信されてきた場合、最新の情報を保持
し、それまでの情報は無効とするのが好ましい。

【０１４８】なお、２またはそれ以上のコールセンター
間は、専用回線を用いて接続しても良いし、公衆回線を
介して接続しても良いし、無線を使用して接続しても良
い。次に、上記した構成において、コールセンター１
が、ある顧客Ｄについて不在または話し中を他のコール
センターに通知した後に、再度顧客Ｄに発呼した結果、
今度は接続に成功した場合、コールセンター１は、顧客
Ｄの情報を通知した他のコールセンターに、顧客Ｄが在
宅となったこと通知するようにしても良い。

【０１４９】情報受け側の他のコールセンターでは、顧
客Ｄが在宅となった通知を受けると、顧客Ｄの不在等の
情報を無効にし、顧客Ｄを前記一定時間経過を待たず
に、例えば即座に、顧客Ｄに発呼することができる。

【０１５０】この場合、図１８の各コールセンターのホ
ストコンピュータ２０１の構成に加えて、コールリスト
２１１および／または顧客情報受信部２１６内で管理さ
れている不在または話し中の顧客について電話発信部２
１３からの再発呼に対する応答により該顧客が在宅とな
ったことを検出する機能と、該顧客の不在等の情報を通
知した他のコールセンターすべての情報受信部２１６に
該顧客が在宅となった旨の情報を通知する機能と、在宅
となった通知を受けた顧客の不在等の情報を無効にする
（あるいは前記一定時間が経過したものとする）機能と
を設ければ良い。

【０１５１】このように本実施形態では、複数のコール
センターが連携して、ある顧客の不在あるいは話し中の
情報を互いに通知するようにしたので、不在あるいは話
し中の顧客に電話をかけることを回避するができ、これ
によって、オペレータ効率向上を図ることができる。本
発明は、上述した実施の形態に限定されるものではな
く、その技術的範囲において種々変形して実施すること
ができる。

【０１５２】

【発明の効果】本発明によれば、オペレータ端末上の端
末プログラムの特定箇所が実行されたことを検出するこ
とにより、オペレータの通話の終了時刻をより高精度に
予測し、プレディクティブダイアリングにおいて発呼す
る数を精度良く算出することができるので、接続された
コールに対する被呼者の待ちの発生を少なくし、あるい
は発生した待ちの時間を短くしつつ、オペレータ効率向
上を図ることができる。

【０１５３】本発明によれば、所定量のセットアップ状
態にある通話を絶え間なく供給し続けるようにすること
で、実質的なセットアップ時間をほとんど０に短縮で
き、また話中による影響も受けにくくなるので、パワー
ダイヤリングでは、オペレータ効率を向上させることが
でき、また、プレディクティブダイヤリングでは、接続
されたコールに対する顧客の待ちの発生を少なくしつ
つ、あるいは発生した待ちの時間を短くしつつ、オペレ
ータ効率向上を図ることができる。

【０１５４】本発明によれば、複数のコールセンター間
で、被呼者の不応答情報を互いに通知し共有することに
より、発呼しても応答しないであろう被呼者に電話をか
ける無駄を効果的に回避することができる。これによっ
て、オペレータ効率向上を図ることができる。

【図面の簡単な説明】

【図１】本発明の実施形態１に係るコールセンター・シ
ステムの基本構成を示す図

【図２】図１のコールセンター・システムのより詳細な
構成を示す図

【図３】終了予測信号発生部の一実現例を説明するため
の図

【図４】従来方式のプレディクティブダイアリングの処
理の流れを示すフローチャート

【図５】本実施形態１に係るプレディクティブダイアリ
ングの処理の流れを示すフローチャート

【図６】本発明の実施形態２−１に係るコールセンター
・システムの基本構成を示す図

【図７】通話の状態遷移を示す図

【図８】スケジューラのメイン処理の手順を示すフロー
チャート

【図９】初期化処理の手順を示すフローチャート

【図１０】接続イベント時の処理の手順を示すフローチ
ャート

【図１１】通話の起動時の処理の手順を示すフローチャ
ート

【図１２】応答イベント時の処理の手順を示すフローチ
ャート

【図１３】会話終了イベント時の処理の手順を示すフロ
ーチャート

【図１４】タイムアウトイベント時の処理

【図１５】本発明の実施形態２−２に係るコールセンタ
ー・システムの基本構成を示す図

【図１６】待ち行列モデルを示す図

【図１７】本発明の実施形態３に係るコールセンター・
システムの基本構成を示す図

【図１８】２つのコールセンター・システムの連携およ
び各コールセンター・システムのホストコンピュータの
内部構成の一例を示す図

【図１９】コールセンター１でのコールリストの一例を
示す図

【図２０】コールセンター１からコールセンター２に送
られる不在者情報の一例を示す図

【図２１】コールセンター２でのコールリストの一例を
示す図

【符号の説明】

１０…交換機 ２０…ホストコンピュータ ２１…応答計測部 ２２…セットアップ時間計測部 ２３…プレディクティブダイアリング・プログラム ２４…終了予測キュー ３０…端末 ３１…終了予測信号発生部 ３２…端末プログラム ４０…電話機 １１０…交換機 １１１…接続状態検出器 １２０…ホストコンピュータ １２１…スケジューラ １２２…ダイヤラー １２３…タイマ １２４…次顧客選択部 １２５…かけ直しリスト １２６…コールリスト １２７…実行接続判定部 １２７１…統計情報収集部 １２７２…動作予測部 １２８…空きオペレータリスト １２９…待ち行列 １３０…端末 ２０１…ホストコンピュータ ２１１…コールリスト ２１２…顧客選択部 ２１３…電話発信部 ２１４…不在・話し中判定部 ２１５…顧客情報通知部 ２１６…顧客情報受信部 ３０４…端末 ３０５…電話機 ３０６…交換機

Claims (6)

【特許請求の範囲】
1. 【請求項１】交換機と、該交換機に接続された複数の電
   話機と、該交換機に接続されたホストコンピュータと、
   該ホストコンピュータに接続された複数のオペレータ端
   末とを備え、オペレータ端末ではアウトバウンド業務の
   ための端末プログラムが実行され、前記ホストコンピュ
   ータは各オペレータの一人の被呼者に対する通話の終了
   を予測し該通話の終了に先だって被呼者リストに従い自
   動発呼を行い、応答のあった呼を空き状態となったオペ
   レータに対応する電話機に接続するシステムにおける発
   呼制御方法であって、 前記オペレータ端末上の端末プログラムの特定の箇所が
   実行されたことを検出して前記通話の終了を事前に検知
   し、 通話の終了が事前に検知されたオペレータの数に基づい
   て、自動発呼する呼数を決定することを特徴とする発呼
   制御方法。
2. 【請求項２】前記通話の終了の事前の検知にあたって
   は、前記オペレータ端末に特定の操作が施されたときに
   実行されるべき端末プログラムの特定の箇所が実行され
   たことを検知することを特徴とする請求項１に記載の発
   呼制御方法。
3. 【請求項３】全オペレータ数を越える数の回線を収容す
   る交換機と、該交換機に接続された複数の電話機と、該
   交換機に接続されたホストコンピュータと、該ホストコ
   ンピュータに接続された複数のオペレータ端末とを備
   え、前記ホストコンピュータは各オペレータの一人の被
   呼者に対する通話の終了に応じて、自動発呼に応答した
   呼を空き状態となったオペレータに対応する電話機に接
   続するシステムにおける発呼制御方法であって、 被呼者の情報を登録した被呼者リストに従い発呼と切断
   を繰り返して、所定数のセットアップ状態にある呼を保
   持し、 呼び出し状態にある呼が前記電話機に接続されもしくは
   一定時間経過後に切断されまたは通話中状態にある呼が
   切断された場合、呼び出し状態にある呼数と通話中状態
   にある呼数との和が、全オペレータ数と同数になるよう
   に、前記セットアップ状態にある呼を呼び出し状態に
   し、 空き状態にあるオペレータを登録したオペレータリスト
   に従い、前記呼び出し状態にした呼で一定時間内に被呼
   者から応答のあったものを、空き状態にあるオペレータ
   に対応する電話機に接続することを特徴とする発呼制御
   方法。
4. 【請求項４】全オペレータ数を越える数の回線を収容す
   る交換機と、該交換機に接続された複数の電話機と、該
   交換機に接続されたホストコンピュータと、該ホストコ
   ンピュータに接続された複数のオペレータ端末とを備
   え、前記ホストコンピュータは各オペレータの一人の被
   呼者に対する通話の終了を予測し該通話の終了に先だっ
   て被呼者リストに従い自動発呼を行うとともに、待ち状
   態にある呼または自動発呼に応答した呼を空き状態とな
   ったオペレータに対応する電話機に接続しまたは自動発
   呼に応答した呼を待ち状態とするシステムにおける発呼
   制御方法であって、 被呼者の情報を登録した被呼者リストに従い発呼と切断
   を繰り返して、所定数のセットアップ状態にある呼を保
   持し、 待ち状態にある呼が前記電話機に接続されまたは呼び出
   し状態にある呼が前記電話機に接続されもしくは一定時
   間経過後に切断されまたは通話中状態にある呼が切断さ
   れた場合、呼び出し状態にある呼数と待ち状態にある呼
   数と通話中状態にある呼数との和が、予め定められた待
   ちの状態の呼の発生率の上限値をもとにして、予め収集
   した統計情報に基づいた待ち行列モデルにより決定され
   る、全オペレータ数より大きい所定数と同数になるよう
   に、前記セットアップ状態にある呼を呼び出し状態に
   し、 空き状態にあるオペレータを登録したオペレータリスト
   に従い、前記呼び出し状態にした呼で一定時間内に被呼
   者から応答のあったものを、空き状態にあるオペレータ
   に対応する電話機に接続しまたは待ち状態とすることを
   特徴とする発呼制御方法。
5. 【請求項５】交換機と、該交換機に接続された複数の電
   話機と、該交換機に接続されたホストコンピュータと、
   該ホストコンピュータに接続された複数のオペレータ端
   末とを備え、被呼者リストに従って発呼を行い、応答の
   あった呼を該電話機に接続するシステムにおいて、発呼
   した被呼者が応答不能な状態にあると判断した場合、該
   システムから他のシステムに該被呼者の不応答情報を通
   知し、 前記不応答情報を受け取った前記他のシステムは、該不
   応答情報が通知された前記被呼者については、少なくと
   も一定時間経過するまで発呼しないよう制御することを
   特徴とする発呼制御方法。
6. 【請求項６】一方のシステムが、応答不能な状態にある
   と判断された前記被呼者に発呼し、該被呼者が一定期間
   内に応答した場合、該一方のシステムは、他方のシステ
   ムに該被呼者が応答可能な状態にあることを示す応答可
   能情報を通知することを特徴とする請求項５に記載の発
   呼制御方法。