(57)【特許請求の範囲】
【請求項１】
マルチメディアマルチネットワーク通信環境中で、発呼者からの第１の通信モードにおける到来通話に応答して、ルータアプリケーションが発呼者とワークステーションにおけるエージェントとの間に通信を確立する方法において、
（ａ）ルータアプリケーションにより到来通話を受信し、
（ｂ）ルータアプリケーションによりワークステーションにおけるソフトウェアに対して、ワークステーションの可能性ある状態の優先順位リストを提供し、
（ｃ）ワークステーションにおけるソフトウェアによりルータアプリケーションに対して、優先順位リスト中の最高の優先順位に基づいて、ワークステーションのステータスを報告し、
（ｄ）ワークステーションの可能性ある状態を参照することにより、発呼者とワークステーションにおけるエージェントとの間で可能性ある共通の通信モードを決定し、
（ｅ）発呼者とワークステーションにおけるエージェントとに共通の通信モードであって、第１の通信モード以外である通信モードで、発呼者とワークステーションにおけるエージェントとの間にルータアプリケーションにより通信を確立するステップを含む方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明はコールセンターにおける電話通信に関し、特に、複数のオブジェクト状態をとることができる、コールセンター中のエンティティのステータスを決定する方法およびシステムに関する。
【０００２】
本願は、１９９７年１月２１日に出願され、同じ譲受人に譲渡された、同じ名称および発明者の特許出願第０８／７８６，８１７号の一部継続出願である。この先の出願は参照により完全にここに組み込まれている。
【０００３】
【従来の技術】
電話は、世界中で最も広く使用されている通信装置の中に入っている。当初電話は人々が物理的に離れているにも関わらず通信できる単なる便利なツールであった。さらに最近では多くの人々および組織が電話を使用して製品やサービスを売買し、消費者製品に対して技術的サポートを提供し、発呼者が自分自身の金融データ等にアクセスできるようにされている。したがって、電話は主要なビジネスおよび取引ツールとなってきた。
【０００４】
ビジネスや取引目的に電話システムをもっと有効に使用するために、コールセンターが開発されている。コールセンターでは、非常に多くのエージェントが発呼者との電話通信を取扱う。発呼者とエージェント間の通話のマッチングは一般的にコンピュータ化スイッチング装置とともに動作するソフトウェアによりなされる。
【０００５】
ここでは簡単な例を使用してコールセンターを使用する多くの利点のうちのいくつかを説明する。コールセンターに対して通話がなされると、一般的に電話通信事業者により通話回線の電話番号がコールセンターに入手可能である。この電話番号に基づいて、コールセンターのソフトウェアはデータベースサーバにアクセスし、発呼者の電話番号をキーとして使用して発呼者についての情報を得ることができる。ソフトウェアは予め定められた基準（例えば、言語スキル、発呼者が購入した製品についての知識等）に基づいてその通話を最高に取扱うことができるエージェントに到来通話をルーティングする。ソフトウェアはまた、データベースから導き出された発呼者についての情報を、エージェントにより使用されるコンピュータスクリーンに直ちに伝えさせる。したがって、エージェントは通話が終端するときに、あるいは通話を受ける前でさえ発呼者についての価値のある情報を得ることができる。結果として、エージェントはさらに効果的に電話処理を取扱うことができる。
【０００６】
先の例から、有効な技術は電話スイッチング技術とコンピュータ情報処理技術の結合を必要とすることが分かるであろう。この結合された技術のために一般的に使用される用語は、コンピュータ−テレフォニ統合（ＣＴＩ）である。
【０００７】
ルーティングの決定をする際に、ルーティングソフトウェアはすべてのエージェントの状態を知る必要がある。例えば、エージェントがビジー状態である（例えば、他の通話に答えている）場合には、通話はそのエージェントにルーティングされない。従来技術のＣＴＩシステムでは、エージェントは１つの状態のみを持つ。ルーティングソフトウェア（とともにシステム中の他のソフトウェア）はこの状態に基づいて決定をする。しかしながらこのようなシステムには柔軟性がない。例えば、エージェントが何らかの仕事をしていて（例えば、緊急でない事項について同僚と会話していて）ビジーであっても、カスタマからの通話をとるために手が空いている他の適任なエージェントがいない場合には、エージェントはその通話を受け入れることができるかもしれない。
【０００８】
【発明が解決しようとする課題】
したがって、コールセンターのリソースをよりよく利用することができる柔軟性あるシステムを得ることが望ましい。
【０００９】
【課題を解決するための手段】
本発明は要求ソフトウェアアプリケーションに対してコールセンター中のエンティティのステータスを柔軟性を持って報告する方法に関係している。エンティティは現在、複数の可能性ある状態のうちの（アクティブ状態と呼ばれる）１つ以上の状態に入ることができる。第１の（報告）ソフトウェアアプリケーションは、（ｉ）エンティティのアクティブ状態、および（ｉｉ）第２の（要求）ソフトウェアアプリケーションにより提供される優先順位リストに基づいてエンティティのステータスを決定する。その後この報告ソフトウェアアプリケーションはステータスを要求ソフトウェアアプリケーションに報告する。
【００１０】
この発明の１つの利点は、要求ソフトウェアアプリケーションが状態の優先順位を決定することである。おそらく、各要求ソフトウェアアプリケーションにはこの状態情報を利用するための最良の方法が分かっている。したがって、要求ソフトウェアアプリケーションが優先順位を決定できるようにすることは、同じステータスをすべての要求ソフトウェアアプリケーションに報告するよりも非常によいことである。
【００１１】
本発明の１つの実施形態では、エンティティには物理的なエンティティ（例えば、キューおよびルーティングポイント、エージェントディレクトリ番号、ならびにエージェント）と論理的なエンティティ（例えば、エージェント場所、およびグループ）が含まれている。各エンティティはソフトウェアオブジェクトと関係している。各オブジェクトは１つ以上の可能性のある状態と１つ以上のアクティブ状態を持つことができる。要求ソフトウェアアプリケーションは各エンティティオブジェクトに対してこれらの可能性ある状態の優先順位を設定し、それらを例えばステータス優先順位テーブルの形態で表す。このテーブルは報告ソフトウェアアプリケーションに送られる。報告ソフトウェアアプリケーションは、最高の優先順位を持つアクティブ状態としてオブジェクトのステータスを報告する。
【００１２】
本発明の他の実施形態では、要求ソフトウェアアプリケーションは報告ソフトウェアアプリケーションに対してステータスを一度だけ報告するように要求してもよい。代わりに、要求ソフトウェアアプリケーションは連続ベースで報告することを要求してもよい。報告ソフトウェアアプリケーションは報告の頻度を規定することができる。
【００１３】
本発明は単一の自動通話分配装置システムおよび複数の自動通話分配装置システムにおいて使用することができる。
【００１４】
本発明のこれらのおよび他の特徴は、添付した図面とともに読むと、以下の説明から明らかになるであろう。
【００１５】
【発明の実施の形態】
本発明は新規なコールセンター方法およびシステムを含んでいる。以下の説明は、当業者が本発明を作りそして使用できるように提供されている。特定の応用の説明は例としてのみ提供されている。説明されている好ましい実施形態に対するさまざまな修正は当業者に容易に明らかになるであろう。また、ここに規定されている一般的な原理は本発明の精神および範囲を逸脱することなく他の実施形態および応用に適用してもよい。したがって、本発明は示されている実施形態に限定されることを意図しているものではなく、ここに開示されている原理および特徴と矛盾しない最も広い範囲にしたがうものである。
【００１６】
図１は本発明を実現するのに使用することができるコールセンター１００のブロック図である。コールセンター１００は公衆電話交換ネットワーク（ＰＳＴＮ）１０４に接続されている。コールセンター１００には、ＰＳＴＮ１０４からの通話を受け入れるスイッチ１０８が含まれている。スイッチ１０８は、自動通話分配装置（ＡＣＤ）、構内交換機（ＰＢＸ）またはＰＳＴＮスイッチとすることができる。スイッチ１０８には、（ＰＳＴＮ１０４に接続するための）高帯域幅ポート１１０と（ポート１１２−１１６のような）複数の低帯域幅ポートが含まれている。これらの低帯域幅ポートのうちいくつかは音声ベースの装置に接続することができる。例えば、ポート１１２−１１５はそれぞれ電話機１２０−１２３に接続されている。エージェントはこれらの電話機を取扱うように割り当てられる。各低帯域幅ポートには１つ以上のディレクトリ番号（“ＤＮ”）が割り当てられている。
【００１７】
標準的なスイッチにより実行される機能はかなり制限され、典型的なコールセンターの要求には合わないことが分かった。例えば、（ワークステーション１２６−１２７のような）各エージェントに利用可能なワークステーションに対して通話についての情報を提供することが好ましい。しかしながら、スイッチはデータをサーチし、処理し、これらのワークステーションにルーティングすることができない。結果として、音声とデジタルデータの組み合わせを所要の場所にルーティングするために、コンピュータ−テレフォニ統合（ＣＴＩ）と呼ばれる新しい技術が必要とされる。
【００１８】
ＣＴＩを実現する方法として、コールセンター１００はＣＴＩサーバ１３２に接続されたルーティングサブシステム１３０をさらに含んでおり、このＣＴＩサーバ１３２は次にＣＴＩリンク１３４を通してスイッチ１０８に接続されている。スイッチ１０８とＣＴＩサーバ１３２との間の通信は技術的に知られているＸ．２５プロトコルに一般的にしたがう。ＣＴＩサーバ１３２はルーティングサブシステム１３０とスイッチ１０８との間のインターフェイスを提供する。スイッチ１０８は、通話を受信した時にＣＴＩサーバ１３２に通知する。ＣＴＩサーバ１３２は情報をルーティングサブシステム１３０に送り、このルーティングサブシステム１３０は、予め定められた基準にしたがって、その通話に答えるのに最も適任なエージェントを選択する。その後ＣＴＩサーバ１３２はスイッチ１０８に通知して、その通話を選択されたエージェントの電話機（すなわち、ＤＮ）に向けさせる一方、ルーティングサブシステム１３０は、電話をかけてきた人に関するデータを選択されたエージェントのワークステーションに向ける。
【００１９】
ルーティングサブシステムとＣＴＩサーバの機能はすべて単一のコンピュータプラットフォーム上で実行することができ、あるいは示されているように分散させることができることは当業者に明らかになるであろう。示されている分散はソフトウェアおよびハードウェアモジュールの数および接続性に対して制限をするものではない。
【００２０】
本発明の１つの実施形態では、ルーティングサブシステム１３０には、スタットサーバ１４０、ルーティングサーバ１４２、およびデータベース１４４が含まれている。これらはデータ通信ネットワーク１５０を使用して相互に通信し、このデータ通信ネットワーク１５０は多くのローカルエリアネットワーク（ＬＡＮ）システムの任意のものであってもよい。スタットサーバ１４０はすべての通話に関係する履歴データ、スイッチのアクティビィティ、コールセンター１００のすべてのエージェントの情報やアクティビィティを集めて記憶する。データベース１４４は、カスタマ、エージェント、電話番号、およびコールセンター１００のさまざまな観点についての情報を含んでいる。ルーティングサーバ１４２はスタットサーバ１４０およびデータベース１４４のデータを使用して通話を取扱うのに適切なエージェントを選択する。選択後、ルーティングサーバ１４２はコマンドをＣＴＩサーバ１３２に送り、次にＣＴＩサーバ１３２はスイッチ１０８に対して到来通話を選択されたエージェントにルーティングするように命令する。
【００２１】
他のＣＴＩ関連アプリケーション（すなわち、ソフトウェアモジュール）があってもよく、これらはデータベース１４４とスタットサーバ１４０のリソースを使用して、他のサービスまたは情報をコールセンター中のエージェントに提供する。図１では、２つのアプリケーション（１５２および１５３）が示されている。アプリケーションの例は、ジェネシス・テレコミュニケーション・ラボラトリにより販売されている“エージェントビュー”および“コールセンタービュー”である。これらのアプリケーションはデータ通信ネットワーク１５０に接続されている。
【００２２】
コールセンターでは、エージェントが２台以上の電話機を管理することが普通である。エージェントにより使用される装置は、この出願中で“エージェント場所”と呼ばれる、（デスクのような）便利な場所に通常設置される。図１は２つの例示的なエージェント場所１６１および１６２を示している。エージェント場所１６１にはワークステーション１２６と２台の電話機１２０および１２１が含まれている。同様に、エージェント場所１６２にはワークステーション１２７と２台の電話機１２６および１２７が含まれている。エージェントがエージェント場所を占有しているとき、エージェントはそこにある電話機あるいはワークステーションの何れかを使用してログオンする。エージェントがエージェント場所を離れる前に、エージェントは電話機あるいはワークステーションを使用してログアウトする。結果として、コールセンター１００は各エージェントの現在の位置を追跡することができる。
【００２３】
スタットサーバ１４０は、１組のアプリケーションプログラミングインターフェイス（“ＡＰＩ”）コマンドを通して、ＣＴＩサーバ１３２、ルーティングサーバ１４２およびアプリケーション１５２−１５３と通信する。（ＣＴＩサーバ１３２とともに動作する）スタットサーバ１４０はスイッチ１０８のアクティビィティを監視して記憶することができる。スタットサーバ１４０はさまざまなエージェントのアクティビィティおよびエージェント場所も監視して記憶する。ルーティングサーバ１４２およびアプリケーション１５２−１５３による、対象とするオブジェクト（例えば、エージェント）のステータスに関する質問に応答して、スタットサーバ１４０は報告をルーティングサーバ１４２に提供する。１つのスタットサーバを使用して（１つ以上のコールセンターに位置しているかもしれない）いくつかのスイッチを管理する実施形態では、スタットサーバ１４０はすべてのスイッチのアクティビィティ、これらのスイッチにより取扱われるすべてのエージェントおよびすべてのエージェント場所を監視して記憶する。本発明のスタットサーバを使用するかもしれない複数のコールセンターアーキテクチャーの詳細な説明は、１９９７年１月１４日に出願され、第０８／７８２，９８３号を有し、本願と同じ譲受人に譲渡された“複数のコールセンターを運用するシステムおよび方法”と題する留保中の特許出願に開示されている。この特許出願は参照によりここに組み込まれている。
【００２４】
ほとんどのコールセンターエンティティ（例えば、電話機およびエージェント）は同時に複数の状態をとれることが認められている。例えば、エージェントの電話機は同時にいくつかのアクティビィティを取扱うように設計されている。したがって、エージェントは同じ電話機を使用して１人のカスタマと話し、他の人（例えば、同僚）を待たせてもよく、また到来通話を待っていてもよい。従来技術のシステムでは、（いくつかある同時性の状態の中から）どの状態を報告すべきかが明確でないことから、スタットサーバが電話機の状態を他のＣＴＩアプリケーションに報告する場合には、このことは報告に関する問題を示す。
【００２５】
また、さらに最近インターネットおよび他のマルチメディアネットワークの出現により、通常の電話機の他に、テレビ会議、ＩＰＮＴ通話、ＩＰＮＴテレビ会議、ワークシェア会議ツール、ビデオメールなどのようなものに対して、ワークステーション（例えば１２６または１２７）自体が通信端末となったりする。１つ以上のこれらの新しいマルチメディアツールにおいてエージェントが従事することは、本質的に利用可能性とともに、異なる（付加的な）ステータスおよび状態にもなる。このような機能性はコールセンターのみならず、任意の種類のマルチメディアマルチネットワークタイプの通信環境において使用することができることは明らかである。
【００２６】
本発明は複数の状態を利用する方法およびシステムである。異なるＣＴＩアプリケーションが状態関連情報を異なって使用する必要があることが分かる。例えば、エージェントが電話で会話をしていたり、データ入力のためにワークステーションを使用している場合には、従来のルーティングルーチンはエージェントがビジーであると考える。しかしながら、高い優先順位の通話（例えば、緊急通話や貴重なカスタマからの通話）を取扱うアプリケーションは、エージェントがエージェント場所にログオンしている限り同じエージェントが利用可能であると考える。これは、緊急電話通話があった場合に、エージェントがワークステーションでの仕事を止めたり、通話を保留状態にすることができるからである。したがって、本発明によりアプリケーションがいくつかある状態のうちどれを知らせて欲しいかを規定することができる。
【００２７】
本発明の実施形態をこれから説明する。この実施形態では、コールセンター中のさまざまなエンティティがソフトウェアオブジェクトと関係している。以下のものはこれらのオブジェクトのいくつかの例である。
【００２８】
（ａ）キューとルーティングポイント：これらはスイッチ中のハードウェア回路であり、オブジェクトとして表されている。キューはハードウェア制御ＡＣＤメカニズムを実現する。制御ディレクトリ番号（“ＣＤＮ”）として呼ばれることがあるルーティングポイントは、（ルーティングルーチンのような）ソフトウェアアプリケーションにより制御することができる。
【００２９】
（ｂ）エージェントＤＮ：これらはスイッチのハードウェアポートであり、オブジェクトとして表されている。各ＤＮは１つ以上の特性と関係している。例えば、ＤＮの中には他のＤＮに直接アクセスすることができるものもあり；ＤＮの中にはキューと関係しているものもあり；ＤＮの中には送出通話に対して制限されるものもあり；ＤＮの中には前の通話の終了後に利用不可能な期間を持つものもある。特定の例では、ノーザン・テレコムにより製造されたスイッチの中には基本的に２種類のＤＮ、位置および内線を含むものがある。内線ＤＮは電話機により直接アクセスすることができ、送出通話を始めることができる。位置ＤＮは１つ以上のキューと関係している。位置ＤＮはこれらのキューを通してのみアクセスすることができ、送出通話を始めることができない。
【００３０】
（ｃ）他の特定のＤＮ：これらは、ボイスメールシステム、インターラクティブ音声応答ユニットなどのような特定のデバイスに接続されているＤＮである。これらのＤＮがオブジェクトとして表されている。
【００３１】
（ｄ）エージェント場所：これらは論理的なスペースであり、それぞれそのスペースと関係するアイテム（例えば、おそらく異なるスイッチやワークステーションに付けられた１つ以上のＤＮ）を含んでいる。物理的な構成では、これらの場所はデスクとすることができる。エージェントがある場所の１つのアイテムにログインすると、全体の場所に対して論理的にログインすることになる。各場所はオブジェクトとして表され、場所ＩＤと関係している。
【００３２】
（ｅ）エージェント：エージェントＩＤにより識別される人（オブジェクト）。エージェントは場所間をダイナミックに移動することができる。スタットサーバは、すべてのエージェントの位置をダイナミックに追跡する特別なルーチンを持っている。例えば、エージェントは第１の場所で午前９：００から１３：００（すなわち、午後１：００）まで働くことができ；（例えばランチのために）ログアウトし、そして１４：００に第２の場所でログインする。エージェント位置追跡ルーチンはその情報を維持するので、ルーティングサーバ（および他のアプリケーション）には、そのエージェントに到達するのにはどのＤＮをダイヤルするのかが分かる。また各エージェントは“本拠地”を持っていてもよく、これはエージェントをダイナミックに追跡できない場合のデフォルト値である。
【００３３】
（ｆ）グループ：任意の組み合わせの多数のエージェント。グループオブジェクトはグループＩＤにより識別される。少なくとも２つのタイプのグループがある。（ここではＳＯｂｊｅｃｔＧｒｏｕｐＡｇｅｎｔｓとして識別される）第１のタイプにはエージェントＩＤのリストが含まれている。このケースでは、スタットサーバはすべてのエージェントの移動を追跡し、含まれているエージェントに対する統計のみを集める。例は特定のスキルを有するグループである。（ここではＳＯｂｊｅｃｔＧｒｏｕｐＰｌａｃｅｓとして識別される）第２のタイプにはエージェント場所（場所ＩＤ）のリストが含まれている。このリスト中の場所の例は、トレーニングルーム、メインオフィス、第２フロアーなどである。このケースでは、これらの場所でだれが働いているのかは重大でないことから、スタットサーバはこのリストに含まれている場所に関係するイベントを追跡する。
【００３４】
さらに他の実施形態では、ルータ１４２は到来通話において、発呼者とエージェントの両者がテレビ会議を利用可能にしていることから、単なる通常のアナログ電話通話（ＰＳＴＮ通話）ではなくテレビ会議（通信のベストモード）を確立することができる、あるいは確立を申し出ることができることを決定することができ、そして先のテレビ会議の利用可能性は可能性ある状態をチェックすることにより見出すことができる。このような機能性はコールセンターのみならず、任意の種類のマルチメディアマルチネットワークタイプの通信環境において使用することができることは明らかである。
【００３５】
図２を使用して先（第１の実施形態）に説明したオブジェクトを例示する。図２は、１つ以上のコールセンターの２つの物理的なスイッチをシミュレートしている２つのスイッチオブジェクト２１２および２１３を示している。スイッチオブジェクト２１２は以下のリソースを含んでいる：ＣＤＮオブジェクト２１４および２１５、キューＤＮオブジェクト２１６、およびＤＮオブジェクト２１７−２１９。同様に、スイッチオブジェクト２１３は以下のリソースを含んでいる：ＣＤＮオブジェクト２２１、キューＤＮオブジェクト２２２、およびＤＮオブジェクト２２３−２２４。これらのオブジェクトは物理的なスイッチ中の対応するＣＤＮ、キュー、およびエージェントＤＮを表している。
【００３６】
エージェントＤＮオブジェクト２１７−２１９および２２３−２２４はエージェント場所オブジェクトにも含まれている。この例では、エージェント場所オブジェクト２２６にはＤＮオブジェクト２１７および２１８が含まれ、エージェント場所オブジェクト２２７にはＤＮオブジェクト２１９および２２３が含まれ、エージェント場所オブジェクト２２８にはＤＮオブジェクト２２４が含まれている。２つの異なるスイッチからのＤＮを同じエージェント場所に関係させることができることに留意すべきである。
【００３７】
エージェント場所オブジェクトの中には、互いにグループ化して場所グループオブジェクトを形成できるものもある。図２では、１つの場所グループオブジェクト２３２のみが示されている。
【００３８】
図２は、オブジェクト２３０および２３１のような複数のエージェントオブジェクトも示している。この例では、エージェントオブジェクト２３０は、図２において破線２３５として示されている、先に言及したエージェント位置追跡ルーチンを使用してエージェント場所オブジェクト２２７にダイナミックにリンクされている。同様に、エージェントオブジェクト２３１は、（図２において破線２３６として示されている）先に説明したダイナミック追跡ルーチンを使用してエージェント場所オブジェクト２２８にダイナミックにリンクされている。エージェントオブジェクトの中には、エージェントグループオブジェクトにグループ化することができるものもある。図２では、１つのエージェントグループオブジェクト２３３のみが示されている。
【００３９】
スタットサーバ１４０は、そのクライアントに対する１組のＡＰＩを提供して、エージェント、エージェントグループ、エージェント場所、場所グループ、ルートポイント、キューなどと関係するオブジェクトのような、さまざまなオブジェクトに対する統計を得る。統計は、現在のオブジェクト状態表示（例えば、現在のエージェントステータス、グループ中の現在のアクティブ通話数など）や履歴状態表示とすることができる。履歴表示はある時間間隔に対する累積情報（例えば、通話の総数、総会話時間、平均会話時間など）である。したがって、クライアントは対象とする時間間隔を特定しなければならない。時間間隔の例は次の通りである。
【００４０】
（ａ）ＳＧｒｏｗｉｎｇＷｉｎｄｏｗ：開始時間が固定されている（例えば、午前９：００）一方で終了時間がスライドする（例えば、“今まで”）。例えば、クライアントは午前９：００から今までの間の総通話数を要求してもよい。
【００４１】
（ｂ）ＳＳｌｉｄｉｎｇＷｉｎｄｏｗ：時間間隔が固定されている一方、開始時間および終了時間がスライドする。例えば、過去１時間の平均通話長。
【００４２】
オブジェクトの説明に戻ると、各オブジェクトは１つ以上の状態を持っている。本発明の１つの実施形態では、エージェントＤＮオブジェクトはテーブル１に示されている状態を持っていてもよい。状態の数や性質は実施における詳細設計事項であるので、当業者により容易に変更させることができることに留意すべきである。
【００４３】
テーブル１
（１）ＮｏｔＭｏｎｉｔｏｒｅｄ：ＣＴＩサーバはこのエージェントＤＮのステータスを現在追跡していない。結果的に、スタットサーバはこのＤＮに対する統計情報を累積していない。
【００４４】
（２）Ｍｏｎｉｔｏｒｅｄ：エージェントＤＮがＣＴＩサーバにより監視されている。
【００４５】
（３）ＬｏｇｇｅｄＩｎ：これはエージェントがエージェントＤＮにログインしていることを示している。
【００４６】
（４）ＯｎＨｏｏｋ：これはエージェントＤＮがオンフック状態であり、通話を待っていることを示している。
【００４７】
（５）ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ：このエージェントＤＮがアクティブ通話を受けているときや、（ボイスメールメッセージを残す可能性のために）エージェントがいないときでさえ、これはほとんど常にアクティブである。ＷａｉｔＦｏｒＮｅｘｔＣａｌｌがアクティブでない唯一の状況は、予め定められたキーが押下されているときである（以下のＮｏｔＲｅａｄｙＦｏｒＮｅｘｔＣａｌｌ参照）。
【００４８】
（６）ＯｆｆＨｏｏｋ：これは電話の受話器がオフフック状態であることを示している。しかしながら、受話器がオフフック状態のときでさえ（例えば、ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ）、他の状態がアクティブの場合がある。
【００４９】
（７）ＣａｌｌＤｉａｌｉｎｇ：これはエージェントが通話のためにダイヤルしたが、その通話はまだ確立されていないことを示している。
【００５０】
（８）ＣａｌｌＲｉｎｇｉｎｇ：インバウンド通話が呼出を始める瞬間からエージェントによりその通話を取扱う直前までにエージェントＤＮに生じているアクションに関係している。
【００５１】
（９）ＮｏｔＲｅａｄｙＦｏｒＮｅｘｔＣａｌｌ：これは通話を受信するのを妨げるハードウェア状態に関係している。これは通常予め定められたキーを押下することにより起動される。
【００５２】
（１０）ＯｆｆｌｉｎｅＷｏｒｋＴｙｐｅ１：これはタイプ１として分類できる業務に対してエージェントがオフライン中であることを示している。
【００５３】
（１１）ＯｆｆｌｉｎｅＷｏｒｋＴｙｐｅ２：これはタイプ２として分類できる業務に対してエージェントがオフライン中であることを示している。
【００５４】
（１２）ＣａｌｌＯｎＨｏｌｄＵｎｋｎｏｗｎ：これは未知のタイプの通話が保留中であることを示している。
【００５５】
（１３）ＣａｌｌＯｎＨｏｌｄＣｏｎｓｕｌｔ：これは相談通話が保留中であることを示している。
【００５６】
（１４）ＣａｌｌＯｎＨｏｌｄＩｎｔｅｒｎａｌ：これは内部通話が保留中であることを示している。
【００５７】
（１５）ＣａｌｌＯｎＨｏｌｄＯｕｔｂｏｕｎｄ：これはアウトバウンド通話が保留中であることを示している。
【００５８】
（１６）ＣａｌｌＯｎＨｏｌｄＩｎｂｏｕｎｄ：これはインバウンド通話が保留中であることを示している。
【００５９】
（１７）ＣａｌｌＵｎｋｎｏｗｎ：これは通話が相談通話、内部通話、アウトバウンド通話、インバウンド通話、または保留中通話であるかをＣＴＩサーバが決定できないことを示している。
【００６０】
（１８）ＣａｌｌＣｏｎｓｕｌｔ：これは相談通話が進行中であることを示している。
【００６１】
（１９）ＣａｌｌＩｎｔｅｒｎａｌ：これは２つの内線（内部通話）間の通話が進行中（すなわち、プリフィックスが使用されていないとき）であることを示している。
【００６２】
（２０）ＣａｌｌＯｕｔｂｏｕｎｄ：これはアウトバウンド通話が進行中であることを示している。
【００６３】
（２１）ＣａｌｌＩｎｂｏｕｎｄ：これはインバウンド通話が進行中であることを示している。
【００６４】
（２２）ＬｏｇｇｅｄＯｕｔ：これはエージェントがエージェントＤＮからログアウトしたことを示している。
【００６５】
（２３）ＣａｌｌＤｉａｌｅｄ：これは電話がダイヤルされたときに成功したことを示している。
【００６６】
（２４）ＣａｌｌＡｂａｎｄｏｎｅｄＦｒｏｍＤｉａｌｉｎｇ：これはダイヤルプロセス中（かつ他の当事者が応答前）にエージェントが電話を切ったことを示している。
【００６７】
（２５）ＣａｌｌＡｎｓｗｅｒｅｄ：これは通話に応答があったことを示している。
【００６８】
（２６）ＣａｌｌＡｂａｎｄｏｎｅｄＦｒｏｍＲｉｎｇｉｎｇ：これは電話が鳴っている間に他の当事者が電話を切ったことを示している。
【００６９】
（２７）ＣａｌｌＡｂａｎｄｏｎｅｄＦｒｏｍＨｏｌｄｉｎｇ：これは通話が保留中に他の当事者が電話を切ったことを示している。
【００７０】
上記にリストアップされている状態は、エージェントＤＮにより“実行”することができるアクションに対応している。先に言及したように、エージェントＤＮは同時に複数のこれらの状態（ここでは“アクティブ状態”と呼ぶ）をとることができる。本発明の１つの実施形態では、本発明のスタットサーバは最高の優先順位を持つアクティブ状態に等しいエージェントＤＮステータスをそのクライアントに対して報告する。本発明では、優先順位はスタットサーバのクライアントにより設定される。これは、エージェントＤＮのステータスの情報を要求する際に、クライアントがステータス優先順位テーブル（“ＳＰＴ”）をパラメータの一部としてスタットサーバに送ることによりなされる。このテーブルにはテーブル１のリストに示されているのと同じ状態が含まれていることから、これらの状態はそのクライアントにより規定される優先順位で配置される。クライアントに報告する際に、スタットサーバは、受信したＳＰＴで規定されている最高の優先順位を持つエージェントＤＮのアクティブ状態に対応するステータスを報告する。報告されるステータスは、ＳＰＴ上の他の優先順位に対応するアクティブ状態とすることができることに留意すべきである。情報を要求しているクライアントがＳＰＴを提供しない場合には、デフォルトＳＰＴが使用される。さらに、クライアントは情報に対する別の要求時に異なるＳＰＴを提供してもよい。
【００７１】
本発明のこの観点の１つの利点は、最適であると思われる情報を各クライアントが得ることができることである。従来技術のシステムでは、情報を要求するすべてのクライアントに対して、スタットサーバはエージェントＤＮに対する１つのステータスのみを報告する。本発明では、スタットサーバは、クライアントにより送信されたＳＰＴパラメータに基づいて、同じエージェントＤＮに対する異なるステータスを異なるクライアントに対して報告することができる。各クライアントは欲しい情報を受信することから、コールセンターのリソースをさらによく利用することができる。
【００７２】
先に指摘したように、各エージェントは２台以上の電話機（すなわち、エージェントＤＮ）にアクセスしてもよい。このケースでは、クライアントは両エージェントＤＮにおけるアクションの優先順位を示すエージェントＳＰＴを規定してもよい。
【００７３】
例として、エージェントが２つのエージェントＤＮに対するアクセスを持ち、第１のＤＮが“ＯｆｆｌｉｎｅＷｏｒｋＴｙｐｅ１”の状態を持ち、第２のＤＮが“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”の状態を持つことを仮定する。クライアントに対して報告されるエージェントのステータスは、これがより高い優先順位を持つ場合には“ＯｆｆｌｉｎｅＷｏｒｋＴｙｐｅ１”である。他の例として、スタットサーバのクライアント（例えば、ルーティングサーバ１４２）は、エージェントと関係するすべてのエージェントＤＮが“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”状態を持っているときには、エージェントのステータスが“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”であると考えてもよい。これはエージェントが何れのコールセンター関連アクティビィティ（例えば、通話に応答するまたはワークステーションを使用する）もアクティブに実行していない場合のケースに相当し、結果として、すべてのエージェントＤＮが使用されておらず、通話を待っている。この優先順位の構成は“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”を最低の優先順位を持つアクションとしてエージェントＳＰＴに入れることにより達成される。しかしながら、特別な通話あるいは緊急な通話がある場合には、ルーティングサーバ１４２は、“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”ステータスを持つエージェントに関係する少なくとも１つのエージェントＤＮがあれば、エージェントのステータスを“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”であると考えたいかもしれない。これは、使用されていない少なくとも１台の電話機にエージェントがアクセスを持つケースに対応する。この優先順位設定は“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”を最高の優先順位としてエージェントＳＰＴに入れることにより達成される。
【００７４】
エージェントＳＰＴの１つの実施形態では、状態の優先順位は連続的かつコンマで区切られてリストアップされており、最低の優先順位が最初にリストアップされる。“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”に対して最低の優先順位を持つエージェントＳＰＴは、“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ，．．．．（他の状態）”となる。一方、“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”に対して非常に高い優先順位を持つエージェントＳＰＴは、“．．．．，ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ，Ｌｏｇｇｅｄ Ｏｕｔ”となる。このケースでは、最高の優先順位は“Ｌｏｇｇｅｄ Ｏｕｔ”であり、ちょうどその下の優先順位が“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”である。
【００７５】
エージェントはグループに構成することができる。グループステータスは、含まれているすべてのエージェントステータスに基づく。どれがエージェントＳＰＴおよびＤＮ  ＳＰＮに類似しているかは“グループＳＰＴ”により決定される。例として、“．．．．，ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”のグループＳＰＴは、少なくとも１つの“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”エージェントステータスがあれば、グループが“ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ”に入ることを意味している。
【００７６】
ルーティングポイントとキューは異なるＳＰＴに応答して異なるステータスを異なるクライアントに送ることもできる。例示的なルーティングポイント／キューの状態をテーブル２に示す。
【００７７】
テーブル２
（１）ＮｏｔＭｏｎｉｔｏｒｅｄ：ＣＴＩサーバはこのＤＮのステータスを現在追跡していない。結果的に、スタットサーバはこのＤＮに対する統計情報を累積していない。
【００７８】
（２）Ｍｏｎｉｔｏｒｅｄ：ルーティングポイント／キューがＣＴＩサーバにより監視されている。
【００７９】
（３）ＮｏｔＲｅａｄｙＦｏｒＮｅｘｔＣａｌｌ：ルーティングまたはキューＤＮに対して使用されるＰＢＸソースが容量に達した時にこの状態が生じる。この容量は非常に大きく、通常は達しないことに留意すべきである。
【００８０】
（４）ＣａｌｌＷａｉｔ：通話がルーティングポイント／キューで保留されている。
【００８１】
（５）ＣａｌｌＥｎｔｅｒｅｄ：これは新しい通話がルーティングポイントまたはキューにちょうど入ってきたことを示す“瞬間的な”アクションである。
【００８２】
（６）ＣａｌｌＤｉｓｔｒｉｂｕｔｅｄ：これは前にルーティングポイント／キューにあった通話がちょうどエージェントに送られたことを示している。
【００８３】
（７）ＣａｌｌＡｂａｎｄｏｎｅｄ：これは通話がルーティングポイントまたはキューにある間にカスタマがちょうど電話を切ったことを示している。
【００８４】
（８）ＷａｉｔＦｏｒＮｅｘｔＣａｌｌ：これは、ルーティングポイント／キューにさらに多くの通話を取扱う容量がまだあることを示している。
【００８５】
本発明の１つの実施形態では、クライアントがスタットサーバから統計を得ることができるようにする２つのメインコールがある。第１のコールは“ＳＧｅｔＳｔａｔ”である。このコールはスタットサーバに対して対象とする統計を一度だけ返すように要求する。第２のコールは“ＳＯｐｅｎＳｔａｔ”である。これはクライアントが連続ベースで統計を受信することに興味を持っていることを意味している。クライアントはさらに、スタットサーバがクライアントに通知し、統計を報告するために、さまざまな基準をセットアップすることができる。例えば、クライアントは、新しい値が最後に報告された値よりも予め定められたパーセンテージだけ大きいときにのみ通知が行われるように指定することができる。代わりに、クライアントは予め定められた時間間隔で通知が行われるように指定することができる。
【００８６】
ＳｇｅｔＳｔａｔコールとＳｏｐｅｎＳｔａｔコールのパラメータの１つはＳＰＴに関係している。本発明の１つの実施形態では、これらの各コールに対するパラメータには多数のオプションフィールドを持つデータ構造へのポインタが含まれている。エージェントＤＮ、エージェント、グループおよびルーティングポイント／キューに対するＳＰＴは、それぞれこれらのオプションフィールドの１つを占有する。したがって、アプリケーションは適切なＳＰＴを規定して、それらをデータ構造に組み込むことができる。このデータ構造を使用してＳｇｅｔＳｔａｔコールとＳｏｐｅｎＳｔａｔコールを呼び出す。
【００８７】
複数のスイッチが同じスタットサーバにより監視されている実施形態では、先に言及したコールには、対象とするスイッチをクライアントが示すことができるパラメータも含まれる。
【００８８】
またマルチメディアの観点は、ビジネスそしてプライベートな人々の両者における一般的な通信に対して、コールセンターのみにおける使用を越えて本発明を価値のあるものにする。これは、システムに対して多くの複雑さを加えることなくベストモードの通信交渉を可能、トランスペアレント、またはインターラクティブにすることができる。
【００８９】
本発明はその特定の例示的な実施形態を参照して説明してきた。本発明の広い精神および範囲を逸脱することなく、さまざまな修正および変更を本発明に対して行ってもよい。したがって明細書および図面は、制限的な意味ではなく例示的ものとして考えるべきであり、本発明は提供される請求の範囲によってのみ制限される。
【図面の簡単な説明】
【図１】図１は、本発明の複数のオブジェクト状態決定システムを実現することができるコールセンターのブロック図である。
【図２】図２は、本発明の複数のコールセンターシステムのスタットサーバにおいて使用されるオブジェクトを例示した図である。
【図１】
0003547397.tif 000002
【図２】
0003547397.tif 000003