JP3535068B2 - マルチチャネル処理の制御装置およびマルチチャネル処理の制御方法 - Google Patents
マルチチャネル処理の制御装置およびマルチチャネル処理の制御方法Info
- Publication number
- JP3535068B2 JP3535068B2 JP2000093114A JP2000093114A JP3535068B2 JP 3535068 B2 JP3535068 B2 JP 3535068B2 JP 2000093114 A JP2000093114 A JP 2000093114A JP 2000093114 A JP2000093114 A JP 2000093114A JP 3535068 B2 JP3535068 B2 JP 3535068B2
- Authority
- JP
- Japan
- Prior art keywords
- queue
- processing
- real
- request
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
- H04M3/523—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing with call distribution or queueing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/45—Aspects of automatic or semi-automatic exchanges related to voicemail messaging
- H04M2203/4536—Voicemail combined with text-based messaging
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
- H04M3/5183—Call or contact centers with computer-telephony arrangements
- H04M3/5191—Call or contact centers with computer-telephony arrangements interacting with the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
- H04M3/523—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing with call distribution or queueing
- H04M3/5232—Call distribution algorithms
- H04M3/5235—Dependent on call type or called number [DNIS]
Landscapes
- Business, Economics & Management (AREA)
- Marketing (AREA)
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Description
【０００１】
【発明の属する技術分野】本発明は、公衆回線からの着
呼に基づく処理要求やインターネット・ウェブサーバ、
E-mailサーバなどで発生した処理要求などの複数のチャ
ネルからの処理要求を最適な処理端末に振り分けるため
のマルチチャネル処理の制御装置およびマルチチャネル
処理の制御方法に関する。
呼に基づく処理要求やインターネット・ウェブサーバ、
E-mailサーバなどで発生した処理要求などの複数のチャ
ネルからの処理要求を最適な処理端末に振り分けるため
のマルチチャネル処理の制御装置およびマルチチャネル
処理の制御方法に関する。
【０００２】
【従来の技術】コールセンタでは、公衆回線からの着呼
に対する電話による顧客対応が中心であり、複数のオペ
レータが着呼に対応するために電話機の前で待機してい
る場合が一般的である。公衆回線からの着呼以外のチャ
ネルとしては、ＦＡＸの送受信やダイレクトメールの送
信など、既存のメディアを応用したものであって、各オ
ペレータにこれらの業務を兼務させることが考えられ
る。
に対する電話による顧客対応が中心であり、複数のオペ
レータが着呼に対応するために電話機の前で待機してい
る場合が一般的である。公衆回線からの着呼以外のチャ
ネルとしては、ＦＡＸの送受信やダイレクトメールの送
信など、既存のメディアを応用したものであって、各オ
ペレータにこれらの業務を兼務させることが考えられ
る。
【０００３】このような電話業務が中心のコールセンタ
では、着呼に対するチャネル制御は、ＰＢＸ（構内交換
機）に頼っており、ＡＣＤ（Automatic Call Distribut
or：自動呼分配装置）システムを活用した構成が一般的
である。
では、着呼に対するチャネル制御は、ＰＢＸ（構内交換
機）に頼っており、ＡＣＤ（Automatic Call Distribut
or：自動呼分配装置）システムを活用した構成が一般的
である。
【０００４】
【発明が解決しようとする課題】近年のインターネット
を中心としたＩＴ技術の進歩により、ＷＷＷ（World Wi
de Web）やE-mailなどを利用した新しいチャネルが顧客
に開かれている。このようなインターネット・ウェブサ
ーバやE-mailサーバを利用した顧客からのアクセスは、
携帯電話や携帯情報端末などの活用によってさらに増加
するものと考えられ、これに対して新たなサービス提供
手段を確立し、目的に応じて各チャネルをうまく融合さ
せて効率的な運用を実現することが要求されている。ま
た、今後も新たな顧客チャネルが確立されることが予測
されるため、このような新たなチャネルへの拡張に対し
て柔軟に対応できることが要求されている。
を中心としたＩＴ技術の進歩により、ＷＷＷ（World Wi
de Web）やE-mailなどを利用した新しいチャネルが顧客
に開かれている。このようなインターネット・ウェブサ
ーバやE-mailサーバを利用した顧客からのアクセスは、
携帯電話や携帯情報端末などの活用によってさらに増加
するものと考えられ、これに対して新たなサービス提供
手段を確立し、目的に応じて各チャネルをうまく融合さ
せて効率的な運用を実現することが要求されている。ま
た、今後も新たな顧客チャネルが確立されることが予測
されるため、このような新たなチャネルへの拡張に対し
て柔軟に対応できることが要求されている。
【０００５】コールセンタシステムにおいて、このよう
な新たなチャネルに対応させるためには、従来のコール
センタにVoIP（Voice Over IP：インターネット電話）
やインターネット・ウェブ、E-mail、携帯端末などと融
合した機能を持たせることが必要となってくる。しかし
ながら、各チャネルにおける特性がそれぞれ異なってお
り、かつ提供するサービスによっても制御方式が異なっ
てくる。
な新たなチャネルに対応させるためには、従来のコール
センタにVoIP（Voice Over IP：インターネット電話）
やインターネット・ウェブ、E-mail、携帯端末などと融
合した機能を持たせることが必要となってくる。しかし
ながら、各チャネルにおける特性がそれぞれ異なってお
り、かつ提供するサービスによっても制御方式が異なっ
てくる。
【０００６】本発明は、チャネルやサービスの特性に応
じて顧客サービスの充実とその運用を効率的に行い、将
来の拡張に備えて構成の変更にも柔軟に対応可能なマル
チチャネル処理の制御装置およびマルチチャネル処理の
制御方法を提案する。
じて顧客サービスの充実とその運用を効率的に行い、将
来の拡張に備えて構成の変更にも柔軟に対応可能なマル
チチャネル処理の制御装置およびマルチチャネル処理の
制御方法を提案する。
【０００７】
【課題を解決するための手段】本発明に係るマルチチャ
ネル処理の制御装置は、顧客とコールセンタとの通信を
行う際の通信手段としての複数のチャネルからの処理要
求を受け付け、処理要求を発生したチャネルの属性を示
すチャネル種別および処理要求の属性を示すキュー区分
に基づいて、リアルタイムで処理する必要のあるリアル
タイム処理要求であるか、必ずしもリアルタイムで処理
する必要のない非リアルタイム処理要求であるかを判別
する処理要求判別手段と、非リアルタイム処理要求であ
ると判別された処理要求のうち、処理対象である顧客に
関するデータが所定の顧客データであるような処理要求
をリアルタイム処理要求に変更し、その他の非リアルタ
イム処理要求についてはその優先順位とともに管理する
非リアルタイム処理管理手段と、リアルタイム処理要求
であると判別された処理要求を、そのリアルタイム処理
が可能なチャネルのうち現在空き状態である処理端末に
割り当てるリアルタイム処理割当手段と、非リアルタイ
ム処理管理手段が管理する非リアルタイム処理をその優
先順位とその処理に対する各処理端末の適格性を考慮し
て各処理端末のいずれかに割り当てる非リアルタイム処
理割当手段とを備える。
ネル処理の制御装置は、顧客とコールセンタとの通信を
行う際の通信手段としての複数のチャネルからの処理要
求を受け付け、処理要求を発生したチャネルの属性を示
すチャネル種別および処理要求の属性を示すキュー区分
に基づいて、リアルタイムで処理する必要のあるリアル
タイム処理要求であるか、必ずしもリアルタイムで処理
する必要のない非リアルタイム処理要求であるかを判別
する処理要求判別手段と、非リアルタイム処理要求であ
ると判別された処理要求のうち、処理対象である顧客に
関するデータが所定の顧客データであるような処理要求
をリアルタイム処理要求に変更し、その他の非リアルタ
イム処理要求についてはその優先順位とともに管理する
非リアルタイム処理管理手段と、リアルタイム処理要求
であると判別された処理要求を、そのリアルタイム処理
が可能なチャネルのうち現在空き状態である処理端末に
割り当てるリアルタイム処理割当手段と、非リアルタイ
ム処理管理手段が管理する非リアルタイム処理をその優
先順位とその処理に対する各処理端末の適格性を考慮し
て各処理端末のいずれかに割り当てる非リアルタイム処
理割当手段とを備える。
【０００８】本発明に係るマルチチャネル処理の制御方
法は、顧客とコールセンタとの通信を行う際の通信手段
としての複数のチャネルで発生する処理要求を受け付
け、処理要求を発生したチャネルの属性を示すチャネル
種別および処理要求の属性を示すキュー区分に基づい
て、リアルタイムで処理する必要のあるリアルタイム処
理要求であるか、必ずしもリアルタイムで処理する必要
のない非リアルタイム処理要求であるかを判別する段階
と、非リアルタイム処理要求であると判別された処理要
求のうち、処理対象である顧客に関するデータが所定の
顧客データであるような処理要求をリアルタイム処理要
求に変更し、その他の非リアルタイム処理要求について
はその優先順位とともに管理する段階と、処理要求がリ
アルタイム処理要求であると判断した場合に、そのリア
ルタイム処理が可能であるチャネルのうち現在空き状態
である処理端末にその処理要求を割り当てる段階とを備
える。
法は、顧客とコールセンタとの通信を行う際の通信手段
としての複数のチャネルで発生する処理要求を受け付
け、処理要求を発生したチャネルの属性を示すチャネル
種別および処理要求の属性を示すキュー区分に基づい
て、リアルタイムで処理する必要のあるリアルタイム処
理要求であるか、必ずしもリアルタイムで処理する必要
のない非リアルタイム処理要求であるかを判別する段階
と、非リアルタイム処理要求であると判別された処理要
求のうち、処理対象である顧客に関するデータが所定の
顧客データであるような処理要求をリアルタイム処理要
求に変更し、その他の非リアルタイム処理要求について
はその優先順位とともに管理する段階と、処理要求がリ
アルタイム処理要求であると判断した場合に、そのリア
ルタイム処理が可能であるチャネルのうち現在空き状態
である処理端末にその処理要求を割り当てる段階とを備
える。
【０００９】ここで、管理中の非リアルタイム処理要求
を、その優先順位と、その非リアルタイム処理要求を処
理可能なチャネル中の現在空き状態である処理端末の適
格性とに基づいて、最適な処理端末に割り当てる段階を
さらに備える構成とすることができる。
を、その優先順位と、その非リアルタイム処理要求を処
理可能なチャネル中の現在空き状態である処理端末の適
格性とに基づいて、最適な処理端末に割り当てる段階を
さらに備える構成とすることができる。
【００１０】
【００１１】さらに本発明では、顧客とコールセンタと
の通信を行う際の通信手段としての複数のチャネルで発
生する処理要求を受け付け、処理要求を発生したチャネ
ルの属性を示すチャネル種別および処理要求の属性を示
すキュー区分に基づいて、リアルタイムで処理する必要
のあるリアルタイム処理要求であるか、必ずしもリアル
タイムで処理する必要のない非リアルタイム処理要求で
あるかを判別する段階と、非リアルタイム処理要求であ
ると判別された処理要求のうち、処理対象である顧客に
関するデータが所定の顧客データであるような処理要求
をリアルタイム処理要求に変更し、その他の非リアルタ
イム処理要求についてはその優先順位とともに管理する
段階と、処理要求がリアルタイム処理要求であると判断
した場合に、そのリアルタイム処理が可能であるチャネ
ルのうち現在空き状態である処理端末にその処理要求を
割り当てる段階とを備えるマルチチャネル処理の制御方
法をコンピュータに実行させるためのプログラムを記録
したコンピュータ読み取り可能な記録媒体を提案する。
ここで記録媒体とは、コンピュータが読み書き可能なフ
ロッピーディスク、ハードディスク、半導体メモリ、CD
-ROM、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のもの
が想定できる。
の通信を行う際の通信手段としての複数のチャネルで発
生する処理要求を受け付け、処理要求を発生したチャネ
ルの属性を示すチャネル種別および処理要求の属性を示
すキュー区分に基づいて、リアルタイムで処理する必要
のあるリアルタイム処理要求であるか、必ずしもリアル
タイムで処理する必要のない非リアルタイム処理要求で
あるかを判別する段階と、非リアルタイム処理要求であ
ると判別された処理要求のうち、処理対象である顧客に
関するデータが所定の顧客データであるような処理要求
をリアルタイム処理要求に変更し、その他の非リアルタ
イム処理要求についてはその優先順位とともに管理する
段階と、処理要求がリアルタイム処理要求であると判断
した場合に、そのリアルタイム処理が可能であるチャネ
ルのうち現在空き状態である処理端末にその処理要求を
割り当てる段階とを備えるマルチチャネル処理の制御方
法をコンピュータに実行させるためのプログラムを記録
したコンピュータ読み取り可能な記録媒体を提案する。
ここで記録媒体とは、コンピュータが読み書き可能なフ
ロッピーディスク、ハードディスク、半導体メモリ、CD
-ROM、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のもの
が想定できる。
【００１２】
【００１３】
【発明の実施の形態】〔概略構成〕本発明の１実施形態
が採用されるコールセンタの概要構成を図１に示す。こ
こで示すコールセンタでは、公衆回線網に接続されるＰ
ＢＸ（構内交換機）１１と、インターネットに接続され
るWebサーバ１２、E-mailサーバ１３を備えている。Ｐ
ＢＸ１１は、オペレータが操作するオペレータ端末であ
るＲＥＰシステム１４、ＶＲＵ（自動音声応答ユニッ
ト）１５に接続されている。また、Webサーバ１２に
は、Webエージェントシステム１６が接続されており、E
-mailサーバ１３にはE-mailエージェントシステム１７
が接続されている。
が採用されるコールセンタの概要構成を図１に示す。こ
こで示すコールセンタでは、公衆回線網に接続されるＰ
ＢＸ（構内交換機）１１と、インターネットに接続され
るWebサーバ１２、E-mailサーバ１３を備えている。Ｐ
ＢＸ１１は、オペレータが操作するオペレータ端末であ
るＲＥＰシステム１４、ＶＲＵ（自動音声応答ユニッ
ト）１５に接続されている。また、Webサーバ１２に
は、Webエージェントシステム１６が接続されており、E
-mailサーバ１３にはE-mailエージェントシステム１７
が接続されている。
【００１４】ＲＥＰシステム１４、ＶＲＵ１５は公衆回
線網からＰＢＸ１１への着呼に対する一次窓口を提供す
るための装置であり、Webエージェントシステム１６は
インターネットからWebサーバ１２への要求があった場
合の一次窓口を提供するための装置であり、E-mailエー
ジェントシステム１７はインターネットからE-mailサー
バ１３への要求があった場合の一次窓口を提供するため
の装置である。
線網からＰＢＸ１１への着呼に対する一次窓口を提供す
るための装置であり、Webエージェントシステム１６は
インターネットからWebサーバ１２への要求があった場
合の一次窓口を提供するための装置であり、E-mailエー
ジェントシステム１７はインターネットからE-mailサー
バ１３への要求があった場合の一次窓口を提供するため
の装置である。
【００１５】ＲＥＰシステム１４、ＶＲＵ１５、Webエ
ージェントシステム１６、E-mailエージェントシステム
１７は、それぞれＭＣＩＣＤ（Multi-Channel Intellig
entCall Distributor）１８に接続されている。ＭＣＩ
ＣＤ１８は、各チャネルで発生する処理要求を統括的に
管理し、最適な処理端末に処理要求を転送するものであ
る。
ージェントシステム１６、E-mailエージェントシステム
１７は、それぞれＭＣＩＣＤ（Multi-Channel Intellig
entCall Distributor）１８に接続されている。ＭＣＩ
ＣＤ１８は、各チャネルで発生する処理要求を統括的に
管理し、最適な処理端末に処理要求を転送するものであ
る。
【００１６】顧客から発せられる要求は、それぞれのチ
ャネルから非同期でＭＣＩＣＤ１８に通知され、各チャ
ネルにおいて自動応答が可能なものについては自動応答
を行う。各チャネルにおいて自動応答できない要求につ
いては、そのチャネルからＭＣＩＣＤ１８に処理要求が
通知される。ＭＣＩＣＤ１８では、各チャネルからの処
理要求に対して各種条件を考慮し、最終的にはＲＥＰ１
４にこれを転送して処理を行わせる。
ャネルから非同期でＭＣＩＣＤ１８に通知され、各チャ
ネルにおいて自動応答が可能なものについては自動応答
を行う。各チャネルにおいて自動応答できない要求につ
いては、そのチャネルからＭＣＩＣＤ１８に処理要求が
通知される。ＭＣＩＣＤ１８では、各チャネルからの処
理要求に対して各種条件を考慮し、最終的にはＲＥＰ１
４にこれを転送して処理を行わせる。
【００１７】ＲＥＰ１４はオペレータ端末で構成されて
おり、電話による通話処理、E-mail処理などが可能とな
っており、オペレータの操作により各チャネルからの処
理要求を実行することが可能な構成となっている。ＭＣ
ＩＣＤ１８の構成を図２に示す。ＭＣＩＣＤ１８は、Ｒ
ＥＰシステム１４、ＶＲＵ１５、Webエージェントシス
テム１６、E-mailエージェントシステム１７の各チャネ
ル側に位置するＢＣ（Broad Channel）コントローラク
ライアント２１と、各クライアントを統括するＢＣ（Br
oad Channel）コントローラサーバ３１とから構成され
ている。クライアント側には、クライアントアプリケー
ション２２、キューコントロールＤＬＬ２４、イベント
送受信部２５などが設けられており、キューコントロー
ルＤＬＬ２４、イベント送受信部２５によってＢＣコン
トローラクライアント２１が構成されている。
おり、電話による通話処理、E-mail処理などが可能とな
っており、オペレータの操作により各チャネルからの処
理要求を実行することが可能な構成となっている。ＭＣ
ＩＣＤ１８の構成を図２に示す。ＭＣＩＣＤ１８は、Ｒ
ＥＰシステム１４、ＶＲＵ１５、Webエージェントシス
テム１６、E-mailエージェントシステム１７の各チャネ
ル側に位置するＢＣ（Broad Channel）コントローラク
ライアント２１と、各クライアントを統括するＢＣ（Br
oad Channel）コントローラサーバ３１とから構成され
ている。クライアント側には、クライアントアプリケー
ション２２、キューコントロールＤＬＬ２４、イベント
送受信部２５などが設けられており、キューコントロー
ルＤＬＬ２４、イベント送受信部２５によってＢＣコン
トローラクライアント２１が構成されている。
【００１８】イベント送受信部２５は、クライアントア
プリケーション２２内のチャネルコントロール２３を介
して、クライアント側の現在の状態やサーバ側から送信
されるキュー通知の入出力を行う。たとえば、イベント
送受信部２５は、チャネルコントロール２３からクライ
アント側の現在の状態を獲得し、これをサーバ側に送信
する。また、サーバ側から送信されてくるキュー通知を
受信してこれをチャネルコントロール２３に送信する。
プリケーション２２内のチャネルコントロール２３を介
して、クライアント側の現在の状態やサーバ側から送信
されるキュー通知の入出力を行う。たとえば、イベント
送受信部２５は、チャネルコントロール２３からクライ
アント側の現在の状態を獲得し、これをサーバ側に送信
する。また、サーバ側から送信されてくるキュー通知を
受信してこれをチャネルコントロール２３に送信する。
【００１９】また、キューコントロールＤＬＬ２４は、
クライアントアプリケーション２２で発生するキュー登
録要求、キュー取得要求、キュー一覧要求、変更要求、
削除要求などをサーバ側に伝達する。ＢＣコントローラ
サーバ３１側は、キューコントロールＤＬＬ２４から送
信されてくるキュー登録要求を受け付けてこのキューデ
ータを振り分けるディスパッチャ３２と、必ずしもリア
ルタイムでの処理を必要としない非リアルタイム処理要
求（ディレイドキュー）を管理するキューマネージャ３
３と、クライアント側から送信されてくる現在の状態を
管理しこれに基づいてキュー通知またはイベントをクラ
イアント側に送信するBC-BUS３４を備えている。
クライアントアプリケーション２２で発生するキュー登
録要求、キュー取得要求、キュー一覧要求、変更要求、
削除要求などをサーバ側に伝達する。ＢＣコントローラ
サーバ３１側は、キューコントロールＤＬＬ２４から送
信されてくるキュー登録要求を受け付けてこのキューデ
ータを振り分けるディスパッチャ３２と、必ずしもリア
ルタイムでの処理を必要としない非リアルタイム処理要
求（ディレイドキュー）を管理するキューマネージャ３
３と、クライアント側から送信されてくる現在の状態を
管理しこれに基づいてキュー通知またはイベントをクラ
イアント側に送信するBC-BUS３４を備えている。
【００２０】ディスパッチャ３２は、キューコントロー
ルＤＬＬ２４からキュー登録要求があった場合、リアル
タイムでの処理が必要なリアルタイム処理要求である
か、必ずしもリアルタイムでの処理が必要でない非リア
ルタイム処理要求（ディレイドキュー）であるかを判別
する。キュー登録要求がリアルタイム処理要求である場
合には、その処理が可能なチャネルを選択し、BC-BUS３
４が管理する各クライアントの状態に応じて、最適なク
ライアントのイベント送受信部２５にキュー通知を送信
する。また、キュー登録要求が非リアルタイム処理要求
である場合には、このキューデータをディレイドキュー
としてキューマネージャ３３に登録する。
ルＤＬＬ２４からキュー登録要求があった場合、リアル
タイムでの処理が必要なリアルタイム処理要求である
か、必ずしもリアルタイムでの処理が必要でない非リア
ルタイム処理要求（ディレイドキュー）であるかを判別
する。キュー登録要求がリアルタイム処理要求である場
合には、その処理が可能なチャネルを選択し、BC-BUS３
４が管理する各クライアントの状態に応じて、最適なク
ライアントのイベント送受信部２５にキュー通知を送信
する。また、キュー登録要求が非リアルタイム処理要求
である場合には、このキューデータをディレイドキュー
としてキューマネージャ３３に登録する。
【００２１】BC-BUS３４は、クライアント側から送信さ
れてくる現在の状態を管理するとともに、管理している
クライアントの現在の状態に基づいて空き状態のクライ
アントにディスパッチャ３２から送られてくるキュー通
知を送信する。キューマネージャ３３は、ディスパッチ
ャ３２が非リアルタイム処理要求であると判断したキュ
ー登録要求をディレイドキューとしてその優先順位とと
もに登録しこれを管理する。また、キューマネージャ３
３は、たとえば事前に抽出された対象顧客に対してプロ
モーションを行うなどのアウトバウンド業務を１件毎に
ディレイドキューとして登録して管理する。このような
アウトバウンド業務では、クライアント側からのキュー
取得要求に対して、要求内容によって最優先のキューを
選択してクライアント側へ返し、クライアントはその取
得されたキューを処理する。キューマネージャ３３で管
理しているディレイドキューの処理が、クライアント側
で完了してキュー削除要求があれば、対応するディレイ
ドキューを削除し、再電話の必要がある場合には新たに
再電話のキューを登録する。
れてくる現在の状態を管理するとともに、管理している
クライアントの現在の状態に基づいて空き状態のクライ
アントにディスパッチャ３２から送られてくるキュー通
知を送信する。キューマネージャ３３は、ディスパッチ
ャ３２が非リアルタイム処理要求であると判断したキュ
ー登録要求をディレイドキューとしてその優先順位とと
もに登録しこれを管理する。また、キューマネージャ３
３は、たとえば事前に抽出された対象顧客に対してプロ
モーションを行うなどのアウトバウンド業務を１件毎に
ディレイドキューとして登録して管理する。このような
アウトバウンド業務では、クライアント側からのキュー
取得要求に対して、要求内容によって最優先のキューを
選択してクライアント側へ返し、クライアントはその取
得されたキューを処理する。キューマネージャ３３で管
理しているディレイドキューの処理が、クライアント側
で完了してキュー削除要求があれば、対応するディレイ
ドキューを削除し、再電話の必要がある場合には新たに
再電話のキューを登録する。
【００２２】キューマネージャ３３は、管理しているデ
ィレイドキューを監視しており、一定の条件を満たした
ディレイドキューがある場合にその旨をディスパッチャ
３２に通知する。たとえば、登録されてから一定時間を
経過したディレイドキューがある場合、クライアント側
からキュー取得要求があり要求された条件を満たすディ
レイドキュー登録がある場合などには、その条件に合う
キューを選択してクライアントへ返す。また、クライア
ント側からキュー一覧要求、変更要求、削除要求などが
あった場合には、これに対応してディレイドキューデー
タの一覧をクライアント側に送信したり、ディレイドキ
ューデータの変更や削除を行う。
ィレイドキューを監視しており、一定の条件を満たした
ディレイドキューがある場合にその旨をディスパッチャ
３２に通知する。たとえば、登録されてから一定時間を
経過したディレイドキューがある場合、クライアント側
からキュー取得要求があり要求された条件を満たすディ
レイドキュー登録がある場合などには、その条件に合う
キューを選択してクライアントへ返す。また、クライア
ント側からキュー一覧要求、変更要求、削除要求などが
あった場合には、これに対応してディレイドキューデー
タの一覧をクライアント側に送信したり、ディレイドキ
ューデータの変更や削除を行う。
【００２３】〔キュー登録要求〕各チャネルにおいて自
動的に応答することが可能なものについては各チャネル
で処理が実行される。たとえば、公衆回線網を介して着
呼した電話に対しては、ＰＢＸ１１内のＡＣＤシステム
により自動的にＲＥＰ１４またはＶＲＵ１５に振り分け
られ、ＲＥＰ１４を扱っているオペレータによる対応ま
たはＶＲＵ１５による自動応答処理が実行される。オペ
レータやＶＲＵ１５での対応では不十分であるような内
容のものについては、キューコントロールＤＬＬ２４を
介してサーバ側にキュー登録要求を送信する。
動的に応答することが可能なものについては各チャネル
で処理が実行される。たとえば、公衆回線網を介して着
呼した電話に対しては、ＰＢＸ１１内のＡＣＤシステム
により自動的にＲＥＰ１４またはＶＲＵ１５に振り分け
られ、ＲＥＰ１４を扱っているオペレータによる対応ま
たはＶＲＵ１５による自動応答処理が実行される。オペ
レータやＶＲＵ１５での対応では不十分であるような内
容のものについては、キューコントロールＤＬＬ２４を
介してサーバ側にキュー登録要求を送信する。
【００２４】また、Webサーバ１２に対して送信されて
くる問い合わせやE-mailサーバ１３に送信されてくるE-
mailへの対応などについては、Webエージェント１６ま
たはE-mailエージェント１７がそれぞれのキューコント
ロールＤＬＬ２４を介してサーバ側にキュー登録要求を
行う。このように、各チャネルにおいて処理要求が発生
した場合には、図３に示すようなフローチャートに基づ
いて、キュー登録要求処理が実行される。
くる問い合わせやE-mailサーバ１３に送信されてくるE-
mailへの対応などについては、Webエージェント１６ま
たはE-mailエージェント１７がそれぞれのキューコント
ロールＤＬＬ２４を介してサーバ側にキュー登録要求を
行う。このように、各チャネルにおいて処理要求が発生
した場合には、図３に示すようなフローチャートに基づ
いて、キュー登録要求処理が実行される。
【００２５】キューコントロールＤＬＬ２４は、ステッ
プＳ１１において、着信した内容がそのクライアントに
おいて処理できないものであると判断した場合には、Ｍ
ＣＩＣＤサーバ３１のディスパッチャ３２にキュー登録
要求を行う。このとき、キューコントロールＤＬＬ２４
では、着信内容に応じてキューデータを作成してこれを
ディスパッチャ３２に送信する。
プＳ１１において、着信した内容がそのクライアントに
おいて処理できないものであると判断した場合には、Ｍ
ＣＩＣＤサーバ３１のディスパッチャ３２にキュー登録
要求を行う。このとき、キューコントロールＤＬＬ２４
では、着信内容に応じてキューデータを作成してこれを
ディスパッチャ３２に送信する。
【００２６】キューデータは、図１０に示すようなテー
ブルで構成されており、チャネル種別、キュー区分、イ
ンアウト区分、ユーザＩＤ、キャンペーンＩＤ、顧客Ｉ
Ｄ、履歴キー、開始日時、終了日時、キューＩＤ、エリ
アコード、世帯名寄せ番号、個人名寄せ番号などの項目
を備えている。チャネル種別は、たとえば、図１１のチ
ャネル識別一覧に示すように、その値に基づいて、オペ
レータ端末であるＲＥＰ、Webエージェント、E-mailエ
ージェント、顧客へのお勧め商品を選択するＣＲＭ（Cu
stomer Relationship Management）エージェント、オペ
レータの管理者であるスーパーバイザー、アウトバウン
ド業務の対象顧客抽出用のセグメント分析などを備えて
いる。チャネル種別を拡張する必要のある場合には、こ
のチャネル識別一覧を適宜変更することにより対応する
ことが可能である。
ブルで構成されており、チャネル種別、キュー区分、イ
ンアウト区分、ユーザＩＤ、キャンペーンＩＤ、顧客Ｉ
Ｄ、履歴キー、開始日時、終了日時、キューＩＤ、エリ
アコード、世帯名寄せ番号、個人名寄せ番号などの項目
を備えている。チャネル種別は、たとえば、図１１のチ
ャネル識別一覧に示すように、その値に基づいて、オペ
レータ端末であるＲＥＰ、Webエージェント、E-mailエ
ージェント、顧客へのお勧め商品を選択するＣＲＭ（Cu
stomer Relationship Management）エージェント、オペ
レータの管理者であるスーパーバイザー、アウトバウン
ド業務の対象顧客抽出用のセグメント分析などを備えて
いる。チャネル種別を拡張する必要のある場合には、こ
のチャネル識別一覧を適宜変更することにより対応する
ことが可能である。
【００２７】キュー区分は、たとえば、図１２のキュー
区分一覧に示すように、その値に基づいて、顧客との通
話の結果再度電話を行うこととなった有効再電話、顧客
不在または話中による未会話再電話、前回のフォローの
ためのフォロー電話、電話でのアウトバウンド業務であ
るキャンペーン、Webサーバへのコールバック要求であ
るWeb−転送、E-mailへの対応であるE-mail−転送、E-m
ailの個別発信であるE-mail−発信（個別）、ダイレク
トメールのためのE-mail−発信（ＤＭ）、最適なオペレ
ータに電話転送を行う電話−転送などを備えている。こ
のキュー区分についても、チャネル種別の変更やシステ
ムの変更に基づいて適宜変更することが可能である。
区分一覧に示すように、その値に基づいて、顧客との通
話の結果再度電話を行うこととなった有効再電話、顧客
不在または話中による未会話再電話、前回のフォローの
ためのフォロー電話、電話でのアウトバウンド業務であ
るキャンペーン、Webサーバへのコールバック要求であ
るWeb−転送、E-mailへの対応であるE-mail−転送、E-m
ailの個別発信であるE-mail−発信（個別）、ダイレク
トメールのためのE-mail−発信（ＤＭ）、最適なオペレ
ータに電話転送を行う電話−転送などを備えている。こ
のキュー区分についても、チャネル種別の変更やシステ
ムの変更に基づいて適宜変更することが可能である。
【００２８】インアウト区分は、そのキューがインバウ
ンド業務であるかアウトバウンド業務であるかを示すも
のである。ユーザＩＤは、そのキューを扱うべきオペレ
ータまたは端末の識別番号である。キャンペーンＩＤ、
顧客ＩＤは、オペレータが電話を受けた際にオペレータ
端末から入力する顧客データ、Web上で顧客が入力した
ＩＤ番号、E-mail中のメールアドレスなどから特定する
ことができる。また、アウトバウンド業務の場合には、
プロモーションを計画する際に抽出した対象顧客のデー
タが入力されることとなる。
ンド業務であるかアウトバウンド業務であるかを示すも
のである。ユーザＩＤは、そのキューを扱うべきオペレ
ータまたは端末の識別番号である。キャンペーンＩＤ、
顧客ＩＤは、オペレータが電話を受けた際にオペレータ
端末から入力する顧客データ、Web上で顧客が入力した
ＩＤ番号、E-mail中のメールアドレスなどから特定する
ことができる。また、アウトバウンド業務の場合には、
プロモーションを計画する際に抽出した対象顧客のデー
タが入力されることとなる。
【００２９】キューＩＤは、ディスパッチャ３２にキュ
ー登録要求があったときに、ディスパッチャ３２が自動
的に採番するように構成することができる。エリアコー
ドは、顧客毎に設定されるものであって、その顧客の住
所やメールアドレスの種別などにより特定することがで
きる。世帯名寄せ番号は、同一世帯中に同時に要件処理
を行うことが可能な顧客がいる場合に用いられ、個人名
寄せ番号は、個人に対して同時に要件処理が可能なもの
がある場合に用いられる。ステップＳ１１において、キ
ューコントロールＤＬＬ２４からディスパッチャ３２に
送信されるキューデータは、ＲＥＰ１４、ＶＲＵ１５か
ら発生するキュー登録要求である場合には、キュー区分
は「９：電話−転送」であり、Webエージェント１６か
ら発生するキュー登録要求である場合には、そのキュー
区分は「５：Web−転送」であり、E-mailエージェント
１７から発生するキュー登録要求である場合には、その
キュー区分は「６：E-mail−転送」となる。
ー登録要求があったときに、ディスパッチャ３２が自動
的に採番するように構成することができる。エリアコー
ドは、顧客毎に設定されるものであって、その顧客の住
所やメールアドレスの種別などにより特定することがで
きる。世帯名寄せ番号は、同一世帯中に同時に要件処理
を行うことが可能な顧客がいる場合に用いられ、個人名
寄せ番号は、個人に対して同時に要件処理が可能なもの
がある場合に用いられる。ステップＳ１１において、キ
ューコントロールＤＬＬ２４からディスパッチャ３２に
送信されるキューデータは、ＲＥＰ１４、ＶＲＵ１５か
ら発生するキュー登録要求である場合には、キュー区分
は「９：電話−転送」であり、Webエージェント１６か
ら発生するキュー登録要求である場合には、そのキュー
区分は「５：Web−転送」であり、E-mailエージェント
１７から発生するキュー登録要求である場合には、その
キュー区分は「６：E-mail−転送」となる。
【００３０】ステップＳ１２において、ディスパッチャ
３２は送信されてきたキュー登録要求がリアルタイムで
の処理が必要なリアルタイムキューであるか、必ずしも
リアルタイムでの処理が必要ではないディレイドキュー
であるかを判別する。リアルタイムキューであるかディ
レイドキューであるかの判断は、キュー登録要求があっ
たキューデータのキュー区分によって判別することが可
能である。たとえば、図１３に示すように、キュー区分
が、「未会話再電話」「キャンペーン」「E-mail−発信
（ＤＭ）」である場合にはリクエストキュー、「有効再
電話」「フォロー会話」「E-mail−転送」「E-mail−発
信（個別）」である場合にはディレイド通知キュー、
「Web−転送」「電話−転送」である場合にはリアルタ
イム通知キューとする。このキュー区分に設定された取
り扱いに応じてリアルタイム処理要求であるか、非リア
ルタイム処理要求であるかが振り分けられるものであ
り、リアルタイム処理要求、非リアルタイム処理要求の
設定を柔軟に行うことができる。
３２は送信されてきたキュー登録要求がリアルタイムで
の処理が必要なリアルタイムキューであるか、必ずしも
リアルタイムでの処理が必要ではないディレイドキュー
であるかを判別する。リアルタイムキューであるかディ
レイドキューであるかの判断は、キュー登録要求があっ
たキューデータのキュー区分によって判別することが可
能である。たとえば、図１３に示すように、キュー区分
が、「未会話再電話」「キャンペーン」「E-mail−発信
（ＤＭ）」である場合にはリクエストキュー、「有効再
電話」「フォロー会話」「E-mail−転送」「E-mail−発
信（個別）」である場合にはディレイド通知キュー、
「Web−転送」「電話−転送」である場合にはリアルタ
イム通知キューとする。このキュー区分に設定された取
り扱いに応じてリアルタイム処理要求であるか、非リア
ルタイム処理要求であるかが振り分けられるものであ
り、リアルタイム処理要求、非リアルタイム処理要求の
設定を柔軟に行うことができる。
【００３１】リアルタイム通知キューは、リアルタイム
で処理を行う必要のある処理要求であり、たとえば、We
bサーバ１２へのコールバック要求やＲＥＰ１４、ＶＲ
Ｕ１５で処理できなかった電話の転送などが対象とな
る。また、リクエストキューは、顧客不在または話中に
よる未会話再電話、電話でのアウトバウンド業務である
キャンペーン、ダイレクトメールのためのE-mail−発信
（ＤＭ）などのアウトバウンド業務に関するものであっ
て、キューコントロールＤＬＬ２４からのキュー取得要
求に応じてクライアント側に送信されるものである。ま
た、ディレイド通知キューは、顧客との通話の結果再度
電話を行うこととなった有効再電話、前回のフォローの
ためのフォロー電話、E-mailへの対応であるE-mail−転
送、E-mailの個別発信であるE-mail−発信（個別）など
の業務が対象である。このリクエストキューとディレイ
ド通知キューとがディレイドキューであり、ディスパッ
チャ３２がこれらのキュー登録要求を受けた場合には、
キューマネージャ３３に送信してディレイドキューとし
て登録・管理を行わせる。ディレイド通知キューは、リ
アルタイムで処理する必要がないものの、顧客からの要
求に対する応答が必要であり、一定時間内に処理する必
要があるものと考えられる。したがって、キューマネー
ジャ３３に登録されてから所定時間が経過すると、ディ
スパッチャ３２に対してキュー通知がなされ、ディスパ
ッチャ３２からの振り分け処理が行われることとなる。
で処理を行う必要のある処理要求であり、たとえば、We
bサーバ１２へのコールバック要求やＲＥＰ１４、ＶＲ
Ｕ１５で処理できなかった電話の転送などが対象とな
る。また、リクエストキューは、顧客不在または話中に
よる未会話再電話、電話でのアウトバウンド業務である
キャンペーン、ダイレクトメールのためのE-mail−発信
（ＤＭ）などのアウトバウンド業務に関するものであっ
て、キューコントロールＤＬＬ２４からのキュー取得要
求に応じてクライアント側に送信されるものである。ま
た、ディレイド通知キューは、顧客との通話の結果再度
電話を行うこととなった有効再電話、前回のフォローの
ためのフォロー電話、E-mailへの対応であるE-mail−転
送、E-mailの個別発信であるE-mail−発信（個別）など
の業務が対象である。このリクエストキューとディレイ
ド通知キューとがディレイドキューであり、ディスパッ
チャ３２がこれらのキュー登録要求を受けた場合には、
キューマネージャ３３に送信してディレイドキューとし
て登録・管理を行わせる。ディレイド通知キューは、リ
アルタイムで処理する必要がないものの、顧客からの要
求に対する応答が必要であり、一定時間内に処理する必
要があるものと考えられる。したがって、キューマネー
ジャ３３に登録されてから所定時間が経過すると、ディ
スパッチャ３２に対してキュー通知がなされ、ディスパ
ッチャ３２からの振り分け処理が行われることとなる。
【００３２】ステップＳ１２において、キュー登録要求
のあったキューデータがリアルタイムキューであると判
断した場合には、ステップＳ１３に移行する。ステップ
Ｓ１３では、リアルタイム通知キューの振り分け先の選
択を行う。リアルタイム通知キューの振り分けは、図１
４に示すような振り分けテーブルを用いて行うことがで
きる。この振り分けテーブルは、たとえばＲＥＰ１４の
各オペレータが扱うことが可能なキューデータに基づい
て各オペレータ毎に作成されており、ユーザＩＤ、キャ
ンペーンコード、エリアコード、重み、転送グループＩ
Ｄ、有効フラグ、インアウト区分などの項目を備えてい
る。
のあったキューデータがリアルタイムキューであると判
断した場合には、ステップＳ１３に移行する。ステップ
Ｓ１３では、リアルタイム通知キューの振り分け先の選
択を行う。リアルタイム通知キューの振り分けは、図１
４に示すような振り分けテーブルを用いて行うことがで
きる。この振り分けテーブルは、たとえばＲＥＰ１４の
各オペレータが扱うことが可能なキューデータに基づい
て各オペレータ毎に作成されており、ユーザＩＤ、キャ
ンペーンコード、エリアコード、重み、転送グループＩ
Ｄ、有効フラグ、インアウト区分などの項目を備えてい
る。
【００３３】ユーザＩＤは、そのオペレータのＩＤ番号
である。このユーザＩＤに関連付けてオペレータが扱う
ことが可能なキャンペーンコード、エリアコードなどが
設定されている。キャンペーンコードやエリアコードは
オペレータのスキルに応じて複数担当するように構成す
ることができる。また、状況に応じて各オペレータの重
みを設定できるように構成されている。さらに、振り分
け情報（エントリ）がインバウンド業務用のものかアウ
トバウンド業務用のものかの区別を行っている。公衆回
線網からの着信に対しては、ＰＢＸ１１内に設けられた
ＡＣＤシステムのマルチログオン機能により、着信時に
その顧客のキャンペーンコード、エリアコードなどを確
認して、これに一致するキャンペーンコードまたはエリ
アコードを有するオペレータに自動振り分けするように
構成できる。ここでは、各チャネルから発生するリアル
タイム処理要求に対して、ディスパッチャ３２が最適な
オペレータを選択するように構成している。
である。このユーザＩＤに関連付けてオペレータが扱う
ことが可能なキャンペーンコード、エリアコードなどが
設定されている。キャンペーンコードやエリアコードは
オペレータのスキルに応じて複数担当するように構成す
ることができる。また、状況に応じて各オペレータの重
みを設定できるように構成されている。さらに、振り分
け情報（エントリ）がインバウンド業務用のものかアウ
トバウンド業務用のものかの区別を行っている。公衆回
線網からの着信に対しては、ＰＢＸ１１内に設けられた
ＡＣＤシステムのマルチログオン機能により、着信時に
その顧客のキャンペーンコード、エリアコードなどを確
認して、これに一致するキャンペーンコードまたはエリ
アコードを有するオペレータに自動振り分けするように
構成できる。ここでは、各チャネルから発生するリアル
タイム処理要求に対して、ディスパッチャ３２が最適な
オペレータを選択するように構成している。
【００３４】ディスパッチャ３２は、リアルタイム通知
キューのキャンペーンＩＤ、エリアコード、インアウト
区分と、各オペレータの振り分けテーブルのキャンペー
ンコード、エリアコード、インアウト区分とを比較し
て、このリアルタイム通知キューを扱うことができるオ
ペレータを選択する。基本的には、インアウト区分が一
致しかつ一致するキャンペーンコードを有するオペレー
タを選択することとなる。エリアコードが指定されてい
る場合には、エリアコードを含めた子細な振り分けを行
う。
キューのキャンペーンＩＤ、エリアコード、インアウト
区分と、各オペレータの振り分けテーブルのキャンペー
ンコード、エリアコード、インアウト区分とを比較し
て、このリアルタイム通知キューを扱うことができるオ
ペレータを選択する。基本的には、インアウト区分が一
致しかつ一致するキャンペーンコードを有するオペレー
タを選択することとなる。エリアコードが指定されてい
る場合には、エリアコードを含めた子細な振り分けを行
う。
【００３５】振り分け先を選択した後、ステップＳ１４
においてキューを通知すべき端末の選択時に端末の空き
状況も考慮して決定し送信を行う。この際、リアルタイ
ム処理要求であるにもかかわらず、空き状態の端末が存
在しない場合、要求元へBUSY通知を行い、現在対応でき
ないことを示す。要求が非リアルタイム処理要求の場合
は、再度キューマネージャに返還し、次の通知処理時に
再処理される。
においてキューを通知すべき端末の選択時に端末の空き
状況も考慮して決定し送信を行う。この際、リアルタイ
ム処理要求であるにもかかわらず、空き状態の端末が存
在しない場合、要求元へBUSY通知を行い、現在対応でき
ないことを示す。要求が非リアルタイム処理要求の場合
は、再度キューマネージャに返還し、次の通知処理時に
再処理される。
【００３６】ディスパッチャ３２からのキュー通知処理
を受けて、クライアント側ではステップＳ１５において
キュー着信処理を行う。ここでは、サーバ側から送信さ
れてくるキューデータを取得して、このリアルタイム通
知キューへの対応を行う。実際には、オペレータが電話
対応やE-mail対応などを行うこととなる。オペレータが
扱うＲＥＰ以外のチャネルで、リアルタイム通知キュー
の取り扱いが可能である場合には、そのようなチャネル
の端末を選択してリアルタイム通知キューを送信して処
理を行わせるように構成でき、チャネルの拡張に伴って
適宜変更することが可能である。
を受けて、クライアント側ではステップＳ１５において
キュー着信処理を行う。ここでは、サーバ側から送信さ
れてくるキューデータを取得して、このリアルタイム通
知キューへの対応を行う。実際には、オペレータが電話
対応やE-mail対応などを行うこととなる。オペレータが
扱うＲＥＰ以外のチャネルで、リアルタイム通知キュー
の取り扱いが可能である場合には、そのようなチャネル
の端末を選択してリアルタイム通知キューを送信して処
理を行わせるように構成でき、チャネルの拡張に伴って
適宜変更することが可能である。
【００３７】ステップＳ１２において、ディスパッチャ
３２がリアルタイムキューではないと判断した処理要求
については、キューマネージャ３３に対してディレイド
キューとしての登録処理を行う。ここで、キューマネー
ジャ３３は、ステップＳ１６において、その処理要求に
ついてディレイドキューとして登録する。ディレイドキ
ューの登録については、セグメント分析のチャネルなど
を通じてアウトバウンド系業務のキューが登録される場
合も含まれ、このときはリクエストキューとしてディレ
イドキューの登録がなされる。
３２がリアルタイムキューではないと判断した処理要求
については、キューマネージャ３３に対してディレイド
キューとしての登録処理を行う。ここで、キューマネー
ジャ３３は、ステップＳ１６において、その処理要求に
ついてディレイドキューとして登録する。ディレイドキ
ューの登録については、セグメント分析のチャネルなど
を通じてアウトバウンド系業務のキューが登録される場
合も含まれ、このときはリクエストキューとしてディレ
イドキューの登録がなされる。
【００３８】ディレイドキューを登録する際には、各キ
ューに対して優先度を付して登録処理を行う。各キュー
の優先度は、図１５に示すような優先度テーブルに基づ
いて設定される。キューの優先度テーブルは、キュー区
分、業務区分、キャンペーンコード、キュー生成日時、
振り分けロジックなどの項目からなる。
ューに対して優先度を付して登録処理を行う。各キュー
の優先度は、図１５に示すような優先度テーブルに基づ
いて設定される。キューの優先度テーブルは、キュー区
分、業務区分、キャンペーンコード、キュー生成日時、
振り分けロジックなどの項目からなる。
【００３９】キュー区分は、そのキューデータが属する
キュー区分であり図１２に示すキュー区分で設定されて
いる。業務区分は、顧客とのコンタクト形態を示すもの
であり、たとえば、図１６に示すように、その値に基づ
いて、業務停止状態、ＣＴＩインバウンド、ポテンシャ
ルセールス、ＣＴＩアウトバウンド、テレバン、E-mail
インバウンド、E-mailアウトバウンド、Web、共通、そ
の他などに区分される。この業務区分は、単純にインア
ウト区分と同様にインバウンドであるかアウトバウンド
であるかを示すものであってもよい。
キュー区分であり図１２に示すキュー区分で設定されて
いる。業務区分は、顧客とのコンタクト形態を示すもの
であり、たとえば、図１６に示すように、その値に基づ
いて、業務停止状態、ＣＴＩインバウンド、ポテンシャ
ルセールス、ＣＴＩアウトバウンド、テレバン、E-mail
インバウンド、E-mailアウトバウンド、Web、共通、そ
の他などに区分される。この業務区分は、単純にインア
ウト区分と同様にインバウンドであるかアウトバウンド
であるかを示すものであってもよい。
【００４０】キューの優先度テーブル中のキャンペーン
コードは、そのキューデータ中のキャンペーンＩＤから
取得することができる。また、キュー生成日時は、キュ
ーデータの登録からの経過時間を監視するためのもので
あって、登録された時刻が設定される。振り分けロジッ
クは、そのキューに対して適用される検索ロジックであ
って、たとえば、キュー生成日時からの経過時間が所定
期間を過ぎたものを検索する、キャンペーンコードが一
致するものを検索する、アウトバウンド業務のキューの
みを検索する、再電話のものを検索する、オペレータＩ
Ｄが一致するものを検索する、エリアコードが一致する
ものを検索する、これらの組み合わせにより検索するな
ど予め用意された振り分けロジックのＩＤ番号が設定さ
れる。
コードは、そのキューデータ中のキャンペーンＩＤから
取得することができる。また、キュー生成日時は、キュ
ーデータの登録からの経過時間を監視するためのもので
あって、登録された時刻が設定される。振り分けロジッ
クは、そのキューに対して適用される検索ロジックであ
って、たとえば、キュー生成日時からの経過時間が所定
期間を過ぎたものを検索する、キャンペーンコードが一
致するものを検索する、アウトバウンド業務のキューの
みを検索する、再電話のものを検索する、オペレータＩ
Ｄが一致するものを検索する、エリアコードが一致する
ものを検索する、これらの組み合わせにより検索するな
ど予め用意された振り分けロジックのＩＤ番号が設定さ
れる。
【００４１】〔キュー取得要求〕クライアント側からデ
ィレイドキューの取得要求を行う場合は、図４に示すフ
ローチャートに基づいて処理が実行される。クライアン
ト側からディレイドキューの取得要求を行う場合として
は、予め計画されたプロモーション業務やディレイド通
知キューの処理などのアウトバウンド業務において、次
の顧客処理を行うためにキューを要求する場合が考えら
れる。
ィレイドキューの取得要求を行う場合は、図４に示すフ
ローチャートに基づいて処理が実行される。クライアン
ト側からディレイドキューの取得要求を行う場合として
は、予め計画されたプロモーション業務やディレイド通
知キューの処理などのアウトバウンド業務において、次
の顧客処理を行うためにキューを要求する場合が考えら
れる。
【００４２】次の顧客処理を実行できる空き状態となっ
て次のキューデータを要求する場合、クライアント側で
は、キューコントロールＤＬＬ２４からキューマネージ
ャ３３に対してキュー取得要求を送信する（ステップＳ
２１）。キュー取得要求は、要求するキュー区分、キャ
ンペーンＩＤ、インアウト区分、エリアコードおよびオ
ペレータのユーザＩＤとともに次顧客データを要求する
旨のデータを送信する。
て次のキューデータを要求する場合、クライアント側で
は、キューコントロールＤＬＬ２４からキューマネージ
ャ３３に対してキュー取得要求を送信する（ステップＳ
２１）。キュー取得要求は、要求するキュー区分、キャ
ンペーンＩＤ、インアウト区分、エリアコードおよびオ
ペレータのユーザＩＤとともに次顧客データを要求する
旨のデータを送信する。
【００４３】キューマネージャ３３では、クライアント
側からキュー取得要求を受けると、ステップＳ２２にお
いてキュー取得処理を実行する。キュー取得処理では、
送信されてきたデータ中のキュー区分、キャンペーンＩ
Ｄ、インアウト区分、エリアコードなどにより、登録さ
れているディレイドキューを検索し、次顧客のキューデ
ータを抽出する。
側からキュー取得要求を受けると、ステップＳ２２にお
いてキュー取得処理を実行する。キュー取得処理では、
送信されてきたデータ中のキュー区分、キャンペーンＩ
Ｄ、インアウト区分、エリアコードなどにより、登録さ
れているディレイドキューを検索し、次顧客のキューデ
ータを抽出する。
【００４４】さらに、キューマネージャ３３は、抽出し
た次顧客のキューデータをユーザＩＤで特定されるクラ
イアントに送信する（ステップＳ２３）。クライアント
側では、送信されてくるキューデータに基づいて次顧客
処理を実行する（ステップＳ２４）。ステップＳ２１の
キュー取得要求において、クライアント側からオペレー
タのユーザＩＤだけを送信し、キューマネージャ３３は
ステップＳ２２においてユーザＩＤに基づいて適切なキ
ューを抽出してそのキューデータを送信するように構成
することが可能である。
た次顧客のキューデータをユーザＩＤで特定されるクラ
イアントに送信する（ステップＳ２３）。クライアント
側では、送信されてくるキューデータに基づいて次顧客
処理を実行する（ステップＳ２４）。ステップＳ２１の
キュー取得要求において、クライアント側からオペレー
タのユーザＩＤだけを送信し、キューマネージャ３３は
ステップＳ２２においてユーザＩＤに基づいて適切なキ
ューを抽出してそのキューデータを送信するように構成
することが可能である。
【００４５】〔キュー一覧要求〕クライアント側からキ
ューマネージャ３３に登録されているキュー一覧を要求
する場合には図５に示すフローチャートに基づいて処理
される。キュー一覧要求は、たとえば、キューマネージ
ャ３３に登録されているディレイドキューのうち、キュ
ー区分が有効再電話であるキューの一覧を閲覧したい場
合などが考えられる。
ューマネージャ３３に登録されているキュー一覧を要求
する場合には図５に示すフローチャートに基づいて処理
される。キュー一覧要求は、たとえば、キューマネージ
ャ３３に登録されているディレイドキューのうち、キュ
ー区分が有効再電話であるキューの一覧を閲覧したい場
合などが考えられる。
【００４６】キュー一覧要求を行う場合には、キューコ
ントロールＤＬＬ２４によりキュー一覧要求をキューマ
ネージャ３３に送信する（ステップＳ３１）。このと
き、送信されるデータとしては、一覧要求を行うキュー
のキュー区分、キャンペーンＩＤ、オペレータのユーザ
ＩＤなどがある。キュー一覧要求を受けたキューマネー
ジャ３３では、送信されてきたデータに基づいてキュー
一覧を作成する（ステップＳ３２）。たとえば、キュー
区分、キャンペーンＩＤ、ユーザＩＤに基づいて、登録
されているディレイドキューを検索し、クライアントか
らの要求に合致したキューデータを抽出し、一覧データ
を作成する。
ントロールＤＬＬ２４によりキュー一覧要求をキューマ
ネージャ３３に送信する（ステップＳ３１）。このと
き、送信されるデータとしては、一覧要求を行うキュー
のキュー区分、キャンペーンＩＤ、オペレータのユーザ
ＩＤなどがある。キュー一覧要求を受けたキューマネー
ジャ３３では、送信されてきたデータに基づいてキュー
一覧を作成する（ステップＳ３２）。たとえば、キュー
区分、キャンペーンＩＤ、ユーザＩＤに基づいて、登録
されているディレイドキューを検索し、クライアントか
らの要求に合致したキューデータを抽出し、一覧データ
を作成する。
【００４７】キューマネージャ３３は、抽出して作成し
た一覧データをユーザＩＤで特定されるクライアント側
に送信する（ステップＳ３３）。一覧データを受信した
クライアント側では、モニタ上に一覧表示させるなどの
一覧処理を実行する（ステップＳ３４）。 〔キュー変更要求〕 キューマネージャ３３に登録されているディレイドキュ
ーのキューデータの変更要求を行う場合には、図６に示
すようなフローチャートに基づいて処理を実行する。キ
ュー変更要求を行う場合としては、キューマネージャ３
３が管理しているディレイドキューのうちキュー区分が
有効再電話のものについて、再電話を行う時間を変更す
る場合などが考えられる。
た一覧データをユーザＩＤで特定されるクライアント側
に送信する（ステップＳ３３）。一覧データを受信した
クライアント側では、モニタ上に一覧表示させるなどの
一覧処理を実行する（ステップＳ３４）。 〔キュー変更要求〕 キューマネージャ３３に登録されているディレイドキュ
ーのキューデータの変更要求を行う場合には、図６に示
すようなフローチャートに基づいて処理を実行する。キ
ュー変更要求を行う場合としては、キューマネージャ３
３が管理しているディレイドキューのうちキュー区分が
有効再電話のものについて、再電話を行う時間を変更す
る場合などが考えられる。
【００４８】クライアント側において、たとえば、再電
話予約の変更処理があった場合（ステップＳ４１）のよ
うに、キューマネージャ３３が管理しているディレイド
キューのデータ変更を行うときには、キュー変更要求を
キューマネージャ３３に送信する（ステップＳ４２）。
キュー変更要求は、キューＩＤ、ユーザＩＤなどととも
に変更を行うデータの送信を行う。
話予約の変更処理があった場合（ステップＳ４１）のよ
うに、キューマネージャ３３が管理しているディレイド
キューのデータ変更を行うときには、キュー変更要求を
キューマネージャ３３に送信する（ステップＳ４２）。
キュー変更要求は、キューＩＤ、ユーザＩＤなどととも
に変更を行うデータの送信を行う。
【００４９】キューマネージャ３３は、送信されてきた
データに基づいて指定されたキューＩＤを有するキュー
データを抽出し、このキューデータに変更データを反映
させる。クライアント側で変更を行うキューデータのキ
ューＩＤを認識できない場合には、キュー区分、キャン
ペーンＩＤ、エリアコード、開始日時などのデータを送
信して、キューマネージャ３３に該当するキューデータ
を検索させるように構成することも可能である。
データに基づいて指定されたキューＩＤを有するキュー
データを抽出し、このキューデータに変更データを反映
させる。クライアント側で変更を行うキューデータのキ
ューＩＤを認識できない場合には、キュー区分、キャン
ペーンＩＤ、エリアコード、開始日時などのデータを送
信して、キューマネージャ３３に該当するキューデータ
を検索させるように構成することも可能である。
【００５０】〔キュー削除要求〕キューマネージャ３３
に登録されているディレイドキューのキューデータの削
除要求を行う場合には、図７に示すようなフローチャー
トに基づいて処理を実行する。キュー削除要求を行う場
合としては、キューマネージャ３３から取得したキュー
の処理が完了したために、キューマネージャ３３の管理
下からそのキューを削除する場合などが考えられる。
に登録されているディレイドキューのキューデータの削
除要求を行う場合には、図７に示すようなフローチャー
トに基づいて処理を実行する。キュー削除要求を行う場
合としては、キューマネージャ３３から取得したキュー
の処理が完了したために、キューマネージャ３３の管理
下からそのキューを削除する場合などが考えられる。
【００５１】クライアント側において、キューマネージ
ャ３３から取得した次顧客処理が終了した場合（ステッ
プＳ５１）のようにキュー削除を要求するときには、キ
ュー削除要求をキューマネージャ３３に送信する（ステ
ップＳ５２）。キュー削除要求は、そのキューデータの
キューＩＤと終了日時およびオペレータのユーザＩＤな
どのデータを送信するように構成できる。
ャ３３から取得した次顧客処理が終了した場合（ステッ
プＳ５１）のようにキュー削除を要求するときには、キ
ュー削除要求をキューマネージャ３３に送信する（ステ
ップＳ５２）。キュー削除要求は、そのキューデータの
キューＩＤと終了日時およびオペレータのユーザＩＤな
どのデータを送信するように構成できる。
【００５２】キューマネージャ３３では、クライアント
側からのキュー削除要求を受け取るとキュー削除処理を
実行する（ステップＳ５３）。キュー削除処理では、送
信されてきたデータ中のキューＩＤに基づいてキューデ
ータを抽出し、処理済みのフラグを立てるなどして、ア
クティブなディレイドキューからこのキューデータを削
除する。
側からのキュー削除要求を受け取るとキュー削除処理を
実行する（ステップＳ５３）。キュー削除処理では、送
信されてきたデータ中のキューＩＤに基づいてキューデ
ータを抽出し、処理済みのフラグを立てるなどして、ア
クティブなディレイドキューからこのキューデータを削
除する。
【００５３】〔状態通知処理〕クライアント側では、な
んらかの処理を実行中であるか否かの現在の状態をサー
バ側に通知する（ステップＳ６１）。現在の状態として
は、処理を実行していない空き状態、なんらかの処理を
実行中であるBUSY状態が考えられる。クライアント側で
現在の状態に変化があった場合に、クライアントアプリ
ケーション２２がこれを認識し、チャネルコントロール
２３を介してイベント送受信部２５に現在の状態データ
を送信する。イベント送受信部２５は、この現在の状態
データをＢＣコントローラサーバ３１のBC-BUS３４に送
信することにより状態通知処理が行われる。
んらかの処理を実行中であるか否かの現在の状態をサー
バ側に通知する（ステップＳ６１）。現在の状態として
は、処理を実行していない空き状態、なんらかの処理を
実行中であるBUSY状態が考えられる。クライアント側で
現在の状態に変化があった場合に、クライアントアプリ
ケーション２２がこれを認識し、チャネルコントロール
２３を介してイベント送受信部２５に現在の状態データ
を送信する。イベント送受信部２５は、この現在の状態
データをＢＣコントローラサーバ３１のBC-BUS３４に送
信することにより状態通知処理が行われる。
【００５４】BC-BUS３４では、クライアント側から送信
されてくる現在の状態データに基づいて、管理している
状態データのうち該当するクライアントの状態データを
変更して状態設定処理を実行する（ステップＳ６２）。 〔ディレイドキュー通知処理〕キューマネージャ３３が
管理するディレイドキューが所定の条件を満たした段階
でディスパッチャ３２にこれを通知し、ディスパッチャ
３２から最適なクライアントに振り分けることが行われ
る。キューマネージャ３３が管理するディレイドキュー
のうち、キュー区分が有効再電話の場合、次に処理を行
う日時を予約設定していることが考えられる。また、キ
ュー区分がフォロー会話、E-mail−転送、E-mail−発信
（個人）であるようなディレイド通知キューは、リアル
タイムで処理する必要がないものの、顧客への対応であ
るため、ある程度の期間内に処理されるべきである。キ
ュー区分が有効再電話であるようなディレイド通知キュ
ーの予約日時に到達した場合や、キュー区分がフォロー
会話、E-mail−転送、E-mail−発信（個人）であるよう
なディレイド通知キューの登録からの経過時間が所定期
間を過ぎた場合に、ディレイドキュー通知処理を実行す
る。
されてくる現在の状態データに基づいて、管理している
状態データのうち該当するクライアントの状態データを
変更して状態設定処理を実行する（ステップＳ６２）。 〔ディレイドキュー通知処理〕キューマネージャ３３が
管理するディレイドキューが所定の条件を満たした段階
でディスパッチャ３２にこれを通知し、ディスパッチャ
３２から最適なクライアントに振り分けることが行われ
る。キューマネージャ３３が管理するディレイドキュー
のうち、キュー区分が有効再電話の場合、次に処理を行
う日時を予約設定していることが考えられる。また、キ
ュー区分がフォロー会話、E-mail−転送、E-mail−発信
（個人）であるようなディレイド通知キューは、リアル
タイムで処理する必要がないものの、顧客への対応であ
るため、ある程度の期間内に処理されるべきである。キ
ュー区分が有効再電話であるようなディレイド通知キュ
ーの予約日時に到達した場合や、キュー区分がフォロー
会話、E-mail−転送、E-mail−発信（個人）であるよう
なディレイド通知キューの登録からの経過時間が所定期
間を過ぎた場合に、ディレイドキュー通知処理を実行す
る。
【００５５】このようなディレイドキュー通知処理を図
９に示すフローチャートに基づいて説明する。ステップ
Ｓ７１では、キューマネージャ３３は、振り分けロジッ
クを用いて登録されたディレイドキューを検索し、たと
えば登録からの経過時間が所定期間を過ぎたディレイド
通知キューや予約日時に到達した有効再電話のキューを
抽出する。ここでは、所定時間間隔で登録されたディレ
イドキューの検索を行って、該当するものがある場合
に、ステップＳ７２に移行する。
９に示すフローチャートに基づいて説明する。ステップ
Ｓ７１では、キューマネージャ３３は、振り分けロジッ
クを用いて登録されたディレイドキューを検索し、たと
えば登録からの経過時間が所定期間を過ぎたディレイド
通知キューや予約日時に到達した有効再電話のキューを
抽出する。ここでは、所定時間間隔で登録されたディレ
イドキューの検索を行って、該当するものがある場合
に、ステップＳ７２に移行する。
【００５６】ステップＳ７２では、ステップＳ７１で検
索した結果、抽出されたディレイド通知キューをディス
パッチャ３２に送信してキュー通知依頼を行う。ここで
は、抽出されたキューデータのキュー区分、インアウト
区分、ユーザＩＤ、キャンペーンＩＤ、顧客ＩＤ、開始
日時、エリアコードなどのデータをディスパッチャ３２
に送信する。
索した結果、抽出されたディレイド通知キューをディス
パッチャ３２に送信してキュー通知依頼を行う。ここで
は、抽出されたキューデータのキュー区分、インアウト
区分、ユーザＩＤ、キャンペーンＩＤ、顧客ＩＤ、開始
日時、エリアコードなどのデータをディスパッチャ３２
に送信する。
【００５７】ステップＳ７３において、ディスパッチャ
３２が、送信されてきたデータに基づいてキュー通知先
を選定する。ここでは、インアウト区分、キャンペーン
ＩＤ、エリアコードなどを、各オペレータの振り分けテ
ーブルと照合して、最適のオペレータを選定する。ユー
ザＩＤが有効であるようなキューの場合には、そのユー
ザＩＤのオペレータを選定することとなる。BC-BUS３４
が管理するクライアントの現在の状態により、選定した
クライアントがBUSY状態のときには、再度選定を実行す
る。このキューに対して複数のオペレータが処理可能で
あるような場合には、着信待ち時間が最も長いオペレー
タに対してキューの通知を行うように構成することもで
きる。
３２が、送信されてきたデータに基づいてキュー通知先
を選定する。ここでは、インアウト区分、キャンペーン
ＩＤ、エリアコードなどを、各オペレータの振り分けテ
ーブルと照合して、最適のオペレータを選定する。ユー
ザＩＤが有効であるようなキューの場合には、そのユー
ザＩＤのオペレータを選定することとなる。BC-BUS３４
が管理するクライアントの現在の状態により、選定した
クライアントがBUSY状態のときには、再度選定を実行す
る。このキューに対して複数のオペレータが処理可能で
あるような場合には、着信待ち時間が最も長いオペレー
タに対してキューの通知を行うように構成することもで
きる。
【００５８】ステップＳ７３においてキュー通知先が特
定されると、ステップＳ７４においてキュー通知処理を
実行する。キュー通知処理は、選定したオペレータに対
応するクライアントのイベント送受信部２５に対して、
BC-BUS３４を介してキュー通知の送信を実行する。ここ
では、そのキューデータのキュー区分、インアウト区
分、ユーザＩＤ、キャンペーンＩＤ、顧客ＩＤ、開始日
時、エリアコードなどの情報を送信する。
定されると、ステップＳ７４においてキュー通知処理を
実行する。キュー通知処理は、選定したオペレータに対
応するクライアントのイベント送受信部２５に対して、
BC-BUS３４を介してキュー通知の送信を実行する。ここ
では、そのキューデータのキュー区分、インアウト区
分、ユーザＩＤ、キャンペーンＩＤ、顧客ＩＤ、開始日
時、エリアコードなどの情報を送信する。
【００５９】クライアント側では、ステップＳ７５にお
いて、送信されてきたデータに基づいてキュー着信処理
を実行する。たとえば、モニタ上に着信したキュー情報
を表示させ、オペレータによる処理の実行を促すように
構成できる。 〔ＲＥＰ画面遷移図〕オペレータが操作するＲＥＰ１４
上の画面遷移について、図１７を用いて説明する。
いて、送信されてきたデータに基づいてキュー着信処理
を実行する。たとえば、モニタ上に着信したキュー情報
を表示させ、オペレータによる処理の実行を促すように
構成できる。 〔ＲＥＰ画面遷移図〕オペレータが操作するＲＥＰ１４
上の画面遷移について、図１７を用いて説明する。
【００６０】まず、クライアントアプリケーション２２
を立ち上げると、ログオン画面４１が表示される。ログ
オン画面４１では、インバウンド業務、アウトバウンド
業務を選択してログオンすることが可能となっている。
通常、オペレータに予め設定された業務を選択してログ
オンすることによって、インバウンド系処理画面または
アウトバウンド系処理画面に移行する。
を立ち上げると、ログオン画面４１が表示される。ログ
オン画面４１では、インバウンド業務、アウトバウンド
業務を選択してログオンすることが可能となっている。
通常、オペレータに予め設定された業務を選択してログ
オンすることによって、インバウンド系処理画面または
アウトバウンド系処理画面に移行する。
【００６１】インバウンド系処理画面では、キュー取得
画面４２、着信待ち画面４３、メイン画面４４を備えて
いる。再電話やE-mail処理などを実行する場合には、キ
ュー取得画面４２によりキューマネージャ３３にキュー
取得要求を行う。電話などの着信を受ける合間に、キュ
ー区分が有効再電話、フォロー会話、E-mail−転送など
の処理を実行する場合には、このキュー取得要求を行っ
て、キューマネージャ３３からキューを取得する。
画面４２、着信待ち画面４３、メイン画面４４を備えて
いる。再電話やE-mail処理などを実行する場合には、キ
ュー取得画面４２によりキューマネージャ３３にキュー
取得要求を行う。電話などの着信を受ける合間に、キュ
ー区分が有効再電話、フォロー会話、E-mail−転送など
の処理を実行する場合には、このキュー取得要求を行っ
て、キューマネージャ３３からキューを取得する。
【００６２】キューマネージャ３３に登録されているデ
ィレイドキューのうち、キュー取得要求に該当するもの
が存在しない場合には、着信待ち画面４３に移行する。
着信待ち画面４３では、公衆回線網を介した電話、ＢＣ
コントローラサーバ３１から送信されてくるキュー通知
などのキューが着信した場合に、これを知らせるように
構成されている。キューの着信があった場合には、メイ
ン画面４４に移行する。
ィレイドキューのうち、キュー取得要求に該当するもの
が存在しない場合には、着信待ち画面４３に移行する。
着信待ち画面４３では、公衆回線網を介した電話、ＢＣ
コントローラサーバ３１から送信されてくるキュー通知
などのキューが着信した場合に、これを知らせるように
構成されている。キューの着信があった場合には、メイ
ン画面４４に移行する。
【００６３】また、キュー取得画面４２において、キュ
ー取得要求に該当するディレイド通知キューが存在する
場合には、ＢＣコントローラサーバ３１から該当するキ
ュー通知があり、メイン画面４４に移行する。メイン画
面４４では、キューに関するデータの表示を行い、必要
なアプリケーションを立ち上げるなどして処理に対応し
た画面表示を行う。処理が終了して次顧客のキューを取
得する場合には、メイン画面４４からキュー取得画面４
２に移行してキュー取得を行う。メイン画面４４からロ
グオフを行うと、メイン画面４４上の処理を終了してロ
グオン画面４１に移行する。
ー取得要求に該当するディレイド通知キューが存在する
場合には、ＢＣコントローラサーバ３１から該当するキ
ュー通知があり、メイン画面４４に移行する。メイン画
面４４では、キューに関するデータの表示を行い、必要
なアプリケーションを立ち上げるなどして処理に対応し
た画面表示を行う。処理が終了して次顧客のキューを取
得する場合には、メイン画面４４からキュー取得画面４
２に移行してキュー取得を行う。メイン画面４４からロ
グオフを行うと、メイン画面４４上の処理を終了してロ
グオン画面４１に移行する。
【００６４】アウトバウンド系処理画面では、キュー取
得画面４５、着信待ち画面４６、メイン画面４７を備え
ている。キャンペーンや再電話、ＤＭ系のE-mail処理な
どを実行する場合には、キュー取得画面４５によりキュ
ーマネージャ３３にキュー取得要求を行う。キュー区分
が未会話再電話、キャンペーン、E-mail−発信（ＤＭ）
などのリクエストキューの処理を実行する場合には、こ
のキュー取得要求を行って、キューマネージャ３３から
キューを取得する。
得画面４５、着信待ち画面４６、メイン画面４７を備え
ている。キャンペーンや再電話、ＤＭ系のE-mail処理な
どを実行する場合には、キュー取得画面４５によりキュ
ーマネージャ３３にキュー取得要求を行う。キュー区分
が未会話再電話、キャンペーン、E-mail−発信（ＤＭ）
などのリクエストキューの処理を実行する場合には、こ
のキュー取得要求を行って、キューマネージャ３３から
キューを取得する。
【００６５】キューマネージャ３３に登録されているデ
ィレイドキューのうち、キュー取得要求に該当するもの
が存在しない場合には、着信待ち画面４６に移行する。
着信待ち画面４６では、ＢＣコントローラサーバ３１か
ら送信されてくるキュー通知などのキューが着信した場
合に、これを知らせるように構成されている。キューの
着信があった場合には、メイン画面４７に移行する。
ィレイドキューのうち、キュー取得要求に該当するもの
が存在しない場合には、着信待ち画面４６に移行する。
着信待ち画面４６では、ＢＣコントローラサーバ３１か
ら送信されてくるキュー通知などのキューが着信した場
合に、これを知らせるように構成されている。キューの
着信があった場合には、メイン画面４７に移行する。
【００６６】また、キュー取得画面４５において、キュ
ー取得要求に該当するリクエストキューが存在する場合
には、ＢＣコントローラサーバ３１から該当するキュー
通知があり、メイン画面４７に移行する。メイン画面４
７では、キューに関するデータの表示を行い、必要なア
プリケーションを立ち上げるなどして処理に対応した画
面表示を行う。処理が終了して次顧客のキューを取得す
る場合には、メイン画面４７からキュー取得画面４５に
移行してキュー取得を行う。メイン画面４７からログオ
フを行うと、メイン画面４７上の処理を終了してログオ
ン画面４１に移行する。
ー取得要求に該当するリクエストキューが存在する場合
には、ＢＣコントローラサーバ３１から該当するキュー
通知があり、メイン画面４７に移行する。メイン画面４
７では、キューに関するデータの表示を行い、必要なア
プリケーションを立ち上げるなどして処理に対応した画
面表示を行う。処理が終了して次顧客のキューを取得す
る場合には、メイン画面４７からキュー取得画面４５に
移行してキュー取得を行う。メイン画面４７からログオ
フを行うと、メイン画面４７上の処理を終了してログオ
ン画面４１に移行する。
【００６７】〔運用形態〕実際の運用形態として、電話
とE-mailの対応を行うコールセンタにおける動作例を図
１８の構成図に基づいて説明する。ここでは、公衆回線
網と接続されるＰＢＸ５１と、インターネット回線網に
接続されるE-mailサーバ５２とを備え、ＰＢＸ５１には
３台のＲＥＰ５３，５４，５５と１回線のＶＲＵ５６が
接続され、E-mailサーバ５２には１台のE-mailエージェ
ント５７が接続された構成とする。各ＲＥＰ５３〜５
５、ＶＲＵ５６およびE-mailエージェント５７は、ＭＣ
ＩＣＤ５８に接続されており、着信やプロモーションな
どに基づくキューがＭＣＩＣＤ５８によって制御されて
各チャネルに振り分けられる。
とE-mailの対応を行うコールセンタにおける動作例を図
１８の構成図に基づいて説明する。ここでは、公衆回線
網と接続されるＰＢＸ５１と、インターネット回線網に
接続されるE-mailサーバ５２とを備え、ＰＢＸ５１には
３台のＲＥＰ５３，５４，５５と１回線のＶＲＵ５６が
接続され、E-mailサーバ５２には１台のE-mailエージェ
ント５７が接続された構成とする。各ＲＥＰ５３〜５
５、ＶＲＵ５６およびE-mailエージェント５７は、ＭＣ
ＩＣＤ５８に接続されており、着信やプロモーションな
どに基づくキューがＭＣＩＣＤ５８によって制御されて
各チャネルに振り分けられる。
【００６８】ＲＥＰシステムのうち、第１ＲＥＰ５３お
よび第２ＲＥＰ５４は電話によるインバウンドとE-mail
処理を担当し、第３ＲＥＰは電話によるアウトバウンド
とE-mail処理を担当することとする。ここで、電話によ
るインバウンドは、一旦ＶＲＵ５６で対応し、自動応答
できないものについては、ＭＣＩＣＤ５８の制御の下に
第１ＲＥＰ５３または第２ＲＥＰ５４で対応するものと
する。
よび第２ＲＥＰ５４は電話によるインバウンドとE-mail
処理を担当し、第３ＲＥＰは電話によるアウトバウンド
とE-mail処理を担当することとする。ここで、電話によ
るインバウンドは、一旦ＶＲＵ５６で対応し、自動応答
できないものについては、ＭＣＩＣＤ５８の制御の下に
第１ＲＥＰ５３または第２ＲＥＰ５４で対応するものと
する。
【００６９】ＶＲＵ５６は、公衆回線網を介して着信し
た電話に対して自動応答で対応し、要件に応じて図３に
示すようなキュー登録要求を行う。この場合のキュー登
録要求は、リアルタイムキューとなる。また、E-mailエ
ージェント５７は、E-mailサーバ５２で着信したE-mail
をディレイドキューとしてキュー登録要求を行う。さら
に、予め計画されたプロモーションなどのアウトバウン
ドリストに対応して、リクエストキューがＭＣＩＣＤ５
８側に登録されている。
た電話に対して自動応答で対応し、要件に応じて図３に
示すようなキュー登録要求を行う。この場合のキュー登
録要求は、リアルタイムキューとなる。また、E-mailエ
ージェント５７は、E-mailサーバ５２で着信したE-mail
をディレイドキューとしてキュー登録要求を行う。さら
に、予め計画されたプロモーションなどのアウトバウン
ドリストに対応して、リクエストキューがＭＣＩＣＤ５
８側に登録されている。
【００７０】E-mailエージェント５７は、所定の時間間
隔（たとえば１分間隔）でE-mailサーバ５２に着信した
E-mailの取得を行い、E-mailが着信していた場合には、
ＭＣＩＣＤ５８に対してキュー登録を行う。ＲＥＰ５３
〜５５から送信されてくる現在の状態により、ＭＣＩＣ
Ｄ５８は各ＲＥＰ５３〜５５の状態を監視することがで
き、E-mail着信のキューが存在すれば、空き状態である
ＲＥＰを選択して定期的にキュー通知処理を試みる。
隔（たとえば１分間隔）でE-mailサーバ５２に着信した
E-mailの取得を行い、E-mailが着信していた場合には、
ＭＣＩＣＤ５８に対してキュー登録を行う。ＲＥＰ５３
〜５５から送信されてくる現在の状態により、ＭＣＩＣ
Ｄ５８は各ＲＥＰ５３〜５５の状態を監視することがで
き、E-mail着信のキューが存在すれば、空き状態である
ＲＥＰを選択して定期的にキュー通知処理を試みる。
【００７１】また、ＶＲＵ５６は、電話の一時応答とし
て対応を行い、ＲＥＰへ転送すべき着信であると判断し
た場合に、ＭＣＩＣＤ５８に対してキュー登録要求を行
う。ＭＣＩＣＤ５８では、ＶＲＵ５６からのキュー登録
要求があると、これをリアルタイム処理要求であると判
断し、直ちに処理可能なＲＥＰに対してキュー通知を送
信する。
て対応を行い、ＲＥＰへ転送すべき着信であると判断し
た場合に、ＭＣＩＣＤ５８に対してキュー登録要求を行
う。ＭＣＩＣＤ５８では、ＶＲＵ５６からのキュー登録
要求があると、これをリアルタイム処理要求であると判
断し、直ちに処理可能なＲＥＰに対してキュー通知を送
信する。
【００７２】E-mailにより発生するキューは、電話の通
常インバウンドのキューより優先度の低いディレイドキ
ューであり、電話のインバウンドを処理できないことを
極力回避するために常に最低１台のＲＥＰが空き状態と
なるように設定する。このため、インバウンド処理を行
うＲＥＰ５３、５４のうちいずれか一方が常に空き状態
を維持するように、E-mailのキュー通知がなされる。
常インバウンドのキューより優先度の低いディレイドキ
ューであり、電話のインバウンドを処理できないことを
極力回避するために常に最低１台のＲＥＰが空き状態と
なるように設定する。このため、インバウンド処理を行
うＲＥＰ５３、５４のうちいずれか一方が常に空き状態
を維持するように、E-mailのキュー通知がなされる。
【００７３】第３ＲＥＰ５５では、アウトバウンド業務
とE-mail処理とをその優先度などに基づいて一定の割合
で処理することとなる。E-mailによるディレイドキュー
の滞留が増加してくると、キューの保留時間が長くな
り、自動的に処理の優先度が上がる。前述したように、
ＭＣＩＣＤ５８中のキューマネージャが管理するディレ
イドキューについて、登録されてから所定時間経過した
場合に、優先的にディレイドキュー通知を行うことで、
キャンペーンなどのアウトバウンドに優先して滞留した
E-mail処理を行うように構成できる。電話によるインバ
ウンド処理が増加した場合、ＲＥＰ５３，５４によるE-
mail処理ができなくなり、E-mailによるディレイドキュ
ーの滞留が増加する可能性があるが、アウトバウンド業
務を担当するＲＥＰ５５に対してE-mailのキューを優先
的に処理させることにより、滞留を減少する方向に作用
させることができる。
とE-mail処理とをその優先度などに基づいて一定の割合
で処理することとなる。E-mailによるディレイドキュー
の滞留が増加してくると、キューの保留時間が長くな
り、自動的に処理の優先度が上がる。前述したように、
ＭＣＩＣＤ５８中のキューマネージャが管理するディレ
イドキューについて、登録されてから所定時間経過した
場合に、優先的にディレイドキュー通知を行うことで、
キャンペーンなどのアウトバウンドに優先して滞留した
E-mail処理を行うように構成できる。電話によるインバ
ウンド処理が増加した場合、ＲＥＰ５３，５４によるE-
mail処理ができなくなり、E-mailによるディレイドキュ
ーの滞留が増加する可能性があるが、アウトバウンド業
務を担当するＲＥＰ５５に対してE-mailのキューを優先
的に処理させることにより、滞留を減少する方向に作用
させることができる。
【００７４】ＲＥＰ、ＶＲＵ、E-mailエージェント、そ
の他のチャネルの構成はこれに限定されるものではな
い。また、インバウンド業務とアウトバウンド業務とを
兼務するＲＥＰを混在させることも可能である。この場
合、インバウンド業務用に空き状態であるＲＥＰが少な
くとも１台できるように設定することが好ましい。 〔緊急メール〕E-mailエージェント５７から登録要求さ
れるE-mailのうち、その内容によっては優先的に処理す
るように構成できる。たとえば、E-mailサーバ１３に着
信したE-mailの発信元が、予め登録された特定のメール
アドレスである場合には、優先的に処理を行うためにＲ
ＥＰ１４に送信してオペレータによる処理を行わせるよ
に構成できる。
の他のチャネルの構成はこれに限定されるものではな
い。また、インバウンド業務とアウトバウンド業務とを
兼務するＲＥＰを混在させることも可能である。この場
合、インバウンド業務用に空き状態であるＲＥＰが少な
くとも１台できるように設定することが好ましい。 〔緊急メール〕E-mailエージェント５７から登録要求さ
れるE-mailのうち、その内容によっては優先的に処理す
るように構成できる。たとえば、E-mailサーバ１３に着
信したE-mailの発信元が、予め登録された特定のメール
アドレスである場合には、優先的に処理を行うためにＲ
ＥＰ１４に送信してオペレータによる処理を行わせるよ
に構成できる。
【００７５】たとえば、優良顧客のメールアドレスを登
録しておき、E-mailエージェント１７からキュー登録要
求があった場合に、登録されたメールアドレスと発信ア
ドレスを照合して、一致するものに対してはＲＥＰ１４
にキュー通知を送信するようにする。このことにより優
良顧客向けサービスを優先的に実施することが可能とな
る。また、電話によるアクセスが困難なろうあ者などの
場合、そのメールアドレスを登録しておき、着信したE-
mailの発信アドレスがこれに合致した場合には、緊急性
を要するものと判断してＲＥＰ１４にキュー通知を送信
するように構成する。このことにより、福祉施設などか
らの緊急連絡に対して対応することが可能となる。
録しておき、E-mailエージェント１７からキュー登録要
求があった場合に、登録されたメールアドレスと発信ア
ドレスを照合して、一致するものに対してはＲＥＰ１４
にキュー通知を送信するようにする。このことにより優
良顧客向けサービスを優先的に実施することが可能とな
る。また、電話によるアクセスが困難なろうあ者などの
場合、そのメールアドレスを登録しておき、着信したE-
mailの発信アドレスがこれに合致した場合には、緊急性
を要するものと判断してＲＥＰ１４にキュー通知を送信
するように構成する。このことにより、福祉施設などか
らの緊急連絡に対して対応することが可能となる。
【００７６】
【発明の効果】本発明によれば、リアルタイム処理要求
に対しては即座に対応することが可能であり、ディレイ
ドキューに対しては登録しておいて最適な処理端末に対
して振り分けることが可能である。この結果、いずれの
処理も効率的に処理が可能となり、顧客に対してもサー
ビスレベルを維持することが可能となる。
に対しては即座に対応することが可能であり、ディレイ
ドキューに対しては登録しておいて最適な処理端末に対
して振り分けることが可能である。この結果、いずれの
処理も効率的に処理が可能となり、顧客に対してもサー
ビスレベルを維持することが可能となる。
【００７７】タイミング的に疎なインバウンド系のキュ
ーは要求発生時点で処理端末へ通知されるほうが効率的
であり、タイミング的に密なアウトバウンド系のキュー
は逐次処理的に処理端末側から取得要求を行うほうが効
率的であり、このような両者の利点を生かす方向でキュ
ーの通知制御を行っていることから、各処理の効率化を
図る。
ーは要求発生時点で処理端末へ通知されるほうが効率的
であり、タイミング的に密なアウトバウンド系のキュー
は逐次処理的に処理端末側から取得要求を行うほうが効
率的であり、このような両者の利点を生かす方向でキュ
ーの通知制御を行っていることから、各処理の効率化を
図る。
【００７８】各処理要求を処理端末に振り分けるのは、
振り分けロジックによるものであって、これを変更する
ことによりチャネル拡張に伴うシステム変更にも容易に
対応することが可能であり、拡張性の高いシステムを提
供することができる。
振り分けロジックによるものであって、これを変更する
ことによりチャネル拡張に伴うシステム変更にも容易に
対応することが可能であり、拡張性の高いシステムを提
供することができる。
【図１】概略構成の一例を示す簡略ブロック図。
【図２】内部構成を示す制御ブロック図。
【図３】キュー登録要求処理のフローチャート。
【図４】キュー取得要求処理のフローチャート。
【図５】キュー一覧要求処理のフローチャート。
【図６】キュー変更要求処理のフローチャート。
【図７】キュー削除要求処理のフローチャート。
【図８】状態通知処理のフローチャート。
【図９】ディレイドキュー通知処理のフローチャート。
【図１０】キューデータのテーブルを示す説明図。
【図１１】チャネル識別一覧を示す説明図。
【図１２】キュー区分一覧を示す説明図。
【図１３】キュー区分とキューの扱いの関係を示す説明
図。
図。
【図１４】振り分けテーブルを示す説明図。
【図１５】優先度テーブルを示す説明図。
【図１６】業務区分一覧を示す説明図。
【図１７】ＲＥＰ画面遷移を示す説明図。
【図１８】実際の運用形態の一例を示すブロック図。
─────────────────────────────────────────────────────
フロントページの続き
(56)参考文献 特開 平10−304073（ＪＰ，Ａ)
特開 平４−344757（ＪＰ，Ａ)
特開 平７−30946（ＪＰ，Ａ)
特開2000−244568（ＪＰ，Ａ)
特表2002−503903（ＪＰ，Ａ)
特表2001−522201（ＪＰ，Ａ)
特表2002−518890（ＪＰ，Ａ)
特表2001−519101（ＪＰ，Ａ)
米国特許5793861（ＵＳ，Ａ)
米国特許5467391（ＵＳ，Ａ)
国際公開99／041720（ＷＯ，Ａ１)
国際公開95／008236（ＷＯ，Ａ１)
(58)調査した分野(Int.Cl.7，ＤＢ名)
H04M 3/523
Claims (4)
- 【請求項１】顧客とコールセンタとの通信を行う際の通
信手段としての複数のチャネルからの処理要求を受け付
け、前記処理要求を発生したチャネルの属性を示すチャ
ネル種別および前記処理要求の属性を示すキュー区分に
基づいて、リアルタイムで処理する必要のあるリアルタ
イム処理要求であるか、必ずしもリアルタイムで処理す
る必要のない非リアルタイム処理要求であるかを判別す
る処理要求判別手段と、前記非リアルタイム処理要求であると判別された処理要
求のうち、処理対象である顧客に関するデータが所定の
顧客データであるような処理要求をリアルタイム処理要
求に変更し、その他の非リアルタイム処理要求について
はその優先順位とともに管理する非リアルタイム処理管
理手段と 、 前記リアルタイム処理要求であると判別された処理要求
を、そのリアルタイム処理が可能なチャネルのうち現在
空き状態である処理端末に割り当てるリアルタイム処理
割当手段と、 前記非リアルタイム処理管理手段が管理する非リアルタ
イム処理をその優先順位とその処理に対する各処理端末
の適格性を考慮して各処理端末のいずれかに割り当てる
非リアルタイム処理割当手段と、 を備えるマルチチャネル処理の制御装置。 - 【請求項２】顧客とコールセンタとの通信を行う際の通
信手段としての複数のチャネルで発生する処理要求を受
け付け、前記処理要求を発生したチャネルの属性を示す
チャネル種別および前記処理要求の属性を示すキュー区
分に基づいて、リアルタイムで処理する必要のあるリア
ルタイム処理要求であるか、必ずしもリアルタイムで処
理する必要のない非リアルタイム処理要求であるかを判
別する段階と、前記非リアルタイム処理要求であると判別された処理要
求のうち、処理対象である顧客に関するデータが所定の
顧客データであるような処理要求をリアルタイム処理要
求に変更し、その他の非リアルタイム処理要求について
はその優先順位とともに管理する段階と 、 前記処理要求がリアルタイム処理要求であると判断した
場合に、そのリアルタイム処理が可能であるチャネルの
うち現在空き状態である処理端末にその処理要求を割り
当てる段階と、 を備えるマルチチャネル処理の制御方法。 - 【請求項３】管理中の非リアルタイム処理要求を、その
優先順位と、その非リアルタイム処理要求を処理可能な
チャネル中の現在空き状態である処理端末の適格性とに
基づいて、最適な処理端末に割り当てる段階をさらに備
える、請求項２に記載のマルチチャネル処理の制御方
法。 - 【請求項４】顧客とコールセンタとの通信を行う際の通
信手段としての複数のチャネルで発生する処理要求を受
け付け、前記処理要求を発生したチャネルの属性を示す
チャネル種別および前記処理要求の属性を示すキュー区
分に基づいて、リアルタイムで処理する必要のあるリア
ルタイム処理要求であるか、必ずしもリアルタイムで処
理する必要のない非リアルタイム処理要求であるかを判
別する段階と、 前記非リアルタイム処理要求であると判別された処理要
求のうち、処理対象である顧客に関するデータが所定の
顧客データであるような処理要求をリアルタイム処理要
求に変更し、その他の非リアルタイム処理要求について
はその優先順位とともに管理する段階と、 前記処理要求がリアルタイム処理要求であると判断した
場合に、そのリアルタイム処理が可能であるチャネルの
うち現在空き状態である処理端末にその処理要求を割り
当てる段階と、 を備えるマルチチャネル処理の制御方法をコンピュータ
に実行させるためのプログラムを記録したコンピュータ
読み取り可能な記録媒体。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000093114A JP3535068B2 (ja) | 2000-03-30 | 2000-03-30 | マルチチャネル処理の制御装置およびマルチチャネル処理の制御方法 |
| US09/717,262 US7519665B1 (en) | 2000-03-30 | 2000-11-22 | Multi-channel processing control device and multi-channel processing control method |
| GB0028988A GB2363283B (en) | 2000-03-30 | 2000-11-28 | Multi-channel processing control device and multi-channel processing control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000093114A JP3535068B2 (ja) | 2000-03-30 | 2000-03-30 | マルチチャネル処理の制御装置およびマルチチャネル処理の制御方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003065070A Division JP2003319074A (ja) | 2003-03-11 | 2003-03-11 | マルチチャネル処理の制御方法およびマルチチャネル処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001285492A JP2001285492A (ja) | 2001-10-12 |
| JP3535068B2 true JP3535068B2 (ja) | 2004-06-07 |
Family
ID=18608343
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000093114A Expired - Fee Related JP3535068B2 (ja) | 2000-03-30 | 2000-03-30 | マルチチャネル処理の制御装置およびマルチチャネル処理の制御方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7519665B1 (ja) |
| JP (1) | JP3535068B2 (ja) |
| GB (1) | GB2363283B (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7603448B2 (en) * | 2000-12-15 | 2009-10-13 | Wind River Systems, Inc. | System and method for managing client processes |
| US8527318B2 (en) * | 2003-04-30 | 2013-09-03 | Sap Ag | Campaign management in multiple communication channels |
| US20070115920A1 (en) * | 2005-10-18 | 2007-05-24 | Microsoft Corporation | Dialog authoring and execution framework |
| US20080215352A1 (en) * | 2007-02-07 | 2008-09-04 | Seaton Corp. | Method and apparatus for recruiting students |
| US8363819B2 (en) * | 2010-07-27 | 2013-01-29 | Genesys Telecommunications Laboratories, Inc. | Collaboration system and method |
| US8582475B1 (en) | 2012-10-30 | 2013-11-12 | Google Inc. | System and method for blended PSTN and computer network customer support interactions |
| US9740513B2 (en) * | 2014-06-05 | 2017-08-22 | Futurewei Technologies, Inc. | System and method for real time virtualization |
| US20210314653A1 (en) * | 2020-04-02 | 2021-10-07 | Rovi Guides, Inc. | Systems and methods for delayed pausing |
| WO2023157296A1 (ja) * | 2022-02-21 | 2023-08-24 | Ｎｔｔテクノクロス株式会社 | 応対支援システム、応対支援方法及びプログラム |
Family Cites Families (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2910795B2 (ja) | 1991-05-21 | 1999-06-23 | 富士通株式会社 | テレマーケティングサービス方式 |
| US5815566A (en) | 1991-10-10 | 1998-09-29 | Executone Information Systems, Inc. | Apparatus and method for dynamic inbound/outbound call management and for scheduling appointments |
| US5247569A (en) | 1992-01-13 | 1993-09-21 | Intervoice, Inc. | System and method for controlling outbound and inbound calls in a telephone communication system |
| AU4280793A (en) | 1992-10-21 | 1994-05-09 | Digital Systems International, Inc. | Integrated intelligent call blending |
| US5586179A (en) * | 1993-03-17 | 1996-12-17 | Davox Corporation | System and method for adding and integrating outbound calling and overall system control to an existing inbound telephone system |
| JPH0730946A (ja) | 1993-07-08 | 1995-01-31 | N T T Idou Tsuushinmou Kk | 移動通信サービス制御装置 |
| WO1995008236A2 (en) | 1993-09-17 | 1995-03-23 | Executone Information Systems, Inc. | Telephone call center |
| EP0684719A1 (en) * | 1994-05-25 | 1995-11-29 | International Business Machines Corporation | Method and apparatus for transmission of high priority traffic on low speed communication links |
| US5519773A (en) | 1994-06-07 | 1996-05-21 | Siemens Colm Communications Inc. | Call sharing for inbound and outbound call center agents |
| US5793861A (en) * | 1996-06-11 | 1998-08-11 | Executone Information Systems, Inc. | Transaction processing system and method |
| US5761289A (en) | 1996-08-13 | 1998-06-02 | At&T Corp | 800 number callback |
| US5901296A (en) * | 1996-12-06 | 1999-05-04 | International Business Machines Corporation | Distributed scheduling for the transfer of real time, loss sensitive and non-real time data over a bus |
| US5926539A (en) | 1997-09-12 | 1999-07-20 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for determining agent availability based on level of uncompleted tasks |
| US6044146A (en) | 1998-02-17 | 2000-03-28 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for call distribution and override with priority |
| US6263066B1 (en) | 1997-02-06 | 2001-07-17 | Genesys Telecommunications Laboratories, Inc. | Multimedia managing and prioritized queuing system integrated with intelligent routing capability |
| US5982873A (en) | 1997-03-07 | 1999-11-09 | Lucent Technologies Inc. | Waiting-call selection based on objectives |
| US6046762A (en) | 1997-04-01 | 2000-04-04 | Cosmocom, Inc. | Multimedia telecommunication automatic call distribution system |
| JP3803712B2 (ja) * | 1997-04-30 | 2006-08-02 | 富士通株式会社 | ノンリアルタイム通信のバンド幅制限値の動的制御方式 |
| US6338046B1 (en) * | 1997-10-06 | 2002-01-08 | Nokia Telecommunications, Oy | System and method for determining charges for usage of a network connection |
| US6188670B1 (en) * | 1997-10-31 | 2001-02-13 | International Business Machines Corporation | Method and system in a data processing system for dynamically controlling transmission of data over a network for end-to-end device flow control |
| US5991393A (en) | 1997-11-04 | 1999-11-23 | Genesys Telecommunicaitons, Laboratories, Inc. | Method for telephony call blending |
| US6272109B1 (en) * | 1997-11-18 | 2001-08-07 | Cabletron Systems, Inc. | Hierarchical schedules for different ATM traffic |
| US6704409B1 (en) * | 1997-12-31 | 2004-03-09 | Aspect Communications Corporation | Method and apparatus for processing real-time transactions and non-real-time transactions |
| US6226377B1 (en) * | 1998-03-06 | 2001-05-01 | Avaya Technology Corp. | Prioritized transaction server allocation |
| US6721325B1 (en) * | 1998-04-23 | 2004-04-13 | Alcatel Canada Inc. | Fair share scheduling of multiple service classes with prioritized shaping |
| JP2000244568A (ja) | 1999-02-23 | 2000-09-08 | Hitachi Ltd | マルチメディア呼分配システム |
| US6985576B1 (en) * | 1999-12-02 | 2006-01-10 | Worldcom, Inc. | Method and apparatus for automatic call distribution |
-
2000
- 2000-03-30 JP JP2000093114A patent/JP3535068B2/ja not_active Expired - Fee Related
- 2000-11-22 US US09/717,262 patent/US7519665B1/en not_active Expired - Fee Related
- 2000-11-28 GB GB0028988A patent/GB2363283B/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| GB2363283B (en) | 2004-02-11 |
| US7519665B1 (en) | 2009-04-14 |
| GB0028988D0 (en) | 2001-01-10 |
| JP2001285492A (ja) | 2001-10-12 |
| GB2363283A (en) | 2001-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6798877B2 (en) | Enhanced end user automatic call distributor control | |
| US7395310B1 (en) | Method and apparatus to queue a plurality of transaction messages | |
| US6449356B1 (en) | Method of multi-media transaction processing | |
| US6850612B2 (en) | End user automatic call distributor network control | |
| US6937715B2 (en) | Contact center management | |
| US7110524B2 (en) | Method and system for call queueing and customer application interaction | |
| CN103024217B (zh) | 一种实现客服业务的方法及客服系统 | |
| KR100359586B1 (ko) | 자동 호출 분배 방법 및 장치 | |
| US5903877A (en) | Transaction center for processing customer transaction requests from alternative media sources | |
| US8320550B2 (en) | Method and system for assigning tasks to workers | |
| JP2006339810A (ja) | 配車受付システム | |
| JP2000307736A (ja) | 通信処理システムにおいて通信を処理する方法およびシステム | |
| US6801620B2 (en) | Enhanced agent automatic call distribution control | |
| US6813349B2 (en) | Communication of user data to an automatic call distributor agent | |
| JP2002523826A (ja) | 自動呼配分器におけるｅメールの処理方法 | |
| US20050213742A1 (en) | Call center system and call reservation method | |
| JP3535068B2 (ja) | マルチチャネル処理の制御装置およびマルチチャネル処理の制御方法 | |
| AU2004205096A1 (en) | Skill based chat function in a communication system | |
| JP2003517219A (ja) | 電話交換機において呼を制御するためのニューラルネットワーク | |
| JPH05130246A (ja) | 配送情報自動通知方法 | |
| JP2002232566A (ja) | コールセンタ運営統計収集システム | |
| JP4308081B2 (ja) | 着信呼分配システム、着信呼分配方法、及び着信呼分配制御装置 | |
| EP1511285A2 (en) | Improved load balancing in a network of contact centres | |
| JP2003319074A (ja) | マルチチャネル処理の制御方法およびマルチチャネル処理システム | |
| US8498402B2 (en) | Customer support using managed real-time communities |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040309 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040310 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3535068 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080319 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090319 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100319 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100319 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110319 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110319 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120319 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130319 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140319 Year of fee payment: 10 |
|
| LAPS | Cancellation because of no payment of annual fees |