(57)【要約】【課題】  溢れ呼となった電話の発信者に、緊急性の高い発信者からコールバックを行うことができると共に、コールバックを行うことによる新たな溢れ呼の発生を抑止する溢れ呼のコールバックシステムを提供する。【解決手段】  溢れ呼となった電話番号を溢れ呼テーブルに順次登録することで、電話番号毎の単位時間あたりの溢れ呼回数を算出し、溢れ呼回数から発信者の緊急性の高さを判断する。また、定期的にオペレータの電話の対応状況やコールセンタへの着信件数の増減率などの監視を行い、その時々で状況に合わせた最適なコールバックの件数を算出し、その件数となるまで発信者にコールバックを行いオペレータと接続を行う。【選択図】  図１
2014187563.tif 000002
【特許請求の範囲】
【請求項１】
電話機からの通信を処理する処理部を有し、前記処理部は、溢れ呼となった電話番号毎の溢れ呼回数をカウントし、前記溢れ呼回数の多い電話番号からコールバックするコールバックシステム。
【請求項２】
請求項１記載のコールバックシステムであって、
前記処理部は、複数のオペレータの対応状況情報を記録し、
前記対応状況情報が着信待ちとなっているオペレータが存在する場合、コールバックするコールバックシステム。
【請求項３】
請求項２記載のコールバックシステムであって、
前記処理部は、前記溢れ呼回数が多い電話番号順にコールバックし、所定の閾値以下の溢れ呼回数の電話番号をコールバックの対象から除外するコールバックシステム。
【請求項４】
請求項３記載のコールバックシステムであって、
前記処理部は、着信待ちとなっているオペレータの割合を前記対応状況情報から算出し、
着信件数情報に基づき所定の時間における着信件数の増減率を算出し、
前記着信待ちとなっているオペレータの割合と前記着信件数の増減率を乗算することにより、コールバックするオペレータ数を決定するコールバックシステム。
【請求項５】
電話機からの通信を処理する処理部により、溢れ呼となった電話番号毎の溢れ呼回数をカウントし、
前記溢れ呼回数の多い電話番号からコールバックするコールバック方法。
【請求項６】
請求項５記載のコールバック方法であって、
前記処理部は、複数のオペレータの対応状況情報を記録し、
前記対応状況情報が着信待ちとなっているオペレータが存在する場合、コールバックするコールバック方法。
【請求項７】
請求項６記載のコールバック方法であって、
前記処理部は、前記溢れ呼回数が多い電話番号順にコールバックし、所定の閾値以下の溢れ呼回数の電話番号をコールバックの対象から除外するコールバック方法。
【請求項８】
請求項７記載のコールバック方法であって、
前記処理部は、着信待ちとなっているオペレータの割合を前記対応状況情報から算出し、
着信件数情報に基づき所定の時間における着信件数の増減率を算出し、
前記着信待ちとなっているオペレータの割合と前記着信件数の増減率を乗算することにより、コールバックするオペレータ数を決定するコールバック方法。
【発明の詳細な説明】
【技術分野】
【０００１】
コールセンタシステムに関する。特に、溢れ呼となった電話番号にコールバックを行う処理に関する。
【背景技術】
【０００２】
コールセンタでは、電話が集中して溢れ呼が発生する場合がある。溢れ呼となった場合は、発信者は電話が繋がるまで待ち続けるか、後で電話を掛け直す必要がある。コールセンタが、自動音声ガイダンスによってコールバック予約を受け付けている場合は、コールバック予約を行い、コールセンタからのコールバックを待つ方法もある。これに関する技術として、特許文献１が挙げられる。特許文献１には、自動音声ガイダンスにより発信者の希望する条件、及び、用件の内容をコールバック予約として受け付け、これに応じてコールバックを行う時期や発信先、順序を調整する技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１２−２８８３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１では、自動音声ガイダンスにて発信者にコールバック予約をしてもらわなければ、コールセンタからコールバックをすることができない。また、コールバックを行う順序は、コールバック予約の内容に基づくため、複数の発信者が同一のコールバック予約をした場合、どの発信者の緊急性が高いかを判断することが難しい。
【課題を解決するための手段】
【０００５】
そこで、本発明では、  電話機からの通信を処理する処理部を有し、前記処理部は、溢れ呼となった電話番号毎の溢れ呼回数をカウントし、前記溢れ呼回数の多い電話番号からコールバックする。
【発明の効果】
【０００６】
本発明によれば、溢れ呼となった電話の発信者に対してコールセンタからコールバックを行うために、発信者にコールバック予約させる必要がない。また、オペレータを効率的に活用し、緊急性の高い発信者からコールバックを行うことができると共に、コールバックを行うことによる新たな溢れ呼の発生を抑止する。
【図面の簡単な説明】
【０００７】
【図１】コールバックシステムの構成図である。
【図２】溢れ呼テーブルのデータ構成図である。
【図３】オペレータ対応状況テーブルのデータ構成図である。
【図４】着信件数テーブルのデータ構成図である。
【図５】コールバック判定テーブルのデータ構成図である。
【図６】電話番号ファイルのデータ構成図である。
【図７】実施例１における全体処理のフローチャートである。
【図８】コールバック判定処理部のフローチャートである。
【図９】溢れ呼集計処理部のフローチャートである。
【図１０】電話発信処理部のフローチャートである。
【発明を実施するための形態】
【０００８】
以下、図面を用いて本発明に関する実施の形態を説明する。
図１は、コールセンタのコールバックシステム１３の構成図である。コールバックシステム１３は、構内交換機１、公衆電話網、携帯電話網などの電話網３、オペレータ用電話機／端末４、ＩＰ網、社内電話網などの社内ネットワーク網５から構成される。構内交換機１と電話機２は電話網３、構内交換機１とオペレータ用電話機／端末４は社内ネットワーク網５によって接続されている。
【０００９】
電話機２は、公衆電話網、携帯電話網などの電話網３を介して、コールセンタ１３に接続されている。電話機２は、固定電話に限定されず、インターネット電話やＩＰ電話等のオペレータと会話できるものであればよい。
【００１０】
構内交換機１は、ＣＴＩ（Ｃｏｍｐｕｔｅｒ Ｔｅｌｅｐｈｏｎｙ Ｉｎｔｅｇｒａｔｉｏｎ)に関する様々な機能を有しているものとし、処理部１０と記憶部１１から構成される。処理部１０は、溢れ呼のコールバックを行うために、溢れ呼蓄積処理部１００、コールバック判定処理部１０１、溢れ呼集計処理部１０２、電話発信処理部１０３の機能を有している。処理部１は、単一の中央演算装置（CPU）又は複数のCPUから構成することができる。記憶部１１に、溢れ呼テーブル１１０、オペレータ対応状況テーブル１１１、着信件数テーブル１１２、コールバック判定テーブル１１３、電話番号ファイル１１４などのデータが格納される。処理部１は、記憶部１１に格納されている情報をメモリ４に読み込んだ上で、実行する。
【００１１】
図２は、溢れ呼テーブル１１０のデータ構成図である。なお、溢れ呼とは、ピーク時にオペレータが対応処理しきれない状態のことをいう。溢れ呼テーブル１１０は、溢れ呼となった発信者の電話番号２１と、その溢れ呼が着信した日時２２を保持する。
【００１２】
図３は、オペレータ対応状況テーブル１１１のデータ構成図である。オペレータ対応状況テーブル１１１は、コールセンタにて現在電話対応業務を行っているオペレータ名３１と、そのオペレータの対応状況３２を保持する。本実施零では、オペレータの対応状況３２は、通話中、データ入力中、着信待ちの３種の値のいずれかとなっている。通話中は、そのオペレータが他者と通話している最中であることである。データ入力中は、通話終了後にシステムに対応履歴などのデータを登録している最中であることである。着信待ちは、次の電話を受けるために待機中であることである。オペレータ対応状況テーブル１１１は、構内交換機１によって、リアルタイムにオペレータの対応状況を判断し、テーブル情報が更新されるものとする。
【００１３】
図４は、着信件数テーブル１１２のデータ構成図である。着信件数テーブル１１２は、集計期間４１と、その期間における着信件数４２を保持する。本実施例では、集計期間４１として５分間隔にレコードを保持する。着信件数テーブル１１２は、構内交換機１によって、リアルタイムに着信件数が集計され、テーブル情報が更新されるものとする。
【００１４】
図５は、コールバック判定テーブル１１３のデータ構成図である。コールバック判定テーブル１１３に、着信待ちのオペレータの割合５１、着信件数の増減率５２と、コールバックを行うオペレータの割合５３が保持される。例えば、現在の着信待ちオペレータの割合５１が１０％、着信件数５２の増減率が−２％の場合、着信待ちオペレータのうちコールバックを行うオペレータの割合５３は２０％５４となる。コールバックを行うオペレータの割合５３は、過去の実績から予め定義されているものとする。この値が大きすぎると、コールバックを行うことで、電話を受けることのできるオペレータがいなくなり、新たな溢れ呼を発生させてしまう可能性がある。また、この値が小さすぎると、着信待ちのオペレータが多くなり、オペレータを効率よく電話対応業務に従事させることができない。
【００１５】
図６は、電話番号ファイル１１４のデータ構成図である。電話番号ファイル１１４は、当日に溢れ呼となった電話の発信者の電話番号６１と、その発信者からの電話が当日に溢れ呼となった溢れ呼回数６２を保持する。
【００１６】
次に、この実施の形態による溢れ呼のコールバックシステムを用いた具体例を図２〜１０を用いて説明する。以下、図７に示す実施例１における全体処理のフローチャートの流れに沿って説明を行う。
【００１７】
まず、図７（１）溢れ呼発生時のフローについて説明する。発信者がコールセンタに電話をかけてきた際、全てのオペレータが通話中または何らかの理由で電話を受話できなければ、その電話は溢れ呼となる。溢れ呼が発生した場合、その情報は、溢れ呼蓄積処理部１００によって溢れ呼テーブル１０１に発信者の電話番号と着信日時が順次登録される（７０１）。緊急性の高い用件の場合は、発信者は溢れ呼となってオペレータと通話できなければ、何度も電話の掛け直しを行う。そのため、溢れ呼テーブル１０１には、緊急性の高い用件の同一電話番号のレコードが複数件登録される。また、一般的なコールセンタでは、午前９時〜１０時や午午後１時〜２時が特に着信件数の多い繁忙時間帯となっており、これらの時間帯に多くの溢れ呼を発生させている。
【００１８】
次に、図７（２）コールバック時のフローについて説明する。溢れ呼蓄積処理部１００によって登録された溢れ呼の電話番号に対してコールバックを行う。まず、コールバック判定処理部１０１は、オペレータ対応状況テーブルから着信待ちとなっているオペレータ数を計算する（７０２）。着信待ちとなっているオペレータが存在する場合、溢れ呼集計処理部により、溢れ呼の集計処理を実行する（７０３）。次に、電話発信処理部１０３により、電話発信の処理を実行する（７０４）。一方、着信待ちとなっているオペレータが存在しない場合、コールバック判定処理部１０１０は、処理を終了する。また、コールバック判定処理部１０１は、５分間隔でコールバックの処理を実行する。各処理の詳細を以下に説明する。
【００１９】
図８は、コールバック判定処理部１０１の詳細のフローである。コールバック判定処理部１０１は、まず、着信待ちとなっているオペレータの割合の算出処理を行う（８０１）。コールバック判定処理部１０１は、着信待ちとなっているオペレータの割合の算出処理を、オペレータ対応状況テーブル１１１を読み込み、現在電話対応業務を行っているオペレータ数、すなわち、オペレータ対応状況テーブル１１１の全レコード数と、着信待ちのオペレータ数、すなわち、着信待ちとなっているオペレータのレコード数をカウントし、着信待ちのオペレータ数を現在電話対応業務を行っているオペレータ数で除算することにより、着信待ちとなっているオペレータの割合により、算出する（８０１）。例えば、現在電話対応業務を行っているオペレータ数が１００人、着信待ちのオペレータ数が１０人であれば、着信待ちとなっているオペレータの割合は、１０％となる。
【００２０】
次に、コールバック判定処理部１０１は、着信件数の増減率の算出処理を行う（８０２）。コールバック判定処理部１０１は、着信件数テーブル１１２を読み込み、最新の２レコードを取得し、最新の５分間での着信件数の増減率を算出する（８０２）。例えば、現在が８月１５日１０時１２分であった場合、着信件数テーブル１１２から、８月１５日１０時０５分から１０時１０分と、８月１５日１０時００分から１０時０５分のレコードを取得し、その着信件数はそれぞれ、９８件４３、１００件４４であるので、着信件数の増減率は−２％となる。
【００２１】
最後に、コールバックを行うオペレータ数の算出処理を行う（８０３）。コールバック判定処理部１０１は、コールバック判定テーブル１１３を読み込み、着信待ちとなっているオペレータの割合の算出処理（８０１）で算出した着信待ちオペレータの割合と、着信件数の増減率の算出処理（８０２）で算出した着信件数の増減率に該当するレコードのコールバックを行うオペレータの割合５３を取得する。その後、着信待ちのオペレータ数とコールバックを行うオペレータの割合５３を乗算し、コールバックを行うオペレータ数を算出し、メモリ１４上に保持する。例えば、着信待ちのオペレータの割合が１０％、着信件数の増減率が−２％であれば、コールバックを行うオペレータの割合として、２０％５４が取得される。着信待ちのオペレータ数が１０人であれば、コールバックを行うオペレータ数は２人という情報がメモリ上に保持される。
【００２２】
図９は、溢れ呼集計処理部１０２のフローである（７０３）。溢れ呼集計処理部１０２は、まず、溢れ呼カウント処理を行う（９０１）。溢れ呼集計処理部１０２は、溢れ呼テーブル１１０を読み込み、電話番号毎にレコード件数をカウントを行い、電話番号毎に溢れ呼回数を集計した一覧を作成する（９０１）。次に、緊急度判定処理を行う（９０２）。溢れ呼集計処理部１０２は、溢れ呼となった回数が多い、つまり、発信者の電話の掛け直し回数が多いほど緊急性が高いと判断する。次に、溢れ呼集計処理部１０２は、電話番号毎に溢れ呼回数を集計した一覧を溢れ呼回数の多い電話番号の順にソートを行う（９０２）。そのため、上位にある電話番号ほど緊急性が高い電話番号となる。また、溢れ呼集計処理部１０２は、予め溢れ呼回数の閾値を定義しておき、閾値以下となった電話番号については、緊急性が低いとして一覧から削除する。
【００２３】
最後に、電話番号ファイル出力処理を行う（９０３）。溢れ呼集計処理部１０２は、ソートした電話番号毎に溢れ呼回数を集計した一覧を電話番号ファイル１１４として作成する（９０３）。
【００２４】
図１０は、電話発信処理部１０３のフローである。電話発信処理部１０３は、まず、着信待ちオペレータ抽出処理を行う（１００１）。電話発信処理部１０３は、オペレータ対応状況テーブル１１１を読み込み、着信待ちとなっているオペレータの一覧を取得する。
【００２５】
次に、電話発信処理部１０３は、コールバックを行うオペレータ数取得処理を行う（１００２）。電話発信処理部１０３は、メモリ上に保持されているコールバックを行うオペレータ数を取得する（１００２）。
【００２６】
次に、電話発信処理を行う（１００３）。電話発信処理部１０３は、電話番号ファイル１１４の先頭から順次電話を発信し、着信待ちとなっているオペレータの一覧からオペレータを選択し、電話を接続する（１００３）。電話発信処理部１０３は、電話番号ファイル１１４が終了、または、コールバックの発信数がコールバックを行うオペレータ数に達するまで、電話発信処理を繰り返す（１００３）。例えば、コールバックを行うオペレータ数が２の場合、図６に示す電話番号ファイル１１４の上から２つの発信者の電話番号「０８０−１１１１−１１１１」と「０９０−２２２２−２２２２」に電話を発信し、着信待ちのオペレータと接続する。なお、「０９０−３３３３−３３３３」には発信されない。
【００２７】
本実施形態によれば、オペレータを効率的に活用し、緊急性の高い発信者からコールバックを行うことができると共に、コールバックを行うことによる新たな溢れ呼の発生を抑止することが可能となる。
【００２８】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【符号の説明】
【００２９】
１      構内交換機
２      電話機
３      電話網
４      オペレータ用電話機／端末
５      社内ネットワーク
１０    処理部
１１    記憶部
１００  溢れ呼蓄積処理部
１０１  コールバック判定処理部
１０２  溢れ呼集計処理部
１０３  電話発信処理部
１１０  溢れ呼テーブル
１１１  オペレータ対応状況テーブル
１１２  着信件数テーブル
１１３  コールバック判定テーブル
１１４  電話番号ファイル
【図１】
2014187563.tif 000003
【図２】
2014187563.tif 000004
【図３】
2014187563.tif 000005
【図４】
2014187563.tif 000006
【図５】
2014187563.tif 000007
【図６】
2014187563.tif 000008
【図７】
2014187563.tif 000009
【図８】
2014187563.tif 000010
【図９】
2014187563.tif 000011
【図１０】
2014187563.tif 000012