(57)【特許請求の範囲】
【請求項１】
コールセンターの物理的な環境中のエンティティのステータスを報告する方法において、
（ａ）報告アプリケーションにより、複数の可能性あるオブジェクト状態を持つエンティティのアクティブ状態を監視し、
（ｂ）要求アプリケーションにより、可能性あるオブジェクト状態の優先順位付リストと、少なくとも１つのアクティブ状態に対する要求を提供し、
（ｃ）報告アプリケーションにより、アクティブ状態でありかつ要求アプリケーションにより提供されたリスト中で最高の優先順位を持つエンティティ状態を要求アプリケーションに提供するステップを含む方法。
【請求項２】
ステップ（ｂ）において、要求アプリケーションが１つよりも多い状態を要求し、ステップ（ｃ）において、報告アプリケーションが最高の優先順位を持つアクティブ状態と最高の優先順位以外の優先順位を持つアクティブ状態を提供する請求項１記載の方法。
【請求項３】
報告アプリケーションにより要求アプリケーションに提供される状態は優先順位の順序で最高の優先順位を持つ状態である請求項２記載の方法。
【請求項４】
コールセンターが複数のエージェントディレクトリ番号を使用する自動通話分配装置（ACD）を備え、エンティティがエージェントディレクトリ番号の１つである請求項１記載の方法。
【請求項５】
エンティティが１台以上の電話機に対するアクセスを持つエージェントであり、各電話機が複数のエージェントディレクトリ番号の１つによりアドレスされている請求項１記載の方法。
【請求項６】
エージェントが少なくとも第１および第２の電話機に対するアクセスを持ち、第１の電話機が第１のアクティブ状態であり、第２の電話機が第２のアクティブ状態であり、報告アプリケーションが要求アプリケーションに対して、エージェントステータスとして第１および第２のアクティブ状態の１つを提供する請求項５記載の方法。
【請求項７】
コールセンターが少なくとも１つの内部ルーティングポイントを有する自動通話分配装置を備え、エンティティが少なくとも１つのルーティングポイントである請求項１記載の方法。
【請求項８】
コールセンターが少なくとも１つのキューを有する自動通話分配装置を備え、エンティティが少なくとも１つのキューである請求項１記載の方法。
【請求項９】
エンティティが複数の可能性ある状態のうちの１つ以上のアクティブ状態にあってもよく、可能性ある状態はそれぞれコールセンター中のエンティティの動作に関係しており、コールセンターの物理的な環境中のエンティティのステータスを報告する方法において、
（ａ）エンティティのアクティブ状態を監視し、
（ｂ）要求アプリケーションにより、報告アプリケーションに対して、可能性あるエンティティ状態の第１の優先順位付リストを第１の時間に提供し、
（ｃ）報告アプリケーションにより、要求アプリケーションに対して、アクティブ状態でありかつ第１の優先順位リスト中で最高の優先順位を持つエンティティの第１のステータスを提供し、
（ｄ）報告アプリケーションにより、要求アプリケーションに対して、可能性あるエンティティ状態の第２の優先順位付リストを第２の時間に提供し、
（ｅ）報告アプリケーションにより、要求アプリケーションに対して、第２の優先順位リストとエンティティのアクティブ状態とに基づいてエンティティの第２のステータスを提供するステップを含み、
第２のステータスが第１のステータス以外のステータスである方法。
【請求項１０】
第１のステータスが第１の優先順位リスト中で最高の優先順位を持つアクティブ状態の１つに対応し、第２のステータスが第２の優先順位リスト中で最高の優先順位を持つアクティブ状態の１つに対応している請求項９記載の方法。
【請求項１１】
第１および第２のステータスが第１および第２のリスト中で予め定められた優先順位を持つアクティブ状態に対応している請求項９記載の方法。
【発明の詳細な説明】
発明の分野
この発明はコールセンターにおける電話通信に関し、特に、複数のオブジェクト状態をとることができる、コールセンター中のエンティティのステータスを決定する方法およびシステムに関する。
発明の背景
電話は、世界中で最も広く使用されている通信装置の１つである。当初電話は人々が物理的に離れているにも関わらず通信できる単なる便利なツールであった。最近では多くの会社が電話を使用して製品やサービスを売買し、消費者製品に対して技術的サポートを提供し、発呼者が自分自身の金融データ等にアクセスできるようにしている。したがって、電話は主要なビジネスおよび取引ツールとなってきた。
ビジネスや取引目的に電話をもっと有効に使用するために、コールセンターが開発されている。コールセンターでは、非常に多くのエージェントが発呼者との電話通信を取扱う。発呼者とエージェント間の通話のマッチングは一般的にソフトウェアによりなされる。ここでは簡単な例を使用してコールセンターを使用する多くの利点の内のいくつかを説明する。コールセンターに対して通話がなされると、一般的に電話キャリアにより通話回線の電話番号がコールセンターに入手可能である。この電話番号に基づいて、コールセンターのソフトウェアはデータベースサーバにアクセスして、その電話番号に割当てられている発呼者についての情報を得ることができる。ソフトウェアは予め定められた基準（例えば、言語スキル、発呼者が購入した製品についての知識等）に基づいてその通話を最高に取扱うことができるエージェントに通話をルーティングすることができる。ソフトウェアは、エージェントにより使用されるコンピュータスクリーンに直ちに関連情報を伝える。したがって、エージェントは通話を受ける前に発呼者についての価値のある情報を得ることができる。結果として、エージェントはさらに効果的に電話処理を取扱うことができる。
先の例から、有効な技術は電話スイッチング技術とコンピュータ情報処理技術の結合を必要とすることが分かるであろう。この結合された技術のために一般的に使用される用語は、コンピュータ−テレフォニ統合（CTI）である。
ルーティングの決定をする際に、ソフトウェアはすべてのエージェントの状態を知る必要がある。例えば、エージェントがビジー状態である（例えば、他の通話に答えている）場合には、通話はそのエージェントにルーティングされない。従来技術のCTIシステムでは、エージェントは１つの状態のみを持つ。ルーティングソフトウェア（とともにシステム中の他のソフトウェア）はこの状態に基づいて決定をする。しかしながらこのシステムには柔軟性がない。例えば、エージェントが何らかの仕事をしていて（例えば、緊急でない事項について同僚と会話していて）ビジーであっても、カスタマからの通話をとるために手が空いている他の適任なエージェントがいない場合には、エージェントはその通話を受け入れることができるかもしれない。したがって、コールセンターのリソースをよりよく利用することができる柔軟性あるシステムを得ることが望ましい。
発明の要約
本発明は要求ソフトウェアアプリケーションに対してコールセンター中のエンティティのステータスを柔軟性を持って報告する方法に関係している。エンティティは現在、（アクティブ状態と呼ばれる）複数の可能性ある状態のうちの１つ以上の状態に入っているかもしれない。第１の（報告）ソフトウェアアプリケーションは、（ｉ）エンティティのアクティブ状態、および（ii）第２の（要求）ソフトウェアアプリケーションにより提供される優先順位リストに基づいてエンティティのステータスを決定する。その後この報告ソフトウェアアプリケーションはステータスを要求ソフトウェアアプリケーションに報告する。
この発明の１つの利点は、要求ソフトウェアアプリケーションが状態の優先順位を決定することである。おそらく、各要求ソフトウェアアプリケーションには状態情報を利用するのに最良の方法が分かっている。したがって、要求ソフトウェアアプリケーションが優先順位を決定できるうようにすることは、同じステータスをすべての要求ソフトウェアアプリケーションに報告するよりも非常によいことである。
本発明の１つの実施形態では、エンティティには物理的なエンティティ（例えば、キューおよびルーティングポイント、エージェントディレクトリ番号、ならびにエージェント）と論理的なエンティティ（例えば、エージェント場所、およびグループ）が含まれている。各エンティティはソフトウェアオブジェクトと関係している。各オブジェクトは１つ以上の可能性のある状態と１つ以上のアクティブ状態を持つことができる。要求ソフトウェアアプリケーションは各エンティティオブジェクトに対してこれらの可能性ある状態の優先順位を設定し、それらを例えばステータス優先順位テーブルの形態で表す。このテーブルは報告ソフトウェアアプリケーションに送られる。報告ソフトウェアアプリケーションは、最高の優先順位をもつアクティブ状態としてオブジェクトのステータスを報告する。
本発明の他の実施形態では、要求ソフトウェアアプリケーションは報告ソフトウェアアプリケーションに対してステータスを１度だけ報告するように要求してもよい。代わりに、要求ソフトウェアアプリケーションは連続ベースで報告することを要求してもよい。報告ソフトウェアアプリケーションは報告の頻度を規定することができる。
本発明は単一の自動通話分配装置システムおよび複数の自動通話分配装置システムにおいて使用することができる。
本発明のこれらのおよび他の特徴は、添付した図面とともに読むと、以下の説明から明らかになるであろう。
【図面の簡単な説明】
図１は、本発明の複数のオブジェクト状態決定システムを実現することができるコールセンターのブロック図である。
図２は、本発明の複数のコールセンターシステムのスタットサーバにおいて使用されるオブジェクトを例示した図である。
発明の詳細な説明
本発明は新規なコールセンター方法およびシステムを含んでいる。以下の説明は、当業者が本発明を作りそして使用できるように提供されている。特定の適用の説明は例としてのみ提供されている。好ましい実施形態に対するさまざまな修正は当業者に容易に明らかになるであろう。また、ここに規定されている一般的な原理は本発明の精神および範囲を逸脱することなく他の実施形態および応用に適用してもよい。したがって、本発明は示されている実施形態に限定されることを意図しているものではなく、ここに開示されている原理および特徴と矛盾しない最も広い範囲にしたがうものである。
図１は本発明を実現するのに使用することができるコールセンター100のブロック図である。コールセンター100は公衆電話交換ネットワーク（PSTN）104に接続されている。コールセンター100には、PSTN104からの通話を受け入れるスイッチ108が含まれている。スイッチ108は、自動通話分配装置（ACD）／構内交換機（PBX）またはPSTNスイッチとすることができる。スイッチ108には、（PSTN104に接続するための）高帯域幅ポート110と（ポート112−116のような）複数の低帯域幅ポートが含まれている。これらの低帯域幅ポートのうちいくつかは音声ベースの装置に接続することができる。例えば、ポート112−115はそれぞれ電話機120−123に接続されている。エージェントはこれらの電話機を取扱うように割り当てられる。各低帯域幅ポートには１つ以上のディレクトリ番号（“DN"）が割り当てられている。
標準的なスイッチにより実行される機能はかなり制限され、典型的なコールセンターの要求には合わないことが分かった。例えば、（ワークステーション126−127のような）各エージェントに利用可能なワークステーションに対して通話についての情報を提供することが好ましい。しかしながら、スイッチはデータをサーチし、処理し、これらのワークステーションにルーティングすることができない。結果として、音声とデジタルデータの組み合わせを所要の場所にルーティングするために、コンピュータ−テレフォニ統合（CTI）と呼ばれる新しい技術が必要とされる。
CTIを実現する方法として、コールセンター100はCTIサーバ132に接続されたルーティングサブシステム130をさらに含んでおり、このCTIサーバ132は次にCTIリンク134を通してスイッチ108に接続されている。スイッチ108とCTIサーバ132との間の通信は一般的にX.25プロトコルにしたがう。CTIサーバ132はルーティングサブシステム130とスイッチ108との間のインターフェイスを提供する。スイッチ108は、通話を受信した時にCTIサーバ132に通知する。CTIサーバ132は情報をルーティングサブシステム130に送り、このルーティングサブシステム130は、予め定められた基準にしたがって、その通話に答えるのに最も適任なエージェントを選択する。その後CTIサーバ132はスイッチ108に通知して、その通話を選択されたエージェントの電話機（すなわち、DN）に向けさせる一方、ルーティングサブシステム130は、電話をかけてきた人に関するデータを選択されたエージェントのワークステーションに向ける。
本発明の１つの実施態様では、ルーティングサブシステム130には、スタットサーバ140、ルーティングサーバ142、およびデータベース144が含まれている。これらはデータ通信ネットワーク150を使用して相互に通信する。スタットサーバ140はすべての通話に関係する履歴データ、スイッチのアクティビティ、コールセンター100のすべてのエージェントの情報やアクティビティを集めて記憶する。データベース144は、カスタマ、エージェント、電話番号、およびコールセンター100のさまざまな観点の情報を含んでいる。ルーティングサーバ142はスタットサーバ140およびデータベース144のデータを使用して通話を取扱うのに適切なエージェントを選択する。選択後、ルーティングサーバ142はコマンドをCTIサーバ132に送り、次にCTIサーバ132はスイッチ108に対して入通話を選択されたエージェントにルーティングするように命令する。
他のCTI関連アプリケーション（すなわち、ソフトウェアモジュール）があってもよく、これらはデータベース144とスタットサーバ140のリソースを使用して、他のサービスまたは情報をコールセンター中のエージェントに提供する。図１では、２つのアプリケーション（152および153）が示されている。アプリケーションの例は、ジェネシス・テレコミュニケーション・ラボラトリにより販売されている“エージェントビュー”および“コールセンタービュー”である。これらのアプリケーションはデータ通信ネットワーク150に接続されている。
コールセンターでは、エージェントが２台以上の電話機を管理することが普通である。エージェントにより使用される装置は、この出願中で“エージェント場所”と呼ばれる、（デスクのような）便利な場所に通常設置される。図１は２つの例示的なエージェント場所161および162を示している。エージェント場所161にはワークステーション126と２台の電話機120および121が含まれている。同様に、エージェント場所162にはワークステーション127と２台の電話機122および123が含まれている。エージェントがエージェント場所を占有しているとき、エージェントはそこにある電話機あるいはワークステーションのいづれかを使用してログオンする。エージェントがエージェント場所を離れる前に、エージェントは電話機あるいはワークステーションを使用してログアウトする。結果として、コールセンター100は各エージェントの現在の位置を追跡することができる。
スタットサーバ140は、１組アプリケーションプログラミングインターフェイス（“API"）コマンドを通して、CTIサーバ132、ルーティングサーバ142およびアプリケーション152−153と通信する。（CTIサーバ132とともに動作する）スタットサーバ140はスイッチ108のアクティビィティを監視して記憶することができる。スタットサーバ140はさまざまなエージェントのアクティビティおよびエージェント場所も監視して記憶する。ルーティングサーバ142およびアプリケーション152−153による、対象とするオブジェクト（例えば、エージェント）のステータスに関する質問に応答して、スタットサーバ140は報告をルーティングサーバ142に提供する。１つのスタットサーバを使用して（１つ以上のコールセンターに位置しているかもしれない）いくつかのスイッチを管理する実施形態では、スタットサーバ140はすべてのスイッチのアクティビィティ、これらのスイッチにより取扱われるすべてのエージェントおよびすべてのエージェント場所を監視して記憶する。本発明のスタットサーバを使用するかもしれない複数のコールセンターアーキテクチャーの詳細な説明は、1997年１月14日に出願され、本願と同じ譲受人に譲渡された“複数のコールセンターを運用するシステムおよび方法”と題する留保中の特許出願第08/782,983号に開示されている。この特許出願は参照のためにここに組み込まれている。
ほとんどのコールセンターエンティティ（例えば、電話機およびエージェント）は同時に複数の状態をとれることが認められている。例えば、エージェントの電話機は同時にいくつかのアクティビィティを取扱うように設計されている。したがって、エージェントは同じ電話機を使用して１人のカスタマと話し、他の人（例えば、同僚）を待たせてもよく、また入通話を待っていてもよい。従来技術のシステムでは、（いくつかある状態の中から）どの状態を報告すべきかが明確でないことから、スタットサーバが電話機の状態を他のCTIアプリケーションに報告するときには、このことは報告に関する問題となる。
本発明は複数の状態を利用する方法およびシステムである。異なるCTIアプリケーションが状態関連情報を異なって使用する必要があることが分かる。例えば、エージェントが電話で会話をしていたり、データ入力のためにワークステーションを使用している場合には、レギュラルーティングルーチンはエージェントがビジーであると考える。しかしながら、高い優先順位の通話（例えば、緊急通話や貴重なカスタマからの通話）を取扱うアプリケーションは、エージェントがエージェント場装置にログオフしている限り同じエージェントが利用可能であると考える。これは、緊急電話通話があった場合に、エージェントがワークステーションでの仕事を止めたり、通話を保留状態にすることができるからである。したがって、本発明によりアプリケーションがいくつかある状態のうちどれを知らせて欲しいかを規定することができる。
本発明の実施形態をこれから説明する。この実施形態では、コールセンター中のさまざまなエンティティがソフトウェアオブジェクトと関係している。以下のものはこれらのオブジェクトのいくつかの例である。
（ａ）キューとルーティングポイント：これらはスイッチ中のハードウェア回路であり、オブジェクトとして表されている。キューはハードウェア制御ACDメカニズムを実現する。制御ディレクトリ番号（“CDN"）として呼ばれることがあるルーティングポイントは、（ルーティングルーチンのような）ソフトウェアアプリケーションにより制御することができる。
（ｂ）エージェントDN:これらはスイッチのハードウェアポートであり、オブジェクトとして表されている。各DNは１つ以上の特性と関係している。例えば、DNの中には他のDNに直接アクセスすることができるものもあり;DNの中にはキューと関係しているものもあり;DNの中には出通話に制限されるものもあり;DNの中には前の通話の終了後に利用不可能な期間を持つものもある。特定の例では、ノーザン・テレコムにより製造されたスイッチの中には基本的に２種類のDN、位置および内線を含むものがある。内線DNは電話機により直接アクセスすることができ、出通話を始めることができる。位置DNは１つ以上のキューと関係している。位置DNはこれらのキューを通してのみアクセスすることができ、出通話を始めることができない。
（ｃ）他の特定のDN:これらは、ボイスメールシステム、相互対話型音声応答ユニットなどのような特定のデバイスに接続されているDNである。これらのDNがオブジェクトとして表されている。
（ｄ）エージェント場所：これらは論理的なスペースであり、それぞれそのスペースと関係するアイテム（例えば、おそらく異なるスイッチやワークステーションに付けられた１つ以上のDN）を含んでいる。物理的な構成では、これらの場所はデスクとすることができる。エージェントがある場所の１つのアイテムにログインすると、全体の場所に対して論理的にログインすることになる。各場所はオブジェクトとして表され、場所IDと関係している。
（ｅ）エージェント：エージェントIDにより識別される人（オブジェクト）。エージェントは場所間をダイナミックに移動することができる。スタットサーバは、すべてのエージェントの位置をダイナミックに追跡する特別なルーチンを持っている。例えば、エージェントは第１の場所で午前9:00から13:00（すなわち、午後1:00）まで働くことができ；（例えばランチのために）ログアウトし、14:00に第２の場所でログインする。エージェント位置追跡ルーチンはその情報を維持するので、ルーティングサーバ（および他のアプリケーション）には、そのエージェントに到達するのにはどのDNをダイヤルするのかが分かる。また各エージェントは“本拠地”を持っていてもよく、これはエージェントをダイナミックに追跡できない場合のデフォルト値である。
（ｆ）グループ：任意の組み合わせの多数のエージェント。グループオブジェクトはグループIDにより識別される。少なくとも２つのタイプのグループがある。（ここではSObjectGroupAgentsとして識別される）第１のタイプにはエージェントIDにリストが含まれている。このケースでは、スタットサーバはすべてのエージェントの移動を追跡し、含まれているエージェントに対する統計のみを集める。例は特定のスキルを有するグループである。（ここではSObjectGroupPlacesとして識別される）第２のタイプにはエージェント場所（場所ID）のリストが含まれている。このリスト中の場所の例は、トレーニングルーム、メインオフィス、第２フロアーなどである。このケースでは、これらの場所でだれが働いているのかは重大でないことから、スタットサーバはこのリストに含まれている場所に関係するイベントを追跡する。
図２を使用して先に説明したオブジェクトを例示する。図３は、１つ以上のコールセンターの２つの物理的なスイッチをシミュレートしている２つのスイッチオブジェクト212および213を示している。スイッチオブジェクト212は以下のリソースを含んでいる:CDNオブジェクト214および215、キューDNオブジェクト216、およびDNオブジェクト217−219。同様に、スイッチオブジェクト213は以下のリソースを含んでいる:CDNオブジェクト221、キューDNオブジェクト222、およびDNオブジェクト223−224。これらのオブジェクトは物理的なスイッチ中の対応するCDN、キュー、およびエージェントDNを表している。
エージェントDNオブジェクト217−218および223−224はエージェント場所オブジェクトにも含まれている。この例では、エージェント場所オブジェクト226はDNオブジェクト217および218が含まれ、エージェント場所オブジェクト227にはDNオブジェクト219および223が含まれ、エージェント場所オブジェクト228にはDNオブジェクト224が含まれている。２つの異なるスイッチからのDNを同じエージェント場所に関係させることができることに留意すべきである。
エージェント場所オブジェクトの中には、互いにグループ化して場所グループオブジェクトを形成できるものもある。図２では、１つの場所グループオブジェクト232のみが示されている。
図２は、オブジェクト230および231のような複数のエージェントオブジェクトも示している。この例では、エージェントオブジェクト230は、図２において破線235として示されている、先に言及したエージェント位置追跡ルーチンを使用してエージェント場所オブジェクト227にダイナミックにリンクされている。同様に、エージェントオブジェクト231は、（図２において破線236として示されている）先に言及したエージェント位置追跡ルーチンを使用してエージェント場所オブジェクト228にダイナミックにリンクされている。
エージェントオブジェクトの中には、エージェントグループオブジェクトにグループ化することができるものもある。図２では、１つのエージェントグループオブジェクト233のみが示されている。
スタットサーバ140は、そのクライアントに対する１組APIを提供して、エージェント、エージェントグループ、エージェント場所、場所グループ、ルートポイント、キューなどと関係するオブジェクトのような、さまざまなオブジェクトに対する統計を得る。統計は、現在のオブジェクト状態表示（例えば、現在のエージェントステータス、グループ中の現在のアクティブ通話数など）や履歴状態表示とすることができる。履歴表示はある時間間隔に対する累積情報（例えば、通話の総数、総会話時間、平均会話時間など）である。したがって、クライアントは対象とする時間間隔を特定しなければならない。時間間隔の例は次の通りである：
（ａ）SGrowingWindow:開始時間が固定されている（例えば、午前9:00）一方で終了時間がスライドする（例えば、“今まで”）。例えば、クライアントは午前9:00から今までの間の総通話数を要求してもよい。
（ｂ）SSlidingWindow:時間間隔が固定されている一方、開始時間および終了時間がスライドする。例えば、過去１時間の平均通話長。
オブジェクトの説明に戻ると、各オブジェクトは１つ以上の状態を持っている。本発明の１つの実施形態では、エージェントDNオブジェクトはテーブル１に示されている状態を持っていてもよい。状態の数や性質は実施における詳細設計事項であるので、当業者により容易に変更させることができることに留意すべきである。
テーブル１
（１）NotMonitored:CTIサーバはこのエージェントDNのステータスを現在追跡していない。結果的に、スタットサーバはこのDNに対する統計情報を累積していない。
（２）Monitored:エージェントDNがCTIサーバにより監視されている。
（３）LoggedIn:これはエージェントがエージェントDNにログインしていることを示している。
（４）OnHook:これはエージェントDNがオンフック状態であり、通話を待っていることを示している。
（５）WaitForNextCall:このエージェントDNがアクティブ通話を受けているときや、（ボイスメールメッセージを残す可能性のために）エージェントがいないときでさえ、これはほとんど常にアクティブである。
WaitForNextCallがアクティブでない唯一の状況は、予め定められたキーが押下されているときである（以下のNotReadyForNextCall参照）。
（６）OffHook:これは電話の受話器がオフフック状態であることを示している。しかしながら、受話器がオフフック状態のときでさえ（例えば、WaitForNextCall）、他の状態はアクティブの場合がある。
（７）CallDialing:これはエージェントが通話のためにダイヤルしたが、その通話はまだ確立されていないことを示している。
（８）CallRinging:入通話が呼出を始める瞬間からエージェントによりその通話を取扱う直前までにエージェントDNに生じているアクションに関係している。
（９）NotReadyForNextCall:これは通話を受信するのを妨げるハードウェア状態に関係している。これは通常予め定められたキーを押下することにより起動する。
（10）OfflineWorkType1:これはタイプ１として分類できる業務に対してエージェントがオフライン中であることを示している。
（11）OfflineWorkType2:これはタイプ２として分類できる業務に対してエージェントがオフライン中であることを示している。
（12）CallOnHoldUnknown:これは未知のタイプの通話が保留中であることを示している。
（13）CallOnHoldConsult:これは相談通話が保留中であることを示している。
（14）CallOnHoldInternal:これは内部通話が保留中であることを示している。
（15）CallOnHoldOutbound:これは出通話が保留中であることを示している。
（16）CallOnHoldInbound:これは入通話が保留中であることを示している。
（17）CallUnknown:これは通話が相談通話、内部通話、出通話、入通話、または保留中通話であるかをCTIサーバが決定できないことを示している。
（18）CallConsult:これは相談通話が進行中であることを示している。
（19）CallInternal:これは２つの内線（内部通話）間の通話が進行中（すなわち、プリフィックスが使用されていないとき）であることを示している。
（20）CallOutbound:これは出通話が進行中であることを示している。
（21）CallInbound:これは入通話が進行中であることを示している。
（22）LoggedOut:これはエージェントがエージェントDNからログアウトしたことを示している。
（23）CallDialed:これは電話がダイヤルされたときに成功したことを示している。
（24）CallAbandonedFromDialing:これはダイヤルプロセス中（かつ他の当事者が応答前）にエージェントが電話を切ったことを示している。
（25）CallAnswered:これは通話に応答があったことを示している。
（26）CallAbandonedFromRinging:これは電話が鳴っている間に他の当事者が電話を切ったことを示している。
（27）CallAbandonedFromHolding:これは通話が保留中に他の当事者が電話を切ったことを示している。
上記にリストアップされている状態は、エージェントDNにより“実行”することができるアクションに対応している。先に言及したように、エージェントDNは同時に複数のこれらの状態（ここでは“アクティブ状態”と呼ぶ）をとることができる。本発明の１つの実施形態では、本発明のスタットサーバは最高の優先順位を持つアクティブ状態に等しいエージェントDNステータスをそのクライアントに対して報告する。本発明では、優先順位はスタットサーバのクライアントにより設定される。これは、エージェントDNのステータスの情報を要求する際に、クライアントが可能性のある状態の優先順位付けリストとしてのステータス優先順位テーブル（“SPT"）をパラメータの一部としてスタットサーバに送ることによりなされる。このテーブルにはテーブル１のリストに示されているのと同じ状態が含まれているので、これらの状態はクライアントにより規定される優先順位で配置される。クライアントに報告する際に、スタットサーバは、受信したSPTで規定されている最高の優先順位を持つエージェントDNのアクティブ状態に対応するステータスを報告する。報告されるステータスは、SPT上の他の優先順位に対応するアクティブ状態とすることができることに留意すべきである。情報を要求しているクライアントがSPTを提供しない場合には、デフォルトSPTが使用される。さらに、クライアントは情報に対する別の要求時に異なるSPTを提供してもよい。
本発明のこの観点の１つの利点は、最適であると思われる情報を各クライアントが得ることができることである。従来技術のシステムでは、情報を要求するすべてのクライアントに対して、スタットサーバはエージェントDNに対する１つのステータスのみを報告する。本発明では、スタットサーバは、クライアントにより送信されたSPTパラメータに基づいて、同じエージェントDNに対する異なるステータスを異なるクライアントに対して報告することができる。各クライアントは欲しい情報を受信することから、コールセンターのリソースをさらによく使用することができる。
先に指摘したように、各エージェントは２台以上の電話機（すなわち、エージェントDN）にアクセスしてもよい。このケースでは、クライアントは両エージェントDNにおけるアクションの優先順位を示すエージェントSPTを規定してもよい。
例として、エージェントが２つのエージェントDNに対するアクセスを持ち、第１のDNが“OfflineWorkType1"の状態を持ち、第２のDNが“WaitForNextCall"の状態を持つことを仮定する。クライアントに対して報告されるエージェントのステータスは、これがより高い優先順位を持つ場合には“OfflineWorkType1"である。他の例として、スタットサーバのクライアント（例えば、ルーティングサーバ142）は、エージェントと関係するすべてのエージェントDNが“WaitForNextCall"状態を持っているときには、エージェントのステータスを“WaitForNextCall"であると考えてもよい。これはエージェントが任意のコールセンター関連アクティビィティ（例えば、通話に応答するまたはワークステーションを使用する）をアクティブに実行していない場合のケースに相当し、結果として、すべてのエージェントDNが使用されておらず、通話を待っている。この優先順位の構成は“WaitForNextCall"を最低の優先順位を持つアクションとしてエージェントSPTに入れることにより達成される。しかしながら、特別な通話あるいは緊急な通話がある場合には、ルーティングサーバ142は、“WaitForNextCall"ステータスを持つエージェントに関係する少なくとも１つのエージェントDNがあれば、エージェントのステータスを“WaitForNextCall"であると考えたいかもしれない。これは、使用されていない少なくとも１台の電話機にエージェントがアクセスを持つケースに対応する。この優先順位設定は“WaitForNextCall"を最高の優先順位としてエージェントSPTに入れることにより達成される。
エージェントSPTの１つの実施形態では、状態の優先順位は連続的かつコンマで区切られてリストアップされており、最低の優先順位が最初にリストアップされる。“WaitForNextCall"に対して最低の優先順位を持つエージェントSPTは、“WaitForNextCall,....（他の状態）”となる。一方、“WaitForNextCall"に対して非常に高い優先順位を持つエージェントSPTは、“....,WaitForNextCall,Logged Out"となる。このケースでは、最高の優先順位は“Logged Out"であり、ちょうどその下の優先順位が“WaitForNextCall"である。
エージェントはグループに構成することができる。グループステータスは、含まれているすべてのエージェントステータスに基づく。どれがエージェントSPTとDN  SPNに類似しているかは“グループSPT"により決定される。例として、“....,WaitForNextCall"のグループSPTは、少なくとも１つの“WaitForNextCall"エージェントステータスがあれば、グループが“WaitForNextCall"に入ることを意味している。
ルーティングポイントとキューは異なるSPTに応答して異なるステータスを異なるクライアントに送ることもできる。例示的なルーティングポイント／キューの状態をテーブル２に示す。
テーブル２
（１）NotMonitored:CTIサーバはこのDNのステータスを現在追跡していない。結果的に、スタットサーバはこのDNに対する統計情報を累積していない。
（２）Monitored:ルーティングポイント／キューがCTIサーバにより監視されている。
（３）NotReadyForNextCall:ルーティングまたはキューDNに対して使用されるPBXソースが容量に達した時にこの状態が生じる。この容量は非常に大きく、通常は達しないことに留意すべきである。
（４）CallWait:通話がルーティングポイント／キューで保留されている。
（５）CallEntered:これは新しい通話がルーティングポイントまたはキューにちょうど入ったきたことを示す“瞬間的な”アクションである。
（６）CallDistributed:これは前にルーティングポイント／キューにあった通話がちょうどエージェントに送られたことを示している。
（７）CallAbandoned:これは通話がルーティングポイントまたはキューにある間にカスタマがちょうど電話を切ったことを示している。
（８）WaitForNextCall:これは、ルーティングポイント／キューにさらに多くの通話を取扱う容量がまだあることを示している。
本発明の１つの実施形態では、クライアントがスタットサーバから統計を得ることができるようにする２つのメイン論理コールがある。第１のコールは“SGetStat"である。このコールはスタットサーバに対して対象とする統計を一度だけ返すように要求する。第２のコールは“SOpenStat"である。これはクライアントが連続ベースで統計を受信することに興味を持っていることを意味している。クライアントはさらに、スタットサーバがクライアントに通知し、統計を報告するために、さまざまな基準をセットアップすることができる。例えば、クライアントは、新しい値が最後に報告された値よりも予め定められたパーセンテージだけ大きいときにのみ通知が行われるように指定することができる。代わりに、クライアントは予め定められた時間間隔で通知が行われるように指定することができる。
SgetStatコールとSopenStatコールのパラメータの１つはSPTに関係している。本発明の１つの実施形態では、これらの各コールに対するパラメータには多数のオプションフィールドを持つデータ構造へのポインタが含まれている。エージェントDN、エージェント、グループおよびルーティングポイント／キューに対するSPTは、それぞれこれらのオプションフィールドの１つを占有する。したがって、アプリケーションは適切なSPTを規定して、それらをデータ構造に組み込むことができる。このデータ構造を使用してSgetStatコールとSopenStatコールを呼び出す。
複数のスイッチが同じスタットサーバにより監視されている実施形態では、先に言及したコールには、クライアントが対象とするスイッチを示すことができるパラメータも含まれる。
本発明はその特定の例示的な実施形態を参照して説明してきた。本発明の広い精神および範囲を逸脱することなく、さまざまな修正および変更を本発明に対して行ってもよい。したがって明細書および図面は、制限的な意味ではなく例示的ものとして考えるべきであり、本発明は提供される請求の範囲によってのみ制限される。
【図１】
0003547142.tif 000002
【図２】
0003547142.tif 000003