(57)【特許請求の範囲】
【請求項１】
作業キュー内の複数の作業項目を、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第１のセットに分配するための中央サーバを含むコンタクト・センタ内で、作業負荷モニタ用エージェントによってサービスに関する作業待ちの状態を評価するための方法であって、
サービス時間目標から現在の時間を引いた残り時間を作業キューの重み付けされた進行時間で除算し、端数切捨てされた整数として算出される必須キュー位置（ＲＱＰ）の値毎の作業項目の計数を格納する複数の要素を供給するステップと、
指標変数を作成して前記指数変数を１に設定し、和変数を作成して前記和変数をゼロに設定するステップと、
前回の和変数の値と、指標変数に対応する前記作業キュー内の作業項目の値の和として新たな和を算出するステップと、
指標変数に対応する前記作業キュー内の作業項目に付随する最大のＲＱＰを判定するステップと、
前記和が前記最大のＲＱＰよりも大きいかどうかを判定するステップと、
前記和が前記最大ＲＱＰよりも大きいときに前記作業キューの状態を「将来の危険」と設定するステップと、
前記指標を１つ増加させ、かつ新たな和の前記算出ステップを繰り返し、最大ＲＱＰを判定し、和が最大ＲＱＰよりも大きいかどうかを判定し、前記和が前記最大ＲＱＰよりも大きくないときに「目標通り」と設定するステップと、
完了の必要のある作業項目の合計数が、完了が予測される作業項目の合計数より大きい場合に、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第２のセットを前記作業キューに割り当てるステップとを含む、方法。
【請求項２】
完了の必要のある作業項目の合計数が、完了が予測される作業項目の合計数より小さい場合に、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第１のセットの過剰を減らすステップと、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第１のセットに、前記作業キューの前記作業項目の割り当てを維持するステップの少なくとも一つを含み、
作業項目が、要素に関して対応する所定のＲＱＰの範囲内にＲＱＰを有すると判定されるときに、作業項目のＲＱＰに対応する要素の値を１つ増加するステップをさらに含み、
各要素が所定のＲＱＰの範囲に対応し、第１の要素が所定のＲＱＰの第１の範囲に対応し、第２の要素が所定のＲＱＰの第２の範囲に対応し、前記第１の範囲が前記第２の範囲より小さい、請求項１に記載の方法。
【請求項３】
前記作業キュー内の各々の作業項目に対応するＲＱＰの範囲を判定するステップを含み、選択された作業項目の数がＮであるときに、前記作業キュー内の選択された作業項目に関するキュー位置の前記所定の範囲が２Ｎ−１＜ＲＱＰ≦２Ｎである、請求項２に記載の方法。
【請求項４】
前記分析のステップがさらに、
前記作業キュー内の全ての作業項目が分析されたかどうかを判定するステップ、
前記作業キュー内の全ての作業項目が分析されたときに状態を「目標通り」と設定し、かつ前記和が前記最大ＲＱＰよりも大きいときに前記「将来の危険」の時間および／または程度を予測するステップを含み、
前記時間が指標と作業キューに関する重み付けされた進行時間の積として算出され、前記程度が前記和と前記最大ＲＱＰの間の差として算出される、請求項１に記載の方法。
【請求項５】
請求項１に記載の方法を実行するために実行可能な命令を含むコンピュータ読み取り可能な媒体。
【請求項６】
複数の顧客から受信した複数のコンタクトにサービス提供するためのコンタクト・センタであって、
複数のリソースに対応する複数のワークステーションを含み、
複数のワークステーションと連絡している中央サーバであって、
コンタクトの少なくとも１つのキューを含み、前記複数のコンタクトの各々が付随のサービス時間目標を有し、
（ａ）前記サービス時間目標から現在の時間を引いた残り時間を作業キューの重み付けされた進行時間で除算し、端数切捨てされた整数として算出される必須キュー位置（ＲＱＰ）の値毎の作業項目の計数を格納する複数の要素を供給し、（ｂ）指標変数を作成して前記指数変数を１に設定し、和変数を作成して前記和変数をゼロに設定し、（ｃ）前回の和変数の値と、指標変数に対応する前記作業キュー内の作業項目の値の和として新たな和を算出し、（ｄ）指標変数に対応する前記作業キュー内の作業項目に付随する最大のＲＱＰを判定し、（ｅ）前記和が前記最大のＲＱＰよりも大きいかどうかを判定し、（ｆ）前記和が前記最大ＲＱＰよりも大きいときに前記作業キューの状態を「将来の危険」と設定し、（ｇ）前記指標を１つ増加させ、かつ新たな和の前記算出ステップを繰り返し、最大ＲＱＰを判定し、和が最大ＲＱＰよりも大きいかどうかを判定し、前記和が前記最大ＲＱＰよりも大きくないときに「目標通り」と設定し、（ｈ）完了の必要のある作業項目の合計数が、完了が予測される作業項目の合計数より大きい場合に、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第２のセットを前記作業キューに割り当てるように動作可能な作業負荷モニタ用エージェントのための手段を含む中央サーバを含むコンタクト・センタ。
【請求項７】
前記作業負荷モニタ用エージェントは、完了の必要のある作業項目の合計数が、完了が予測される作業項目の合計数より小さいと判定したときに、前記作業負荷モニタ用エージェントが、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第１のセットの過剰を減らすこと、コンピュータ・ワークステーションおよび／または音声通信機器リソースの第１のセットに、前記作業キューの前記作業項目の割り当てを維持することの少なくとも１つを実行するよう動作可能である、請求項６に記載のコンタクト・センタ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース配分システム内の作業項目のスケジュール化を指向する。特に、本発明はキュー待機サービスの作業項目のサービス時間目標、およびサービス時間目標に関するキュー内の作業項目の状態の評価を指向する。
【背景技術】
【０００２】
現在、キュー内の作業項目に関するオペレーションのタイミングとサービス時間目標に関して計算を実行するために自動コンタクト分配（ＡＣＤ）システム、リソース選択と割り振りのアルゴリズムが一般的に使用される。これらの計算は、例えば、電話コールがコール・センタで受信されると実行される。そのようなコールが受信されると、通常ではそれは電話コールへの対応を担うリソースのプールに割り当てられる。さらに、そのようなコールは概して３分間といったサービス時間目標を有し、それはエージェントにとってコールに応答するための目標である。これらのサービス時間目標は、顧客がエージェントと話すのに長時間待たされないことを確実化することを手助けするのに有用であり、その待ち時間は顧客の満足度を下げかねない。
【０００３】
そのようなＡＣＤシステムでは、コンタクト・センタに入来するコンタクトは複数のリソースによって応答され、かつ取り扱いされる。ＡＣＤシステムは、そのコンタクトの取り扱いに適したスキル・セットを有し、かつ空いている、すなわちその瞬間に他のコンタクトを取り扱っていないリソース、概してエージェントが何であろうと入来するコンタクトを自動的にそれに分配して接続する。ここで使用する「コンタクト」は２つのエンティティ間のいかなるモードもしくはタイプの接触にも関し、限定されないが２、３の例を挙げると音声コール、ＶｏＩＰ、テキスト・チャット、ｅメール、ファクシミリ、電子文書、ウェブ形式、音声メッセージ、およびビデオコールが含まれる。
【特許文献１】米国特許第５，５０５，８９８号
【特許文献２】Ｆｌｏｃｋｈａｒｔらの係属中の米国特許出願「Ｃｏｎｔａｃｔ  Ｃｅｎｔｅｒ  Ｒｅｓｏｕｒｃｅ  Ａｌｌｏｃａｔｉｏｎ  Ｂａｓｅｄ  Ｏｎ  Ｗｏｒｋ  Ｂｉｄｄｉｎｇ／Ａｕｃｔｉｏｎ」
【特許文献３】米国特許第５，５０６，８９８号
【特許文献４】米国特許出願番号第０９／６４１，４０３号
【発明の開示】
【発明が解決しようとする課題】
【０００４】
コンタクトは、各コンタクト・タイプに関するビジネス／サービス方針、目的および目標といった予め設定された判定基準に基づいて多様なキューに配置され、通常では、それらの到着および／または優先順位の順番で各キュー内に配置される。多数の顧客からの着信コンタクトが不規則にかつピークを伴って行われるため、コンタクトを扱うために利用可能な適切なリソースがないとコンタクト・センタはコンタクトのためのサービス時間目標が満了するときに過負荷になる可能性がある。さらに、コンタクト・センタは現在満了しつつあるサービス時間目標を有する現在のコンタクトを扱うのに充分なリソースを有する可能性はあるが、しかし将来のいくつかの時点にサービス時間目標を有するコンタクトを扱うのに充分なリソースを有さない可能性がある。
【０００５】
当該技術で知られているように、サービス時間目標が満了しつつあるかどうか検出するアルゴリズムを有し、かつサービス時間目標がこの先で満了になりそうかどうかも予測することは、そのようなＡＣＤシステムに関して通例である。各キュー項目に関する実際または見込まれる待ち時間を判定するために数多くの技術が考案されてきており、キュー項目は通常ではその実際および／または見込みの待ち時間に基づいてサービスを受けている。しかしながら、コンタクト・センタが目標より遅れているかどうか、または間近に危険な状態にあるかどうかを判定するために、そのような技術は概してキューの先頭しか見ない。サービス時間目標がこの先で満了しそうであることを予測するのに使用される技術は、概して、キューの最後尾またはキュー内の最後の項目だけを見ており、この項目がその作業項目に関するサービス時間目標もしくはそれ以前にサービスを受けると予測されるかどうかの判定を行ない、将来に危険性があるかどうかについてイエス／ノーの回答を与える。理解されるであろうが、キュー内の最後の項目は、実質的に同時に満了するであろうサービス時間目標をすべてが有する項目の数に従うことが可能である。その結果、キュー内の最後の項目が将来の危険性を示さないことは可能であるが、実際では、キュー内の最後の作業項目に先行する比較的重い作業負荷に付随して将来の危険性が存在する。したがって、将来の危険性を判定し、かつそのような危険性が生じるであろうとき、および潜在的なリソースの不足を修正するのに必要なリソースの量もやはり判定することが可能な方法と装置を有することが有利であろう。
【０００６】
そのような技術の別の問題は、それらがリアルタイムのサービス用に設計されなかったことである。上述したように、ｅメール、ファクシミリ、電子文書、ウェブ形式、音声メッセージの形でコンタクトを受けることは通例であり、それらはエージェントの即時の配慮を要求するものではなく、むしろ予め設定したサービス時間目標期間以内で配慮されることを必要とする。例えば、コンタクト・センタは電子メールに関して１営業日のサービス時間目標を有する可能性がある。同様に、受信されるウェブ形式は２営業日以内に回答をされる目標を有する可能性がある。そのようなコンタクトは「バックオフィス・コンタクト」と称され、それらはバックオフィスによってサービスを受けるキューの中に置かれ、それらはエージェントによってリアルタイムでコンタクトを伴うサービスを受けないことを意味する。
【０００７】
いくつかのＡＣＤシステムでは、そのような作業項目は順序化されていないキューの中に置かれる。これらの項目はしばしば異なる時間に受信され、異なるサービス目標を有する。したがって、もしも順序化された作業プールの中に項目が置かれ、コンタクトにサービス提供すべき残り時間によってコンタクトが順序化される場合、コンタクトがキューに追加される度にキューが再配列されねばならなくなる可能性がある。理解されるであろうが、作業キューの再配列はシステム内の有意の量のリソースを消費する可能性があり、したがって順序化されていない作業プールもしくは作業キューの中にそのような作業項目を置くことが有利になる可能性がある。非順序化作業プールにコンタクトを置くことに伴う１つの問題は、リソース割り当てアルゴリズムが概して順序化作業プールを使用して動作するように設計されていることである。したがって、非順序化作業プールで作業を評価することでプールの状態を判定し、かつその作業プールについてあり得る将来のリソース不足に関する予測をたてることが可能なリソース割り当てアルゴリズムを備えた非順序化作業プールを有することが有利であろう。
【課題を解決するための手段】
【０００８】
これらおよびその他の必要性は本発明の様々な実施形態および構成によって対処される。本発明は、順序化または非順序化作業プール内で作業待ちサービスの状態を評価するための方法と装置を概して指向する。本方法は特にコンタクト・センタで有用である。
【０００９】
一実施形態では、コンタクト、製品注文、サービス要求といった作業項目はリソースによるサービスのための作業キューの中に置かれる。サービスに関する作業待ちの状態は、少なくとも部分的に作業キューに基づいて、作業キュー内の作業項目に関して項目の順序化セットを作成すること、およびその順序化セットを分析して作業キューの将来の状態を予測することによって評価される。前記作業キュー内の各々の作業キューに関する必須キュー位置（ＲＱＰ）が判定されることが可能であり、そのＲＱＰは各々の作業項目に関するサービス時間目標および作業項目の完了に関して見積もられる時間に基づいている。項目の順序化セットはカウンタのアレーを作製することによって作り出されることが可能であり、カウンタのアレーの各々の要素が必須キュー位置の所定の範囲に対応する。カウンタのアレーは、各作業項目に関するＲＱＰに付随するカウンタのアレー内でカウンタに増分を与えることによって変えられることが可能である。一実施形態では、各作業項目に関する必須キュー位置は、その作業項目が受信された後の時間量をその作業項目に関するサービス時間目標から差し引いてその作業項目に関する残り時間を得ることによって決定される。各々の作業項目について、必須キュー位置の決定はその作業項目に関する残り時間を作業キューの重み付けされた進行時間（ＷＡＴ）で除算する工程を含む可能性がある。重み付けされた進行時間は、キューの中で作業項目が位置１つ進むのに要する平均時間の目安である。重み付けされた進行時間の計算は米国特許第５，５０６，８９８号に述べられており、その開示はその全文を参考資料でここに組み入れられている。
【００１０】
一実施形態では、項目の順序化セットは、順序化セット内の各項目に対応する必須キュー位置の範囲を決定すること、および各作業項目に付随する必須キュー位置に対応する順序化セット内の項目に付随するカウンタに増分を与えることによって作り出される。順序化セット内の各項目に関するキュー位置の範囲は、例えば、順序化セット内の各項目が１つのキュー位置に対応することが可能、または項目の数がＮである場合に順序化セット内の各項目が２Ｎ−１＜ＲＱＰ≦２Ｎであることが可能、といった予め確立した判定基準に設定される可能性がある。
【００１１】
一実施形態では、作業キューの将来の状態を予測するために順序化セットを分析する工程は、指標変数を作り出す工程、指標変数を１に設定する工程、和変数を作り出す工程、和変数をゼロに設定する工程、和変数の前回の値と和変数に対応する順序化セット内の項目の値の和として新たな和を算出する工程、その和が指標よりも大きいかどうかを判定する工程、その和が指標よりも大きいときに状態を「将来の危険」に設定する工程、および指標に増分を与え、新たな和の算出を繰り返す工程、その和が指標よりも大きいかどうかを判定する工程、その和が指標よりも大きくないときに状態を設定する工程を含む。別の実施形態では、キュー位置の範囲は順序化セット内の各項目に対応し、判定する工程は、指標変数に対応する順序化セット内の項目に付随する最大数のキュー位置よりも和が大きいかどうかを判定する工程を含む。
【００１２】
順序化セットの分析はさらに、順序化セット内に追加の項目があるかどうかを判定する工程、および順序化セット内に追加の項目がないときに状態を「的確」に設定する工程を含むことが可能である。順序化セットの分析はまた、和が指標よりも大きいときに「将来の危険」の時間を予測する工程も含むことが可能である。その時間は指標と作業項目の完了に関する算定時間の積として算出されることが可能である。順序化セットの分析は、和が指標よりも大きいときに「将来の危険」の程度を判定する工程を含むことが可能である。一実施形態では、将来の危険の程度は和と指標の間の差として算出される。別の実施形態では、将来の危険の程度は和と指標変数に対応する順序化セット内の項目に付随する最大数キュー位置の間の差として算出される。また別の実施形態では、本発明はコンピュータ読み取り可能な媒体を供給し、それがサービスに関する作業待ちの状態を判定する工程を実行するための命令、およびサービスに関する作業待ちの状態を判定する工程を実行するように動作可能な論理回路を含む。
【００１３】
また別の実施形態で、本発明はある方法を実行するために計算用の部品もやはり供給し、その方法は複数の作業項目の各々について必須キュー位置（ＲＱＰ）を判定する工程を含み、そのＲＱＰは作業項目に関する残り時間およびカウンタのアレーの要素でカウンタに増分を与える作業キューに関する重み付けされた進行時間に基づいており、その要素が必須キュー位置の所定の範囲に対応し、作業項目の将来の状態を予測するためにカウンタのアレーを分析する工程を含む。必須キュー位置を判定する工程は、各作業項目に関してその作業項目が受信された後の時間量をその作業項目に関するサービス時間目標から差し引いてその作業項目に関する残り時間を得る工程を含むことが可能である。必須キュー位置を判定する工程は作業キューおよび各作業項目について重み付けされた進行時間を決定する工程、残り時間を作業キューに関する重み付けされた進行時間で除算する工程を含むことが可能である。カウンタに増分を与える工程は、カウンタのアレー内の各要素に対応する必須キュー位置の範囲を判定する工程、および必須キュー位置を判定する工程で得られた必須キュー位置に対応するカウンタ・アレー内の要素に付随するカウンタに増分を与える工程を含むことが可能である。一実施形態では、カウンタ・アレー内の各要素に関するキュー位置の所定の範囲は１である。別の実施形態では、カウンタ・アレー内の各々の要素に関するキュー位置の所定の範囲は、要素の数がＮである場合に２Ｎ−１＜ＲＱＰ≦２Ｎである。
【００１４】
一実施形態では、分析工程は指標変数を作り出す工程、指標変数を１に設定する工程、和変数を作り出す工程、和変数をゼロに設定する工程、和変数の値と指標変数に対応するカウンタ・アレーの要素内のカウンタの値の和として新たな和を算出する工程、その和が指標よりも大きいかどうかを判定する工程、その和が指標よりも大きいときに状態を「将来の危険」に設定する工程、および指標に増分を与え、新たな和の算出を繰り返す工程、その和が指標よりも大きいかどうかを判定する工程、その和が指標よりも大きくないときに状態を設定する工程を含む。一実施形態では、判定する工程は、指標変数に対応するカウンタ・アレーの要素に付随する最大数のキュー位置よりも和が大きいかどうかを判定する工程を含む。分析工程もまた、カウンタ・アレー内に追加の要素があるかどうかを判定する工程、およびカウンタ・アレー内に追加の要素がないときに状態を「的確」と設定する工程を含むことが可能である。分析工程はまた、和が指標よりも大きいときに「将来の危険」の時間を判定する工程を含むことも可能である。将来の危険の時間は指標と作業キューの重み付けされた進行時間の積として算出される。分析工程はさらに、和が指標よりも大きいときに「将来の危険」の程度を判定する工程を含むことも可能である。その程度は和と指標の間の差として算出されることが可能である。別の実施形態では、分析工程はさらに、指標変数に対応するカウンタ・アレーの要素に付随する最大数のキュー位置よりも和が大きいときに、和とその要素に付随する最大数のキュー位置の間の差として算出される「将来の危険」の程度を判定する工程を含む。
【００１５】
本発明のまた別の態様はコンタクト・センタの電子的メモリ内に保持される表を提供し、それは少なくとも２つの作業項目、およびそれらの作業項目に関する必須キュー位置の所定の範囲に付随する記入内容を有する順序化されたリストを有する。一実施形態では、それらの記入内容は作業項目に関する必須キュー位置を示す。一実施形態では、順序化リスト内の各記入内容に関する必須キュー位置の所定の範囲は１である。別の実施形態では、順序化リスト内の各記入内容に関するキュー位置の所定の範囲は、要素の数がＮである場合に２Ｎ−１＜ＲＱＰ≦２Ｎである。
【００１６】
本発明のまた別の態様は複数の顧客から受信した複数のコンタクトにサービス提供するためのコンタクト・センタを提供し、それが複数のリソースに対応する複数のワークステーション、それら複数のワークステーションと連絡していて複数コンタクトのキューを少なくとも１つ含む中央サーバを含み、複数コンタクトの各々が付随するサービス時間目標を有し、かつコンタクト・センタは、（ａ）複数コンタクトのキューをモニタし、（ｂ）複数のコンタクトに関するサービス時間目標との関連で複数コンタクトのキューの状態を評価し、かつ（ｃ）サービス時間目標が満了しそうにないコンタクトの数およびそのコンタクト数についてサービス時間目標が満了するであろう時間を判定するように動作可能な作業負荷モニタ用エージェントを含む。一実施形態では、キュー内のコンタクト１つまたは複数のリアルタイムおよび非リアルタイムのコンタクトを含む。別の実施形態では、作業負荷モニタ用エージェントがさらに、作業キューの重み付けされた進行時間を識別し、かつコンタクトの各々に関する必須キュー位置を判定するように動作可能である。作業負荷モニタ用エージェントは、作業キューの重み付けされた進行時間、キューにコンタクトが受信されて以来の経過時間、およびコンタクトに関するサービス時間目標に基づいて必須キュー位置を判定することが可能である。ある実施形態では、必須キュー位置はサービス時間目標と作業キューの重み付けされた進行時間で除算された経過時間の間の差として算出される。複数のコンタクトの中のいくつかのコンタクトは少なくとも２つのサービス時間目標を有する可能性がある。ある実施形態では、作業負荷モニタ用エージェントはさらにキュー内のコンタクトに付随する必須キュー位置の代表を判定するように動作可能である。一実施形態では、必須キュー位置の代表にあるキュー位置よりも前にキューに入れられたコンタクトの数よりも必須キュー位置の代表にあるキュー位置が小さいときに所定の作業負荷水準が存在する。所定の作業負荷水準が存在する見込みのある時間は作業キューの重み付けされた進行時間と所定の作業負荷水準が存在する見込みのあるキュー位置の積である。サービス提供を要求されるコンタクトの数は必須キュー位置と必須キュー位置よりも前にキューに入れられたコンタクトの数の間の差である。
【００１７】
これらおよびその他の利点はここに含まれ、特に添付の図面類と関連させてなされる本発明の開示から明らかになるであろう。
【００１８】
上述の実施形態と構成は完全でもなければ網羅的でもない。理解されるであろうが、上述または以下で詳細に述べる１つまたは複数の特徴を単独または組み合わせで利用して本発明の他の実施形態が可能である。
【発明を実施するための最良の形態】
【００１９】
図１は本発明の具体例の実施形態を示している。
コンタクト・センタ６は（Ａｖａｙａ，Ｉｎｃ．の改造型Ａｄｖｏｃａｔｅ（商標）ソフトウェアを走らせるＤｅｆｉｎｉｔｙ（商標）またはＭｕｌｔｉ−Ｖａｎｔａｇｅ（商標）Ｅｎｔｅｒｐｒｉｓｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｅｒｖｅｒといった）中央サーバ１０、コンタクトもしくは顧客に関する情報およびコンタクトの価値と効率を高めることが可能なその他の情報を含むデータ記憶のセットもしくはデータベース１２、複数のサーバ、すなわちファックス・サーバ２４、データ・ネットワーク・サーバ２０、ｅメール・サーバ１６、およびその他のサーバ１３、構内交換設備ＰＢＸ２８（または自動式構内交換設備ＰＡＸ）、パーソナルコンピュータのようなコンピュータ・ワークステーション１５を操作する（人間エージェントとして示されている）第１の複数もしくはセットのリソース１４、および／またはローカルエリアネットワークＬＡＮ（または広域ネットワークＷＡＮ）３６によってすべてが相互接続された電話器１７または他のタイプの音声通信機器、およびやはりパーソナルコンピュータのようなコンピュータ・ワークステーション１５および／または公共交換電話ネットワークもしくはＰＳＴＮ４８を介してＰＢＸ２８に接続され、かつインターネットのようなデータ・ネットワーク４４を介して中央サーバ１０に接続された電話器１７または他のタイプの音声通信機器を操作する（人間エージェントとして示されている）第２の複数もしくはセットのリソース１００を有する。ファックス・サーバ２４、ウェブ・サーバ２０およびｅメール・サーバ１６は通信接続４０を介してデータ・ネットワーク４４に接続される。
【００２０】
その他のサーバ１３は、場合によって設けられる（点線の）通信回線２２、３２を介してＰＢＸ２８および／またはデータ・ネットワーク４４に接続されることが可能である。理解されるであろうが、その他のサーバ１３には（通常ではＰＢＸ２８またはネットワーク４４に接続されていない）スキャナ、対話式音声識別ＩＶＲソフトウェア、ＶｏＩＰソフトウェア、ビデオコール・ソフトウェア、音声メッセージ・ソフトウェア、ＩＰ音声サーバなどが含まれる可能性がある。ＰＢＸ２８は複数のトランク１８を介して、ＰＳＴＮ４８に接続され、リソース１４のファックス・サーバ２４および電話器１７に接続される。理解されるであろうが、ファックスは適切に備え付けられたパーソナルコンピュータによってＰＳＴＮ４８経由またはネットワーク４４経由で受信することが可能である。ＰＢＸ２８、ファックス・サーバ２４、ｅメール・サーバ１６、ウェブ・サーバ２０、およびデータベース１２は従来式である。
【００２１】
理解されるであろうが、中央サーバ１０は、着信コンタクトを受ける通信部品（例えばＰＢＸ２８、ファックス・サーバ２４、ｅメール・サーバ１６、ウェブ・サーバ２０、および／またはその他のサーバ１３）によって着信のリアルタイムもしくは非リアルタイムのコンタクトをＬＡＮ３６を経由して通知される。着信コンタクトは、そのコンタクトを特定のワークステーションおよび／またはリソースへと転送するために中央サーバ１０が受信用通信部品に命令を転送するまでその部品によって保持される。サーバ１０は所定の判定基準に基づいて利用可能なリソースのワークステーションへとこれらのコンタクトを配分して接続する。リソースは中央サーバ１０の命令によってそれらに送られたコンタクトを処理する。
【００２２】
図１のアーキテクチャで中央サーバ１０が電話コールのようなリアルタイムのコンタクトをリソースへと転送するとき、中央サーバ１０はリソースがさらに良好に顧客の役に立つことを可能にするためにデータベース１２からリソースのコンピュータ・ワークステーションへと（例えばポップアップ表示による）画面もやはり転送する。通常、その情報通知は中央サーバと行き先リソースのワークステーションの間のデータ通信リンクの確立によって達成される。
【００２３】
ある構成では、第１と第２の複数もしくはセットのリソースはコンタクト・センタを運営する業界もしくは企業の従業員および非従業員にそれぞれ相当する。例えば、第２の複数もしくはセットのリソースは請負業者、下請け業者、（入札店を含む）他の組織の従業員などであることが可能である。第１の複数のリソースは中央サーバ／ＰＢＸおよび普通ではセンタへのサービス・コンタクトによって直接サービス提供されるかまたはサポートされる。言い換えると、第１の複数のリソースもしくはリソース／ワークステーションのセットはコンタクト・センタ６によって規定される企業ネットワークへの加入者であるか、またはサーバ／ＰＢＸによってサービス提供される施設内にある。第２の複数のリソースもしくはリソース／ワークステーションのセットは、概して、中央サーバによって直接サービス提供され、かつ／またはサポートされることはなく、通常では第１の複数もしくはセットのリソースから地理的に移動した場所に置かれる。言い換えると、第２の複数のリソースもしくはリソース／ワークステーションのセットは企業ネットワークへの加入者ではないか、または企業ネットワークによってサポートされず、ＰＢＸと中央サーバによってサービス提供される施設の外部にある。第２のセットのリソースはしたがって「外部」である可能性があり、それらはサーバＰＢＸによって端末終点として直接サポートされることはない（例えばそれらが、交換器／サーバによってサービス提供される内部終点に付随する拡張部を有することはない）。これらリソースとの通信は（電話コールのための）ＰＳＴＮ４８を通じて方向付けされ（かつ交換器／サーバの外部ポートで受信され）、データ・ネットワーク４４を通じて（顧客関連情報伝送といったデータ通信のために）方向付けされる。第２のセットのリソースは、例えば本出願と同じ日付に出願され、ここに参考資料で組み入れているＦｌｏｃｋｈａｒｔらの係属中の米国特許出願「Ｃｏｎｔａｃｔ  Ｃｅｎｔｅｒ  Ｒｅｓｏｕｒｃｅ  Ａｌｌｏｃａｔｉｏｎ  Ｂａｓｅｄ  Ｏｎ  Ｗｏｒｋ  Ｂｉｄｄｉｎｇ／Ａｕｃｔｉｏｎ」で検討されている入札タイプの処理を通じて、価値の低い、もしくは利益の少ない作業項目をサービス提供するといったことによって第１のセットのリソースを補強もしくはサポートするために使用される可能性がある。
【００２４】
中央サーバ１０は第１の複数リソースに対応するコンタクトのキュー４２と４６の複数の第１のセット３８を有するメモリ３０を含む。コンタクトのキューの各セットは多様な作業タイプおよび／またはリアルタイム対非リアルタイムについて従来方式でサービス提供し、コンタクト（または作業項目）を保持する。図示した実施形態では、キュー４２は非リアルタイムのコンタクトをサービス提供し、その一方でキュー４６はリアルタイムのコンタクトをサービス提供する。この実施形態は、特に顧客関係管理（ＣＲＭ）環境にとって適しており、そこでは顧客はビジネスにコンタクトするためにいかなる媒体も使用されることが可能である。ＣＲＭ環境では、リアルタイムと非リアルタイムのコントクトの両方が等しい効率と有効性でもって取り扱いおよび分配されねばならない。キューの各々のセットの中で、各々のキューは異なる優先順位および／または異なるタイプのコンタクト（例えばｅメール、ファックス、電子もしくは紙の文書、ウェブ形式の送信、音声メッセージ、音声コール、ＶｏＩＰコール、テキスト・チャット、ビデオコールなど）を保持している。コンタクトの優先順位はよく知られている所定の判定基準に従って決定される。各キューは先入れ先出し（ＦＩＦＯ）バッファ・メモリとして機能することが可能であり、かつ対応する１つのコンタクトの識別各々について複数の作業項目または位置５０を有する。キューの先頭の位置は位置１、次に引き続く位置は位置２等々であると考えられる。キューはまた、非順序化作業キューであることも可能であり、そこではキュー内に含まれる作業項目はＦＩＦＯメモリの中にない。そのような非順序化構成は、例えば異なるサービス時間目標を伴う作業項目を有し、各作業項目の完了に続く作業キューの再配列が有意な量のリソースを必要とするであろう非リアルタイムのキューにとって有利である。
【００２５】
メモリ３０はさらに待ち時間判定エージェント５４を含む。その名前が意味するように、このエージェントはキュー内に置かれるコンタクトがサービス提供するリソースへと供給される前に待たねばならないであろう長さおよび／または既にサービス提供を待ってきた長さの推定値を判定する。その推定値はエージェント５４によって、各セットの各キュー内の各作業項目について別々に導き出される可能性があり、ここでは推定待ち時間（ＥＷＴ）と称する。
【００２６】
リアルタイムのコンタクトについては、推定待ち時間（ＥＷＴ）は、任意の適切なアルゴリズム、例えば、加重された進行時間（ＷＡＴ）と呼ばれるコンタクトの対応する待ち時間行列（キュー）の位置５０を通してのコンタクトの平均進行速度に基づいている。リアルタイムのコンタクトに関するエージェント５４の具体的な導入例は米国特許第５，５０６，８９８号で開示されている。米国特許第５，５０６，８９８号では、自動コンタクト分配（ＡＣＤ）システム内の改善された推定待ち時間配列が設けられ、それは特定のキュー内のキューにあるか、もしくはある可能性のあるコールがエージェントによってサービス提供される前に待たねばならないであろう長さのさらに正確な評価を導き出す。その配列は、特定のキューの複数の位置を通って進むコールの平均速度を使用する。デキューのコールについては、その配列はキューの先頭に向かってあるキュー位置から次に進むコールの個々の速度を判定する。このときそれは、キューを通る最後のデキューのコールの前のコールから導き出されてキューを通る重み付けされた平均進行速度を再計算するためにこの個々の速度を使用する。特定のコールの推定待ち時間を導き出すために、その配列は現在の重み付けされた平均進行速度をキュー内の特定のコールの位置で乗算する。その配列はコールがキュー内にある前もしくは間のいかなる時間にその導き出しを更新するように求められる可能性もある。また、その配列は各々の別のキューについて別々および個々に推定待ち時間の導き出しを実行する。都合の良いことにその配列は、エージェントのログインとログアウト、多重分割／スキルのキューイング、多重スキルを伴うかまたは多重分割にあるエージェント、優先順位キューイング、インターフロー、イントラフロー、およびコール放棄率に起因するキューに従事しているエージェントの数の変化を含む、推定待ち時間に影響するＡＣＤ特徴の効果を考慮に入れている。
【００２７】
非リアルタイムのコンタクトについては、推定待ち時間の評価は概してリアルタイムのコンタクトとは異なって判定される。待ち時間を算出するための１つの取り組み方は２０００年８月１７日に出願され、「Ｗａｉｔ  Ｔｉｍｅ  Ｐｒｅｄｉｃｔｉｏｎ  Ａｒｒａｎｇｅｍｅｎｔ  ｆｏｒ  Ｎｏｎ−Ｒｅａｌ−Ｔｉｍｅ  Ｃｕｓｔｏｍｅｒ  Ｃｏｎｔａｃｔ」というタイトルの米国特許出願番号第０９／６４１，４０３号に述べられている。その出願の中で、選択された作業項目に付随する時間間隔、進行時間、またはその他のタイプのタイミング情報は、キューに付随する米国特許第５，５０６，８９８号の重みづけされた（ウェイトづけされた）進行時間のような待ち時間の推定から除外される。ある構成では、除外された時間間隔、進行時間、またはその他のタイプのタイミング情報は以下の事象、すなわち（ｉ）キューが作業エージェントが作業エージェントを有していない（例えば交換器センタ（またはコンタクト・センタ）が配置されていない）、（ｉｉ）キューが空である（例えばコンタクト・センタが使用されていない作業エージェントを有する）、（ｉｉｉ）コンタクト・センタ（またはコールもしくは交換器センタ）が非稼動中である（例えばコンタクト・センタが閉鎖されているかそうでなければサービス提供していない）、（ｉｖ）コンタクト・センタの作業エージェントがその項目をサービス提供しないように選択している（例えば次の利用可能な作業エージェントがそのサービス項目を保留または拒否することを項目のサービス提供を管理する規則が容認している）、および／または（ｖ）システムのクロックが、（管理者によって、またはそうでなければ）タイミング情報に関してコンタクト・センタによってアクセスされる場合に変えられる事象のうちの少なくとも１つの発生の後に追随する。
【００２８】
メモリ３０はさらに作業項目選択エージェント２６を含むことが可能である。エージェント２６は従来式である。それは利用可能なリソースによってサービス提供されるキューのうちの１つまたは複数から、各コンタクト・タイプに関する待ち時間および／またはビジネス／サービス方針、目的、および目標に基づいて作業項目を選択する。
【００２９】
メモリはさらに、以下で検討されるように、第１のセットのリソースについてあり得る不足または余剰を予測するための作業負荷モニタ用エージェント７０を含む。もしも第１のセットのリソース内で不足が予測されれば、各作業項目に関する入札処理を構成かつ追跡するため、およびそのような作業項目について勝ち残り入札者を選択するために、本出願と同じ日付に出願されたＦｌｏｃｋｈａｒｔらの係属中の米国特許出願「Ｃｏｎｔａｃｔ  Ｃｅｎｔｅｒ  Ｒｅｓｏｕｒｃｅ  Ａｌｌｏｃａｔｉｏｎ  Ｂａｓｅｄ  Ｏｎ  Ｗｏｒｋ  Ｂｉｄｄｉｎｇ／Ａｕｃｔｉｏｎ」で検討されているような入札式項目選択リソース７４が使用されることが可能である。
【００３０】
作業負荷モニタ用エージェント７０は待ち時間判定エージェント５４からＥＷＴ情報を受け取り、各キューの長さ、複数の第１のリソースの中で利用可能なリソースの数、モニタされる各キュー内のコンタクトのタイプと優先順位、および予測される作業負荷の水準をモニタする。この情報に基づいて、各々のコンタクトのタイプについて所定のビジネス／サービス方針、目的、および目標を満足させるためにコンタクト・センタが措置をとらねばならないときを作業負荷モニタ用エージェント７０が予測する。
【００３１】
時間の関数として完了した作業項目の量の予測のグラフによる例示が図２に含まれている。図２に例示されているように、作業項目が時間の関数として取り扱われることが可能な速度は線１０４によって表わされる。正弦波の波形１０８はリソースによって時間の関数としてサービス提供されるべき作業項目の数を表わす。図２に例示した範例では、時間ｔ２よりも前では利用可能なリソースの過剰が存在し、時間ｔ２の後では作業項目の過剰が存在する。もしも作業負荷モニタ用エージェント７０が時間ｔ１で過剰の作業項目の状況を予測すれば、過剰リソースの数を他の用途に利用可能にするといった過剰リソースに付随する措置がとられる可能性がある。もしも作業負荷モニタ用エージェント７０が過剰の作業項目を予測すれば、過剰の作業項目が時間ｔ２よりも前に第２のセットのリソースのうちの１つまたは複数の構成部分に割り当てられるといったリソースの不足に付随する措置がとられる可能性がある。
【００３２】
ここで図３〜４を参照すると、本発明の一実施形態の作業負荷モニタ用エージェント７０の動作がさらに詳細に述べられている。上記で検討したように、作業キュー４２、４６はリソースの特定のプールによってサービス提供されるべき作業項目を含んでいる。図１の実施形態で説明したように、作業キュー４２は非リアルタイムのコンタクトに付随し、１つよりも多くのタイプのコンタクトを有する可能性があり、各コンタクトは異なるサービス時間目標を有する。非リアルタイムのコンタクトはいくつかの異なるタイプのコンタクトを含む「バックオフィス」タイプのコンタクトである可能性がある。例えば、作業キュー４２内の項目は中でもｅメールの照会、ウェブ形式、および購入要求を含む可能性がある。ｅメール照会は１時間のサービス時間目標を有する可能性があり、ウェブ形式は４時間のサービス時間目標を有する可能性があり、購入要求は１日のサービス時間目標を有する可能性がある。一実施形態では、これらのコンタクトはそれらが受信された順序で作業キュー４２内に置かれる。したがって、キュー内の最初の項目はサービス時間目標の満了前の最短の時間量を有する項目ではない可能性がある。キューの最初の項目が（１日のサービス時間目標を有する）購入要求であり、キューの第２の項目が（１時間のサービス時間目標を有する）ｅメール照会であるときにそのような状況が生じる。一実施形態では、作業負荷モニタ用エージェント７０は作業キュー４２、４６の各々を評価し、キューが「目標遅れ」、「目標通り」であるかどうか、「間近の危険」を有するかまたは「将来の危険」を有するかを示すために作業キュー４２、４６の各々に状態を割り当てる。さらに、もしもキューが目標遅れ、間近の危険、または将来の危険の状態にある場合、作業負荷モニタ用エージェント７０は問題を解決するために必要とされるリソースの量について予測をたてるように動作することが可能である。もしも将来の危険状態が予測されれば、作業負荷モニタ用エージェント７０はシステムが危険な状態に入るであろうときの予測をたてるように動作することもやはり可能である。
【００３３】
作業キュー４２、４６の状態を判定するとき、作業負荷モニタ用エージェント７０は作業項目の現在の状態をそれらの個々のサービス時間目標に関して判定するために、事象ベースおよび／または期間ベースで作業キューもしくはプールを調査するであろう。上述したように、キューもしくはプール内の各々の作業項目がサービス時間目標を有するであろう。キューもしくはプール内の各々の作業項目に関する残り時間は、
残り時間＝（サービス時間目標）−（現在の時間）
として算出されることが可能である。もしもいずれかの作業項目が負の残り時間を有する場合、作業項目および作業キューの状態は「目標遅れ」である。一実施形態では、そのような状況で作業負荷モニタ用エージェント７０は目標遅れの状態を示すために適切なメッセージを発生する。そのメッセージは、そのときに問題を改善するために措置をとることが可能な適切な作業者またはソフトウェア・システムへと送られることが可能である。メッセージは適切な作業者への電子的通知、ユーザ・インターフェース上の表示、またはその他の表示である可能性がある。一実施形態では、作業負荷モニタ用エージェント７０はその後、先に進んで作業キュー内の作業項目の各々について必要なキュー位置を算出する。別の実施形態では、もしも目標遅れの状態が検出されると、作業負荷モニタ用エージェント７０は適切な警報を単純に発生し、必要なキュー位置を算出するために先に進むことはない。
【００３４】
必要なキュー位置を判定するとき、キューに関するＷＡＴが判定される。上述したように、ＷＡＴはキューから由来する各サービス事象間の平均経過時間である。例えば、もしも作業項目が６秒毎に１つの平均速度でキューからサービス提供される場合、そのキューに関するＷＡＴは６秒であり、それは例えばキュー内の第２の項目が１２秒以内に完了されると予測されるであろうことを意味する。いったんＷＡＴが判定されると、その後、キューもしくはプール内の各作業項目に関する必要なキュー位置が、ＷＡＴで除算された作業項目に関する残り時間として算出され、隣りの整数へと端数切り捨てされる。例えば、もしも作業項目がそのサービス時間目標の前に２０秒の残り時間を有し、かつそのキューもしくはプールに関するＷＡＴが６秒である場合、サービス時間目標を満足させるために、その作業項目はその次の３つのエージェントのうちの１つによってサービス提供されてこのキューからサービス作業を利用可能になる必要があると予測される。したがって、その作業項目に関する必要なキュー位置は３である。
【００３５】
ここで図３を参照すると、キュー内の作業項目の各々について必要なキュー位置を算出するための操作工程を具体的に示すフローチャート図がここに記述されている。作業キューもしくはプール内の作業項目に付随する順序化されたリストが作成され、それはある実施形態では必須キュー位置アレー（「ＲＱＰＡ」）と称されるカウンタ・アレーである。ＲＱＰＡ内の各々の要素は、必須キュー位置の間で完了されることを必要とする作業項目の数を示す。必須キュー位置はＲＱＰＡ内の要素の位置によって示される。したがって、ＲＱＰＡ内の第２の要素は必須キュー位置２を備えた作業項目の数を示す。ＲＱＰＡとは無関係であって「目標遅れ計数」と称されるカウンタもやはり作業キューもしくはプールに付随し、目標よりも遅れている作業項目の数を示す。ブロック１５０で示したように作業キューの評価が開始される。ブロック１５４で示したようにＲＱＰＡの各要素がゼロに初期化され、かつ目標遅れ計数がゼロに初期化される。これはＲＱＰＡの各要素および目標遅れ計数がゼロの値を有するように設定することによって達成される。ブロック１５８で、作業キュー内の最初の項目が走査される。ブロック１６２で気付かれるように、その作業項目について必須キュー位置（「ＲＱＰ」）が算出される。その作業項目の必須キュー位置の算出に続いて、ブロック１６３で気付かれるように必須キュー位置がゼロ未満であるかどうかが判定される。負の必須キュー位置は、残り時間が負であってその作業項目が目標よりも遅れていることを示す。もしも必須キュー位置が負であれば、ブロック１６４に従って目標遅れ計数が増分を与えられる。もしも必須キュー位置がゼロ以上であれば、ブロック１６６に従って必須キュー位置に対応するＲＱＰＡアレー、ＲＱＰＡ［ＲＱＰ］内の要素が増分を与えられる。その後、ブロック１７０で、作業キュー内にさらに作業項目が存在するかどうかが判定される。もしもそれ以上作業項目がなければ、ブロック１７１で目標遅れ計数がゼロよりも大きいかどうかが判定される。目標遅れ計数が０より大きくない場合、ブロック１７４に示すようにＲＱＰＡが分析される。もしも目標遅れ計数がゼロよりも大きければ、ブロック１７２に従って作業負荷モニタ用エージェントが現在の状態を「目標遅れ」であると設定し、それは問題の時間が現在の時間であること、および問題の程度が目標遅れ計数であることを示す。もしも作業キューの中にさらに作業項目が存在すれば、ブロック１７８に従って作業キューの中の次の作業項目が走査される。次の作業項目の走査に引き続いて、ブロック１６２から１７８に関して述べた操作工程が繰り返される。その結果、作業キューの評価に追随してＲＱＰＡが作成され、それはＲＱＰＡのキュー位置に対応する時間までに完了されるべき作業項目の数に対応する各アレー要素内の項目を含む。
【００３６】
ここで図４を参照すると、本発明の一実施形態についてＲＱＰＡを分析するための操作工程が記述されている。最初にブロック２００で気付かれるように、必須キュー位置アレーの要素ゼロ（ＲＱＰＡ［０］）がゼロよりも大きいかどうかが判定される。これは必須キュー位置ゼロを１つまたは複数の作業項目が有することを示し、それは作業項目が前の利用可能になったエージェントによってサービス提供されるべきであったことを示す。作業項目を処理することが可能な次のエージェントが利用可能になる時間までに、作業項目がそのサービス時間目標を既に逃しているであろうことはありがちである。そのようなケースでは、ブロック２０４で示されるように作業負荷モニタ用エージェントは現在の状態を「間近の危険」であると設定し、それは問題の時間が現在の時間であること、および問題の程度がＲＱＰＡ［０］の値であることを示す。もしもＲＱＰＡ［０］がゼロであると判定されれば、ブロック２０８で作業負荷モニタ用エージェント７０は指標変数を１に設定し、和変数をゼロに設定する。その後、ブロック２１２で気付かれるように、作業負荷モニタ用エージェント７０は和変数を和と、指標変数に対応する必須キュー位置アレーの要素の値を加えた合計（Ｓｕｍ＝Ｓｕｍ＋ＲＱＰＡ［Ｉｎｄｅｘ］）であると設定する。その後、ブロック２１６で、その和が指標よりも大きいかどうかが判定される。もしも和が指標よりも大きい場合、これは完了される必要のある作業項目の合計数が、ＷＡＴで測定されたサービス作業項目の現在の速度で完了されると予測される作業項目の合計数よりも大きいことを示す。
【００３７】
もしも和が指標よりも大きい場合、システムの状態は「将来の危険」に設定され、予測される問題の時間は指標とＷＡＴの積（Ｉｎｄｅｘ×ＷＡＴ）であり、問題の程度は和と指標の間の差（ｓｕｍ−Ｉｎｄｅｘ）である。ブロック２１６でもしも和が指標よりも大きくない場合、ブロック２２４に従って指標が増分を与えられる。ブロック２２８でＲＱＰＡの終端に到達しているかどうかの判定がなされる。もしもＲＱＰＡの終端に到達していれば、システムの状態は「目標通り」であり、それはその作業キューもしくは作業プール内にある作業項目に関するリソースに予測される不足が存在しないことを意味する。もしもブロック２２８でＲＱＰＡの終端に到達していないと判定されると、ＲＱＰＡの終端に到達するかまたは「将来の危険」の状態が見出されるかのいずれかまでブロック２１２から２２８の操作工程が繰り返される。例えば、もしも指標が６であり、かつ必須キュー位置６以下を備えた作業項目の和が９（Ｉｎｄｅｘ＝６、Ｓｕｍ＝９）であれば、これは３つの作業項目がそれらのサービス時間目標までに完了されないと予測されることを示す。もしもＷＡＴが１５秒である場合、この問題が生じるであろう時間は９０秒（Ｉｎｄｅｘ×ＷＡＴ＝６×１５＝９０秒）であると予測される。問題の程度は３つの作業項目であると予測される。一実施形態では、この情報はユーザ・インターフェース上に表示され、そのときにその問題を発生前に修正するように試みることが可能な適切な作業者またはソフトウェア・システムに電子的通知が転送される。図４の実施形態は問題の証拠が検出されると停止するが、別の実施形態ではたとえ「将来の危険」の状態が見出されてもすべてのあり得る問題および／または最も重大な問題を見出すためにアレー全体が走査される。
【００３８】
さらに、一実施形態では、作業負荷モニタ用エージェント７０は例えば過剰のリソースが予測される作業キューをモニタする。例えば、システムの状態が「目標通り」である場合、作業負荷モニタ用エージェント７０はいくつの過剰リソースが利用可能であるかを判定することが可能である。例えば、そのような過剰リソースは異なる機能へと割り当てられることが可能である。過剰リソースの数および過剰の時間を判定するとき、上述したものと同様の計算が利用されることが可能である。和とＲＱＰＡ内の要素に付随する最大数キュー位置の間の差が、キュー位置に付随する時間について予測される過剰リソースの数を示すのに使用されることが可能である。例えば、もしも和が２０であり、かつＲＱＰＡの要素に付随する最大キュー位置が３０である場合、これは作業キュー内の作業項目に関するサービス時間目標を維持しながら、１０の過剰リソースがその時点で利用可能であると予測されることを示す。もしもシステムの状態が「目標通り」である場合、これは、過剰のリソースの除外がシステムの状態を将来の危険へと置かないならば、現在そのキューにあるすべての作業項目に関するサービス時間目標を維持しながら、これらの過剰リソースが他の仕事のために使用されることが可能であることを示す。
【００３９】
見受けられるように、上記で供給されるシステムと方法は生じ得る問題の時刻、ならびに生じ得る問題の範囲の両方の結果を作り出し、それは生じ得る問題の事前の解決に有利である。さらに、このシステムと方法は順序化された作業キューならびに非順序化作業キューもしくは作業プールの両方に使用されることが可能である。これは、各々の作業項目がその必須キュー位置に関して評価され、その必須キュー位置を有する作業項目が走査される度に増分を与えられる必須キュー位置に対応する要素をカウンタ・アレーが有する結果である。したがって、たとえ作業項目が順序化されていないとしても、各項目が走査されるとき、その必須キュー位置はカウンタ・アレー内に含まれ、それはその後、作業キューもしくは作業プールの状態を判定するために使用されることが可能である。
【００４０】
図３〜４の実施形態がサービス待ちしている作業項目の状態を評価するために使用されることが可能な多くの技術のうちの１つの具体例であることは理解されるであろう。サービスを待っている作業項目に付随する順序化されたリストを作成し、分析するための他の代替選択肢が存在し、当業者によって容易に理解されるであろう。例えば、必須キュー位置アレーが、アレー内の要素の位置に等しい数値を有するアレー内の各々の要素で初期化されることが可能である。したがって、アレーの位置１は値１を有し、アレーの位置２は値２を有する等々、であろう。作業項目が評価されて作業項目に関する必須キュー位置が判定されるとき、必須キュー位置以上に付随する必須キュー位置アレー内の要素の値は減少分を差し引かれることが可能である。この方式で、必須キュー位置内の要素は、サービスを待っている作業の状態を示すために更新される。その後、ＲＱＰＡがいかなる負の項目についても走査されることが可能であり、それは、その必須キュー位置に付随する時間の前に完了されると予測されるよりも多くの作業項目が存在することを示すであろう。
【００４１】
別の実施形態では、カウンタ・アレーはすべての必須キュー位置をアレーの要素として含むわけではなく、必須キュー位置のある範囲が特定のアレー要素に割り当てられる。図５はカウンタ・アレー２５０、およびそれに対応してアレーの各要素２５８に付随するキュー位置２５４を具体的に示す表である。この実施形態では、カウンタ・アレー内の要素に関すると、アレー内の各要素２５８（「Ｎ」）は２Ｎ−１＜ＲＱＰ≦２Ｎの範囲内の必須キュー位置（「ＲＱＰ」）を有する作業項目の数を格納している。したがって図５の表に具体的に示したように、例えば、アレー要素３は５から８の範囲内のＲＱＰを有する作業項目の計数を含み、アレー要素４は９から１６の範囲内のＲＱＰを有する作業項目の計数を含むであろう。この実施形態では作業項目を走査するとき、ゼロのＲＱＰを有するいかなる作業項目もシステムを「間近の危険」の状態に置き、その後、いかなる将来の危険の状態も判定するためにアレーが分析される。
【００４２】
アレーの分析は、すべてのＲＱＰではなく規定の範囲のＲＱＰ内の生じ得る問題を検出することが可能である。もしも作業キューが大きなサイズである場合、この実施形態はアレーがはるかに短くなるせいで性能の向上に結びつき、したがってさらに少ないシステム・リソースしか消費しない。この実施形態では、１０の要素を含むカウンタ・アレーは約１０００の作業項目の作業キューもしくは作業プールを扱うことが可能である。付け加えると、この実施形態は、比較的短い時間量で満了するサービス時間目標を有し、検出されるいかなる問題にも反応する時間が少ない作業項目により一層大きく焦点を当て、その一方で、比較的長い時間量で満了するサービス時間目標を有する作業項目に付随した問題は概算の時間範囲で示される。下位の必須キュー位置の上昇した細分性が短期の問題への迅速な注意を可能にし、その一方で上位の必須キュー位置の低下した細分性がさらに長期の計画立案と解決策を可能にする。その結果、もしも生じ得る問題が例えば必須キュー位置６５〜１２８で検出されれば、適切な作業者が警報を受けることが可能であり、その後、生じ得る問題が必須キュー位置４で検出される状況と比べて正しい措置をとるための比較的長い時間的期間を有する。図５の実施形態は２のべき乗のＲＱＰ範囲を使用するが、当業者によって容易に理解されるように、そのようなアレー内の要素に関してどのような範囲のＲＱＰも使用される可能性がある。
【００４３】
本発明のこれまでの考察は具体的例示と説明を目的として提示されてきた。さらに、本説明はここで開示した形式に本発明を限定することを意図するものではない。したがって、関連技術の技術と知識の中にあって上記の教示と相応の変形例および改造例は本発明の範囲内にある。以上に説明した実施形態はさらに、本発明の実施の現在知られている最良の形態を説明すること、および他の当業者が彼らの特定の本発明の用途もしくは使用法によって必要とされる様々な変更を伴ってそのようなもしくはその他の実施形態で本発明を使用することを可能にすることを意図している。先行技術によって許容される範囲に対する代替選択肢の実施形態を含むように添付の特許請求項が解釈されることを意図する。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態のコンタクト・センタを示すブロック図である。
【図２】作業項目の量（縦軸）対時間（横軸）を示す図である。
【図３】本発明の一実施形態の、作業項目に関する必須キュー位置を算出するための動作工程を例示するフローチャート図である。
【図４】本発明の一実施形態の、カウンタ・アレーを分析するための動作工程を例示するフローチャート図である。
【図５】本発明の一実施形態により、カウンタ・アレーの要素および各要素に付随する必須キュー位置の範囲を例示する表である。
【図１】
0004842529.tif 000002
【図２】
0004842529.tif 000003
【図３】
0004842529.tif 000004
【図４】
0004842529.tif 000005
【図５】
0004842529.tif 000006