(57)【要約】【課題】  コンタクトセンターに関し、特にクライアント端末が異業種・異業社を含む複数のコンタクトセンターからの呼を扱う分散型のコンタクトセンターを提供する。【解決手段】  コンタクトセンターシステムは、複数のコンタクトセンターと、前記複数のコンタクトセンターと接続するクライアント端末と、で構成され、前記クライアント端末は、前記複数のコンタクトセンターに対応するアプリケーションとそれらの間の通信競合制御機能とをクライアント端末側にのみ具備し、それによって任意のクライアント端末が前記複数のコンタクトセンターに対応する呼を受付ける。【選択図】      図１
2005117620.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンタクトセンターと、
前記複数のコンタクトセンターと接続するクライアント端末と、で構成するコンタクトセンターシステムであって、
前記クライアント端末は、前記複数のコンタクトセンターに対応するアプリケーションとそれらの間の通信競合制御機能とをクライアント端末側にのみ具備し、それによって任意のクライアント端末が、前記複数のコンタクトセンターに対応する呼を受付けること、を特徴とするコンタクセンターシステム。
【請求項２】
さらに、前記複数のコンタクトセンターを管理制御する監視端末を有し、
前記監視端末は、全オペレータの稼働計画に基づいて、呼制御スケジュール情報を前記複数のコンタクトセンター毎に設定することで所望のサービスを実現する機能、を有することを特徴とする請求項１記載のコンタクセンターシステム。
【請求項３】
前記クライアント端末は、さらに前記複数のコンタクトセンター毎の待ち呼を管理して表示する機能と、
表示された待ち呼を任意に選択して所望のコンタクトセンターの待ち呼を受付ける機能、又は所定の条件にしたがう待ち呼を自動的に選択して受付ける機能と、を有することを特徴とする請求項１記載のコンタクトセンターシステム。
【請求項４】
前記通信競合制御手段は、１つのコンタクトセンターからの着信を受付けると、他のコンタクトセンターからの着信を不可とする機能、及び／又は他のコンタクトセンターにその着信不可を通知して着信を中止させ、再度着信呼の待ち合わせをさせる機能、を含むことを特徴とする請求項１記載のコンタクトセンターシステム。
【請求項５】
前記複数のコンタクトセンターは、そのいずれかに障害が発生すると、他のコンタクトセンターを迂回してクライアント端末に着信させる機能と、迂回による着信であることをそのクライアント端末に通知する機能と、を有し、
前記クライアント端末は、その通知により受付け不可となったコンタクトセンターの対応アプリケーションを起動させる、ことを特徴とする請求項１記載のコンタクトセンターシステム。
【請求項６】
さらに、前記複数のコンタクトセンターに共通のスペシャリスト端末と、
前記クライアント端末からのアラーム情報を管理するアラーム管理サーバと、を有し、
前記スペシャリスト端末は、前記アラーム管理サーバから取得した前記アラーム情報が指示するクライアント端末とコンタクトセンターとの間の通話に割り込み通話を行うこと、を特徴とする請求項１記載のコンタクトセンターシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンタクトセンターシステムに関し、特に異業種・異業社を含む複数のコンタクトセンターへの呼を制御する分散型コンタクトセンターシステムに関するものである。
【背景技術】
【０００２】
テレビショッピングやクレーム相談等の種々の業務に用いられる分散型又は在宅型コンタクトセンターは、顧客がアクセスするコンタクトセンターと、それに公衆網を通じて接続される複数のクライアント端末とによって構成される。以降では、ネットワーク上に配置される単数又は複数のコンタクトセンターとその監視端末を総称して「リモートサイト」と呼ぶ。
【０００３】
そこでは、顧客からリモートサイトへのアクセス呼が、リモートサイト内の交換機等により公衆網を介して自宅やサテライトオフィス等に勤務するオペレータのクライアント端末へ配信される。リモートサイトには、ＡＣＤ（Automatic Call Distribution）機能等を用いて、特定のクライアント端末に呼を集中させない仕組みや、クライアント端末が応答不可能な時に別の応答可能なクライアント端末を選択して呼を転送する仕組みが設けられている（特許文献１参照）。
【０００４】
リモートサイトは、また、分散するオペレータのログオン又はログオフの状態管理手段や、各々のオペレータの応対中，応対待ち，離席等の状態管理をリアルタイムで行う仕組みを有している（特許文献２参照）。このような技術は、いずれも一つの本部のコンタクトセンターにオペレータ用の複数のクライアント端末が従属するという、従来の分散型コンタクトセンターシステムの構成を前提にしている。
【０００５】
【特許文献１】特開平１１−３１７８１７号公報（特許第３１７９７５４号）
【特許文献２】特開２００２−７７４０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、コンタクトセンターには、電話が頻繁に掛かる繁忙な時間帯と、あまり電話の掛からない閑散な時間帯とが存在する。そのため、時間帯に応じてオペレータの人員配置を行っても本部への着信状況によって閑散な時間帯が発生し、その間もオペレータは時間と場所を拘束されるため、非効率的な作業を強いられるという問題があった。
【０００７】
前述したように、従来のリモートサイトは、複数のクライアント端末が電話網やインターネット網を介して１つの本部のコンタクトセンターに従属する構成を有していたため、リモートサイトは別のコンタクトセンターからの呼を受付けることができなかった。ところで、仮にクライアント端末が複数のコンタクトセンターと接続できるとすれば、クライアント端末における閑散時間帯の発生を低減させることができる。
【０００８】
しかしながら、この場合にも、クライアント端末にインストールされた複数のコンタクトセンターにそれぞれ対応するアプリケーションが互いに独立に動作して、複数のコンタクトセンターからの呼が同時着信する等の危険性があり、かえって顧客からのクレームが増えたり、コンタクトセンター運営会社のビジネスやオペレータの操作に支障が生じる等の問題が生じ得る。
【０００９】
他にも、従来技術によればリモートサイトとコンタクトセンターは１対1に対応するため、コンタクトセンターに異常が発生した場合にはコンタクトセンター業務そのものが機能停止するという問題もあった。
【００１０】
さらに、近年のコンタクトセンター業務では、法的な専門知識を有しており、クレーマ対応に秀でたスペシャリストの配置が要求されるようになってきている。例えば、食品業界においては狂牛病問題や鳥ウィルス問題等が発生しており、それに関するコンタクトセンターへの問い合わせやクレームは高度化している。そのため、取扱商品以外の、特に法律問題に関する、対応を要求されるケースが増加している。
【００１１】
しかしながら、中小規模のコンタクトセンターでは、スペシャリストによる助言等を必要とする呼だけのためにスペシャリストを常駐させることは経済的負担により困難であり、そのため顧客を十分満足させる対応がとれないという問題があった。
【００１２】
そこで本発明の目的は、上記問題点に鑑み、リモートサイトに複数のコンタクトセンターを設けて各々のコンタクトセンターにクライアント端末が接続できるように分散型コンタクトセンターシステムを構成し、各クライアント端末には複数のコンタクトセンター用のアプリケーションと、それらを統合的に制御する手段と、を備えた分散型コンタクトセンターシステムを提供することにある。
【００１３】
また、本発明の目的は、リモートサイトに複数のコンタクトセンターを設けて各々のコンタクトセンターにクライアント端末が接続できるように分散型コンタクトセンターシステムを構成し、そのリモートサイトには複数のコンタクトセンターの管理手段と、任意のコンタクトセンターが障害となった場合に別のコンタクトセンターへ迂回させる迂回手段と、を備えた分散型コンタクトセンターシステムを提供することにある。
【００１４】
さらに、本発明の目的は、複数のコンタクトセンターに共通のスペシャリストを配置することで、コンタクトセンター毎にスペシャリストを配置する経済的負担を大幅に軽減し、併せて法律家等のスペシャリストによる高度な対応も可能とした分散型コンタクトセンターシステムを提供することにある。
【課題を解決するための手段】
【００１５】
本発明によれば、複数のコンタクトセンターと、前記複数のコンタクトセンターと接続するクライアント端末と、で構成するコンタクトセンターシステムであって、前記クライアント端末は、前記複数のコンタクトセンターに対応するアプリケーションとそれらの間の通信競合制御機能とをクライアント端末側にのみ具備し、それによって任意のクライアント端末が、前記複数のコンタクトセンターに対応する呼を受付けるコンタクセンターシステムが提供される。
【００１６】
さらに、前記複数のコンタクトセンターを管理制御する監視端末を有し、前記監視端末は、全オペレータの稼働計画に基づいて、呼制御スケジュール情報を前記複数のコンタクトセンター毎に設定することで所望のサービスを実現する機能、を有する。前記クライアント端末は、さらに前記複数のコンタクトセンター毎の待ち呼を管理して表示する機能と、表示された待ち呼を任意に選択して所望のコンタクトセンターの待ち呼を受付ける機能、又は所定の条件にしたがう待ち呼を自動的に選択して受付ける機能と、を有する。
【００１７】
前記通信競合制御手段は、１つのコンタクトセンターからの着信を受付けると、他のコンタクトセンターからの着信を不可とする機能、及び／又は他のコンタクトセンターにその着信不可を通知して着信を中止させ、再度着信呼の待ち合わせをさせる機能、を含む。前記複数のコンタクトセンターは、そのいずれかに障害が発生すると、他のコンタクトセンターを迂回してクライアント端末に着信させる機能と、迂回による着信であることをそのクライアント端末に通知する機能と、を有し、前記クライアント端末は、その通知により受付け不可となったコンタクトセンターの対応アプリケーションを起動させる。
【００１８】
また、前記コンタクセンターシステムは、前記複数のコンタクトセンターに共通のスペシャリスト端末と、前記クライアント端末からのアラーム情報を管理するアラーム管理サーバと、を有しており、前記スペシャリスト端末は、前記アラーム管理サーバから取得した前記アラーム情報が指示するクライアント端末とコンタクトセンターとの間の通話に割り込み通話を行う。
【発明の効果】
【００１９】
本発明によれば、クライアント端末の機能を変更することのみで一人のオペレータが異業種・異業社を含む複数のコンタクトセンターの呼を担当することができる。そして、監視端末にオペレータ着信における優先制御機能を追加することにより複数のコンタクトセンター間のオペレータ配置を効率良く行うことができる。
【００２０】
また、オペレータは複数のコンタクトセンターの待ち呼状態表示から任意の待ち呼を選択して受付けるか、又はシステムにより自動的に選定された呼を受付けることで、コンタクトセンターの違いを意識せずにオペレータ操作を行うことができる。そして、オペレータの稼動スケジュールをオペレータ端末に登録し、複数のコンタクトセンターに自動ログインすることで、最適なオペレータ配置を行うことができる。
【００２１】
さらに、リモートサイト内の任意のコンタクトセンターが障害になった場合においても、他のコンタクトセンターに迂回できる冗長構成のシステム提供が可能であり、トラブルによるサービス停止を防止することができる。
【００２２】
さらにまた、各コンタクトセンターに共通のスペシャリストを配置することで、コンタクトセンター毎の経済的負担を大幅に軽減し、その一方ではスペシャリストによる高度な助言等も可能となり、顧客満足度の高いサービスを提供できる。本発明では、クライアント端末の機能を変更することのみで一人のオペレータが異業種・異業社を含む複数のコンタクトセンターの呼を担当する場合において、専門知識を持つスペシャリストがこれら複数のコンタクトセンターのクライアント端末からのアラームに対して、サイレントモニタ及び割込み通話で対応する事により、複数のコンタクトセンター間のスペシャリスト配置を効率良く行うことができる。
【発明を実施するための最良の形態】
【００２３】
図１は、本発明による分散型コンタクトセンターシステムのネットワーク構成の一例を図式的に示したものである。
図１において、顧客Ａ〜Ｃは、公衆電話網（ＰＳＴＮ）やインターネット等の公衆ＩＰ網（１）を介して、リモートサイト２内にある自己のコンタクトセンターＡ〜Ｃに問合せ等の電話をかける。ここでは、顧客ＡはＡ社のコンタクトセンターＡ（５）へ、顧客ＢはＢ社のコンタクトセンターＢ（６）へ、そして顧客ＣはＣ社のコンタクトセンターＣ（７）へそれぞれアクセスする。
【００２４】
クライアント端末４は、従来では１つの本部のコンタクトセンターにのみ従属して接続していたのに対して、本発明では私設網や公衆ＩＰ網（３）を介してリモートサイト内の複数のコンタクトセンター５〜７に接続する。これにより、クライアント端末４のオペレータは、複数のコンタクトセンター５〜７にそれぞれ対応した受付け業務を実施できる。なお、図中には１つのクライアント端末４のみを示しているが、実際には複数のクライアント端末４がそれぞれ複数のコンタクトセンター５〜７に接像される。
【００２５】
本発明のクライアント端末４は、複数のコンタクトセンター５〜７にそれぞれ対応したクライアントアプリケーションＡ〜Ｃに加えて、複数のクライアントアプリケーションＡ〜Ｃの各動作状態を監視・管理・制御する統合制御アプリケーションを有しており、クライアント端末４の側の判断によってクライアントアプリケーションＡ〜Ｃの競合制御を実行し、また特殊な受付けサービス等を実施している。
【００２６】
監視端末８は、リモートサイト２内の複数コンタクトセンター５〜７及びそれらと接続するクライアント端末４へ、私設網や公衆ＩＰ網（３）を介して制御指示を出すために、集中管理者が使用する端末である。
【００２７】
図２は、図１のリモートサイトの基本的なブロック構成例を示している。また、図３には、図２のリモートサイトと接続するクライアント端末の基本的なブロック構成例を示している。
図２において、リモートサイト２は、複数のコンタクトセンター５〜７及び監視端末８で構成される。ここでは、図１との対応関係を明確にするために３つのコンタクトセンターの場合を例示している。以下、主にコンタクトセンター５について説明するが、他のコンタクトセンター６及び７も同様である。
【００２８】
（１）コンタクトセンター
コンタクトセンター５は、コンタクトセンターサーバ５１とＩＰ−ＰＢＸ５２とで構成される。コンタクトセンターサーバ５１は、過去のお客様情報の統合データベース５１０を収用しているサーバであり、クライアント端末の要求に従い顧客情報を通知する。その顧客情報データベース５１０は、コンタクトセンター毎の顧客の情報を管理している。
【００２９】
ＩＰ−ＰＢＸ５２は、ＰＳＴＮまたは公衆ＩＰ網を経由して顧客の電話を受付けるコンタクトセンターの私設交換機（ＰＢＸ）システムであって、ＩＰパケットを解釈して音声とデータとを統合的に交換処理する。ＩＰ−ＰＢＸ５２は、種々のテーブル５２０〜５２４、呼制御処理部５２５、通信制御部５２９、及びテーブル設定部５２８により構成される。なお、本発明の新規な部分には図中に斜線を付してある。
【００３０】
先ず、各テーブルについて説明すると、コンタクトセンター判定テーブル５２０は、各コンタクトセンターにおいてゲートウェイ（ＧＷ）と他のコンタクトセンターとの迂回回線の対応関係を管理するテーブルである。オペレータ端末スケジュールテーブル５２１は、当該コンタクトセンターに所属するオペレータのスケジュールを管理しており、どの時間帯に、どのオペレータが、どのコンタクトセンターのサービスを実施しているかを管理するテーブルである。
【００３１】
オペレータグループ登録テーブル５２２は、オペレータの端末が属するＡＣＤグループを登録するテーブルである。ＩＰ−ＰＢＸは、呼が着信したＡＣＤグループに属するオペレータへ転送を行う。クライアント端末情報テーブル５２３は、オペレータ番号とダイヤル番号との対応表である。また、待呼テーブル５２４は、コンタクトセンターに着信してクライアント端末へ転送されるのを待っている呼数をカウントするテーブルである。
【００３２】
次に、上記テーブル以外の呼制御処理部５２５は、ＩＰ−ＰＢＸ５２における交換サービス及びスイッチング処理を実行する。その着信元分析部５２６は、コンタクトセンター判定テーブル５２０及びクライアント端末情報テーブル５２３に基づいて起動すべきオペレータを決定し、該当するアプリケーション種別をクライアント端末４の対応アプリケーション起動制御部４２０に送信する。
【００３３】
また、その着信競合制御部５２７は、呼制御処理部５２５からの要求に従ってクライアント端末４への通知を分析し、呼制御処理部５２５に対して１）着信呼が着信中のクライアント端末を開放、２）着信呼の再待ち合わせ処理の要求を行う。
【００３４】
テーブル設定処理部５２８は、監視端末８からオペレータの端末スケジュール入力を受け、オペレータ端末スケジュールテーブル５２１及びオペレータグループ登録テーブル５２２を設定する。そして、通信制御部５２９は、ＩＰ−ＰＢＸ５２におけるＩＰパケットの入出力等の通信制御を行う。
【００３５】
（２）監視端末
監視端末８は、リモートサイト内のコンタクトセンター５〜７及びクライアント端末４へ制御指示を出す集中管理者が使用する端末である。その全オペレータ端末スケジュールテーブル８０１は、リモートサイト２内の全てのオペレータ端末スケジュールを管理するテーブルである。
【００３６】
また、スケジュール決定制御部８０２は、集中管理者が監視端末から入力したコンタクトセンター情報、オペレータ情報、及びスケジュール情報を、前記の全オペレータ端末スケジュールテーブル８０１に設定する機能と、その設定した各情報をリモートサイト２内のＩＰ-ＰＢＸ５２に通知する機能とを有する。そして、監視端末通信制御部８０３は、ＩＰ-ＰＢＸ５２の通信制御部５２９及びクライアント端末４の通信制御部４１との通信処理を実行する。
【００３７】
（３）クライアント端末
図３に示すクライアント端末４は、複数のコンタクトセンター５〜７と私設網又はインターネット３を介して接続し、そしてコンタクトセンター５〜７のそれぞれに対応する複数のアプリケーション４３〜４４をもつ。
【００３８】
対応アプリケーション起動テーブル４２１は、各コンタクトセンター５〜７から受信する起動アプリケーション種別と、クライアント内で起動するアプリケーション４３〜４４を対応付けるテーブルである。また、対応アプリケーション起動制御部４２０は、コンタクトセンター５〜７の着信元分析部５２６より受信した起動アプリケーション種別をもとに、対応アプリケーション起動テーブル４２１を参照して、着信に対応する起動アプリケーション４３〜４４を決定する。
【００３９】
例えば、クライアントアプリケーション４３は、コンタクトセンターＡ（５）との間で利用される電話制御部Ａ（４３０）及びアプリケーションＡの本体４３２と、他のコンタクトセンター６〜７からの呼との競合制御を行う着信競合制御Ａ（４３１）とで構成される。他のクライアントアプリケーション４４も同様の構成を有する。
【００４０】
電話制御部Ａ（４３０）は、統合制御アプリケーション４５のアプリケーション制御処理部４５０からの要求に従って、コンタクトセンターＡ（５）との間で電話制御を行う。着信競合制御Ａ（４３１）は、コンタクトセンターＡ（５）のＩＰ−ＰＢＸ５２に対して着信競合通知を行う。
【００４１】
次に、統合制御アプリケーション４５は、コンタクトセンター対応のクライアントアプリケーション４３２〜４４２の統合制御を行う本発明の特徴的な部分である。そのアプリケーション制御処理部４５０は、各アプリケーション４３２〜４４２の状態変化を監視し、それを端末状態管理制御部４５２に通知する。また、次に説明するＳｉｇｎ−ｏｎスケジュール管理制御部４５４及び端末状態管理制御部４５２の指示に従ってアプリケーション４３２〜４４２の制御及び状態監視を行う。さらに、コンタクトセンター対応のアプリケーション４３２〜４４２を起動する制御を行う。
【００４２】
端末状態管理制御部４５２は、各端末の状態を管理する端末状態管理テーブル４５３を参照して、アプリケーション制御処理部４５０に対する制御イベントを決定する。また、Ｓｉｇｎ−ｏｎスケジュール管理制御部４５４は、アプリケーション制御処理部４５０、通信制御部４１、及び監視端末８の監視端末通信制御部８０３を経由して、オペレータ端末スケジュールを入手し、そのオペレータ端末スケジュールに従ってコンタクトセンター対応のアプリケーション４３２〜４４２の起動をアプリケーション制御処理部４５０に指示する。
【００４３】
コンタクトセンターアプリケーション対応テーブル４５５は、コンタクトセンターに対応するアプリケーション４３２〜４４２を管理する。そして、コンタクトセンター状態表示部４５１は、後述する図８に示すように、接続された複数のコンタクトセンター５〜７の「待呼数」及び「着席釦」をクライアント端末の画面に表示すると共に、オペレータが着席釦を押下すると「着席釦押下」をアプリケーション制御処理部４５０に通知する。
【００４４】
以降では、上述した図２及び３の説明をもとに、図１の分散型コンタクトセンターシステム構成を前提に、幾つかの実施例について説明する。
【００４５】
（Ａ）着信競合制御
（Ａ−１）複数アプリケーションの競合制御
先ず、顧客ＡがコンタクトセンターＡ（５）の電話番号をダイヤルしてコンタクトセンター５のＩＰ−ＰＢＸ５２に着信する。着信した呼は、ＩＰ−ＰＢＸ５２の呼制御処理部５２５で着信先のクライアント端末４が決定され、その通信制御部５２９を介して決定したクライアント端末４に転送される。
【００４６】
転送された呼は、クライアント端末４の通信制御部４１を経由して電話制御部Ａ４３０へ着信し、起動されたクライアントアプリケーションＡ（４３）のアプリケーションＡ（４３２）が着信状態に設定される。各クライアントアプリケーション４３〜４４の動作状況を監視している統合制御アプリケーション４５のアプリケーション制御処理部４５０は、アプリケーションＡ（４３２）への着信を検出して、端末状態管理制御部４５２に検出状態を「着信」として通知する。
【００４７】
端末状態管理制御部４５２は、通知された検出状態により端末状態管理テーブル４５３を参照し、アプリケーション４３２〜４４２に対する監視状態、及びアプリケーション４３２〜４４２に対する制御イベントを決定する。この場合、検出状態が「着信」であるため、制御イベントはアプリケーション４３２への「画面へのポップアップイベント」と決定し、監視状態はアプリケーション４３２の「受付け終了（切断釦押下表示）」とその他のアプリケーションＢ〜Ｃに対する「監視停止」とを決定する。
【００４８】
次に、端末状態管理制御部４５２は、決定した監視状態及び制御イベントをアプリケーション制御処理部４５０に返信する。アプリケーション制御処理部４５０は、返信された制御イベントによりアプリケーションＡ（４３２）に対して「画面へのポップアップイベント」を送出し、クライアントアプリケーションＡ（４３）を活性化することでオペレータが受付けを開始できるようにする。
【００４９】
アプリケーション制御処理部４５０は、さらにアプリケーション４３２が「受付け終了」状態になるのを監視すると同時に、その他のアプリケーションＢ〜Ｃの状態監視を停止して「着信」を検出しない様にする。その後、クライアント端末４のオペレータが着信呼に対する受付けを終了し、「切断釦」を押下すると、アプリケーション４３２は切断釦押下状態に遷移する。
【００５０】
アプリケーション制御処理部４５０は、その「切断釦」の押下を検出して端末状態管理制御部４５２に検出状態を「受付け終了」として通知する。端末状態管理制御部４５２は、通知された検出状態により端末状態管理テーブル４５３を参照してアプリケーション４３２に対するイベントを「着席イベント」と決定すると共に、全アプリケーションＡ〜Ｃに対する監視状態を「着信」と決定する。
【００５１】
そして、端末状態管理制御部４５２は、決定した監視状態及び制御イベントをアプリケーション制御処理部４５０に返信する。アプリケーション制御処理部４５０は、返信された制御イベントによりアプリケーションＡ（４３２）へ「着席イベント」を送出すると共に、全アプリケーションＡ〜Ｃが「着信」状態になるのを監視し、いずれかのアプリケーションＡ〜Ｃから着信を待つ。
【００５２】
上記のように、「着信」のあったアプリケーションのみをその「受付け終了」まで動作させ、その他のアプリケーションを動作させないようにすることで、複数のクライアントアプリケーション４３〜４４の競合制御（４３１〜４４１）を実施する。
【００５３】
（Ａ−２）不要な着信処理の発生防止
以下では、前述したその他のアプリケーションＢ〜Ｃの状態監視を停止して「着信」を検出しないようにする一実施例と併せて、不要な着信処理の発生を防止する一実施例についても説明する。端末状態管理制御部４５２が、検出状態「着信」の通知によってアプリケーションＡ（４３２）〜Ｃ（４４２）に対する監視状態及び制御イベントを決定する際に、その他のアプリケーションＢ及びＣに対する制御イベントを「離席イベント」、そして監視状態を「監視停止」と決定する。
【００５４】
次に、端末状態管理制御部４５２は、決定した監視状態及び制御イベントをアプリケーション制御処理部４５０に返信する。アプリケーション制御処理部４５０は、その他のアプリケーションＢ及びＣへ「離席イベント」を送出する。さらに、アプリケーション制御処理部４５０は、返信された監視状態によりその他のアプリケーションＢ及びＣの状態監視を停止する。
【００５５】
その他のアプリケーションＢ及びＣは、「離席イベント」を受信するとアプリケーションの「離席釦」を押下する動作を擬似して離席の状態へ遷移し、「離席のイベント」を通信制御部４１通してそれぞれのコンタクトセンターＢ（６）及びＣ（７）の各ＩＰ−ＰＢＸ６２及び７２内の通信制御部６２９及び７２９へを送出する。ここでは、図２のコンタクトセンターＡ（５）のブロック引用符号“５ｘｘ”を、コンタクトセンターＢ（６）及びＣ（７）のブロック引用符号“６ｘｘ”及び “７ｘｘ”に変更して示している。
【００５６】
「離席イベント」は、ＩＰ−ＰＢＸ６２及び７２の通信制御部６２９及び７２９を介して呼制御処理部６２５及び７２５に通知され、呼制御処理部６２５及び７２５は、その「離席イベント」により送信元のクライアント端末４を「離席」の状態にする。呼制御処理部６２５及び７２５は、送信元のクライアント端末４が離席状態の間は、そのクライアント端末４への着信呼の転送を停止する。
【００５７】
これにより、コンタクトセンターＢ（６）及びＣ（７）からの不要な着呼による、クライアント端末４内での着信処理の発生が防止される。
【００５８】
（Ａ−３）コンタクトセンターの待ち合せ処理
ここでは、複数のコンタクトセンターＡ（５）及びＢ（６）からの呼が、１つのクライアント端末４にほぼ同時に着信した場合の一実施例について説明する。この場合、クライアント端末４では、例えば先に着信したコンタクトセンターの着信呼をのみを受付け、より後の着信呼を持つコンタクトセンターに対し「着信不可」になったことを通知する。その通知を受けたコンタクトセンターでは、一旦その呼を終了させて「待ち合せ」の状態に遷移させる。
【００５９】
一例として、クライアント端末４が、コンタクトセンターＡ（５）からの着信呼をクライアントアプリケーションＡ（４３２）が受付け中に、クライアントアプリケーションＣ（４４２）にも着信があった場合で説明する。アプリケーション４４２が着信状態になると、統合制御アプリケーション４５のアプリケーション制御処理部４５０は、アプリケーション４４２に着信があったこと検出し、端末状態管理制御部４５２に検出状態を「着信」として通知する。
【００６０】
端末状態管理制御部４５２は、通知された検出状態により端末状態管理テーブル４５３を参照し、アプリケーションＣ（４４２）に対するイベントを「着信競合イベント」と決定し、アプリケーション制御処理部４５０に返信する。アプリケーション制御処理部４５０は、返信された制御イベントによりアプリケーション４４２に対し「着信競合イベント」を送出し、それによってアプリケーション４４２は着信競合制御４４１を起動する。
【００６１】
着信競合制御４４１は、「着信競合イベント」を通信制御部４１通してコンタクトセンターＣ（７）のＩＰ−ＰＢＸ７２の通信制御部７２９へ送出する。ここでは、図２のコンタクトセンターＡ（５）のブロック引用符号“５ｘｘ”を、コンタクトセンターＣ（７）のブロック引用符号“７ｘｘ”に変更している。
【００６２】
「着信競合イベント」は、通信制御部７２９を介して呼制御処理部７２５に通知される。呼制御処理部７２５は、着信競合処理を実施すべく着信競合制御７２７を起動する。着信競合制御７２７は、コンタクトセンター側で一定時間応答を待った後に応答のない呼の着信を中止して再度待ち合せさせる「Automatic-Busy-out」等による着信を直ちに中止し、その呼の再度の待ち合わせの間は既存のサービス等を実行させる。
【００６３】
これより、先の着信呼の受付け終了を待ってからオペレータが後の着信呼に対応したり、又は「Automatic-Busy-out」等のサービス実行を待つことなく、直ちに不用な着信を中止して、再度の着信呼の待ち合わせを行わせることができる。
【００６４】
（Ｂ）最適オペレータ配置
集中管理者は、監視端末８からオペレータ毎の稼動スケジュール（コンタクトセンター番号、日付、オペレータ番号、勤務時間、オペレータグループ番号）を入力する。また、コンタクトセンター毎にオペレータ端末スケジュールを各コンタクトセンターに転送する時刻（スケジュール転送時間）を入力する。
【００６５】
図４には、全オペレータ端末スケジュールテーブル８０１の一例を示している。
図４に示すように、全オペレータ端末スケジュールテーブル８０１は、「コンタクトセンター番号」と「日付情報」からコンタクトセンターオペレータ端末スケジュールが検索され、それに「オペレータ番号」を加えることで、オペレータ端末スケジュールが検索できるように構成されている。オペレータ端末スケジュールは、オペレータ毎の「日付け情報」、「オペレータ情報」、「勤務時間情報」、「オペレータグループ番号」、等の情報を含む。
【００６６】
スケジュール決定制御部８０２は、入力情報である前述の稼動スケジュールと日付情報（１月１日を起算日とした日付（入力情報）の値）を検索キーとして、全オペレータ端末スケジュールテーブル８０１を検索し、監視端末通信制御部８０３を介して対応するコンタクトセンターに転送し、そのオペレータ端末スケジュールとしてコンタクトセンター情報、日付情報、オペレータ情報、勤務時間情報、オペレータグループ番号等を設定する。
【００６７】
また、スケジュール決定制御部８０２は、コンタクトセンター番号と入力情報である前述のスケジュール転送時刻を、その内部に置かれた送信起動スケジュールテーブルに設定する。そして、監視端末８のタスクマネージャに「起動時刻＝スケジュール転送時刻」及び「起動プログラム＝スケジュール決定制御部８０２」を設定する。
【００６８】
図５には、送信起動スケジュールテーブルの一例を示している。
図５に示すように、「コンタクトセンター番号」を検索キーとして各コンタクトセンターへの転送時間が取得される。
【００６９】
監視端末８のタスクマネージャより、前述で設定した起動時刻にスケジュール決定制御部８０２が起動される。スケジュール決定制御部８０２は、送信起動スケジュールテーブルの「スケジュール転送時間」と現在時刻とを比較し、それらが一致した「コンタクトセンター番号」を抽出する。抽出したコンタクトセンター番号と日付情報で全オペレータ端末スケジュールテーブル８０１を検索し、コンタクトセンター５〜７毎のオペレータ端末スケジュールを抽出する。
【００７０】
抽出されたコンタクトセンター毎のオペレータ端末スケジュールは、監視端末通信制御部８０３及び各コンタクトセンター５〜７の通信制御部５２９を介してＩＰ-ＰＢＸ５２のテーブル設定処理部５２８に送信される。テーブル設定処理部５２８は、受信したコンタクトセンター毎のオペレータ端末スケジュールを、オペレータグループ登録テーブル５３２及びオペレータ端末スケジュールテーブル５２１にそれぞれ設定する。
【００７１】
これにより、集中管理者のコントロールにより、オペレータ稼動計画に従った最適なオペレータ配置が可能となる。
【００７２】
（Ｃ）アプリケーションの自動起動及び自動ログイン
図３に示すように、ここではクライアント端末４のスタートアップにより、統合制御アプリケーション４５のアプリケーション制御処理部４５０が起動されるように設定されている状態とする。クライアント端末４の電源投入時に、スタートアップによってアプリケーション制御処理部４５が起動され、自オペレータ番号を入力情報として、クライアント端末４の通信制御部４１及び監視端末８の監視端末通信制御部８０３を経由して、そのスケジュール決定制御部８０２が起動される。
【００７３】
スケジュール決定制御部８０２は、オペレータ番号を入力として全オペレータ端末スケジュールテーブル（図５参照）から、オペレータ番号に対応したオペレータ端末スケジュールを抽出する。そして、抽出したオペレータ端末スケジュールを監視端末通信制御部８０３及びクライアント端末４の通信制御部４１を経由して、そのアプリケーション制御処理部４５０に通知する。
【００７４】
アプリケーション制御処理部４５０は、受信したオペレータ端末スケジュールを入力情報としてＳｉｇｎ-Ｏｎスケジュール管理制御部４５４を起動する。Ｓｉｇｎ-Ｏｎスケジュール管理制御部４５４は、その内部データのＳｉｇｎ-Ｏｎスケジュールデータの「Ｓｉｇｎ-Ｏｎ時間」及び「コンタクトセンター番号」に受信したオペレータ端末スケジュールの「勤務時間１開始」及び「コンタクトセンター番号」をそれぞれ設定する。次に、クライアント端末４のタスクマネージャに「起動プログラム＝Ｓｉｇｎ-Ｏｎスケジュール管理制御部４５４」と「起動時刻＝勤務時間１開始」を設定する。
【００７５】
図６には、Ｓｉｇｎ-Ｏｎスケジュールデータの一例を示している。
図６に示すように、「コンタクトセンター番号」を検索キーとして、「Ｓｉｇｎ-Ｏｎ時間（勤務開始時間）」が取得され、その時刻に各コンタクトセンター毎の対応プログラムが起動される。
【００７６】
クライアント端末４のタスクマネージャが、その設定した起動時刻にＳｉｇｎ-Ｏｎスケジュール管理制御部４５４を起動すると、Ｓｉｇｎ-Ｏｎスケジュール管理制御部４５４は、内部のＳｉｇｎ-Ｏｎスケジュールデータを現在時刻でサーチして一致する「コンタクトセンター番号」を抽出する。そして、抽出したコンタクトセンター番号を入力情報として、アプリケーション制御処理部４５０を起動する。
【００７７】
アプリケーション制御処理部４５０は、「コンタクトセンター番号」を検索キーとして、コンタクトセンターアプリケーション対応テーブル４５５より、入力情報のコンタクトセンター番号に対応するアプリケーション番号（ＡＰ−ＮＯ）及びそのアプリケーションを抽出して起動する。また、端末状態管理テーブル４５３のアプリケーション制御表内のログイン登録表を「ＡＰ−ＮＯ」で索引して「ログイン名」及び「パスワード」を抽出する。
【００７８】
図７には、端末状態管理テーブル４５３の一構成例を示している。
図７に示すように、端末状態管理テーブル４５３は、端末の動作状態を管理する端末状態管理表とその端末上で動作するアプリケーションの状態遷移等を制御するアプリケーション制御表とに分けられる。アプリケーション制御表にはログイン登録表が含まれ、そのログイン登録表を「ＡＰ−ＮＯ」で索引することで、登録済みの「ログイン名」及び「パスワード」が抽出される。
【００７９】
アプリケーション制御処理部４５０は、起動したアプリケーションのログオンプロンプトを監視してそのログオンプロンプトを検出すると、抽出した「ログイン名」及び「パスワード」を、ログオンプロンプトのテキストボックスに設定して実行させる。
【００８０】
これにより、オペレータ端末スケジュールに合ったコンタクトセンター対応アプリケーションが自動起動され且つ自動ログインが可能となる。
【００８１】
（Ｄ）コンタクトセンターの待呼の選択
先ず、本発明との比較のために従来システムにおける待呼の選択動作について簡単に説明しておく。一例として、コンタクトセンターＡ（５）に着信呼があると、コンタクトセンター５の呼制御処理部５２５が「待呼数」をカウントアップして、その待呼の数は待呼テーブル５２４に蓄えられる。
【００８２】
呼制御処理部５２５は、待呼テーブル５２４を定期的に監視して、待呼数に変化があると待呼ランプ又は待呼数のデイスプレイ表示通知等を編集し、ＩＰ−ＰＢＸ５２の通信制御部５２９を介してクライアント端末４の通信制御部４１へ通知する。この通知は、通信制御部４１及び電話制御部Ａ（４３１）を通してアプリケーションＡ（４３２）に通知され、通知された情報に従ってアプリケーションＡはそのアプリケーションの表示画面上に「待呼数」を表示する。
【００８３】
一方、本発明による待呼の選択動作においては、クライアント端末４の端末状態管理制御部４５２が、アプリケーション制御処理部４５０を介して全てのアプリケーション４３２〜４４２の待呼を定期的に監視し、アプリケーション毎の「待呼数」を端末状態管理テーブル４５３に蓄えると共に、その端末状態管理テーブル４５３の状態をアプリケーション制御処理部４５０を介してコンタクトセンター状態表示部４５１に通知し、コンタクトセンター状態表示画面にそれを表示させる。
【００８４】
図８は、コンタクトセンター状態表示画面の一例を示したものである。
図８に示すように、画面上には各コンタクトセンターＡ（５）〜Ｃ（７）のアプリケーション対応に「待呼数」と「着席釦」が表示され、さらにクライアント端末４に対する「クライアント着席釦」が表示されている。オペレータは、それぞれの「釦」をキーボードやマウス等により押下することで、各々のアプリケーションＡ（４３２）〜Ｃ（４４２）に対する要求指示を出す。
【００８５】
オペレータが、図８に示すコンタクトセンター状態表示画面からコンタクトセンターＡ（５）を選択してその「着席釦」を押下すると、コンタクトセンター状態表示部４５１は、アプリケーション制御処理部４５０介して端末状態管理制御部４５２にアプリケーションＡ（４３２）に対する「着席要求」を通知する。
【００８６】
端末状態管理制御部４５２は、この通知により端末状態管理テーブル４５３を参照し、アプリケーション４３２に対する制御イベント及び監視状態を決定する。この場合の検出状態は「着席要求」であるため、その制御イベントは「着席イベント」と決定し、同時にその監視状態を「着信」と決定する。その決定した制御イベント及び監視状態はアプリケーション制御処理部４５０に返信される。
【００８７】
アプリケーション制御処理部４５０は、返信された制御イベントによりアプリケーション４３２へ「着席イベント」を送出すると共に、アプリケーション４３２が「着信」状態になるのを監視する。その後、コンタクトセンター５からクライアントアプリケーション４３へ着信呼が転送されて来ると、アプリケーション４３２は着信状態となる。
【００８８】
アプリケーション制御処理部４５０は、アプリケーション４３２に着信があったことを検出し、端末状態管理制御部４５２に検出状態を「着信」として通知する。端末状態管理制御部４５２は、通知された検出状態により端末状態管理テーブル４５３を参照して、アプリケーション４３２に対する制御イベント及び監視状態を決定する。
【００８９】
この場合、検出状態が「着信」であるため、制御イベントはアプリケーション４３２への「画面へのポップアップイベント」を決定し、監視状態はアプリケーション４３２の「受付け終了」を決定する。次に、端末状態管理制御部４５２は、決定した制御イベント及び監視状態をアプリケーション制御処理部４５０に返信する。
【００９０】
アプリケーション制御処理部４５０は、返信された制御イベントによりアプリケーション４３２へ「画面へのポップアップイベント」を送出し、クライアントアプリケーションＡ（４３）を活性化することでオペレータが受付けを開始できる様にする。更に、アプリケーション制御処理部４５０は、返信された監視状態により、アプリケーション４３２が「受付け終了（切断釦押下）」状態になるのを監視する。
【００９１】
その後、オペレータが着信呼に対する受付けを終了し、「切断釦」を押下すると、アプリケーション４３２は切断釦を押下した状態となり、それをアプリケーション制御処理部４５０が検出する。その検出状態は「受付け終了」であるから、アプリケーション制御処理部４５０はコンタクトセンター状態表示部４５１に対してオペレータ端末の画面にコンタクトセンター状態表示画面（図８）をポップアップさせ、オペレータに次に受付けを行うコンタクトセンターを選択するように促す。
【００９２】
以上により、オペレータは、接続された複数のコンタクトセンター５〜７の「待呼」の状態をクライアント端末４の画面上で確認し、その中から所望のコンタクトセンターを選択することで、クライアント端末４の側の判断で各コンタクトセンターの着信呼に適宜応対することが可能となる。
【００９３】
（Ｅ）最大待呼を有するコンタクトセンターの自動選択
本発明において、コンタクトセンター状態表示画面（図８）が表示されている状態において、オペレータが「クライアント着席釦」を押下する。これにより、コンタクトセンター状態表示部４５１は、アプリケーション制御処理部４５０を介して端末状態管理制御部４５２に対してクライアント端末４に対する「システム着席要求」を通知する。
【００９４】
端末状態管理制御部４５２は、この通知により端末状態管理テーブル４５３の全てのアプリケーションＡ〜Ｃの「待呼数」を参照し、待呼数が最大のアプリケーションを抽出する。例えば、アプリケーションＡ（４３２）を抽出した場合には、「システム着席要求」をアプリケーション４３２の「着席要求」に変換する。以降は、上述と同様にアプリケーション４３２に対する制御イベント及び監視状態を決定して着信制御を実施する。
【００９５】
以上により、オペレータは、クライアント端末を着信可能な状態にすることで、複数のコンタクトセンターの中から待呼の最も多いコンタクトセンターとの接続を自動的に行うことが可能となる。
【００９６】
（Ｆ）コンタクトセンター障害時の迂回接続
図９は、顧客Ａがインターネット等の公衆ＩＰ網１を使って、コンクトセンターＡに問い合わせの電話をかける場合を示している。
図9において、顧客ＡがコンタクトセンターＡに電話をかけると、通常回線Ａを経由して通常時のゲートウェイ（ＧＷ−１）５３に接続し、ゲートウェイ５３を介してコンタクトセンターＡ（５）に着信する。
【００９７】
しかしながら、何らかの理由（本例では通常回線Ａの障害）によりコンタクトセンター５が着信不可の状態に陥っていた場合には、顧客Ａの通話は公衆ＩＰ網１におけるのＨ.４５０．２プロトコルの設定によって迂回回線Ａに転送される。その結果、顧客Ａの通話は、迂回回線Ａを経由して迂回時のゲートウェイ（ＧＷ−２）６４に接続し、ゲートウェイ６４を介してコンタクトセンターＢ（６）に着信する。
【００９８】
以降の説明では、図２のコンタクトセンターＡ（５）のブロック引用符号“５ｘｘ”をコンタクトセンターＢ（６）のブロック引用符号“６ｘｘ”に変更して示している。コンタクトセンター６では、着信を受けた呼制御処理部６２５の内の着信分析部６２６では、いずれのゲートウェイ（ＧＷ−２／ＧＷ−３）６４又は６３への着信かを判定する。そこでは、一方のゲートウェイ（ＧＷ−３）６３への着信は通常のコンタクトセンター６への着信と判断し、他方のゲートウェイ（ＧＷ−２）６４への着信はコンタクトセンターＡ（５）の着信が迂回してきたものと判断する。
【００９９】
着信元分析部６２６は、後者の場合にコンタクトセンター判定テーブル６２０を参照して、コンタクトセンター５のコンタクトセンター番号を抽出する。抽出したコンタクセンター番号は通信制御部６２９から監視端末８へ送出され、その監視端末通信制御部８０３を介してスケジュール決定制御部８０２に通知される。
【０１００】
スケジュール決定制御部８０２は、その「コンタクトセンター番号」を検索キーとして全オペレータ端末スケジュールテーブル８０１を検索し、稼動時間中の「オペレータ番号」を抽出する。スケジュール決定制御部８０２は、抽出したオペレータ番号を監視端末通信制御部８０３及びコンタクトセンター６の通信制御部６２９を経由して着信元分析部６２６に通知する。着信元分析部６２６は、そのオペレータ番号をもとにクライアント端末情報テーブル６２３を検索して、着信させるクライアント端末のダイヤル番号を抽出する。
【０１０１】
ダイヤル番号を抽出した着信元分析部６２６は、通信制御部６２９へ「クライアント接続依頼」を行う。それにより、通信制御部６２９は、抽出したダイヤル番号で呼接続要求を行う。クライアント端末４の通信制御部４１は、コンタクトセンターＢ（６）からの呼接続要求を受け、呼接続許可を返信してコンタクトセンター６とクライアント端末４との間の呼を確立させる。
【０１０２】
呼が確立すると、コンタクトセンター６の着信元分析部６２６は、起動アプリケーション種別を通信制御部６２４経由でクライアント端末４の対応アプリケーション起動制御部４２０へ送信する。対応アプリケーション起動制御部４２０は、起動すべきアプリケーション種別を対応アプリケーション起動テーブル４２１と照合して決定する。
【０１０３】
本例では、コンタクトセンターＡ（５）のアプリケーションＡ（４３２）が選択される。次に、対応アプリケーション起動制御部４２０は、通信制御部４１に決定したクライアントアプリケーション４３２に、着信呼を接続させるアプリケーション接続要求を行う。通信制御部４２０は、着信呼をクライアントアプリケーションＡ（４３）に接続してサービスを開始させる。
【０１０４】
このように、コンタクトセンターＡ（５）が着信不可の状態であっても、顧客Ａの着信呼はコンタクトセンターＢ（６）を迂回してクライアント端末４に接続され、顧客Ａは所望のサービスを受けることが可能となる。
【０１０５】
以上述べたように、クライアント端末側では、複数のコンタクトセンターとの間の業務を効率良く担務でき、クライアント端末における閑散時間帯の低減が図られる。また、複数のコンタクトセンターからの待ち呼を、クライアント端末側で任意に又は優先的に選択して受付けることも可能となる。
【０１０６】
例えば、複数のコンタクトセンターから同時に複数の呼が同一オペレータに着信した場合には、１つの呼だけを受付けてその他の呼は着信不可にしたり、着信不可となった呼は別のクライアント端末へ転送することも可能となる。また、クライアント端末側で各コンタクトセンターの輻輳状態を管理して、輻輳しているコンタクトセンターからの呼を優先的に処理することも可能となる。
【０１０７】
さらに、リモートサイト側では、サイト内の複数のコンタクトセンターを管理して、任意のコンタクトセンターが障害となった時には非常用の迂回装置を介して別のコンタクトセンターへ呼を迂回させることも可能となる。
【０１０８】
図１０は、本発明による分散型コンタクトセンターシステムの別のネットワーク構成例を図式的に示したものである。本例では、これまで述べた本発明によるネットワーク構成を前提に、ネットワーク内に共通のスペシャリストを配置して、複数のコンタクトセンターからの高度な問合せに適宜対応できるようにしている
【０１０９】
図１０は、先に説明した図１と同様の構成を有しているが、図中に二重線枠で示すアラーム監視サーバ９及びスペシャリスト端末１０が新たに設けられている点が異なる。また、図１１及び１２には、図１０のリモートサイト２及びクライアント端末４のそれぞれのブロック構成例を示している。
【０１１０】
図１１及び１２も基本的には先に説明した図２及び３と同様の構成を有しており、図中に斜線を付して示す図１１の通信制御部５１２と図１２のアラーム釦制御部４５６及び現クライアント情報テーブル４５７が新たに追加されている。図１２のアラーム管理サーバ９と図１３のスペシャリスト端末は、新規に設けられたものである。なお、図１〜３と同じ部分については同じ引用符号を付しており、それらについては更に説明しない。
【０１１１】
ここでは先ず、本例における分散型コンタクトセンターシステムの概略動作について説明しておく。
図１０において、コンタクトセンター５からクライアント端末４に顧客Ａからのアクセス呼が配信される（図中の１）。クライアント端末４のオペレータは、顧客Ａからの問合せに対して本人では対応できないことから「アラーム釦」を押下し、それによるアラーム情報がアラーム監視サーバ９に登録される（図中の２）。
【０１１２】
スペシャリスト端末１０は、アラーム監視サーバ９を定期的にスキャンして前記アラーム情報を検出する（図中の３）。検出されたアラーム情報とそれに関連する顧客情報がスペシャリスト端末１０に表示される。スペシャリストは、スペシャリスト端末１０を介して顧客Ａとクライアントの通話内容をサイレントモニタし、適宜「割り込み釦」を押下して顧客Ａとクライアントとの通話に割り込む（図中の４）。これにより、顧客Ａ、クライアント、そしてスペシャリストの三者通話の状態に移行し、スペシャリストは顧客Ａからの問合せに対して専門家として返答する。
【０１１３】
上記の動作を念頭に、以下では新たに追加された各部の動作について説明する。
図１１において、サーバ５１の通信制御部５２は、スペシャリスト端末１０が顧客情報テーブル５１０から顧客Ａの顧客情報を取得する際の通信制御を行う。取得した顧客情報はスペシャリスト端末１０に表示される。顧客情報には、顧客Ａの過去の問合せ履歴や顧客Ａがクレーマか否か等の種々の情報が含まれる。
【０１１４】
図１２において、クライアント端末４のアラーム釦制御部４５６は、オペレータが「アラーム釦」を押下した際に起動され、そのクライアントを特定する情報を現クライアント情報テーブル４５７から取得して、通信制御部４１経由でアラーム管理サーバ９の通信制御部９１に通知する。
【０１１５】
アラーム管理サーバ９は、クライアント端末４のアラーム釦制御部４５６からアラームを受信してアラーム状態を管理する。その通信制御部９１は、クライアント端末４及びスペシャリスト端末１０との通信を行う。アラーム状態テーブル制御部９２は、クライアント端末４からのアラーム情報及びスペシャリスト端末１０からの対応情報を受けて、それらをアラーム状態テーブル９３に設定する。アラーム状態テーブル９３は、全てのオペレータ対応のアラーム状態を管理する。
【０１１６】
図１３のスペシャリスト端末１０は、問合せ状況の表示、顧客とクライアント端末４との間の通話内容のサイレントモニタ、その通話に対する割り込み制御（三者通話）を行う。なお、スペシャリスト端末１０の基本的なブロック構成はクライアント端末４とほぼ同様である（図１２参照）。通信制御部１０１０は、アラーム管理サーバ９及びコンタクトセンター５〜７のＩＰ−ＰＢＸ５２との間の通信を行う。クライアントアプリケーションＡ（１０２０）は、コンタクトセンターＡ（５）との通信に利用される電話制御部Ａ（１０２１）とアプリケーションＡ（１０２２）から成る。
【０１１７】
電話制御部１０２１は、アプリケーション制御処理部１０４１からの要求に従ってコンタクトセンター５との間の電話制御を行う。また、アプリケーション１０２２は、コンタクトセンター５で利用されるアプリケーションである。同様に、クライアントアプリケーションＣ（１０３０）は、コンタクトセンターＣ（７）との通信に利用される。
【０１１８】
統合制御アプリケーション１０４０は、各クライアントアプリケーションＡ（１０２０）〜Ｃ（１０３０）を統合的に制御する。アプリケーション制御処理部１０４１は、アラーム監視制御部１０４４から起動されて対応するクライアントアプリケーション１０２０〜１０３０を起動する。また、割り込み釦制御部１０４２から起動されて、クライアントと顧客の通話に対する割り込み通話を対応するＩＰ−ＯＢＸ（５２等）に要求する。
【０１１９】
割り込み釦制御１０４２は、スペシャリストが「割り込み釦」を押下した時に起動されてアプリケーション制御処理部１０４１を起動する。現クライアント情報テーブル１０４３は、現にスペシャリスト端末１０が起動しているクライアントの情報を管理するテーブルである。アラーム監視制御部１０４４は、タスクマネージャから定期的に起動され、自状態が「空き」であれば、アプリケーション制御処理部１０４１を起動する。自状態テーブル１０４５は、スペシャリスト端末の空き／塞がりを管理するテーブルである。
【０１２０】
次に各部相互の関連動作を、図１４に示す具体例を用いて詳細に説明する。図１４は、顧客Ａからの問合せに対してスペシャリストが応答するまでの動作シーケンスの一例を示したものである。また、図１５〜１７にはその過程で参照されるテーブル等の一例を示している。
【０１２１】
本例におけるクライアント端末４は、全てのコンタクトセンター５〜７に共通のスペシャリスト呼び出し釦（「アラーム釦」）を有している。図１２のアラーム釦制御部４５６がこのアラーム釦をクライアント端末４上に表示する。
【０１２２】
なお、従来より「監督呼び出し釦」を具備するクライアントアプリケーションも多く存在する。しかしながら、これはコンタクトセンター専用の呼び出し釦であり、主にその企業で取り扱っている商品知識に詳しい監督者をオペレータからのアラームで呼び出して、サイレントモニタや割り込み通話を行うためのものである。
【０１２３】
図１４では、図１０に示す顧客ＡがコンタクトセンターＡ（５）にアクセスし、コンタクトセンター５がネットワーク内のあるクライアント端末４にそれを配信するところから開始する（Ｓ０１）。
【０１２４】
なお、その前段階として顧客Ａからコンタクトセンター５に着信があると、図１１の着信元分析部５２６で、顧客の電話番号、コンタクトセンター番号、着信させるクライアント番号、クライアントの電話番号及び起動するアプリケーションを収集する。この情報は、図１２に示すクライアント端末４へ通知され、クライアント端末４のアプリケーション制御処理部４５０がそのアプリケーション番号に対応したクライアントアプリケーション４３を起動すると共に、図１５に示すこの情報を現クライアント情報テーブル４５７に設定する。
【０１２５】
図１４に戻って、着信によって顧客Ａとクライアント端末４のオペレータは通話中となる（Ｓ０１及び０２）。ここでは、顧客Ａのクレームが法的な内容のために、オペレータはクライアント端末４の「アラーム釦」を押下してスペシャリストに助言を求める（Ｓ０３）。
【０１２６】
この場合には、図１２のアラーム釦制御部４５６が、アプリケーション制御処理部４５０を起動する。アプリケーション制御処理部４５０は、クライアント端末４を特定する情報（図１５参照）を現クライアント情報テーブル４５７から取得し、それをアラーム情報としてアラーム監視サーバ９に登録するように要求する（Ｓ０４）。
【０１２７】
アラーム監視サーバ９は、そのアラーム情報を通信制御部９１を介して受信してアラーム状態テーブル制御部９２を起動する。アラーム状態テーブル制御部９２は、アラーム状態テーブル９３をサーチし、その空きエリアにＯＳが持っている現在時刻（登録時刻）を付加したアラーム情報を設定する（Ｓ０５）。図１６にはアラーム状態テーブル９３に登録されたアラーム情報の一例を示している。登録時刻等の情報を除けば、クライアント端末４の現クライアント情報テーブル４５７に設定されている情報のコピーである。
【０１２８】
一方、図１３に示すスペシャリスト端末１０において、アラーム監視制御部１０４４がＯＳ機能のタスクマネージャによって定期的に起動されている。アラーム監視制御部１０４４は、起動の際に自端末の状態を示す自状態データ１０４５を参照する。図１７に示すように、自状態テーブル１０４５には、現時点で顧客からの問合せに応答可能な「空き」状態か、それ以外の「塞がり」状態かが設定されている。自状態が「塞がり」の場合にはなにもしない。
【０１２９】
自状態が「空き」に設定されると（Ｓ０６）、アラーム監視制御部１０４４から定期的に起動されたアプリケーション制御処理部１０４１が、通信制御部１０１０を経由して、図１２に示すアラーム管理サーバ９のアラーム状態テーブル制御部９２に登録されたアラーム情報を要求する（Ｓ０７）。アラーム状態テーブル制御部９２は、アラーム状態テーブル９３をサーチして登録時刻が一番古いアラーム情報を抽出する（図１６参照）。抽出された情報は、二重アクセスを回避するためアラーム状態テーブル９３から削除される。
【０１３０】
なお、前記アラーム情報のサーチ及び抽出の際には、法律等の特定分野のアラーム情報だけを抽出するように構成してもよい。例えば、図１５のアラーム情報にアラーム種別の情報を付加したり、スペシャリスト端末１０からのアラーム要求情報に抽出すべきアラーム種別の情報を含ませるようにしてもよい。
【０１３１】
抽出されたアラーム情報は、通信制御部４１及び１０１０経由でスペシャリスト端末１０のアプリケーション制御処理部１０４１に渡される（Ｓ０８）。スペシャリスト端末１０のアプリケーション制御処理部１０４１は、入力データを現クライアント情報テーブル１０４３に設定する。また、入力データから対応するクライアントアプリケーションＡ（１０２０）を起動し、併せて「割り込み釦」を表示する。
【０１３２】
その際、アプリケーション制御処理部１０４１は、アラーム監視制御部１０４４を起動して自状態の変更要求（空きから塞がり）を出す。アラーム監視制御部１０４４は、その内部データである自状態テーブル１０４５の自状態データを「空き」から「塞がり」に変更する。
【０１３３】
アプリケーション制御処理部１０４１は、さらに入力データのコンタクトセンター番号及び顧客の電話番号を基に、通信制御部１０１０経由で、該コンタクトセンター５のサーバ５１（図１１）へ顧客Ａの顧客情報を要求する（Ｓ０９）。コンタクトセンターサーバ５１は、顧客Ａの電話番号をキーとして顧客情報データベース５１０を検索し、通信制御部５２９及び１０１０１経由でスペシャリスト端末１０のアプリケーション制御処理部１０４１へ検索結果の顧客情報を渡す（Ｓ１０）。
【０１３４】
アプリケーション制御処理部１０４１は、既に起動されているクライアントアプリケーションＡ（１０２０）に顧客情報表示を要求し、そのアプリケーション上に受信した顧客情報を表示させる（Ｓ１１）。表示される顧客情報には、顧客Ａの過去のアクセス履歴やクレーマか否か等の種々の情報が含まれる。
【０１３５】
次に、アプリケーション制御処理部１０４１は、先に入力されたコンタクトセンター番号と顧客の電話番号及びクライアントの電話番号を入力として、通信制御部１０１０及び５２９経由で、当該コンタクトセンター５のＩＰ−ＰＢＸ５２に顧客の電話番号とクライアントの電話番号に対するサイレントモニタ要求を発行する（Ｓ１２及び１３）。なお、「モニタ」設定は、スペシャリストが手動でモニタ設定できるようにしてもよい。
【０１３６】
この要求により、ＩＰ−ＰＢＸ５２は、顧客Ａとクライアント端末４との間の通話をモニタできるように、スペシャリスト端末１０との間にモニタ用の通話パスを追加する（Ｓ１４）。このモニタは、顧客Ａとクライアント端末４との間の通話を、両者に気づかれないようにスペシャリスト端末１０の側で聴取するものであり、「サイレントモニタ」と呼ばれる。
【０１３７】
このサイレントモニタ中に、スペシャリストがスペシャリスト端末１０の画面上に表示されている「割り込み釦」を押下すると（Ｓ１５）、統合制御アプリケーション１０４０の割り込み釦制御部１０４２が起動され、アプリケーション制御処理部１０４１に「割り込み通話（三者通話）」の要求を出す。アプリケーション制御処理部１０４１は、現クライアント情報テーブル１０４３から顧客Ａの電話番号と現クライアントの電話番号を抽出し、通信制御部１０１０を介してコンタクトセンター５に通話の割り込みを要求する（Ｓ１６）。
【０１３８】
この要求はコンタクトセンター５の通信制御部５２９を経由してＩＰ−ＰＢＸ５２に与えられ、入力された顧客Ａの電話番号と現クライアントの電話番号を基に、その間の通話に対して割り込み通話を要求する。これにより、ＩＰ−ＰＢＸ５２は割り込み通話用のパスを設定することで、顧客Ａと現クライアントの通話への割り込み通話を実行する（Ｓ１７）。
【０１３９】
この後の処理は図１４中には示していないが、スペシャリストによるサイレントモニタまたは割り込み通話が終了すると、スペシャリスト端末１０の電話制御部Ａ（１０２１）から、アプリケーションＡ（１０２０）を経由して、アプリケーション制御処理部１０４１に完了要求が発行される。
【０１４０】
アプリケーション制御処理部１０４１は、アラーム監視制御部１０４４を起動して自状態の変更要求（塞がりから空き）を出す。アラーム監視制御部１０４４は、その内部データである自状態テーブル１０４５の自状態データを「塞がり」から「空き」に変更する。
【０１４１】
以上述べたように、本例によれば、複数のコンタクトセンターに対応するクライアント端末からのアラーム要求が発生した場合、これに対応する共通のスペシャリストにその旨を通知し、この通知を受けたスペシャリストがサイレントモニタ及び割込み通話により対応を行うことが可能となる。
【０１４２】
そのため、複数のコンタクトセンター共通のスペシャリストを配置でき、コンタクトセンター毎にそれぞれのスペシャリストを配置するのに比べて経済的負担が大幅に軽減される。さらに、問合せ内容に応じて種々のスペシャリストによる高度な助言等も可能となるため、顧客満足度の高いサービスが提供可能となる。
【図面の簡単な説明】
【０１４３】
【図１】本発明による分散型コンタクトセンターシステムのネットワーク構成の一例を図式的に示した図である。
【図２】図１のリモートサイトの基本的なブロック構成例を示した図である。
【図３】図１のクライアント端末の基本的なブロック構成例を示した図である。
【図４】全オペレータ端末スケジュールテーブルの一例を示した図である。
【図５】送信起動スケジュールテーブルの一例を示した図である。
【図６】Ｓｉｇｎ-Ｏｎスケジュールデータの一例を示した図である。
【図７】端末状態管理テーブルの一構成例を示した図である。
【図８】コンタクトセンター状態表示画面の一例を示した図である。
【図９】コンタクトセンター障害時の迂回接続の一例を示した図である。
【図１０】分散型コンタクトセンターシステムの別のネットワーク構成例を図式的に示した図である。
【図１１】図１０のリモートサイトの基本的なブロック構成例を示した図である。
【図１２】図１０のクライアント端末及びアラーム管理サーバの基本的なブロック構成例を示した図である。
【図１３】図１０のスペシャリスト端末の基本的なブロック構成例を示した図である。
【図１４】図１０の一動作例を示すシーケンス図である。
【図１５】現クライアント情報の一例を示した図である。
【図１６】アラーム情報の一例を示した図である。
【図１７】自状態情報の一例を示した図である。
【符号の説明】
【０１４４】
１    ＰＳＴＮ又は公衆ＩＰ網
２    リモートサイト
３    私設網又は公衆ＩＰ網
４    クライアント端末
５〜７    コンタクトセンター
８    監視端末
９    アラーム監視サーバ
１０    スペシャリスト端末
４３〜４４    クライアントアプリケーション
４５    統合制御アプリケーション
５１〜７１    コンタクトセンターサーバ
５２〜７２    ＩＰ‐ＰＢＸ
５３、６３、６４    ゲートウェイ
【図１】
2005117620.tif 000003
【図２】
2005117620.tif 000004
【図３】
2005117620.tif 000005
【図４】
2005117620.tif 000006
【図５】
2005117620.tif 000007
【図６】
2005117620.tif 000008
【図７】
2005117620.tif 000009
【図８】
2005117620.tif 000010
【図９】
2005117620.tif 000011
【図１０】
2005117620.tif 000012
【図１１】
2005117620.tif 000013
【図１２】
2005117620.tif 000014
【図１３】
2005117620.tif 000015
【図１４】
2005117620.tif 000016
【図１５】
2005117620.tif 000017
【図１６】
2005117620.tif 000018
【図１７】
2005117620.tif 000019