JP2016140066A - 独立したカスタマーサービスエージェント - Google Patents

Abstract

【課題】エージェントノードにコンタクトを自動的に分散させるためのシステムと方法とを提供する。【解決手段】測定指標サービスはコントローラサービスに接続されている。コネクティビティコントローラはＳＩＰシグナリングを使用してテレフォンコールを処理するメカニズムを扱い、他のシステムによるコールの処理を可能にする機能を提示し、システムを介して電話イベントを伝播させることができる。併せて顧客電話をエージェント電話に接続することができる。メディアサーバはアナウンスの機械的な再生を処理し、システム内の復数の異なるコンテクストにおいて音楽を保持する。顧客が保留状態にあるときに顧客をこのサーバに接続することができる。コールレコーダシステムは顧客コールを記録する。【選択図】図１

Description

関連出願の相互参照
本発明は、アメリカ合衆国仮特許出願第60/987,744号、Jay等、発明の名称「Global Automatic Call Distribution」、２００７年１１月１３日出願、および、アメリカ合衆国仮特許出願第61/037,678号、Jay等、発明の名称「Global Automatic Call Distribution」、２００８年３月１８日出願の優先権を主張するものである。これら仮特許出願の内容は全て参照により本明細書に組み込まれている。

多くの企業は販売前および販売後に顧客とコンタクトを取る機会がますます増えてきている。コールセンターは、例えば、販売ならびにマーケティングコンタクト、テクニカルサポートおよび請求書などの種々のコンタクト状況にわたる大量のコールを処理するための集中型のスケーラブルなメカニズムとして開発されたものである。しかしながら、コールセンターは種々の短所を有している。

例えば、コールセンターコントローラは各コールセンターにおける顧客コールのキュー長を推定し、最も待機時間が短いと思われるキューに特定のコールをルーティングする。判断が正しくない場合、コールはその後異なるコールセンターに転送されない可能性がある。これによって、他のコールセンターのエージェントを利用可能であっても、顧客が１つのコールセンターにおいて待ち続ける事態が引き起こされる可能性がある。この仕様に基づき種々のコールセンター間でサービスレベルが異なる可能性があり、これはネットワーク全体のサービスレベルに悪影響を及ぼす可能性がある。

コールセンターはリアルタイム情報の遅れに起因してコールバースト、すなわちコール量の突発的な増加も経験する可能性がある。リアルタイム情報は数秒の時代遅れ（out of date）の古いものになる可能性がある。コールセンターコントローラが時代遅れの情報に基づきルーティングの判断を行う場合、過度に多くのコールを１つの小さいコールセンターにルーティングしてしまうか、顧客のキューの長さを誤って推定してしまう可能性がある。これを処理することを意図したヒューリスティックスが存在するが、それらのヒューリスティックスは幾つかのケースに分類されることが考えられ、したがって全体のシステムがより複雑になる傾向にある。さらには、コールセンターコントローラがコールをひとたびコールセンターにルーティングしてしまえば、コールセンターコントローラには制限が課され、転送にどれ程の時間が掛かったのか、また転送は成功したのか否かも分からなくなる可能性がある。ヒューリスティックは単純な問題を処理するために存在するが、（例えば非標準的なルーティング、または障害のあるキャリアのルーティングに起因する）緩慢な転送期間は依然としてコールバーストを生じさせる可能性がある。

さらにはコールセンターが、このコールセンターを運営している組織によって管理されていない基礎となるプラットフォームに依存している可能性もある。つまり、例えば、基礎となるプラットフォームに問題がある場合に、コールセンターはその問題に直接的に対処できない可能性がある。むしろ、これらの問題点を単に許容するようにコールセンターコントローラを設計することが考えられる。これにより、基礎となるプラットフォームにおける問題を検出するよう設計されたヒューリスティックを有する多数の「ウォッチャー」システムが形成されることになる。しかしながらそのようなウォッチャーシステムによって生成されるコードは複雑になる可能性がある。

コールタイプを基礎としたコールのルーティングは多くの理由により、すなわち、（１）コールルーティングの決定は種々異なる場所でなされる可能性がある（すなわち、決定が分散的に行われる可能性がある）、（２）コールルーティングは構内交換機（ＰＢＸ；Private Branch eXchange）の能力に制限される可能性がある、（３）リアルタイム情報が利用可能でない可能性がある、といった理由により困難になる可能性がある。これら全ての問題点は、より小さいルーティングキューを効果的に管理するタスクを過度に困難にする可能性がある。ルーティングにおける非能率により、コールセンターに過剰な割り当て（つまり、センターのエージェントは自身に割り当てられたコールの割合よりも多くのコールを受信しているか、受信した）が行われるか、不十分な割り当てが行われる可能性がある。コールセンターリソースの過剰な割り当ておよび不十分な割り当てにより、カスタマーサービスエージェントは過度に忙しくなるか、暇になる可能性がある。そうなるとカスタマーサービスエージェント間での摩擦が増加しかねない。さらには、過剰な割り当てまたは不十分な割り当て、および／または、コールの区分とエージェントのスキルの釣り合いにおけるその他の非能率により、顧客が安定していないレベルのサービスを受ける可能性がある。

改善されたルーティングアルゴリズムによりコールセンターのオペレーションにおける非能率を改善することはできるが、この非能率を無くすことはできない。殊に、何らかの特定の期間においては、到来するコールの量、すなわち着信量がカスタマーサービスエージェントの利用可能数を上回るか、その数に達しない可能性がある。したがって、種々のコールとエージェント数との間での１対１の対応を達成することは困難になる。コールボリュームのばらつき（到来するコールのタイプのばらつきを含む）は系統的な経過と無作為な経過の両方に帰すことができる。例えば、１日のピーク時中のコールボリュームは同日の非ピーク時のコールボリュームの２倍にもなる可能性がある。ピーク日には休みの日に比べてより多くのコールが見込まれる。さらには、無作為（または単に予測不可能）な変化もコールボリュームに影響を及ぼす。ソフトウェアメーカがバグのある製品をある日リリースしたならば、その次の日のコールボリュームは、困惑した顧客が何故新しいソフトウェアが正常に動作しないのかを尋ねるために通常に比べて著しく多くなる可能性がある。

カスタマーサービスエージェントのアベイラビリティはコールボリュームの変動の遭遇に適していないことが考えられる。コールセンターの人員配置が数週間または数ヶ月にわたり事前に計画されることも考えられる。さらには、時間内ボリュームの大きな予測外のピークには全く対処できなくなるであろう。マネージャがさらなるエージェントが必要であることに気付き、そのようなエージェントと連絡を取り、それらのエージェントを使用できるようになったときには、短期間のピークは既に過ぎてしまっていることが考えられる。反対にコールボリュームが少ない期間では、貴重なコールセンターリソースを使用しながらも仕事の無いカスタマーサービスエージェントが現われることも考えられる。

以上の考察の原理は電話を基礎とするコールセンターに限定されるものではない。他の種類の分野もサービスに対する需要を供給に適合させることが困難であることによって同様に影響を受けることが考えられる。例えば、Ｅメール応答センター（例えば、顧客のＥメールによる問合せにエージェントが応答するセンター）も同様に予測不能な大量のＥメールに直面する可能性がある。

本発明に伴う多くの利点および態様は、以下の詳細な説明および添付の図面を参照することにより容易に認められ、またより良く理解される。

顧客とカスタマーサービスエージェントとの間のコンタクトを管理するための例示的なコール分散システムの概略的なブロック図を示す。 図１に示されているようなシステムのコールキューイングおよびコールルーティングコンポーネントの詳細を表す概略的なブロック図を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているようなシステムによって分散されるコールにカスタマーサービスエージェントが影響を及ぼすことを可能にするユーザインタフェースの例示的な構成要素を示す。 図１に示されているシステムを使用するカスタマーサービスエージェントに対するキャパシティ情報を記憶している例示的な割当テーブルを示す。 図１に示されているシステムを使用するカスタマーサービスエージェントに対する例示的な履歴ルーティング情報を示す。 図１に示されているシステムを使用するカスタマーサービスエージェントに対する例示的な履歴ルーティング情報を示す。 図１に示されているシステムを使用するカスタマーサービスエージェントに対する例示的な履歴ルーティング情報を示す。 図１に示されているシステムを使用するカスタマーサービスエージェントに対する例示的なコンフィギュレーション情報を示す。 図１に示されているシステムによって管理されるエージェントサブノードに関する例示的なサンプルリアルタイムデータ、殊にコールアクティビティを示す。 図１に示されているシステムによって記録することができる潜在的なコール測定指標の例示的なテーブルを示す。 図１に示されているシステムによって管理されるエージェントサブノードおよびカスタマーサービスエージェントに関する例示的なサンプル履歴データを示す。 特定のカスタマーサービスエージェントに関する例示的なサンプル履歴データを示す。 図１に示されているシステムによって記録することができる統計量の例示的なテーブルを示す。 図１に示されているシステムによって記録することができる統計量の例示的なテーブルを示す。 図１に示されているシステムによって記録することができる統計量の例示的なテーブルを示す。 複数のタイプのコンタクトを独立したカスタマーサービスエージェントにルーティングするために、市場を基礎とした価格情報を利用することができる例示的なコンタクト分散システムの概略的なブロック図を示す。

概観
顧客、発呼者または他のユーザからのコールまたは他のタイプのコンタクト、例えば電子メールメッセージ、テキストメッセージ、ワークアイテムリクエストなどをカスタマーサービスエージェント（ＣＳＡ）に自動的に分散するための方法およびシステムを説明する。幾つかの実施形態により、標準的な閉じられた電話システムおよび高価なプロプライエタリな電話機よりも適した、オープンセッション開始プロトコル（ＳＩＰ；Session Initiation Protocol）標準および廉価な「オフ・ザ・シェルフ」な機器を取り巻くコール分散機能を確立することができる。そのような実施形態は、（企業内の従業員のために頻繁に使用されるような廉価なＳＩＰ電話交換機を含む）あらゆる電話システムによってサポートされ、カスタマーサービスエージェントに直接的にダイアルすることができる機能を超えるものはコール分散システムに要求しない。したがってそれらの実施形態により、コールセンター（本明細書においては「エージェントノード」とも称する）に比較的廉価な電話機ハードウェアを備えさせることができる。さらにそのような実施形態では、アウトソーサーズと電話を軸にした商業パートナとを、それらの既存の電話システムに依存せずに容易に統合させることができる。またそのような実施形態は、新たなカスタマーサービスの作業シナリオ、例えば自宅からのＣＳＡ業務、また非常に高価で本格的なＰＢＸまたは他の構内交換機システムを用いることのない廉価な期間「ショッピングモール」エージェントノードの準備もサポートすることができる。

幾つかの実施形態は集中型のコールキュー管理を可能にする。集中型のキュー管理は高度なコールルーティングを実現し、そのようなコールルーティングにより顧客の保留時間を短縮することができる。もしくは、同一の顧客負荷を既存のネットワークと同じサービスレベルで処理する回数を減らすことができる。そのような集中型のキュー管理は、電話のキューが従来のように各コールセンターにおいて維持管理される場合に発生する非能率を低減することができる。そのような実施形態はルーティングの決定を可能な限り長く、例えばコールを受けるためにエージェントが利用可能になるまで遅らせる。これによりネットワーク全体のサービス品質を改善することができる。集中型のコールキュー管理によりネットワーク内の全てのエージェントノードの一様なサービス品質レベル（ＳＬ）を維持することができる。

例示的なコール分散システムのコンポーネント
図１は、顧客からＣＳＡへのコールを自動的に分散させるための例示的なコール分散システム１００を示す。さらに図２は、殊にコールキューイングおよびコールルーティングに関するシステム１００の例示的な付加的な構成要素を示す。以下において説明する構成要素の内の多くは任意のものであると解され、システムのその実施形態は複数の構成要素を組み合わせることができるが、複数の構成要素を組み合わせなくてもよい。複数の構成要素が異なるもの、または別個のものである必要はない。構成要素をシステム内で再編することができる。システムは、以下において説明する全てのサブシステムを含む単一の物理的なサーバにおいて表すことができるか、システムを複数の物理的なサーバに分割することができる。

システム１００はカスタマーリレーションモジュール（ＣＲＭ；customer relations module）１０１、コールコントローラサービス１０２、コネクティビティコントローラ１０３および測定指標サービス１０４を有することができ、これらは各々ハードウェア、ソフトウェアまたはそれらの組み合わせで表すことができる。システムは顧客（典型的には電話口の顧客）１０５とＣＳＡ電話１０６とコンピューティングデバイス１０７との間のコネクションの割り当て、ルーティングおよび維持管理に対して権限を有している。システムは典型的には、電話キャリア１０８および１０９およびデータキャリア１１０を介して顧客とエージェントを接続する。

１つの実施形態においては、ＣＲＭ１０１によりシステム１００は顧客とのコンタクトおよびリレーション、すなわち関係を管理することができる。ＣＲＭを種々のデータベース（図示せず）から構成することができ、また他のシステムとのリンク（図示せず）を有することができ、これらはいずれも直接的および間接的に顧客コンタクト管理と関連付けられている。ＣＲＭはエージェントノードを管理するためのビジネスロジックも提供することができる。

コールコントローラサービス１０２は到来する顧客コールを処理する：この顧客コールは以下のものを含むが、それらに限定されるものではない：エージェントの状態／利用可能性の追跡（すなわち、到来する顧客コールを処理するためにどのエージェントが利用可能であるか）、（保留中の顧客がメディアサービス１１２に接続できる間に）特定のＣＳＡまたはコールタイプに関して保留中の顧客の（場合によっては順番通りではない）論理キュー（図示せず）の維持；コールのルーティング、すなわち利用可能なエージェントと到来する顧客コールとの組み合わせ；電話サブシステム（１０３および付随するコンポーネント）のオペレーションによって生成された情報の測定指標サービス１０４への転送。

測定指標サービス１０４は典型的にはコールコントローラサービス１０２に接続されている。このサービスは顧客コールおよびＣＳＡの両方に関する情報を記憶する。さらには、このサービスはリアルタイムデータおよび履歴データに基づいてレポート（例えばＳＬレポート）を作成することができる。測定指標サービスはコールコントローラサービス１０２に情報を提供することができる。

コネクティビティコントローラ１０３はＳＩＰシグナリング（ボイス・オーバＩＰ技術）を使用してテレフォンコールを処理するメカニズムを扱い、他のシステム（例えばコールコントローラサービス）によるコールの処理を可能にする機能を提示し、システム１００を介して電話イベントを伝播させることができる。コネクティビティコントローラ１０３は顧客電話１０５をエージェント電話１０６に接続することができる。コネクティビティコントローラ１０３は以下のサブシステム、すなわち、メディアサーバ１１２、自動音声応答装置（ＩＶＲ；interactive voice response）システム１１３およびコールレコーダシステム１１４を使用することができる。

メディアサーバ１１２はアナウンスの機械的な再生を処理し、システム内の複数の異なるコンテクストにおいて音楽を保持する。顧客が保留状態にあるときに顧客をこのサーバに接続することができる。このシステムは、ＣＳＡが顧客に接続される直前に、ＣＳＡへの「つぶやき」（すなわち、連絡的な前置きのメッセージ）を再生することができる。

自動音声応答装置１１３は、顧客が繋がったＣＳＡに転送される前に、顧客コールを時々処理する「ロボット」でもよい。ＩＶＲは、コールをルーティングするため、および／または、コールタイプを分類するために使用される予備的な情報を取得することができる。

コールレコーダシステム１１４は顧客コールを記録する。コールレコーダは行われているコールまたは行われたコールをシステム１００内のどこでも聞けるようにするための共通のインタフェースを提供することができる。

ＣＳＡは典型的にはシステムとの２つのコネクション、すなわち参照番号１０７で表されたコンピューティングマシンコネクションと、参照番号１０６で表された電話コネクションとを有することになる。コンピューティングマシンは一般的にシステム１００とのユーザインタフェース１１１を表示することができる。当業者であれば、１人または複数のＣＳＡを通常のモノリシックなコールセンター内に配置できることが分かる（ただし、ＣＳＡおよびシステム１００は物理的に近接している）。択一的に、ＣＳＡが他のＣＳＡ（例えば「コールセンター」内のＣＳＡ）に近接させて配置されていることも考えられるが、システムからは離されている（この場合は「データセンター」内に収容されることなる）。さらに別の択一形態として、１人または複数のＣＳＡをシステムデータセンターおよび他のＣＳＡの両方から離すことができる。「コンピューティングマシン」という術語自体は広範に制限なく使用されており、システム１００からのユーザインタフェースを表示することができるあらゆる種類の通信装置、例えばＰＣ、キオスク、シンクライアント、ホームコンピュータ、専用マシンまたは組み込みマシンが含まれる。同様に、エージェント電話システムも広範に制限なく使用されており、専用電話装置、ＶｏＩＰ装置、複合型ＰＢＸシステム、通常の電話線上のオフ・ザ・シェルフ電話などが含まれる。幾つかの実施形態において、ＰＢＸまたは他の電話交換システムを介してエージェント電話システム１０６を接続することは必要ではない。さらには本明細書の目的に関して、物理的にはモノリシックなコールセンターかデータセンター内の１つまたは複数のＣＳＡのグルーピング、論理的には、例えば相互に近接していないＣＳＡのグルーピングをエージェントノードとも称する。

ＣＳＡユーザインタフェース１１１はコールコントローラサービス１０２またはＣＲＭ１０１からのコンテンツを表示する。そのようなインタフェースはコンピューティングマシンにおいて実行されるプロプライエタリなアプリケーションでよい。択一的に、インタフェースはコールコントローラサービス１０２またはＣＲＭ１０１によって形成された、さもなければ提供されたウェブページ、ブラウザ、アプレットなどを表示することができる。システム１００とユーザインタフェース１１１との間のリンクはデータキャリアのあらゆるホスト、ＨＴＴＰ、ＨＴＴＰＳ、インスタントメッセージ、分散メモリまたはプロプライエタリプロトコルを含むプロトコル、もしくはそれらの組み合わせによって媒介される。

参照番号１０５でもって表されている顧客および顧客電話システムはコールシステム１００のエンドユーザに相当する。そのような顧客は一般的に電話キャリア１０８の内の１つを介してシステムに接続される。そのようなコネクションは比較的新しい、慣例のものではないプロトコル、例えばＳＩＰ、ＨＴＴＰ、ＩＲＣ、他のインスタントメッセージプロトコルなどを介しても確立することができる。顧客を廉価な電話装置、複合型ＰＢＸシステムまたは通信の他のあらゆるメカニズムを使用するシステムと接続することができる。

システムオペレーションおよびＣＳＡの利用可能性
１つの実施形態によるシステム１００と顧客とＣＳＡとの間のインタラクションの概観を説明する。ＣＳＡには自身のコンピューティングマシン１０７においてＣＲＭ１０１とのユーザインタフェース１１１を提供することができる。リンクは直接的なものでよい。もしくは、リンクをコールコントローラサービス１０２によって媒介させてもよい。利用可能性をシステムにシグナリングするために、ＣＳＡはキーを押すか、コンピューティングマシン１０７におけるＣＲＭユーザインタフェースからユーザインタフェースコントロールを選択することができる。続いてコールコントローラサービス１０２は、コネクティビティコントローラ１０３を介してＣＳＡの電話システム１０６を用いたＣＳＡとのコールを開始することができる。ＣＳＡはこのコールに応答し、顧客からのコールに対し準備が整っており、受け入れ可能であることをシステムにシグナリングする。

キューにおいてサービスを待機している顧客がいない場合、ＣＳＡは利用可能状態が継続していることを指示するために、システムとのこの静かに開かれている（すなわち受話器が外れている）コネクションを継続することができる。利用可能状態から利用不可能状態への移行（例えば昼食を取る、もしくはコーヒーブレークを取るため）をシグナリングするために、ＣＳＡは単純に受話器を置くことができる。コネクティビティコントローラ１０３とのコネクションが切断されたことにより、ＣＳＡはもはや顧客コールを取ることができない（またはＣＳＡは例えばネットワーク内の障害に起因してシステムから意図せずに切り離された）ことがＣＳＡにより指示されていることを、コールコントローラサービス１０２およびＣＲＭ１０１にシグナリングすることができる。

択一的に、ＣＳＡが利用可能状態であることをシグナリングしているときに、コールコントローラサービス１０２によって維持管理されている集中型のキューにおいて待機している顧客が存在するならば、コネクティビティコントローラ１０３によって顧客とＣＳＡを即座に接続することができるか、ＩＶＲ１１３によって提供されるコールに関する情報、例えばコールタイプまたは顧客区分を指示するつぶやきの直後に接続することができる。つぶやきの代わりに、またはつぶやきに加えて、ＣＲＭ１０１はＣＳＡのユーザインタフェースに提供されるべきコール、顧客もしくはＣＳＡに関する情報を提供することができる。そのような情報を例えば「ポップアップ」または「バブル」として表示することができる。つぶやき、ポップアップ、バブルおよび状況情報を通知する方法をコール中に使用することもできる。つまり、例えば、ＣＲＭ１０１がコールの最中に顧客に関する付加的な情報を導き出した場合、ＣＲＭはそのような情報を対応中のＣＳＡにつぶやくまたは表示することができる。

コールが終了した後に、ＣＳＡは受話器を置き、その後に「アフター・コール・ワーク（After Call Work）」状態に入ることができる。当業者であれば、この状態はＣＳＡが例えばメモを書き、他のＣＳＡにコールし、コンセッションを承認するなどにより、コールのディブリーフィングまたはアフター・アクション・レビューを行う時間に相当するものであることが分かる。ＣＳＡが別のコールを取る準備が整うと、ＣＳＡは利用可能状態を改めて上記のようにシグナリングすることができる。

ＣＲＭシステム１０１が故障すると、ＣＳＡはシステムに利用可能性をシグナリングするためのボタンを押すことができない、またはクリックすることができない、もしくはＣＳＡがボタンをクリックしても、ＣＳＡは利用可能状態になることはできず、したがってコールを受け取ることができない。幾つかの実施形態は、ＣＳＡに自身の利用可能性を自身の電話システム１０６を介してシグナリングできるようにする、電話システムを基礎としたインタラクティブ音声アプリケーションを含むことができる。

幾つかのケースにおいては、「１分毎」の課金は行われないキャリア協定を取り決めることができる。その代わりに、ピークの同時発生（一回に使用されるラインの最大数）に関する課金を取り決めることができる。その場合、この静かに開かれたコネクションの維持に関する罰金は存在しない。そのような実施形態においては、保留中の顧客はコネクティビティコントローラ１０３に接続されるのではなく、ＣＳＡの電話装置１０６の物理的なロケーションに接続されるので、エージェントノードへのピークの同時発生を改善することができる（すなわち減らすことができる）。このことは、良くあるケースであるが、ＣＳＡが配置される傾向にある場所よりも電話の同時処理に費用の掛からない場所にコネクティビティコントローラ１０３のためのデータセンターが配置されている場合には有利となる。このことは、システムを収容している１つの（または複数の）データセンターが優れたコネクティビティを有する領域に配置されている場合には当てはまるであろう。

静かに開かれているコネクションがシステムのオペレーションに必要ないことが分かるであろう。択一的な実施形態においては、ＣＳＡはユーザインタフェース１１１または他のデバイスにおけるコントロールにアクセスすることによって利用可能性をシグナリングすることができる。コールコントローラ１０２は続いて、このコールコントローラ１０２がＣＳＡに接続すべき顧客を有している場合には、例えばＣＳＡにコールすることによって、ＣＳＡの電話装置１０６と接続することをコネクティビティコントローラ１０３に指示できる。

コールコントロールパネル
幾つかの実施形態においては、ＣＳＡが顧客からの電話コンタクトを取ることを認可されている場合（またはＣＲＭ１０１に既知であるようなＣＳＡのプロフィールが作成されている場合）、「コールコントロールパネル」３００をコンピューティングマシン１０７におけるＣＳＡのユーザインタフェース１１１に表すことができる（図３Ａ〜３Ｉを参照されたい）。このユーザインタフェースは当業者には周知の手段、例えばＨＴＴＰ、ＨＴＴＰＳ、リモートデスクトップなどによって確立することができる。コールコントロールパネル３００はＣＳＡの今現在の状態３０１を指示することができる。幾つかの実施形態においては、たとえ他の状態、例えば「利用可能」から始動できる場合であっても、ＣＳＡはデフォルトで「オフライン」状態から出発する。ＣＳＡは「状態セット」ドロップダウン３０２を選択することによって状態を変更することができる。ドロップダウン３０２を用いて状態メニューオプション３０２ａを表すことができる（図３Ｂを参照されたい）。状態セットドロップダウン３０２は、ＣＳＡがコールを受け取ると消すことができる（つまり、その場合ＣＳＡは状態を変更することはできない）。コールコントロールパネル３００を、図３Ｃに示されているようにＣＳＡのその時点における状態に依存して種々に描写することができる。状態インディケータ３０３は種々の状態に関して種々のコード、例えば、コールの待機に関しては色無し、コール中には緑色、または利用不可能状態に関しては黄色を示すことができる。タイマ３０４は状態または他のイベントの時間を計ることができる。発呼者のＩＤ３０５を表示することができる。他の詳細３０６も表示することができる。ＣＳＡの状態が変化すると、例えば顧客またはＣＳＡが受話器を置くと、コールコントロールパネル３００を非同期で再描写することができる。

高度なエージェント状態
コールコントロールパネル３００に状態の多数の選択肢を表示することができる。状態のサンプルセットを以下において説明する。この列記は排他的なものではなく、他の多くの状態、またそれらの状態の組合せも本願発明の範囲に含まれる。さらには、本発明の実施形態を実施するためにそれらの全ての状態、または幾つかの状態を満たしている必要はない。

オフライン：電話コールを取るＣＳＡが先ずシステムにサインインすると、ＣＳＡを自動的にオフライン状態にすることができる。通常の場合、システムはこの状態にあるＣＳＡにコールを送らない。しかしながら幾つかの実施形態は、この状態にあるＣＳＡが他の作業を行うことを妨げるものではない。例えば、オフライン状態のＣＳＡが顧客のＥメールによるコンタクトに応答することを妨げることはできない。オフラインを「補助」状態として分類することができ、この状態は補助を行いながら過ごす時間に寄与する（下記の測定指標の節を参照されたい）。

利用可能：ＣＳＡまたはシステム１００が状態を利用可能にセットすると、ＣＲＭはＣＳＡへのコールを開始することができる。上述のように、ＣＳＡはコールに応答することができ、またコールを取るための利用可能状態を継続していることを指示するために静かに開かれたコネクションを維持することができる。この状態にある間は、ＣＳＡは何時でも受話器を置くことができる。その場合、ＣＳＡは「オフライン」状態に移行することができる。さらにＣＳＡは、例えば「休憩中」に切り替えるために、状態セットドロップダウンメニュー３０２ａから別の状態を選択することができる。この時点においてシステム１００はコールを切断することができ、またＣＳＡが利用可能状態に戻るまで顧客コールを一切送らない。利用可能状態にある間に、ＣＳＡをあらゆる補助状態に切り替えることができる。システム１００のサインアウトにより、有利にはＣＳＡを自動的にオフライン状態に切り替えることができる。

コールについて利用可能：ＣＳＡまたはシステム１００が状態を「コールについて利用可能」にセットすると、ＣＲＭはＣＳＡへのコールを開始することができるが、ＣＳＡは通常の場合、静かに開かれたコネクションを維持しない。顧客とＣＳＡとの間のコネクションをＣＳＡへのコールの指示によって開始することができる。ＣＳＡは、例えば、状態セットドロップダウンメニュー３０２ａにアクセスすることによって利用不可能状態または他の状態を指示することができる。

通話中：ＣＳＡが顧客と通話している間、ドロップダウンメニュー３０２ａは表示されないので、ＣＳＡは有利には状態をオフラインまたは利用可能に切り替えることができない。ＣＳＡが（例えば、ページが再描写されなかったために）依然としてドロップダウンメニュー３０２ａを利用できる場合には、状態を変更するためのコールに失敗する可能性があり、また問題を示唆するためにポップアップを表示することができる。通話中に、この状態に関する適切なオプションをＣＳＡに与えるためにコールコントロールパネル３００を変更することができる（図３Ｄを参照されたい）。これらのオプションは、顧客を保留状態にするオプション３０７、コールを切断するオプション３０８、顧客を転送する、または他の機能を実施するオプション３０９を含む。

保留中：例えば図３Ｄに示されているように、保留コントロール３０７を選択することによって顧客を保留状態にすることができる。顧客はメディアサーバ１１２から流される保留音を聴くことができる。顧客を保留状態にしている間、ＣＳＡのコネクションは無音であってもよい（場合によっては周期的なビープ音を出すことも考えられる）。コールタイマ３１０は顧客のその時点における保留時間をトラックすることができる。

アフター・コール・ワーク：切断コントロール３０８を選択するか、単に受話器を置くことによって、ＣＳＡを通話中状態からアフター・コール・ワーク（ＡＣＷ）状態に移行させることができる。上述のように、この状態はコールの「ラップアップ」、すなわち要約にとって有用となる。

転送：通話中状態からＣＳＡが転送コントロール３０９を選択する場合、ポップアップを表示することができ、これによりＣＳＡは転送先を入力することができる（図３Ｅを参照されたい）。ＣＳＡが転送先３１１を入力し、ダイアルコントロール３１２を選択すると、ダイアルパッド３１３を非表示にすることができ、またＣＳＡがコネクションを開始している間は顧客を保留状態にすることができる（図３Ｆを参照されたい）。転送先のコネクションに基づき、コールコントロールパネル３００は、図３Ｇに示されているように、２つの会話のトラッキングを展開することができる。この状態においては、図３Ｈに示されているように、ＣＳＡは全ての関係者の間でのカンファレンスを開始するためにオールトークコントロール３１５を選択することができる。択一的に、ＣＳＡは（適切な「×」３１６を選択することにより）関係者のコネクションを選択的に切断することができるか、ＣＳＡ自身が（チャット終了コントロール３１７を選択することにより）そのコールから離れることができる。例えば、コールコントロールパネル３００における適切なコントロールを選択するか転送先番号をダイアルし、顧客をその転送番号に接続し、それと同時にＣＳＡ自身のコネクションを切断することによって、ＣＳＡは顧客に対して「突然の転送」を行うことができる。択一的に、別の適切なコントロールを選択するか転送先番号をダイアルし、転送番号に顧客を接続し、一定時間の経過後にＣＳＡを会話から切断することによって、ＣＳＡは「丁寧な転送」を開始することができる。ＣＳＡは選択的に、図３Ｉに示されているように、適切な再生コントロール３１８または一時停止コントロール３１９を選択することによって関係者を保留状態にすることができる（後には、保留状態を解除することができる）。

上記の記載から、システム１００は以下のいずれの事項、すなわち（１）ＣＳＡは複数のコネクションを受け取ることができる電話装置を有していること；もしくは（２）ＰＢＸまたは他の電話装置は転送を実行することができること、を要求することなく、発呼者の転送先への丁寧な転送または突然の転送を実施できることが分かる。転送はオープンな標準的なコネクティビティコントローラ１０３によって実施されており、またコールコントローラサービス１０２によって指示されているので、転送を実施するために使用されるシステムのコストおよび複雑性を低減することができる。

他の状態：測定指標の収集（下記において説明する）を改善するために、幾つかの実施形態はより多くの状態を使用することができる。これにより、ＣＳＡがどのように時間を過ごしているかのより細密な考察を行うことができる。そのような状態として、昼食、私用、トレーニング、Ｅメール、プロジェクト、システム問題、休憩Ｘ（ここでＸは休憩番号、例えば休憩１および休憩２を表す）が挙げられるが、これらの状態は排他的なものではない。

ＣＳＡの認可
上述のように、システム１００の幾つかの実施形態は、通常のコールセンター外に配置されている複数のＣＳＡを提供する。幾つかの実施形態はそのようなＣＳＡを認可および許可するためのメカニズムを提供する。特別なメカニズムはエージェントノードまたは個々のＣＳＡに固有のものである。択一的に、メカニズムを全てのタイプのＣＳＡに対して有効にすることもできる。

図１を参照すると、認証メカニズムをＣＳＡのコンピューティングデバイス１０７および／またはＣＳＡの電話装置１０６におけるユーザインタフェース１１１によって提供することができる。幾つかの実施形態においては、ＣＳＡのコンピューティングデバイス１０７に表示すべき、ユーザインタフェース１１１の一連の表示を形成することができる。

例えば、ＣＳＡを先ずユーザインタフェースディスプレイ、例えばcallcenter.com/loginのようなウェブページまたはポータルにナビゲートすることができる。ＣＳＡは自身の電話グリーティング名、電話ログインおよびシティコードを入力することができる。さらにＣＳＡは（場合によっては他のオプションに加えて）コールコントロールパネルを表示するための好みを選択することができる。しかしながら、パネル（および好み）を全てのユーザが利用できるものではなく、殊にＣＳＡとして許可されていない者は利用することはできない。ＣＳＡは、コネクティビティコントローラ１０３が電話装置１０６を介してＣＳＡとコンタクトを取る場合に使用されるべき内線をセットすることができる。ログインの成功および内線のセットに基づき、コールコントロールパネル３００はＣＳＡを「オフライン」状態または幾つかの別の状態にすることができる。

コールキューイングおよびコールルーティング
図２は、図１のシステム１００の幾つかの実施形態による、コールのキューイングおよびルーティングに関する詳細を示す。図示されているシステム１００はコールコントローラサービス１０２、集中型のコールキュー２０２およびデータ記憶装置２０３を有する。システム１００の外部には到来するコールボリューム２０６（種々のネットワーク上にいることが考えられる顧客１０５からの複数のコールから成る）と、単純に単一のオブジェクト２０５として表されている、個々のＣＳＡマシン１０７および／または電話１０６の集合体が示されている。１つまたは複数のエージェントノード２０４内に幾つかのＣＳＡ、全てのＣＳＡを配置することができるが、エージェントノード２０４内にＣＳＡが配置されていなくてもよい。上述のように、エージェントノード２０４は１つまたは複数のＣＳＡを含むことができる。さらに、エージェントノード２０４に相互に近接するＣＳＡまたは相互に離れたＣＳＡを含ませることができる。１つの実施形態において、ＣＳＡは共通のプロフィールに基づき１つのエージェントノードに物理的または論理的にグループ分けされる。したがって、ノード内のＣＳＡのプロフィールに少なくとも部分的に基づき特定のエージェントノードにコールをルーティングすることができる。図２は、完全なシステム１００に含まれていることが考えられる構成要素の内の一部のみが示されていると解するべきである。図２は、説明を簡単にするために簡単なものに留められている。したがって、付加的な構造上の詳細については図１およびそれに付随する説明を参照すべきである。前述のように、また図面に示されているように、複数のＣＳＡ２０５を共通のエージェントノード内に配置することができるが、それらのＣＳＡは独立して機能することができる。ＣＳＡは通常の場合、上記のようなシステム１００とのユーザインタフェースリンク（図示せず）を維持管理する。集中型のコールキュー２０２は物理的、論理的および／または他のキューに付加的に、コネクティビティコントローラ１０３によって管理される。

到来するコール２０６はシステム１００によって（例えば、組織の８００番（フリーダイアル）へのダイアル、ローカル番号へのダイアル、ＳＩＰまたはインスタントメッセージなどを介する接続によって）受け取られるので、それらのコール２０６は通常の場合、待機中の顧客のキュー２０２に置かれる。このとき顧客はメディアサーバ１１２からの音楽またはＩＶＲ１１３からの統合音声レコーディングを聴かされている。

コールコントローラサービス１０２は経時的にキュー２０２内の顧客とＣＳＡ２０５との間のリンクを確立する。このリンクの確立はコネクティビティコントローラ１０３によって行われる。コントローラはファースト・イン・ファースト・アウト（ＦＩＦＯ）またはラスト・イン・ファースト・アウト（ＬＩＦＯ）のような何らかの特定の順序でＣＳＡ２０５にキュー２０２内の顧客を割り当てる必要はない。むしろコントローラ１０２は、以下において説明するような考察および／または優先キューに基づく順番通りでない割り当てを使用することができる。幾つかの実施形態においては、ここで説明したような全てのキュー、または幾つかのキューをプールとも称する。コントローラは二次的なコールセンターレベルのキューを要求または使用することなく、エージェントノード２０４内のＣＳＡをキュー２０２内の顧客と直接的にリンクさせることができる。

コールコントローラサービス１０２は一般的に、どの顧客をどのＣＳＡにルーティングするかを決定するために、少なくとも１つのデータ記憶装置２０３もしくは付加的なシステムまたはコンポーネントにアクセスする。この情報を以下においてより詳細に説明するが、一般的にこの情報は、顧客がどれ程長く保留状態にあるかのような情報、顧客クラス、特定のＣＳＡの特性、コールタイプ、顧客履歴、また特定のＣＳＡ２０５およびエージェントノード２０４のユーティライゼーション（多忙さおよび配分）などの情報を含む。

殊に、幾つかの実施形態においては、システム１００のオペレーションに関する状態測定指標、例えばある特定のＣＳＡ２０５はどれ程の間「利用可能」状態で待機し続けているかに基づいて、到来するコールに繋ぐためのＣＳＡ２０５を選択することができる。つまり、例えば、コールコントローラサービス１０２は通常の場合、他の全て（または大半の）利用可能なＣＳＡ２０５と少なくとも同じ程度はコールを待機しているＣＳＡ２０５に所定のコールを接続することができる。そのような状態測定指標の他の例は、ＣＳＡに任せられた他のキューの数およびタイプに関する情報を含む。

別の実施形態では、システム１００のオペレーションに関連する状態測定指標とは異なる要因に基づいて、特定の到来するコールに接続するためのＣＳＡ２０５を選択することができる。例えば、発呼者のＩＤ、コールタイプ、要求されるスキル、および／または、システム１００を用いた以前の履歴のようなコールに関連する情報に基づいて所定のコールに応答するために特定のＣＳＡ２０５を選択することができる。例えば、異常な数のコールをシステム１００に行った発呼者をルーティング時に特別に考慮することができる。この情報をデータ記憶装置２０３において管理することができる。

システム１００のオペレーションに関連する状態測定指標とは異なる要因に基づいた、特定の到来するコールに接続するためのＣＳＡ２０５の選択の別の例として、ＣＳＡ２０５をＣＳＡ２０５の能力に基づき選択することができる。これらの能力にＣＳＡ２０５のＩＤ、プロファイル、および／または、スキルを含ませることができる。以下ではこれらの能力をより詳細に説明する。ＣＳＡのＩＤにはＣＳＡの地理的な位置、国籍、語学の腕前、方言などを含ませることができる。能力にはＣＳＡ２０５の履歴情報、例えばフィードバックおよびトレーニング、特定のＣＳＡ２０５のエージェントノードに関連する情報なども含ませることができる。ＣＳＡ２０５の履歴情報にはＣＳＡ２０５と発呼者との間の何らかの以前の履歴（例えば以前のコールまたはコンタクト）を含ませることができる。関連するエージェントノードに関する情報もＣＳＡ２０５のＩＤの一部とみなすことができる。

所定のコールを特定のＣＳＡ２０５にルーティングするための決定を、上述の要因の内の１つまたは複数のカテゴリに依存させることができる。つまり、例えば、幾つかの実施形態においては、（１）ＣＳＡがキューにおいて待機している総時間のような状態測定指標；（２）コールタイプまたは発呼者がシステムとコンタクトを取った回数のようなコール特性または発呼者特性；（３）発呼者との以前の履歴のようなＣＳＡ能力の各々に基づきルーティングを決定することができる。もちろんこれらの実施形態は一般的に、ルーティングをＣＲＭ１０１またはシステム１０２に既知であるか、他のシステムからインポートしたいずれかの情報またはデータに基づいて決定することができる。

幾つかのシステム１００は複数のキューを実現することができ、応答すべき到来したコールが少なくとも１つのキューに保持され、ＣＳＡ２０５は少なくとも１つの別のキューにおいて管理されることが分かる。コールとＣＳＡ２０５をそれらのそれぞれのキューのでたらめな順序で合わせることができる。幾つかの実施形態はコールおよびＣＳＡ２０５の各々または１つに関するキューの複数のレベルを管理することができる。

システム１００は所定のコールを受け取るために（幾つかの測定指標にしたがい）資格を与えられたエージェントのキューを管理することができる。つまり、例えば、高額支払い層に属する顧客からのコールを処理または取り扱うために「プレミアム」ＣＳＡのキューを管理することができる。プレミアムＣＳＡの資格を与えるために使用される測定指標として、例えば、ＣＳＡ２０５としての勤続年数、トレーニング、包括的なフィードバック、平均顧客満足度、言語スキルなどが考えられる。幾つかの実施形態においては、資格測定指標は少なくとも部分的に、何らかの特定のコールに固有のものではない要因を基礎とする。「資格キュー」の別の例は、特定のスキルを有するＣＳＡ２０５のキュー、特定の期間にわたり利用可能である、および／または、利用可能であったＣＳＡ、所定のエージェントノードからのＣＳＡなどを含む。

ＣＳＡ２０５は特定のコールを処理するために資格キューから選択（または選抜）することができる。システム１００は、ＬＩＦＯまたはＦＩＦＯのような静的な順序に基づいて資格キューからＣＳＡを割り当てることができるが、これは必ずしも必要ではない。むしろ、システム１００は資格のあるエージェントのキューから（上述の資格測定指標とは異なっていてもよい）選択測定指標に従い特定の資格のあるエージェントを動的に選択または識別することができる。選択測定指標はシステム１００のオペレーションに関する状態測定指標、例えば、所定のＣＳＡ２０５はどれ程「利用可能」状態で待機し続けているかを基礎とすることができる。

他方では、選択測定指標はシステム１００の状態測定指標とは異なる情報を基礎とすることができる。例えば、特別なコールに関連する情報、例えば発呼者のＩＤおよび／またはシステム１００との以前の履歴に基づいて所定のコールに応答するために、「資格を与えられた」キューから少なくとも部分的に特定のＣＳＡ２０５を選択することができる。別の例として、ＣＳＡ２０５を少なくとも部分的に、上述のようなＣＳＡ２０５の能力に基づき選択することができる。

幾つかの実施形態はこの２レベルの資格および選択システムを使用し、コールの分散およびルーティングに関する細密な制御を提供する。例えば、ＣＳＡ２０５はコールタイプに広範に応答できることを指示するために、資格キュー（換言すれば、プール）をあらゆる特定のコールに依存せずに管理することができる。そのようなコールタイプのコールがシステム１００に到来すると、例えばその所定のコールに特有の特性、システムニーズまたはＣＳＡ能力に基づき資格キューからＣＳＡを選択することができる。

つまり、上述の例を引き続き説明すると、例えば、（１）ＣＳＡ２０５と発呼者は以前に会話しており、発呼者はＣＳＡの能力に満足している、（２）ＣＳＡのエージェントノードはその時点において十分に利用されていないという理由から、「プレミアム」資格キューにおける特定のＣＳＡ２０５をそのキューから選択し、特定の発呼者に割り当てることができる。このＣＳＡ２０５をプレミアムＣＳＡキューにおいてより長い期間待機し続けているＣＳＡ２０５に優先して選択することができる。

もちろん、選択機能（また資格機能）を本明細書において説明した幾つかのパラメータまたは全てのパラメータに依存させることができる。さらには、選択機能および資格機能を動的に変更することができる。もちろん、選択および資格の複数のレベルを実現することもできる。幾つかのシステムは幾つかの測定指標に従いＣＳＡの選択を取り消す、または資格を取り消すことができる。特定のキューに割り当てられたコールまたはＣＳＡ２０５をキューから除外する、および／または、経時的に他のキューに再割り当てすることができる。ＣＳＡ２０５、発呼者およびコールを選択機能または資格機能に従い優先選択順位においてランク付けすることもできる。したがって、到来するコールを一番上のランクのＣＳＡに割り当てることができるか、この到来するコールにとって最適なＣＳＡに割り当てることができる。

上記においては、種々のタイプの要因、例えばコールタイプ、ＣＳＡスキル、エージェントノード割り当てなどに基づいた、ＣＳＡ２０５およびコールのルーティング（接続）を参照した。以下の節においてはこれらの種々のタイプのルーティングを説明する。

スキルに基づくルーティング
本明細書においては、スキルとはコールタイプまたはコール区分、例えばＵＳＰｒｉｍａｒｙ８００番、シューズ（Shoes）、優先顧客などを参照することができる。種々のスキルを別個の無料番号に対応付けることができる。択一的に、種々の無料番号を同じスキルに対応付けることができ、また同一番号に対するコールをその後に得られた知識に基づき割り当てることができる。システムは種々の電話番号（ＰＢＸによってしか提供されない番号も含む）から全てのコールをルーティングすることができる。

スキルコンフィギュレーションはシステムを適切にスケーリングできるようにするために可能な限り簡潔になされる。スキルを追加、編集および削除できるようユーザインタフェースを形成することができる。したがってコール分散システム１００は、スキルについての変更がなされる度にＥメール通知を（必要に応じてＥメールエイリアスに記載された全てのユーザに）送信することができる。択一的に、ハードコーディングされたスキルコンフィギュレーションを使用することができる。以下のタイプの情報を各スキルに関連付けることができる。この列記は代表的なものであり、排他的なものではない。全ての項目が実施されなければならない訳ではない。

スキル名：スキルの略名、例えばＵＳＰｒｉｍａｒｙ，ＵＫＰｒｉｍａｒｙ，ＳｈｏｅｓＵＳＰｒｉｍａｒｙなど。

記述：スキルの比較的長い記述、場合によってはデータ作成日も含む。

ルーティングタイプ：スキルに関して使用されるルーティングロジック。選択肢は「シンプル」（例えば先着順サービス）または「割当テーブル」（このタイプのコールは以下において説明するパーセント割当テーブルに従いルーティングされる）が考えられる。

ウェルカムメッセージ／ＩＶＲホームページ：再生すべきメディアファイル名またはＩＶＲの統一資源識別子（ＵＲＩ；Uniform Resource Identifier）またはスキルに関して実行すべきスクリプト。

ウィザード：着呼に基づき実行することができるウィザード。ウィザードはコールに関連付けられたスキルを変更することができる。

オペレーション時間：このスキルに関するオペレーション時間。システム１００は週間スケジュールを管理することができる。システムは間隔を空けて、このスキルに関してトレーニングを受けているＣＳＡを集めている特定のエージェントノード２０４が開かれているか閉じられているかを指示することができる。

勤務時間外メッセージ：（１）勤務時間外（スキルに関する時間によって規定される）であるか、（２）コールを処理できるＣＳＡが誰もログインしていないときにコールがそのエリアに到来すると再生されるメディアメッセージ。メッセージを種々のコンテクストで再生することができる。

保留音メッセージ：保留音として再生されるメディア。必要な何らかのメッセージ（例えば「そのまま暫くお待ち下さい」）を組み込むことができる。

スキル情報をデータ記憶装置２０３に記憶することができる。さらに、システム１００は各スキルに対応付けられた電話番号のリストを管理することができる。コールが到来すると、コールコントローラサービス２０１はコールをどのように分類するかを決定するためにダイアル番号識別サービス（ＤＮＩＳ；Dialed Number Identification Service）をスキャンすることができる。管理することができるデータの排他的ではないサンプルリストは以下の通りである：
ＤＮＩＳ名：顧客によってダイアルされた番号の表現。
記述：このＤＮＩＳの記述。
スキル：このＤＮＩＳに関連付けられたスキル。
メディア／ＩＶＲホームページ：このＤＮＩＳへのコールに使用されるべきメディアファイルまたはＩＶＲホームページの名称／ＵＲＩ。このセッティングは対応するスキルのセッティングを無効にすることができる。

特別なルーティング：コールが非標準的または特別なルーティングプログラムを有することを許可する。例えば、所定のエージェントノード２０４になされたコールはそのエージェントノード内のＣＳＡにルーティングされるべきである。さらに、特定のエージェントノードを特別なＤＮＩＳから除外することができる。例えば、特定のエリアコードまたは場所からなされたコールを、それと同一のエリアコードまたは場所にある特定の（１つまたは複数の）コールセンター内のＣＳＡに接続することを予め排除することができる。

システム１００の幾つかの実施形態はスキルを基礎とするルーティング（ＳＢＲ；skills-based routing）プロトコルをサポートする。一般的に、コールの到来に関するＳＢＲはシステム１００が到来するコール２０６を考えられる最高のＣＳＡ２０５に合わせることを試みることができる。コールコントロールサービス１０２はＳＢＲを実施することがで、またＳＢＲプロトコルにおける種々の次元のトレードオフのバランスを取ることができる。一般的に、ＳＢＲを以下のコールルーティング優先順位の内の幾つかまたは全てをサポートするよう設計できる（ここで各優先順位はスキル固有であるか汎用的である）：（１）可能であれば常に各顧客に関するサービスレベル品質の目標に達する；（２）適切な量のコールトラフィックを各エージェントノード２０４にルーティングする（場合によっては、サービスレベルに悪影響が及ぼされないように修正される）；および／または、（３）到来するコールに関して要求されるスキル／トレーニングをその要求されるスキルを備えたＣＳＡ（データ記憶装置２０３に記憶されている）に合わせる。もちろん、他の優先順位またはそれらの優先順位の組合せも考えられる。これらのプロトコルのサブセットの内ただ１つを実施するだけで、またはそのようなプロトコルに近似するものの内ただ１つを実施するだけで、コールコントローラサービス１０２を開始することができる。

スキルを基礎としたルーティングを達成するために、キューを使用することができ、これによりコールが分類される。それらのキューは論理的で到来するコールに相補的なキュー２０２でよい。ルーティングキューは一般的に以下のように機能する：
１．コールがシステム１００に到来すると、それらのコールをダイアルされた番号に依存するデフォルトスキルに割り当てることができる。例えば、特定の８００番への各コールを（キューに関連付けられた）ＵＳＰｒｉｍａｒｙスキルに割り当てることができる。
２．コールのスキル割り当てをウィザードによって変更することができる。この変更をコールがいずれかのキューに置かれる前に行うことができる。択一的に、コールをキューに置いた後に、スキル割り当てを変更することができる。これにより異なるキューへの再分類を行うこともできる。コールがキューに置かれると、（１）応答が行われるまで；（２）コールが切断されるまで；または、（３）（オプション）再割り当てが行われるまで、コールはそのキュー内に留まることができる。
３．一般的に、キュー内の最も古いコールが最初に応答される。システムの複数の実施形態は優先順位または好み、すなわち贔屓の顧客に関して区別されたサービスレベル（ＳＬ）をサポートすることができる。これは「重み」係数を介して達成することができ、キューにおける総時間は例えば（キュー内の＃秒）×（コールに対する重み係数）とみなすことができる。２の重みを有する好みの顧客に相対的に、デフォルトコールの重みを１とすることができる。この場合、好みの顧客のコールは一般的に、同じキュー内の好みでない顧客のコールに比べて２倍早く応答されることになる。
４．上述のように、到来するコールにキューを再割り当てするためにウィザードを使用することができる。これらのウィザードはＩＶＲ１１３または他のメカニズムを使用する発呼者によって提供された情報、もしくはそこから導出できる何らかの情報を使用することができる。これらのウィザードはコンタクトを分析する多くのシステムに依存することが考えられるので、全てのコールが単純に（有利にはいずれのウィザードアクションも要求しない）そのデフォルトキューに置かれる場合には、ウィザードは失敗することも考えられる。
５．幾つかの実施形態においては、無制限の数のキューを生成することができ、またそれらのキューをコールボリューム、コールタイプまたはＣＳＡスキルなどの条件が変更された際に、コールコントローラサービス１０２によって動的に生成することができる。

一度コールがキューに割り当てられると、それらのコールをＣＳＡに割り当てる（ルーティングする）ことができる。幾つかの実施形態においては、各ＣＳＡが正確に１つのキューに割り当てられ、そのキューのみからコールを取ることができる。しかしながら別の実施形態においては、コールコントローラサービス１０２が融合型のＣＳＡ割り当てをサポートし、これによりＣＳＡは複数のキューからのコールを処理することができる。融合型の割り当てを達成するために、各ＣＳＡに対してコールコントローラサービス１０２は以下のものを提供することができる：
１．キューのリスト。このリストに基づきＣＳＡは作業を行うことができる。融合タイプに依存して、あるキューはそれよりも後にリストに記載された別のキューよりも高い優先順位を取得することができる。
２．複数のキューからどのようにして１つのＣＳＡを選ぶかを決定する融合タイプ。融合タイプはＣＳＡが単一のキューにしか割り当てられない場合には重要ではない。融合タイプは以下のものを含む（ただし、それらに制限されるものではない）。

一番古いコール。ＣＳＡが一番古いコール融合タイプでもって構成されている場合、ＣＳＡにはこのＣＳＡが処理を行うよう構成されているいずれかのキューにおける一番古いコール（必要に応じて重み係数を含む）が割り当てられる。この場合にはキューの順序は問題にならない。

順序正しいキューの排出（drain）。このタイプによれば、第１のキューはＣＳＡに第２のキューからのコールが割り当てられる前は空でなければならず、最初の２つのキューはＣＳＡが第３のキューからいずれかのコールを受け取る前には空でなければならない（以下同様）。

混合型。このタイプでは、コールが別のキューにおいて長い時間にわたり保留されていない限り（例えば時間閾値Ｔが規定される）、ＣＳＡは１つのキューに集中することができる。より詳細には、ＣＳＡのいずれのキューにおけるいずれのコールも（重み係数に関して調整される）Ｔ秒よりも前のものでない場合、ＣＳＡは順序正しくキューを排出する（上記を参照されたい）。択一的には、（重み係数に関して調整された後の）Ｔ秒よりもキュー内に長くいる１つまたは複数のコールが存在する場合、ＣＳＡにはＣＳＡのいずれかのキューにおける一番古いコールが割り当てられる（上記を参照されたい）。

幾つかの実施形態では、スキルおよびＣＳＡプロフィールを構成するためのメカニズムが提供される。幾つかの実施形態においては、キューおよびＣＳＡプロフィールのリストを中央で修正することができ、また電話コンタクト分析ウィザード（上述のように、このウィザードは到来したコールに適切なキューを割り当てることができる）を用いた変更と連携させて修正することができる。これらのキュー名へのアクセスを制限することができる。例えばいくつかの実施形態では、無関係のマーチャントのキューのビューからアウトソーサー（例えば、自身の顧客のシステムとのコンタクトをアウトソーシングする事業）を排除することができるか、他のいずれかのキューに対してアウトソーサーは処理を行えるよう設定されていない。

ＣＳＡプロフィールを複数のＣＳＡに適用することができるので、単一のプロフィールの変更により複数のＣＳＡのコンフィギュレーションが変化することになる。幾つかの実施形態はこの機能を使用し、コールボリュームの動的な変動を処理できるようにするために、複数のＣＳＡのプロフィールを変更する方式を提供することができる。そのようにするために、システムは以下の動作を実施することができる：
１．ＣＳＡプロフィール（融合タイプを用いる、スキルの順序付けられたリスト）の作成
２．特定のＣＳＡに関するプロフィールの割り当て／編集

このコンフィギュレーションを、各エージェントノード２０４におけるマネージャによって、中央システム１００におけるマネージャによって、種々のイベントに応答するシステムによって自動的に、またはそれらの内の幾つかによって、もしくはいずれにもよらずに実施することもできる。個々のエージェントノードマネージャは、コールボリュームの急増に応じた要求により、このコンフィギュレーション情報を変更することができる。システムの幾つかの実施形態は、コンフィギュレーションエラーの可能性を低減するために、（それらのコンフィギュレーションが変更されたインタフェースへのアクセスを制限することによって）ＣＳＡプロフィールの作成および管理を中央に集中させる。幾つかの実施形態においては、各アウトソーサーに対するＣＳＡプロフィールをシステムまたはシステム管理者によって作成および管理することができる。別の実施形態においては、アウトソーサーが自身のプロフィールを作成および管理するためのインタフェースを有することができる。幾つかの実施形態によれば、プロフィールについての比較的細密なセキュリティ権限が提供される。

割当テーブルを基礎とするルーティング
割当テーブルは、各エージェントノードが適切なコールボリュームを受け取ること、すなわち自身の割り当てまたは稼働目標に合わせることの保証の助けとするために使用することができる。割当テーブルは、人員過剰のエージェントノード（すなわち、コールに関して利用可能なＣＳＡを過度に多く保有しているエージェントノード）が適切な人員数のエージェントノードから大量のコールを引き抜く（したがってペナルティを科す）ことを阻止するメカニズムを提供する。そのようなペナルティの阻止は予算管理または事業計画の一部である。

割当テーブルを以下の少なくとも３つの目的のために使用することができる：（１）複数のエージェントノードから利用可能な複数のＣＳＡが存在する場合のＣＳＡおよびエージェントノードの選択；（２）全てのエージェントノードに複数のキューが存在する場合に、それらのキューをエージェントノードのキャパシティに比例して維持できるようにするためのエージェントノードキャパシティの評価；および（３）リアルタイム情報（ＣＳＡの利用可能性）を利用できない場合のコールの割り当て。実施形態がこれらの各目的に対して割当テーブルを実施することは必要ない。

（１）に従いＣＳＡを選択するために、コールコントローラサービス１０２は、所定のコールを取るために利用可能であり、且つ資格のあるＣＳＡのリストを編集することができる。利用可能な複数のＣＳＡが存在する場合、コールコントローラサービス１０２は、実際の（現在または過去の）理想的な割当パーセンテージ間の差が最小になるように選択を行うことができる。いずれかの特定のキューに適用される割当テーブルが存在しない場合、最も長く利用可能であったＣＳＡに、そのＣＳＡが何処に位置しているかを考慮することなく、コールを単純にルーティングすることができる。

幾つかの実施形態においては、割当テーブルは複数のエージェントノードのキャパシティを相互に相対的に規定する。例えば、エージェントノードＡが２５％のキャパシティを有し、エージェントノードＢが５０％のキャパシティを有する場合、割当テーブルが使用されると、エージェントノードＢはエージェントノードＡよりもおよそ２倍の量のコールを受け取ることになる。曜日および各期間に対して別個のパーセント割当テーブルが存在していてもよい。割当テーブルに表される期間は連続的であるか離散的であり、例えば３０分刻みで増加する。図４には、割当テーブルにおいて１日の経過にわたり記憶することができるキャパシティ情報の例が示されている。

割当テーブルを個々のキュー（１つのスキル）またはキューのセット（複数のスキル）に適用することができる。システムは多くの細密なスキルを有することができるので、割当テーブルを複数のキューにわたり適用することができる。幾つかの実施形態においては、各キューに対して１つのテーブルを提供することは必要ない。つまり、例えば、システムはＣＳＡを「型にはめ続ける」ように意図された、つまり、ＣＳＡが特的の限定的なタイプの問題に反復的に従事し、その問題の領域における自身の効率を改善または維持することが意図されたスキル定義を提供することができる。コンセプトとしては、これら２つのスキルの各々がゼネラリストプライマリＣＳＡに関する仕事量の一部を含むので、したがってシステムはそれらのキューの各々に対する個別の割当テーブルを予測し提供することを試みようとはしない。

コールを種々のサブエージェントノード２０４におけるＣＳＡにルーティングできるようにするために、コールコントローラサービス１０２はそれらのルーティング決定の内の少なくとも幾つかの履歴を保存することができる。この履歴によりシステムを関連するテーブル割当パーセンテージに適合または近似させることができる。例として、エージェントノードＡが（所定の期間にわたり）コールトラフィックの７０％を受け取り、エージェントノードＢが残りの３０％を受け取ることを想定したケースを考察する。エージェントノードＡにおける全てのＣＳＡがコールバースト中に話中である場合、システムは顧客のサービスレベル（ＳＬ）を維持するためにコールをエージェントノードＢにおけるＣＳＡにルーティングする。したがって、エージェントノードＡはバースト中の所定のコールボリュームよりは少ないコールを受け取ることになるであろう。コールコントローラサービス１０２はこの履歴を管理するか、その履歴の表現を管理し、後に区別することができる。つまり、例えば、バーストの終了後にコールコントローラサービス１０２はエージェントノードＡへの不均衡なコールボリューム（例えば７０％よりも多いコールボリューム）をルーティングすることができる。この履歴は無期限、終日とすることができるか、幾つかの他の期間に構成することができるが、割当値が変化した時（期間の境界において発生する可能性がある）には常にクリアされる。

１つの例として、ルーティングする必要がある新たなＵＳＰｒｉｍａｒｙコールを想定する。コールコントローラサービス１０２は、図５Ａに示されているように（図中ＤＡＫ、ＧＦＫ、ＨＴＳおよびＰＳＣはエージェントノード２０４のコード名である）、関連する各キューに関する割当テーブルおよび履歴情報を考慮することができる。図５Ｂに示されているように、複数のキューにわたり履歴情報が集計され、図５Ｃに示されているように、関連する割当テーブルに表されている理想的な割当情報と比較される。図５Ｂと図５Ｃの差に表されているように、その時点における割り当てと理想的な割り当てとの間の差は、将来のルーティング選択（例えば、理想的なルーティングパーセンテージと、その時点における（履歴、すなわち過去の）パーセンテージとの差が最小になるようなルーティング）の基礎を形成することができる。

幾つかの実施形態は、過去の選択パターンがある程度の精度レベルまで（割り当てテーブルを基礎としているか、割り当てテーブルから導出される）理想的な割り当てに合うように、キューからのコールの選択を試み、またコールをルーティングするためにどのＣＳＡを選択するかについて適合される。したがって幾つかの実施形態は以下の入力を使用することができる：
１．選択が行われるグループ（例えばキュー）；
２．選択の履歴（例えば過去の測定指標）；および、
３．考慮中の各グループに関する理想的な選択分散を指示するテーブル（例えば割当テーブル）。

幾つかの実施形態によれば、この情報を考慮すれば後続の選択を行う方法は以下のようなものでよい：
１．ＣＳＡへのコールの考えられる各選択に関して、各グループに関するものであろう仮想分散はその選択に基づくものであろうことを計算する。
２．その選択に関して生じた包括的なエラーを、理想的な分散とその選択の結果である分散との差を合計することによって計算する。つまり、選択に関する包括的なエラーが計算され、これは以下のように表すことができる：
選択に関する包括的なエラー＝
合計（ＡＢＳ（グループに関する実際の％−グループに関する理想的な％））、ただし合計は全てのグループについて行われる。
３．実際の分散が理想的な分散に最も良く整合する選択肢を選ぶ。択一的には、包括的なエラーを増加させない第１選択肢が選ばれる。

しかしながら当業者であれば、多くの代替手段が考えられ、またそのような代替手段を図７，８および９にリスト化された統計量を含む他の統計量、また他の数学的な機能、例えば乗算および加算、ならびに全称記号および存在記号に依存させられることが分かる。

高度なルーティング
コールコントローラサービス１０２の幾つかの実施形態は細密なルーティング決定を行うために必須のフレキシビリティを有することになる。この節では、以下の３つの代表的なルーティング判定基準、すなわち：（１）携帯電話機を最近購入した特別扱いの発呼者；（２）標準的でない支払い方式を利用している発呼者に対する特別な扱い；および（３）ＣＳＡを型にはめたままにする（上記を参照されたい）、を提供するためにそのようなシステムをどのように構成できるかを説明する。これらは、システムの変動性を強調するために選択された３つの代表的な判定基準に過ぎず、これら３つの判定基準の代わりにより多くの判定基準、より少ない判定基準および異なる判定基準を使用することも考えられる。

第１に、時折、エージェントノードのオペレータの無線キャリアとの契約は、そのオペレータがワイヤレスキャリアの顧客とのコンタクトの処理を国外のＣＳＡに許可することを阻止する。したがってシステムの幾つかの実施形態を、携帯電話機を最近購入した顧客を国内のＣＳＡ（国内のＣＳＡはこのキューを処理するために資格が与えられているものとする）にルーティングするために適合させることができる。そのようなシステムは「携帯電話機ゼネラリスト」キューと、そのようなコールを国内のＣＳＡに割り当てるよう構成されたコールコントローラとを有することができる。専門の携帯電話機トレーニングを受けたＣＳＡのための別の「携帯電話機スペシャリスト」キューがあってもよい。そのような専門のＣＳＡに権限を与え、またそのＣＳＡがプライマリキューおよび携帯電話機ゼネラリストキューの両方から選べるようにすることができる。

ＣＳＡはサービスレベル融合タイプ（上記を参照されたい）により構成することができるか、有利には、複合型融合タイプを使用して、（プライマリＣＳＡよりも少ない数のＣＳＡが働くことになるので）電話キューに関して重み付けされた好みをＣＳＡに与えることもできる。それらのコンタクトを検出するウィザードが正常に機能しなかった場合には、コールは有利にはプライマリキューに置かれることになる。したがって、幾つかの実施形態においては、プライマリキューから選ばれる全てのＣＳＡはそのようなコンタクトを処理するための指示を受け取ることになる。

第２に、顧客は標準的でない手段（電信送金など）を利用して支払いをしようとすることがある。したがって幾つかの実施形態では、そのようなコンタクトを、それらの比較的稀なケースを処理することができるＣＳＡのプールへのルーティングを試みることができる。このことは「標準的でない支払い」キューを作成することによって行うことができる。続いて、特定のＣＳＡに標準的でない支払いキューからコールを選ぶ権限が与えられる。そのようなＣＳＡとして例えば、１ヶ月以上の経験を有するＣＳＡ、または必要な特定のコンピュータセットアップを有するＣＳＡ、または他の何らかの適切な判定基準に従ったＣＳＡが挙げられる。

第３に、上述のように、ＣＳＡを制限された数のスキル領域において少なくとも特定の期間、例えば１時間、１日、１ヶ月、または不定の期間にわたり集中させることによって、ＣＳＡを「型にはめ続ける」ことは有利である。これを達成するために、ＣＳＡを「型にはめる」ことができる各々の（または種々の）コンタクトタイプに１つのキューを割り当て、またＣＳＡをそれぞれ特定の１つまたは複数の専門キューに割り当てるようコールコントローラサービス１０２を設計することができる。専門的なキューまたは一般的なキューのいずれにおいてもサービスレベルが低下しないことを保証するために複合型融合タイプを使用することができる。

システム１００のフレキシビリティの別の例として、図６は、１つの実施形態に従い上述の各ルーティング判定基準を同時に満たすコンフィギュレーション情報を示す。図面に関して、参照番号６０１では訓練を積んだＣＳＡがサービスレベル融合機能において標準的でない支払コールを受け取るよう構成されている。参照番号６０２においては、新規採用者が複合型混合機能のもとで、型（Groove）１のコールを受け取るように構成されている。

測定されて利用されるべきＣＳＡ能力（また必要に応じて、発呼者能力）に関するフィードバックを提供するようにシステム１００を構成することもできる。システム１００はレビュープロシージャを実施することができ、ＣＳＡ（またはマネージャ）は他のＣＳＡのアクションをレビューすることができる。つまり、例えば、コールが先ず第１のＣＳＡにルーティングされ、顧客が後にコールバックする場合、コンタクトを（意図的に、または意図せずに）異なる第２のＣＳＡにルーティングすることができる。第２のＣＳＡは、コール、チケットまたは履歴および先行のコールに関連付けられたいずれかの記録をレビューする過程において、第１のＣＳＡの能力を満足、不満、良好などにフラグをセットすることを決定する。

システム１００の幾つかの実施形態においては、顧客自身が例えばコールの終了時に実施した電話概括によってフィードバックを提供することができる。マネージャは会話を聴くこともでき、さらなるレビューのためにその会話にフラグをセットすることができる。同様に、システム１００自体が、会話にフラグを立てるためのオートメーション化された手段、例えば高度音声応答検出器を有することができる。顧客に関するフィードバック（すなわち顧客の評判）も同様に実施することができる。

システム１００はフィードバックに基づいてルーティング決定を行うことができる。例えば、例外的に高いレビューを有するＣＳＡには「最高の」コール、すなわち最も優先順位の高いコール（例えば高いサーバ層のコール）をルーティングすることができる。同様に、フィードバックの少ないＣＳＡにルーティングするコールを減らすことができるか、トレーニングを選択させることができる。所定のコンタクトのＣＳＡの会話に関して肯定的なフィードバックがある場合、システムは今後その顧客によるコールをそのＣＳＡによりルーティングしやすくすることができる。フィードバックの記憶およびフィードバックに基づいたコールのルーティングをフィードバックコンポーネント、コネクティビティコントローラ１０２、ＣＲＭ１０１または他のコンポーネントによって実施することができる。

独立したＣＳＡおよび市場を基礎としたプライシングおよびルーティング
上述のように、需要を所定のコンタクトのサービスに合わせるために、そのコンタクト（ここでコンタクトとして通信、タスク、サービスまたはワークアイテム、例えばコール、電子メッセージ、ジョブなどが考えられる）を処理することができるエージェントの供給を調整することは容易なタスクではない。電子メッセージはＥメールメッセージ、テキストメッセージ、ファックス、音声メール、チャットメッセージ、ツイッターメッセージなどを含むことができる。

タスク完了に関する需要は非常に短い期間の予測困難な変動にさらされている。例えば、製品またはプロジェクトの販売開始または販売延期、バグの発見、コンピュータウィルスの発生、停電、天候条件などはいずれも、別個にまたは組み合わされて作用して、予測された需要を上回るか下回る特定のコンタクトタイプのサービスに関する実際の需要を生じさせる可能性がある。過剰または不足が１分、１時間、１日または１年にわたり続く可能性もある。例えば、ソフトウェア会社は製品のリリースを６月１日に予定していたとする。分散センターまたはシステムのマネージャ、例えばコールセンターまたはＥメール応答システムは、販売開始後の最初の１週間における（新製品の新規の顧客全てを処理するための）コンタクトボリュームの増加を予定して計画を立てることができ、また２週目にはコールボリュームが通常に戻るであろうと想定することができる。しかしながら、ぎりぎりの所での販売延期によって製品の販売が１週間後（６月８日）にずらされた場合、マネージャは６月２日における実際の需要は予測した需要を遥かに下回り、他方では６月９日における実際の需要が予測した需要を遥かに上回ることを発見できる。そのような状況においてマネージャが実際の需要に応じて供給を迅速に調整できなければ、マネージャは顧客が満足しないことを経験して知るであろうし、また第２週には不適当な数のＣＳＡを使用することになるであろう。

実際の需要に合わせるために利用可能な供給を調整することはマネージャにとってチャレンジである。例えばＣＳＡが前もって仕事のスケジュールを立てていた場合、タスクを完了するためのＣＳＡの利用可能な供給は難しくなる可能性があり、また需要の調整を遅らせる可能性がある。雇用者であるＣＳＡのスケジュールをぎりぎりの通知で調整することは困難になりかねない。さらに一般的には、通常の分散センターはＣＳＡの補充に平均的な時間を要することになる。コンタクトを取る時間、通勤時間、職場の設定時間などが含まれるこの平均時間が、予測不可能な顕著な需要変動の最小時間（それどころか平均時間）を上回ることも考えられる。さらに、ＣＳＡの供給は顕著な短期変動性を有する。例えば、インフルエンザの集団発生または悪天候により、分散センターの人員が、特定の日または特定の時間に関して予算に計上した人員を遥かに下回ることも考えられる。

これらの要因（供給における柔軟性の欠如、需要と供給の両方における短気の予測できない変動）はコンタクト・割当システムの効果的な管理についての障害の克服を困難にする可能性がある。他の目的との関係において、本発明の実施形態は供給の柔軟性の欠如を低減する市場メカニズムを提供し、短気の変動の影響を緩和することができる。（需要を考慮せずに）タスクを完了できるようにするために利用可能なＣＳＡに対して固定給を支払うのではなく、市場メカニズムを実施するシステムは実際に完了させたタスクに対するタスク毎の報酬に（完全にまたは部分的に）基づきＣＳＡに給与を支払うことができる。さらに市場メカニズムは、所定の作業単位に応じてＣＳＡに支払われる報酬をその作業単位に対する需要により変動させることができる。

ＣＳＡが自身の市場への関与を動的に調整できなければ、タスク毎の報酬の価値および需要に応じた報酬レベルの変動を制限することができる。したがって幾つかの実施形態においては、ＣＳＡは特定の価格で作業単位を提供することを承諾または拒絶することができる。しかしながら、ある期間にわたり分散センターにおいて（または分散センターを用いて）作業することへの同意がＣＳＡに要求される場合、ＣＳＡが個々の作業単位を拒絶できることは、乗り換えコストに起因して実際的というよりは理論的である。

したがって、システムの幾つかの実施形態ではＣＳＡが固定の供給スケジュールから切り離される。短い通知に基づき、また乗り換えコストが低減されたことにより、ＣＳＡが作業単位を完了させるための供給を提供するか否かを選択できることによって、システムはより効果的に実際の供給を実際の需要に合わせることができる。１つの例として、供給を上回る過剰な需要を調整するために、システムは作業単位毎に支払われる報酬額を上げることができる。新たな報酬レベルが特定の独立したＣＳＡの機会コストおよび乗り換えコストを超える場合、その独立したＣＳＡには（それまで利用可能でなかった場合には）供給の提供を開始すること、または、既に働いていた場合には（より一層働くことによって）付加的な供給を提供することの動機が与えられることになる。反対に、実際の供給が実際の需要を上回る場合、システムは作業単位毎の報酬額を下げることができる。新たな報酬レベルが機会コストおよび乗り換えコストを下回る場合、独立したＣＳＡは作業にあまり精を出さないことによって、または何か他のことをすることによって自身の利用可能性を下げることになる。

そのようなシステムにおいて需要に合わせるよう調整を行うレートはＣＳＡが経験した乗り換えコストに少なくとも部分的に依存する。例えば、分散センターにおいて席に着くまで例えば４５分の通勤時間を必要とするＣＳＡは高い乗り換えコストを経験する可能性がある。したがって、幾つかの実施形態では乗り換えコストを低減するためのメカニズムを提供する。例えば、本明細書に記載したシステムの幾つかの実施形態ではＣＳＡを分散センターから切り離すことが試みられる。例えば、ＣＳＡが自宅に居るか近所のコーヒーショップに居る間にコンタクトを提供できる場合、ＣＳＡは市場により関与することになるであろうし、また自身の利用可能性を効果的に調整できるようになるであろう。もちろん幾つかの実施形態では、分散センターに出社するオプションをＣＳＡに提供することができる。ＣＳＡを分散センターから切り離すために、幾つかの実施形態はタスクを完了するためのリモートインタフェースを提供することができる。それらのリモートインタフェースは完了されるべきタスクに応じて変更され、また（例えば）コンピュータ器機、電話機、ユーザインタフェースおよび／または物理的なオブジェクトならびにツールを含むことができる。リモートインタフェースを例えばコンピュータ、電話網および／または通信網によってサポートすることができる。

殊に幾つかの実施形態は独立したＣＳＡおよび／または市場を基礎としたプライシングを許可することができるので、ＣＳＡを通常の分散センターの外部に配置することができ、またＣＳＡにコールの完了に関して動的に変動する価格を提示することができる。独立したＣＳＡは特定のコールまたはコールクラスを受諾するか拒絶するかを選択することができる。

例えば、独立したＣＳＡおよび市場を基礎とするプライシングは顧客のチャットセッションに応答するためにＣＳＡのジャスト・イン・タイム（just-in-time）の利用可能性を提供することができる。到来するチャット要求の量がピークに達すると、システムはチャット要求に応答するために独立したＣＳＡに増額された報酬のオファーを自動的に開始することができる。報酬がＣＳＡの機会コストを上回って増額されれば、より多くのＣＳＡがチャット要求に応答するようになるであろう。したがって、ピークに達している量のチャット要求も、応答のサービスレベル（品質）の僅かな低下で、もしくは無視できる程度の低下で処理を行うことができる。

上記の別の例として、独立したＣＳＡの１つの特定のタイプのコンタクト、すなわちテレフォンコールへの適用を以下において詳細に説明する。以下に記述する原理は他のタイプのコンタクトにも適用できることが分かる。つまり多くのケースにおいては、熟練者がそのようなオブジェクトを処理するためのシステムを設計できることを保証するために、「コール」という用語を「コンタクト」、「作業単位」、「Ｅメール」、「タスク」、「チャット」などに置き換えることができる。

したがって、電話コールセンターを例示的に参照すると、上記のコールセンターシステム１００の幾つかの実施形態によれば、ＣＳＡをシステム１００および／またはエージェントノード２０４から切り離すことができる。したがって、ＣＳＡには電話コネクションおよび／またはデータコネクションだけが要求される。エージェントノードにおける実際の物理的な位置は要求されない。この場合には当然、幾つかの実施形態ではＣＳＡは通常とは異なる方式で雇用され、報酬を受け取ることになる。そのような実施形態は新たなカスタマーサービスのワークシナリオ、例えば自宅で働くＣＳＡ、インディペンデントコントラクターとして雇用されたＣＳＡ、または廉価で一時的な「ショッピングモール」エージェントノードをサポートすることができる。

幾つかの実施形態は、（時給または固定給とは異なり、もしくはそれらに付加的に）その都度のコールを基礎として報酬を受ける少なくとも幾つかのＣＳＡに対して市場メカニズムを提供することもできる。コールに対して市場を基礎とするプライシングを達成するために、幾つかの実施形態は４つの別個の機能を含むことができる：（１）コールに対する価格の決定；（２）その価格のＣＳＡへの通知；（３）コールに対する価格のＣＳＡによる受諾；および（４）所定の価格での受諾されたコールへの課金。

再び図１を参照すると、幾つかの実施形態においては、ＣＲＭ１０１、測定指標サービス１０４、収益サービス１１５、コネクティビティコントローラ１０３またはコールコントローラを用いることにより、それらが単独で、または組み合わされて価格を決定することができる。幾つかの実施形態においては、価格はある程度固定されたものでもよい。例えば、コールに関する価格を所定の固定額に設定することができる。択一的に、価格を個人のコールスキルに関して固定することができ、またリアルタイム市場状況に先立って決定することができる（例えば、価格が経営者側によって設定されている場合）。別の実施形態においては、例えば（制限を課すことなく）、ＣＳＡの利用可能性およびスキルセットの集合、コール量およびスキルセットの集合、時刻、エージェントノード割り当てなどのような多数の要因に基づき価格はフレキシブルで可変のものでもよい。

測定指標サービス１０４およびＣＲＭ１０１は「コール応答能力」の供給に関連する情報、例えばＣＳＡの状態および特性を記憶することができる。上述のように、ＣＳＡプロフィールはスキルを基礎としたルーティングと関連して存在する。応答能力の供給の決定に有効な情報を含ませるためにそれらのプロフィールを拡張することができる。つまり、例えば、システムは現在オンライン中のＣＳＡの１％しか特定のコールの応答に必要なスキルを有していないことを知ることができる。この情報は特定のコールの応答に関して比較的高い価格をサポートすることになるであろう。択一的に、特定のコールを９５％のＣＳＡが応答できる場合、この情報はコールの応答に関して比較的低い価格をサポートできるであろう。１日の特定の時間において利用可能なＣＳＡの数が少ない場合、コールコントローラサービス１０２はコールの応答に関してより高い価格を設定することができる。一般的に、図７，図８または図９において挙げた統合的な情報のいずれかに基づいて、または応答能力に関して取得された他の何らかの統合データに基づいて価格を変更することができる。

特定のＣＳＡに対して価格を決定することもできる。つまり、例えば、特に古参のＣＳＡまたは有能なＣＳＡには経験の少ないＣＳＡまたは未熟なＣＳＡよりも高い価格をオファーすることができる。同様に、上述のような「型にはめられている」ＣＳＡには異なる価格をオファーすることができる。特定のＣＳＡの電話コストまたは計算コストに関する特別な情報に基づき価格を変更することができる。また、特定のＣＳＡに関して取得された何らかのフィードバックに基づいて価格を決定することもできる。一般的に、ＣＳＡの固有情報に基づいて価格を変更することができる。

測定指標サービス１０４およびキューはコール応答能力に対する需要に関連する情報、例えば到来するコール２０６の状態および特性を記憶することができる。上述のように、キューはコール量およびスキルタイプに関する情報を表し、また測定指標サービス１０４はそのような情報を管理する。したがって、特定のコールタイプの予想されるコールボリュームまたはスキル、時刻、もしくは特定のコールがサービスを待機し続けた時間の長さに基づき価格を変更することができる。また一般的に、図７，図８または図９に挙げたコール固有の情報に従い、または到来するコールに関して既知であるいずれかの情報に従い、コール全体を基礎として、またはその都度のコールを基礎として価格を変更することができる。アウトソーシング会社が進んで支払う報酬に基づき価格を変更することができる。

幾つかの実施形態においては、リアルタイムの情報に基づき価格を決定することができ、また迅速に変動させることができる。別の実施形態においては、価格を前もって決定することができる、および／または、ある程度の期間にわたり固定することができる。ＣＳＡの受諾パターンに基づき価格を変動させるか、変更することができる。幾つかの実施形態においては、ＣＳＡ、エージェントノードまたは他のエンティティは、それらが進んでコールを受諾するであろう価格の付け値を提示することができるコールコントローラサービス１０２または他のコンポーネントは価格の低い順、ダッチオークションまたは他の何らかのアルゴリズムで示された価格を受諾することができる。価格はコール毎、１分毎（または他の期間）のコールまたは１分毎（または他の期間）の利用可能性、またはそれらの組み合わせ、もしくは他のイベントタイプにより決定することができる。

図１を参照すると、価格情報はユーザインタフェース１１１（上記を参照されたい）を介してＣＳＡのコンピューティングマシン１０７に通知される。コールコントロールパネル３００（図３Ａ〜図３Ｉを参照されたい）を、特定のコールに対してオファーされた価格、将来のコールに対してオファーされた価格、コールに対する将来の価格スケジュールなどを表示するために補完することができる。ＣＳＡは特定の価格オファーを選択または拒絶することができる。ＣＳＡは異なるコールタイプまたは時間に関する代替的な価格の中から選択を行うことができる。別の実施形態においては、ＣＳＡは特定のコールタイプに関して自身で価格を提示することができる。ＣＳＡは複数のコールスキルタイプに関する価格を受諾することができる。択一的に、少なくとも幾つかの価格受諾機能をエージェントノードおよびエージェントノード管理部に設けることができる。つまり、例えば、特定のエージェントノードはその全てのＣＳＡに関する価格を設定または管理することができる。

幾つかの実施形態では、価格が所定のレベルに合致する、または所定のレベルを上回るか下回ると、例えばＥメール、ポップアップ、インスタントメッセージ、テキスト、テレフォンコールまたは他の通知方法によってＣＳＡに通知を行うことができる。別の実施形態では、特定のＣＳＡは価格のサブセットしか見ることができないように、価格のフィルタリングをサポートすることができる。ＣＳＡは１つまたは複数の何らかの判定基準に従い価格をフィルタリングすることができ、これはコールコントロールパネルまたは他のユーザインタフェースにおける表示に作用を及ぼす。

幾つかの実施形態においては、ＣＳＡはオファーされた価格をコントロールパネル３００または他のユーザインタフェースにおける適切なユーザインタフェースコントロールの選択によって受諾することができる。択一的に、ＣＳＡは利用可能状態に移行することによって価格を受諾することができる。価格の変更は利用可能状態に留まっているＣＳＡによって暗示的に受諾されるか、ＣＳＡが受諾を取り消すまで受諾される。択一的に、価格の変更はＣＳＡの受諾を自動的に終了させることができ、これによりＣＳＡをオフライン状態に移行させることができる。択一的に、幾つかの実施形態においては、ＣＳＡが能動的に（例えばコントロールをアクティブ化することによって）、または受動的に（例えばコールに応答しないことによって、または代替的な状態に移行することによって）コールまたはコールに関する価格を拒絶することができる。

ユーザインタフェースまたはコントロールパネル３００は受諾をコールコントローラ１０２に通知することができ、このコールコントローラ１０２は続けて受諾情報を記憶するか、受諾情報を収益サービス（図１の参照番号１１５を参照されたい）にルーティングする。受諾情報を個々のＣＳＡプロフィール、システム１００のアカウンティングサブシステム、またはネットワークリンクによってシステム１００と接続されている外部アカウンティングシステムと関連させて記憶することができる。択一的に、価格の受諾情報を局所的にＣＳＡのコンピューティングマシン１０７に記憶し、続けてシステム１００または外部システムに伝送することができる。価格受諾情報はＣＳＡが属するエージェントノード２０４（ＣＳＡが実際にそのようなセンターに属している場合）によって受信され、管理されることも考えられる。

幾つかの実施形態においては、ＣＳＡが一度価格を受諾すると、上述の実施形態に従いコールをＣＳＡにルーティングすることができる。ＣＳＡがコールを受け取ると（またはコールを完了すると）、そのコールの交渉価格をＣＳＡの口座に振り込むことができる。完了または受け取ったコールの記録を、そのような記録を管理するエンティティに伝送することができる。このエンティティは上述のような価格受諾情報を管理するために使用されるエンティティ（例えば収益サービス１１５）と同一でもよいが、それらのエンティティは異なるものでもよい。

幾つかの実施形態では価格受諾情報およびコール受け取り情報を含む記録が管理される。この情報を収益サービス１１５によって管理および統制することができる。いずれか時点でＣＳＡにはその労力に対して賃金が支払われる。特定の期間の支払い総額は各支払い分（例えば受け取ったコール、完了したコール、利用可能時間）と支払いイベント毎の交渉価格との積の合計である。当業者には既知の収益・給与メカニズムを使用して、この総額を従業員ＣＳＡの口座に支払いを目的として送金することができる。特定のエージェントノードの従業員であるＣＳＡはエージェントノードから支払いを受けるか、システム（またはシステムオーナ）または収益サービス１１５がそのような資金を調達し、エージェントノードに直接的に送金することができる（エージェントノードは続いてＣＳＡに支払いを行う）。エージェントノードの下では働いていないＣＳＡはシステム１００、収益サービス１１５または適切な金額を振り込むことができる別のシステムを用いる個人的な給与アカウントを有することができる。

択一的に、ＣＳＡはシステム１００、システムオペレータ、第３パーティーの支払いオペレータ、クレジットカードまたはデビットカードを用いる消費者アカウントまたは他の形態のアカウントを有することができる。システムは例えば資金の適切なアカウントへの直接的な送金によって入金することができる。このアカウントを、システム１００のオペレータが所有する代替目的のシステム間で共有することができる。収益サービス１１５はこの情報を管理することができるか、この情報を管理するために他のシステムに通知することができる。つまり、例えば、ＣＳＡは小売店から本を購入することができ（したがって＄２０の借方記入）、ある期間内に１コールにつき３＄でコールに１０回応答することができる（したがって３０＄の貸方記入）。幾つかの実施形態を、ＣＳＡのアカウントへの貸方記入および借方記入の両方を指示するよう構成することができる。幾つかの実施形態においては、ＣＳＡのアカウントはその後１０＄の貸方残高を示すことができる。

当業者であれば、動的なプライシングおよび／またはイベント毎のプライシングを含む実施形態はＣＳＡの雇用およびトレーニングにおけるフレキシビリティおよび効率を提供できることが分かる。例えば、そのような実施形態はＣＳＡに最適な回数のトレーニングを終えることを推奨することができる。従来の時給計算に従った支払いが行われる場合、ＣＳＡは過度に多いトレーニングまたは過度に少ないトレーニングを受ける可能性がある。殊に、ＣＳＡはコールの処理に先だって一定の期間（例えば２週間）トレーニングを受けることが考えられる。そのようなトレーニングには、（殊に「型にはめる」ルーティングシステムが使用される場合には）ＣＳＡが仕事中に自発的には発揮しない、または発揮の機会が見込まれないスキルに関するトレーニングも含まれる。

他方では、ＣＳＡが特定のコールを進んで処理しようとするが、そのようなスキルについてのトレーニングまたは許可を受けていない場合、ＣＳＡは（最適なトレーニングレベルに比べて）トレーニング不足とされる。この事態は、トレーニングを受けて特別なスキルで働くことについての動機がＣＳＡに与えられていない場合（ＣＳＡがコールタイプに関係なく時間給で支払いを受けている場合に起きる）、細密なルーティングに関して効果的なメカニズムが存在しない場合、または、特定のＣＳＡの細密なスキルの検出に関して効果的なメカニズムが存在しない場合に起こりうる。

本発明の幾つかの実施形態では、スキルの一般的な市場価格を考慮して、トレーニングを受けることが理に適っていると思わせる十分な量（また最低限の量）のトレーニングを受けさせる動機をＣＳＡに与える。つまり、例えば特定のコールスキルを処理する資格が与えられたＣＳＡの数が少ない場合、そのようなスキルについてのコール毎の価格は（上述のように）他のスキルに比べて高くなるであろう。そのような高い価格はそのスキルに関する資格を得るために自発的にトレーニングを受けることをＣＳＡに促すことになる。そのスキルに関する資格を与えられたＣＳＡが殺到すると、利用可能なコール応答の供給は増加することになり、したがってそのスキルに関するコール毎の価格は下がることになる。択一的に、過度に多くの（または十分な数の）ＣＳＡが特定のタスクを実施するためにトレーニングを受けている場合、そのタスクに関する価格は下がる可能性があり、これにより特定のタスクに関してトレーニングを受ける将来のＣＡＳの数は減少することが考えられる。

幾つかの実施形態では、就業時間の厳格性を低減することもできる。上述のように、システムに到来するコールボリュームは、分、時、日また月の経過にわたり非常に広範に変化することが考えられる。伝統的な時間決めでの支払いシステム、すなわち時給システムでは、（実際に殺到したコールボリュームが予想されたコールボリューム上回る場合には）人員不足が発生するか、（予想されたコールボリュームが実際のコールボリュームを上回る場合には）過剰人員が発生する可能性がある。しかしながら、そのような状況をある期間、例えば次の予測周期、または次の１時間、または翌日中に調整することはできない。動的なプライシングおよび／または独立したＣＳＡを用いるシステムでは、過剰人員の状況が価格を下げることになるので、このことは何人かのＣＳＡに何かをしながら時間を過ごすことを推奨する。これについて、自宅または他の場所にいるＣＳＡに関しては単純に別のタスクに移ることが考えられ、このようなことは伝統的なコールセンターでは許可または許容されないであろう。他方、人員不足の場合、ＣＳＡにはこの価格がより高い状況を利用することが推奨される。それらのＣＳＡには価格水準または価格限度についてのＥメールまたはテキスト（または他のシステム）による通知が行われる設定になっているか、ＣＳＡが自身のコンピュータまたは他の機器においてシステムとのユーザインタフェースを開いた状態で維持している場合には、ＣＳＡに高い価格を通知することができる。幾つかの実施形態では、ＣＳＡ（およびエージェントノードのオペレータ）に対して比較的低い乗り換えコストを提供することができる。例えば、ＣＳＡの１つのスキルに関する価格が＄５／コールである通知をＣＳＡが受け取ったときに、ＣＳＡが自宅で勤務時間外に状況をオンライン検索するようＣＳＡを誘導することができる。これによりＣＳＡはログインして、その価格についての好機を利用するために自身の状態を利用可能にすることができる。

幾つかの実施形態は、ＣＳＡの独立的および／または非伝統的なトレーニングを提供することができる。トレーニングをモジュール方式で（例えばＣＳＡが個別に受けることができる比較的連続していない単位で）行うことができ、またユーザインタフェース（図１の参照番号１１１を参照されたい）または電話コネクション、もしくは両方を介して提供することができる。エージェントノードまたは他の物理的な場所においてトレーニングを提供することができる。

上記においてはコールセンターに関連させて説明したが、当業者であれば独立したＣＳＡの原理をより広範に適用できることが分かる。殊に、独立したＣＳＡが契約を結ぶことができる作業単位を「コール」と表したが、単純に、通信、サービス、課業、もしくは、Ｅメール、チャットまたはインスタントメッセージなどによるコンタクトと表すこともできる。システム１００は複数のタイプのコンタクト（例えばＣＳＡが電話に応答し、Ｅメールを送信する）を実施することもできる。つまりそのようなシステムにおいては、例えばコールコントローラ１０２および／または電話コントローラ１０３を、相補的または付加的に、コールコントローラおよび電話コントローラによってコールについて実施される機能に類似する、Ｅメールについての機能を実施することができる「Ｅメールコントローラ」に置換することができる。

図１２は、コンタクトの分散を実施するシステム１００’の代替的な例を示す。図１２において、システム１００’は到来するコンタクトボリューム１２１０を複数のＣＳＡ２０５にルーティングする。このコンテクストにおいて、コンタクトは本明細書において記載した項目、例えば電話コール、Ｅメール、インスタントメッセージなどのいずれかでよい。到来するコンタクトボリューム１２１０は複数のタイプのコンタクトを含むことができる。システム１００’は到来するコンタクトボリューム１２１０の中から複数のコンタクトを受け取る。システム１００’のルーティングおよび分散コンポーネント１２２０は到来するコンタクトをＣＳＡ２０５のリモートインタフェースに直接的に転送、ルーティング、接続することができる。システム１００’およびＣＳＡリモートインタフェース１２２５は、到来するコンタクトタイプに関するコネクティビティを実現するために使用される特別なハードウェアおよび／またはソフトウェアを有することができる。例えば、システム１００’がＥメールおよび電話コールを処理すべき場合には、ネットワーキングおよび電話ソフトウェアおよび／またはハードウェアを、ルーティングおよび分散コンポーネント１２２０および幾つかのＣＳＡリモートインタフェース１２２５の一方または両方に含ませることができる。リモートインタフェース１２２５を標準化させることができるが、変更することもできる。全てのリモートインタフェースが各コンタクトタイプに関する機能を実施する必要はない。リモートインタフェース１２２５は、利用可能状態、利用不可能状態、また本明細書において記載した状態の幾つかまたは全てを指示することができるメカニズムをＣＳＡ２０５に提供することができる。リモートインタフェース１２２５はシステム１００’と通信することができ、これによりシステム１００’のコンポーネントによって提供される情報または機能をリモートインタフェース１２２５に伝送することができる。したがって、リモートインタフェース１２２５も同様に情報（例えばＣＳＡの受諾）をシステム１００’のコンポーネントに伝送することができる。

ルーティングおよび分散コンポーネント１２２０をプライシングコンポーネント１２３０に接続することができる。プライシングコンポーネント１２３０は上述したようなコンタクトに関連付けられた価格および他のデータを決定することができる。つまり、例えば、プライシングコンポーネント１２３０は１つの特定のタイプのコンタクト（例えばインスタントメッセージ）に関する提供価格を市場情報または市場状況、例えば、非常に多数のインスタントメッセージが到来する状況などに応じて調整することができる。プライシング情報をリモートインタフェース１２２５にプッシュすることができる。

収益コンポーネント１２３１は複数のコンポーネントおよびリモートインタフェース１２２５からの情報、例えばプライシングおよび受諾情報を追跡、利用もしくは処理することができる。フィードバックコンポーネント１２３２をルーティングおよび分散コンポーネント１２２０、リモートインタフェース１２２５または他のコンポーネントに情報を提供するために使用することができる。フィードバックを顧客のルーティングに利用することができる（例えば、顧客が前もってＣＳＡに対して肯定的なフィードバックを残していた場合、その顧客が後続のコールにおいてそのＣＳＡに再びルーティングされる可能性がより高くなる）。

トレーニングコンポーネント１２３３も同様に情報を利用し、また提供することができる。例えば、トレーニングコンポーネント１２３３はトレーニング情報をプライシングコンポーネント１２３３に提供することができ、このトレーニング情報を特定のＣＡＳスキルの供給の決定に利用することができる。トレーニングコンポーネントは情報を受け取り、これによりどのＣＳＡが特定の単位のトレーニングからの利益を必要としているか、利益を得るか、または利益を得そうであるかを計算することができる。トレーニングコンポーネントは特定のＣＳＡ２０５にそのＣＳＡ２０５に属するリモートインタフェース１２２５を介して直接的にトレーニングを提供することができる。

図１２のシステム１００’のオペレーションの例として、到来するコンタクトボリュームは特定のユーザからのＥメールを含むものとする。プライシングコンポーネントは、この特定のユーザおよびコンタクトタイプおよびスキルに関するＥメール応答の一般的なレートは２＄であると決定することができる。情報をリモートインタフェース１２２５にプッシュすることができ、ＣＳＡは＄２／ＥメールでＥメールに応答するために自身は「利用可能である」か否かを決定することができる。したがって、ルーティングおよび分散コンポーネント１２２０は＄２／Ｅメールを受諾しようとするＣＳＡの中から１人のＣＳＡを選択することができる。

ルーティングおよび分散コンポーネント１２２０は、例えばリモートインタフェース１２２５の表示装置上に表示されるべきＥメールの同様のバージョンが生じることによって、選択されたＣＳＡ２０５のリモートインタフェース１２２５にＥメールを送信（さもなければ配布）することができる。

コンタクトの終了時に（もっとも他の時間トリガおよびイベントトリガも考えられる）、収益、フィードバックおよびトレーニングについての情報を形成することができる。ＣＳＡ２０５に＄２を振り込むことができ、ユーザはフィードバックを問い合せることができ、（また必要に応じてこのフィードバックに基づいて）ＣＳＡ２０５に特定のトレーニングを受けるよう提案することができる。

その後ユーザはシステム１００’と、以前のコンタクトタイプとは異なるタイプであることが考えられる別のコンタクトを取ることも考えられる。したがって、例えば、ユーザはインスタントメッセージを介してシステムとコンタクトを取ることが考えられる。ここで、ルーティングおよび分散コンポーネント１２２０は、最初のＥメールを処理したＣＳＡと同一のＣＳＡ２０５にユーザのメッセージをルーティングするために、それぞれのコンポーネント１２３２および１２３３によって提供されたフィードバックおよびトレーニング情報を利用することができる。

図１２は、システム１００’内に包含させることができるコンポーネントの内の一部のみを示している。多くの付加的なコンポーネント、例えば異なるタイプのコンタクトのためのコントローラ、ＣＲＭ、測定指標サービスなどを含ませることができる。さらには、本明細書において記載したような各コンポーネントに属する機能を他のコンポーネントに伝送することができるか、そのような機能を共有することができる。本明細書においては「コール」または「コンタクト」と記述していることが多い、システムによってルーティングされる作業単位は通信に制限されるものではない。システム１００’はパーティー間の通信を要求しない分散ユニットまたはオブジェクトにも適している。つまり、例えば、システム１００’は雑用およびタスク（例えば印刷要求、調査要求、会計報告および物理的な構築要求）、追跡調査、遅れが生じているインタラクションなどを分散させることができる。そのような場合、システム１００’はサービスレベルおよび品質期待値を維持および遵守するためのメカニズムを提供するという利点をもたらすことができる。

測定指標
図１に示されているように、コールコントローラサービス１０２（およびシステム１００の他の構成要素）は、コール、顧客、ＣＳＡなどに関する測定指標の記憶も検索も行う測定指標サービス１０４を使用することができる。そのような統計量を収集し、分析し、および／または、表示することができ、正当な許可が与えられている人間はそれらをビューすることができる。

表示および分類を目的として、測定指標をリアルタイム統計量と履歴統計量に分類することができる。この区別は表示の形式設定を目的とした場合に重要な役割を果たす。リアルタイム統計量は、単一のデータポイント、一般的には「現在」値のみを有する統計量として規定される。これに対し、履歴統計量は時間（例えば、数分の期間、３０分の期間、数日または不定の期間）にわたる範囲の値のセットを有する。多くの場合、リアルタイム統計量はシステムの目下の状態、例えばキューにおけるコールの数、利用可能なＣＳＡの数などを反映する。しかしながら、幾つかの「リアルタイム」統計量は履歴情報を含む。例えば「目下の」ＳＬを他のリアルタイム統計量と共に表示することができ、またこのＳＬはそのコンテクストにおいて、当日における（その時点までの）全てのコール（またはＳＬ計算において使用されたいずれかのコール）に関するサービスレベルを意味する。

システム１００、例えばＣＲＭ１０１はＣＭＳを基礎とするウェブページを提供することができ、このウェブページにおいて（正当な許可が与えられている）人々はリアルタイムデータを検索することができる。幾つかの実施形態は、各エージェントノードに関するデータをビューすることができるユーザを制限することができる。例えば、カスタマーサービス課出身の人は全てのエージェントノードに関するリアルタイムデータをビューすることができるが、外部のエージェントノードは自身のオペレーションに関するデータをビューするためのアクセスしかできない。リアルタイム測定指標は種々のやり方で「ロールアップ」（結合および／または統合）することができ、また位置、チームおよびスキルの適切な組み合わせを反映することができる。サンプルデータが図７に示されている。この図７には、位置（上側半分、参照番号７０１）およびスキル（下側半分、参照番号７０２）によって編成されたリアルタイムデータを示す。これらの図面は例示的なものに過ぎず、また本発明の範囲から逸脱することなく種々に変更することができる。測定指標サーバ（図１，参照番号１０４）は、（１）企業；（２）所定の位置；および／または（３）チームを含む種々の編成レベルにおけるデータのビューを提供することもできる。これらのビュー（企業、位置、チーム）はそれぞれ、例えばサブグループおよび／またはスキルによって生じる同様の統計量を提供することができる。

図８は、測定指標サービス１０４によって保存またはレポートすることができる、幾つかの統計量の名前および記述の表を示す。この表は強制的なもの、または排他的なものを意図しているのではない。さらに幾つかの実施形態は個々のＣＳＡに関する詳細な統計量を保存およびレポートすることができる。保存または計算することができる、したがってユーザに表示するために選択することができる幾つかの情報は以下の情報を含む：
ＣＳＡログイン：ＣＳＡのログインまたはＩＤ。
ＣＳＡ名：ＣＳＡの姓名。
ＣＳＡ内線：ＣＳＡの内線番号または電話番号。
目下の状態：ＣＳＡの目下の状態、必要に応じてキューも含まれる。
状態継続時間：ＣＳＡがその状態にある合計時間。
融合タイプ：ＣＳＡの融合タイプ。以下のタイプの内の１つでよい：（１）最も古いコール；（２）順番通りのキューの選択；または（３）ハイブリッド。
スキル：ＣＳＡが処理できる全てのスキルのリスト。

測定指標サービス１０４は、種々の状態における時間閾値を超えたＣＳＡを識別するための機能を提供することもできる。これは、例えば何らかの条件が度を超え強調されているＣＳＡ、Ｅメールを送信する適切なマネージャによって達成することができる。幾つかの実施形態は、異なるＣＳＡ状態に対して異なる閾値を提供することによって、または複数の閾値（例えば「警告」および「危険」）を提供することによって、この機能を部分的に実施することができる。幾つかの実施形態は、例えばスキルタイプ、位置またはＣＳＡの経験などによって閾値を動的に変更することができる。択一的に、静的な「万能（one-size-fits-all）」アプローチを利用することができる。

履歴統計量を一般的に、特定の期間にわたるログにアクセスすることによって計算することができる。履歴統計量は、システム１００において今現在何が起きているかを反映することができない。リアルタイムデータを用いる場合のように、許可されたユーザには履歴データの種々のビューを表示することができる。履歴データをビューさせるための判定基準の例はサービスレベル、コール数、種々の状態で過ごしたＣＳＡ時間、平均時間のようなコール測定指標などが含まれるが、これらに制限されるものではない。

図９に示されているように、履歴データのビューはエージェントノード２０４と個々のＣＳＡに関する以下のものを各々含んでいてもよい：受け取ったコール数９０１、平均サービスレベル９０２、平均保留時間、平均通話時間９０３、他の状態に関する平均時間（例えば９０４）および平均放棄時間９０５（すなわちＣＳＡによって応答されることなく顧客が「電話を切った」平均時間）など。ビューをエージェントノード９０６、日時９０７または他のいずれかのカテゴリ毎に記憶することができる。カテゴリを一般的に開く（参照番号９０８を参照されたい）ことができ、カテゴリは履歴情報（例えばエージェントノードに属するＣＳＡ）から成る。図１０に示されているように、幾つかの実施形態は、ビューアが特定のエンティティに関するより詳細な結果をビューするために個々のＣＳＡ（または他のカテゴリにおける他のエントリ）を選択することができる。

図１１Ａ〜図１１Ｃは、測定指標サービス１０４によって計算することができる幾つかの統計量を表の形で示したものである。このリストは排他的なものではない。列の先頭の「統合タイプ」１１０１は非排他的なカテゴリを表し、このカテゴリの下において特定の統計量を統合または結合することができる。「スキルロールアップ」１１０２は非排他的なスキルグループ分けを表し、このカテゴリの下において所定の統計量を統合することができる。「インターバルロールアップ」１１０３は非排他的な例示的な期間を表し、このカテゴリの下において統計量を統合することができる。これらの列におけるデータは見易くするために限定されたものと解される。当業者であれば、ここに示していない多数の代替的なデータも考えられることが分かる。

測定指標をシステムによって収集することができ、また、例えば管理者による使用のために出力することができる。例えば、希望のコンタクトまたは容易に応答できる（easy-to-answer）コンタクトのＣＳＡによるチェリーピッキングを発見または緩和するために特定のコンタクトに関する放棄率を利用することができる。幾つかの実施形態においては、あるコンタクトが特定のＣＳＡのスキルレベルを超えている場合、コンタクトについての属性の追加によってＣＳＡを補うことができる、および／または、ＣＳＡはコンタクトを適切にルーティングさせることができる。

フォールトトレランス
幾つかの実施形態を、特定のシステムコンポーネントが利用不可能な状況に直面した際にロバストであるよう設計することができる。例えば、幾つかの実施形態は、システム１００内の障害およびシステム１００の障害（またＣＳＡ利用可能性情報に関して、情報システムが依存している基礎をなすサービス、例えばネットワーキングおよびプロキシサーバの障害）に耐性があるよう設計することができる。ＣＲＭアクセスを妨げるネットワーキングの問題が存在する場合、耐性のないシステムはコールを受け取るためにどのＣＳＡが利用可能であるかを知ることはできない。したがって幾つかの実施形態は、ＣＳＡが顧客からのコールを受け取るために利用可能であることをシステムに知らせるためにＣＲＭシステムを使用することができない場合には、ＣＳＡがコールすることができるＩＶＲアプリケーションを含むことができる。ＣＳＡの電話システムがコールを行うことができるときは何時でも、ＩＶＲアプリケーションを利用することができる。

別の例として、システム１００およびそのコンポーネントを可能な限り高度に利用できるように幾つかの実施形態を設計することができる。幾つかの実施形態は、部分的に、システム１００およびそのコンポーネントを可能な限り簡潔に設計することによってこの問題に取り組むことができる。これにより、機能停止の最も一般的な原因として考えられるソフトウェアの問題を最小にすることができる。この設計の追究において、システム内のハードウェア、ソフトウェアまたはネットワーキングの障害が常に存在するような場合には、機能を短時間停止させることも考えられる。この問題に取り組むために、幾つかの実施形態は主たるシステム１００に障害が発生した場合に、その機能を引き継ぐことができるウォームスタンバイシステムを含むことができる。幾つかの実施形態は、主たるシステムに１〜２分の障害が発生した場合には、ウォームスタンバイシステムを主たるシステムに置き換えることができる。この間、コールは繋がらない可能性がある。択一的には、システムをバックアップに移行させている間、コールを途絶えさせず、またはコールを切断させずに、顧客は通常よりも少し長く単純に保留状態で待機させられる。

ネットワークの機能停止の処理
幾つかのケースにおいては、システム１００が到来するいずれのコールも処理しないことを選択することができる。例えば、キーサービスにアクセスすることができず、またシステムが顧客はＣＳＡのヘルプを受けられないことを知る場合、サービス機能が復帰するまでの期間は、単純に、到来する顧客コールを処理しないことは有利である。

幾つかの実施形態はユーザインタフェースを提供することができ、このインタフェースにおいて管理者は（場合によっては選択されたスキルに関して）保留中の顧客とのコネクションを切断することができ、新たな顧客とのコネクションの確立を阻止することができる。幾つかの実施形態では、選択されたスキルに関して保留中の各顧客に対してメディアメッセージを再生し、その後に顧客とのコネクションを切断することができる。いずれのコールも受諾しないように構成されているスキルについてコールを行った新たな顧客の各々に対して、幾つかの実施形態ではメディアメッセージを再生し、続いて顧客とのコネクションを切断することができる。幾つかの実施形態においては、このスキルを処理するＣＳＡと今現在接続されているコールは切断されない（場合によっては、ＣＳＡは必要に応じて単純に電話を切ることができるため）。セキュリティおよび監査に関する予防措置として、システム１００はＥメール通知を特定のＥメールリストに送信することができ、これは誰かがこの機能に従事しているときには何時でも行われ、場合によっては、この状態を使用可能な管理者のログインも、（管理者が与えた）この動作を行うための理由も捕捉することができる。

エージェントノードの停止
幾つかの実施形態は、エージェントノード２０４を停止させるオプションを提供し、このオプションではコールがエージェントノードにルーティングされない。このアクションが実施されると、（１つまたは全ての）スキルもエージェントノードも特定することができる。択一的に、１つのエージェントノードにおいて問題が発生している場合、ＣＳＡには単純にコールを要求しないことを指示することができ、続いてシステムはそれらのＣＳＡにコールをルーティングしなくなる。

エージェントノードの停止はノード固有のキューへのあらゆるコールの到来を阻止することができるので、それらのコールは即座にそれらを受け取ることができるエージェントノードにルーティングすることができる（この際に、最初にプライオリティキューに移されることは必要ない）。

結論
条件を表す記述、例えば、とりわけ「可能である」、「可能性がある」、「であろう」または「できる」は、別個の記載が無い限り、もしくは使用されているコンテクスト内で理解される限り、一般的に特定の実施形態は特定の特徴、構成要素および／またはステップを含むが、他の実施形態はそれらの特定の特徴、構成要素および／またはステップを含まないことを意味する。したがってそのような条件を表す言葉は、特徴、構成要素および／またはステップが１つまたは複数の実施形態にいずれにせよ必要とされること、または１つまたは複数の実施形態が、ユーザ入力またはプロンプトの使用の有無に拘らず、それらの特徴、構成要素および／またはステップがいずれかの特定の実施形態に含まれるか否か、またはいずれかの特定の実施形態において実施されるべきか否かを決定するためのロジックを含んでいなければならないことを意味しているのではない。

本明細書において説明した、および／または、添付の図面に示したフローチャートにおけるあらゆるプロセスの説明、構成要素またはブロックは、プロセスにおける特定の論理的な機能またはステップを実施するための１つまたは複数の実行可能な命令を含むコードモジュール、コードセグメントまたはコード部分を潜在的に表すものと解されるべきである。当業者であれば分かるように、択一的な実施形態は、そこに含まれる機能に依存して構成要素または機能を削除することができるか、（実施的に同時の実施または反対の順序での実行も含めて）図示または説明した順序とは異なる順序で実行することができる、本明細書において説明した実施形態の範囲に含まれる。

上記の実施形態についての種々のヴァリエーションおよび修正形態が考えられ、それらの構成要素は他の許容される実施例に含まれると解するべきである。そのような全ての修正形態およびヴァリエーションは本願明細書の範囲に含まれ、添付の特許請求の範囲に記載された発明によって保護されることが意図されている。

Claims (20)

1. コンタクトを自動的に分散させるためのシステムにおいて、
   コンタクト分散コンポーネントと、前記コンタクト分散コンポーネントと通信するプライシングコンポーネントと、前記コンタクト分散コンポーネントと通信する収益コンポーネントとを有し、
   前記コンタクト分散コンポーネントは、到来するコンタクトを、該到来するコンタクトを処理することができるリモートエージェントの能力を表すプロフィールを有しているリモートエージェントにルーティングし、前記リモートエージェントが前記到来するコンタクトを拒絶することを可能にし、
   前記プライシングコンポーネントは、該到来するコンタクトを処理するために支払われるべき、前記リモートエージェントにオファーされる価格を設定し、前記プライシングコンポーネントは、市場を基礎としたプライシングに関連する測定指標に基づいて前記価格を決定するように構成されており、
   前記収益コンポーネントは、前記プライシングコンポーネントによって設定された価格の前記リモートエージェントへの支払いを開始する、
   コンタクトを自動的に分散させるためのシステム。
2. 前記市場を基礎としたプライシングに関連する測定指標は、
   （１）利用可能で、かつ、前記到来するコンタクトを処理する特定のスキルを有するリモートエージェントの数、
   （２）前記リモートエージェントによって提供されたサービスの質についての事前のレビュー、および、
   （３）前記リモートエージェントが、進んで受諾することを表した最低価格
   のうちの１つ以上を含む、請求項１記載のシステム。
3. コンタクトを自動的に分散させるためのコンピュータ実施方法において、
   到来するコンタクトを処理するリモートエージェントを選択するステップを有し、該リモートエージェントは、当該エージェントが前記到来するコンタクトを処理することができることを表すプロフィールに関連付けられており、
   市場を基礎としたプライシングに関連する測定指標に基づいて、前記到来するコンタクトを処理するために、前記リモートエージェントに支払われるべき価格を設定するステップを有し、
   前記価格を前記リモートエージェントにオファーするステップを有し、
   前記到来するコンタクトを、識別されたエージェントにルーティングするステップを有し、該識別されたエージェントは、少なくとも、前記オファーされた価格に基づいて、前記到来するコンタクトを拒絶することが可能である、コンタクトを自動的に分散させるためのコンピュータ実施方法。
4. 前記市場を基礎としたプライシングに関連する測定指標は、利用可能で、かつ、前記到来するコンタクトを処理する特定のスキルを有するリモートエージェントの数を含む、請求項３記載のコンピュータ実施方法。
5. 前記市場を基礎としたプライシングに関連する測定指標は、前記リモートエージェントによって提供されたサービスの質についての事前のレビューを含む、請求項３記載のコンピュータ実施方法。
6. 前記市場を基礎としたプライシングに関連する測定指標は、前記リモートエージェントが、進んで受諾することを表した最低価格を含む、請求項３記載のコンピュータ実施方法。
7. 前記識別されたエージェントは、コントロールをアクティブ化することにより、前記到来するコンタクトを能動的に拒絶することが可能である、請求項３記載のコンピュータ実施方法。
8. 前記設定された価格は固定の価格か可変の価格である、請求項３記載のコンピュータ実施方法。
9. 前記リモートエージェントは１つのエージェントノードに属する、請求項３記載のコンピュータ実施方法。
10. 前記エージェントノードは１つのエージェントまたは物理的に一緒にグループ化された複数のエージェントを有する、請求項９記載のコンピュータ実施方法。
11. 前記エージェントノードは１つのエージェントまたは論理的に一緒にグループ化された複数のエージェントを有する、請求項９記載のコンピュータ実施方法。
12. １つまたは複数の前記エージェントは、少なくとも部分的にプロフィールに基づいて、論理的に一緒にグループ化されている、請求項１１記載のコンピュータ実施方法。
13. さらに、前記到来するコンタクトおよび前記リモートエージェントに関連する測定指標を収集するステップを含む、請求項３記載のコンピュータ実施方法。
14. さらに、前記到来するコンタクトを、集中キューに関連付けられた１つのルーティングキューに割り当てるステップを含み、前記ルーティングキューは１つのエージェントに割り当てられている、請求項３記載のコンピュータ実施方法。
15. さらに、前記到来するコンタクトに関連するフィードバックを前記識別されたエージェントに関連付けるステップを有する、請求項３記載のコンピュータ実施方法。
16. さらに、前記到来するコンタクトの前記識別されたエージェントへのルーティングに少なくとも部分的に基づいて、トレーニング管理を決定するステップを有する、請求項３記載のコンピュータ実施方法。
17. 前記到来するコンタクトは電話コールまたは電子メッセージのうちの少なくとも１つである、請求項３記載のコンピュータ実施方法。
18. コンタクトを自動的に分散させるシステムにおいて、
    コンタクト分散コンポーネントと、前記コンタクト分散コンポーネントと通信するプライシングコンポーネントとを有し、
    前記コンタクト分散コンポーネントは、到来するコンタクトを、該到来するコンタクトを処理できることを表すプロフィールを有しているリモートエージェントに向け、前記リモートエージェントは、前記到来するコンタクトを拒絶することが可能であり、
    前記プライシングコンポーネントは、該到来するコンタクトを処理するために支払われるべき、前記リモートエージェントにオファーされる価格を設定し、
    前記プライシングコンポーネントは、
    （１）利用可能で、かつ、前記到来するコンタクトを処理する特定のスキルを有するリモートエージェントの数、
    （２）前記リモートエージェントによって提供されたサービスの質についての事前のレビュー、および、
    （３）前記リモートエージェントが、進んで受諾することを表した最低価格
    のうちの１つ以上に基づいて、前記価格を決定するように構成されている、
    コンタクトを自動的に分散させるシステム。
19. コンタクトを直接的に、該コンタクトを処理できるエージェントに自動的に分散させるコンピュータ実行可能コンポーネントを有するコンピュータ読取り可能媒体において、
    前記コンピュータ実行可能コンポーネントは、コンタクト分散モジュールと、該コンタクト分散モジュールと通信するプライシングコンポーネントと、ユーザインタフェースモジュールとを有し、
    前記コンタクト分散モジュールは、前記リモートエージェントが、該到来するコンタクトを処理できることを表し、且つ、該リモートエージェントに関連付けられているプロフィールを有しているリモートエージェントに前記到来するコンタクトを向け、
    前記プライシングモジュールは、前記到来するコンタクトを処理するために支払われる、前記エージェントにオファーされる価格を設定し、
    前記ユーザインタフェースモジュールは、前記リモートエージェントが、前記到来するコンタクトを処理するための前記リモートエージェントにオファーされた価格を受諾することを可能にし、
    前記プライシングコンポーネントは、市場を基礎としたプライシングに関連する測定指標に基づいて前記価格を決定するようにさらに構成されている、
    ことを特徴とする、コンピュータ読取り可能媒体。
20. 前記市場を基礎としたプライシングに関連する測定指標は、
    （１）利用可能で、かつ、前記到来するコンタクトを処理する特定のスキルを有するリモートエージェントの数、
    （２）前記リモートエージェントによって提供されたサービスの質についての事前のレビュー、および、
    （３）前記リモートエージェントが、進んで受諾することを表した最低価格
    のうちの１つ以上を含む、請求項１９記載のコンピュータ読取り可能媒体。

Images