JP6279872B2 - 呼制御サーバ、呼制御方法及びコンピュータプログラム - Google Patents

Description

本発明は、呼の制御の技術に関し、特にコールセンタにおける呼を制御する技術に関する。

銀行、証券会社、通信販売会社等のサービス事業者は、サービスの利用者（ユーザ）のためにコールセンタを設置している。コールセンタのオペレータの人数が少ないと、ユーザのかけた電話がオペレータに繋がりにくくなる。しかし、コールセンタのオペレータを増員することはコスト増となる。そこで、コールセンタに電話をかけてきたユーザをＷＥＢへ誘導することで、オペレータの増員を抑制する技術が知られている（特許文献１）。

特開２０１３−１４１０６６号公報

しかし、ユーザにとっては、ＷＥＢに用件を入力するよりも、オペレータと直接会話した方が楽な場合も多い。また、オペレータに電話が繋がらなかったユーザをＷＥＢへ誘導しても、そのユーザがＷＥＢにアクセスしてくれるとは限らない。特に新規ユーザの場合は、その可能性が高いと考えられる。これは、サービス事業者にとっては、新規ユーザを獲得する機会を損失しているといえる。

本発明の目的は、サービス事業者およびユーザの双方にとって満足度の高いコールセンタを実現することにある。

本発明の一実施形態に係る呼制御サーバは、ユーザ端末との間に確立した第１の呼をオペレータ端末へ転送可能か否かを判定し、当該判定の結果が転送不可能な場合は、第１の呼を保留する転送処理部と、
判定の結果が転送不可能な場合、後に前記ユーザ端末との間に確立する第２の呼の制御に用いられる予約時間を決定する時間決定部と、
時間決定部によって決定された予約時間を含むメッセージを、第１の呼の発信元であるユーザ端末へ送信するメッセージ処理部とを備える。

本発明によれば、サービス事業者およびユーザの双方にとって満足度の高いコールセンタを実現することができる。

第１の実施形態に係るシステムの構成例を示す。 第１の実施形態に係る各装置が有する機能の例を示すブロック図である。 ユーザ管理テーブルの構成例を示す。 第１の実施形態に係る保留管理テーブルの構成例を示す。 ＣＢ（ＣａｌｌＢａｃｋ）時間管理テーブルの構成例を示す。 予約ＣＢ時間を含むＳＭＳ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）の構成例を示す。 予約ＣＢ時間の変更用ＷＥＢページの構成例を示す。 ＳＭＳの送信及びＣＢに関する処理例を示すシーケンスチャートである。 第１の実施形態に係る転送処理部の処理例を示すフローチャートである。 ＣＢ時間決定部の処理例を示すフローチャートである。 第２の実施形態に係る各装置が有する機能例を示す。 第２の実施形態に係る保留管理テーブルの構成例を示す。 優先時間管理テーブルの構成例を示す。 優先時間を含むＳＭＳの構成例を示す。 優先時間の変更用ＷＥＢページの構成例を示す。 ＳＭＳの送信及び優先時間に関する処理例を示すシーケンスチャートである。 第２の実施形態に係る転送処理部の処理例を示すフローチャートである。 優先時間決定部の処理例を示すフローチャートである。

以下、図面を参照しながら本発明の実施形態を説明する。

＜第１の実施形態＞
図１は、第１の実施形態に係るコールセンタシステムの構成例を示す。
第１の実施形態に係るコールセンタシステムは、ＩＶＲ（Ｉｎｔｅｒａｃｔｉｖｅ Ｖｏｉｃｅ Ｒｅｓｐｏｎｓｅ）１２と、制御サーバ１３Ａと、オペレータ端末１４とを有する。

ＩＶＲ１２は、着呼を検知して自動的に呼を確立し、音声案内を再生する装置である。オペレータ端末１４は、コールセンタのオペレータが利用する端末である。オペレータは、オペレータ端末１４を用いて、ユーザと通話をしたり、ユーザに電話をかけたりする。オペレータ端末１４は、例えば、ヘッドセットの接続されたＰＣ等である。制御サーバ１３Ａは、コールセンタシステムにおける呼を制御する装置である。ユーザ端末１１は、通話機能とデータ通信機能を有する端末であり、例えば、携帯電話又はスマートフォン等である。

ユーザ端末１１と、ＩＶＲ１２と、オペレータ端末１４とは、通話が可能な電話網１５に接続されている。電話網１５は、例えば、３Ｇ網、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）網及び／又はＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）網等で構成される。ユーザ端末１１は、電話網１５を通じて、ＩＶＲ１２及びオペレータ端末１４と通話をすることができる。電話網１５では、電話番号が呼の発信元及び発信先の装置を特定するために用いられる。

ユーザ端末１１と、制御サーバ１３Ａとは、データ通信が可能な通信網１６に接続されている。通信網１６は、例えば、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ網、ＬＴＥ網、ＡＴＭ網及び／又はインターネット網等で構成される。ユーザ端末１１は、通信網１６を通じて、制御サーバ１３Ａとデータを送受信することができる。通信網１６では、ＩＰアドレスがデータの送信元及び送信先の装置を特定するために用いられる。

図１では、説明の便宜上、電話網１５と通信網１６とを分けているが、同一の通信網上で通話及びデータ通信が実現されてもよい。

ＩＶＲ１２と、制御サーバ１３Ａと、オペレータ端末１４とは、データの送受信が可能な内部ネットワーク１７に接続されている。内部ネットワーク１７は、例えば、ＬＡＮ及び／又は専用線等で構成される。ＩＶＲ１２と、制御サーバ１３Ａと、オペレータ端末１４とは、内部ネットワーク１７を通じて、データを送受信することができる。ＩＶＲ１２と制御サーバ１３Ａとは、内部ネットワーク１７に代えて、データ伝送可能な所定のケーブルで接続されてもよい。

サービス事業者は、ＩＶＲ１２と、制御サーバ１３Ａと、オペレータ端末１４とを備えるコールセンタシステムを用いて、ユーザがオペレータと通話可能なコールセンタを運営する。例えば、銀行及び証券会社等のコールセンタは、ユーザから電話で、口座開設及び／又は住所変更等の問い合わせを受け付ける。例えば、通信販売会社のコールセンタは、ユーザから電話で、商品購入及び／又は購入商品のアフターサポート等の問い合わせを受け付ける。

図２は、第１の実施形態に係る各装置が有する機能の例を示すブロック図である。
ユーザ端末１１、ＩＶＲ１２、制御サーバ１３Ａ及びオペレータ端末１４のそれぞれは、ＣＰＵ、メモリ及び記憶媒体等（何れも不図示）を備えるいわゆる電子計算機である。各装置は、ＣＰＵ、メモリ及び記憶媒体等を用いて所定のコンピュータプログラムを実行することにより、図２に示す各機能を実現する。

（ユーザ端末１１の機能）
ユーザ端末１１は、機能として、呼を制御する呼制御部３１と、ＳＭＳを処理するＳＭＳ処理部３２と、ＷＥＢを処理するＷＥＢ処理部３３と、入出力に係るＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を処理するＵＩ部３４とを有する。

ユーザ端末１１の呼制御部３１は、電話網１５上の呼を制御する。呼は、発信元及び発信先の電話番号を含む。ユーザ端末１１からコールセンタの電話番号が入力された場合、呼制御部３１は、発信元にユーザ端末１１（に挿入されているＳＩＭカード）の電話番号を有し、発信先にコールセンタの電話番号を有する呼を、電話網１５を通じて発呼する。そして、コールセンタのＩＶＲ１２から応答を受けた場合、呼制御部３１は、ＩＶＲ１２との間に呼（セッション）を確立する。

ユーザ端末１１の呼制御部３１は、ユーザ端末１１の電話番号を発信先とする、コールセンタのオペレータ端末１４からの着呼を検知した場合、コールセンタから着信があった旨をユーザに通知する。そして、ユーザがその着信に出ると、ユーザ端末１１の呼制御部３１は、コールセンタへ応答を返し、オペレータ端末１４との間に呼を確立する。これにより、ユーザはオペレータと通話をすることができる。

ユーザ端末１１のＳＭＳ処理部３２は、電話網１５上で送受信されるＳＭＳを処理する。ＳＭＳは、発信先に電話番号を設定することができる。ＳＭＳは、ＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）又はＥＭＳ（Ｅｎｈａｎｃｅｄ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）であってもよい。ユーザ端末１１のＳＭＳ処理部３２は、自分の電話番号を発信先とするＳＭＳを受信する。そして、ＳＭＳ処理部３２は、そのＳＭＳの内容を、ＵＩ部３４を通じて表示する。ＳＭＳは、電話網１５上で送受信されるので、送信先にプッシュ通知される。送信元は、送信したＳＭＳが送信先に到着したか否かを確認することができる。送信先に到着しなかったＳＭＳは、再送され得る。

ユーザ端末１１のＷＥＢ処理部３３は、通信網１６上で送受信されるＷＥＢページのデータを処理する。ＷＥＢ処理部３３は、ユーザ端末１１に入力されたＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に対応するＷＥＢサーバへアクセスし、ＷＥＢページのデータを取得する。そして、ＷＥＢ処理部３３は、そのＷＥＢページの内容を、ＵＩ部３４を通じて表示する。ＷＥＢ処理部３３は、例えば、ＷＥＢブラウザである。

ＵＩ部３４は、様々な情報をディスプレイに表示すると共に、ユーザからの入力を受け付ける。ＵＩ部３４は、例えば、電話番号の入力を受け付けたり、ＳＭＳの内容を表示したり、ＷＥＢページの内容を表示したりする。

（ＩＶＲ１２の機能）
ＩＶＲ１２は、機能として、呼を制御する呼制御部４１と、自動的に着呼に応答する自動応答部４２とを有する。

ＩＶＲ１２の呼制御部４１は、電話網１５上の呼を制御する。呼制御部４１は、コールセンタの電話番号を発信先とするユーザ端末１１からの着呼を検知した場合、その旨を自動応答部４２に通知する。自動応答部４２は自動的に応答するので、ユーザ端末１１とＩＶＲ１２との間に呼を確立する。

ＩＶＲ１２の自動応答部４２は、呼制御部４１から通知された着呼に自動的に応答する。自動応答部４２は、確立した呼を通じてユーザ端末１１に、自動音声案内を再生する。自動応答部４２は、確立した呼を通じてユーザ端末１１から送信されたプッシュ信号を、制御サーバ１３Ａの転送処理部５１へ通知する。

（制御サーバ１３Ａの機能）
制御サーバ１３Ａは、機能として、転送処理部５１Ａと、ＣＢ（ＣａｌｌＢａｃｋ）時間決定部５２と、ＳＭＳ処理部５３と、ＷＥＢ処理部５４と、ユーザ管理テーブル１０１と、保留管理テーブル１０２Ａと、ＣＢ時間管理テーブル１０３と、を有する。以下、各機能及びテーブルについて説明する。

図３は、ユーザ管理テーブル１０１の構成例を示す。
ユーザ管理テーブル１０１は、ユーザに関する情報（「ユーザ情報」という）を管理する。ユーザ情報は、例えば、ユーザＩＤ１１１と、ユーザ名１１２と、電話番号１１３と、住所１１４とを対応付ける。図３に示すレコード１１０ａのユーザ情報は、ユーザＩＤ１１１「１」と、ユーザ名１１２「野村太郎」と、電話番号１１３「０９０−４４４４−９９９９」と、住所１１４「東京都」とを対応付けている。ユーザ管理テーブル１０１には、過去にサービス事業者のサービスを利用したことのあるユーザのユーザ情報のみが登録されており、新規ユーザの情報は登録されていない。

図４は、保留管理テーブル１０２Ａの構成例を示す。
保留管理テーブル１０２Ａは、保留中の呼を管理する。保留管理テーブル１０２Ａには、ＩＶＲ１２が呼を確立したものの、例えば、全てのオペレータ端末１４がビジー（対応不可能）であるため、何れのオペレータ端末１４にも転送できない呼が登録（保留）される。

保留管理テーブル１０２Ａは、転送の順番を示す転送順番１２１と、電話番号１２２とを対応付けて管理する。図４に示すレコード１２０ａは、転送順番１２１「１位」の保留中の電話番号１２２は「０９０−５５５５−６６６６」であることを示す。

転送処理部５１は、オペレータ端末１４のビジーが解消された場合、転送順番１２１の先頭から順番に、その保留中の呼をオペレータ端末１４へ転送する。転送済みの保留は、保留管理テーブル１０２Ａから削除される。通話が切断された保留も、保留管理テーブル１０２Ａから削除される。

図５は、ＣＢ時間管理テーブル１０３の構成例を示す。
ＣＢ時間管理テーブル１０３は、ＣＢ時間に関する情報（「ＣＢ時間情報」という）を管理する。ＣＢ時間情報は、ＣＢ時間１３１と、予約数１３２と、最大予約数１３３と、電話番号１３４とを対応付ける。ＣＢ時間情報は、さらに、ユーザ名１３５と、用件１３６とを対応付けてもよい。

ＣＢ時間１３１は、オペレータ端末１４がユーザ端末１１へＣＢする予定の時間帯を示す。ユーザ端末１１へは、ＳＭＳによって、ＣＢされる予定の時間帯（「予約ＣＢ時間」という）が予め通知される。

最大予約数１３３は、各ＣＢ時間１３１において登録可能な予約ＣＢ時間な最大数を示す。予約数１３２は、各ＣＢ時間１３２において登録されている予約ＣＢ時間の数を示す。つまり、「予約数１３２＝最大予約数１３３」となったＣＢ時間１３１には、これ以上予約ＣＢ時間を登録することができない。例えば、図５のＣＢ時間１３１「１３：３０−１４：００」には、既に最大予約数１３３「８」と同じ予約数１３２「８」が登録されているので、このＣＢ時間１３１には、これ以上予約ＣＢ時間を登録することができない。

最大予約数１３３は、ＣＢ時間１３１毎に異なる設定であってもよい。例えば、統計的にＩＶＲ１２の着呼件数が比較的多い時間帯は、その時間帯を含むＣＢ時間１３１の最大予約数１３３を小さく設定してもよい。例えば、統計的にＩＶＲ１２の着呼件数が比較的少ない時間帯は、その時間帯を含むＣＢ時間１３１の最大予約数１３３を大きく設定してもよい。これにより、或る時間帯に集中していた着呼件数を平準化することができる。

電話番号１３４には、ＣＢ時間１３１に予約ＣＢ時間を登録したユーザ端末１１の電話番号が登録される。

ユーザ管理テーブル１０１に、電話番号１３４に対応するユーザ名が存在する場合は、ユーザ名１３５に、そのユーザ名が登録されてもよい。ユーザ管理テーブル１０１に、電話番号１３４に対応するユーザ名が存在しない場合は、ユーザ名１３５に、「新規」が登録されてもよい。電話番号１３４に対応するユーザ端末１１から、例えば、プッシュ信号によって用件内容（例えば、口座開設、住所変更、口座解約等）が選択された場合は、用件１３６に、その選択された用件内容が登録されてもよい。

以下、図２の説明に戻る。
転送処理部５１Ａは、呼の転送および予約ＣＢ時間に関する処理を実行する。転送処理部５１Ａは、ＩＶＲ１２が確立したユーザ端末１１との間の呼を、オペレータ端末１４へ転送可能な否か判定する。転送処理部５１Ａは、対応可能なオペレータ端末１４が存在する場合、「転送可」と判定し、何れのオペレータ端末１４も対応不可能な場合、「転送不可」と判定する。転送処理部５１Ａは、「転送可」と判定した場合、その呼を対応可能なオペレータ端末１４へ転送する。転送処理部５１Ａは、「転送不可」と判定した場合、その呼を保留管理テーブル１０２に登録（保留）する。

転送処理部５１Ａは、呼の発信元（保留中の呼でもよい）のユーザ端末１１に対して、予約ＣＢ時間を含むＳＭＳを送信するか否かを判定する。転送処理部５１Ａは、例えば、次の条件に基づいて、この判定を行う。
（１）転送処理部５１Ａは、ユーザ端末１１から予約ＣＢ時間が要求された場合、予約ＣＢ時間を含むＳＭＳを送信すると判定する。例えば、ユーザ端末１１のプッシュ信号から、予約ＣＢ時間の要求が選択された場合である。
（２）転送処理部５１Ａは、ユーザ端末１１との間の呼を確立した時点の保留管理テーブル１０２Ａにおける保留数が、閾値よりも多い場合、予約ＣＢ時間を含むＳＭＳを送信すると判定する。保留時間が長くなる可能性が高いからである。
（３）転送処理部５１Ａは、保留時間が閾値以上となった場合、その保留中のユーザ端末１１に、予約ＣＢ時間を含むＳＭＳを送信すると判定する。ユーザの不満を緩和するためである。
（４）転送処理部５１Ａは、保留中に切断された場合、その保留中であったユーザ端末１１に、予約ＣＢ時間を含むＳＭＳを送信すると判定する。新規ユーザの取り逃がしを防ぐためである。

転送処理部５１Ａは、予約ＣＢ時間を含むＳＭＳを送信すると判定した場合、予約ＣＢ時間を決定するようＣＢ時間決定部５２に指示する。そして、転送処理部５１Ａは、ＣＢ時間決定部５２の決定した予約ＣＢ時間を取得し、ＣＢ時間管理テーブル１０３に登録する。ＣＢ時間決定部５２の処理の詳細については後述する。

転送処理部５１Ａは、予約ＣＢ時間を変更および／又はキャンセルするためのＷＥＢページを作成するようＷＥＢ処理部５４に指示する。そして、転送処理部５１Ａは、ＷＥＢ処理部５４の作成したＷＥＢページのＵＲＬを取得する。ＷＥＢ処理部５４の処理の詳細については後述する。

転送処理部５１Ａは、ＣＢ時間決定部５２の決定した予約ＣＢ時間と、ＷＥＢ処理部５４の作成したＷＥＢページのＵＲＬとを含むＳＭＳを、予約ＣＢ時間を含むＳＭＳを送信すると判定したユーザ端末１１に送信するようＳＭＳ処理部５３に指示する。ＳＭＳ処理部５３は、この指示を受けて、ユーザ端末１１の電話番号を送信先としたＳＭＳを生成し、その生成したＳＭＳを送信する。

転送処理部５１Ａは、ＳＭＳがユーザ端末１１に到達したか否かを確認することができる。よって、転送処理部５１Ａは、所定時間内にＳＭＳがユーザ端末１１に到達したことを確認できない場合、そのＳＭＳに含まれる予約ＣＢ時間に係るＣＢ時間情報をＣＢ時間管理テーブル１０３から削除し、そのＳＭＳに含まれるＵＲＬに対応するＷＥＢページを破棄してもよい。

ＣＢ時間決定部５２は、ユーザ端末１１に対する予約ＣＢ時間を決定する。ＣＢ時間決定部５２は、例えば、次の条件に基づいて、予約ＣＢ時間を決定する。

（１）ＣＢ時間決定部５２は、ＣＢ時間管理テーブル１０３において「予約数１３２＜最大予約数１３３」を満たすＣＢ時間１３１の中から１つの予約ＣＢ時間を決定する。このとき、ＣＢ時間決定部５２は、上記条件を満たすＣＢ時間１３１の内、最大予約数１３３と予約数１３２との差分が最大のＣＢ時間１３１を、予約ＣＢ時間に決定してもよい。

または、ＣＢ時間決定部５２は、上記条件を満たすＣＢ時間１３１の内、ユーザ端末１１からの着呼の時刻から最も近いＣＢ時間１３１を、予約ＣＢ時間に決定してもよい。

または、ＣＢ時間決定部５２は、新規ユーザか否か（既存ユーザか）に基づいて、予約ＣＢ時間を決定してもよい。例えば、上記条件を満たすＣＢ時間１３１の内、新規ユーザの場合は、最大予約数１３３と予約数１３２との差分が最大のＣＢ時間１３１を、予約ＣＢ時間に決定し、既存ユーザの場合は、ユーザ端末１１からの着呼の時刻から最も近いＣＢ時間１３１を、予約ＣＢ時間に決定してもよい。なぜなら、新規ユーザは、既存ユーザと比較して、オペレータの対応する時間が長くなりやすいからである。

（２）ＣＢ時間決定部５２は、ＣＢ時間管理テーブル１０３において「予約数１３２＜最大予約数１３３」を満たすＣＢ時間１３１の一部又は全部を、複数の予約ＣＢ時間候補としてユーザ端末１１に通知し、ユーザ端末１１から選択された１つの予約ＣＢ時間候補を、予約ＣＢ時間に決定する。このとき、ＣＢ時間決定部５２は、ＩＶＲ１２を用いて、複数の予約ＣＢ時間候補をユーザ端末へ自動音声案内し、ユーザ端末１１からプッシュ信号によって１つの予約ＣＢ時間候補を選択させてもよい。

ＣＢ時間決定部５２は、予約ＣＢ時間候補の数が閾値より多い場合、上記（１）で述べた各種条件に基づいて閾値以下の数の予約ＣＢ時間候補に絞った上で、絞られた予約ＣＢ時間候補をユーザ端末１１へ通知してもよい。

制御サーバ１３ＡのＷＥＢ処理部５４は、ユーザ端末１１から予約ＣＢ時間の変更及び／又はキャンセルを行うためのＷＥＢページと、そのＷＥＢページに対応するＵＲＬとを生成する。そして、ＷＥＢ処理部５４は、ユーザ端末１１からＵＲＬにアクセスされると、そのＵＲＬに対応するＷＥＢページのデータをユーザ端末１１へ送信する。つまり、ＷＥＢ処理部５４は、ＷＥＢサーバの機能を有する。

制御サーバ１３ＡのＷＥＢ処理部５４は、予約ＣＢ時間の変更用のＷＥＢページと、キャンセル用のＷＥＢページとを別々に生成し、それぞれのＷＥＢページのＵＲＬを生成してもよいし、変更及びキャンセルの両方が可能な１つのＷＥＢページを生成し、その１つのＷＥＢページのＵＲＬを生成してもよい。

ＷＥＢ処理部５４は、呼毎に異なるＵＲＬを生成してもよい。ＷＥＢ処理部５４は、生成するＷＥＢページに有効期限を設定し、その有効期限が経過すると、そのＷＥＢページを破棄（アクセス不可と）してもよい。ＷＥＢ処理部５４は、ＣＢ時間管理テーブル１０３から削除されたＣＢ時間情報に対応するＷＥＢページを破棄（アクセス不可と）してもよい。

（オペレータ端末１４の機能）
オペレータ端末１４は、機能として、呼制御部６１と、ＵＩ部６２とを有する。
呼制御部６１は、ユーザ端末１１の呼制御部３２とほぼ同様であるので、説明を省略する。ＵＩ部６２は、様々な情報をオペレータ端末１４のディスプレイに表示すると共に、オペレータからの入力を受け付ける。ＵＩ部６２は、例えば、制御サーバ１３Ａから転送された呼の発信元（ユーザ端末１１）の電話番号を表示したり、予約ＣＢ時間の一覧を表示したりする。

図６は、予約ＣＢ時間を含むＳＭＳの例を示す。
ユーザ端末１１のＳＭＳ処理部３２は、制御サーバ１３Ａから予約ＣＢ時間を含むＳＭＳを受信すると、ＵＩ部３４を通じて、図６に示すようなＳＭＳの内容２００を表示する。

ＳＭＳの内容２００には、例えば、送信元の情報２０１と、送信先の電話番号２０２と、予約ＣＢ時間２０３と、予約ＣＢ時間の変更用ＷＥＢページのＵＲＬ２０４と、予約ＣＢ時間のキャンセル用ＷＥＢページのＵＲＬ２０５と、が含まれる。

ユーザは、図６に示すＳＭＳの内容２００の予約ＣＢ時間２０３を見て、オペレータからＣＢされる予定の時間帯が「１４：００−１４：３０」であることを知る。ユーザが予約ＣＢ時間２０３を選択すると、ユーザ端末１１は、その予約ＣＢ時間「１４：００−１４：３０」を、ユーザ端末１１にインストールされているスケジュールアプリケーション及び／又はリマインダーアプリケーション等に登録してもよい。

ユーザが変更用ＷＥＢページのＵＲＬ２０４を選択すると、ユーザ端末１１のＷＥＢ処理部３３は、そのＵＲＬにアクセスし、変更用ＷＥＢページのデータを取得して表示する。ユーザは、変更用ＷＥＢページを操作して、予約ＣＢ時間を変更することができる。変更用ＷＥＢページの例については後述する。このように、ユーザは、予約ＣＢ時間を容易に変更することができる。

ユーザがキャンセル用ＷＥＢページのＵＲＬ２０５を選択すると、ユーザ端末１１のＷＥＢ処理部３３は、そのＵＲＬへアクセスし、キャンセル用ＷＥＢページのデータを取得して表示する。ユーザは、キャンセル用ＷＥＢページを操作して、予約ＣＢ時間をキャンセルすることができる。制御サーバ１３ＡのＷＥＢ処理部５４は、ユーザ端末１１からキャンセル要求が送信されると、その予約ＣＢ時間に対応するＣＢ時間情報をＣＢ時間管理テーブル１０３から削除する。このように、ユーザは、予約ＣＢ時間を容易にキャンセルすることができる。

図７は、予約ＣＢ時間の変更用ＷＥＢページの例を示す。
ＳＭＳの内容２００から変更用ＷＥＢページのＵＲＬ２０４が選択されると、ユーザ端末１１のＷＥＢ処理部３３は、ＵＩ部３４を通じて、例えば、図７に示すような予約ＣＢ時間の変更用ＷＥＢページ３００を表示する。

予約ＣＢ時間の変更用ＷＥＢページ３００は、複数のＣＢ時間３０１と、各ＣＢ時間の予約状況３０２とを有する。

予約状況３０２が「予約不可」のＣＢ時間３０１は、予約ＣＢ時間の登録が不可能なＣＢ時間である。例えば、ＣＢ時間管理テーブル１０３において「予約数１３２＝最大予約数１３３」のＣＢ時間である。

予約状況３０２が「予約中」のＣＢ時間３０１は、登録中の予約ＣＢ時間である。つまり、ＣＢ時間管理テーブル１０３に登録済みの予約ＣＢ時間である。

予約状況３０２が「空欄」のＣＢ時間３０１は、予約ＣＢ時間の登録が可能なＣＢ時間である。例えば、ＣＢ時間管理テーブル１０３において「予約数１３２＜最大予約数１３３」のＣＢ時間である。

図７において、ユーザが、予約状況３０２が「空欄」のＣＢ時間３０１「１４：３０−１５：００」を選択すると、その選択された予約状況３０２の「空欄」が「予約変更」に変更される（符号３１１）。

そして、ユーザが「送信」ボタン３２０を選択すると、ユーザ端末１１のＷＥＢ処理部３３は、「予約変更」に変更されたＣＢ時間「１４：３０−１５：００」を、制御サーバ１３Ａへ送信する。制御サーバ１３ＡのＷＥＢ処理部５４は、その変更されたＣＢ時間「１４：３０−１５：００」を受信し、ＣＢ時間管理テーブル１０３に登録済みの予約ＣＢ時間「１４：００−１４：３０」を、変更後のＣＢ時間「１４：３０−１５：００」に変更する。

このように、ユーザが容易に予約ＣＢ時間を変更及びキャンセルできるようにすることにより、コールセンタ側は、ＣＢしてもユーザが応答しないといったロスを減らすことができる。

図８は、ＳＭＳの送信及びＣＢに関する処理の例を示すシーケンスチャートである。

ユーザ端末１１は、コールセンタ（ＩＶＲ１２）へ発呼する（Ｓ１１）。発呼の発信元にはユーザ端末１１の電話番号、発信先にはコールセンタ（ＩＶＲ１２）の電話番号が含まれる。ＩＶＲ１２は、着呼を検知して応答を返し、ユーザ端末１１とＩＶＲ１２との間で呼を確立する（Ｓ１２）。ＩＶＲ１２は、ユーザ端末１１と呼を確立した旨を、制御サーバ１３Ａへ通知する（Ｓ１３）。

制御サーバ１３Ａは、その呼をオペレータ端末１４へ転送可能か否か判定する（Ｓ１４）。ここでは、制御サーバ１３Ａが「転送不可」と判定したとする。

「転送不可」と判定した場合、制御サーバ１３Ａは、その呼を保留管理テーブル１０２Ａへ保留する（Ｓ１５）。そして、制御サーバ１３Ａは、所定の条件に基づいて、予約ＣＢ時間を含むＳＭＳを送信可能か否か判定する（Ｓ１６）。ここでは、制御サーバ１３ＡがＳＭＳを「送信可」と判定したとする。

ＳＭＳを「送信可」と判定した場合、制御サーバ１３Ａは、ＩＶＲ１２に、ユーザ端末１１との間の呼を切断するよう指示する（Ｓ１７）。この指示を受けてＩＶＲ１２は、ユーザ端末１１との間の呼を切断する（Ｓ１８）。

制御サーバ１３Ａは、予約ＣＢ時間を決定し（Ｓ１９）、その予約ＣＢ時間を含むＳＭＳをユーザ端末１１へ送信する（Ｓ２０）。ユーザ端末１１は、そのＳＭＳを受信し、ＳＭＳの内容を表示する（Ｓ２１）。

次に、予約ＣＢ時間内の処理を説明する。
オペレータ端末１４は、ＣＢ時間管理テーブル１０３を参照し（Ｓ３１）、予約ＣＢ時間内に、その予約ＣＢ時間に対応する電話番号のユーザ端末１１へ発呼する（Ｓ３２）。

ユーザ端末１１が着呼を検知して応答すると、ユーザ端末１１とオペレータ端末１４との間に呼が確立する（Ｓ３３）。

上述の処理において、ユーザ端末１１および電話網１５が、呼を確立したままＳＭＳを受信できる構成である場合、ステップＳ１７及びＳ１８の呼切断の処理は行われなくてもよい。

以上の処理により、ユーザは、オペレータに電話が転送されなかった場合、ＳＭＳで通知された予約ＣＢ時間内に、オペレータからＣＢしてもらうことができる。

図９は、制御サーバ１３Ａの転送処理部５１Ａの処理の例を示すフローチャートである。

転送処理部５１Ａは、ＩＶＲ１２の呼制御部３１から呼を確立した旨の通知を受けると（Ｓ１０１）、その呼をオペレータ端末１４へ転送可能か否かを判定する（Ｓ１０２）。

転送可能な場合（Ｓ１０２：ＹＥＳ）、転送処理部５１Ａは、その呼をオペレータ端末１４へ転送し（Ｓ１０３）、当該処理を終了する（ＥＮＤ）。

転送不可能な場合（Ｓ１０２：ＮＯ）、転送処理部５１Ａは、保留管理テーブル１０２に登録されている保留数が閾値よりも多いか（保留数＞閾値）否かを判定する（Ｓ１１０）。

保留数が閾値以下（保留数≦閾値）である場合（Ｓ１１０：ＮＯ）、転送処理部５１Ａは、その呼を保留管理テーブル１０２へ登録（保留）し（Ｓ１３０）、当該処理を終了する（ＥＮＤ）。短い保留時間でオペレータ端末１４へ転送できる可能性が高いからである。

保留数が閾値より多い（保留数＞閾値）場合（Ｓ１１０：ＹＥＳ）、転送処理部５１Ａは、ＩＶＲ１２の自動応答部４２を用いてユーザ端末１１に対して、予約ＣＢ時間を含むＳＭＳを送信してもよいか否かを問い合わせる（Ｓ１１１）。保留時間が長くなる可能性が高いからである。

ユーザ端末１１からＳＭＳ送信が拒否された場合（Ｓ１１１：ＮＯ）、転送処理部５１Ａは、その呼を保留管理テーブル１０２Ａへ登録（保留）し（Ｓ１３０）、当該処理を終了する（ＥＮＤ）。ユーザが保留を選択したからである。

ユーザ端末１１からＳＭＳ送信が許可された場合（Ｓ１１１：ＹＥＳ）、転送処理部５１Ａは、呼を切断する（Ｓ１１２）。つまり、転送処理部５１Ａは、その呼を保留しない。そして、転送処理部５１Ａは、ＣＢ時間決定部５２に、予約ＣＢ時間の決定を指示する（Ｓ１１３）。ＣＢ時間決定部５２の処理については後述するが、ＣＢ時間決定部５２は、決定した予約ＣＢ時間を転送処理部５１Ａに返す。

転送処理部５１Ａは、その予約ＣＢ時間をＣＢ時間管理テーブル１０３に登録する（Ｓ１１４）。

転送処理部５１は、ＷＥＢ処理部３３に、予約ＣＢ時間の変更及びキャンセル用のＷＥＢページを生成するよう指示する（Ｓ１１５）。ＷＥＢ処理部３３は、生成したＷＥＢページのＵＲＬを転送処理部５１Ａに返す。

転送処理部５１Ａは、ＳＭＳ処理部３２に、予約ＣＢ時間と、変更及びキャンセル用のＷＥＢページのＵＲＬとを含むＳＭＳを生成し、そのＳＭＳを呼の発信元の電話番号（ユーザ端末１１）に送信するように指示する（Ｓ１１６）。ＳＭＳ処理部３２は、この指示に基づいてＳＭＳを生成し、送信する。そして、転送処理部５１Ａは、当該処理を終了する（ＥＮＤ）。

以上の処理により、制御サーバ１３Ａは、保留時間が長くなりそうな場合に、予約ＣＢ時間を含むＳＭＳをユーザ端末１１へ送信することができる。

図１０は、ＣＢ時間決定部５２の処理例を示すフローチャートである。図１０は、図９のステップＳ１１３の詳細である。

ＣＢ時間決定部５２は、ＣＢ時間管理テーブル１０３を参照し、「予約数１３２＜最大予約数１３３」の複数のＣＢ時間１３１を、予約ＣＢ時間候補として抽出する（Ｓ２０１）。

ＣＢ時間決定部５２は、その抽出した複数の予約ＣＢ時間候補を、ＩＶＲ１２の自動応答部４２を用いてユーザ端末１１へ自動音声案内する（Ｓ２０２）。

ＣＢ時間決定部５２は、ユーザ端末１１からプッシュ信号によって選択された１つの予約ＣＢ時間候補を受領する（Ｓ２０３）。

ＣＢ時間決定部５２は、その受領した１つの予約ＣＢ時間候補を、予約ＣＢ時間に決定する（Ｓ２０４）。ＣＢ時間決定部５２は、その予約ＣＢ時間を転送処理部５１Ａへ返し、当該処理を終了する（ＥＮＤ）。

なお、ＣＢ時間決定部５２は、ユーザ端末１１に予約ＣＢ時間候補を提供せずに、ＣＢ時間管理テーブル１０３を参照し、「予約数１３２＜最大予約数１３３」のＣＢ時間１３１の中から、１つの予約ＣＢ時間を決定してもよい。以上の処理により、予約ＣＢ時間が決定される。

第１の実施形態に係る構成によれば、次の効果を得ることができる。
（１）保留時間が長くなりそうなユーザに対して予約ＣＢ時間を含むＳＭＳを送信することにより、保留時間が長くオペレータになかなか繋がらないといったユーザの不満を緩和することができる。
（２）ユーザは、電話がオペレータに繋がらない場合、ＳＭＳによって通知された予約ＣＢ時間に、オペレータからＣＢしてもらうことができる。よって、何時かけてもオペレータに繋がらないといったユーザの不満を緩和できる。
（３）コールセンタが予約ＣＢ時間を決定できるので、時間帯によって大きく変動し得る着呼数を平準化することができる。よって、オペレータの人数をピーク時に合わせる必要がなくなり、オペレータに要するコスト増を抑制することができる。
（４）ユーザは、ＳＭＳに含まれるＵＲＬから、予約ＣＢ時間を容易に変更及びキャンセルすることができるので、オペレータからのＣＢにユーザが応答してくれる可能性が高くなる。よって、オペレータがＣＢをしてもユーザが応答しないといったロスを減らすことができる。
（５）保留中に切断されたユーザに対して予約ＣＢ時間を含むＳＭＳを送信することにより、オペレータに繋がらなかった新規ユーザの取りこぼしを減らすることができる。

＜第２の実施形態＞
第１の実施形態では、オペレータ端末１４からユーザ端末１１へＣＢする実施形態を示したが、第２の実施形態では、ユーザ端末１１からオペレータ端末１４へかけ直す実施形態を示す。以下、第１の実施形態と同様の構成及び機能を有するブロックには同じ符号を付し、説明を省略する。

図１１は、第２の実施形態に係る各装置が有する機能の例を示すブロック図である。

（制御サーバ１３Ｂの機能）
制御サーバ１３Ｂは、機能として、転送処理部５１Ｂと、優先時間決定部７２と、ＳＭＳ処理部５３と、ＷＥＢ処理部５４と、ユーザ管理テーブル１０１と、保留管理テーブル１０２Ｂと、優先時間管理テーブル１０６と、を有する。以下、各機能及びテーブルについて説明する。

図１２は、保留管理テーブル１０２Ｂの構成例を示す。
保留管理テーブル１０２Ｂは、保留中の呼を管理する。保留管理テーブル１０２Ｂには、ＩＶＲ１２が呼を確立したものの、例えば、全てのオペレータ端末１４がビジー（対応不可能）であるため、何れのオペレータ端末１４にも転送できない呼が登録（保留）される。

保留管理テーブル１０２Ｂは、転送順番１２１と、電話番号１２２と、優先度１２３とを対応付けて管理する。図１２に示すレコード１５０ａは、転送順番「１位」の保留中の電話番号は「０９０−７７７７−８８８８」であることを示す。

転送処理部５１は、オペレータ端末１４のビジーが解消された場合、転送順番１２１の先頭から順番に、その保留されていた呼をオペレータ端末１４へ転送する。転送済みの保留は、保留管理テーブル１０２Ｂから削除される。通話が切断された保留も、保留管理テーブル１０２Ｂから削除される。

優先度１２３は、その保留が、優先時間内に着呼したものであるか否かを示す。例えば、優先時間内に着呼した保留の優先度１２３には「優先」が、それ以外の優先度１２３には「通常」が登録される。優先度１２３は、転送処理部５１Ｂが転送順番を調整する際に用いられる。例えば、転送処理部５１Ｂは、保留の優先度１２３が「優先」の呼を保留管理テーブル１０２Ｂに登録する場合、登録済みの優先度１２３が「通常」の呼よりも転送順番１２１が先になるように登録する。

図１３は、優先時間管理テーブル１０６の構成例を示す。
優先時間管理テーブル１０６は、優先時間に関する情報（「優先時間情報」という）を管理する。優先時間情報は、優先時間１６１と、予約数１６２と、最大予約数１６３と、電話番号１６４とを対応付ける。優先時間情報は、さらに、ユーザ名１３５と、用件１３６とを対応付けてもよい。

優先時間１６１は、ユーザ端末１１からの呼を優先的にオペレータ端末１４へ転送する時間帯を示す。ユーザ端末１１へは、ＳＭＳによって、優先的に転送される時間帯（予約優先時間）が予め通知される。

最大予約数１６３は、各優先時間１６１において登録可能な予約優先時間の最大数を示す。予約数１６２は、各優先時間１６１において登録されている予約優先時間の数を示す。つまり、「予約数１６２＝最大予約数１６３」となった優先時間１６１には、これ以上予約優先時間を登録することができない。例えば、図１３の優先時間１６１「１３：３０−１４：００」には、既に最大予約数１６３「８」と同じ予約数１６２「８」が登録されているので、この優先時間１６１には、これ以上予約優先時間を登録することができない。

最大予約数１６３は、優先時間１６１毎に異なる設定であってもよい。例えば、統計的にＩＶＲ１２の着呼件数が比較的多い時間帯は、その時間帯を含む優先時間１６１の最大予約数１６３を小さく設定してもよい。例えば、統計的にＩＶＲ１２の着呼件数が比較的少ない時間帯は、その時間帯を含む優先時間１６１の最大予約数１６３を大きく設定してもよい。これにより、或る時間帯に集中していた着呼件数を平準化することができる。

電話番号１３４には、優先時間１６１に予約優先時間を登録したユーザ端末１１の電話番号が登録される。

以下、図１１の説明に戻る。
転送処理部５１Ｂは、呼の転送および予約優先時間に関する処理を実行する。転送処理部５１Ｂは、ＩＶＲ１２が確立したユーザ端末１１との間の呼を、オペレータ端末１４へ転送可能な否か判定する。例えば、転送処理部５１Ｂは、対応可能なオペレータ端末１４が存在する場合、「転送可」と判定し、何れのオペレータ端末１４も対応不可能な場合、「転送不可」と判定する。転送処理部５１Ｂは、「転送可」と判定した場合、その呼を対応可能なオペレータ端末１４へ転送する。転送処理部５１Ｂは、転送不可能と判定した場合、その呼を保留管理テーブル１０２Ｂに保留する。

このとき、転送処理部５１Ｂは、その呼の発信元の電話番号が優先時間管理テーブル１０６に登録されており、且つ、着呼の時刻が優先時間１６１の範囲内である場合、優先度１２３を「優先」として、優先度１２３が「通常」の保留よりも転送順番１２１が先になるように、その呼を保留管理テーブル１０２Ｂに登録（保留）する。ここで、転送処理部５１Ｂは、保留管理テーブル１０２Ｂに優先度１２３４が「優先」の保留が存在する場合、その保留よりも転送順番１２１が後になるように、その呼を登録（保留）してもよい。

転送処理部５１Ｂは、その呼が、上記の条件に該当しない場合、優先度１２１を「通常」として、優先度１２３が「通常」の保留の最後の転送順番１２１となるように、その呼を保留管理テーブル１０２に登録（保留）する。上記の条件とは、例えば、その呼の発信元の電話番号が優先時間管理テーブル１０６に登録されていない、又は、着呼の時刻が優先時間１６１の範囲外である場合である。これにより、優先時間内の着呼は、通常の着呼よりも優先的にオペレータへ転送される。

転送処理部５１Ｂは、呼の発信元（保留中の呼でもよい）のユーザ端末１１に対して、予約優先時間を含むＳＭＳを送信するか否かを判定する。転送処理部５１Ｂは、例えば、次の条件に基づいて、この判定を行う。
（１）転送処理部５１Ｂは、ユーザ端末１１から予約優先時間が要求された場合、予約優先時間を含むＳＭＳを送信すると判定する。例えば、ユーザ端末１１のプッシュ信号から、予約優先時間の要求が選択された場合である。
（２）転送処理部５１Ｂは、ユーザ端末１１との間の呼を確立した時点の保留管理テーブル１０２Ｂにおける保留数が、閾値よりも多い場合、予約優先時間を含むＳＭＳを送信すると判定する。保留時間が長くなる可能性が高いからである。
（３）転送処理部５１Ｂは、保留時間が閾値以上となった場合、その保留中のユーザ端末１１に、予約優先時間を含むＳＭＳを送信すると判定する。ユーザの不満を緩和するためである。
（４）転送処理部５１Ｂは、保留中に切断された場合、その保留中であったユーザ端末１１に、予約優先時間を含むＳＭＳを送信すると判定する。新規ユーザの取り逃がしを防ぐためである。

転送処理部５１Ｂは、予約優先時間を含むＳＭＳを送信すると判定した場合、予約優先時間を決定するよう優先時間決定部７２に指示する。そして、転送処理部５１Ｂは、優先時間決定部７２の決定した予約優先時間を取得し、優先時間管理テーブル１０６に登録する。優先時間決定部７２の処理の詳細については後述する。

転送処理部５１Ｂは、予約優先時間を変更および／又はキャンセルするためのＷＥＢページを作成するようＷＥＢ処理部５４に指示する。そして、転送処理部５１Ｂは、ＷＥＢ処理部５４の作成したＷＥＢページのＵＲＬを取得する。ＷＥＢ処理部５４の処理の詳細については後述する。

転送処理部５１Ｂは、優先時間決定部７２の決定した予約優先時間と、ＷＥＢ処理部５４の作成したＷＥＢページのＵＲＬとを含むＳＭＳを、予約優先時間を含むＳＭＳを送信すると判定したユーザ端末１１に送信するようＳＭＳ処理部５３に指示する。ＳＭＳ処理部５３は、この指示を受けて、ユーザ端末１１の電話番号を送信先としたＳＭＳを生成し、その生成したＳＭＳを送信する。

転送処理部５１Ｂは、ＳＭＳがユーザ端末１１に到達したか否かを確認することができる。よって、転送処理部５１Ｂは、所定時間内にＳＭＳがユーザ端末１１に到達したことを確認できない場合、そのＳＭＳに含まれる予約優先時間に係る優先時間情報を優先時間管理テーブル１０６から削除し、そのＳＭＳに含まれるＵＲＬに対応するＷＥＢページを破棄してもよい。

優先時間決定部７２は、ユーザ端末１１に対する予約優先時間を決定する。優先時間決定部７２は、例えば、次の条件に基づいて、予約優先時間を決定する。

（１）優先時間決定部７２は、優先時間管理テーブル１０６において「予約数１６２＜最大予約数１６３」を満たす優先時間１６１の中から１つの予約優先時間を決定する。このとき、優先時間決定部７２は、上記条件を満たす優先時間１６１の内、最大予約数１６３と予約数１６２との差分が最大の優先時間１６１を、予約優先時間に決定してもよい。

または、優先時間決定部７２は、上記条件を満たす優先時間１６１の内、ユーザ端末１１からの着呼の時刻から最も近い優先時間１６１を、予約優先時間に決定してもよい。

または、優先時間決定部７２は、新規ユーザか否か（既存ユーザか）に基づいて、予約優先時間を決定してもよい。例えば、上記条件を満たす優先時間１６１の内、新規ユーザの場合は、最大予約数１６３と予約数１６２との差分が最大の優先時間１６１を、予約優先時間に決定し、既存ユーザの場合は、ユーザ端末１１からの着呼の時刻から最も近い優先時間１６１を、予約優先時間に決定してもよい。なぜなら、新規ユーザは、既存ユーザと比較して、オペレータの対応する時間が長くなりやすいからである。

（２）優先時間決定部７２は、優先時間管理テーブル１０６において「予約数１６２＜最大予約数１６３」を満たす優先時間１６１の一部又は全部を、複数の予約優先時間候補としてユーザ端末１１に通知し、ユーザ端末１１から選択された１つの予約優先時間候補を、予約優先時間に決定する。このとき、優先時間決定部７２は、ＩＶＲ１２を用いて、複数の予約優先時間候補をユーザ端末へ自動音声案内し、ユーザ端末１１からプッシュ信号によって１つの予約優先時間候補を選択させてもよい。

優先時間決定部７２は、予約優先時間候補の数が閾値より多い場合、上記（１）で述べた各種条件に基づいて閾値以下の数の予約優先時間候補に絞った上で、絞られた予約優先時間候補をユーザ端末１１へ通知してもよい。

図１４は、予約優先時間を含むＳＭＳの例を示す。
ユーザ端末１１のＳＭＳ処理部３２は、制御サーバ１３Ｂから予約優先時間を含むＳＭＳを受信すると、ＵＩ部３４を通じて、図１４に示すようなＳＭＳの内容４００を表示する。

ＳＭＳの内容４００には、例えば、送信元の情報４０１と、送信先の電話番号４０２と、予約優先時間４０３と、予約優先時間の変更用ＷＥＢページのＵＲＬ４０４と、予約優先時間のキャンセル用ＷＥＢページのＵＲＬ４０５と、が含まれる。

ユーザは、図１４に示すＳＭＳの内容４００の予約優先時間４０３を見て、コールセンタに電話すると優先的にオペレータに転送される時間帯が「１４：００−１４：３０」であることを知る。ユーザが予約優先時間４０３を選択すると、ユーザ端末１１は、その予約優先時間「１４：００−１４：３０」を、ユーザ端末１１にインストールされているスケジュールアプリケーション及び／又はリマインダーアプリケーション等に登録してもよい。

また、ＳＭＳの内容４００には、コールセンタの電話番号４０６が含まれてもよい。ユーザが電話番号４０６を選択すると、ユーザ端末１１は、この電話番号４０６に発呼してもよい。これにより、ユーザは、簡単にコールセンタに電話をかけ直すことができる。

ユーザが変更用ＷＥＢページのＵＲＬ４０４を選択すると、ユーザ端末１１のＷＥＢ処理部３３は、そのＵＲＬにアクセスし、変更用ＷＥＢページのデータを取得して表示する。ユーザは、変更用ＷＥＢページを操作して、予約優先時間を変更することができる。変更用ＷＥＢページの例については後述する。このように、ユーザは、予約優先時間を容易に変更することができる。

ユーザがキャンセル用ＷＥＢページのＵＲＬ４０５を選択すると、ユーザ端末１１のＷＥＢ処理部３３は、そのＵＲＬへアクセスし、キャンセル用ＷＥＢページのデータを取得して表示する。ユーザは、キャンセル用ＷＥＢページを操作して、予約優先時間をキャンセルすることができる。制御サーバ１３ＢのＷＥＢ処理部３３は、ユーザ端末１１からキャンセル要求が送信されると、その予約優先時間に対応する優先時間情報を優先時間管理テーブル１０６から削除する。このように、ユーザは、予約優先時間を容易にキャンセルすることができる。

図１５は、優先時間変更用のＷＥＢページの例を示す。
ＳＭＳの内容４００から変更用ＷＥＢページのＵＲＬ４０４が選択されると、ユーザ端末１１のＷＥＢ処理部３３は、ＵＩ部３４を通じて、例えば、図１５に示すような変更用ＷＥＢページ５００を表示する。

予約状況５０２が「予約不可」の優先時間５０１は、予約優先時間の登録が不可能な優先時間である。例えば、優先時間管理テーブル１０６において「予約数１６２＝最大予約数１６３」のＣＢ時間である。

予約状況５０２が「予約中」の優先時間５０１は、登録中の予約優先時間である。つまり、優先時間管理テーブル１０６に登録済みの予約優先時間である。

予約状況５０２が「空欄」の優先時間５０１は、予約優先時間の登録が可能な優先時間である。例えば、優先時間管理テーブル１０６において「予約数１３２＜最大予約数１３３」の優先時間である。

図１５において、ユーザが、予約状況５０２が「空欄」の優先時間５０１「１４：３０−１５：００」を選択すると、その選択された予約状況５０２の「空欄」が「予約変更」に変更される（符号５１１）。

そして、ユーザが「送信」ボタン５２０を選択すると、ユーザ端末１１のＷＥＢ処理部３３は、「予約変更」に変更された優先時間「１４：３０−１５：００」を、制御サーバ１３Ｂへ送信する。制御サーバ１３ＢのＷＥＢ処理部５４は、その変更された優先時間「１４：３０−１５：００」を受信し、優先時間管理テーブル１０６に登録済みの予約優先時間「１４：００−１４：３０」を、変更後の優先時間「１４：３０−１５：００」に変更する。

このように、ユーザは、自分の予定に合わせて柔軟に予約優先時間を変更及びキャンセルすることができる。これにより、コールセンタ側は、ユーザの満足度を高めることができる。

図１６はＳＭＳの送信及び優先時間に関する処理の例を示すシーケンスチャート例である。

ユーザ端末１１は、コールセンタ（ＩＶＲ１２）へ発呼する（Ｓ５１）。発呼の発信元にはユーザ端末１１の電話番号、発信先にはコールセンタ（ＩＶＲ１２）の電話番号が含まれる。ＩＶＲ１２は、着呼を検知して応答を返し、ユーザ端末１１とＩＶＲ１２との間で呼を確立する（Ｓ５２）。ＩＶＲ１２は、ユーザ端末１１と呼を確立した旨を、制御サーバ１３Ｂへ通知する（Ｓ５３）。

制御サーバ１３Ｂは、その呼をオペレータ端末１４へ転送可能か否か判定する（Ｓ５４）。ここでは、制御サーバ１３Ｂが「転送不可」と判定したとする。

「転送不可」と判定した場合、制御サーバ１３Ｂは、優先時間管理テーブル１０６を参照し、呼の発信元の電話番号が優先転送に該当するか否かを判定する（Ｓ５５）。ここでは、呼の発信元の電話番号が優先時間管理テーブル１０６に登録されておらず、制御サーバ１３Ｂは、この呼を「通常転送」と判定したとする。

「通常転送」と判定した場合、制御サーバ１３Ｂは、その呼の優先度１２３を「通常」として保留管理テーブル１０２Ｂに登録（保留）する（Ｓ５６）。

制御サーバ１３Ｂは、所定の条件に基づいて、予約優先時間を含むＳＭＳを送信可能か否か判定する（Ｓ５７）。ここでは、制御サーバ１３Ｂが、ＳＭＳを「送信可」と判定したとする。

ＳＭＳを「送信可」と判定した場合、制御サーバ１３Ｂは、ＩＶＲ１２に、ユーザ端末１１との間の呼を切断するよう指示する（Ｓ５８）。この指示を受けてＩＶＲ１２は、ユーザ端末１１との間の呼を切断する（Ｓ５９）。

制御サーバ１３Ｂは、予約優先時間を決定し、その決定した予約優先時間を優先時間管理テーブル１０６に登録する（Ｓ６０）。制御サーバ１３Ｂは、その予約優先時間を含むＳＭＳをユーザ端末１１へ送信する（Ｓ６１）。ユーザ端末１１は、そのＳＭＳを受信し、ＳＭＳの内容を表示する（Ｓ６２）。

次に、予約優先時間内の処理を説明する。
ユーザ端末１１は、予約優先時間内に、コールセンタ（ＩＶＲ１２）へ発呼する（Ｓ７１）。ＩＶＲ１２は、着呼を検知して応答を返し、ユーザ端末１１とＩＶＲ１２との間で呼を確立する（Ｓ７２）。ＩＶＲ１２は、ユーザ端末１１と呼を確立した旨を、制御サーバ１３Ｂへ通知する（Ｓ７３）。

制御サーバ１３Ｂは、その呼をオペレータ端末１４へ転送可能か否か判定する（Ｓ７４）。ここでは、制御サーバ１３Ｂが「転送不可」と判定したとする。このステップＳ７１〜Ｓ７４の処理は、上記のステップＳ５１〜Ｓ５４の処理に対応する。

「転送不可」と判定した場合、制御サーバ１３Ｂは、優先時間管理テーブル１０６を参照し、呼の発信元の電話番号が優先転送に該当するか否かを判定する（Ｓ７５）。ここで、この呼は、発信元の電話番号がステップＳ６０において優先時間管理テーブル１０６に登録されており、且つ、着呼の時刻が優先時間の範囲内であるので、制御サーバ１３Ｂは、この呼を「優先転送」と判定する。

「優先転送」と判定した場合、制御サーバ１３Ｂは、その呼の優先度１２３を「優先」として保留管理テーブル１０２Ｂに登録（保留）する（Ｓ７６）。つまり、制御サーバ１３は、この呼の転送順番１２１が、優先度１２３が「通常」の保留中の呼よりも先となるように、この呼を保留管理テーブル１０２に登録（保留）する。

制御サーバ１３Ｂは、転送順番１２１に従って、保留中の呼をオペレータ端末１４へ転送する（Ｓ７７）。優先度１２３が「優先」の呼の転送順番１２１は、優先度１２１が「通常」の呼よりも先なので、この呼は、通常よりも短時間でオペレータ端末１４へ転送される。そして、オペレータ端末１４とユーザ端末１１との間に呼が確立する（Ｓ７８）。

上述の処理において、ユーザ端末１１および電話網１５が、呼を確立したままＳＭＳを受信できる構成である場合、ステップＳ５８及びＳ５９の呼切断の処理は行われなくてもよい。

以上の処理により、ユーザは、オペレータに電話が転送されなかった場合、ＳＭＳで通知された予約優先時間内にコールセンタへ電話をかけることにより、優先的にオペレータへ転送してもらうことができる。

図１７は、制御サーバ１３Ｂの転送処理部５１Ｂの処理の例を示すフローチャートである。

転送処理部５１Ｂは、ＩＶＲ１２の呼制御部４１から呼を確立した旨の通知を受けると（Ｓ４０１）、その呼をオペレータ端末１４へ転送可能か否かを判定する（Ｓ４０２）。

転送可能な場合（Ｓ４０２：ＹＥＳ）、転送処理部５１Ｂは、その呼をオペレータ端末１４へ転送し（Ｓ４０３）、当該処理を終了する（ＥＮＤ）。このとき、この呼に対応する優先時間情報が優先時間管理テーブル１０６に登録されている場合、転送処理部５１は、この優先時間情報を削除する。

転送不可能な場合（Ｓ４０２：ＮＯ）、転送処理部５１Ｂは、この呼が優先転送に該当するか否か判定する（Ｓ４１０）。つまり、転送処理部５１Ｂは、この呼の発信元の電話番号が優先時間管理テーブル１０６に登録されており、且つ、この呼の着呼の時刻が予約優先時間内であるか否かを判定する。

この呼が優先転送に該当する場合（Ｓ４１０：ＹＥＳ）、転送処理部５１Ｂは、優先度１２３を「優先」に設定する（Ｓ４１２）。そして、転送処理部５１Ｂは、この呼を、優先度１２３に基づいて、保留管理テーブル１０２Ｂに登録し（Ｓ４３０）、当該処理を終了する（ＥＮＤ）。

優先度１２３が「優先」の呼の場合、転送処理部５１Ｂは、その呼を、優先度１２３が「通常」の登録済みの呼よりも先の転送順番１２１となるように、保留管理テーブル１０２Ｂに登録する。このとき、転送処理部５１Ｂは、保留管理テーブル１０２Ｂに優先度１２３が「優先」の呼が登録済みの場合、この呼を、優先度１２３が「優先」の登録済みの呼よりも後の転送順番１２１となるように、保留管理テーブル１０２Ｂに登録してもよい。

この呼が優先転送に該当しない場合（Ｓ４１０：ＮＯ）、転送処理部５１Ｂは、優先度１２３を「通常」に設定する。そして、転送処理部５１Ｂは、保留管理テーブル１０２Ｂの保留数が閾値よりも多いか（保留数＞閾値）否かを判定する（Ｓ４１３）。

保留数が閾値以下（保留数≦閾値）である場合（Ｓ４１３：ＮＯ）、転送処理部５１Ｂは、優先度１２３が「通常」の呼を、保留管理テーブル１０２へ登録（保留）し（Ｓ４３０）、当該処理を終了する（ＥＮＤ）。短い保留時間でオペレータ端末１４へ転送できる可能性が高いからである。

保留数が閾値より多い（保留数＞閾値）場合（Ｓ４１３：ＹＥＳ）、転送処理部５１Ｂは、ＩＶＲ１２の自動応答部４２を用いてユーザ端末１１に対して、予約優先時間を含むＳＭＳを送信してもよいか否かを問い合わせる（Ｓ４１４）。保留時間が長くなる可能性が高いからである。

ユーザ端末１１からＳＭＳ送信が拒否された場合（Ｓ４１４：ＮＯ）、転送処理部５１Ｂは、優先度１２３が「通常」の呼を、保留管理テーブル１０２Ｂへ登録し（Ｓ４３０）、当該処理を終了する（ＥＮＤ）。ユーザが保留を選択したからである。

優先度１２３が「通常」の呼の場合、転送処理部５１Ｂは、その呼を、優先度１２３が「通常」の登録済みの呼よりも後の転送順番１２１となるように、保留管理テーブル１０２Ｂに登録する。

ユーザ端末１１からＳＭＳ送信が許可された場合（Ｓ４１４：ＹＥＳ）、転送処理部５１Ｂは、呼を切断する（Ｓ４１５）。つまり、転送処理部５１Ｂは、その呼を保留しない。そして、転送処理部５１Ｂは、優先時間決定部７２に、予約優先時間の決定を指示する（Ｓ４１６）。優先時間決定部７２の処理については後述するが、優先時間決定部７２は、決定した予約優先時間を転送処理部５１Ｂに返す。

転送処理部５１Ｂは、その予約優先時間を優先時間管理テーブル１０６に登録する（Ｓ４１７）。

転送処理部５１Ｂは、ＷＥＢ処理部５４に、予約優先時間の変更用及びキャンセル用のＷＥＢページを生成するよう指示する（Ｓ４１８）。ＷＥＢ処理部５４は、生成したＷＥＢページのＵＲＬを転送処理部５１Ｂに返す。

転送処理部５１Ｂは、ＳＭＳ処理部５３に、予約優先時間と、変更用及びキャンセル用のＷＥＢページのＵＲＬとを含むＳＭＳを生成し、そのＳＭＳを呼の発信元の電話番号（ユーザ端末１１）に送信するように指示する（Ｓ４１９）。ＳＭＳ処理部５３は、この指示に基づいてＳＭＳを生成し、送信する。そして、転送処理部５１Ｂは、当該処理を終了する（ＥＮＤ）。

以上の処理により、制御サーバ１３Ｂは、保留時間が長くなりそうな場合に、予約優先時間を含むＳＭＳをユーザ端末１１へ送信することができる。また、制御サーバ１３Ｂは、予約優先時間内にユーザ端末１１から着呼した通話を、優先的にオペレータ端末１４へ転送することができる。

図１８は、優先時間決定部７２の処理の例を示すフローチャートである。図１８は、図１７のステップＳ４１６の詳細である。

優先時間決定部７２は、優先時間管理テーブル１０６を参照し、「予約数１６２＜最大予約数１６３」の複数の優先時間１６１を、予約優先時間候補として抽出する（Ｓ５０１）。

優先時間決定部７２は、その抽出した複数の予約優先時間候補を、ＩＶＲ１２の自動応答部４２を用いてユーザ端末１１へ音声案内する（Ｓ５０２）。

優先時間決定部７２は、ユーザ端末１１からプッシュ信号によって選択された１つの予約優先時間候補を受領する（Ｓ５０３）。

優先時間決定部７２は、その受領した１つの予約優先時間候補を、予約優先時間に決定する（Ｓ５０４）。

優先時間決定部７２は、その予約優先時間を転送処理部５１Ｂへ返し、当該処理を終了する（ＥＮＤ）。

なお、優先時間決定部７２は、ユーザ端末１１に予約優先時間候補を提供せずに、優先時間管理テーブル１０６を参照し、「予約数１６２＜最大予約数１６３」の優先時間１６１の中から、１つの予約優先時間を決定してもよい。以上の処理より、予約優先時間が決定される。

第２の実施形態に係る構成によれば、次の効果を実現することができる。
（１）保留時間が長くなりそうなユーザに対して予約優先時間を含むＳＭＳを送信することにより、保留時間が長くオペレータになかなか繋がらないといったユーザの不満を緩和することができる。
（２）ユーザは、電話がオペレータに繋がらない場合、ＳＭＳによって通知された予約優先時間内に電話をかけることで、オペレータに優先的に転送してもらうことができる。よって、何時かけてもオペレータにつながらないといったユーザの不満を緩和できる。
（３）コールセンタが予約優先時間を決定できるので、時間帯によって大きく変動し得る着呼数を平準化することができる。よって、オペレータの人数をピーク時に合わせる必要がなくなるので、オペレータに要するコストを抑制することができる。
（４）第１の実施形態のようにオペレータからユーザにＣＢする方式の場合、ＣＢにユーザが応答しないというオペレータのロスが発生しうる。しかし、第２の実施形態はユーザにかけ直してもらう方式であるので、予約優先時間内にユーザがかけ直してくれなかったとしても、第１の実施形態のようなオペレータのロスが発生しない。
（５）保留中に切断された新規ユーザに対して予約優先時間を含むＳＭＳを送信することにより、オペレータに繋がらなかった新規ユーザの取りこぼしを減らすことができる。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１１…ユーザ端末 １２…ＩＶＲ １３Ａ、１３Ｂ…制御サーバ １４…オペレータ端末 １５…電話網 １６…通信網

Claims (1)

1. ユーザ端末との間に確立した第１の呼をオペレータ端末へ転送可能か否かを判定し、当該判定の結果が転送不可能な場合は、前記第１の呼を保留する転送処理部と、
   前記判定の結果が転送不可能な場合、後に前記ユーザ端末との間に確立する第２の呼の制御に用いられる予約時間を決定する時間決定部と、
   前記時間決定部によって決定された予約時間を含むメッセージを、前記第１の呼の発信元である前記ユーザ端末へ送信するメッセージ処理部と
   を備え、
   前記判定の結果が転送不可能であって、且つ、保留中に前記第１の呼が切断された場合に、前記予約時間を含むメッセージを前記ユーザ端末へ送信する
   呼制御サーバ。

Images