JP4132601B2 - 着信呼制御装置及び方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、例えば、電話（音声通話）システムにより顧客（ユーザ）からの問い合わせや要求に応対するコールセンタシステムなどにおいて、顧客からの着信呼を複数の受付（オペレータ）端末のいずれかに着信させる制御に用いて好適な、着信呼制御装置及び方法に関する。
【０００２】
【従来の技術】
近年、顧客サポートやクレーム対応のために電話システムと顧客データベースを連携したコールセンタシステムは、ＣＲＭ（Customer Relationship Management）において重要な役割を担っている。特に、顧客からの電話に対して受付台（受付端末）においてスムーズな対応を行なうことはサービス性の向上のために重要である。
【０００３】
このため、従来のコールセンタシステム（ＣＲＭシステム）では、例えば、顧客の発信者番号情報を基に電話をかけてきた顧客を特定し、その顧客に関する登録情報（個人情報など）を会員データベースから取得してオペレータ端末（パーソナルコンピュータなど）上に表示させることが一般に行なわれ、これにより、オペレータは、電話をかけてきた顧客情報を閲覧しながらその顧客と音声通話による応対サービスを展開することが可能である。
【０００４】
ところで、このようなコールセンタシステムでは、通常、自動呼分配（ACD：Automatic Call Distribution）と呼ばれる機能により、着信呼を複数台存在するオペレータ端末（以下、受付台ともいう）に均等に着信させるようになっており、全てのオペレータ端末が通話中状態の時には、お待たせメッセージを流すなどして、受付台が空くまで顧客を待たせる運用であった。
【０００５】
【発明が解決しようとする課題】
しかしながら、顧客の待ち時間が長くなることはサービス性の低下につながるため、顧客からの電話に対して待ち時間をいかに短くするかはサービス向上のために非常に重要な課題である。特に、顧客の中でも大口取引者などの重要顧客（ＶＩＰ：Very Important Person）からの電話に対しては待ち合わせ無し、あるいは、最小限の待ち時間での対応をすることが望まれる。
【０００６】
そこで、例えば、重要顧客からの電話（ＶＩＰ呼）を専門に受け付ける受付台を何台か用意しておくことも考えらるが、このようにＶＩＰ呼専用の受付台を用意すると、受付台資源及びオペレータ人材を効率的に利用することができない。即ち、ＶＩＰ呼が頻繁にかかってくるような場合はＶＩＰ呼専用の受付台に着信呼が集中してＶＩＰ呼担当のオペレータに負荷が集中することになり、逆に、ＶＩＰ呼が少ない場合はＶＩＰ呼専用の受付台はほとんど稼働せずＶＩＰ呼担当のオペレータは手すきになるという現象が生じる。
【０００７】
また、従来は、例えば、特開２０００−６９１６８号公報に示されているように、顧客が指定したオペレータ、あるいは、顧客が指定したランク（習熟度）を満足するオペレータに、自動的に呼を着信させる技術も提案されているが、このような公知技術においても、一部のオペレータ（ランクの高いオペレータなど）に対して呼が集中しやすく、受付台資源及びオペレータ人材の効率的な運用は望めない。
【０００８】
また、この公知技術では、ＶＩＰ呼を意識した着信制御を行なわないので、全受付台通話中のためにＶＩＰ呼が待たされる確率が、他の非ＶＩＰ呼（以下、一般呼ともいう）と同程度に発生することになり、重要顧客に対するサービス性が低下してしまうことにもなる。
本発明は、このような課題に鑑み創案されたもので、受付端末資源及びオペレータ人材の効率的な運用を図りながら、ＶＩＰ呼などの特定の呼に対しても待ち合わせ無し、あるいは、最小限の待ち時間で応対できるようにした、着信呼制御装置及び方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記の目的を達成するために、本発明の着信呼制御装置は、特定の着信呼に応答すべき特定着信呼用受付端末と当該特定着信呼用受付端末以外の非特定着信呼用受付端末とのいずれかに設定されるｎ台の受付端末のうち空き状態となった任意のｍ台（ただし、ｎ，ｍはｎ＞ｍを満足する自然数）を、上記の空き状態となった受付端末の設定状態によらず、該特定着信呼用受付端末として設定する特定着信呼用受付端末設定手段と、着信呼が特定の着信呼かどうかを識別する着信呼識別手段と、この着信呼識別手段で上記の着信呼が特定の着信呼であると識別されると、その着信呼を上記の特定着信呼用受付端末に着信させる着信制御手段とをそなえて成ることを特徴としている。
【００１０】
上述のごとく構成された本発明の着信呼制御装置では、ｎ台の受付端末のうち空き状態となった任意のｍ台が、特定の呼に応答すべき特定着信呼用受付端末として、常時、確保されるので、特定の着信呼が応答待ち状態になる確率が最小限に抑制される。また、このとき、空き状態となった受付端末が特定着信呼用受付端末となるので、受付端末グループ内において特定着信呼用受付端末となる受付端末は、適宜、変更される（固定されない）（以上、請求項１，４，５）。
【００１１】
ここで、上記の特定着信呼用受付端末設定手段は、空き状態となった受付端末から順番にｍ台分を上記の特定着信呼用受付端末として設定するように構成してもよく、このようにすれば、簡単な制御で、所望数の受付端末を特定着信呼用受付端末として確保することができる（請求項２）。
また、上記の着信制御手段は、上記の特定着信呼用受付端末が全て応答中の場合に、特定着信呼用受付端末以外の非特定着信呼用受付端末に空き状態の受付端末が存在すると、その受付端末に特定の着信呼を着信させる非特定着信呼用受付端末着信手段をそなえていてもよい。このようにすれば、特定の着信呼が応答待ち状態になる確率がさらに低減される（請求項３）。
【００１２】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
（Ａ）一実施形態の説明
図１は本発明の一実施形態としての着信呼制御装置が適用されるコールセンタシステムを示すブロック図で、この図１に示すコールセンタシステム１は、公衆網８に接続された構内交換機（ＰＢＸ）２，この構内交換機２にそれぞれ収容された発信者情報受信装置３及び複数の受付台（受付端末；電話機など）４１−１〜４１−ｎから成る受付台グループ４，呼制御装置５，ＬＡＮ（Local Area Network）などの所望のネットワーク６を介して発信者情報受信装置３と呼制御装置５と通信可能に接続され顧客情報などを管理するデータベースサーバ７をそなえて構成されており、上記のＰＢＸ２，発信者情報受信装置３，呼制御装置５及びデータベースサーバ７から成る部分が本実施形態の着信呼制御装置１１として機能するようになっている。
【００１３】
ここで、まず、上記のＰＢＸ２は、呼制御装置５からの制御に従って、公衆網８から着信してきた呼を受付台４１−ｉ（ｉ＝１〜ｎ）のいずれかに接続するためのものであり、発信者情報受信装置３は、加入者端末（電話機など）９から電話をかけてきた顧客（発信者）を特定するための情報を受信するもので、本実施形態では、例えば、上記の加入者端末９（以下、発信者９、あるいは、顧客９と表記することもある）に対して、事前の会員登録手続きなどによってデータベースサーバ７に既に登録済みの情報（発信者識別情報；カスタマーＩＤやクレジットカード番号など）の入力を促すことにより発信者９によって入力される発信者識別情報を受信するためのものである。
【００１４】
このため、本発信者情報受信装置３は、その要部に着目すると、図１中に示すように、ＰＢＸインタフェース部３１，メッセージ送出部３２，ＤＴＭＦ（Dual Tone Multiple Frequency）信号受信部３３，記憶装置３４及びＬＡＮインタフェース部３５などをそなえて構成されている。
ここで、上記のＰＢＸインタフェース部３１は、ＰＢＸ２との間で送受される信号のインタフェースをとる（プロトコル変換などを行なう）ためのものであり、メッセージ送出部３２は、受付台グループの受付端末（以下、受付台ともいう）４１−ｉのいずれかに着信呼が接続される前に、上記の発信者９に対して例えば「カスタマーＩＤを入力して下さい。」などといった自動音声応答メッセージをＰＢＸインタフェース部３１及びＰＢＸ２を介して送出するためのものである。
【００１５】
また、ＤＴＭＦ信号受信部３３は、上記の自動音声応答メッセージに対する発信者９の端末（電話機）操作によりＤＴＭＦ信号〔プッシュボタン（ＰＢ）音〕信号として発信者９から受信される発信者識別情報を受信するためのものであり、記憶装置３４は、その受信発信者識別情報を記憶するためのものであり、ＬＡＮインタフェース部３５は、ＬＡＮ６上で送受される信号とのインタフェースをとる（プロトコル変換などを行なう）ためのもので、本ＬＡＮインタフェース部３５からＬＡＮ６を介して上記の発信者識別情報をデータベースサーバ７に提供することができるようになっている。
【００１６】
そして、データベースサーバ７は、上記の発信者識別情報と予め登録されている顧客情報とに基づいて発信者９を特定して、その発信者９が重要顧客であるか否かを識別（判定）することにより、上記の着信呼が重要顧客からの着信呼（特定の着信呼）であるか否かを識別する着信呼識別部７１としての機能を有するもので、その識別結果は、ＬＡＮ６を介して、後述する呼制御装置５（呼制御部５３）に通知されるようになっている。
【００１７】
次に、上記の各受付台４１−ｉは、それぞれ、発信者９に対して音声通話による応対サービスを提供するためのもので、本実施形態では、受付台制御部４１１や液晶ディスプレイなどの表示部４１２がそなえられていることを前提としている。なお、本受付台４１−ｉは、電話機能付きのパーソナルコンピュータなどとして構成されていてもよい。
【００１８】
また、呼制御装置５は、基本的に、ＰＢＸ２による発信者９と受付台４１−ｉとの呼接続を制御するとともに、データベースサーバ７と連携して発信者９についての顧客情報を、ＰＢＸ２を介して受付台４１−ｉに提供するためのもので、これにより、受付台４１−ｉのオペレータは、表示部４１２に表示された発信者９についての顧客情報を閲覧しながらの音声通話による応対が可能になる。
【００１９】
このため、本呼制御装置５は、その要部に着目すると、図１中に示すように、ＰＢＸインタフェース部５１，呼情報送受信部５２，呼制御部５３，ＬＡＮインタフェース部５４及び記憶装置５５をそなえて構成されている。
ここで、上記のＰＢＸインタフェース部５１は、ＰＢＸ２とのインタフェースをとるためのものであり、呼情報送受信部５２は、発信者９からの呼接続要求（ＳＥＴＵＰ）信号の受信やその受信ＳＥＴＵＰ信号に対する呼の接続要求（ＣＯＮＮＥＣＴ）信号の送信など、一連の呼接続処理（シーケンス）を実行するのに必要な信号の送受を呼制御部５３からの指示に従って行なうためのものであり、ＬＡＮインタフェース部５４は、呼制御部５３とデータベースサーバ７との通信時にＬＡＮ６とのインタフェースをとる（プロトコル変換などを行なう）ためのものである。
【００２０】
また、呼制御部５３は、基本機能として、上記の呼接続処理や、上述のごとく発信者９の顧客情報を受付台４１−ｉに提供するためのＬＡＮインタフェース部５４を介したデータベースサーバ７との通信処理などを統括して制御する機能を有するものであるが、本実施形態では、記憶装置５５において記憶・管理されている受付台応答順位管理情報５００に基づいて、重要顧客９からの着信呼（以下、ＶＩＰ呼という）、もしくは、それ以外の着信呼（以下、非ＶＩＰ呼、又は、一般呼という）を着信すべき受付台４１−ｉを決定し、その決定に応じてＰＢＸ２を制御することにより、着信呼（ＶＩＰ呼あるいは非ＶＩＰ呼）を所定の受付台４１−ｉに着信させるための機能も有している。
【００２１】
具体的に、記憶装置５５には、上記の受付台応答順位管理情報５００として、例えば図５中に示すように、ＶＩＰ呼を着信させるべき（ＶＩＰ呼に応答すべき）受付台４１−ｉが所定台数（ｍ台；ただし、ｍはｎ＜ｍを満足する自然数）分登録可能なＶＩＰ呼応答順位テーブル５０１と、ＶＩＰ呼以外の着信呼を着信すべき受付台４１−ｉがｎ台分登録可能な非ＶＩＰ呼応答順位テーブル５０２とが記憶・管理されている。なお、本記憶装置５５には、呼制御部５３が動作する上で必要な呼制御プログラムや加入者情報，呼処理履歴，課金情報なども記憶されている。
【００２２】
そして、呼制御部５３は、着信呼がＶＩＰ呼の場合は上記のＶＩＰ呼応答順位テーブル５０１に最も古く登録された受付台（ＶＩＰ呼第１応答受付台）４１−ｉをそのＶＩＰ呼の着信先受付台４１−ｉとして決定してＰＢＸ２を制御し、着信呼が非ＶＩＰ呼の場合は上記の非ＶＩＰ呼応答順位テーブル５０２に最も古く登録された受付台（非ＶＩＰ呼第１応答受付台）４１−ｉを非ＶＩＰ呼の着信先受付台４１−ｉとして決定してＰＢＸ２を制御する。
【００２３】
なお、上記の各応答順位テーブル５０１，５０２には、いずれも、空き状態（非応答中）の受付台４１−ｉのみが登録され、応答中状態に遷移した受付台４１−ｉの登録は削除され、以降に登録されている受付台４１−ｉの順位は１つずつ繰り上がる。また、ＶＩＰ呼応答順位テーブル５０１に登録された受付台４１−ｉはＶＩＰ呼専用の受付台４１−ｉとなり、非ＶＩＰ呼のための受付台４１−ｉとしては使用されない。
【００２４】
さらに、ＶＩＰ呼応答順位テーブル５０１には、初期状態では任意のｍ台の受付台４１−ｉがＶＩＰ呼第１〜第ｍ応答受付台４１−ｉとして登録され、その後は、空き状態となった受付台４１−ｉが生じる毎に、呼制御部５３によって、最も古く登録された受付台（ＶＩＰ呼第１応答受付台４１−ｉ）が非ＶＩＰ呼応答順位テーブル５０２の最後にスライド登録される〔このとき、ＶＩＰ呼応答順位テーブル５０１における受付台４１−ｉの応答順位は１つ上がる（ＶＩＰ呼第ｍ応答受付台４１−ｉは第ｍ−１応答受付台４１−ｉとなる）〕とともに、上記の空き状となった受付台４１−ｉがＶＩＰ呼応答順位テーブル５０１の最後に（ＶＩＰ呼第ｍ応答受付台４１−ｉとして）追加登録される。
【００２５】
つまり、本実施形態の呼制御部５３は、空き状態となった受付台４１−ｉをそれまで応答していた着信呼の呼の種別（ＶＩＰ呼／非ＶＩＰ呼）に関わらず全て一旦ＶＩＰ呼応答順位テーブル５０１に登録することで、常に、空き状態となった受付台４１−ｉを順番に所定台数分だけＶＩＰ呼応答受付台４１−ｉとして確保しておき、ＶＩＰ呼が発生すると、そのＶＩＰ呼を確保したＶＩＰ呼応答受付台４１−ｉに確保順に着信させるように動作するのである。
【００２６】
このため、本呼制御部５３は、例えば図２に示すように、ｎ台の受付端末のうち空き状態となった任意のｍ台を、ＶＩＰ呼に応答すべきＶＩＰ呼応答受付台４１−ｉとしてＶＩＰ呼応答順位テーブル５０１に登録（設定）しうるＶＩＰ呼応答受付台設定部５３Ａとしての機能と、データベースサーバ７（着信呼識別部７１）で着信呼がＶＩＰ呼であると識別されると、そのＶＩＰ呼をＶＩＰ呼応答順位テーブル５０１におけるＶＩＰ呼第１応答受付台４１−ｉに着信させる着信制御部５３Ｂとしての機能とを有していることになる。
【００２７】
なお、上記のＶＩＰ呼応答受付台設定部５３Ａは、空き状態の受付台４１−ｉが所定台数（ｍ台）を超えた場合の前記非ＶＩＰ呼応答順位テーブル５０２へのスライド登録を行なう機能も兼用している。
そして、上記の着信制御部５３Ｂは、本実施形態では、上記の機能以外に、この図２に示すように、次のような機能部も有している。
【００２８】
▲１▼非ＶＩＰ呼用着信制御部５３Ｂ−１
この非ＶＩＰ呼用着信制御部（非特定着信呼用受付端末着信手段）５３Ｂ−１は、上記のＶＩＰ呼応答順位テーブル５０１に登録されているＶＩＰ呼応答受付台４１−ｉの全てが話し中（応答中）状態の場合に、非ＶＩＰ呼応答順位テーブル５０２における非ＶＩＰ呼第１応答受付台４１−ｉにＶＩＰ呼を着信させるようＰＢＸ２を制御する。
【００２９】
▲２▼ＶＩＰ呼設定通知部５３Ｂ−２
このＶＩＰ呼設定通知部（特定着信呼用受付端末設定通知手段）５３Ｂ−２は、ＶＩＰ呼応答受付台設定部５３ＡによってＶＩＰ呼応答順位テーブル５０１に登録されたＶＩＰ呼応答受付台４１−ｉに対して、その受付台４１−ｉがＶＩＰ呼専用の受付台４１−ｉとして設定された旨を通知する。これにより、受付台４１−ｉの表示部４１２において通知情報が表示されるなどして、オペレータは自身がＶＩＰ呼担当になったことを認識することができる。なお、この通知は、音声によって直接行なっても良い。また、前記のスライド登録により、非ＶＩＰ呼応答受付台となった受付台４１−ｉには、その旨が通知される。
【００３０】
▲３▼応答待ち呼キュー管理部５３Ｂ−３
この応答待ち呼キュー管理部（応答待ち着信呼管理手段）５３Ｂ−３は、図７（Ａ）に模式的に示すように、全ての受付台４１−ｉが応答中の場合に応答待ちとなっている全着信呼についての着信順を応答待ち呼キュー５３１により管理する。この応答待ち呼キュー５３１に最も古く登録された待ち呼から順に空き状態となった受付台４１−ｉに待ち呼が着信する。
【００３１】
▲４▼応答待ち呼キュー制御部５３Ｂ−４
この応答待ち呼キュー制御部（応答待ち着信呼制御手段）５３Ｂ−４は、全ての受付台４１−ｉが応答中のときにＶＩＰ呼を受けると、上記の応答待ち呼キュー５３１の登録順序（つまり、呼の着信順序）を制御して、図７（Ｂ）に模式的に示すように、そのＶＩＰ呼を上記の応答待ち呼キュー５３１の非ＶＩＰ呼の前（最初のＶＩＰ呼の場合は先頭）に割り込ませることにより、そのＶＩＰ呼を非ＶＩＰ呼よりも先に空き状態の受付台４１−ｉに着信させるようにするためのもので、これにより、ＶＩＰ呼は全受付台４１−ｉが応答中で待ち状態となっても、最小の待ち時間で済むことになる。
【００３２】
▲５▼ＶＩＰ呼応答待ち通知部５３Ｂ−５
このＶＩＰ呼応答待ち通知部（特定着信呼応答待ち通知手段）５３Ｂ−５は、上記の応答待ち呼キュー５３１にＶＩＰ呼が登録・管理されていることを全受付台４１−ｉに通知するためのもので、その通知情報は、受付台４１−ｉの表示部４１２に表示されるようになっている。これにより、全オペレータは、待ち状態となっているＶＩＰ呼が存在していることを認識することができる。
【００３３】
なお、上述した図２に示す呼制御部５における各部５３Ａ，５３Ｂ（５３Ｂ−１〜５３Ｂ−４）は、ハードウェアとしてそなえられているわけではなく、図示しないＣＰＵ（Central Processing Unit）などが所定のソフトウェア（プログラム）に従って動作することによって実現される。
以下、上述のごとく構成された本実施形態のコールセンタシステム１の動作について詳述する。
【００３４】
まず、コールセンタシステム１では、呼制御装置５において、図３に示すように、着信呼があるか否かを監視しており（ステップＳ１）、例えば、発信者９から呼がＰＢＸ２に着信してくると（ステップＳ１でＹＥＳの場合）、呼制御装置５は、発信者情報受信装置５及びデータベースサーバ７と連携して、次のような着信制御処理を実行する（ステップＳ２）。
【００３５】
即ち、呼制御装置５（呼制御部５３）は、ＰＢＸ２を制御して、発信者からの着信呼を、一旦、発信者情報受信装置３に接続する。すると、発信者情報受信装置３は、発信者９に対して発信者識別情報の入力を促すメッセージをメッセージ送出部３２から自動送出する。このメッセージを聴取した発信者９が、電話機操作により発信者識別情報を入力すると、その発信者識別情報が、ＤＴＭＦ信号としてＤＴＭＦ信号受信部３３で受信され、記憶装置３４に記憶される。
【００３６】
そして、この発信者識別情報は、ＬＡＮインタフェース部３５を介してＬＡＮ６によりデータベースサーバ７に送られる。データベースサーバ７では、受信した発信者識別情報を基に発信者がＶＩＰ顧客であるか、非ＶＩＰ顧客であるかを判定して、その判定結果を呼制御装置５（呼制御部５３）へ送出する。呼制御部５３は、図４に示すように、上記の判定結果がＶＩＰ呼であれば（ステップＳ２１でＹＥＳなら）、次に、ＶＩＰ呼応答順位テーブル５０１に受付台４１−ｉが登録されているか（つまり、空き状態のＶＩＰ呼応答受付台４１−ｉが存在するか）を確認する（ステップＳ２２）。
【００３７】
この結果、ＶＩＰ呼応答順位テーブル５０１に受付台４１−ｉが登録されていれば、呼制御部５３は、ＶＩＰ呼第１応答受付台として登録されている受付台４１−ｉを上記のＶＩＰ呼の着信先として決定し（ステップＳ２２のＹＥＳルートからステップＳ２３）、着信制御部５３Ｂによって、決定した受付台４１−ｉにＶＩＰ呼が着信するようＰＢＸ２を制御してそのＶＩＰ呼を上記の決定受付台４１−ｉに着信させる（ステップＳ２４；図５中のステップＡ１）。
【００３８】
そして、呼制御部５３は、ＶＩＰ呼応答受付台設定部５３Ａによって、ＶＩＰ呼応答順位テーブル５０１において、ＶＩＰ呼第１応答受付台として登録されていた受付台４１−ｉの登録を抹消するとともに、以降のＶＩＰ呼応答受付台としての登録があればその受付台４１−ｉの順位を繰り上げて、ＶＩＰ呼応答順位テーブル５０１の内容を更新する（ステップＳ２５）。
【００３９】
一方、上記の着信呼が非ＶＩＰ呼であった場合（ステップＳ２１でＮＯの場合）、もしくは、上記の着信呼はＶＩＰ呼であるが、ＶＩＰ呼応答受付台に空きが無かった場合（ステップＳ２１でＹＥＳ、且つ、ステップＳ２２でＮＯの場合）、呼制御部５３は、いずれも、非ＶＩＰ呼応答順位テーブル５０２を参照して、非ＶＩＰ呼応答受付台４１−ｉの登録があるかどうかを確認し（ステップＳ２６）、登録があれば、その受付台（非ＶＩＰ呼第１応答受付台）４１−ｉを非ＶＩＰ呼、あるいは、ＶＩＰ呼の着信先として決定する（ステップＳ２６のＹＥＳルートからステップＳ２７）。
【００４０】
そして、呼制御部５３は、着信制御部５３Ｂの非ＶＩＰ呼用着信制御部５３Ｂ−１によって、上述のごとく着信呼の着信先として決定した非ＶＩＰ呼応答受付台４１−ｉに上記の着信呼（非ＶＩＰ呼／ＶＩＰ呼）が着信するようＰＢＸ２を制御してその着信呼を非ＶＩＰ呼応答受付台４１−ｉに着信させる（ステップＳ２８；図５中のステップＡ２，Ａ３）。
【００４１】
その後、呼制御部５３は、ＶＩＰ呼応答受付台設定部５３Ａによって、非ＶＩＰ呼応答順位テーブル５０２において、非ＶＩＰ呼第１応答受付台として登録されていた上記の受付台４１−ｉの登録を抹消するとともに、以降の非ＶＩＰ呼応答受付台としての登録があればその受付台４１−ｉの順位を繰り上げて、非ＶＩＰ呼応答順位テーブル５０２の内容を更新する（ステップＳ２９）。
【００４２】
ところで、着信呼があったときに全受付台４１−ｉが応答中であった場合（つまり、各応答順位テーブル５０１，５０２のいずれにも受付台４１−ｉが登録されていない状態の場合；ステップＳ２６でＮＯの場合）、呼制御部５３は、そのときの着信呼（ＶＩＰ呼／非ＶＩＰ呼）を応答待ちキュー管理部５３Ｂ−３における応答待ち呼キュー５３１に登録する（ステップＳ３０）。
【００４３】
ただし、このとき、応答待ち呼キュー５３１への登録対象の着信呼が非ＶＩＰ呼であった場合、その着信呼は、非ＶＩＰ待ち呼として、通常通り、応答待ち呼キュー５３１の最後に登録され、登録対象の着信呼がＶＩＰ呼であった場合、そのＶＩＰ呼は、図７（Ｂ）にて前述したように、応答待ち呼キュー制御部５３Ｂ−４によって、応答待ち呼キュー５３１の非ＶＩＰ待ち呼よりも前に着信した呼として登録される。
【００４４】
これにより、上記のＶＩＰ待ち呼は、受付台４１−ｉが空き次第、その受付台４１−ｉに着信することになる。つまり、ＶＩＰ呼は全受付台４１−ｉが応答中で待ち状態となっても、最小限の待ち時間で、所望の受付台４１−ｉに接続されるのである。
そして、応答待ち呼キュー５３１にＶＩＰ呼が登録されて応答待ち呼キュー管理部５３Ｂ−３においてＶＩＰ呼が管理される場合（ステップＳ３１でＹＥＳの場合）、呼制御部５３は、その旨をＶＩＰ呼応答待ち通知部５３Ｂ−５によって、ＰＢＸ２を介して全受付台４１−ｉに通知する（ステップＳ３２）。これにより、全受付台４１−ｉのオペレータは、待ち状態のＶＩＰ呼が存在することを認識することができる。
【００４５】
ところで、或る着信呼（ＶＩＰ呼／非ＶＩＰ呼）に対して応答中だった受付台４１−ｉが、回線切断により空き状態となり、呼制御部５３に回線切断情報が通知されると（図３に示すステップＳ３でＹＥＳの場合）、呼制御部５３（ＶＩＰ呼応答受付台設定部５３Ａ）は、まず、ＶＩＰ呼応答順位テーブル５０１に予め設定した台数分（ｍ台）の応答待ち状態（空き状態）の受付台４１−ｉが既に登録されているか否かを確認する（ステップＳ４）。
【００４６】
その結果、ｍ台分の空き受付台４１−ｉがＶＩＰ呼応答受付台として登録されていなければ、呼制御部５３（ＶＩＰ呼応答受付台設定部５３Ａ）は、空き状態となった上記の受付台４１−ｉをＶＩＰ呼応答順位テーブル５０１に追加登録してＶＩＰ呼応答順位テーブル５０１を更新する（ステップＳ４のＮＯルートからステップＳ５；図５中のステップＡ４）。
【００４７】
一方、ｍ台分の空き受付台４１−ｉがＶＩＰ呼応答受付台として既に登録されていれば、呼制御部５３（ＶＩＰ呼応答受付台設定部５３Ａ）は、ＶＩＰ呼応答順位テーブル５０１において最も古い登録（ＶＩＰ呼第1応答受付台４１−ｉ）を非ＶＩＰ呼応答順位テーブル５０２の最後に非ＶＩＰ呼応答受付台４１−ｉとしてスライド登録するとともに、空き状態となった上記の受付台４１−ｉをＶＩＰ応答順位テーブル５０１の最後に（ＶＩＰ呼第ｍ応答受付台として）登録して、各応答順位テーブル５０１，５０２をそれぞれ更新する（ステップＳ４のＹＥＳルートからステップＳ６；図５中のステップＡ５，Ａ６）。
【００４８】
このようにして、本実施形態の呼制御部５３は、空き状態となった受付台４１−ｉをそれまで応答していた着信呼の呼の種別（ＶＩＰ呼／非ＶＩＰ呼）に関わらず全て一旦ＶＩＰ呼応答順位テーブル５０１に登録することで、常に、空き状態となった受付台４１−ｉを順番に所定台数分だけＶＩＰ呼応答受付台４１−ｉとして確保するように動作する。
【００４９】
ここで、この応答順位テーブル５０１，５０２に対する受付台４１−ｉの登録動作について、図６を用いてより具体的に説明する。なお、ここでは、便宜上、ｍ＝１、即ち、ＶＩＰ呼応答受付台４１−ｉの台数が１台である場合を例にする。また、図６では、受付台４１−１〜４１−ｎはそれぞれ「受付台１〜ｎ」と表記している。
【００５０】
まず、この図６に示すように、例えば、ＶＩＰ応答順位テーブル５０２にＶＩＰ呼応答受付台として受付台４１−２が登録されており、非ＶＩＰ応答順位テーブル５０２に非ＶＩＰ呼応答受付台として受付台４１−１が登録されている状態５５０−１で、新たなＶＩＰ呼が着信したとする。すると、このＶＩＰ呼には、受付台４１−２が応答し、各応答順位テーブル５０１，５０２の登録状態は状態５５１−１に遷移する。即ち、この状態５５１−１では、ＶＩＰ呼応答順位テーブル５０１に受付台４１−ｉは登録されていない。
【００５１】
かかる状態５５１−１で、さらに別のＶＩＰ呼が着信した場合、ＶＩＰ呼応答順位テーブル５０１に受付台４１−ｉは登録されていないが、非ＶＩＰ呼応答順位テーブル５０２に受付台４１−１が登録されていることから、この非ＶＩＰ呼応答受付台４１−１が上記のＶＩＰ呼に応答し、この結果、各応答順位テーブル５０１，５０２の登録状態は状態５５２−１に遷移する。
【００５２】
さらに、この状態５５２−１で、さらに別のＶＩＰ呼が着信した場合、各応答順位テーブル５０１，５０２のいずれにも受付台４１−ｉが登録されていないので、ＶＩＰ呼は応答待ち呼キュー５３１に非ＶＩＰ呼よりも前に着信した呼として登録されることになる。
次に、図６に示す初期状態５５０−１において、非ＶＩＰの着信があった場合、非ＶＩＰ呼応答順位テーブル５０２に非ＶＩＰ呼応答受付台４１−１の登録があることから、この非ＶＩＰ呼応答受付台４１−１が上記の非ＶＩＰ呼に応答し、その結果、各応答順位テーブル５０１，５０２の登録状態は状態５５１−２に遷移する。
【００５３】
かかる状態５５１−２で、さらに非ＶＩＰ呼が着信すると、この場合、ＶＩＰ呼応答順位テーブル５０１にＶＩＰ呼応答受付台４１−２の登録はあるが、非ＶＩＰ呼応答順位テーブル５０２に非ＶＩＰ呼応答受付台４１−ｉの登録が無いため、着信呼（非ＶＩＰ呼）は応答待ち呼キュー５３１の最後に入る。このとき、各応答順位テーブル５０１，５０２の登録状態に変化は無く、状態５５２−２となる。
【００５４】
次に、図６に示す初期状態５５０−１において、例えば、ＶＩＰ呼に応答していた受付台４１−３が呼の切断により空き状態となった場合は、状態５５１−３に遷移し、空きとなった受付台４１−３が、ＶＩＰ呼応答順位テーブル５０１に登録されるとともに、既に登録されていた受付台４１−２は、ＶＩＰ呼応答順位テーブル５０１からスライドして非ＶＩＰ呼応答順位テーブル５０２に登録される。
【００５５】
一方、図６に示す初期状態５５０−１において、例えば、非ＶＩＰ呼に応答していた受付台４１−４が呼の切断により空き状態となった場合は、状態５５１−４に遷移し、空きとなった受付台４１−４が、ＶＩＰ呼応答順位テーブル５０１に登録されるとともに、既に登録されていた受付台４１−２は、この場合も、ＶＩＰ呼応答順位テーブル５０１からスライドして非ＶＩＰ呼応答順位テーブル５０２に登録される。
【００５６】
以上のように、本実施形態によれば、ｎ台の受付端末のうち空き状態となった任意の受付台４１−ｉを順番にＶＩＰ呼応答順位テーブル５０１に登録してゆくことで、常に、任意のｍ台分の受付台４１−ｉがＶＩＰ呼に応答するＶＩＰ呼応受付台として確保されるので、どの空き受付台４１−ｉをどの応答順位に設定するかといった複雑な設定制御を必要とせずに、簡単な制御で、ＶＩＰ呼が応答待ち状態になる確率を最小限に抑制することができ、システム１（着信制御）の簡素化を図りながら、顧客に対する受付作業の大幅なサービス性向上を図ることができる。
【００５７】
また、この場合、空き状態となった受付台４１−ｉがＶＩＰ呼応答受付台となるので、受付台グループ４内においてＶＩＰ呼受付台となる受付台４１−ｉが固定されることはなく、空き状態となった受付台４１−ｉが生じる毎に、動的に変化する。従って、特定の受付台４１−ｉにＶＩＰ呼が集中するようなことも無く、受付台資源およびオペレータ人材の有効利用を図ることができる。
【００５８】
さらに、本実施形態では、ＶＩＰ呼応答受付台４１−ｉが全て応答中の場合でも、非ＶＩＰ呼応答受付台４１−ｉに空きがあれば、その非ＶＩＰ呼応答受付台４１−ｉがＶＩＰ呼に応答するので、さらに、ＶＩＰ呼が応答待ち状態になる確率を低減することができている。
また、全ての受付台４１−ｉが応答中のときに、ＶＩＰ呼が着信した場合でも、そのＶＩＰ呼は応答待ち呼キュー５３１に非ＶＩＰ呼よりも前に着信した呼として登録され、その後、受付台４１−ｉが空き次第、その受付台４１−ｉがＶＩＰ呼に応答するので、ＶＩＰ呼の待ち時間を最小限に抑えることができ、さらなるサービス性の向上を図ることができている。
【００５９】
さらに、ＶＩＰ呼／非ＶＩＰ呼応答受付台として登録された受付台４１−ｉには、その旨が通知されるので、オペレータは、自担当の受付台４１−ｉの現登録状況をリアルタイムに把握することができ、例えば、自担当の受付台４１−ｉがＶＩＰ呼応答受付台として登録されており次回の着信がＶＩＰ呼であることを事前に知ることができる。従って、上記のような通知を行なわない場合に比して、よりスムーズな応対（受付作業；応答業務）を実施することができる。
【００６０】
また、ＶＩＰ呼が応答待ち呼キュー５３１に登録されて待ち状態になっている場合には、その旨が全受付台４１−ｉに通知されるので、オペレータは、ＶＩＰ呼が待ち状態になっていることを意識しながら、受付作業を実施することができ、ＶＩＰ待ち呼に対して迅速な対応をとることが可能である。
なお、上述した実施形態では、全ての受付台４１−ｉが応答中のときに、ＶＩＰ呼が着信した場合、そのＶＩＰ呼は、常に、非ＶＩＰ呼よりも前に着信した呼として待ち呼キュー５３１に登録されるため、ＶＩＰ待ち呼が多く発生すると、非ＶＩＰ呼の待ち時間が非常に長くなる可能性がある。このような場合には、例えば、非ＶＩＰ待ち呼間にＶＩＰ待ち呼をランダムに割り込み登録することで、ＶＩＰ待ち呼の割り込みによる影響を緩和することが可能である。
【００６１】
また、上述した例では、応答待ち呼キュー管理部５３Ｂ−３において、１つの待ち呼キュー５３１で全ての応答待ち着信呼の着信順管理を行なっているが、例えば図８に模式的に示すように、ＶＩＰ呼用の待ち呼キュー５３１Ａと非ＶＩＰ呼（一般呼）用の待ち呼キュー５３１Ｂとを設けてＶＩＰ呼及び一般呼別にそれぞれの着信順を管理するようにしてもよい。
【００６２】
この場合、例えば図９に示すように、上記の着信制御部５３Ｂにおける応答待ち呼キュー制御部５３Ｂ−４の代わりに、応答待ち呼キュー管理部５３Ｂ−３において応答待ちのＶＩＰ呼が管理されている間は、その応答待ちのＶＩＰ呼を優先して空き状態となった受付台４１−ｉに着信させるＶＩＰ待ち呼優先制御部（応答待ち特定着信呼優先制御手段）５３Ｂ−６をそなえることで、次のような着信制御が可能である。
【００６３】
即ち、ＶＩＰ呼用の待ち呼キュー５３１Ａに１つでもＶＩＰ呼の登録があれば、受付台４１−ｉが空き次第、その受付台４１−ｉにＶＩＰ待ち呼を着信させ、ＶＩＰ呼用の待ち呼キュー５３１ＡにＶＩＰ呼の登録が無く、一般呼用の待ち呼キュー５３１Ｂに一般呼の登録があれば、非ＶＩＰ呼応答受付台４１−ｉが空き次第、その非ＶＩＰ呼応答受付台４１−ｉに一般待ち呼を着信させることができる。
【００６４】
これにより、上述したごとく１つの待ち呼キュー５３１における待ち呼の着信順を制御する場合と同様に、ＶＩＰ呼の待ち時間を最小限に抑えることができるとともに、本例の場合は、ＶＩＰ待ち呼を一般待ち呼の前や間に割り込ませる制御が不要なので、より単純な制御でＶＩＰ待ち呼の優先着信制御が実現可能である。
【００６５】
（Ｂ）第１変形例の説明
上述した実施形態では、空き状態となった受付台４１−ｉは、呼制御部５３（ＶＩＰ呼応答受付台設定部５３Ａ）によって、無条件にＶＩＰ呼応答順位テーブル５０１に登録される場合を説明したが、例えば図１０及び図１１に示すように、ＶＩＰ呼応答受付台設定部５３Ａに、受付台登録テーブル判定部５１０を設けて、所定の条件に従って、空き受付台４１−ｉの登録先を各応答順位テーブル５０１，５０２のいずれか振り分けるようにしてもよい。
【００６６】
ここで、この受付台登録テーブル判定部５１０による空き受付台４１−ｉの登録先の振り分け方については、様々な手法が考えられる。即ち、例えば、前回の応答でＶＩＰ呼に応答していた受付台４１−ｉは非ＶＩＰ呼応答順位テーブル５０２に登録し、前回の応答で一般呼に応答していた受付台４１−ｉはＶＩＰ呼応答順位テーブル５０１に登録するといった具合に、前回応答した着信呼の種別に応じて登録先を変えるようにしてもよいし、各受付台４１−ｉ毎にＶＩＰ呼及び一般呼に応答した回数をそれぞれ管理しておき、両方の呼に対して均等に応答するように登録先を変えるようにしてもよい。
【００６７】
また、ＶＩＰ呼の着信数を監視しておき、ＶＩＰ呼の着信数が多い場合は、空き受付台４１−ｉを優先してＶＩＰ呼応答順位テーブル５０１に登録し、逆に、ＶＩＰ呼の着信数が少ない場合は、空き受付台４１−ｉを非ＶＩＰ呼応答順位テーブル５０２に登録するといった手法を採ることも可能である。
なお、空き受付台４１−ｉの登録先振り分け以外の動作は、上述した実施形態と同様とする。つまり、いずれの手法を採った場合も、上述した実施形態と同様に、予め設定された所定台数（ｍ台）のＶＩＰ呼応答受付台４１−ｉを確保するように動作するのが基本である。
【００６８】
このように、受付台登録テーブル判定部５１０によって、所定の条件に従い、空き受付台４１−ｉの登録先を各応答順位テーブル５０１，５０２のいずれか振り分けるようにすれば、受付台４１−ｉに対する着信量の平均化（つまり、受付台資源及びオペレータ人材の有効利用）を重視した着信制御や、実際の着信量を重視した着信制御など、状況に応じた柔軟な制御が可能である。
【００６９】
なお、上記の受付台登録テーブル判定部５１０において、所定の条件として、空き受付台４１−ｉは常にＶＩＰ呼応答順位テーブル５０１に登録するという条件を設定した場合が、前述した実施形態に相当する。
（Ｃ）第２変形例の説明
上述した実施形態では、受付台応答順位管理情報５００として、ＶＩＰ呼応答順位テーブル５０１および非ＶＩＰ呼応答順位テーブル５０２という個別のテーブルにより、ＶＩＰ呼応答受付台４１−ｉおよび非ＶＩＰ呼応答受付台４１−ｉの登録を管理していたが、例えば図１２に示すように、１つの呼応答順位テーブル５１２により、ＶＩＰ呼／非ＶＩＰ呼応答受付台４１−ｉの双方を管理することも可能である。
【００７０】
即ち、この場合、呼制御部５３は、空き状態となった受付台４１−ｉを空き順に呼応答順位テーブル５１２の先頭から第１〜第ｎ応答受付台として登録してゆき、登録受付台４１−ｉがｍ＋１台以上ある場合には、着信呼がＶＩＰ呼であっても非ＶＩＰ呼であっても第1応答受付台４１−ｉにその着信呼を着信させる一方、登録受付台４１−ｉがｍ台以下の場合は着信呼がＶＩＰ呼であれば第１応答受付台４１−ｉにそのＶＩＰ呼を着信させるが、非ＶＩＰ呼の場合は着信させずに応答待ち呼キュー５３１（５３１Ｂでもよい）に登録するように動作する。
【００７１】
つまり、呼応答順位テーブル５１２に、所定台数（ｍ台）を超える受付台４１−ｉの登録がある状態では、ＶＩＰ呼／非ＶＩＰ呼に関わらず任意の空き受付台４１−ｉがその着信呼に応答するが、空き受付台４１−ｉの登録がｍ台以下しかない状態では、ＶＩＰ呼応答受付台領域５１１に位置する登録受付台４１−ｉの全てが自動的にＶＩＰ呼応答受付台となり、ＶＩＰ呼のみに応答するようになるのである。
【００７２】
なお、この場合も、着信呼に応答した（着信呼を着信させた）受付台（第１応答受付台）４１−ｉの登録は、呼応答順位テーブル５１２から削除され、第２応答受付台４１−ｉは第１応答受付台４１−ｉ、第３応答受付台４１−ｉは第２応答受付台４１−ｉという具合に、以降の登録受付台４１−ｉの応答順位がそれぞれ繰り上がる。
【００７３】
このように、本変形例においても、最低ｍ台の空き状態となった受付台４１−ｉがＶＩＰ呼応答受付台として自動的に確保されるので、ＶＩＰ呼が着信したときに空き受付台４１−ｉが無く、ＶＩＰ呼を待たせしまうようなことを限りなく少なくすることができる。
また、この場合も、ＶＩＰ呼応答受付台として登録される受付台４１−ｉは、固定されず、空き受付台４１−ｉの発生毎に、ＶＩＰ呼専用の受付台４１−ｉが受付台グループ４内で動的に変化するので、受付台資源及びオペレータ人材の有効活用が可能である。
【００７４】
（Ｄ）第３変形例の説明
上述した実施形態では、発信者識別情報として顧客に入力してもらった情報（カスタマーＩＤやクレジットカード番号など）を発信者情報受信装置３にて受信することで、発信者９の特定を行なっているが、公衆網８から提供されるいわゆる発信者番号情報を発信者識別情報として利用して発信者９の特定を行なうようにしてもよい。
【００７５】
この場合、例えば図１３に示すように、発信者情報受信装置３は不要になり、発信者９から通知される発信者番号情報は、ＰＢＸ２を介して呼制御装置５（ＰＢＸインタフェース部５１，呼情報送受信部５２，呼制御部５３）を経由して記憶装置５５に蓄積されるとともに、ＬＡＮインタフェース部５４からＬＡＮ６を介してデータベースサーバ７に送られる。
【００７６】
そして、データベースサーバ７では、着信呼識別部７１によって、発信者番号情報を基に発信者９が重要顧客であるか一般顧客であるかを判定して着信呼がＶＩＰ呼か非ＶＩＰ呼かを判定し、その判定結果が呼制御装置５（呼制御部５３）へ送出される。
以降は、前述した実施形態（あるいは、第１及び第２変形例でもよい）と同様にして、呼制御部５３によって、上記の判定結果（ＶＩＰ呼／非ＶＩＰ呼）に応じた受付台４１−ｉへの着信制御が、各応答順位テーブル５０１，５０２（あるいは、呼応答順位テーブル５１２）に基づいて実行される。
【００７７】
このように、本変形例では、発信者識別情報として発信者番号情報を利用することで、図１に示したものに比して、コールセンタシステム１（着信呼制御装置１１）の構成を簡素にすることができ、その小型化及び低コスト化に大いに寄与する。
（Ｅ）第４変形例の説明
図１４は図１に示すコールセンタシステムの第４変形例を示すブロック図であるが、この図１４に示すコールセンタシステム１は、図１３により上述した第３変形例のシステム構成を基本として、ＰＢＸ２内に前記のデータベースサーバ７を設けるとともに、前記の外付けであった呼制御装置５としての機能をデータベースサーバ７内にもたせた構成になっている。
【００７８】
そして、データベースサーバ７には、前記の着信呼識別部７１が設けられるとともに、発信者識別データ１０８と前記の受付台応答順位管理情報５００とが保存されており、上記の発信者識別データ１０８と、公衆網８から通知される発信者９の発信者識別情報としての発信者番号情報とを着信呼識別部７１において比較することで、発信者９からの着信呼がＶＩＰ呼であるか非ＶＩＰ呼であるかが識別されるようになっている。
【００７９】
以降は、データベースサーバ７によって、前述した実施形態（あるいは、第１及び第２変形例でもよい）と同様にして、受付台応答順位管理情報５００（各応答順位テーブル５０１，５０２、もしくは、呼応答順位テーブル５１２）に基づく着信呼の振り分けが行なわれる。
このように、本変形例では、ＰＢＸ２に、前述した呼制御装置５及びデータベースサーバ７としての機能をもたせているので、さらに、コールセンタシステム１の構成を簡素にすることができ、その規模の縮小化及び低コスト化に大いに寄与する。
【００８０】
なお、本変形例では、前記の第３変形例のシステム構成を前提としているため、発信者情報受信装置３が不要な構成になっているが、勿論、前述した実施形態と同様に発信者識別情報として顧客の入力情報を利用する場合には、発信者情報受信装置３を設ける必要がある。この場合、発信者情報受信装置３は、図１に示すようにＰＢＸ２に外付けしても良いし、ＰＢＸ２（データベースサーバ７）にその機能ももたせるようにしてもよい。
【００８１】
また、本発明は、上述した実施形態及び各変形例に限定されず、本発明の趣旨を逸脱しない範囲で、種々変形して実施することができる。
例えば、上述した例では、空き状態となった受付台４１−ｉから順番にｍ台分がＶＩＰ呼第１〜第ｍ応答受付台として登録されるが、この空き受付台４１−ｉの登録順序は、必ずしも空き状態となった順序である必要はなく、適宜に変更することができる。
【００８２】
また、上述した例における「特定の着信呼」とは、必ずしも重要顧客からの着信呼である必要はなく、勿論、コールセンタシステム１の保守者などが独自に「特定」と定義した着信呼でもよい。
（Ｆ）付記
（付記１） ｎ台の受付端末のうち空き状態となった任意のｍ台（ただし、ｎ，ｍはｎ＞ｍを満足する自然数）を、特定の着信呼に応答すべき特定着信呼用受付端末として設定しうる特定着信呼用受付端末設定手段と、
着信呼が特定の着信呼かどうかを識別する着信呼識別手段と、
該着信呼識別手段で該着信呼が特定の着信呼であると判別されると、当該着信呼を該特定着信呼用受付端末に着信させる着信制御手段とをそなえて成ることを特徴とする、着信呼制御装置。
【００８３】
（付記２） 該特定着信呼用受付端末設定手段が、
空き状態となった受付端末から順番にｍ台分を該特定着信呼用受付端末として設定するように構成されたことを特徴とする、付記１記載の着信呼制御装置。
（付記３） 該着信制御手段が、
該特定着信呼用受付端末が全て応答中の場合に、該特定着信呼用受付端末以外の非特定着信呼用受付端末に空き状態の受付端末が存在すると、当該受付端末に該特定の着信呼を着信させる非特定着信呼用受付端末着信手段をそなえていることを特徴とする、付記１又は付記２に記載の着信呼制御装置。
【００８４】
（付記４） 該着信制御手段が、
該特定着信呼用受付端末設定手段によって該特定着信呼用受付端末として設定された受付端末に対して、その旨を通知する特定着信呼用受付端末設定通知手段をそなえていることを特徴とする、付記１〜３のいずれか１項に記載の着信呼制御装置。
【００８５】
（付記５） 該着信制御手段が、
応答待ちの全着信呼についての着信順を管理する応答待ち着信呼管理手段と、
全ての受付端末が応答中のときに該特定の着信呼を受けると、当該着信呼が非特定着信呼よりも前に空き状態の受付台に着信すべき呼となるよう該応答待ち着信呼管理手段での該着信順を制御する応答待ち着信呼制御手段とをそなえていることを特徴とする、付記１〜４のいずれか１項に記載の着信呼制御装置。
【００８６】
（付記６） 該着信呼管理手段が、
応答待ちの特定の着信呼についての着信順と該特定の着信呼以外の着信呼についての着信順とをそれぞれ個別に管理しうるように構成されるとともに、
該着信制御手段が、
該着信呼管理手段において応答待ちの特定の着信呼が管理されている間は、該応答待ちの特定の着信呼を優先して空き状態となった受付端末に着信させる応答待ち特定着信呼優先制御手段をそなえていることを特徴とする、付記５記載の着信呼制御装置。
【００８７】
（付記７） 該着信制御手段が、
該着信呼管理手段において該特定の着信呼が管理されていることを全受付台に通知する特定着信呼応答待ち通知手段をそなえていることを特徴とする、付記５又は付記６に記載の着信呼制御装置。
（付記８） ｎ台の受付端末のうち空き状態となった任意のｍ台（ただし、ｎ，ｍはｎ＞ｍを満足する自然数）を、特定の着信呼に応答すべき特定着信呼用受付端末として設定しておき、
特定の着信呼を受けると当該着信呼を該特定着信呼用受付端末に着信させることを特徴とする、着信呼制御方法。
【００８８】
（付記９） 最初に空き状態となった受付端末から順番にｍ台分を該特定着信呼用受付端末として設定することを特徴とする、付記８記載の着信呼制御方法。
（付記１０） 該特定着信呼用受付端末が全て応答中の場合は、該特定着信呼用受付端末以外の空き状態の非特定着信呼用受付端末に、該特定の着信呼を着信させることを特徴とする、付記８又は付記９に記載の着信呼制御方法。
【００８９】
（付記１１） 該特定着信呼用受付端末として設定した受付端末に対して、その旨を通知することを特徴とする、付記８〜１０のいずれか１項に記載の着信呼制御方法。
（付記１２） 全ての受付端末が応答中のときに該特定の着信呼を受けると、当該着信呼を、非特定着信呼よりも前に空き状態の受付端末に着信させるべき着信呼として管理することを特徴とする、付記８〜１１のいずれか１項に記載の着信呼制御方法。
【００９０】
（付記１３） 応答待ちの特定の着信呼についての着信順と該特定の着信呼以外の着信呼についての着信順とをそれぞれ個別に管理しておき、
応答待ちの特定の着信呼を管理している間は、該応答待ちの特定の着信呼を優先して空き状態となった受付端末に着信させることを特徴とする、付記８〜１１のいずれか１項に記載の着信呼制御方法。
【００９１】
（付記１４） 該応答待ちの特定の着信呼を管理していることを全受付台に通知することを特徴とする、付記１２又は付記１３に記載の着信呼制御方法。
（付記１５） 着信呼を複数の受付端末のいずれかに着信させる着信制御装置において、
特定の着信呼を着信すべき特定着信呼用受付端末を、該複数の受付端末から成る受付端末グループ内で変更する手段をそなえたことを特徴とする、着信呼制御装置。
【００９２】
【発明の効果】
以上詳述したように、本発明によれば、ｎ台の受付端末のうち空き状態となった任意のｍ台が、特定の呼に応答すべき特定着信呼用受付端末として、常時、確保されるので、全ての受付端末が応答中で特定の着信呼が応答待ち状態になってしまう確率が最小限に抑制される。また、このとき、空き状態となった受付端末が特定着信呼用受付端末となるので、受付端末グループ内において特定着信呼用受付端末となる受付端末は、適宜、変更される（固定されない）。従って、着信呼に対する応答業務のサービス性が大幅に向上するとともに、受付端末資源の有効利用を図ることができる（以上、請求項１，４，５）。
【００９３】
ここで、本発明では、空き状態となった受付端末から順番にｍ台分を上記の特定着信呼用受付端末として設定するようにしてもよく、このようにすれば、簡単な制御で、所望数の受付端末を特定着信呼用受付端末として確保することができるので、着信制御の簡素化に大いに寄与する（請求項２）。
また、上記の特定着信呼用受付端末が全て応答中の場合には、特定着信呼用受付端末以外の空き状態の非特定着信呼用受付端末に、特定の着信呼を着信させることもできるので、特定の着信呼が応答待ち状態になる確率がさらに低減されて、特定の着信呼に対する応答業務のサービス性がさらに向上する（請求項３）。
【図面の簡単な説明】
【図１】本発明の一実施形態としての着信呼制御装置が適用されるコールセンタシステムを示すブロック図である。
【図２】図１に示す呼制御部に着目した構成を示すブロック図である。
【図３】図１に示すコールセンタシステムの動作（着信制御）を説明するためのフローチャートである。
【図４】図１に示すコールセンタシステムの動作（着信制御）を説明するためのフローチャートである。
【図５】図１に示すコールセンタシステムの動作（着信制御）を説明するための模式図である。
【図６】図１に示すコールセンタシステムの動作（テーブル状態遷移）を説明するための模式図である。
【図７】（Ａ）及び（Ｂ）はいずれも本実施形態の待ち呼管理及び制御を説明するための模式図である。
【図８】本実施形態の他の待ち呼管理及び制御を説明するための模式図である。
【図９】図８に示す待ち呼管理及び制御を実現する呼制御部の構成を示すブロック図である。
【図１０】本実施形態の第１変形例を示すブロック図である。
【図１１】本実施形態の第１変形例の動作を説明するための模式図である。
【図１２】本実施形態の第２変形例の動作を説明するための模式図である。
【図１３】本実施形態の第３変形例としてのコールセンタシステムの構成を示すブロック図である。
【図１４】本実施形態の第４変形例としてのコールセンタシステムの構成を示すブロック図である。
【符号の説明】
１ コールセンタシステム
２ 構内交換機（ＰＢＸ）
３ 発信者情報受信装置
４ 受付台グループ
５ 呼制御装置
６ ネットワーク（ＬＡＮ）
７ データベースサーバ
８ 公衆網
９ 加入者端末
１１ 着信呼制御装置
３１，５１ ＰＢＸインタフェース部
３２ メッセージ送出部
３３ ＤＴＭＦ信号受信部
３４，５５ 記憶装置
３５，５４ ＬＡＮインタフェース部
４１−１〜４１−ｎ 受付台（受付端末）
５２ 呼情報送受信部
５３ 呼制御部
５３Ａ ＶＩＰ呼応答受付台設定部
５３Ｂ 着信制御部
５３Ｂ−１ 非ＶＩＰ呼用着信制御部
５３Ｂ−２ ＶＩＰ呼設定通知部
５３Ｂ−３ 応答待ち呼キュー管理部
５３Ｂ−４ 応答待ち呼キュー制御部
５３Ｂ−５ ＶＩＰ呼応答待ち通知部
５３Ｂ−６ ＶＩＰ待ち呼優先制御部
７１ 着信呼識別部
１０８ 発信者識別データ
４１１ 制御部
４１２ 表示部
５００ 受付台応答順位管理情報
５０１ ＶＩＰ呼応答順位テーブル
５０２ 非ＶＩＰ呼応答順位テーブル
５１０ 受付台登録テーブル判定部
５１１ ＶＩＰ呼応答受付台領域
５１２ 呼応答順位テーブル
５３１ 待ち呼キュー
５３１Ａ ＶＩＰ呼用の待ち呼キュー
５３１Ｂ 非ＶＩＰ呼（一般呼）用の待ち呼キュー

Claims (5)

1. 特定の着信呼に応答すべき特定着信呼用受付端末と当該特定着信呼用受付端末以外の非特定着信呼用受付端末とのいずれかに設定されるｎ台の受付端末のうち空き状態となった任意のｍ台（ただし、ｎ，ｍはｎ＞ｍを満足する自然数）を、上記の空き状態となった受付端末の設定状態によらず、該特定着信呼用受付端末として設定する特定着信呼用受付端末設定手段と、
   着信呼が特定の着信呼かどうかを識別する着信呼識別手段と、
   該着信呼識別手段で該着信呼が特定の着信呼であると識別されると、当該着信呼を該特定着信呼用受付端末に着信させる着信制御手段とをそなえて成ることを特徴とする、着信呼制御装置。
2. 該特定着信呼用受付端末設定手段が、
   空き状態となった受付端末から順番にｍ台分を該特定着信呼用受付端末として設定するように構成されたことを特徴とする、請求項１記載の着信呼制御装置。
3. 該着信制御手段が、
   該特定着信呼用受付端末が全て応答中の場合に、該非特定着信呼用受付端末に空き状態の受付端末が存在すると、当該受付端末に該特定の着信呼を着信させる非特定着信呼用受付端末着信手段をそなえていることを特徴とする、請求項１又は請求項２に記載の着信呼制御装置。
4. 特定の着信呼に応答すべき特定着信呼用受付端末と当該特定着信呼用受付端末以外の非特定着信呼用受付端末とのいずれかに設定されるｎ台の受付端末のうち空き状態となった任意のｍ台（ただし、ｎ，ｍはｎ＞ｍを満足する自然数）を、上記の空き状態となった受付端末の設定状態によらず、該特定着信呼用受付端末として設定し、
   特定の着信呼を受けると当該着信呼を該特定着信呼用受付端末に着信させることを特徴とする、着信呼制御方法。
5. 着信呼を複数の受付端末のいずれかに着信させる着信呼制御装置において、
   特定の着信呼に応答すべき特定着信呼用受付端末と当該特定着信呼用受付端末以外の非特定着信呼用受付端末とのいずれかに設定される該複数の受付端末から成る受付端末グループ内で、該複数の受付端末のいずれかを、該受付端末の設定状態によらず該特定着信呼用受付端末に設定する手段をそなえたことを特徴とする、着信呼制御装置。

Images