(57)【要約】【課題】コールセンターにおける各プロジェクトごとの電話回線への負荷状況、すなわち稼電の混雑度を見ながら、当該各プロジェクト間で電話回線を動的に融通しあうことが可能な技術を提供する。【解決手段】混雑度基準受信部１５１と、回線利用状況データ受信部１５２と、着信率算出部１５３と、混雑度判定部１５４と、回線融通依頼部１５５と、回線融通処理実行部１５６とからシステム１００を構成する。【選択図】図１
2008312044.tif 000002
【特許請求の範囲】
【請求項１】
コールセンター業務の各プロジェクトにおいて、外部の顧客から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者から提供されて、コールセンター業務を遂行するコールセンターの管理システムであって、
各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェースから受け付け、メモリ装置に格納する、混雑度基準受信部と、
前記プロジェクトごとの回線利用状況データを、前記キャリア事業者のシステムから受信し、運用管理データベースに格納する、回線利用状況データ受信部と、
前記運用管理データベースから読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベースに格納する、着信率算出部と、
前記運用管理データベースから読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納する、混雑度判定部と、
前記混雑度判定部において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリに格納する、回線融通依頼部と、
前記回線融通依頼情報をメモリから読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する、回線融通処理実行部とを備えることを特徴とする、
コールセンター管理システム。
【請求項２】
前記混雑度基準データは、前記単位時間ごとの着信率を複数の単位時間にわたって移動平均した着信率移動平均値を用いて規定され、
前記着信率算出部は、前記単位時間ごとの着信率の算出に加え、当該着信率を複数の単位時間にわたって移動平均した着信率移動平均値を算出し、着信率データとして前記運用管理データベースに格納するとともに、
前記混雑度判定部は、前記着信率データに代わり、前記運用管理データベースから読み出した前記着信率移動平均値を、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納することを特徴とする、
請求項１に記載のコールセンター管理システム。
【請求項３】
前記コールセンター業務の各プロジェクトは、複数のコールセンターに分散して遂行され、
前記複数のコールセンターは、それぞれ前記コールセンター管理システムを備え、
前記回線融通依頼部は、前記回線融通依頼情報を、他のコールセンターに属する前記他のプロジェクトのコールセンター管理システムに向けて送信するとともに、
前記回線融通処理実行部は、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のコールセンターに属する他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行することを特徴とする、
請求項１または２に記載のコールセンター管理システム。
【請求項４】
前記混雑度判定部において前記回線管理データベースに格納された、各プロジェクトごとの混雑状況データを読み出し、混雑度が高いと判定されるプロジェクトについて、当該プロジェクトに属するオペレータの端末に、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末を介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する応対を繰り返すよう促す、着信優先指示を出力する、着信優先指示出力部と、
稼電した顧客から、前記オペレータや自動応答装置が聴取した情報を、前記オペレータ端末や前記自動応答装置から取得し、前記運用管理データベースに格納する、顧客情報登録部とを備えることを特徴とする、
請求項１〜３のいずれかに記載のコールセンター管理システム。
【請求項５】
前記運用管理データベースから、稼電した顧客からコールバックする予定で前記オペレータや自動応答装置が聴取した電話番号を読み出し、当該電話番号を、オペレータによるコールバック処理実行に備えて当該オペレータの端末に出力する、コールバックスタンバイ自動実行部を備えることを特徴とする、
請求項４に記載のコールセンター管理システム。
【請求項６】
前記コールバックのための電話番号が、前記オペレータの端末にコールバック処理実行に備えて出力されている、コールバックスタンバイ状態において、外部の顧客からの稼電が当該オペレータに接続されてしまうことを防止する処理を実行する、稼電ブロック部を備えることを特徴とする、
請求項５に記載のコールセンター管理システム。
【請求項７】
コールセンター業務の各プロジェクトにおいて、外部の顧客から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者から提供されて、コールセンター業務を遂行するコールセンターの管理を行うコンピュータが、
各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェースから受け付け、メモリ装置に格納する処理と、
前記プロジェクトごとの回線利用状況データを、前記キャリア事業者のシステムから受信し、運用管理データベースに格納する処理と、
前記運用管理データベースから読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベースに格納する処理と、
前記運用管理データベースから読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納する処理と、
前記混雑度判定部において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリに格納する処理と、
前記回線融通依頼情報をメモリから読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する処理と、
を実行することを特徴とする、コールセンター管理方法。
【請求項８】
コールセンター業務の各プロジェクトにおいて、外部の顧客から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者から提供されて、コールセンター業務を遂行するコールセンターの管理を行うコンピュータに、
各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェースから受け付け、メモリ装置に格納するステップと、
前記プロジェクトごとの回線利用状況データを、前記キャリア事業者のシステムから受信し、運用管理データベースに格納するステップと、
前記運用管理データベースから読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベースに格納するステップと、
前記運用管理データベースから読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納するステップと、
前記混雑度判定部において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリに格納するステップと、
前記回線融通依頼情報をメモリから読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行するステップと、
を実行させることを特徴とする、コールセンター管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コールセンター管理システム、コールセンター管理方法、およびコールセンター管理プログラムに関し、特に、コールセンターにおける各プロジェクトごとの電話回線への負荷状況、すなわち稼電の混雑度を見ながら、当該各プロジェクト間で電話回線を動的に融通しあうことが可能な技術に関する。
【背景技術】
【０００２】
情報処理や情報通信の負荷を緩和するための技術が提案されている。例えば、特許文献１には、コンピュータネットワークシステムにおいて端末装置からのアクセス状態に応じた適切な負荷分散処理を行いうる負荷分散システムおよび方法ならびにプログラムを提供するとの目的の下、インターネット経由で多数の端末装置からのアクセスを受け付けるコンピュータネットワークシステムにおける負荷分散システムであって、複数のウェブサーバを含んで構成された第１ サーバ群と、複数のウェブサーバを含んで構成された第２ サーバ群とを備え、上記第１ サーバ群は、サブドメインがそれぞれ異なるように設定された複数のウェブサイトが格納されたウェブサーバが複数並列にインターネット接続されて構成され、上記第２ サーバ群は、サブドメインがそれぞれ異なるように設定された複数のウェブサイトが格納されたウェブサーバが複数並列にインターネット接続されて構成され、上記第１ サーバ群を構成する複数のウェブサーバはそれぞれサブドメインが異なるように設定され、上記第２ サーバ群を構成する複数のウェブサーバはそれぞれサブドメインが異なるように設定され、上記第１ サーバ群を構成するウェブサーバに格納された各ウェブサイトと、上記第２ サーバ群を構成するウェブサーバに格納された各ウェブサイトとは、相互に対応するウェブサイトがそれぞれ同じサイト構成であり、端末装置からのアクセスに対し、当該アクセスのアクセス状態に基づいて、上記第１ サーバ群を構成するウェブサーバと、第２ サーバ群を構成するウェブサーバとで選択的にアクセスを受け付けるよう構成されたことを特徴とする負荷分散システムなどが開示されている。
【特許文献１】特開２００７−９４４６６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、ネットワークやアプリケーションへの負荷、すなわちコンピュータシステムへの負荷に起因する処理速度の低下などの不具合を防止する負荷分散技術は、コールセンターなどにおける電話回線への負荷、すなわち顧客（コールセンターに電話を掛ける客）からの稼電の混雑度を緩和するための技術とは本質的に異なる。前者は、負荷の増大に伴う影響が、例えば処理速度の「低下」として現れ、どんなに負荷が大きい場合であっても、処理速度がゼロになることは基本的にない。一方、後者の場合は、例えば、顧客からのコールセンターへの稼電数が、当該コールセンターに用意されている電話回線数を上回ってしまった場合などは、後から稼電した顧客はその呼がコールセンターに接続されず、全く通話を行うことができない。つまり、後者の場合は負荷の影響は、可か不可か、すなわち、接続および通話が可能か不可能かという、いわば二値的な結果として現れてしまう。
【０００４】
上記後者のような技術、すなわち、コールセンターなどにおける電話回線への負荷、すなわち稼電の混雑度を緩和するための技術においては、従来、いわば静的な問題解決技術しか存在しなかった。つまり、以下のような技術である。コールセンター事業では、通常、具体的なコールセンター業務（以下、プロジェクトという）ごとに、顧客が稼電するための代表番号（例：０１２０で始まるフリーダイヤル番号など）が設定され、その代表番号として利用される電話回線の束を、あらかじめ、電話回線を提供するキャリア事業者から契約する。そして、稼電が契約回線数を上回り、コールセンターに稼電される呼が溢れ、当該コールセンターへの自動応答装置やオペレータに通話が接続される着信率が著しく低下してしまった場合は、コールセンターの管理者はオペレータに「着信優先モード（または、コールバックモード）」の対応を取るよう指示を出す。着信優先モードの対応とは、オペレータや自動応答装置が、顧客からの呼を着信し、通話を接続した上で「後ほどこちらから掛け直しますので電話番号をお教えください」などと伝えて即座に通話を打ち切り、コールバックするための電話番号を取得しつつ、とにかく次々と稼電を受けてゆく対応である。これにより、外部からコールセンターに稼電されたにも関わらず接続できず溢れてしまっている呼を、とにかく次々と接続し、混雑度を緩和し、着信率を上昇させることができる。
【０００５】
あるいは別の解決策として、あらかじめキャリア業者からの契約に含まれていた混雑時用の予備回線、いわゆるバッファ回線を、当該混雑中のプロジェクトに割り当て、電話回線数を増加させることにより着信率を上昇させる技術も存在している。しかし、これら二つの負荷緩和策は、いずれも静的なものであって、動的なものではない。
【０００６】
そこで本発明は上記課題を鑑みてなされたものであり、コールセンターにおける各プロジェクトごとの電話回線への負荷状況、すなわち稼電の混雑度を見ながら、当該各プロジェクト間で電話回線を動的に融通しあうことが可能な、コールセンター管理技術の提供を主たる目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決する本発明のコールセンター管理システムは、コールセンター業務の各プロジェクトにおいて、外部の顧客から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者から提供されて、コールセンター業務を遂行するコールセンターの管理システムであって、各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェースから受け付け、メモリ装置に格納する、混雑度基準受信部と、前記プロジェクトごとの回線利用状況データを、前記キャリア事業者のシステムから受信し、運用管理データベースに格納する、回線利用状況データ受信部と、前記運用管理データベースから読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベースに格納する、着信率算出部と、前記運用管理データベースから読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納する、混雑度判定部と、前記混雑度判定部において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリに格納する、回線融通依頼部と、前記回線融通依頼情報をメモリから読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する、回線融通処理実行部とを備える。
【０００８】
また、前記コールセンター管理システムにおいて、前記混雑度基準データは、前記単位時間ごとの着信率を複数の単位時間にわたって移動平均した着信率移動平均値を用いて規定され、前記着信率算出部は、前記単位時間ごとの着信率の算出に加え、当該着信率を複数の単位時間にわたって移動平均した着信率移動平均値を算出し、着信率データとして前記運用管理データベースに格納するとともに、前記混雑度判定部は、前記着信率データに代わり、前記運用管理データベースから読み出した前記着信率移動平均値を、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納する、としてもよい。
【０００９】
また、前記コールセンター管理システムにおいて、前記コールセンター業務の各プロジェクトは、複数のコールセンターに分散して遂行され、前記複数のコールセンターは、それぞれ前記コールセンター管理システムを備え、前記回線融通依頼部は、前記回線融通依頼情報を、他のコールセンターに属する前記他のプロジェクトのコールセンター管理システムに向けて送信するとともに、前記回線融通処理実行部は、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のコールセンターに属する他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する、としてもよい。
【００１０】
また、前記コールセンター管理システムは、前記混雑度判定部において前記回線管理データベースに格納された、各プロジェクトごとの混雑状況データを読み出し、混雑度が高いと判定されるプロジェクトについて、当該プロジェクトに属するオペレータの端末に、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末を介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する応対を繰り返すよう促す、着信優先指示を出力する、着信優先指示出力部と、稼電した顧客から、前記オペレータや自動応答装置が聴取した情報を、前記オペレータ端末や前記自動応答装置から取得し、前記運用管理データベースに格納する、顧客情報登録部とを備える、としてもよい。
【００１１】
また、前記コールセンター管理システムは、前記運用管理データベースから、稼電した顧客からコールバックする予定で前記オペレータや自動応答装置が聴取した電話番号を読み出し、当該電話番号を、オペレータによるコールバック処理実行に備えて当該オペレータの端末に出力する、コールバックスタンバイ自動実行部を備えるとしてもよい。
【００１２】
また、前記コールセンター管理システムにおいて、前記コールバックのための電話番号が、前記オペレータの端末にコールバック処理実行に備えて出力されている、コールバックスタンバイ状態において、外部の顧客からの稼電が当該オペレータに接続されてしまうことを防止する処理を実行する、稼電ブロック部を備える、としてもよい。
【００１３】
また、本発明のコールセンター管理方法は、コールセンター業務の各プロジェクトにおいて、外部の顧客から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者から提供されて、コールセンター業務を遂行するコールセンターの管理を行うコンピュータが、各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェースから受け付け、メモリ装置に格納する処理と、前記プロジェクトごとの回線利用状況データを、前記キャリア事業者のシステムから受信し、運用管理データベースに格納する処理と、前記運用管理データベースから読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベースに格納する処理と、前記運用管理データベースから読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納する処理と、前記混雑度判定部において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリに格納する処理と、前記回線融通依頼情報をメモリから読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する処理と、を実行する方法である。
【００１４】
また、本発明のコールセンター管理プログラムは、コールセンター業務の各プロジェクトにおいて、外部の顧客から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者から提供されて、コールセンター業務を遂行するコールセンターの管理を行うコンピュータに、各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェースから受け付け、メモリ装置に格納するステップと、前記プロジェクトごとの回線利用状況データを、前記キャリア事業者のシステムから受信し、運用管理データベースに格納するステップと、前記運用管理データベースから読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベースに格納するステップと、前記運用管理データベースから読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベースに格納するステップと、前記混雑度判定部において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリに格納するステップと、前記回線融通依頼情報をメモリから読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行するステップと、を実行させるプログラムである。
【００１５】
その他、本願が開示する課題、及びその解決方法は、発明の実施の形態の欄、及び図面により明らかにされる。
【発明の効果】
【００１６】
本発明によれば、コールセンターにおける各プロジェクトごとの電話回線への負荷状況、すなわち稼電の混雑度を見ながら、当該各プロジェクト間で電話回線を動的に融通しあうことが可能な、コールセンター管理技術を提供できる。
【発明を実施するための最良の形態】
【００１７】
−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態のコールセンター管理システム１００を含むネットワーク構成図である。前記コールセンター管理システム１００（以下、システム１００という）は、コールセンター業務の各プロジェクトにおいて、外部の顧客（コールセンターに電話を掛ける客を指す、以下同様）から稼電される電話番号に使用される複数の電話回線を、電話回線のキャリア事業者Ａから提供されて、コールセンター業務を遂行するコールセンター６００の管理システム１００である。
【００１８】
コールセンター６００には、システム１００以外に、ＰＢＸ６０１、自動応答装置６０２、コールセンター管理者のコンピュータ端末６０３Ｃおよび同管理者の電話機６０３Ｐ、各オペレータのコンピュータ端末６０４Ｃ、６０５Ｃ、６０６Ｃおよび同各オペレータの電話機６０４Ｐ、６０５Ｐ、６０６Ｐなどが設けられている。ＰＢＸ（private branch exchange：構内電話交換機）６０１は、コールセンター６００内の各電話機６０２、６０３Ｐ〜６０６Ｐ間の相互接続や、コールセンター６００と外部電話回線Ｔ１、Ｔ２、Ｂとの接続などを行う。コールセンター６００の外部電話回線Ｔ１、Ｔ２、Ｂは、契約により、電話回線キャリア事業者であるキャリア局Ａから提供されている。電話回線Ｔ１、Ｔ２は、それぞれ、別々のコールセンター業務プロジェクト（以下、単にプロジェクトという）に使用される電話回線の束を表している。一本の電話回線で同時に複数の稼電を接続し、通話を行うことはできない。コールセンター管理者のコンピュータ端末６０３Ｃや各オペレータのコンピュータ端末６０４Ｃ、６０５Ｃ、６０６Ｃは、例えば通常のパーソナルコンピュータなどであり、本実施形態のこれら端末６０３Ｃ、６０４Ｃ、６０５Ｃ、６０６Ｃおよび上記各電話機６０３Ｐ、６０４Ｐ、６０５Ｐ、６０６Ｐは、ＣＴＩ（Computer Telephony Integration）技術により連動するものとする。
【００１９】
各プロジェクトには、例えば「０１２０」から始まるフリーダイヤル番号のような「代表番号」が設定されている。この代表番号の下に、外部の顧客からの稼電を受けるための電話回線（いわゆる実回線）が、通常は複数本ずつ割り当てられている。また、図１における電話回線Ｂは、キャリア事業者Ａから契約により提供された混雑時用の予備回線、いわゆるバッファ回線である。本発明では、これら電話回線Ｔ１、Ｔ２、Ｂは、本コールセンター６００のオペレータや管理者などが外部の顧客に向けて（通常の接続＝着信とは逆に）発呼する（以下、コールバックするという）際にも使用されるものとする。実際のコールセンターでは、顧客からの稼電を受ける電話回線と、コールバック用の電話回線とは区別されている場合もあるが、本発明はそのような着信用回線とコールバック用回線とが分けられている場合であっても、同様に適用が可能である。また、本コールセンタ管理システム１００は、ＶｏＩＰ（Voice over Internet Protocol）など、通常の電話回線と異なる電話通信技術を用いる場合にも同様に適用可能である。
【００２０】
また、コールセンター６００（仮にその名前を「首都圏センタ」とする）を運営するコールセンター事業者は、図示しない他のコールセンター（仮にその名前を「△○購入窓口」とする）においても同様のコールセンター業務プロジェクトを行っているものとする。当該他のコールセンターにおけるプロジェクトの電話回線も、コールセンター６００と同じくキャリア局Ａから、契約により提供されるため、これら両コールセンター間では、電話回線を共有的に使用し、混雑時などに互いに融通しあうことが可能である。上記他の△○購入窓口コールセンターにおいても、いずれも図示省略しているが、コールセンター６００と同様のコールセンター管理システム、ＰＢＸ、自動応答装置、コールセンター管理者の端末および同管理者の電話機、各オペレータの端末および同各オペレータの電話機などが設けられているものとする。
【００２１】
コールセンター６００への外部の顧客からの稼電（呼）は、キャリア局ＡからＰＢＸ６０１へと入ってくる場合（図の「稼電１」）もあれば、さらに他のキャリア局Ｂ、Ｃからキャリア局Ａを経由して入ってくる場合（図の「稼電２」、「稼電３」）もある。顧客からの稼電は、各キャリア局Ａ〜Ｃの局内交換機２０１、３０１、４０１を順次経由してＰＢＸ６０１へと接続される。各キャリア局Ａ〜Ｃには、それぞれ、上記局内交換機２０１、３０１、４０１に接続されて、各種管理システム２００、３００、４００および回線接続履歴データベース２０２、３０２、４０２が設けられている。図１では一例として３つのキャリア局Ａ〜Ｃを描いたが、この数に限定されるものではない。
【００２２】
キャリア局Ａ〜Ｃの各種管理システム２００、３００、４００の有する機能は、ネットワーク通信管理機能、局内交換機２０１、３０１、４０１の管理機能、および、後述する、コールセンタ６００などにおけるプロジェクトの回線利用状況データ蓄積機能などである。
【００２３】
また、システム１００は、ＷＡＮ（Wide Area Network：広域通信網）５００を介し、キャリア局Ａの各種管理システム２００や、図示省略しているが、上記他のコールセンターのコールセンター管理システムに接続されている。また、システム１００は、ＬＡＮ（Local Area Network：構内通信網）を介し、コールセンター６００内のＰＢＸ６０１や自動応答装置６０２、コールセンター管理者の端末６０３Ｃおよび各オペレータの端末６０４Ｃ、６０５Ｃ、６０６Ｃに接続されている。これらの接続手段は、それぞれＷＡＮやＬＡＮに限定されるものではなく、その他の種類の通信ネットワークによるものであってもよい。
【００２４】
前記システム１００の機能構成としては、本発明のコールセンター管理方法を実行する機能を実現すべく、ハードディスクドライブなどの記憶装置１０１にプログラム１０２を備えて、このプログラム１０２をメモリ１０３に読み出し、演算装置たるＣＰＵ１０４により実行する。また、前記システム１００は、各種ボタン類などの入力インターフェイス１０５や、ディスプレイなどの出力インターフェイス１０６を有している。また、システム１００は、ＷＡＮ５００を介し、キャリア局Ａの各種管理システム２００や、上記他のコールセンターのコールセンター管理システムなどの外部装置との間で、データ授受を実行したり、ＬＡＮを介してコールセンター内部のＰＢＸ６０１や自動応答装置６０２、コールセンター管理者の端末６０３Ｃおよび各オペレータの端末６０４Ｃ、６０５Ｃ、６０６Ｃなどとの間でデータ授受を実行したりする、通信装置（ネットワーク管理装置）１０７を有している。また、システム１００の後述する各種機能部と通信装置１０７との間では、Ｉ／Ｏ部１０８がデータのバッファリングや各種仲介処理を実行している。
【００２５】
続いて、前記システム１００が、例えばプログラム１０２に基づき構成・保持する機能部につき説明を行う。なお、前記システム１００は、運用管理データベース１２５と、回線管理データベース１２６と、ＰＢＸ管理データベース１２７とを利用可能であるとする。前記各データベース１２５〜１２７は、前記システム１００のコンピュータ装置が備えるハードディスクドライブなどの適宜な記憶装置に備わるものとしてもよい。或いは、これらデータベース１２５〜１２７がシステム１００とは別にネットワーク（前記ＷＡＮ５００や前記ＬＡＮ）上に存在するとしてもよい。後者のようなの場合、前記システム１００は例えばＤＢＭＳ（Database Management System）を備え、上記ネットワークを介して前記各データベース１２５〜１２７にアクセスし、情報登録や情報検索などの処理を実行することとすればよい。
【００２６】
こうしたシステム１００は、まず、ＰＢＸ６０１の動作を管理する、ＰＢＸ管理部１５０を備える。ＰＢＸ管理部１５０によるＰＢＸ６０１の動作管理に関連するデータはＰＢＸ管理データベース１２７に格納される。
【００２７】
また、システム１００は、各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェース１０５から受け付け、メモリ装置に、具体的には例えば前記運用管理データベース１２５などに格納する、混雑度基準受信部１５１を備える。
【００２８】
稼電の混雑度を示す基準は、例えば、各プロジェクトのＳＬＡ（service level agreement：サービスレベルアグリーメント）などに基づいて決定される。混雑度を示す基準を規定するための値（パラメータ）としては、着信率や着信率移動平均値などを採用することができる。着信率や着信率移動平均値の説明は後述する。また、混雑度基準データの具体例についても後述する。
【００２９】
また、前記システム１００は、前記プロジェクトごとの回線利用状況データを、前記キャリア事業者Ａのシステム、具体的にはキャリア局Ａの各種管理システム２００から受信し、運用管理データベース１２５に格納する、回線利用状況データ受信部１５２を備える。
【００３０】
通常、コールセンターに電話回線を提供するキャリア局Ａでは、コールセンターが使用するそれら各電話回線の詳細な利用状況データが蓄積されている。本実施形態では、キャリア局Ａの各種管理システム２００に接続された回線接続履歴データベース２０２に、この回線利用状況データが蓄積されているものとする。各コールセンター事業者は、この回線利用状況データを取得し、様々な分析に利用することができる。
【００３１】
本実施形態では、具体的には、コールセンター６００のシステム１００の回線利用状況データ受信部１５２は、様々な分析に使用しうる最大限の種類のデータを１セットとして抽出し、これを「最大抽出回線利用状況データ」として、キャリア局Ａのシステムの回線接続履歴データベース２０２から取得し、運用管理データベース１２５に格納する。
【００３２】
図２に、この最大抽出回線利用状況データの構造例を示している。この最大抽出回線利用状況データは、コールセンターごとに（すなわち、コールセンター６００の回線利用状況データを前記他のコールセンターの回線利用状況データから区別して）、かつプロジェクトごとに（すなわち、代表番号ごとに）区別されて、回線利用状況データ受信部１５２により取得される。最大抽出回線利用状況データの構造は、図２の例では、集計区間開始時刻のデータと、総発呼数、完了呼数、話中数、時間外呼数、地域外呼数、限度超過数、迷惑拒否数、待中放棄数、待数超過数、待時超過数、拒否端末数、受け付け呼数、溢れ呼数、非通知呼数、その他の呼数、待後完了数、平均通話時間、待後完了平均時間、待中放棄平均待時間といったデータを関連付けたレコードの集合体となっている。
【００３３】
また、前記システム１００は、前記運用管理データベース１２５から読み出した、各プロジェクトの回線利用状況データ、具体的には前記最大抽出回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンター６００に接続された、単位時間ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベース１２５に格納する、着信率算出部１５３を備える。
【００３４】
着信率の算出は具体的には、まず、着信率算出部１５３が、運用管理データベース１２５から前記最大抽出回線利用状況データを読み出し、その中から着信率を算出するために必要最小限の種類のデータを抽出し、これを「最小抽出回線利用状況データ」として、前記運用管理データベース１２５に格納する。
【００３５】
図３に、この最小抽出回線利用状況データの構造例を示している。この最小抽出回線利用状況データは、元となる上記最大抽出回線利用状況データと同様に、コールセンターごとに、かつプロジェクトごとに構成されている。最小抽出回線利用状況データの構造は、図３の例では、集計区間開始時刻のデータと、総発呼数、完了呼数、話中数、拒否端末呼数、平均通話時間、総発呼数累計、完了呼数累計といったデータを関連付けたレコードの集合体となっている。
【００３６】
ここで、集計区間開始時刻とは、キャリア局Ａで集計される回線利用状況データの集計の単位時間（「集計単位時間」と呼ぶことにする）ごとの開始時刻である。総発呼数とは、集計単位時間ごとに外部の顧客などから稼電された総数である。完了呼数とは、総発呼のうち、自動応答装置６０２やオペレータとの通話が完了した数である。話中数とは、総発呼のうち、稼電されたが電話回線に空きがなく、コールセンター６００の自動応答装置６０２やオペレータに接続できなかった総数である。拒否端末呼数とは、指定外のインフラから稼電された呼の総数である。指定外のインフラとは例えば、キャリア局Ａで設定した、航空機や船舶、衛星、特定の携帯電話など特殊な稼電元のことである。総発呼数累計および完了呼数累計は、後述する着信率移動平均値の算出を迅速に実行するために下準備的に算出されるデータである。これら総発呼数累計および完了呼数累計は、着信率算出部１５３により、運用管理データベース１２５から前記最大抽出回線利用状況データを読み出し、上記総発呼数、完了呼数、話中数などの最小抽出回線利用状況データを抽出する際に算出され、運用管理データベース１２５に格納される。
【００３７】
次に、着信率の算出方法の一例について、詳細に説明する。本発明における着信率の定義は、「各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間（着信率を算出する上での単位時間。以下、この単位時間を上記集計単位時間と区別するために「着信率単位時間」と呼ぶことにする）ごとの割合」とするが、より具体的には、着信率として「接続率」や「応対率」などの値が用いられる。接続率とは、外部からの稼電が、自動応答装置６０２を含めたコールセンター６００全体のどこかに接続された値である。応答率とは、外部からの稼電が、コールセンター６００の管理者やオペレータの電話機６０３Ｐ〜６０６Ｐに接続された値である。以下の説明では、「着信率」という場合、接続率を指すものとする。しかしながら、着信率として応答率を用いたとしても、本発明は同様に適用可能である。
【００３８】
接続率は、一例として以下の式（１）によって算出することができる。  
2008312044.tif 000003
着信率算出部１５３は、例えば、式（１）に含まれる総発呼数、拒否端末呼数、話中数などの数値を、運用管理データベース１２５に格納された上記最小抽出回線利用状況データから読み取り、式（１）に従い接続率を算出し、着信率データとして運用管理データベース１２５に格納する。
【００３９】
また、前記システム１００は、前記運用管理データベース１２５から読み出した前記各プロジェクトの着信率データを、前記メモリ装置から、具体的には例えば前記運用管理データベース１２５などから読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベース１２６に格納する混雑度判定部１５４を備える。
【００４０】
混雑度の判定に使用される混雑度基準データの一例を、図４に示す。図中、ビジー率とは、１００（％）から、着信率の値を減算した値である。ビジー率が高いほど、該当するプロジェクトの電話回線束における、外部からの稼電による混雑度が高いことを示す。混雑状況データの具体例については後述する。
【００４１】
図４の混雑度基準データにおいて、「溢れ状態」とは、ほぼ全てのオペレータが外部からの稼電を着信している状態であり、従って当該プロジェクトには空き回線が存在しないことを示す。「溢れ状態」以外の混雑度は、ビジー率の高い順に、外部からの稼電を着信しているオペレータが多い、いわば手すきのオペレータが少ない状態を示すが、それらのプロジェクトはいずれも、少なくとも一つの空き回線を有していることを示す。
【００４２】
以上のように、混雑度を示す指標として、例えば上記接続率などの着信率を用い、各プロジェクトごとの混雑度を判定するようにすれば、コールセンターにおける各プロジェクトごとの電話回線の現在の負荷状況、すなわち稼電の混雑度を、リアルタイム的に把握しつつ、後述する電話回線の融通などのコールセンター管理を行うことができる。従来の技術として、過去の電話回線負荷状況（稼電の混雑度）の実績データに基づき、混雑状況を予測するコールセンター管理は、既に実現されているが、それではごく大まかな予測を行うことしかできなかった。本実施形態のシステム１００のように、他のプロジェクトや他のコールセンターから空き電話回線を融通して当該プロジェクトの電話回線を増やしたり、逆に他の混雑度の高いプロジェクトやコールセンターに当プロジェクトから電話回線を融通したりといった、ごくリアルタイム的でダイナミックなコールセンター管理を行うことが可能なシステム１００では、混雑度を過去のデータから予測するだけでは不十分であった。これに対し、本実施形態のコールセンター管理システム１００では、上述のように、電話回線負荷状況、すなわち混雑度を、着信率を用いてリアルタイム的に把握しつつ、コールセンターの管理に反映させることができるので、非常に有利である。
【００４３】
また、前記システム１００は、前記混雑度判定部１５４において混雑度が高いと判定されたプロジェクトに対し、他のプロジェクトから、当該他のプロジェクトが保有する空き電話回線を融通する処理を依頼する回線融通依頼情報を生成し、メモリ１０３に格納する、回線融通依頼部１５５を備える。
【００４４】
ここで、「前記混雑度判定部１５４において混雑度が高いと判定されたプロジェクト」とは、具体的には例えば、図４の混雑度基準データで「溢れ状態」および「高負荷」と分類されたプロジェクトを指す。
【００４５】
また、本実施形態では、上記回線融通依頼情報の生成は、前記混雑度判定部１５４における混雑度の判定を基に、システム１００の回線融通依頼部１５５が自動的に実行することとしているが、変形例として、コールセンター管理者が管理者端末６０３Ｃから手動的に指示を入力し、システム１００の入力インターフェース１０５から回線融通依頼部１５５が当該指示を受け付け、回線融通依頼部１５５などが実行することも可能とすれば好ましい。
【００４６】
また、回線融通を依頼する相手である他のプロジェクトは、必ずしも、混雑度が低いプロジェクトや空き電話回線が存在するプロジェクトを、システム１００側で選択する必要はない。すなわち、とりあえず無作為に複数の他のプロジェクトに回線融通依頼を送信して「打診」し、当該回線融通依頼を受信した他のプロジェクトが属するコールセンター管理システムが、当該回線融通依頼が受け入れ可能であるか否かを判断するようにしてもよい。その際の受け入れ可否の判断は、当該他のプロジェクトが属するコールセンター管理システムが、自プロジェクトの混雑度や空き回線状況を基に、自動的に実行してもよいし、当該他のプロジェクトが属するコールセンターの管理者が手動でも実行できるようにしておけば好ましい。本実施形態の後述する処理フロー例では、プロジェクトの混雑度が低い、あるいは空き回線を有する場合、システム１００は、自身が「回線提供可能」であるという情報を生成し、登録しておくこととしている。
【００４７】
また、前記システム１００は、前記回線融通依頼情報をメモリ１０３から読み出し、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する、回線融通処理実行部１５６を備える。
【００４８】
ここで、本実施形態では、上記回線融通処理の実行は、システム１００の回線融通処理実行部１５６が自動的に実行することとしているが、変形例として、コールセンター管理者が管理者端末６０３Ｃから手動的に指示を入力し、システム１００の入力インターフェース１０５から回線融通処理実行部１５６が当該指示を受け付け、回線融通処理実行部１５６などが実行することも可能とすれば好ましい。
【００４９】
このように、本実施形態のコールセンター管理システム１００では、コールセンターにおける各プロジェクトごとの電話回線への負荷状況、すなわち稼電の混雑度を見ながら、当該各プロジェクト間で電話回線を動的に融通しあうことが可能となる。すなわち、各プロジェクト間では互いの電話回線をまるで共有のように扱い、各プロジェクトの混雑度を、着信率を基にリアルタイム的に把握しつつ、ダイナミックに融通しあうことが可能となり、非常に有利である。
【００５０】
また、本実施形態では、前記コールセンター６００のコールセンター業務の各プロジェクトは、複数のコールセンター（コールセンター「○×お客様センタ」６００および図示しない「△○購入窓口」コールセンター）に分散して遂行され、前記複数のコールセンターは、それぞれ前記コールセンター管理システム１００を備え、前記回線融通依頼部１５５は、前記回線融通依頼情報を、当該他のコールセンターに属する前記他のプロジェクトのコールセンター管理システムに向けて送信するとともに、前記回線融通処理実行部１５６は、前記回線融通依頼が、受け入れ可能なものである場合に、前記他のコールセンターに属する他のプロジェクトが保有する空き電話回線を、前記混雑度が高いと判定されたプロジェクトに融通する処理を実行する。
【００５１】
これによれば、ＷＡＮ５００などを介して接続された、当コールセンター６００以外の他のコールセンターとの間でも、電話回線への負荷状況、すなわち稼電の混雑度を見ながら、互いのプロジェクト間で電話回線を動的に融通しあうことが可能となる。すなわち、異なるコールセンターに属するプロジェクト間で電話回線を共有のように扱い、各プロジェクトの混雑度を、着信率を基にリアルタイム的に把握しつつ、ダイナミックに融通しあうことが可能となり、非常に有利である。
【００５２】
また、本実施形態のシステム１００は、前記混雑度判定部１５４において前記回線管理データベース１２６に格納された、各プロジェクトごとの混雑状況データを読み出し、混雑度が高いと判定されるプロジェクトについて、当該プロジェクトに属するオペレータの端末６０４Ｃ〜６０６Ｃに、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末６０４Ｃ〜６０６Ｃを介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する応対を繰り返すよう促す、着信優先指示を出力する、着信優先指示出力部１５７と、稼電した顧客から、前記オペレータや自動応答装置６０２が聴取した情報を、前記オペレータ端末６０４〜６０６Ｃや前記自動応答装置６０２から取得し、前記運用管理データベース１２５に格納する、顧客情報登録部１５８とを備える。
【００５３】
ここで、「混雑度が高いと判定されたプロジェクト」とは、前記同様、図４の混雑度基準データで「溢れ状態」および「高負荷」と分類されたプロジェクトなどを指す。オペレータの端末６０４Ｃ〜６０６Ｃへの着信優先指示は、具体的には例えば、「溢れ状態」や「高負荷」などの具体的な混雑度をも表示するようにすれば好ましい。
【００５４】
このように、現在の電話回線負荷状況、すなわち混雑度が高いプロジェクトのオペレータの端末６０４Ｃ〜６０６Ｃに着信優先指示を出力することにより、オペレータは、管理者からの指示を待つことなくスムーズに、「着信優先モード」に切り替えた応対を行うことが可能となる。着信優先モードの応対とは、上記のように、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末６０４Ｃ〜６０６Ｃを介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する応対である。これにより、外部からコールセンターに稼電されたにも関わらず接続できず溢れてしまっている呼を、とにかく次々と接続し、混雑度を緩和し、着信率を上昇させることができる。このとき当該顧客から取得し、オペレータ端末６０４Ｃ〜６０６Ｃを介して入力した電話番号は、顧客情報登録部１５８の機能により、運用管理データベース１２５に格納される。
【００５５】
なお、上記のような着信優先指示は、管理者の端末６０３Ｃにも出力することとすれば好ましい。本実施形態では、着信優先指示を、管理者の端末６０３Ｃおよびオペレータの端末６０４Ｃ〜６０６Ｃのディスプレイ画面に、ポップアップウィンドウや点滅するアイコンなどの形で表示するようにする。また、管理者の端末６０３Ｃには、着信優先指示のような「結果」だけでなく、上記着信率やビジー率などの数値、あるいは上記着信率データそのものなどを、出力するようにすれば好ましい。そのようにすれば、例えば、一定時間経過後に混雑度が高まりそうな状況を、経験や勘、過去のデータなどに基づいて、管理者が予測し、あらかじめ手動的に他のプロジェクトからの回線融通を手配することも可能となるからである。
【００５６】
また、本実施形態のシステム１００は、前記運用管理データベース１２５から、稼電した顧客からコールバックする予定で前記オペレータや自動応答装置６０２が聴取した電話番号を読み出し、当該電話番号を、オペレータによるコールバック処理実行に備えて当該オペレータの端末６０４Ｃ〜６０６Ｃに出力する、コールバックスタンバイ自動実行部１５９を備える。
【００５７】
これにより、オペレータは、非常に簡単に、外部からの稼電に応対する通常の着信業務から、コールバック予定客へのコールバック業務に移ることができる。
【００５８】
また、本実施形態のシステム１００は、前記コールバックのための電話番号が、前記オペレータの端末６０４Ｃ〜６０６Ｃにコールバック処理実行に備えて出力されている、コールバックスタンバイ状態において、外部の顧客からの稼電が当該オペレータに接続されてしまうことを防止する処理を実行する、稼電ブロック部１６０を備える。
【００５９】
コールバックスタンバイ状態のオペレータに対する稼電ブロック処理は、具体的には、稼電ブロック部１６０からＰＢＸ６０１にそのような指示を出し、実行させることにより行われる。
【００６０】
これにより、コールバックスタンバイ状態のオペレータは、すでにコールバック用の電話番号がオペレータの端末６０４Ｃ〜６０６Ｃに出力され、コールバック実行直前であるにも関わらず、不意に外部からの稼電が入ってきてしまいそちらに対応せざるをえなくなることがなくなり、スムーズにコールバック予定客へのコールバック業務を遂行することができる。
【００６１】
−−−混雑度の判定に着信率移動平均値を用いる変形例−−−
ところで、上記のように、接続率や応答率などで表される着信率は、一人の「リダイヤル客」がいるかいないかによって、大きく上下してしまうという問題がある。ここで、「リダイヤル客」とは、コールセンター６００が遂行中のプロジェクトに稼電するも、電話回線の混雑度が高いため、自動応答装置６０２にもオペレータや管理者にも接続されず、従って何度も繰り返し稼電している顧客のことを指す。リダイヤル客が一人あるいは僅か数名程度現れただけで、着信率は大きく低下し、上記ビジー率は大きく上昇する。逆に、リダイヤル客の稼電が自動応答装置６０２やオペレータあるいは管理者の電話機６０３Ｐ〜６０６Ｐに接続されたり、リダイヤル客が接続をあきらめて稼電をやめたりすることにより、リダイヤル客がいなくなると、着信率は大きく上昇し、上記ビジー率は大きく低下する。
【００６２】
このような、リダイヤル客の存在などによる、いわば「見せかけ」の、混雑度やビジー率の激しい上下を、正確に評価し、混雑度の判定に反映させる技術が望まれる。そこで、混雑度の判定に、以下に説明するような着信率移動平均値を用いることとすれば、より好ましい。
【００６３】
そのような変形例の場合、システム１００は、前記混雑度基準データは、前記単位時間（着信率単位時間）ごとの着信率を複数の単位時間にわたって移動平均した着信率移動平均値を用いて規定され、前記着信率算出部１５３は、前記単位時間ごとの着信率の算出に加え、当該着信率を複数の単位時間にわたって移動平均した着信率移動平均値を算出し、着信率データとして前記運用管理データベース１２５に格納するとともに、前記混雑度判定部１５４は、前記着信率データに代わり、前記運用管理データベース１２５から読み出した前記着信率移動平均値を、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして、各プロジェクトに対応付けて回線管理データベース１２６に格納する。
【００６４】
図５に、運用管理データベース１２５に格納される、着信率移動平均値を用いた着信率データのデータ構造例を示している。項目ｎは、その次の項目である着信率単位時間の開始時刻Ａの通し番号を示す時間帯Ｎｏ．である。図５の例では、着信率単位時間は１０分としている。項目Ｂ、Ｃ、Ｄ、Ｅ、Ｉ、Ｊは、それぞれ、上記図２の最大抽出回線利用状況データおよび図３の最小抽出回線利用状況データと同様の、総発呼数（稼電の累計数）、完了呼数、話中数、平均通話時間、総発呼数累、完了呼数累計である。ただし、上記図２の最大抽出回線利用状況データおよび図３の最小抽出回線利用状況データは、単位時間（集計単位時間）を、１分としたものであったのでその点は異なる。
【００６５】
図５における、項目Ｉの総発呼数累および項目Ｊの完了呼数累計は、前述したように、着信率算出部１５３により、着信率移動平均値の算出を迅速に実行するために下準備的に算出されたデータである。１０分平均着信率Ｋ、２０分平均着信率Ｌ、３０分平均着信率Ｍ、および６０分平均着信率Ｎは、いずれも総発呼数累Ｉおよび完了呼数累計Ｊを用いて算出される。項目Ｐは、上記着信優先指示としてオペレータ端末６０４Ｃ〜６０６Ｃや管理者端末６０３Ｃに出力されるメッセージである。図５の例では、着信率移動平均値により、混雑度が高いと判断される場合、「注意」というメッセージが着信優先指示としてオペレータ端末６０４Ｃ〜６０６Ｃや管理者端末６０３Ｃに出力される。
【００６６】
着信率移動平均値を用いる本変形例の場合、図４に示した、混雑度の判定に使用される混雑度基準データの例において、ビジー率を、例えば１００（％）からＫ〜Ｎいずれかの着信率移動平均値を減算して求めることとすればよい。あるいは、これら着信率移動平均値Ｋ〜Ｎを複合的に用いてビジー率を算出するようにしてもよい。その結果、例えば、上述の例と同様、混雑度基準データで「溢れ状態」および「高負荷」と分類されたプロジェクトを「前記混雑度判定部１５４において混雑度が高いと判定されたプロジェクト」と規定することとすればよい。
【００６７】
あるいは、図４に示した混雑時準データから離れて、着信率移動平均値の特性をより詳細に活かした判定方法によって、リダイヤル客の影響を除去した実質的な混雑度を評価することとしてもよい。具体的には以下のように行う。すなわち、図５の例において、時間帯Ｎｏ．８とＮｏ．９とを比較すると、１０分平均着信率値Ｋは、１００％から２２％へと急激に減少しているが、６０分平均着信率Ｎは、１００％から５０％へと、１０分平均ほどの減少率ではない。これは、おそらく時間帯Ｎｏ．９においてリダイヤル客が登場したことを示している。したがって、このような場合は、６０分平均着信率Ｎのような長い時間にわたる着信率平均値を主な評価基準とし、その結果、項目Ｐの着信優先指示は「ＯＫ」すなわち特に着信優先指示は出力されないこととする。
【００６８】
次に、図５の例において、時間帯Ｎｏ．９とＮｏ．１０とを比較すると、１０分平均着信率値Ｋは、２２％から６％へと、さほど急激でない１６％の幅で減少しており、６０分平均着信率Ｎは、５０％から２７％へと、１０分平均以上の幅で減少している。これは、Ｎｏ．１０の時間帯で、リダイヤル客が登場したのではなく、稼電してきた顧客の数が増加し、見せかけでなく真性に混雑度が高まったものと考えられる。しかも１０分平均値で見ても６０分平均値で見ても、６％と２７％と非常に低い着信率となっており、非常に混雑度が高く多くの稼電が溢れている状態と考えられる。従ってこのような場合、項目Ｐの着信優先指示は、「注意」が出力される。
【００６９】
次に、図５の例において、時間帯Ｎｏ．１０とＮｏ．１１とを比較すると、１０分平均着信率値Ｋは、６％から９％へと、若干持ち直して上昇しているが、相変わらずその値自体は低く、６０分平均着信率Ｎで見てみると、２７％から２２％へと、引き続き減少している。これは、リダイヤル客が登場したのではなく、いまだに真性の混雑度が非常に高く、多くの稼電が溢れている状態だと推察される。従ってこのような場合、項目Ｐの着信優先指示は、引き続き「注意」が出力される。このような状態がさらに連続する場合や、さらに真性の混雑度が高まり、より多くの稼電が溢れてしまっていると推察される場合は、項目Ｐの着信優先指示を、「注意」から「警告」などに高めることが望ましい。
【００７０】
次に、図５の例において、時間帯Ｎｏ．１１とＮｏ．１２とを比較すると、１０分平均着信率値Ｋは、９％から６７％へと、急激に上昇しているが、６０分平均着信率Ｎで見てみると、２２％から３２％へと、１０分平均と比較すると小さな幅で上昇している。これは、おそらく時間帯Ｎｏ．１２においてリダイヤル客がいなくなったことを示している。したがって、このような場合は、１０分平均着信率Ｋのような短い時間にわたる着信率平均値を主な評価基準とし、その結果、項目Ｐの着信優先指示は「ＯＫ」に戻すこととする。このとき、仮に、６０分平均着信率Ｎの値で見てしまうと、３２％と相変わらず非常に高い混雑度であり、多くの稼電が溢れているようにも見受けられるが、この場合は、１０分平均着信率Ｋの急激な上昇が、リダイヤル客の減少を表しているものと考えられ、リダイヤル客が一人でも減少することは、実質の混雑度を急激に低下させるということがわかっているからである。
【００７１】
このように、着信率に代えて、着信率移動平均値を用いて混雑度の判定を行うようにすることによって、リダイヤル客の存在などによる、いわば「見せかけ」の、混雑度やビジー率の激しい上下を、正確に評価し、実質の混雑度の上下を正確に推定することができ、非常に有利となる。すなわち、単純に着信率単位時間における着信率を算出しただけでは、リダイヤル客が登場した時点で急激にビジー率が上昇し、あたかも稼電を行っている顧客が急に増加することによって混雑度が高まったように見えてしまい、逆に、リダイヤル客がいなくなると急激にビジー率が低下し、稼電を行っている顧客が急に減少することによって混雑度が低くなったように見えてしまうのであるが、複数の着信率単位時間にわたる移動平均である着信率移動平均値を適宜用いることによって、リダイヤル客の影響が適切に除去され、「見せかけ」の混雑度でなく、実質の混雑度を判定することができるのである。
【００７２】
なお、これまで示した前記システム１００における各機能部１５０〜１６０は、ハードウェアとして実現してもよいし、メモリ１０３やＨＤＤ（Hard Disk Drive）などの適宜な記憶装置に格納したプログラム１０２として実現するとしてもよい。この場合、前記システム１００のＣＰＵ１０４が、プログラム１０２実行に合わせて記憶装置より該当プログラムをメモリ１０３に読み出して、これを実行することとなる。
【００７３】
−−−データベース構造−−−
次に、本実施形態のシステム１００が利用する、運用管理データベース１２５、回線管理データベース１２６、ＰＢＸ管理データベース１２７の各データ構造について説明する。なお、図２に示したような、運用管理データベース１２５の最大抽出回線利用状況データの構造例、および、図３に示したような、運用管理データベース１２５の最小抽出回線利用状況データの構造例については、すでに説明したので省略する。また、図４に示したような、運用管理データベース１２５の混雑度基準データの構造例、および、図５に示したような、着信率移動平均値を用いた場合の着信率データの構造例についても、すでに説明したので省略する。
【００７４】
図６は、本実施形態における回線管理データベース１２６のデータ構造例１、２を示す図である。データ構造例１は、プロジェクト別回線状況情報のデータ構造例、データ構造例２は、電話回線別回線状況情報のデータ構造例である。図６に示すように、回線管理データベース１２６は、混雑度判定部１５４が、運用管理データベース１２５から読み出した前記各プロジェクトの着信率データを、前記メモリ装置から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データとして格納するデータベースである。
【００７５】
プロジェクト別回線状況情報１は、例えば、プロジェクトのＩＤに、各プロジェクトの代表番号、各プロジェクトが属するコールセンター名、各プロジェクトが使用する電話回線数、各プロジェクトの混雑度、転送先電話番号といった情報を対応付けたレコードの集合体となっている。電話回線数における「基本回線」とは、元々当プロジェクトに割り当てられていた電話回線であり、「借用」とは他のプロジェクトから融通された電話回線である。電話回線別回線状況情報２は、プロジェクトのＩＤ、各プロジェクトの代表番号、各プロジェクトが属するコールセンター名、各電話回線（実回線）の電話番号、回線状況、回線借用先、各プロジェクトの混雑度、転送先電話番号といった情報を対応付けたレコードの集合体となっている。回線状況における「基本回線」および「借用」とは、上記プロジェクト別回線状況情報１と同様である。ＩＤ００３の２つの電話回線は、予備用、すなわちバッファ用に契約された電話回線Ｂ（図１参照）を示す。
【００７６】
図７は、本実施形態におけるＰＢＸ管理データベース１２７のデータ構造例１、２を示す図である。データ構造例３は、通信処理情報テーブルのデータ構造例、データ構造例４は、運用管理情報テーブルのデータ構造例である。図７に示すように、ＰＢＸ管理データベース１２７は、ＰＢＸの動作を管理するための情報を格納するデータベースである。
【００７７】
通信処理情報テーブル３は、例えば、処理ＩＤに、ＰＢＸ入力端子Ｎｏ．、状態変化時間、接続先、変化後の状態といった情報を対応付けたレコードの集合体となっている。電話回線数における「基本回線」とは、元々当プロジェクトに割り当てられていた電話回線であり、「借用」とは他のプロジェクトから融通された電話回線である。運用管理情報テーブル４は、混雑度の高さによって決定される処理モードのＩＤ、処理モード、処理実行プログラムといった情報を対応付けたレコードの集合体となっている。各処理モードの詳細については、後述する処理フロー例で説明する。処理実行設定における、「受け入れ要請プログラム」とは、他のプロジェクトに対し、電話回線の融通を依頼するプログラムであって、上記の回線融通依頼部１５５の機能に相当するプログラムである。「着信優先プログラム」は、上記着信優先指示出力部１５７などの機能に相当するプログラムである。「コールバックプログラム」とは、上記コールバックスタンバイ自動実行部１５９や稼電ブロック部１６０などの機能に相当するプログラムである。
【００７８】
−−−処理フロー例−−−
以下、本実施形態におけるコールセンター管理方法に対応する処理フロー例について、図に基づき説明する。なお、以下で説明するコールセンター管理方法に対応する各種動作は、前記システム１００が、適宜なメモリ１０３に読み出して実行するプログラム１０２によって実現される。そして、こうしたプログラム１０２は、以下に説明される各種の動作を行うためのコードからそれぞれ構成されている。なお、以下の処理フロー例では、コールセンター６００のプロジェクトと互いに空き電話回線を融通しあうプロジェクトは、他のコールセンターにおいて遂行されているものとし、従ってコールセンター６００と他のコールセンターとの間で空き電話回線の融通依頼、および／または融通が実行されることとする。
【００７９】
−−−処理フロー例１−−−
図８は、本実施形態のコールセンター管理方法の実施手順例１を示すフロー図である。ここではまず、コールセンター管理システム１００における初期設定について説明する。
【００８０】
まず、システム１００の混雑度基準受信部１５１は、各プロジェクトごとに定められる、稼電の混雑度を示す基準である混雑度基準データを、入力インターフェース１０５から受け付け、メモリ装置、本実施形態では具体的には、前記運用管理データベース１２５に格納する（ｓ１００）。
【００８１】
次に、システム１００の回線利用状況データ受信部１５２は、プロジェクトごとの回線利用状況データを、キャリア事業者Ａのシステム２００から受信し、運用管理データベース１２５に格納する（ｓ１０２、ｓ１０４）。キャリア事業者Ａの各種管理システム２００は、具体的には、上記最大抽出回線利用状況データの抽出依頼をシステム１００から受信し、これに基づいて、キャリア局Ａの回線接続履歴データベース２０２からこれを抽出し、システム１００に向けて送信する（ｓ１０４）。
【００８２】
次に、システム１００の着信率算出部１５３は、前記運用管理データベース１２５から読み出した、各プロジェクトの回線利用状況データから、各プロジェクトの電話番号への稼電が当該コールセンターに接続された、単位時間（着信率単位時間）ごとの割合を示す着信率を算出し、着信率データとして前記運用管理データベース１２５に格納する（ｓ１０６）。
【００８３】
具体的には、着信率算出部１５３は、まず前記運用管理データベース１２５から前記最大抽出回線利用状況データを読み出し、当該最大抽出回線利用状況データから前記最小抽出回線利用状況データを抽出し、前記運用管理データベース１２５に格納する。また、その際、上記変形例のように着信率移動平均値を用いて混雑度の判定を行う場合は、総発呼累計および完了呼数累計の各データを算出し、最小抽出回線利用状況データの一部として格納する。次に、着信率算出部１５３は、最小抽出回線利用状況データから必要なデータを読み出し、着信率を算出し、着信率データとして前記運用管理データベース１２５に格納する。
【００８４】
次に、システム１００の混雑度判定部１５４は、前記運用管理データベース１２５から読み出した前記各プロジェクトの着信率データを、前記メモリ装置である運用管理データベース１２５から読み出した前記混雑度基準データと比較し、各プロジェクトごとの混雑度を判定し、その結果を混雑状況データ（図６参照）として、各プロジェクトに対応付けて回線管理データベース１２６に格納する（ｓ１０８）。
【００８５】
本初期設定のフローにより、図６に示すように、当該コールセンター６００において遂行されている各プロジェクトの現在の混雑度が判定された。以上により、本フローの処理を終了する。
【００８６】
−−−処理フロー例２−−−
図９は、本実施形態のコールセンター管理方法の実施手順例２を示すフロー図である。ここでは、処理フロー例１で判定された混雑度に従い、各プロジェクトをそれぞれの混雑度に該当する処理モードへと分岐させる処理について説明する。
【００８７】
まず、システム１００のプログラム１０２は、処理フロー例１のステップｓ１０８で回線管理データベース１２６に格納された混雑状況データを読み出し（ｓ２００）、次に、各プロジェクトの混雑度に応じ、それぞれ処理フロー例３〜７の処理へと分岐させる（ｓ２０２）。
【００８８】
本実施形態では、プロジェクトの混雑度に応じ、図７の運用管理テーブル４に示した処理モードの中から、何れか一つあるいは複数の処理モードに対応する一連の処理が、自動的に選択されるように分岐される。しかしながら、これら処理モードの選択は、コールセンター管理者などが、手動的にも追加、および／または変更できるようにすれば好ましい。そのような、混雑度と処理モードの対応の一例を示した表を、図１０に示す。
【００８９】
図１０の各処理モードにおいて、「受け入れ要請」とは、システム１００が、他のプロジェクトに対し、電話回線の融通を依頼する処理モードである。「着信優先」とは、オペレータが、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末６０４Ｃ〜６０６Ｃを介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する、上記「着信優先モード」の応対を行う処理モードである。「現状維持」とは、通常のコールセンター運用を維持する処理モードである。「その他処理」とは、例えば、オペレータや管理者が、電子メールへの対応や、他のプロジェクトや他のコールセンタのプロジェクトの処理を代行するなど、他の処理モード以外の様々な処理を行うための処理モードである。「受け入れ許可」とは、当該プロジェクトに空き回線が存在する（「溢れ状態」以外の混雑度である）ため、他のプロジェクトや他のコールセンターのプロジェクトからの融通依頼に応えて、当該空き回線の融通許可情報を当該他のプロジェクトや他のコールセンターに対し通知する処理モードである。「コールバック」とは、比較的混雑度が低く、手すきのオペレータが存在するため、それらのオペレータに、コールバック業務を実行させるための処理モードである。
【００９０】
図１０の表における、「手動変更可」の部分は、コールセンター管理者などの判断により、手動的に実行可能な処理モードである。これら手動的に実行可能な処理モードを実行させるには、具体的には、管理者などが、それぞれの手動的処理モード実行指示を、管理者端末６０３Ｃやシステム１００の入力インターフェース１０５などから入力することにより、システム１００に実行させることとすればよい。
【００９１】
以上により、本フローの処理を終了する。
【００９２】
−−−処理フロー例３−−−
図１１は、本実施形態のコールセンター管理方法の実施手順例３を示すフロー図である。ここでは、処理フロー例２で、混雑度が「溢れ状態」のプロジェクトの場合に分岐された処理について説明する。この場合、システム１００は、図１０に示すように、受け入れ要請および着信優先を中心とした処理を実行する。
【００９３】
まず、システム１００の着信優先指示出力部１５７は、前記混雑度判定部１５４において前記回線管理データベース１２６に格納された、各プロジェクトごとの混雑状況データを読み出し、混雑度が高いと判定されるプロジェクトについて、当該プロジェクトに属するオペレータの端末６０４Ｃ〜６０６Ｃに、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末を介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する応対を繰り返すよう促す、着信優先指示を出力する（ｓ３００）。これにより、当プロジェクトのオペレータは、着信優先モードの対応に切り替える。
【００９４】
次に、本実施形態では、着信優先指示出力部１５７は、管理者端末６０３Ｃにも着信優先モードに切り替える旨を通知する（ｓ３０２）。これにより管理者も、オペレータの対応が着信優先モードに切り替わることを把握できる。また、管理者の端末６０３Ｃへは、着信優先モードの通知のみならず、上記着信率やビジー率などの数値も出力することとすれば好ましい。そのようにすれば、例えば、当該プロジェクトの混雑度が高まりそうな状況をあらかじめ予測し、前もってバッファ回線Ｂの導入や他のコールセンターへの空き回線融通依頼などを手動的に行うなど、溢れ状態未然防止などを図ることなどが可能となるからである。
【００９５】
次に、システム１００のプログラム１０２では、当プロジェクトに割り当てられている空き状態のバッファ回線Ｂがあるか否かを判別し（ｓ３０４）ある場合（ｓ３０４：ＹＥＳ）には、当該バッファ回線を使用できるよう変更を依頼すべく、回線変更の登録要請をキャリア局Ａの各種管理システム２００に送信する（ｓ３０６）。キャリア局Ａの各種管理システム２００では、当該回線変更の登録要請を受信し、バッファ回線Ｂを使用できるよう変更処理する（ｓ３０８）。なお、本実施形態では、ステップｓ３０６およびステップｓ３０８により、回線変更の登録が実行された場合には、システム１００のプログラム１０２によって、回線管理データベース１２６に格納された、プロジェクト別回線状況情報の「回線数」および電話回線別回線状況情報（図６参照）の「回線状況」の各データを更新することとする。
【００９６】
ステップｓ３０４で、当プロジェクトに割り当てられている空き状態のバッファ回線Ｂがない場合（ｓ３０４：ＮＯ）には（またはバッファ回線Ｂを導入してもまだ溢れ状態であるような場合には）、他のコールセンターに受け入れ要請、すなわち回線融通依頼を送信する（ｓ３１０）。具体的には、回線融通依頼部１５５が、回線融通依頼情報を生成し、メモリ１０３に格納するとともに、他のコールセンターのコールセンター管理システムへと送信する。
【００９７】
他のコールセンターのコールセンター管理システムでは、ステップｓ３１０で送信された回線融通依頼情報を受信し（ｓ３１２）、受入要請が受入可能かどうか、すなわち融通可能な空き回線が存在するか否かを判断し（ｓ３１４）、融通可能である場合（ｓ３１４：ＹＥＳ）は、融通可能である旨の通知をシステム１００へと送信する（ｓ３１６）。ステップｓ３１４で、融通不可能であると判断された場合（ｓ３１４：ＮＯ）は、融通不可能である旨の通知をシステム１００へと送信する（ｓ３１８）。
【００９８】
システム１００ではこれらの通知を他のコールセンターのコールセンター管理システムから受信し、融通可能な回線があるか否かを判断し（ｓ３２０）、融通可能である場合、すなわち前記回線融通依頼が受け入れ可能である場合（ｓ３２０：ＹＥＳ）には、当該他のコールセンターに属する他のプロジェクトが保有する空き電話回線を、混雑度が高いと判定された当該プロジェクトに融通する処理を実行する。具体的には、上記ステップｓ３０６の回線変更登録要請処理を実行する。このとき、キャリア局Ａの各種管理システム２００では、当該回線変更の登録要請を受信し、該他のコールセンターに属する他のプロジェクトが保有する空き電話回線を使用できるよう変更処理する（ｓ３０８）。
【００９９】
ステップｓ３２０で、融通可能でない場合、すなわち前記回線融通依頼が受け入れ不能である場合（ｓ３２０：ＮＯ）には、システム１００の処理を終了するが、この場合には、コールセンター６００の管理者などが、混雑度を減少させ着信率を高めるべく、コールセンター６００内でとりうる様々な対策を講ずることとなる。
【０１００】
以上により、本フローの処理を終了する。
【０１０１】
−−−処理フロー例４−−−
図１２は、本実施形態のコールセンター管理方法の実施手順例４を示すフロー図である。ここでは、処理フロー例２で、混雑度が「高負荷」のプロジェクトの場合に分岐された処理について説明する。この場合、システム１００は、図１０に示すように、着信優先および受け入れ許可を中心とした処理を実行する。
【０１０２】
まず、システム１００の着信優先指示出力部１５７は、前記混雑度判定部１５４において前記回線管理データベース１２６に格納された、各プロジェクトごとの混雑状況データを読み出し、混雑度が高いと判定されるプロジェクトについて、当該プロジェクトに属するオペレータの端末６０４Ｃ〜６０６Ｃに、通話相手たる顧客から当該顧客の電話番号を取得しオペレータ端末を介して入力した上で、後ほどコールバックする旨を告げてただちに通話を終了する応対を繰り返すよう促す、着信優先指示を出力する（ｓ４００）。これにより、当プロジェクトのオペレータは、着信優先モードの対応に切り替える。
【０１０３】
次に、本実施形態では、着信優先指示出力部１５７は、管理者端末６０３Ｃにも着信優先モードに切り替える旨を通知する（ｓ４０２）。これにより管理者も、オペレータの対応が着信優先モードに切り替わることを把握できる。また、管理者の端末６０３Ｃへは、着信優先モードの通知のみならず、上記着信率やビジー率などの数値も出力することとすれば好ましい。そのようにすれば、例えば、当該プロジェクトの混雑度が高まりそうな状況をあらかじめ予測し、前もってバッファ回線Ｂの導入や他のコールセンターへの空き回線融通依頼などを手動的に行うなど、溢れ状態未然防止などを図ることなどが可能となるからである。
【０１０４】
次に、システム１００のプログラム１０２は、混雑度が高い他のコールセンターのコールセンター管理システムから送信された（ｓ４０４）回線融通依頼情報を受信し、これに応えて融通可能である旨の通知を他のコールセンターのコールセンター管理システムへと送信する（ｓ４０６）。
【０１０５】
以上により、本フローの処理を終了するが、本処理フロー例のように混雑度が「高負荷」の場合は、「溢れ状態」となることを防ぐため、コールセンター６００の管理者などの判断により、手動的にバッファ回線Ｂの使用や、他のコールセンターへの、空き回線の融通依頼などを行ってもよい。
【０１０６】
−−−処理フロー例５−−−
図１３は、本実施形態のコールセンター管理方法の実施手順例５を示すフロー図である。ここでは、処理フロー例２で、混雑度が「通常」のプロジェクトの場合に分岐された処理について説明する。この場合、システム１００は、図１０に示すように、現状維持、受け入れ許可、およびコールバックを中心とした処理を実行する。現状維持の処理とは、通常のコールセンター処理を維持するだけである。
【０１０７】
まず、システム１００のプログラム１０２は、混雑度が高い他のコールセンターのコールセンター管理システムから送信された（ｓ５００）回線融通依頼情報を受信し、これに応えて融通可能である旨の通知を他のコールセンターのコールセンター管理システムへと送信する（ｓ５０２）。
【０１０８】
次に、システム１００のコールバックスタンバイ自動実行部１５９は、前記運用管理データベース１２５から、稼電した顧客からコールバックする予定で前記オペレータや自動応答装置６０２が聴取した電話番号を読み出し、当該電話番号を、オペレータによるコールバック処理実行に備えて当該オペレータの端末６０４Ｃ〜６０６Ｃに出力する（ｓ５０４）。ここで、必ずしも全てのオペレータに対し、コールバックスタンバイを実行する必要はなく、例えば手すきのオペレータのみを対象とすればよい。
【０１０９】
次に、システム１００の稼電ブロック部１６０は、前記コールバックのための電話番号が、前記オペレータの端末６０４Ｃ〜６０６Ｃにコールバック処理実行に備えて出力されている、コールバックスタンバイ状態において、外部の顧客からの稼電が当該オペレータに接続されてしまうことを防止する処理を実行する（ｓ５０６）。ここではステップｓ５０４で、コールバックスタンバイの対象とされたオペレータの端末に対し、稼電ブロック処理を実行すればよい。
【０１１０】
以上により、本フローの処理を終了する。
【０１１１】
−−−処理フロー例６−−−
図１４は、本実施形態のコールセンター管理方法の実施手順例６を示すフロー図である。ここでは、処理フロー例２で、混雑度が「軽負荷」のプロジェクトの場合に分岐された処理について説明する。この場合、システム１００は、図１０に示すように、その他処理、受け入れ許可、およびコールバックを中心とした処理を実行する。
【０１１２】
まず、システム１００のプログラム１０２は、上記各種のその他処理を実行する（ｓ６００）。  
次に、システム１００のプログラム１０２は、混雑度が高い他のコールセンターのコールセンター管理システムから送信された（ｓ６０２）回線融通依頼情報を受信し、これに応えて融通可能である旨の通知を他のコールセンターのコールセンター管理システムへと送信する（ｓ６０４）。
【０１１３】
次に、システム１００のコールバックスタンバイ自動実行部１５９は、前記運用管理データベース１２５から、稼電した顧客からコールバックする予定で前記オペレータや自動応答装置６０２が聴取した電話番号を読み出し、当該電話番号を、オペレータによるコールバック処理実行に備えて当該オペレータの端末６０４Ｃ〜６０６Ｃに出力する（ｓ６０６）。ここで、必ずしも全てのオペレータに対し、コールバックスタンバイを実行する必要はなく、例えば手すきのオペレータのみを対象とすればよい。
【０１１４】
次に、システム１００の稼電ブロック部１６０は、前記コールバックのための電話番号が、前記オペレータの端末６０４Ｃ〜６０６Ｃにコールバック処理実行に備えて出力されている、コールバックスタンバイ状態において、外部の顧客からの稼電が当該オペレータに接続されてしまうことを防止する処理を実行する（ｓ６０８）。ここではステップｓ５０４で、コールバックスタンバイの対象とされたオペレータの端末に対し、稼電ブロック処理を実行すればよい。
【０１１５】
以上により、本フローの処理を終了する。
【０１１６】
−−−処理フロー例７−−−
図１５は、本実施形態のコールセンター管理方法の実施手順例７を示すフロー図である。ここでは、処理フロー例２で、混雑度が「空き状態」のプロジェクトの場合に分岐された処理について説明する。この場合、システム１００は、図１０に示すように、受け入れ許可、およびコールバックを中心とした処理を実行する。
【０１１７】
まず、システム１００のプログラム１０２は、混雑度が高い他のコールセンターのコールセンター管理システムから送信された（ｓ７００）回線融通依頼情報を受信し、これに応えて融通可能である旨の通知を他のコールセンターのコールセンター管理システムへと送信する（ｓ７０２）。
【０１１８】
次に、システム１００のコールバックスタンバイ自動実行部１５９は、前記運用管理データベース１２５から、稼電した顧客からコールバックする予定で前記オペレータや自動応答装置６０２が聴取した電話番号を読み出し、当該電話番号を、オペレータによるコールバック処理実行に備えて当該オペレータの端末６０４Ｃ〜６０６Ｃに出力する（ｓ７０４）。ここで、必ずしも全てのオペレータに対し、コールバックスタンバイを実行する必要はなく、例えば手すきのオペレータのみを対象とすればよい。
【０１１９】
次に、システム１００の稼電ブロック部１６０は、前記コールバックのための電話番号が、前記オペレータの端末６０４Ｃ〜６０６Ｃにコールバック処理実行に備えて出力されている、コールバックスタンバイ状態において、外部の顧客からの稼電が当該オペレータに接続されてしまうことを防止する処理を実行する（ｓ７０６）。ここではステップｓ５０４で、コールバックスタンバイの対象とされたオペレータの端末に対し、稼電ブロック処理を実行すればよい。以上により、本フローの処理を終了する。
【０１２０】
以上、本実施形態によれば、コールセンター６００や他のコールセンターにおける各プロジェクトごとの電話回線への負荷状況、すなわち稼電の混雑度を見ながら、当該コールセンター６００や他のコールセンターにおける各プロジェクト間で、電話回線を動的に融通しあうことが可能となる。
【０１２１】
以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【図面の簡単な説明】
【０１２２】
【図１】本実施形態のコールセンター管理システムを含むネットワーク構成図である。
【図２】本実施形態における運用管理データベースの最大抽出回線利用状況データの構造例を示す図である。
【図３】本実施形態における運用管理データベースの最小抽出回線利用状況データの構造例を示す図である。
【図４】本実施形態における運用管理データベースの混雑度基準データの構造例を示す図である。
【図５】本実施形態における運用管理データベースの、着信率移動平均値を用いた場合の着信率データの構造例を示す図である。
【図６】本実施形態における回線管理データベースのデータ構造例１、２を示す図である。
【図７】本実施形態におけるＰＢＸ管理データベースのデータ構造例３、４を示す図である。
【図８】本実施形態のコールセンター管理方法に対応する処理フロー例１を示す図である。
【図９】本実施形態のコールセンター管理方法に対応する処理フロー例２を示す図である。
【図１０】本実施形態のコールセンター管理方法に対応する処理フロー例２における、混雑度と処理モードの対応を示す表である。
【図１１】本実施形態のコールセンター管理方法に対応する処理フロー例３を示す図である。
【図１２】本実施形態のコールセンター管理方法に対応する処理フロー例４を示す図である。
【図１３】本実施形態のコールセンター管理方法に対応する処理フロー例５を示す図である。
【図１４】本実施形態のコールセンター管理方法に対応する処理フロー例６を示す図である。
【図１５】本実施形態のコールセンター管理方法に対応する処理フロー例７を示す図である。
【符号の説明】
【０１２３】
１００  コールセンター管理システム
１０１  記憶装置（ハードディスクドライブ）
１０２  プログラム
１０３  メモリ
１０４  ＣＰＵ
１０５  入力インターフェイス
１０６  出力インターフェイス
１０７  通信装置
１０８  Ｉ／Ｏ部
１２５  運用管理データベース
１２６  回線管理データベース
１２７  ＰＢＸ管理データベース
１５０  ＰＢＸ管理部
１５１  混雑度基準受信部
１５２  回線利用状況データ受信部
１５３  着信率算出部
１５４  混雑度判定部
１５５  回線融通依頼部
１５６  回線融通処理実行部
１５７  着信優先支持出力部
１５８  顧客情報登録部
１５９  コールバックスタンバイ自動実効部
１６０  稼電ブロック部
２００、３００、４００  各種管理システム
２０１、３０１、４０１  局内交換機
２０２、３０２、４０２  回線接続履歴データベース
５００  ＷＡＮ
６００  コールセンター
６０１  ＰＢＸ
６０２  自動応答装置
６０３Ｃ  管理者端末
６０３Ｐ  管理者電話機
６０４Ｃ、６０５Ｃ、６０６Ｃ  オペレータ端末
６０４Ｐ、６０５Ｐ、６０６Ｐ  オペレータ電話機
Ｔ１、Ｔ２  電話回線
Ｂ  バッファ用電話回線
【図１】
2008312044.tif 000004
【図２】
2008312044.tif 000005
【図３】
2008312044.tif 000006
【図４】
2008312044.tif 000007
【図５】
2008312044.tif 000008
【図６】
2008312044.tif 000009
【図７】
2008312044.tif 000010
【図８】
2008312044.tif 000011
【図９】
2008312044.tif 000012
【図１０】
2008312044.tif 000013
【図１１】
2008312044.tif 000014
【図１２】
2008312044.tif 000015
【図１３】
2008312044.tif 000016
【図１４】
2008312044.tif 000017
【図１５】
2008312044.tif 000018