コール・センタで対話を処理するための将来のエージェント・レディネスを予測するシステムおよび方法
アウトバウンド・コールを行うシステムは、アウトバウンド電話呼をかける、ネットワークに接続された第１ノードと、ネットワークに接続され、ビジーである、準備ができている、および準備ができる時間に関するエージェント状況を報告するために第１ノードにアクセス可能な第２ノードと、ネットワークに接続され、第２ノードにアクセス可能な複数のエージェント機器と、エージェント機器上ごとに１つインストールされる複数のエージェント・アクティビティ・アプリケーションとを含む。好ましい実施形態では、アウトバウンド・コールが、呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて予測される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電話通信の分野に関し、具体的には、コール・センタで対話を処理するための将来のエージェント赤さを予測する方法および装置に関する。
【背景技術】
【０００２】
電話の分野では、消費者商品および／または消費者サービスを消費者の基部に提供する会社の代わりに働くコール・センタがある。コール・センタは、遠隔通信機器と、コール・センタによって代表される１つまたは複数の会社の顧客と対話するために予約された生の個人との連合と定義することができる。
【０００３】
現行技術のコール・センタは、コネクション指向交換電話網を介する電話呼およびインターネット・プロトコル（ＩＰ）ネットワークを介するデータ・ネットワーク・テレフォニ（ＤＮＴ）呼を処理することができる。コール・センタは、通常、対話に使用されるエージェント機器をサポートするローカル・エリア・ネットワーク（ＬＡＮ）を含む。エージェント機器は、一般に、クライアント・インターフェース・アプリケーションを実行するグラフィカル・ユーザ・インターフェース（ＧＵＩ）を有するＬＡＮ接続されたコンピュータである。電話送受器または電話ヘッドセットも、顧客と対話する際にエージェントによって使用される通信機器の一部である。電話は、ＣＯＳＴ電話またはＩＰベースの電話とすることができる。
【０００４】
類似するトレーニングまたは技量を有するエージェントは、特定のコール・センタ・キャンペーンに取り組むために、いくつかのコール・センタで関連付けによって一緒にグループ化される。アウトバウンド・コーリング（ｏｕｔｂｏｕｎｄ ｃａｌｌｉｎｇ）キャンペーンは、集中的なコール・センタ・エージェントのグループを使用する、１つのそのようなキャンペーン・タイプである。アウトバウンド・コーリング・キャンペーンでは、予測された個数のアウトバウンド・コールが、通常は、リストによって提供される顧客電話番号へ自動化されたアウトバウンド・ダイヤラによってかけられる。アウトバウンド・コールは、キャンペーンの持続期間全体を通じてさまざまな期間に何回かに分けてかけられる。アウトバウンド・コンタクト・サーバによってかけられた電話に答える顧客を、処置のために着信として、使用可能なコール・センタ・エージェントにルーティングすることができる。多くの場合に、対話型音声応答（ＩＶＲ）システムが、呼に答える顧客に、次の使用可能な生きたエージェントをしばらく待つように促すために使用される。顧客が生きたエージェントに接続された後に、取引をする機会が、コール・センタのために存在する。
【０００５】
特に自動化されたダイヤリング・システムが使用される時の、アウトバウンド・コーリング・キャンペーンに関する課題の１つは、キャンペーン中の任意の所与のダイヤリング・インターバルにダイヤルすべきアウトバウンド・コールの最良の個数を予測することである。確率論が、多くの予測ダイヤリング動作で、使用可能なエージェントの人数を考慮して、アウトバウンド・コールのよい個数がどれほどであるのかを判定するのを試みるのに使用される。かけられた呼のあるパーセンテージが人間によって答えられないことの、ある確率がある。かけられ、顧客によって答えられる呼のあるパーセンテージが、キューから離脱して、放棄呼と考えられることの、ある確率がある。
【０００６】
キャンペーン中に維持されなければならない２つの主要な原理は、顧客が、生きているエージェントに接続されるために長くは待たないことと、エージェントが、次の呼を受けるためにあまりに長くは待たないことである。アウトバウンド・コール・キャンペーンに関する対話処理でのエージェント利用のより高いパーセンテージが、コール・センタ環境で望まれるが、ルーティングに使用される現在の予測アルゴリズムなどの、呼を処理するためのエージェント・レディネス（ｒｅａｄｉｎｅｓｓ）を判定する従来の手段の多くは、ビジー・エージェントが呼を受ける準備ができていると考えられる時など、エージェントの状況に関する予備情報を考慮できない。過剰なダイヤリング・レート（ｄｉａｌｉｎｇ ｒａｔｅ）が、許容できるレベルを超えて高まる可能性があり、呼放棄レートは、許容できるレベルを超えて高まり、エージェント利用パーセンテージは、より低くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、明らかに必要なものは、使用可能ではないが、アウトバンド・コールが答えられる時までに使用可能になる可能性があるエージェントの人数を考慮する、生きているエージェントに接続するためにアウトバウンド・コールをかけるシステムおよび方法である。
【課題を解決するための手段】
【０００８】
上で述べた問題は、アウトバウンド・コール・キャンペーンの対話処理でのエージェント利用のより高いパーセンテージが、コール・センタ環境で望まれるが、ルーティングに使用される現在の予測アルゴリズムなどの呼を処理するためのエージェント・レディネスを判定する従来の手段の多くが、ビジー・エージェントが呼を受ける準備ができていると考えられる時などのエージェントの状況に関する予備情報を考慮できないことである。過剰なダイヤリング・レートが、許容できるレベルを超えて高まる可能性があり、呼放棄レートは、許容できるレベルを超えて高まり、エージェント利用パーセンテージは、より低くなる。
【０００９】
したがって、本発明人らは、アウトバウンド・キャンペーンに関する過剰なダイヤル条件、より高い呼放棄レート、またはキャンペーンに関するより低いエージェント利用パーセンテージ平均を生じない形で信頼できるエージェント・レディネス予測を提供するために潜在的に利用できる予測能力を示す要素を探して、コール・センタの機能要素を検討した。
【００１０】
すべてのコール・センタ・キャンペーンは、呼負荷によって駆動され、その１つの副産物が、呼を処理する準備のできたエージェントの欠如から生じる、あるパーセンテージの切断された呼または放棄呼である。ほとんどのそのようなコール・センタは、コール・センタの仕事を行うのにアウトバウンド・コンタクト・ユーティリティおよび内部ルーティング・システムを使用し、コンタクト・サーバ、ルータ、および予測ルーティング戦略は、通常、そのような装置の一部である。
【００１１】
本発明人は、ダイヤリングの時点で、対話キューを担当するエージェントのグループについてより信頼できるエージェント・レディネス予測を達成できる場合に、大幅なエージェント利用パーセンテージ増加が生じる可能性があることを、発明的瞬間に認めた。したがって、本発明人は、エージェントに関する呼を受ける準備ができるための時間ウィンドウが、アウトバウンド・コールをかけ、内部ルーティングのために接続する時間までに一般に制限される指定された時間ウィンドウ以下である場合に、ビジー・エージェントが呼を受ける準備ができていると考えることを可能にする、コール・センタ・アウトバウンド・キャンペーンのための独自の予測ルーティング・システムを構築した。エージェント利用パーセンテージの大幅な増加が、過剰なダイヤリングに起因する呼放棄レートの増加を伴わずに、５０人以下のエージェントのグループについて生じる。
【００１２】
したがって、本発明の一実施形態では、アウトバウンド・コールを行うシステムが、提供され、アウトバウンド電話呼をかける、ネットワークに接続された第１ノードと、ネットワークに接続され、ビジーである、準備ができている、および準備ができる時間に関するエージェント状況を報告するために第１ノードにアクセス可能な第２ノードと、ネットワークに接続され、第２ノードにアクセス可能な複数のエージェント機器と、エージェント機器上ごとに１つインストールされる複数のエージェント・アクティビティ・アプリケーションとを含む。好ましい実施形態では、アウトバウンド・コールが、呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて予測される。
【００１３】
一実施形態では、アウトバウンド・コールは、電話ダイヤラを使用してダイヤルされる。一実施形態では、ネットワークは、電話網およびインターネット・ネットワークに接続されたローカル・エリア・ネットワークである。一実施形態では、第１ノードは、電話交換機を介する公衆交換電話網への接続性を有するアウトバウンド・コンタクト・サーバである。一実施形態では、第２ノードは、統計サーバである。一実施形態では、エージェント機器は、デスクトップ・コンピュータであり、エージェント・アクティビティ・アプリケーションは、デスクトップ・インターフェースである。一実施形態では、呼は、ダイヤル・アウトすべき呼の正しい個数を予測するためにエージェント可用性および保留中可用性に関する報告された情報を使用するアルゴリズムによって作られた計算結果に従って予測される。
【００１４】
本発明のもう１つの態様によれば、アウトバウンド電話キャンペーンにおいて、呼を担当するエージェントのグループを最もよく利用するためにダイヤル・アウトすべき呼の正しい個数を予測する方法が提供される。この方法は、（ａ）呼を受けるために待っている使用可能なエージェントおよび指定された時間ウィンドウ内に呼を受ける準備ができるエージェントの人数を合計するステップと、（ｂ）（ａ）の合計からエージェントのキュー内で待っている接続された呼の個数を引くステップと、（ｃ）コール・ヒット・レート（ｃａｌｌ ｈｉｔ ｒａｔｅ）および放棄呼のパーセンテージに対するパーセンテージ定数に対して（ｂ）の値を調整することによって呼の認容できる個数を予測するステップと、（ｄ）進行中の呼の個数を減算することによって（ｃ）の値をさらに洗練するステップとを含む。
【００１５】
この方法の一態様では、ステップ（ａ）で、指定される時間ウィンドウは、呼をダイヤル・アウトする点と進行中の呼が答えられ、キューに入れられる点との間の平均推定時間以下である。この態様では、ステップ（ｂ）で、待っている接続された呼は、顧客によって答えられ、使用可能なエージェントについてキューに入れられた、アウトバウンド・ダイヤルされた呼である。この態様では、ステップ（ｃ）で、コール・ヒット・レートは、人によって答えられるアウトバウンド・コールのパーセンテージである。一態様では、ステップ（ｃ）で、放棄呼は、キュー内で放棄される。この態様では、ステップ（ｄ）で、進行中の呼は、まだ答えられていない現行アウトバウンド・コールである。
【００１６】
本発明のもう１つの実施形態によれば、コール・センタに関連し、ビジーと報告される１人または複数のエージェントが、対話要求に答えるために使用可能になる時を予測するシステムが提供される。このシステムは、各機器がエージェントによって操作される、ネットワークに接続された各機器にローカルにネットワーク上に存在する監視アプリケーションと、定義されたタスクに関するエージェント進行を報告する、機器あたり１つ存在する報告アプリケーションと、監視アプリケーションから情報を受け取り、いずれかのエージェントが対話要求を受け入れる準備ができた場合にそのエージェントがどれであるのかを判定するデータ処理コンポーネントとを含む。各報告アプリケーションは、ホスティング・エージェントの現行タスク実行状態に関して監視アプリケーションに通知を送り、処理コンポーネントは、報告された状態情報に基づいて、各エージェントが対話を受ける準備ができる時刻を計算する。
【００１７】
一実施形態では、機器は、コンピュータであり、報告アプリケーションは、デスクトップ・エージェント・インターフェーシング・アプリケーションである。この実施形態では、タスクは、１つまたは複数のフェーズを有し、各フェーズは、完了までの既知の平均時間を有する。一実施形態では、通知は、ショート・メッセージ・サービス通知であり、通知内容は、タスク識別および現行フェーズ識別を含む。
【００１８】
一実施形態では、要求される対話は、生の電話対話または生のチャット・セッションである。好ましい実施形態では、データ処理コンポーネントは、ルーティング・サーバである。一実施形態では、報告アプリケーションは、エージェントのフェーズ状態を報告するために手動で操作される。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態による、アウトバウンド・コール・システムをサポートする通信ネットワークのアーキテクチャ的概要を示す図である。
【図２】本発明の実施形態による、アウトバウンド・コール発呼システムの基本コンポーネントとコンポーネント対話特性とを示すブロック図である。
【図３】類似する人数のエージェントに関する他のシステムと比較した本発明のシステムの経験的テスティングの結果を示す折れ線グラフである。
【図４】本発明の実施形態による、所与の発呼インターバルでかけるべきアウトバウンド・コールの正しい個数を予測するステップを示すプロセス・フロー図である。
【図５】本発明の実施形態による、発呼に関するエージェントの可用性を予測するためにタイムトゥーレディ（ｔｉｍｅ−ｔｏ−ｒｅａｄｙ）情報を更新するステップを示すプロセス・フロー図である。
【発明を実施するための形態】
【００２０】
本発明人らは、コール・センタ環境で呼を受けるためのエージェント可用性を予測するシステムおよび方法を提供する。本発明を、可能にする詳細において次の例で説明し、次の例は、本発明の１つまたは複数の実施形態を表すことができる。
【００２１】
図１に、本発明の実施形態による、アウトバウンド・コール・システムをサポートする通信ネットワーク１００のアーキテクチャ的概要を示す。通信ネットワーク１００は、本明細書でネットワーク・クラウド１０２およびネットワーク・クラウド１０３によって表される公衆交換電話網（ＰＳＴＮ）へのネットワーク接続性を有するコール・センタ１０１を含む。ＰＳＴＮセグメント１０２は、地理的に局所的なセグメントを表し、ＰＳＴＮセグメント１０３もそうである。ＰＳＴＮセグメント１０２および１０３は、議論のためにのみ、この例では物理的に分離されている。ネットワーク・インフラストラクチャの当業者は、物理インフラストラクチャを論じる時のネットワーク境界の曖昧さを了解するであろう。無線電話キャリア・ネットワークへの接続性をも、この例では論理的に含めることができるが、図のスペースを節約するために、それらは図示されていない。ＰＳＴＮネットワーク・セグメント１０２および１０３は、すべての電話網接続性を表さなければならない。本発明人は、その高い公衆アクセス特性のゆえにＰＳＴＮネットワークを選択する。
【００２２】
ＷＡＮ １０４は、都市域ネットワーク（ｍｕｎｉｃｉｐａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＭＡＮ）、ＷＡＮに接続された会社ＬＡＮ、またはインターネット・ネットワークを含む、私有ネットワーク、会社ネットワーク、または公衆ネットワークとすることができる。本発明人は、その高い公衆アクセス特性のゆえに、この例ではインターネット・ネットワークを選択する。本明細書のこれ以降では、ＷＡＮ １０４を、好ましい実施形態に従ってインターネット１０４と呼ぶ場合がある。しかし、本発明の実践は、インターネット・ネットワークまたはＰＳＴＮに限定されない。インターネット１０４は、本明細書でインターネット・バックボーン１２１によっても表され、インターネット・バックボーン１２１は、全体としてのインターネットを構成する回線、機器、およびアクセス・ポイントのすべてを表す。したがって、本発明の実践に対する地理的限定はない。
【００２３】
コール・センタ１０１は、その中に配置され、ネットワーク通信用のさまざまなステーションおよび機器に接続するように適合されたローカル・エリア・ネットワーク（ＬＡＮ）１０５を有する。ＬＡＮ １０５は、複数のエージェント・ステーション１０６（１〜ｎ）をサポートする。エージェント・ステーション１０６（１〜ｎ）は、一般に、この実施形態ではそれぞれデスクトップ・パーソナル・コンピュータ（ＰＣ）および電話機を含むものとして特徴付けられる。この例では、各エージェント・コンピュータは、ＬＡＮ接続され、各電話機は、内部電話配線によってＰＳＴＮセグメント１０２内のローカル電話交換機（ＬＳ）１１９に接続される。電話交換機１１９を、ＡＣＤ（ａｕｔｏｍａｔｅｄ ｃａｌｌ ｄｉｓｔｒｉｂｕｔｏｒ）とすることができる。一実施形態では、ＬＳ １１９を、構内交換機（ＰＢＸ）交換機とすることができる。ＬＳ １１９を、本発明の趣旨および範囲から逸脱せずに、コール・センタ１０１の物理ドメイン内で維持し、電話局交換機として管理することができる。この例では、交換機は、ネットワーク内に設けられ、コール・センタによって賃貸される。
【００２４】
ＬＳ １１９は、ＣＴＩ（ｃｏｍｐｕｔｅｒ ｔｅｌｅｐｈｏｎｅ ｉｎｔｅｇｒａｔｅｄ）プロセッサ１０９によってインテリジェント・ルーティングおよびカスタマ・インターフェースについて機能強化され、ＣＴＩプロセッサ１０９は、対話型音声応答ユニットのインスタンスをもサポートする。ＣＴＩプロセッサ１０９は、コール・センタ１０１の側でＬＡＮ １０５に接続され、ＣＴＩリンクによってＬＳ １１９に接続される。複数のコール・センタ電話連絡先１２０（１〜ｎ）が、ＰＳＴＮ １０２内に図示されている。本明細書で電話機アイコンによって表される電話連絡先１２０（１〜ｎ）は、センタに連絡することができるか電話を使用してセンタが連絡できる、コール・センタ１０１のすべての顧客を表す。一実施形態では、電話連絡先１２０（１〜ｎ）は、アウトバウンド・コール・センタ・キャンペーンの一部としてコール・センタ１０１によって作られるアウトバウンド連絡先である。
【００２５】
ＰＳＴＮセグメント１０３は、ローカル電話交換機ＬＳ １２５を含む。ＬＳ １２５は、インターネット・ネットワーク１０４へのインターネット・アクセスを得るのに使用できる、ＰＳＴＮネットワーク内の任意の電話交換機を表す。電話交換機１２５は、電話幹線を介してＬＳ １１９に接続される。複数のアウトバウンド招待客１２７（１〜ｎ）は、インターネット・サービス・プロバイダ（ＩＳＰ）１２６を介するＬＳ １２５へのインターネット・アクセス回線を介するインターネット・バックボーン１２１へのアクセスを有する、コール・センタ１０１のウェブ接続された顧客を表す。招待客１２７（１〜ｎ）は、論理的には動作するデスクトップ・パーソナル・コンピュータ（ＰＣ）として特徴付けられるが、スマート・ホン、携帯情報端末（ＰＤＡ）、ラップトップ機、またはある他のネットワーク対応機器などの任意のインターネット対応電子機器を使用してインターネット１０４へのアクセスを得ることができる。この例では、用語招待客は、コール・センタ１０１から送信された招待がコール・センタとの対話に参加するために招待客１２７（１〜ｎ）のいずれかによって受信され得る、招待の状態を表す。一実施形態では、招待される対話は、オンライン・チャットである。
【００２６】
招待客１２７（１〜ｎ）を、インターネット１０４内に図示され、バックボーン１２１に接続されたウェブ・サーバ（ＷＳ）１２２にオンラインで接続することができる。ＷＳ １２２は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＷＳ １２２は、ユニバーサル・リソース・ロケータおよびさらにウェブ・ブラウジングによって情報にアクセスする接続されたクライアントに、ウェブ・ページ情報を含む電子情報を供給する。各コンピュータを、当技術分野で既知のようにウェブ・ブラウザを使用してインターネット１０４に接続されると仮定することができる。この例では、ＷＳ １２２は、コール・センタ１０１の会社ウェブ・サイト（図示せず）をホスティングし、この会社ウェブ・サイトには、顧客がコンピューティング機器１２７（１〜ｎ）から操作することによってアクセスすることができる。招待客１２７（１〜ｎ）は、ＩＰ音声テレフォニを実践するためのヘッドセットを含むインターネット・プロトコル（ＩＰ）音声アプリケーションをも備える。ＩＰベースのＩＶＲプラットフォーム１２３は、コール・センタ１０１に包括的な会社ウェブ・サイト上でホスティングされ、その結果、コール・センタは、当技術分野で明確に確立される音声認識技術を使用して、招待客１２７（１〜ｎ）および任意の他のコンピュータ・ネットワーク顧客と対話できるようになる。
【００２７】
チャット・サーバ（ＣＨＳ）１２４は、インターネット１０４内に図示され、バックボーン１２１に接続される。ＣＨＳ １２４は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。チャット・サーバ１２４は、１つまたは複数の顧客およびコール・センタ１０１からの１つまたは複数のエージェントを含む電子チャット・セッションをホスティングする。チャット・サーバ１２４を、コール・センタ１０４によってホスティングすることができ、あるいは、コール・センタ１０４によって賃貸し、またはこれにサブスクライブすることができる。リンクを、チャットのためにＷＳ １２２内でホスティングされるコール・センタ１０１のウェブ・サイト上に設けることができ、このリンクは、顧客をサーバ１２４にリダイレクトすることができる。招待客１２７（１〜ｎ）に、彼らに電子的に送信されるアウトバウンド招待を介してまたはＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）によって、チャットするように招待することができる。この例では、招待客１２７（１〜ｎ）のインターネット接続性は、ＩＳＰ １２６と、ＰＳＴＮを介する電話接続性とを介して提供される。インターネット・アクセスの方法を、サービス総合ディジタル網（ＩＳＤＮ）、ディジタル加入者回線（ＤＳＬ）、無線ブロードバンド、Ｔ−Ｘネットワーク接続、ケーブル・モデム、衛星サービス、または類似物とすることができる。
【００２８】
本明細書では、アウトバウンド連絡先１２０（１〜ｎ）およびアウトバウンド招待客１２７（１〜ｎ）が、コール・センタ１０１によって、またはコール・センタによってホスティングされるある対話への懇請の目的によって、連絡をとられたコール・センタ１０１の顧客を表すことに留意されたい。コール・センタ１０１から開始されるアウトバウンド連絡は、アウトバウンド電話連絡キャンペーンの形または電子的に受信される招待の形をとることができる。アウトバウンド音声連絡を、ＣＯＳＴ（ｃｏｎｎｅｃｔｉｏｎ ｏｒｉｅｎｔｅｄ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｙ）連絡またはＶｏＩＰ呼を含むＩＰＮＴ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｎｅｔｗｏｒｋ Ｔｅｌｅｐｈｏｎｅ）呼とすることができる。
【００２９】
コール・センタ１０１内のＬＡＮ １０５は、インターネット・プロトコル・ルータ（ＩＲ）１１１をサポートする。ＩＲ １１１は、実行可能ソフトウェアを格納し、ルータ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＩＲ １１１は、ＬＡＮ １０５にインターネット接続性を提供する。ＩＲ １１１は、両方向の音声呼、チャット、および電子メッセージングをサポートする。ＬＡＮ １０５は、インターネット・プロトコル上の転送制御プロトコル（ＴＣＰ／ＩＰ）のために機能強化される。ＬＡＮ １０５は、アウトバウンド・コンタクト・サーバ（ＯＣＳ）１１４をサポートする。ＯＣＳ １１４は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＯＣＳ １１４は、コール・センタ１０１の代わりにアウトバウンド電話呼をかけるための自動電話ダイヤラ（図示せず）を備える。ＯＣＳ １１４は、自動化されたダイヤリング・ソフトウェアを介してＣＯＳＴ呼をかけることができる。ＯＣＳ １１４を、アウトバウンド連絡先１２０（１〜ｎ）に電話をかけるためにアウトバウンド・コール・キャンペーン中に使用することができる。一実施形態で、ＯＣＳ １１４は、アウトバウンド招待客１２７（１〜ｎ）にＩＰベースのアウトバウンド音声呼をかけるように機能強化される。
【００３０】
統計サーバ（ＳＳ）１１２は、コール・センタ１０１内に図示され、ＬＡＮ １０５に接続される。ＳＳ １１２は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＳＳ １１２は、キュー内の推定待ち時間（ｅｓｔｉｍａｔｅｄ ｗａｉｔｉｎｇ ｔｉｍｅ、ＥＷＴ）およびエージェント・ステーション１０６（１〜ｎ）から働くエージェントの現行可用性状態などのリアル・タイム統計を含むコール・センタ動作に関連する統計をコンパイルするように適合される。統計リポジトリ１１３は、設けられ、別々のデータ・リンクを介してサーバ１１２に接続される。センタで働くエージェントの現行状況を、ＳＳ １１２に報告し、アクセスのためにリポジトリ１１３に格納することができる。
【００３１】
エージェント・コンピュータは、エージェント・デスクトップ（ＡＤＴ）アプリケーション１０７を備える。１つのそのようなアプリケーションが、ステーション１０６（１〜ｎ）内の各コンピュータ上に図示されている。ＡＤＴ １０７は、エージェントがコール・センタ・システムおよびアプリケーションに接続し、ログ・インすることを可能にし、また、特定の通信能力およびルーティング能力をエージェントに提供する。この実施形態では、ＡＤＴ １０７は、報告能力を有して機能強化され、この報告能力では、アプリケーションが、通信中およびコール・センタ動作中に特定のエージェントの状態を監視し、報告することができる。たとえば、あるエージェントが、電話呼を受け入れる準備ができた場合に、ＡＤＴ １０７は、その状態をＳＳ １１２に報告する。エージェント電話キュー１０８は、コール・センタ１０１内に図示され、ＬＡＮ １０５に接続される。エージェント・キュー１０８は、エージェント・ステーション１０６（１〜ｎ）で働くエージェントによって共有されるキューを表す。エージェント・キュー１０８は、生の支援を待っているＣＯＳＴテレフォニ・イベントとデータ・ネットワーク・テレフォニ（ＤＮＴ）イベントとの両方を表すように適合された仮想キューとすることができる。
【００３２】
ＬＡＮ １０５は、ＵＲＳ（ｕｎｉｖｅｒｓａｌ ｒｏｕｔｉｎｇ ｓｅｒｖｅｒ）１１６をサポートする。ＵＲＳ １１６は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＵＲＳ １１６上の実行可能ソフトウェアは、ルーティング・ソフトウェア（ＳＷ）１２８を含む。ＵＲＳ １１６は、ＣＯＳＴ対話とＤＮＴ対話との両方をサポートする。ＵＲＳは、コール・センタ１０１内の対話を適当なエージェントおよびシステムにルーティングするのに使用されるインテリジェント・ルーティング戦略を提供する。たとえば、生の支援を要求するＬＳ １１９を本拠とする呼は、内部的にＵＲＳ １１６からの命令に基づいてルーティングされる。ＵＲＳ １１６は、現行状態情報のためにＳＳ １１２にサブスクライブすることができる。ＣＴＩプロセッサ１０９は、交換機で受信される着信ごとにルーティング命令のためにＵＲＳ １１６を呼び出す。
【００３３】
ＬＡＮ １０５は、招待（ＩＮＶ）サーバ１１７をサポートする。ＩＮＶ １１７は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＩＮＶ １１７は、たとえばチャット・セッションなどのコール・センタ１０１と対話に参加するようにウェブ・ページ訪問者に勧誘するそのウェブ・ページ訪問者へのアウトバウンド招待を生成するように適合される。この能力は、本発明人に既知であり、関連しない特許出願の対象である。ＰＳＴＮセグメント１０２は、ネットワーク・ゲートウェイ１１０によってインターネット１０４にブリッジされる。このゲートウェイは、２つのネットワークの間で音声通信をブリッジするＳＳ−７または他の既知のゲートウェイとすることができる。
【００３４】
本発明の好ましい実施形態では、コール・センタ１０１は、アウトバウンド・コーリング・キャンペーンに着手することができ、ここで、連絡先１２０（１〜ｎ）などのアウトバウンド連絡先は、電話によって連絡され、コール・センタのエージェントとのある音声対話にかかわるように懇請される。ＯＣＳ １１４上で実行されるＳＷ １１５として本明細書で図示されたペーシング・アルゴリズムは、各ダイヤリング・インターバルに、人間によって答えられたアウトバウンド・コールを着信として接続された呼を受けるのに使用可能なエージェントに効果的に分配するために、何回のアウトバウンド・コールをかけるべきかを判定する。
【００３５】
アウトバウンド・キャンペーン中の任意のダイヤリング・インターバルにかけるべきアウトバウンド・コールの個数を判定するための考慮事項は、コール・センタ１０１のサービス品質（ＱｏＳ）目標を満足することを含む。たとえば、使用可能なエージェントが、呼の間にあまりに長く待たないことが好ましい。顧客が、使用可能なエージェントをあまりに長く待たないことも好ましい。したがって、ＯＣＳ １１４が、どのダイヤリング・インターバルにも少なすぎるまたは多すぎる呼をかけないことが重要である。これは、部分的には、電話をかける時にキャンペーンを担当するエージェントの可用性を知ることによって達成される。アウトバウンド・コールがかけられる時に人間が電話に答える確率（ヒット・レート）など、考慮すべき変数もある。この確率は、ダイヤリング・インターバル中にかけられるすべての呼のパーセンテージとして表される。コール・センタの目標は、低く、比較的一定の呼放棄レートを有することである。たとえば、少なすぎるエージェントについて多すぎる呼がかけられ、接続される場合に、顧客があまりに長くエージェントを待ったので放棄される呼のパーセンテージは、許容できないレベルまで上昇する可能性がある。したがって、過剰なダイヤリングは、ダイヤリング・インターバル中にかけられるすべての呼のおそらくは５％など、最低限に保たれなければならない。
【００３６】
本発明人に既知の通常のアウトバウンド・コール・キャンペーンでは、アウトバウンド・コンタクト・サーバは、呼を受けるのに既に使用可能と判定されるエージェントの人数についてのみ電話をかける。本発明のシステムは、システムが、既に使用可能なエージェントを考慮することと、かけられた電話が答えられ、内部的にルーティングされる時に、ビジーである何人のエージェントが呼を受けるのに使用可能になるのかを電話をかけることの決定点から予測することとを可能にする、独自の機能強化を提供する。正確な予測を達成するために、ＡＤＴアプリケーション１０７は、エージェント・タスクを監視する能力で機能強化される。
【００３７】
エージェント・タスクは、各フェーズが平均処理時間または平均処理持続時間を有する、タスク・フェーズの適用によって定量化される。たとえば特定のタイプ販売の電話呼などのタスクは、複数のフェーズを有する可能性がある。フェーズは、タスクが実行されるたびに繰り返され、通常は秒単位で表される平均持続時間を有する、タスクの一部と定義することができる。販売呼は、たとえば４０秒の平均持続時間を有する可能性がある。エージェントは、第１フェーズで製品情報をコンパイルし、第２フェーズ中に注文量を確認し、クレジット・カード番号をとり、その後、最終フェーズで電子領収書および出荷注文を生成するために注文を処理しなければならない可能性がある。各フェーズが、タスク全体について４０秒のうちのある分割という平均持続時間を有する可能性がある。
【００３８】
ＡＤＴ １０７は、すべてのフェーズ遷移でリアル・タイムでＳＳ １１２に自動的に報告することができる。たとえば、指定されたタスクのフェーズ１で、エージェントは、呼を受け入れる準備ができるまでに４０秒を有する。そのタスクのフェーズ１とフェーズ２との間の遷移で、エージェントは、呼を受け入れる準備ができたと考えられ得るようになる前に２０秒を有する可能性がある。そのタスクの第２フェーズと最終フェーズとの間の遷移点で、エージェントは、呼を受け入れるのに使用可能と考えられ得るようになる前に１０秒だけを有する可能性がある。予備エージェント状態情報が重要であるのは、アウトバウンド・キャンペーン中に実行されるダイヤリング・インターバルの点から、そのインターバル中にダイヤルされる呼が顧客によって答えられる前に非常に多くの秒数が経過するからである。この時間の長さは、ダイヤリング・インターバルごとに平均をとられ、呼をダイヤルする点で、ＳＷ １１５によって支援されるＯＣＳ １１４が、ＵＲＳ １２８からまたは直接にＳＳ １１２から既に使用可能なエージェントの人数を得るようになる。その後、ＯＣＳ １１４は、かけられた呼が答えられ、キューに接続される時に使用可能であると予測されるビジー・エージェントの人数を入手する。
【００３９】
その後、答えられた呼は、キャンペーンを担当するエージェントのグループに関する着信として扱われ、ＳＷ １２８によって支援されるＵＲＳ １１６によって、使用可能なエージェントにルーティングされる。呼が答えられる時までの複数のビジー・エージェントの可用性を予測することによって、放棄レートを超えずに、より多くの呼をかけ、成功してルーティングすることができる。本発明の一実施形態では、予測アルゴリズムは、ＯＣＳ １１４上でＳＷ １１５として実行され、ＳＳ １１２は、リポジトリ１１３内に現行統計のすべてを保つ。このアルゴリズムは、電話呼の別の束を加えるとシステムが決定するたびに点火する。既に呼を受け入れる準備ができていると判定されるエージェントは、呼を待っており、答えられた呼が着信として彼らにルーティングされるまでビジーではないエージェントである。準備ができると予測されるエージェントは、システムによる発呼から呼応答およびエージェントへの内部ルーティングまでの平均時間ウィンドウ以下の残りタスク時間を有するビジー・エージェントである。
【００４０】
本発明の一実施形態では、この予測方法は、たとえばチャットなどのある対話への参加のアウトバウンド・ウェブ招待に使用される。この実施形態では、ＩＮＶサーバ１１７は、ＷＳ １２２内でホスティングされる会社ウェブ・サイトをブラウズしているのを検出された招待客１２７（１〜ｎ）などのウェブ連絡先への招待を生成する。この実施形態では、ステーション１０６（１〜ｎ）で働くエージェントは、そのエージェントとチャット招待を受け入れる招待客との間でセット・アップされるチャット・セッションに入る準備ができている。このケースでの変数は、ＳＷ １１８によって支援される招待システム（ＩＮＶサーバ１１７）が、チャット・セッションに参加するためのエージェントの予測された可用性に基づいて送出される招待の数を決定するという点で、アウトバウンド電話連絡に似ている。テレフォニ法とウェブ招待法との間の１つの相違は、エージェントがＡＤＴアプリケーション・チャット・インターフェース内で同時に複数のチャット・ウィンドウを実行することができると仮定して、１人のエージェントが複数の受け入れられたチャット招待について使用可能と考えられ得ることとすることができる。
【００４１】
ヒット・レートは、チャット招待の受け入れについて計算され、平均をとられる。放棄レートを、チャット・セッションが招待客のために開始される前にキュー内の高いＥＷＴに起因してネットワークから外れた、チャット招待を受け入れた招待客のパーセンテージと定義することができる。このケースのアルゴリズムは、ＳＷ １１８としてＩＮＶサーバ１１７上で実行される。ＡＤＴアプリケーション１０７は、ビジーまたは非ビジーに関するエージェント状況を、招待が送出される時にチャットに既に使用可能なエージェントについてＳＳ １１２に報告する。これらのエージェントは、準備ができていると考えられ、送出されたチャット招待の受け入れに基づいてチャット・セッションのために予約される。招待が受け入れられる時までに準備ができると予測されるビジー・エージェントは、これらのエージェントについて残っているタスク時間が、招待が送出された時に始まりこれらの招待が答えられると予想される時に終わる指定された時間ウィンドウ内である場合に、システムによって準備ができていると考えられる。ヒット・レートなどの変数が、招待客によって答えられる送信された招待のパーセンテージを予測するために計算される。招待が無視されるか断られる確率要因は、たとえばビジー、機械によって答えられる、答えられない、答えられたが断られたなど、電話連絡先に関する確率変数に似て平均ヒット・レートに算入される。
【００４２】
ＯＣＳ １１４は、ＣＴＩプロセッサ１０９およびＬＳ １１９の経路を介する連絡先１２０（１〜ｎ）へのアウトバウンド電話呼をダイヤルすることができる。一実施形態では、ＯＣＳ １１４は、ＬＳ １１９および連絡先１２０（１〜ｎ）へのゲートウェイ１１０を介するＩＲ １１１の経路を介して呼をダイヤルする。ＳＷ １１８によって支援されるＩＮＶサーバ１１７は、ＩＲ １１１を介してＷＳ １２２にチャット招待を送信する。本発明の一実施形態では、チャット招待は、音声ブラウザを使用してウェブ・サイトをブラウズしているかＩＰボイス・テレフォニ・アプリケーションを使用してウェブ・サイト（ＩＰ／ＩＶＲプラットフォーム１２３）と対話している招待客への合成された音声招待としてＩＰ／ＩＶＲプラットフォーム１２３を介して作られた音声プロンプト招待として含まれる。一実施形態では、ＯＣＳ １１４は、アウトバウンド・コーリング・キャンペーン中に単一のダイヤリング・インターバルでＣＯＳＴ呼とＩＰテレフォニ呼との両方をかけることができる。このケースでは、一方はかけられたＣＯＳＴ呼、他方はかけられたＩＰ呼に関する、２つの平均をとられる回答までの時間ウィンドウがある可能性がある。エージェントにルーティングされる着信を、すべて、一実施形態では電話機によって処理することができる。別の実施形態では、ＩＰ呼は、コンピュータ・テレフォニ・アプリケーションを介して答えられ、ＣＯＳＴ呼は、電話機によって処理される。
【００４３】
図２は、本発明の実施形態による、アウトバウンド・コール発呼システムの基本コンポーネントとコンポーネント対話特性とを示すブロック図である。エージェント・デスクトップ・アプリケーション（ＡＤＴ）２００が、この例では、アウトバウンド・キャンペーンで働く１２人のコール・センタ・エージェントのエージェント番号１について図示されている。ＡＤＴ ２００は、図１のＡＤＴ １０７に類似する。エージェント番号１は、タイプ取引の電話呼と定義されるタスク２０４でビジーと考えられる。この例では、完了まで平均５秒のフェーズ１、平均１０秒で完了されるフェーズ２、および平均１０秒で完了されるフェーズ３を含む３フェーズとしての電話呼。この例では、タスク持続時間全体が、２５秒である。アウトバウンド・コールの発呼からのこれらの呼に答えるのに要する時間が２５秒を超える場合には、アウトバウンド・ダイヤリング・インターバルの初めにタイプ取引の電話呼で現在ビジーであるすべてのエージェントが、呼を受け入れる準備ができると予測される。
【００４４】
ＡＤＴ ２００は、エージェント状況をリアル・タイムでＳＳ ２０１に報告する。ＳＳサービス２０１は、ＳＳサーバ１１２およびＳＷ １１３に類似する。この小さいエージェント・グループで働く１２人のエージェントがいる。エージェント１〜１２のうちで、ＳＳは、呼を受けるために既に使用可能である、これらのエージェントのうちの２人を数える。呼を受けるのに既に使用可能と考えられるエージェント７および１２がいる。たとえば、エージェント７および１２は、呼を受け入れるために既に使用可能であるものとすることができ、エージェント１は、呼を受け入れる準備ができると予測されるものとすることができる。この例では、エージェント１は、ビジーであるが、タイプ取引の電話呼のタスクのフェーズ３に入っている。
【００４５】
この例では、図１のＵＲＳ １１６に類似するルーティング・サービス２０２は、アウトバウンド・コンタクト・サービス２０３の代わりに統計サービスから情報を得、アウトバウンド・コンタクト・サービス２０３は、図１のＯＣＳ １１４に類似する。好ましい実施形態では、この方法は、既に準備ができているエージェントの人数に、答えられた呼のある最小ダイヤル持続時間より早く準備ができるエージェントの人数を加え、キューに入れられた呼の数を引いたものと定義される、使用可能なエージェントの人数の計算を含む。キューに１つの呼があり、したがって、準備ができると予測された第３のエージェントが、キューに入れられた呼によって打ち消され、２人の準備ができたエージェントが残される。
【００４６】
この方法は、放棄呼の所望のパーセンテージを超えずに使用可能なエージェントの人数およびヒット・レシオの推定値についてダイヤルできる、アウトバウンド・コールの認容できる個数の計算をも含む。最終的に、この方法は、ダイヤルできる予測呼の個数を予測する。ダイヤルされなければならない予測呼の個数は、アウトバウンド・コールの認容できる個数と、かけられたがまだ答えられていない呼と定義されるダイヤルされた呼の個数との間の差である。
【００４７】
ここで戻って図２を参照すると、３人の準備のできたエージェント（２人は準備ができ、１人は予測された）がいる。キュー内の１つの呼を引いて、２人の準備のできたエージェントが残される。予測されたエージェントおよびキュー内の単一の呼が、打ち消し合う。かけられた呼の発呼から応答までの持続時間は、この例では１０秒である。ヒット・レシオ（答えられる呼）は、５０％である。呼の許容できる放棄レートは、１０％である。８％の現行放棄レシオを仮定すると、使用可能なエージェントの人数は２である（２人の準備ができたエージェント＋第３のエージェント−１つのキューに入れられた呼）。
【００４８】
かけることのできる呼の認容できる個数は、３つの呼である。このカテゴリの呼を追加することの背後にある論理は、放棄呼の期待されるパーセンテージが８％である（１０％の許容されるレート未満）であることに基づく。このケースでは、放棄呼の確率は、定数１２．５％÷答えられる呼の平均値すなわち１．５（１２．５％÷１．５）＝８．３３％である。ある呼は、３つの認容できる呼というこの例で１２．５％の確率で放棄され得る。答えられる呼の期待される平均値は、１．５（３つの認容できる呼×０．５）である。
【００４９】
この例では、アウトバウンド・コンタクト・サービスは、ダイヤルされたがまだ答えられていない１つの呼があるので、２つの呼をかける。３つの認容できる呼−１つのダイヤルされた呼＝かけられるべき予測呼の個数＝２つの予測呼。呼の認容できる個数が、３つの呼ではなく４つの呼である場合には、放棄呼の期待されるパーセンテージは、１０％という最大の許容できるパーセンテージより大きい。この例では、我々は、エージェント１が、平均呼持続時間（１０秒）としてシステムによって課せられる時間限度またはそれ以内に呼を受ける準備ができるという予備情報を有する。ビジー・エージェントの予備情報がなければ、ダイヤルされなければならない呼の予測個数は、０である。このケースでは、第３のエージェントは、１０秒で使用可能になった後に、呼を通常より長く待つはずである。
【００５０】
本発明の一実施形態では、放棄呼の期待される個数は、答えられた呼の個数から使用可能なエージェントの人数を引いたものと等しい。その差が０より大きい場合には、使用可能なエージェントの人数は２である。この例では、答えられる呼の平均個数、放棄呼の平均個数、および放棄呼の期待されるパーセンテージが、ダイヤラによってかけられる呼の個数に基づく依存する形で表される。３つの呼について、５０％のヒット・レシオ（答えられる呼のパーセンテージ）を与えられれば、答えられる呼の平均個数を、３＊｛ｐ＊（１−ｐ）２｝＊１＋３＊｛ｐ２＊（１−ｐ）｝＊２＋ｐ３＊３＝１２＊０．１２５＝１．５として表すことができる。放棄呼の平均個数を、ｐ３＊１＝０．１２５として表すことができる。放棄呼の期待されるパーセンテージを、０．１２５／１．５＊１００％＝８．３％として表すことができる。したがって、３つの認容できる呼について、放棄呼の期待されるパーセンテージは、１０％というこの例での許容限度より小さい。
【００５１】
上のパラメータを与えられて、ダイヤラが、４つの呼を試みる場合には、答えられる呼の平均個数は、４＊｛ｐ＊（１−ｐ）３｝＊１＋６＊｛ｐ２＊（１−ｐ）２｝＊２＋４＊｛ｐ３＊（１−ｐ）｝＊３＋ｐ４＊４＝３２＊０．０６２５＝２として表される。放棄呼の平均個数は、４＊｛ｐ３＊（１−ｐ）｝＊１＋ｐ４＊２＝６＊０．０６２５＝０．３７５として表される。放棄呼の期待されるパーセンテージは、０．３７５／２＊１００％＝１８．７５％になる。期待される呼放棄レートは、１０％という許容できる最大値より大きい。発呼の条件は、期待される呼放棄パーセンテージが、比較的低い許容可能レベル、この例では１０％を超えてはならないということである。この例では、２つの呼がかけられる。というのは、可能性が、１つの呼だけが、顧客が呼に答える時に準備ができる第３のエージェントにルーティングされることであるからである。
【００５２】
本発明の好ましい実施形態では、アウトバウンド・ダイヤリング・サーバは、５０人以下のエージェントを利用するキャンペーンでかけるべきアウトバウンド・コールの正しい個数を判定するためにこの予測方法を使用する。このタイプのエージェント・グループは、小さいグループと考えることができる。
【００５３】
図３は、類似する人数のエージェントに関する他のシステムと比較した本発明のシステムの経験的テスティングの結果を示す折れ線グラフ３００である。グラフ３００は、発呼を予測する異なる方法を使用する別々のアウトバウンド・キャンペーンを担当するエージェントの平均エージェント利用係数または「ビジー係数」をプロットするものである。使用されるエージェントの最大人数は、５０であり、これは、エージェントの小さいグループを示す。テストのすべてについて、ヒット・レシオ＝０．３である（回答確率＝０．３、無回答確率＝０．５、ビジー確率＝０．２）。呼持続時間は、約４０秒になる。比較に関するパラメータは、パーセンテージとして表された、グループ内のエージェントのビジー係数である。
【００５４】
５人から５０人までのエージェントの小さいグループについて、本発明人に既知であり、曲線３０２をプロットするために星アイコンを使用して本明細書で図示されるプログレッシブ・ダイヤリング（ｐｒｏｇｒｅｓｓｉｖｅ ｄｉａｌｉｎｇ）法は、５０人までのエージェントのすべての小さいグループ数について、プロットされた結果の曲線３０２によって示されるように、比較的平らなままである。平均エージェント・ビジー係数は、選択された小さいグループについて約５５％で比較的低いままである。小さいグループに関する方法は、より効果的であり、本明細書では、結果の曲線３０３のプロット内で円を使用して図示されている。この方法は、約５人のエージェントについて６２％のビジー係数を返す。曲線３０３は、より多くのエージェントに伴って安定して上昇し、５０人のエージェントのグループについて７０％のビジー係数を達成する。一般予測法として分類され、本明細書で四角アイコンによって図示される１つの方法は、エージェントのより小さいグループについて非常に悪い性能を有し、３５人と５０人との間のエージェントのエージェント・グループについてはるかによい性能を有する結果曲線３０４を作る。５人のエージェントについて、この方法は、エージェントの４５％未満のビジー係数をもたらす。このパーセンテージは、２０人のエージェントで６０％、３５人のエージェントで８０％、５０人のエージェントで８５に上昇する。この方法は、エージェントのより少ない人数ではるかに信頼できない。
【００５５】
本発明人に既知であり、本明細書で六角形によって図示されるエージェント・スモール・グループ（ａｇｅｎｔ ｓｍａｌｌ ｇｒｏｕｐ、ＡＳＧ）法は、結果曲線３０５を作る。曲線３０５は、５人のエージェントから２０人のエージェントへ劇的に上昇し、２０人のエージェントのグループについて７５％のビジー係数を達成する。２０人のエージェントの小さいグループについて７５％エージェント・ビジー係数に上昇した後に、この方法は、平坦になり、ビジー係数は、５０人のエージェントのグループ・サイズまで平坦なままになる。
【００５６】
フィードバック（ビジー・エージェントの予備可用性予測）を伴うエージェント・スモール・グループ（ＡＳＧ）の本発明の方法は、結果曲線３０６を作る。わずか５人ほどのエージェントもの非常に小さいエージェント・グループについて、エージェント・ビジー係数は、約７２％である。この曲線は、３人から４０人のエージェントまでのより大きいグループについて劇的に上昇し、４０人では、エージェントのビジー係数は約８３％である。５０人のエージェントについて、一般予測法は、８３％と比較して約８５％というエージェントに関するわずかにより高いビジー係数をもたらす。しかし、本発明の方法は、４５人未満のエージェントのエージェント・グループについて、一般予測法および他の既知の方法のすべてをしのぐ。エージェントに関するより高いビジー係数は、エージェントがキャンペーン中によりよく利用されることを意味する。
【００５７】
図４は、本発明の実施形態による、アウトバウンド・コール・キャンペーン中の所与の発呼インターバルでかけるべきアウトバウンド・コールの正しい個数を予測するステップ４００を示すプロセス・フロー図である。ステップ４０１で、システムは、アウトバウンド・コールをかけるべきか否かを判定する。この判定は、リアル・タイム統計から入手されるエージェントの可用性情報に基づいて行うことができる。システムが、コールをかけないと決断する場合には、このプロセスは、ステップ４０１でシステムによってコールをかける決定が行われるまで、ループ・バックする。
【００５８】
ステップ４０２で、システムは、既に呼を受ける準備ができている、キャンペーンを担当するエージェントして定義された準備ができているエージェントの人数を得る。次に、システムは、ステップ４０３で、考慮すべきタイムトゥーレディ（ＴＴＲ）エージェントがいるかどうかを判定する。ＴＴＲエージェントは、顧客がシステムによってかけられた呼に答えるのに要する時間（呼持続時間）以下の指定された時間フレーム内に準備ができたエージェントになるビジー・エージェントである。たとえば、ＴＴＲエージェントは、呼持続時間が１５秒の場合に、１０秒で使用可能になるものとすることができる。そのエージェントは、発呼について準備ができたエージェントと共に使用可能と考えられる。１５秒より長い時間を有するＴＴＲエージェントは、現行の発呼インターバルについて使用可能とは考えられない。
【００５９】
一実施形態では、エージェント自体が、保留中の発呼インターバルの通知を受信した時に、統計に手動で報告する。この例では、エージェントは、ＴＴＲ値を推定し、これをエージェント・デスクトップ・アプリケーションを介して報告する。別の実施形態では、ＡＤＴアプリケーションが、平均完了時間を割り当てられたタスク・ステージまたはフェーズに対するエージェント状態を監視するように機能強化される。この例では、エージェント・デスクトップは、エージェントが現行タスクのあるフェーズから別のフェーズに遷移するたびに、統計サーバに自動的に報告する。システムは、エージェントのタスクが完了する前にどれほどの時間が残されているのかを、使用可能なデータ（フェーズ１＝１０秒、フェーズ２＝１０秒など）から知る。
【００６０】
ステップ４０３で、現行発呼インターバルについて考慮すべきＴＴＲエージェントがないとシステムが判定する場合には、システムは、ステップ４０５で、準備ができているエージェントの人数を持ち越す。システムが、ステップ４０３で可用性の考慮の資格があるＴＴＲエージェントを見つける場合には、システムは、ステップ４０４で、準備ができたエージェントと資格を与えられたＴＴＲエージェントとの合計を計算する。ステップ４０６では、システムは、ＴＴＲエージェントが考慮されたか否かにかかわらず、キュー内に呼があるかどうかを調べる。ステップ４０６で、キュー内に現在は呼がない場合には、システムは、使用可能なエージェントの人数から数を減算する必要がない。ステップ４０８では、システムは、放棄呼の現行％が許容される最大パーセンテージ未満であるかどうかを知るために放棄呼の現行％をチェックすることができる。
【００６１】
システムが、ステップ４０６で、最後の発呼インターバルからのエージェントに関するキューに１つまたは複数の呼があると判定する場合に、システムは、使用可能なエージェントとキュー内の呼（１つまたは複数）との間の差を計算する。より具体的には、システムは、キュー内の呼の個数に基づいて、総数からＴＴＲエージェントの個数を差し引く。キューに１つの呼がある場合には、システムは、１つのＴＴＲエージェントを差し引くか打ち消す。考慮すべきＴＴＲエージェントがない場合には、システムは、準備ができているエージェントを考慮から除去する。本明細書では、ＴＴＲエージェントの場合に、複数のＴＴＲエージェントがあるならば、システムが、最大のタイムトゥーレディ数を有するＴＴＲエージェントを除去することに留意されたい。プロセスは、ステップ４０７からステップ４０８に移り、ここで、システムは、許容可能なしきい値に対して呼放棄パーセンテージをチェックする。
【００６２】
ステップ４０９では、システムは、準備ができたエージェントに関するかけるべき呼の公称個数に呼を追加すべきかどうかを判定する。システムは、呼放棄パーセンテージの考慮を含む使用可能な情報に基づいて、かけるべき認容できる呼の個数を判定する。認容できる呼は、準備ができているエージェントの呼と、キュー内の呼の差引きの後にまだ使用可能と考えられるＴＴＲエージェントの呼とを含む。
【００６３】
システムが、ステップ４０９で、かけるべき呼の公称個数に呼を追加しないと判定する場合には、ステップ４１０で、システムは、まだ顧客によって答えられていない、最後のインターバルからのダイヤルされた呼があるどうかをチェックする。システムが、ステップ４１０で、ダイヤルされた呼がないと判定する場合に、システムは、ステップ４１２で、最終的な計算された個数のアウトバウンド・コールをかける。システムが、ステップ４０９で、公称総数に呼を追加すると決断する場合には、追加される呼の個数は、所望の呼放棄パーセンテージの超過をもたらさない個数に制限される。プロセスは、ステップ４１０に移り、ここで、システムは、ダイヤルされた呼があるかどうかをチェックする。システムが、ステップ４１０で、１つまたは複数のダイヤルされた呼があると判定する場合に、システムは、ステップ４１１で、呼の許容可能なまたは許される個数とダイヤルされた呼の個数との間の差を計算する。より具体的には、システムは、許容可能なまたは許される呼の個数からダイヤルされた呼の個数を差し引く。その後、システムは、ステップ４１２で、正しい個数のアウトバウンド・コールをかける。この方法の目標は、呼放棄レートを許容できるレベルの下に保ちながらキャンペーンを担当するエージェントの時間を最適に利用するためにちょうど十分な呼をかけることである。
【００６４】
図５は、本発明の実施形態による、発呼に関するエージェントの可用性を予測するためにタイムトゥーレディ情報を更新するステップ５００を示すプロセス・フロー図である。ステップ５０１で、グループ・エージェントは、タスクでビジーである。ステップ５０２で、システムは、タスクのタイプを登録する。タスクは、呼の決まりきった性質が、完了までの予測された時間を有するステージまたはフェーズ単位で呼を定量化することを可能にする、特定のタイプの電話呼とすることができる。
【００６５】
ステップ５０３では、システムは、ステップ５０２で登録されたタスクのタイプに関するタスク・フェーズ・パラメータを得る。フェーズ・パラメータは、タスクのフェーズごとに割り当てられた時間からなる。ステップ５０４では、システムは、エージェントがタスクを行っている間に、フェーズ遷移についてエージェントを監視する。監視コンポーネントは、エージェントのワークステーション内のエージェントのコンピュータ上で実行されるエージェント・デスクトップ・アプリケーション内など、エージェントにローカルとすることができる。タスクがＣＯＳＴ呼である一実施形態では、監視コンポーネントを、コール・センタによって使用される電話交換機を制御するＣＴＩプロセッサ内で実施することができる。別の実施形態では、アウトバウンド・コール発呼インターバルにタスクでビジーな各エージェントは、そのエージェントが呼を受ける準備ができると期待される時刻をエージェント・デスクトップ・アプリケーションを介して統計サーバに報告する責任を負う。このケースでの報告する行為を、システムがアウトバウンド・コールの次のラウンドをかけることの通知の受信時に開始することができる。通知は、エージェント・デスクトップ・アプリケーション内でポップ・アップまたはトーストのグラフィックとして現れることができる。報告は、ショート・メッセージ・サービス（ＳＭＳ）メッセージまたはコンタクト・サーバおよびダイヤリング・システムによって理解され得るある他のテキスト・メッセージとすることができる。
【００６６】
一実施形態では、エージェント・デスクトップ・アプリケーションは、エージェントによる介入なしで自動的にエージェント状況を報告することを可能にされる。このケースでは、アプリケーションは、エージェントがあるタスク・フェーズから次のタスク・フェーズへ遷移する時に報告する。その後、システムは、キャンペーンを担当するすべてのビジー・エージェントについてタスクの完了までの時間を計算することができる。この実施形態の変形形態では、監視コンポーネントは、タスクの完了までの現行時間の報告を要求する照会がいつでも到着し得ることの理解と共に、エージェントがタスクでビジーになる時からエージェントがタスクを完了し、もう一度使用可能になる時までの時間を能動的に追跡することができる。このケースでは、タスク・ステージまたはタスク・フェーズが、不必要である可能性がある。タスクの完了までの時間の値は、図４で説明したＴＴＲに類似し、エージェントが準備ができる前の残っている秒数単位で表され得る。
【００６７】
監視コンポーネントは、ステップ５０５で、ビジー・エージェントについて、エージェントがフェーズを遷移しつつあるかどうかを判定する。ステップ５０５で、モニタが、エージェントがフェーズを遷移しつつあるのではないと判定する場合には、プロセスは、ビジー・エージェントについて監視するステップ５０４にループ・バックする。デスクトップ監視のケースでは、各エージェントは、彼ら自身の監視および報告システムを有する。しかし、一実施形態では、ビジーになる、キャンペーンを担当するすべてのエージェントが、ＣＴＩプロセッサまたは本発明のエージェントおよびシステムによって使用されるコンピューティング・ネットワークに接続されたある他のサーバなどの中央位置から監視される。
【００６８】
監視コンポーネントが、ステップ５０５で、エージェントがタスクのフェーズを遷移しつつあると判定する場合には、ステップ５０６で、エージェント・デスクトップ・アプリケーションが、統計サーバにフェーズ遷移を報告することができ、現在システム内にあるすべてのＴＴＲ情報をセットしまたは更新することができる。たとえば、呼は、第１フェーズが完了に推定された２０秒を要し、第２フェーズが完了に１０秒を要する、２つのフェーズを有する場合がある。第１フェーズで、ビジー・エージェントは、３０秒のＴＴＲ値を有すると報告される。第２フェーズが開始される時に、そのエージェントは、１０秒のＴＴＲ値を有すると報告される。１０秒が満了した後に、そのエージェントは、準備ができていると報告される。ステップ５０６は、キャンペーンを担当しているすべてのビジー・エージェントについて発生する。
【００６９】
ステップ５０７では、統計サーバは、アウトバウンド・コール発呼インターバルが開始されたかどうかを判定することができる。システムが、ＯＢコール発呼インターバルを開始した場合には、ステップ５０８で、システムは、ビジー・エージェントのＴＴＲが平均呼持続時間を表すしきい値（呼が答えられるまでのアウトバウンド・コール発呼の時間）以下であるかどうかを判定する。ステップ５０７は、キャンペーンを担当しているすべてのビジー・エージェントについて発生する。
【００７０】
システムが、ステップ５０７で、アウトバウンド・コーリング・インターバルを開始していない場合には、プロセスは、継続されるエージェント・タスク実行監視のためにステップ５０４に戻ると決定する。ステップ５０７で、アウトバウンド・コーリング・インターバルがシステムによって開始された場合には、これは、システムが、呼を受ける準備ができた少なくとも１つのエージェントの存在を判定したことを意味する。このケースには、ステップ５０８で、システムは、ビジー・エージェントについて報告されたＴＴＲ値をしきい値に対してチェックして、何人のＴＴＲエージェントを、呼を受け入れる準備が既にできているエージェントと考えることができるのかを判定する。ステップ５０８は、すべてのビジー・エージェントについて実行される。
【００７１】
ステップ５０８で、あるエージェントについてＴＴＲがしきい値より大きい場合に、そのエージェントは、ビジーであり、発呼の現行ラウンドに使用可能ではないと考えられる。これは、報告する各ビジー・エージェントにあてはまる。システムが、あるエージェントについて、そのエージェントのＴＴＲ値がしきい値以下であると判定する場合には、ステップ５０９で、そのエージェントが、使用可能または準備ができていると考えられ、または数えられる。本明細書では、システムが、準備ができたエージェントとＴＴＲエージェントとの間の区別を維持することに留意されたい。キューに入れられた呼があるケースでは、ＴＴＲエージェントは、その使用可能の状況が予測にすぎないので、最初に考慮から除去される。あるＴＴＲエージェントが、予測されたＴＴＲが満了してから少し後、おそらくはタスク完了に関する問題がある場合に何秒も後に、実際に使用可能になる可能性がある。そのケースでは、そのエージェントに指定された呼が、そのエージェントが使用可能になるか次のエージェントが使用可能になるのをキュー内で待つ可能性がある。エージェントは、ＴＴＲが満了する前に準備ができる場合もある。このケースでは、システムは、ＴＴＲエージェントではなく準備ができているものとしてそのエージェントを数える。
【００７２】
準備ができているまたはＴＴＲに基づいてエージェントを監視し、分類する方法を含む本発明の方法を、先を見越したチャット・キャンペーンなどの先を見越したウェブベースの招待キャンペーンで実施することができる。チャット対話の予測不能な性質のゆえに、チャット・セッションを決まりきったタスクとしてどのようにステージに分けるのかに、いくつかの相違がある可能性がある。しかし、チャットが、取引などの構造化された電話呼に類似する目的を念頭において構造化される場合に、完了までの平均時間を、経時的に査定し、チャット・セッションに割り当てることができる。エージェントと顧客との間の他の構造化された生の通信セッションを、インスタント・メッセージ会話および類似物のようにステージに分けることもできる。
【００７３】
本発明の予測的可用性判定の方法およびシステムを、本発明の趣旨および範囲から逸脱せずに、述べられた特徴およびコンポーネントの一部またはすべてを使用して提供できることは、当業者に明白であろう。上で説明された実施形態が、単一のより広義の発明の特定の例であり、この単一のより広義の発明が、教示された単一の説明のどれよりも広い範囲を有することができることも、当業者に明白であろう。本発明の趣旨および範囲から逸脱しない、この説明内で作られる多数の代替形態がある可能性がある。
【技術分野】
【０００１】
本発明は、電話通信の分野に関し、具体的には、コール・センタで対話を処理するための将来のエージェント赤さを予測する方法および装置に関する。
【背景技術】
【０００２】
電話の分野では、消費者商品および／または消費者サービスを消費者の基部に提供する会社の代わりに働くコール・センタがある。コール・センタは、遠隔通信機器と、コール・センタによって代表される１つまたは複数の会社の顧客と対話するために予約された生の個人との連合と定義することができる。
【０００３】
現行技術のコール・センタは、コネクション指向交換電話網を介する電話呼およびインターネット・プロトコル（ＩＰ）ネットワークを介するデータ・ネットワーク・テレフォニ（ＤＮＴ）呼を処理することができる。コール・センタは、通常、対話に使用されるエージェント機器をサポートするローカル・エリア・ネットワーク（ＬＡＮ）を含む。エージェント機器は、一般に、クライアント・インターフェース・アプリケーションを実行するグラフィカル・ユーザ・インターフェース（ＧＵＩ）を有するＬＡＮ接続されたコンピュータである。電話送受器または電話ヘッドセットも、顧客と対話する際にエージェントによって使用される通信機器の一部である。電話は、ＣＯＳＴ電話またはＩＰベースの電話とすることができる。
【０００４】
類似するトレーニングまたは技量を有するエージェントは、特定のコール・センタ・キャンペーンに取り組むために、いくつかのコール・センタで関連付けによって一緒にグループ化される。アウトバウンド・コーリング（ｏｕｔｂｏｕｎｄ ｃａｌｌｉｎｇ）キャンペーンは、集中的なコール・センタ・エージェントのグループを使用する、１つのそのようなキャンペーン・タイプである。アウトバウンド・コーリング・キャンペーンでは、予測された個数のアウトバウンド・コールが、通常は、リストによって提供される顧客電話番号へ自動化されたアウトバウンド・ダイヤラによってかけられる。アウトバウンド・コールは、キャンペーンの持続期間全体を通じてさまざまな期間に何回かに分けてかけられる。アウトバウンド・コンタクト・サーバによってかけられた電話に答える顧客を、処置のために着信として、使用可能なコール・センタ・エージェントにルーティングすることができる。多くの場合に、対話型音声応答（ＩＶＲ）システムが、呼に答える顧客に、次の使用可能な生きたエージェントをしばらく待つように促すために使用される。顧客が生きたエージェントに接続された後に、取引をする機会が、コール・センタのために存在する。
【０００５】
特に自動化されたダイヤリング・システムが使用される時の、アウトバウンド・コーリング・キャンペーンに関する課題の１つは、キャンペーン中の任意の所与のダイヤリング・インターバルにダイヤルすべきアウトバウンド・コールの最良の個数を予測することである。確率論が、多くの予測ダイヤリング動作で、使用可能なエージェントの人数を考慮して、アウトバウンド・コールのよい個数がどれほどであるのかを判定するのを試みるのに使用される。かけられた呼のあるパーセンテージが人間によって答えられないことの、ある確率がある。かけられ、顧客によって答えられる呼のあるパーセンテージが、キューから離脱して、放棄呼と考えられることの、ある確率がある。
【０００６】
キャンペーン中に維持されなければならない２つの主要な原理は、顧客が、生きているエージェントに接続されるために長くは待たないことと、エージェントが、次の呼を受けるためにあまりに長くは待たないことである。アウトバウンド・コール・キャンペーンに関する対話処理でのエージェント利用のより高いパーセンテージが、コール・センタ環境で望まれるが、ルーティングに使用される現在の予測アルゴリズムなどの、呼を処理するためのエージェント・レディネス（ｒｅａｄｉｎｅｓｓ）を判定する従来の手段の多くは、ビジー・エージェントが呼を受ける準備ができていると考えられる時など、エージェントの状況に関する予備情報を考慮できない。過剰なダイヤリング・レート（ｄｉａｌｉｎｇ ｒａｔｅ）が、許容できるレベルを超えて高まる可能性があり、呼放棄レートは、許容できるレベルを超えて高まり、エージェント利用パーセンテージは、より低くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、明らかに必要なものは、使用可能ではないが、アウトバンド・コールが答えられる時までに使用可能になる可能性があるエージェントの人数を考慮する、生きているエージェントに接続するためにアウトバウンド・コールをかけるシステムおよび方法である。
【課題を解決するための手段】
【０００８】
上で述べた問題は、アウトバウンド・コール・キャンペーンの対話処理でのエージェント利用のより高いパーセンテージが、コール・センタ環境で望まれるが、ルーティングに使用される現在の予測アルゴリズムなどの呼を処理するためのエージェント・レディネスを判定する従来の手段の多くが、ビジー・エージェントが呼を受ける準備ができていると考えられる時などのエージェントの状況に関する予備情報を考慮できないことである。過剰なダイヤリング・レートが、許容できるレベルを超えて高まる可能性があり、呼放棄レートは、許容できるレベルを超えて高まり、エージェント利用パーセンテージは、より低くなる。
【０００９】
したがって、本発明人らは、アウトバウンド・キャンペーンに関する過剰なダイヤル条件、より高い呼放棄レート、またはキャンペーンに関するより低いエージェント利用パーセンテージ平均を生じない形で信頼できるエージェント・レディネス予測を提供するために潜在的に利用できる予測能力を示す要素を探して、コール・センタの機能要素を検討した。
【００１０】
すべてのコール・センタ・キャンペーンは、呼負荷によって駆動され、その１つの副産物が、呼を処理する準備のできたエージェントの欠如から生じる、あるパーセンテージの切断された呼または放棄呼である。ほとんどのそのようなコール・センタは、コール・センタの仕事を行うのにアウトバウンド・コンタクト・ユーティリティおよび内部ルーティング・システムを使用し、コンタクト・サーバ、ルータ、および予測ルーティング戦略は、通常、そのような装置の一部である。
【００１１】
本発明人は、ダイヤリングの時点で、対話キューを担当するエージェントのグループについてより信頼できるエージェント・レディネス予測を達成できる場合に、大幅なエージェント利用パーセンテージ増加が生じる可能性があることを、発明的瞬間に認めた。したがって、本発明人は、エージェントに関する呼を受ける準備ができるための時間ウィンドウが、アウトバウンド・コールをかけ、内部ルーティングのために接続する時間までに一般に制限される指定された時間ウィンドウ以下である場合に、ビジー・エージェントが呼を受ける準備ができていると考えることを可能にする、コール・センタ・アウトバウンド・キャンペーンのための独自の予測ルーティング・システムを構築した。エージェント利用パーセンテージの大幅な増加が、過剰なダイヤリングに起因する呼放棄レートの増加を伴わずに、５０人以下のエージェントのグループについて生じる。
【００１２】
したがって、本発明の一実施形態では、アウトバウンド・コールを行うシステムが、提供され、アウトバウンド電話呼をかける、ネットワークに接続された第１ノードと、ネットワークに接続され、ビジーである、準備ができている、および準備ができる時間に関するエージェント状況を報告するために第１ノードにアクセス可能な第２ノードと、ネットワークに接続され、第２ノードにアクセス可能な複数のエージェント機器と、エージェント機器上ごとに１つインストールされる複数のエージェント・アクティビティ・アプリケーションとを含む。好ましい実施形態では、アウトバウンド・コールが、呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて予測される。
【００１３】
一実施形態では、アウトバウンド・コールは、電話ダイヤラを使用してダイヤルされる。一実施形態では、ネットワークは、電話網およびインターネット・ネットワークに接続されたローカル・エリア・ネットワークである。一実施形態では、第１ノードは、電話交換機を介する公衆交換電話網への接続性を有するアウトバウンド・コンタクト・サーバである。一実施形態では、第２ノードは、統計サーバである。一実施形態では、エージェント機器は、デスクトップ・コンピュータであり、エージェント・アクティビティ・アプリケーションは、デスクトップ・インターフェースである。一実施形態では、呼は、ダイヤル・アウトすべき呼の正しい個数を予測するためにエージェント可用性および保留中可用性に関する報告された情報を使用するアルゴリズムによって作られた計算結果に従って予測される。
【００１４】
本発明のもう１つの態様によれば、アウトバウンド電話キャンペーンにおいて、呼を担当するエージェントのグループを最もよく利用するためにダイヤル・アウトすべき呼の正しい個数を予測する方法が提供される。この方法は、（ａ）呼を受けるために待っている使用可能なエージェントおよび指定された時間ウィンドウ内に呼を受ける準備ができるエージェントの人数を合計するステップと、（ｂ）（ａ）の合計からエージェントのキュー内で待っている接続された呼の個数を引くステップと、（ｃ）コール・ヒット・レート（ｃａｌｌ ｈｉｔ ｒａｔｅ）および放棄呼のパーセンテージに対するパーセンテージ定数に対して（ｂ）の値を調整することによって呼の認容できる個数を予測するステップと、（ｄ）進行中の呼の個数を減算することによって（ｃ）の値をさらに洗練するステップとを含む。
【００１５】
この方法の一態様では、ステップ（ａ）で、指定される時間ウィンドウは、呼をダイヤル・アウトする点と進行中の呼が答えられ、キューに入れられる点との間の平均推定時間以下である。この態様では、ステップ（ｂ）で、待っている接続された呼は、顧客によって答えられ、使用可能なエージェントについてキューに入れられた、アウトバウンド・ダイヤルされた呼である。この態様では、ステップ（ｃ）で、コール・ヒット・レートは、人によって答えられるアウトバウンド・コールのパーセンテージである。一態様では、ステップ（ｃ）で、放棄呼は、キュー内で放棄される。この態様では、ステップ（ｄ）で、進行中の呼は、まだ答えられていない現行アウトバウンド・コールである。
【００１６】
本発明のもう１つの実施形態によれば、コール・センタに関連し、ビジーと報告される１人または複数のエージェントが、対話要求に答えるために使用可能になる時を予測するシステムが提供される。このシステムは、各機器がエージェントによって操作される、ネットワークに接続された各機器にローカルにネットワーク上に存在する監視アプリケーションと、定義されたタスクに関するエージェント進行を報告する、機器あたり１つ存在する報告アプリケーションと、監視アプリケーションから情報を受け取り、いずれかのエージェントが対話要求を受け入れる準備ができた場合にそのエージェントがどれであるのかを判定するデータ処理コンポーネントとを含む。各報告アプリケーションは、ホスティング・エージェントの現行タスク実行状態に関して監視アプリケーションに通知を送り、処理コンポーネントは、報告された状態情報に基づいて、各エージェントが対話を受ける準備ができる時刻を計算する。
【００１７】
一実施形態では、機器は、コンピュータであり、報告アプリケーションは、デスクトップ・エージェント・インターフェーシング・アプリケーションである。この実施形態では、タスクは、１つまたは複数のフェーズを有し、各フェーズは、完了までの既知の平均時間を有する。一実施形態では、通知は、ショート・メッセージ・サービス通知であり、通知内容は、タスク識別および現行フェーズ識別を含む。
【００１８】
一実施形態では、要求される対話は、生の電話対話または生のチャット・セッションである。好ましい実施形態では、データ処理コンポーネントは、ルーティング・サーバである。一実施形態では、報告アプリケーションは、エージェントのフェーズ状態を報告するために手動で操作される。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態による、アウトバウンド・コール・システムをサポートする通信ネットワークのアーキテクチャ的概要を示す図である。
【図２】本発明の実施形態による、アウトバウンド・コール発呼システムの基本コンポーネントとコンポーネント対話特性とを示すブロック図である。
【図３】類似する人数のエージェントに関する他のシステムと比較した本発明のシステムの経験的テスティングの結果を示す折れ線グラフである。
【図４】本発明の実施形態による、所与の発呼インターバルでかけるべきアウトバウンド・コールの正しい個数を予測するステップを示すプロセス・フロー図である。
【図５】本発明の実施形態による、発呼に関するエージェントの可用性を予測するためにタイムトゥーレディ（ｔｉｍｅ−ｔｏ−ｒｅａｄｙ）情報を更新するステップを示すプロセス・フロー図である。
【発明を実施するための形態】
【００２０】
本発明人らは、コール・センタ環境で呼を受けるためのエージェント可用性を予測するシステムおよび方法を提供する。本発明を、可能にする詳細において次の例で説明し、次の例は、本発明の１つまたは複数の実施形態を表すことができる。
【００２１】
図１に、本発明の実施形態による、アウトバウンド・コール・システムをサポートする通信ネットワーク１００のアーキテクチャ的概要を示す。通信ネットワーク１００は、本明細書でネットワーク・クラウド１０２およびネットワーク・クラウド１０３によって表される公衆交換電話網（ＰＳＴＮ）へのネットワーク接続性を有するコール・センタ１０１を含む。ＰＳＴＮセグメント１０２は、地理的に局所的なセグメントを表し、ＰＳＴＮセグメント１０３もそうである。ＰＳＴＮセグメント１０２および１０３は、議論のためにのみ、この例では物理的に分離されている。ネットワーク・インフラストラクチャの当業者は、物理インフラストラクチャを論じる時のネットワーク境界の曖昧さを了解するであろう。無線電話キャリア・ネットワークへの接続性をも、この例では論理的に含めることができるが、図のスペースを節約するために、それらは図示されていない。ＰＳＴＮネットワーク・セグメント１０２および１０３は、すべての電話網接続性を表さなければならない。本発明人は、その高い公衆アクセス特性のゆえにＰＳＴＮネットワークを選択する。
【００２２】
ＷＡＮ １０４は、都市域ネットワーク（ｍｕｎｉｃｉｐａｌ ａｒｅａ ｎｅｔｗｏｒｋ、ＭＡＮ）、ＷＡＮに接続された会社ＬＡＮ、またはインターネット・ネットワークを含む、私有ネットワーク、会社ネットワーク、または公衆ネットワークとすることができる。本発明人は、その高い公衆アクセス特性のゆえに、この例ではインターネット・ネットワークを選択する。本明細書のこれ以降では、ＷＡＮ １０４を、好ましい実施形態に従ってインターネット１０４と呼ぶ場合がある。しかし、本発明の実践は、インターネット・ネットワークまたはＰＳＴＮに限定されない。インターネット１０４は、本明細書でインターネット・バックボーン１２１によっても表され、インターネット・バックボーン１２１は、全体としてのインターネットを構成する回線、機器、およびアクセス・ポイントのすべてを表す。したがって、本発明の実践に対する地理的限定はない。
【００２３】
コール・センタ１０１は、その中に配置され、ネットワーク通信用のさまざまなステーションおよび機器に接続するように適合されたローカル・エリア・ネットワーク（ＬＡＮ）１０５を有する。ＬＡＮ １０５は、複数のエージェント・ステーション１０６（１〜ｎ）をサポートする。エージェント・ステーション１０６（１〜ｎ）は、一般に、この実施形態ではそれぞれデスクトップ・パーソナル・コンピュータ（ＰＣ）および電話機を含むものとして特徴付けられる。この例では、各エージェント・コンピュータは、ＬＡＮ接続され、各電話機は、内部電話配線によってＰＳＴＮセグメント１０２内のローカル電話交換機（ＬＳ）１１９に接続される。電話交換機１１９を、ＡＣＤ（ａｕｔｏｍａｔｅｄ ｃａｌｌ ｄｉｓｔｒｉｂｕｔｏｒ）とすることができる。一実施形態では、ＬＳ １１９を、構内交換機（ＰＢＸ）交換機とすることができる。ＬＳ １１９を、本発明の趣旨および範囲から逸脱せずに、コール・センタ１０１の物理ドメイン内で維持し、電話局交換機として管理することができる。この例では、交換機は、ネットワーク内に設けられ、コール・センタによって賃貸される。
【００２４】
ＬＳ １１９は、ＣＴＩ（ｃｏｍｐｕｔｅｒ ｔｅｌｅｐｈｏｎｅ ｉｎｔｅｇｒａｔｅｄ）プロセッサ１０９によってインテリジェント・ルーティングおよびカスタマ・インターフェースについて機能強化され、ＣＴＩプロセッサ１０９は、対話型音声応答ユニットのインスタンスをもサポートする。ＣＴＩプロセッサ１０９は、コール・センタ１０１の側でＬＡＮ １０５に接続され、ＣＴＩリンクによってＬＳ １１９に接続される。複数のコール・センタ電話連絡先１２０（１〜ｎ）が、ＰＳＴＮ １０２内に図示されている。本明細書で電話機アイコンによって表される電話連絡先１２０（１〜ｎ）は、センタに連絡することができるか電話を使用してセンタが連絡できる、コール・センタ１０１のすべての顧客を表す。一実施形態では、電話連絡先１２０（１〜ｎ）は、アウトバウンド・コール・センタ・キャンペーンの一部としてコール・センタ１０１によって作られるアウトバウンド連絡先である。
【００２５】
ＰＳＴＮセグメント１０３は、ローカル電話交換機ＬＳ １２５を含む。ＬＳ １２５は、インターネット・ネットワーク１０４へのインターネット・アクセスを得るのに使用できる、ＰＳＴＮネットワーク内の任意の電話交換機を表す。電話交換機１２５は、電話幹線を介してＬＳ １１９に接続される。複数のアウトバウンド招待客１２７（１〜ｎ）は、インターネット・サービス・プロバイダ（ＩＳＰ）１２６を介するＬＳ １２５へのインターネット・アクセス回線を介するインターネット・バックボーン１２１へのアクセスを有する、コール・センタ１０１のウェブ接続された顧客を表す。招待客１２７（１〜ｎ）は、論理的には動作するデスクトップ・パーソナル・コンピュータ（ＰＣ）として特徴付けられるが、スマート・ホン、携帯情報端末（ＰＤＡ）、ラップトップ機、またはある他のネットワーク対応機器などの任意のインターネット対応電子機器を使用してインターネット１０４へのアクセスを得ることができる。この例では、用語招待客は、コール・センタ１０１から送信された招待がコール・センタとの対話に参加するために招待客１２７（１〜ｎ）のいずれかによって受信され得る、招待の状態を表す。一実施形態では、招待される対話は、オンライン・チャットである。
【００２６】
招待客１２７（１〜ｎ）を、インターネット１０４内に図示され、バックボーン１２１に接続されたウェブ・サーバ（ＷＳ）１２２にオンラインで接続することができる。ＷＳ １２２は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＷＳ １２２は、ユニバーサル・リソース・ロケータおよびさらにウェブ・ブラウジングによって情報にアクセスする接続されたクライアントに、ウェブ・ページ情報を含む電子情報を供給する。各コンピュータを、当技術分野で既知のようにウェブ・ブラウザを使用してインターネット１０４に接続されると仮定することができる。この例では、ＷＳ １２２は、コール・センタ１０１の会社ウェブ・サイト（図示せず）をホスティングし、この会社ウェブ・サイトには、顧客がコンピューティング機器１２７（１〜ｎ）から操作することによってアクセスすることができる。招待客１２７（１〜ｎ）は、ＩＰ音声テレフォニを実践するためのヘッドセットを含むインターネット・プロトコル（ＩＰ）音声アプリケーションをも備える。ＩＰベースのＩＶＲプラットフォーム１２３は、コール・センタ１０１に包括的な会社ウェブ・サイト上でホスティングされ、その結果、コール・センタは、当技術分野で明確に確立される音声認識技術を使用して、招待客１２７（１〜ｎ）および任意の他のコンピュータ・ネットワーク顧客と対話できるようになる。
【００２７】
チャット・サーバ（ＣＨＳ）１２４は、インターネット１０４内に図示され、バックボーン１２１に接続される。ＣＨＳ １２４は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。チャット・サーバ１２４は、１つまたは複数の顧客およびコール・センタ１０１からの１つまたは複数のエージェントを含む電子チャット・セッションをホスティングする。チャット・サーバ１２４を、コール・センタ１０４によってホスティングすることができ、あるいは、コール・センタ１０４によって賃貸し、またはこれにサブスクライブすることができる。リンクを、チャットのためにＷＳ １２２内でホスティングされるコール・センタ１０１のウェブ・サイト上に設けることができ、このリンクは、顧客をサーバ１２４にリダイレクトすることができる。招待客１２７（１〜ｎ）に、彼らに電子的に送信されるアウトバウンド招待を介してまたはＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）によって、チャットするように招待することができる。この例では、招待客１２７（１〜ｎ）のインターネット接続性は、ＩＳＰ １２６と、ＰＳＴＮを介する電話接続性とを介して提供される。インターネット・アクセスの方法を、サービス総合ディジタル網（ＩＳＤＮ）、ディジタル加入者回線（ＤＳＬ）、無線ブロードバンド、Ｔ−Ｘネットワーク接続、ケーブル・モデム、衛星サービス、または類似物とすることができる。
【００２８】
本明細書では、アウトバウンド連絡先１２０（１〜ｎ）およびアウトバウンド招待客１２７（１〜ｎ）が、コール・センタ１０１によって、またはコール・センタによってホスティングされるある対話への懇請の目的によって、連絡をとられたコール・センタ１０１の顧客を表すことに留意されたい。コール・センタ１０１から開始されるアウトバウンド連絡は、アウトバウンド電話連絡キャンペーンの形または電子的に受信される招待の形をとることができる。アウトバウンド音声連絡を、ＣＯＳＴ（ｃｏｎｎｅｃｔｉｏｎ ｏｒｉｅｎｔｅｄ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｙ）連絡またはＶｏＩＰ呼を含むＩＰＮＴ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｎｅｔｗｏｒｋ Ｔｅｌｅｐｈｏｎｅ）呼とすることができる。
【００２９】
コール・センタ１０１内のＬＡＮ １０５は、インターネット・プロトコル・ルータ（ＩＲ）１１１をサポートする。ＩＲ １１１は、実行可能ソフトウェアを格納し、ルータ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＩＲ １１１は、ＬＡＮ １０５にインターネット接続性を提供する。ＩＲ １１１は、両方向の音声呼、チャット、および電子メッセージングをサポートする。ＬＡＮ １０５は、インターネット・プロトコル上の転送制御プロトコル（ＴＣＰ／ＩＰ）のために機能強化される。ＬＡＮ １０５は、アウトバウンド・コンタクト・サーバ（ＯＣＳ）１１４をサポートする。ＯＣＳ １１４は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＯＣＳ １１４は、コール・センタ１０１の代わりにアウトバウンド電話呼をかけるための自動電話ダイヤラ（図示せず）を備える。ＯＣＳ １１４は、自動化されたダイヤリング・ソフトウェアを介してＣＯＳＴ呼をかけることができる。ＯＣＳ １１４を、アウトバウンド連絡先１２０（１〜ｎ）に電話をかけるためにアウトバウンド・コール・キャンペーン中に使用することができる。一実施形態で、ＯＣＳ １１４は、アウトバウンド招待客１２７（１〜ｎ）にＩＰベースのアウトバウンド音声呼をかけるように機能強化される。
【００３０】
統計サーバ（ＳＳ）１１２は、コール・センタ１０１内に図示され、ＬＡＮ １０５に接続される。ＳＳ １１２は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＳＳ １１２は、キュー内の推定待ち時間（ｅｓｔｉｍａｔｅｄ ｗａｉｔｉｎｇ ｔｉｍｅ、ＥＷＴ）およびエージェント・ステーション１０６（１〜ｎ）から働くエージェントの現行可用性状態などのリアル・タイム統計を含むコール・センタ動作に関連する統計をコンパイルするように適合される。統計リポジトリ１１３は、設けられ、別々のデータ・リンクを介してサーバ１１２に接続される。センタで働くエージェントの現行状況を、ＳＳ １１２に報告し、アクセスのためにリポジトリ１１３に格納することができる。
【００３１】
エージェント・コンピュータは、エージェント・デスクトップ（ＡＤＴ）アプリケーション１０７を備える。１つのそのようなアプリケーションが、ステーション１０６（１〜ｎ）内の各コンピュータ上に図示されている。ＡＤＴ １０７は、エージェントがコール・センタ・システムおよびアプリケーションに接続し、ログ・インすることを可能にし、また、特定の通信能力およびルーティング能力をエージェントに提供する。この実施形態では、ＡＤＴ １０７は、報告能力を有して機能強化され、この報告能力では、アプリケーションが、通信中およびコール・センタ動作中に特定のエージェントの状態を監視し、報告することができる。たとえば、あるエージェントが、電話呼を受け入れる準備ができた場合に、ＡＤＴ １０７は、その状態をＳＳ １１２に報告する。エージェント電話キュー１０８は、コール・センタ１０１内に図示され、ＬＡＮ １０５に接続される。エージェント・キュー１０８は、エージェント・ステーション１０６（１〜ｎ）で働くエージェントによって共有されるキューを表す。エージェント・キュー１０８は、生の支援を待っているＣＯＳＴテレフォニ・イベントとデータ・ネットワーク・テレフォニ（ＤＮＴ）イベントとの両方を表すように適合された仮想キューとすることができる。
【００３２】
ＬＡＮ １０５は、ＵＲＳ（ｕｎｉｖｅｒｓａｌ ｒｏｕｔｉｎｇ ｓｅｒｖｅｒ）１１６をサポートする。ＵＲＳ １１６は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＵＲＳ １１６上の実行可能ソフトウェアは、ルーティング・ソフトウェア（ＳＷ）１２８を含む。ＵＲＳ １１６は、ＣＯＳＴ対話とＤＮＴ対話との両方をサポートする。ＵＲＳは、コール・センタ１０１内の対話を適当なエージェントおよびシステムにルーティングするのに使用されるインテリジェント・ルーティング戦略を提供する。たとえば、生の支援を要求するＬＳ １１９を本拠とする呼は、内部的にＵＲＳ １１６からの命令に基づいてルーティングされる。ＵＲＳ １１６は、現行状態情報のためにＳＳ １１２にサブスクライブすることができる。ＣＴＩプロセッサ１０９は、交換機で受信される着信ごとにルーティング命令のためにＵＲＳ １１６を呼び出す。
【００３３】
ＬＡＮ １０５は、招待（ＩＮＶ）サーバ１１７をサポートする。ＩＮＶ １１７は、実行可能ソフトウェアを格納し、サーバ機能を使用可能にするために必要なデータを格納するためにそれにアクセス可能なディジタル媒体を含む。ＩＮＶ １１７は、たとえばチャット・セッションなどのコール・センタ１０１と対話に参加するようにウェブ・ページ訪問者に勧誘するそのウェブ・ページ訪問者へのアウトバウンド招待を生成するように適合される。この能力は、本発明人に既知であり、関連しない特許出願の対象である。ＰＳＴＮセグメント１０２は、ネットワーク・ゲートウェイ１１０によってインターネット１０４にブリッジされる。このゲートウェイは、２つのネットワークの間で音声通信をブリッジするＳＳ−７または他の既知のゲートウェイとすることができる。
【００３４】
本発明の好ましい実施形態では、コール・センタ１０１は、アウトバウンド・コーリング・キャンペーンに着手することができ、ここで、連絡先１２０（１〜ｎ）などのアウトバウンド連絡先は、電話によって連絡され、コール・センタのエージェントとのある音声対話にかかわるように懇請される。ＯＣＳ １１４上で実行されるＳＷ １１５として本明細書で図示されたペーシング・アルゴリズムは、各ダイヤリング・インターバルに、人間によって答えられたアウトバウンド・コールを着信として接続された呼を受けるのに使用可能なエージェントに効果的に分配するために、何回のアウトバウンド・コールをかけるべきかを判定する。
【００３５】
アウトバウンド・キャンペーン中の任意のダイヤリング・インターバルにかけるべきアウトバウンド・コールの個数を判定するための考慮事項は、コール・センタ１０１のサービス品質（ＱｏＳ）目標を満足することを含む。たとえば、使用可能なエージェントが、呼の間にあまりに長く待たないことが好ましい。顧客が、使用可能なエージェントをあまりに長く待たないことも好ましい。したがって、ＯＣＳ １１４が、どのダイヤリング・インターバルにも少なすぎるまたは多すぎる呼をかけないことが重要である。これは、部分的には、電話をかける時にキャンペーンを担当するエージェントの可用性を知ることによって達成される。アウトバウンド・コールがかけられる時に人間が電話に答える確率（ヒット・レート）など、考慮すべき変数もある。この確率は、ダイヤリング・インターバル中にかけられるすべての呼のパーセンテージとして表される。コール・センタの目標は、低く、比較的一定の呼放棄レートを有することである。たとえば、少なすぎるエージェントについて多すぎる呼がかけられ、接続される場合に、顧客があまりに長くエージェントを待ったので放棄される呼のパーセンテージは、許容できないレベルまで上昇する可能性がある。したがって、過剰なダイヤリングは、ダイヤリング・インターバル中にかけられるすべての呼のおそらくは５％など、最低限に保たれなければならない。
【００３６】
本発明人に既知の通常のアウトバウンド・コール・キャンペーンでは、アウトバウンド・コンタクト・サーバは、呼を受けるのに既に使用可能と判定されるエージェントの人数についてのみ電話をかける。本発明のシステムは、システムが、既に使用可能なエージェントを考慮することと、かけられた電話が答えられ、内部的にルーティングされる時に、ビジーである何人のエージェントが呼を受けるのに使用可能になるのかを電話をかけることの決定点から予測することとを可能にする、独自の機能強化を提供する。正確な予測を達成するために、ＡＤＴアプリケーション１０７は、エージェント・タスクを監視する能力で機能強化される。
【００３７】
エージェント・タスクは、各フェーズが平均処理時間または平均処理持続時間を有する、タスク・フェーズの適用によって定量化される。たとえば特定のタイプ販売の電話呼などのタスクは、複数のフェーズを有する可能性がある。フェーズは、タスクが実行されるたびに繰り返され、通常は秒単位で表される平均持続時間を有する、タスクの一部と定義することができる。販売呼は、たとえば４０秒の平均持続時間を有する可能性がある。エージェントは、第１フェーズで製品情報をコンパイルし、第２フェーズ中に注文量を確認し、クレジット・カード番号をとり、その後、最終フェーズで電子領収書および出荷注文を生成するために注文を処理しなければならない可能性がある。各フェーズが、タスク全体について４０秒のうちのある分割という平均持続時間を有する可能性がある。
【００３８】
ＡＤＴ １０７は、すべてのフェーズ遷移でリアル・タイムでＳＳ １１２に自動的に報告することができる。たとえば、指定されたタスクのフェーズ１で、エージェントは、呼を受け入れる準備ができるまでに４０秒を有する。そのタスクのフェーズ１とフェーズ２との間の遷移で、エージェントは、呼を受け入れる準備ができたと考えられ得るようになる前に２０秒を有する可能性がある。そのタスクの第２フェーズと最終フェーズとの間の遷移点で、エージェントは、呼を受け入れるのに使用可能と考えられ得るようになる前に１０秒だけを有する可能性がある。予備エージェント状態情報が重要であるのは、アウトバウンド・キャンペーン中に実行されるダイヤリング・インターバルの点から、そのインターバル中にダイヤルされる呼が顧客によって答えられる前に非常に多くの秒数が経過するからである。この時間の長さは、ダイヤリング・インターバルごとに平均をとられ、呼をダイヤルする点で、ＳＷ １１５によって支援されるＯＣＳ １１４が、ＵＲＳ １２８からまたは直接にＳＳ １１２から既に使用可能なエージェントの人数を得るようになる。その後、ＯＣＳ １１４は、かけられた呼が答えられ、キューに接続される時に使用可能であると予測されるビジー・エージェントの人数を入手する。
【００３９】
その後、答えられた呼は、キャンペーンを担当するエージェントのグループに関する着信として扱われ、ＳＷ １２８によって支援されるＵＲＳ １１６によって、使用可能なエージェントにルーティングされる。呼が答えられる時までの複数のビジー・エージェントの可用性を予測することによって、放棄レートを超えずに、より多くの呼をかけ、成功してルーティングすることができる。本発明の一実施形態では、予測アルゴリズムは、ＯＣＳ １１４上でＳＷ １１５として実行され、ＳＳ １１２は、リポジトリ１１３内に現行統計のすべてを保つ。このアルゴリズムは、電話呼の別の束を加えるとシステムが決定するたびに点火する。既に呼を受け入れる準備ができていると判定されるエージェントは、呼を待っており、答えられた呼が着信として彼らにルーティングされるまでビジーではないエージェントである。準備ができると予測されるエージェントは、システムによる発呼から呼応答およびエージェントへの内部ルーティングまでの平均時間ウィンドウ以下の残りタスク時間を有するビジー・エージェントである。
【００４０】
本発明の一実施形態では、この予測方法は、たとえばチャットなどのある対話への参加のアウトバウンド・ウェブ招待に使用される。この実施形態では、ＩＮＶサーバ１１７は、ＷＳ １２２内でホスティングされる会社ウェブ・サイトをブラウズしているのを検出された招待客１２７（１〜ｎ）などのウェブ連絡先への招待を生成する。この実施形態では、ステーション１０６（１〜ｎ）で働くエージェントは、そのエージェントとチャット招待を受け入れる招待客との間でセット・アップされるチャット・セッションに入る準備ができている。このケースでの変数は、ＳＷ １１８によって支援される招待システム（ＩＮＶサーバ１１７）が、チャット・セッションに参加するためのエージェントの予測された可用性に基づいて送出される招待の数を決定するという点で、アウトバウンド電話連絡に似ている。テレフォニ法とウェブ招待法との間の１つの相違は、エージェントがＡＤＴアプリケーション・チャット・インターフェース内で同時に複数のチャット・ウィンドウを実行することができると仮定して、１人のエージェントが複数の受け入れられたチャット招待について使用可能と考えられ得ることとすることができる。
【００４１】
ヒット・レートは、チャット招待の受け入れについて計算され、平均をとられる。放棄レートを、チャット・セッションが招待客のために開始される前にキュー内の高いＥＷＴに起因してネットワークから外れた、チャット招待を受け入れた招待客のパーセンテージと定義することができる。このケースのアルゴリズムは、ＳＷ １１８としてＩＮＶサーバ１１７上で実行される。ＡＤＴアプリケーション１０７は、ビジーまたは非ビジーに関するエージェント状況を、招待が送出される時にチャットに既に使用可能なエージェントについてＳＳ １１２に報告する。これらのエージェントは、準備ができていると考えられ、送出されたチャット招待の受け入れに基づいてチャット・セッションのために予約される。招待が受け入れられる時までに準備ができると予測されるビジー・エージェントは、これらのエージェントについて残っているタスク時間が、招待が送出された時に始まりこれらの招待が答えられると予想される時に終わる指定された時間ウィンドウ内である場合に、システムによって準備ができていると考えられる。ヒット・レートなどの変数が、招待客によって答えられる送信された招待のパーセンテージを予測するために計算される。招待が無視されるか断られる確率要因は、たとえばビジー、機械によって答えられる、答えられない、答えられたが断られたなど、電話連絡先に関する確率変数に似て平均ヒット・レートに算入される。
【００４２】
ＯＣＳ １１４は、ＣＴＩプロセッサ１０９およびＬＳ １１９の経路を介する連絡先１２０（１〜ｎ）へのアウトバウンド電話呼をダイヤルすることができる。一実施形態では、ＯＣＳ １１４は、ＬＳ １１９および連絡先１２０（１〜ｎ）へのゲートウェイ１１０を介するＩＲ １１１の経路を介して呼をダイヤルする。ＳＷ １１８によって支援されるＩＮＶサーバ１１７は、ＩＲ １１１を介してＷＳ １２２にチャット招待を送信する。本発明の一実施形態では、チャット招待は、音声ブラウザを使用してウェブ・サイトをブラウズしているかＩＰボイス・テレフォニ・アプリケーションを使用してウェブ・サイト（ＩＰ／ＩＶＲプラットフォーム１２３）と対話している招待客への合成された音声招待としてＩＰ／ＩＶＲプラットフォーム１２３を介して作られた音声プロンプト招待として含まれる。一実施形態では、ＯＣＳ １１４は、アウトバウンド・コーリング・キャンペーン中に単一のダイヤリング・インターバルでＣＯＳＴ呼とＩＰテレフォニ呼との両方をかけることができる。このケースでは、一方はかけられたＣＯＳＴ呼、他方はかけられたＩＰ呼に関する、２つの平均をとられる回答までの時間ウィンドウがある可能性がある。エージェントにルーティングされる着信を、すべて、一実施形態では電話機によって処理することができる。別の実施形態では、ＩＰ呼は、コンピュータ・テレフォニ・アプリケーションを介して答えられ、ＣＯＳＴ呼は、電話機によって処理される。
【００４３】
図２は、本発明の実施形態による、アウトバウンド・コール発呼システムの基本コンポーネントとコンポーネント対話特性とを示すブロック図である。エージェント・デスクトップ・アプリケーション（ＡＤＴ）２００が、この例では、アウトバウンド・キャンペーンで働く１２人のコール・センタ・エージェントのエージェント番号１について図示されている。ＡＤＴ ２００は、図１のＡＤＴ １０７に類似する。エージェント番号１は、タイプ取引の電話呼と定義されるタスク２０４でビジーと考えられる。この例では、完了まで平均５秒のフェーズ１、平均１０秒で完了されるフェーズ２、および平均１０秒で完了されるフェーズ３を含む３フェーズとしての電話呼。この例では、タスク持続時間全体が、２５秒である。アウトバウンド・コールの発呼からのこれらの呼に答えるのに要する時間が２５秒を超える場合には、アウトバウンド・ダイヤリング・インターバルの初めにタイプ取引の電話呼で現在ビジーであるすべてのエージェントが、呼を受け入れる準備ができると予測される。
【００４４】
ＡＤＴ ２００は、エージェント状況をリアル・タイムでＳＳ ２０１に報告する。ＳＳサービス２０１は、ＳＳサーバ１１２およびＳＷ １１３に類似する。この小さいエージェント・グループで働く１２人のエージェントがいる。エージェント１〜１２のうちで、ＳＳは、呼を受けるために既に使用可能である、これらのエージェントのうちの２人を数える。呼を受けるのに既に使用可能と考えられるエージェント７および１２がいる。たとえば、エージェント７および１２は、呼を受け入れるために既に使用可能であるものとすることができ、エージェント１は、呼を受け入れる準備ができると予測されるものとすることができる。この例では、エージェント１は、ビジーであるが、タイプ取引の電話呼のタスクのフェーズ３に入っている。
【００４５】
この例では、図１のＵＲＳ １１６に類似するルーティング・サービス２０２は、アウトバウンド・コンタクト・サービス２０３の代わりに統計サービスから情報を得、アウトバウンド・コンタクト・サービス２０３は、図１のＯＣＳ １１４に類似する。好ましい実施形態では、この方法は、既に準備ができているエージェントの人数に、答えられた呼のある最小ダイヤル持続時間より早く準備ができるエージェントの人数を加え、キューに入れられた呼の数を引いたものと定義される、使用可能なエージェントの人数の計算を含む。キューに１つの呼があり、したがって、準備ができると予測された第３のエージェントが、キューに入れられた呼によって打ち消され、２人の準備ができたエージェントが残される。
【００４６】
この方法は、放棄呼の所望のパーセンテージを超えずに使用可能なエージェントの人数およびヒット・レシオの推定値についてダイヤルできる、アウトバウンド・コールの認容できる個数の計算をも含む。最終的に、この方法は、ダイヤルできる予測呼の個数を予測する。ダイヤルされなければならない予測呼の個数は、アウトバウンド・コールの認容できる個数と、かけられたがまだ答えられていない呼と定義されるダイヤルされた呼の個数との間の差である。
【００４７】
ここで戻って図２を参照すると、３人の準備のできたエージェント（２人は準備ができ、１人は予測された）がいる。キュー内の１つの呼を引いて、２人の準備のできたエージェントが残される。予測されたエージェントおよびキュー内の単一の呼が、打ち消し合う。かけられた呼の発呼から応答までの持続時間は、この例では１０秒である。ヒット・レシオ（答えられる呼）は、５０％である。呼の許容できる放棄レートは、１０％である。８％の現行放棄レシオを仮定すると、使用可能なエージェントの人数は２である（２人の準備ができたエージェント＋第３のエージェント−１つのキューに入れられた呼）。
【００４８】
かけることのできる呼の認容できる個数は、３つの呼である。このカテゴリの呼を追加することの背後にある論理は、放棄呼の期待されるパーセンテージが８％である（１０％の許容されるレート未満）であることに基づく。このケースでは、放棄呼の確率は、定数１２．５％÷答えられる呼の平均値すなわち１．５（１２．５％÷１．５）＝８．３３％である。ある呼は、３つの認容できる呼というこの例で１２．５％の確率で放棄され得る。答えられる呼の期待される平均値は、１．５（３つの認容できる呼×０．５）である。
【００４９】
この例では、アウトバウンド・コンタクト・サービスは、ダイヤルされたがまだ答えられていない１つの呼があるので、２つの呼をかける。３つの認容できる呼−１つのダイヤルされた呼＝かけられるべき予測呼の個数＝２つの予測呼。呼の認容できる個数が、３つの呼ではなく４つの呼である場合には、放棄呼の期待されるパーセンテージは、１０％という最大の許容できるパーセンテージより大きい。この例では、我々は、エージェント１が、平均呼持続時間（１０秒）としてシステムによって課せられる時間限度またはそれ以内に呼を受ける準備ができるという予備情報を有する。ビジー・エージェントの予備情報がなければ、ダイヤルされなければならない呼の予測個数は、０である。このケースでは、第３のエージェントは、１０秒で使用可能になった後に、呼を通常より長く待つはずである。
【００５０】
本発明の一実施形態では、放棄呼の期待される個数は、答えられた呼の個数から使用可能なエージェントの人数を引いたものと等しい。その差が０より大きい場合には、使用可能なエージェントの人数は２である。この例では、答えられる呼の平均個数、放棄呼の平均個数、および放棄呼の期待されるパーセンテージが、ダイヤラによってかけられる呼の個数に基づく依存する形で表される。３つの呼について、５０％のヒット・レシオ（答えられる呼のパーセンテージ）を与えられれば、答えられる呼の平均個数を、３＊｛ｐ＊（１−ｐ）２｝＊１＋３＊｛ｐ２＊（１−ｐ）｝＊２＋ｐ３＊３＝１２＊０．１２５＝１．５として表すことができる。放棄呼の平均個数を、ｐ３＊１＝０．１２５として表すことができる。放棄呼の期待されるパーセンテージを、０．１２５／１．５＊１００％＝８．３％として表すことができる。したがって、３つの認容できる呼について、放棄呼の期待されるパーセンテージは、１０％というこの例での許容限度より小さい。
【００５１】
上のパラメータを与えられて、ダイヤラが、４つの呼を試みる場合には、答えられる呼の平均個数は、４＊｛ｐ＊（１−ｐ）３｝＊１＋６＊｛ｐ２＊（１−ｐ）２｝＊２＋４＊｛ｐ３＊（１−ｐ）｝＊３＋ｐ４＊４＝３２＊０．０６２５＝２として表される。放棄呼の平均個数は、４＊｛ｐ３＊（１−ｐ）｝＊１＋ｐ４＊２＝６＊０．０６２５＝０．３７５として表される。放棄呼の期待されるパーセンテージは、０．３７５／２＊１００％＝１８．７５％になる。期待される呼放棄レートは、１０％という許容できる最大値より大きい。発呼の条件は、期待される呼放棄パーセンテージが、比較的低い許容可能レベル、この例では１０％を超えてはならないということである。この例では、２つの呼がかけられる。というのは、可能性が、１つの呼だけが、顧客が呼に答える時に準備ができる第３のエージェントにルーティングされることであるからである。
【００５２】
本発明の好ましい実施形態では、アウトバウンド・ダイヤリング・サーバは、５０人以下のエージェントを利用するキャンペーンでかけるべきアウトバウンド・コールの正しい個数を判定するためにこの予測方法を使用する。このタイプのエージェント・グループは、小さいグループと考えることができる。
【００５３】
図３は、類似する人数のエージェントに関する他のシステムと比較した本発明のシステムの経験的テスティングの結果を示す折れ線グラフ３００である。グラフ３００は、発呼を予測する異なる方法を使用する別々のアウトバウンド・キャンペーンを担当するエージェントの平均エージェント利用係数または「ビジー係数」をプロットするものである。使用されるエージェントの最大人数は、５０であり、これは、エージェントの小さいグループを示す。テストのすべてについて、ヒット・レシオ＝０．３である（回答確率＝０．３、無回答確率＝０．５、ビジー確率＝０．２）。呼持続時間は、約４０秒になる。比較に関するパラメータは、パーセンテージとして表された、グループ内のエージェントのビジー係数である。
【００５４】
５人から５０人までのエージェントの小さいグループについて、本発明人に既知であり、曲線３０２をプロットするために星アイコンを使用して本明細書で図示されるプログレッシブ・ダイヤリング（ｐｒｏｇｒｅｓｓｉｖｅ ｄｉａｌｉｎｇ）法は、５０人までのエージェントのすべての小さいグループ数について、プロットされた結果の曲線３０２によって示されるように、比較的平らなままである。平均エージェント・ビジー係数は、選択された小さいグループについて約５５％で比較的低いままである。小さいグループに関する方法は、より効果的であり、本明細書では、結果の曲線３０３のプロット内で円を使用して図示されている。この方法は、約５人のエージェントについて６２％のビジー係数を返す。曲線３０３は、より多くのエージェントに伴って安定して上昇し、５０人のエージェントのグループについて７０％のビジー係数を達成する。一般予測法として分類され、本明細書で四角アイコンによって図示される１つの方法は、エージェントのより小さいグループについて非常に悪い性能を有し、３５人と５０人との間のエージェントのエージェント・グループについてはるかによい性能を有する結果曲線３０４を作る。５人のエージェントについて、この方法は、エージェントの４５％未満のビジー係数をもたらす。このパーセンテージは、２０人のエージェントで６０％、３５人のエージェントで８０％、５０人のエージェントで８５に上昇する。この方法は、エージェントのより少ない人数ではるかに信頼できない。
【００５５】
本発明人に既知であり、本明細書で六角形によって図示されるエージェント・スモール・グループ（ａｇｅｎｔ ｓｍａｌｌ ｇｒｏｕｐ、ＡＳＧ）法は、結果曲線３０５を作る。曲線３０５は、５人のエージェントから２０人のエージェントへ劇的に上昇し、２０人のエージェントのグループについて７５％のビジー係数を達成する。２０人のエージェントの小さいグループについて７５％エージェント・ビジー係数に上昇した後に、この方法は、平坦になり、ビジー係数は、５０人のエージェントのグループ・サイズまで平坦なままになる。
【００５６】
フィードバック（ビジー・エージェントの予備可用性予測）を伴うエージェント・スモール・グループ（ＡＳＧ）の本発明の方法は、結果曲線３０６を作る。わずか５人ほどのエージェントもの非常に小さいエージェント・グループについて、エージェント・ビジー係数は、約７２％である。この曲線は、３人から４０人のエージェントまでのより大きいグループについて劇的に上昇し、４０人では、エージェントのビジー係数は約８３％である。５０人のエージェントについて、一般予測法は、８３％と比較して約８５％というエージェントに関するわずかにより高いビジー係数をもたらす。しかし、本発明の方法は、４５人未満のエージェントのエージェント・グループについて、一般予測法および他の既知の方法のすべてをしのぐ。エージェントに関するより高いビジー係数は、エージェントがキャンペーン中によりよく利用されることを意味する。
【００５７】
図４は、本発明の実施形態による、アウトバウンド・コール・キャンペーン中の所与の発呼インターバルでかけるべきアウトバウンド・コールの正しい個数を予測するステップ４００を示すプロセス・フロー図である。ステップ４０１で、システムは、アウトバウンド・コールをかけるべきか否かを判定する。この判定は、リアル・タイム統計から入手されるエージェントの可用性情報に基づいて行うことができる。システムが、コールをかけないと決断する場合には、このプロセスは、ステップ４０１でシステムによってコールをかける決定が行われるまで、ループ・バックする。
【００５８】
ステップ４０２で、システムは、既に呼を受ける準備ができている、キャンペーンを担当するエージェントして定義された準備ができているエージェントの人数を得る。次に、システムは、ステップ４０３で、考慮すべきタイムトゥーレディ（ＴＴＲ）エージェントがいるかどうかを判定する。ＴＴＲエージェントは、顧客がシステムによってかけられた呼に答えるのに要する時間（呼持続時間）以下の指定された時間フレーム内に準備ができたエージェントになるビジー・エージェントである。たとえば、ＴＴＲエージェントは、呼持続時間が１５秒の場合に、１０秒で使用可能になるものとすることができる。そのエージェントは、発呼について準備ができたエージェントと共に使用可能と考えられる。１５秒より長い時間を有するＴＴＲエージェントは、現行の発呼インターバルについて使用可能とは考えられない。
【００５９】
一実施形態では、エージェント自体が、保留中の発呼インターバルの通知を受信した時に、統計に手動で報告する。この例では、エージェントは、ＴＴＲ値を推定し、これをエージェント・デスクトップ・アプリケーションを介して報告する。別の実施形態では、ＡＤＴアプリケーションが、平均完了時間を割り当てられたタスク・ステージまたはフェーズに対するエージェント状態を監視するように機能強化される。この例では、エージェント・デスクトップは、エージェントが現行タスクのあるフェーズから別のフェーズに遷移するたびに、統計サーバに自動的に報告する。システムは、エージェントのタスクが完了する前にどれほどの時間が残されているのかを、使用可能なデータ（フェーズ１＝１０秒、フェーズ２＝１０秒など）から知る。
【００６０】
ステップ４０３で、現行発呼インターバルについて考慮すべきＴＴＲエージェントがないとシステムが判定する場合には、システムは、ステップ４０５で、準備ができているエージェントの人数を持ち越す。システムが、ステップ４０３で可用性の考慮の資格があるＴＴＲエージェントを見つける場合には、システムは、ステップ４０４で、準備ができたエージェントと資格を与えられたＴＴＲエージェントとの合計を計算する。ステップ４０６では、システムは、ＴＴＲエージェントが考慮されたか否かにかかわらず、キュー内に呼があるかどうかを調べる。ステップ４０６で、キュー内に現在は呼がない場合には、システムは、使用可能なエージェントの人数から数を減算する必要がない。ステップ４０８では、システムは、放棄呼の現行％が許容される最大パーセンテージ未満であるかどうかを知るために放棄呼の現行％をチェックすることができる。
【００６１】
システムが、ステップ４０６で、最後の発呼インターバルからのエージェントに関するキューに１つまたは複数の呼があると判定する場合に、システムは、使用可能なエージェントとキュー内の呼（１つまたは複数）との間の差を計算する。より具体的には、システムは、キュー内の呼の個数に基づいて、総数からＴＴＲエージェントの個数を差し引く。キューに１つの呼がある場合には、システムは、１つのＴＴＲエージェントを差し引くか打ち消す。考慮すべきＴＴＲエージェントがない場合には、システムは、準備ができているエージェントを考慮から除去する。本明細書では、ＴＴＲエージェントの場合に、複数のＴＴＲエージェントがあるならば、システムが、最大のタイムトゥーレディ数を有するＴＴＲエージェントを除去することに留意されたい。プロセスは、ステップ４０７からステップ４０８に移り、ここで、システムは、許容可能なしきい値に対して呼放棄パーセンテージをチェックする。
【００６２】
ステップ４０９では、システムは、準備ができたエージェントに関するかけるべき呼の公称個数に呼を追加すべきかどうかを判定する。システムは、呼放棄パーセンテージの考慮を含む使用可能な情報に基づいて、かけるべき認容できる呼の個数を判定する。認容できる呼は、準備ができているエージェントの呼と、キュー内の呼の差引きの後にまだ使用可能と考えられるＴＴＲエージェントの呼とを含む。
【００６３】
システムが、ステップ４０９で、かけるべき呼の公称個数に呼を追加しないと判定する場合には、ステップ４１０で、システムは、まだ顧客によって答えられていない、最後のインターバルからのダイヤルされた呼があるどうかをチェックする。システムが、ステップ４１０で、ダイヤルされた呼がないと判定する場合に、システムは、ステップ４１２で、最終的な計算された個数のアウトバウンド・コールをかける。システムが、ステップ４０９で、公称総数に呼を追加すると決断する場合には、追加される呼の個数は、所望の呼放棄パーセンテージの超過をもたらさない個数に制限される。プロセスは、ステップ４１０に移り、ここで、システムは、ダイヤルされた呼があるかどうかをチェックする。システムが、ステップ４１０で、１つまたは複数のダイヤルされた呼があると判定する場合に、システムは、ステップ４１１で、呼の許容可能なまたは許される個数とダイヤルされた呼の個数との間の差を計算する。より具体的には、システムは、許容可能なまたは許される呼の個数からダイヤルされた呼の個数を差し引く。その後、システムは、ステップ４１２で、正しい個数のアウトバウンド・コールをかける。この方法の目標は、呼放棄レートを許容できるレベルの下に保ちながらキャンペーンを担当するエージェントの時間を最適に利用するためにちょうど十分な呼をかけることである。
【００６４】
図５は、本発明の実施形態による、発呼に関するエージェントの可用性を予測するためにタイムトゥーレディ情報を更新するステップ５００を示すプロセス・フロー図である。ステップ５０１で、グループ・エージェントは、タスクでビジーである。ステップ５０２で、システムは、タスクのタイプを登録する。タスクは、呼の決まりきった性質が、完了までの予測された時間を有するステージまたはフェーズ単位で呼を定量化することを可能にする、特定のタイプの電話呼とすることができる。
【００６５】
ステップ５０３では、システムは、ステップ５０２で登録されたタスクのタイプに関するタスク・フェーズ・パラメータを得る。フェーズ・パラメータは、タスクのフェーズごとに割り当てられた時間からなる。ステップ５０４では、システムは、エージェントがタスクを行っている間に、フェーズ遷移についてエージェントを監視する。監視コンポーネントは、エージェントのワークステーション内のエージェントのコンピュータ上で実行されるエージェント・デスクトップ・アプリケーション内など、エージェントにローカルとすることができる。タスクがＣＯＳＴ呼である一実施形態では、監視コンポーネントを、コール・センタによって使用される電話交換機を制御するＣＴＩプロセッサ内で実施することができる。別の実施形態では、アウトバウンド・コール発呼インターバルにタスクでビジーな各エージェントは、そのエージェントが呼を受ける準備ができると期待される時刻をエージェント・デスクトップ・アプリケーションを介して統計サーバに報告する責任を負う。このケースでの報告する行為を、システムがアウトバウンド・コールの次のラウンドをかけることの通知の受信時に開始することができる。通知は、エージェント・デスクトップ・アプリケーション内でポップ・アップまたはトーストのグラフィックとして現れることができる。報告は、ショート・メッセージ・サービス（ＳＭＳ）メッセージまたはコンタクト・サーバおよびダイヤリング・システムによって理解され得るある他のテキスト・メッセージとすることができる。
【００６６】
一実施形態では、エージェント・デスクトップ・アプリケーションは、エージェントによる介入なしで自動的にエージェント状況を報告することを可能にされる。このケースでは、アプリケーションは、エージェントがあるタスク・フェーズから次のタスク・フェーズへ遷移する時に報告する。その後、システムは、キャンペーンを担当するすべてのビジー・エージェントについてタスクの完了までの時間を計算することができる。この実施形態の変形形態では、監視コンポーネントは、タスクの完了までの現行時間の報告を要求する照会がいつでも到着し得ることの理解と共に、エージェントがタスクでビジーになる時からエージェントがタスクを完了し、もう一度使用可能になる時までの時間を能動的に追跡することができる。このケースでは、タスク・ステージまたはタスク・フェーズが、不必要である可能性がある。タスクの完了までの時間の値は、図４で説明したＴＴＲに類似し、エージェントが準備ができる前の残っている秒数単位で表され得る。
【００６７】
監視コンポーネントは、ステップ５０５で、ビジー・エージェントについて、エージェントがフェーズを遷移しつつあるかどうかを判定する。ステップ５０５で、モニタが、エージェントがフェーズを遷移しつつあるのではないと判定する場合には、プロセスは、ビジー・エージェントについて監視するステップ５０４にループ・バックする。デスクトップ監視のケースでは、各エージェントは、彼ら自身の監視および報告システムを有する。しかし、一実施形態では、ビジーになる、キャンペーンを担当するすべてのエージェントが、ＣＴＩプロセッサまたは本発明のエージェントおよびシステムによって使用されるコンピューティング・ネットワークに接続されたある他のサーバなどの中央位置から監視される。
【００６８】
監視コンポーネントが、ステップ５０５で、エージェントがタスクのフェーズを遷移しつつあると判定する場合には、ステップ５０６で、エージェント・デスクトップ・アプリケーションが、統計サーバにフェーズ遷移を報告することができ、現在システム内にあるすべてのＴＴＲ情報をセットしまたは更新することができる。たとえば、呼は、第１フェーズが完了に推定された２０秒を要し、第２フェーズが完了に１０秒を要する、２つのフェーズを有する場合がある。第１フェーズで、ビジー・エージェントは、３０秒のＴＴＲ値を有すると報告される。第２フェーズが開始される時に、そのエージェントは、１０秒のＴＴＲ値を有すると報告される。１０秒が満了した後に、そのエージェントは、準備ができていると報告される。ステップ５０６は、キャンペーンを担当しているすべてのビジー・エージェントについて発生する。
【００６９】
ステップ５０７では、統計サーバは、アウトバウンド・コール発呼インターバルが開始されたかどうかを判定することができる。システムが、ＯＢコール発呼インターバルを開始した場合には、ステップ５０８で、システムは、ビジー・エージェントのＴＴＲが平均呼持続時間を表すしきい値（呼が答えられるまでのアウトバウンド・コール発呼の時間）以下であるかどうかを判定する。ステップ５０７は、キャンペーンを担当しているすべてのビジー・エージェントについて発生する。
【００７０】
システムが、ステップ５０７で、アウトバウンド・コーリング・インターバルを開始していない場合には、プロセスは、継続されるエージェント・タスク実行監視のためにステップ５０４に戻ると決定する。ステップ５０７で、アウトバウンド・コーリング・インターバルがシステムによって開始された場合には、これは、システムが、呼を受ける準備ができた少なくとも１つのエージェントの存在を判定したことを意味する。このケースには、ステップ５０８で、システムは、ビジー・エージェントについて報告されたＴＴＲ値をしきい値に対してチェックして、何人のＴＴＲエージェントを、呼を受け入れる準備が既にできているエージェントと考えることができるのかを判定する。ステップ５０８は、すべてのビジー・エージェントについて実行される。
【００７１】
ステップ５０８で、あるエージェントについてＴＴＲがしきい値より大きい場合に、そのエージェントは、ビジーであり、発呼の現行ラウンドに使用可能ではないと考えられる。これは、報告する各ビジー・エージェントにあてはまる。システムが、あるエージェントについて、そのエージェントのＴＴＲ値がしきい値以下であると判定する場合には、ステップ５０９で、そのエージェントが、使用可能または準備ができていると考えられ、または数えられる。本明細書では、システムが、準備ができたエージェントとＴＴＲエージェントとの間の区別を維持することに留意されたい。キューに入れられた呼があるケースでは、ＴＴＲエージェントは、その使用可能の状況が予測にすぎないので、最初に考慮から除去される。あるＴＴＲエージェントが、予測されたＴＴＲが満了してから少し後、おそらくはタスク完了に関する問題がある場合に何秒も後に、実際に使用可能になる可能性がある。そのケースでは、そのエージェントに指定された呼が、そのエージェントが使用可能になるか次のエージェントが使用可能になるのをキュー内で待つ可能性がある。エージェントは、ＴＴＲが満了する前に準備ができる場合もある。このケースでは、システムは、ＴＴＲエージェントではなく準備ができているものとしてそのエージェントを数える。
【００７２】
準備ができているまたはＴＴＲに基づいてエージェントを監視し、分類する方法を含む本発明の方法を、先を見越したチャット・キャンペーンなどの先を見越したウェブベースの招待キャンペーンで実施することができる。チャット対話の予測不能な性質のゆえに、チャット・セッションを決まりきったタスクとしてどのようにステージに分けるのかに、いくつかの相違がある可能性がある。しかし、チャットが、取引などの構造化された電話呼に類似する目的を念頭において構造化される場合に、完了までの平均時間を、経時的に査定し、チャット・セッションに割り当てることができる。エージェントと顧客との間の他の構造化された生の通信セッションを、インスタント・メッセージ会話および類似物のようにステージに分けることもできる。
【００７３】
本発明の予測的可用性判定の方法およびシステムを、本発明の趣旨および範囲から逸脱せずに、述べられた特徴およびコンポーネントの一部またはすべてを使用して提供できることは、当業者に明白であろう。上で説明された実施形態が、単一のより広義の発明の特定の例であり、この単一のより広義の発明が、教示された単一の説明のどれよりも広い範囲を有することができることも、当業者に明白であろう。本発明の趣旨および範囲から逸脱しない、この説明内で作られる多数の代替形態がある可能性がある。
【特許請求の範囲】
【請求項１】
アウトバウンド電話呼をかける、ネットワークに接続された第１ノードと、
前記ネットワークに接続され、準備ができていない、準備ができている、および準備ができる時間に関するエージェント状況を報告するために前記第１ノードにアクセス可能な第２ノードと、
を含む、アウトバウンド・コールを行うシステムであって、
ダイヤルすべきアウトバウンド・コールの正しい個数が、呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて判定される
ことを特徴とするシステム。
【請求項２】
参加するエージェントが、デスクトップ・インターフェースとしてエージェント・アクティビティ・アプリケーションを実行するネットワーク接続されたエージェント機器から働く、請求項１に記載のシステム。
【請求項３】
前記エージェント機器が、デスクトップ・コンピュータであり、前記エージェント・アクティビティ・アプリケーションが、統計サーバにエージェント・アクティビティ状態を報告する、請求項２に記載のシステム。
【請求項４】
（ａ）ネットワークに接続された第１ノードによってアウトバウンド電話呼をかけるステップと、
（ｂ） 前記ネットワークに接続され、前記第１ノードにアクセス可能な第２ノードによって、準備ができていない、準備ができている、および準備ができる時間に関するエージェント状況を報告するステップと、
（ｃ）呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて、ダイヤルすべきアウトバウンド・コールの正しい個数を判定するステップと
を含む、アウトバウンド・コールを行う方法。
【請求項５】
参加するエージェントが、デスクトップ・インターフェースとしてエージェント・アクティビティ・アプリケーションを実行するネットワーク接続されたエージェント機器から働く、請求項４に記載の方法。
【請求項６】
前記エージェント機器が、デスクトップ・コンピュータであり、前記エージェント・アクティビティ・アプリケーションが、統計サーバにエージェント・アクティビティ状態を報告する、請求項５に記載の方法。
【請求項１】
アウトバウンド電話呼をかける、ネットワークに接続された第１ノードと、
前記ネットワークに接続され、準備ができていない、準備ができている、および準備ができる時間に関するエージェント状況を報告するために前記第１ノードにアクセス可能な第２ノードと、
を含む、アウトバウンド・コールを行うシステムであって、
ダイヤルすべきアウトバウンド・コールの正しい個数が、呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて判定される
ことを特徴とするシステム。
【請求項２】
参加するエージェントが、デスクトップ・インターフェースとしてエージェント・アクティビティ・アプリケーションを実行するネットワーク接続されたエージェント機器から働く、請求項１に記載のシステム。
【請求項３】
前記エージェント機器が、デスクトップ・コンピュータであり、前記エージェント・アクティビティ・アプリケーションが、統計サーバにエージェント・アクティビティ状態を報告する、請求項２に記載のシステム。
【請求項４】
（ａ）ネットワークに接続された第１ノードによってアウトバウンド電話呼をかけるステップと、
（ｂ） 前記ネットワークに接続され、前記第１ノードにアクセス可能な第２ノードによって、準備ができていない、準備ができている、および準備ができる時間に関するエージェント状況を報告するステップと、
（ｃ）呼を受け入れる準備ができていると報告されたエージェントの人数に、指定された時間ウィンドウ内に呼を受け入れる準備ができると予測されたエージェントの人数を加えたものに基づいて、ダイヤルすべきアウトバウンド・コールの正しい個数を判定するステップと
を含む、アウトバウンド・コールを行う方法。
【請求項５】
参加するエージェントが、デスクトップ・インターフェースとしてエージェント・アクティビティ・アプリケーションを実行するネットワーク接続されたエージェント機器から働く、請求項４に記載の方法。
【請求項６】
前記エージェント機器が、デスクトップ・コンピュータであり、前記エージェント・アクティビティ・アプリケーションが、統計サーバにエージェント・アクティビティ状態を報告する、請求項５に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１２−５２９２２７（Ｐ２０１２−５２９２２７Ａ）
【公表日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願番号】特願２０１２−５１３９７５（Ｐ２０１２−５１３９７５）
【出願日】平成２２年５月２１日（２０１０．５．２１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３５７６５
【国際公開番号】ＷＯ２０１０／１４１２４３
【国際公開日】平成２２年１２月９日（２０１０．１２．９）
【出願人】（３９９０４８２０５）ジェネシス・テレコミュニケーションズ・ラボラトリーズ・インコーポレーテッド (18)
【Ｆターム（参考）】
【公表日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願日】平成２２年５月２１日（２０１０．５．２１）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３５７６５
【国際公開番号】ＷＯ２０１０／１４１２４３
【国際公開日】平成２２年１２月９日（２０１０．１２．９）
【出願人】（３９９０４８２０５）ジェネシス・テレコミュニケーションズ・ラボラトリーズ・インコーポレーテッド (18)
【Ｆターム（参考）】
[ Back to top ]