(57)【要約】  コンタクトまたはコールセンターのような環境内で呼収益およびエージェントの生産性を増大させるための方法およびシステムが説明される。呼およびコンタクト情報を分類するのに属性が使用され得る。システムは収集されたデータから学習することができる。確率、呼収益、および予測呼対応時間のような予想を補助するために計算が実行され得る。そのような計算は、所望の結果を達成するための、コンタクトを発呼する最良の時間を求めるのに使用され得る。【選択図】  図２
2015526785.tif 000002
【特許請求の範囲】
【請求項１】
コンタクトセンターにおける生産性を増大させるための方法であって、
ａ）データベースからコンタクト情報を要求するステップと、
ｂ）前記データベースによって提供される前記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するステップと、
ｃ）前記指定ディメンション値を含むレコードを生成するステップと、
ｄ）前記ディメンション値に対する各結果コードに対する予測呼対応時間値、呼収益値、および確率を求めるために一連の計算を実行するステップと、
ｅ）結果コードのセットに対する確率、予測対応時間、および予測呼収益の予想を求めるステップと
を含む、方法。
【請求項２】
ステップ（ｄ）は、
ｄ．１）前記ディメンション値が結果コードを得る能力を求めてディメンション値について前記ディメンション値履歴レコードを検索するステップと、
ｄ．２）ステップ（ａ）の各結果からの確率をプールするステップと、
ｄ．３）確率を計算するステップと
をさらに含む、請求項１に記載の方法。
【請求項３】
ステップ（ｄ）は、
ｄ．１）呼の間に起こったことの分類を指定する文字列を含むラップコードを考慮することによって結果コードを計算するステップをさらに含む、請求項１に記載の方法。
【請求項４】
ｄ．１．１）前記結果コードを、成功、正しい相手、間違った相手、留守番電話、回線使用中、応答なし、エージェントによる他の対応、および機械による他の対応のうちの１つまたは複数として指定するステップをさらに含む、請求項３に記載の方法。
【請求項５】
ステップ（ｂ）は、
ｂ．１）前記コンタクト情報から、自動ディメンションデータ、時間ディメンションデータ、および人口学的ディメンションデータのうちの１つまたは複数を抽出するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記自動ディメンションデータは、前記システムが前記呼に対応するときに呼から抽出される、請求項５に記載の方法。
【請求項７】
前記自動ディメンションデータは、呼の結果、電話ユーザのタイプ、呼の長さ、コンタクトが保留にされた時間長、呼のエスカレート状態、電話のタイムゾーンオフセット、および、電話のタイムゾーン名のうちの１つまたは複数を含む、請求項５に記載の方法。
【請求項８】
前記時間ディメンションデータは、前記呼が開始された時間を考慮して呼から抽出される、請求項５に記載の方法。
【請求項９】
前記時間ディメンションデータは、間隔をおいてとられる日間通算時間、呼の曜日、呼の月、および呼の年のうちの１つまたは複数を含む、請求項５に記載の方法。
【請求項１０】
前記人口学的ディメンションデータは、コンタクトリストを含むデータベース内の指定フィールド内の指定値から抽出される、請求項５に記載の方法。
【請求項１１】
前記人口学的ディメンションデータは、場所、主要電話加入区域コード、社会的性別、婚姻区分、未払残高、郵便番号、信用度、年齢、収入、職業、および在留資格のうちの１つまたは複数を含む、請求項５に記載の方法。
【請求項１２】
前記人口学的ディメンションデータは、条件付きで定義される、請求項５に記載の方法。
【請求項１３】
前記人口学的ディメンションデータはユーザ定義である、請求項５に記載の方法。
【請求項１４】
前記人口学的ディメンションデータは自動的に与えられる、請求項５に記載の方法。
【請求項１５】
ステップ（ｅ）は、
ｅ．１）前記コンタクトの確率を有するコンタクトを所与として予測収益を乗算することによって、最高の収益生産性を有する、発呼するためのコンタクトを求めるステップと、
ｅ．２）前記ステップ（ｅ．１）の結果を予測対応時間で除算するステップと、
ｅ．３）前記最高の収益生産性を有するコンタクトを、コンタクトをとるために選択するステップと
をさらに含む、請求項１に記載の方法。
【請求項１６】
ステップ（ｅ）は、
ｅ．１）前記コンタクトの確率を有するコンタクトを所与として予測収益を乗算することによって、最高の収益生産性を有する、発呼するためのコンタクトを求めるステップと、
ｅ．２）前記ステップ（ｅ．１）の結果を予測対応時間によって除算するステップと、
ｅ．３）最高の総和を有するコンタクトのセットを、コンタクトをとるために選択するステップと
をさらに含む、請求項１に記載の方法。
【請求項１７】
前記ディメンション値は、コンタクトの挙動が他の日と異なると予測される日を除外する、請求項１に記載の方法。
【請求項１８】
前記日は休日である、請求項１７に記載の方法。
【請求項１９】
前記コンタクトの挙動が他の日と異なると予測される前記日に特別措置が適用される、請求項１７に記載の方法。
【請求項２０】
前記予測対応時間は、呼事象に寄与する対応時間の加重平均として計算される、請求項１に記載の方法。
【請求項２１】
前記予測対応時間は、数学的に適切な方法によって、各ディメンション値の予測確率によって、また、ディメンションにわたって重み付けされる、請求項２０に記載の方法。
【請求項２２】
コンタクトセンターにおける総収益を増大させるための方法であって、
ａ）データベースからコンタクト情報を要求するステップと、
ｂ）前記データベースによって提供される前記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するステップと、
ｃ）前記指定ディメンション値を含むレコードを生成するステップと、
ｄ）前記ディメンション値に対する各結果コードに対する呼収益値および確率を求めるために一連の計算を実行するステップと、
ｅ）結果コードのセットに対する確率および予測呼収益の予想を求めるステップと
を含む、方法。
【請求項２３】
ステップ（ｅ）は、
ｅ．１）前記コンタクトの最高収益を有するコンタクトを所与として予測収益を乗算することによって、最高収益を有する、発呼するためのコンタクトを求めるステップと、
ｅ．２）前記ステップ（ｅ．１）の結果を予測対応時間で除算するステップと、
ｅ．３）前記最高収益を有するコンタクトを、コンタクトをとるために選択するステップと
をさらに含む、請求項２２に記載の方法。
【請求項２４】
ステップ（ｂ）は、
ｂ．１）前記コンタクト情報から、自動ディメンションデータ、時間ディメンションデータ、および人口学的ディメンションデータのうちの１つまたは複数を抽出するステップをさらに含む、請求項２２に記載の方法。
【請求項２５】
前記自動ディメンションデータは、前記システムが前記呼に対応するときに呼から抽出される、請求項２４に記載の方法。
【請求項２６】
前記自動ディメンションデータは、呼の結果、電話ユーザのタイプ、呼の長さ、コンタクトが保留にされた時間長、呼のエスカレート状態、電話のタイムゾーンオフセット、および、電話のタイムゾーン名のうちの１つまたは複数を含む、請求項２４に記載の方法。
【請求項２７】
前記時間ディメンションデータは、前記呼が開始された時間を考慮して呼から抽出される、請求項２４に記載の方法。
【請求項２８】
前記時間ディメンションデータは、間隔をおいてとられる日間通算時間、呼の曜日、呼の月、および呼の年のうちの１つまたは複数を含む、請求項２４に記載の方法。
【請求項２９】
前記人口学的ディメンションデータは、コンタクトリストを含むデータベース内の指定フィールド内の指定値から抽出される、請求項２４に記載の方法。
【請求項３０】
前記人口学的ディメンションデータは、場所、主要電話加入区域コード、社会的性別、婚姻区分、未払残高、郵便番号、信用度、年齢、収入、職業、および在留資格のうちの１つまたは複数を含む、請求項２４に記載の方法。
【請求項３１】
前記人口学的ディメンションデータは、条件付きで定義される、請求項２４に記載の方法。
【請求項３２】
前記人口学的ディメンションデータはユーザ定義である、請求項２４に記載の方法。
【請求項３３】
前記人口学的ディメンションデータは自動的に与えられる、請求項２４に記載の方法。
【請求項３４】
コンタクトセンターにおける生産性を増大させるための方法であって、
ａ）データベースからコンタクト情報を要求するステップであって、前記データベースは、呼収益の実効結果を求めることが可能である、要求するステップと、
ｂ）前記データベースによって提供される前記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するステップと、
ｃ）前記指定ディメンション値を含むレコードを生成するステップと、
ｄ）前記ディメンション値に対する結果コードから予測呼対応時間値、呼収益値、および確率を求めるために一連の計算を実行するステップであって、
ｉ．前記値の、数学的に適切な様式で所望のコードを得る能力を求めて各ディメンション値に関する履歴レコードを検索することと、
ｉｉ．数学的に適切な様式で、各結果値の確率をプールして確率を求めることと、
ｉｉｉ．数学的に適切な様式で、呼の前記対応時間の加重平均を求めることと、
ｉｖ．数学的に適切な様式で、すべての所望の結果コードにわたって各所望の結果コードの値をプールすることと
のうちの１つまたは複数を含む、一連の計算を実行するステップと、
ｅ）予測対応時間および予測呼収益の予想を求めるステップと
を含む、方法。
【請求項３５】
コンタクトセンターにおける生産性を増大させるためのシステムであって、
ａ）呼収益の実効結果を求めることが可能な、データベースからコンタクト情報を要求するための手段と、
ｂ）前記コンタクト情報のディメンション値を解析するための手段と、
ｃ）前記指定ディメンション値を含むレコードを生成するための手段と、
ｄ）前記ディメンションに対する各結果コードに対する予測呼対応時間値、呼収益値、および確率を求めるための手段と、
ｅ）結果コードのセットに対する確率、予測対応時間、および予測呼収益の予想を求めるための手段と
を備える、システム。
【請求項３６】
コンタクトセンターにおける総収益を増大させるためのシステムであって、
ａ）データベースからコンタクト情報を要求するための手段と、
ｂ）前記データベースによって提供される前記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するための手段と、
ｃ）前記指定ディメンション値を含むレコードを生成するための手段と、
ｄ）前記ディメンション値に対する各結果コードに対する呼収益値および確率を求めるために一連の計算を実行するための手段と、
ｅ）結果コードのセットに対する確率および予測呼収益の予想を求めるための手段と
を備える、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、遠隔通信システムおよび方法ならびに機械学習の実行に関する。より詳細には、本発明は、これらのシステム内のコールエージェントの生産性および呼収益を改善する技法に関する。
【発明の概要】
【課題を解決するための手段】
【０００２】
たとえば、コンタクトまたはコールセンターのような環境内で呼収益およびエージェントの生産性を改善するための方法およびシステムが説明される。呼およびコンタクト情報を分類するのに属性が使用され得る。システムは収集されたデータから学習することができる。確率、呼収益、および予測呼対応時間のような予想を補助するために計算が実行され得る。そのような計算は、所望の結果を達成するための、コンタクトを発呼する最良の時間を求めるのに使用され得る。
【０００３】
一実施形態において、コンタクトセンターにおける生産性を増大させるための方法が提供され、方法は、データベースからコンタクト情報を要求するステップと、上記データベースから提供される上記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するステップと、上記指定ディメンション値を含むレコードを生成するステップと、上記ディメンション値に対する各結果コードに対する予測呼対応時間値、呼収益値、および確率を求めるために一連の計算を実行するステップと、結果コードのセットに対する確率、予測対応時間、および予測呼収益の予想を求めるステップとを含む。
【０００４】
別の実施形態において、コンタクトセンターにおける総収益を増大させるための方法が提供され、方法は、データベースからコンタクト情報を要求するステップと、上記データベースから提供される上記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するステップと、上記指定ディメンション値を含むレコードを生成するステップと、上記ディメンション値に対する各結果コードに対する呼収益値および確率を求めるために一連の計算を実行するステップと、結果コードのセットに対する確率および予測呼収益の予想を求めるステップとを含む。
【０００５】
別の実施形態において、コンタクトセンターにおける生産性を増大させるための方法が提示され、方法は、データベースからコンタクト情報を要求するステップであって、上記データベースは、呼収益の実効結果を求めることが可能である、要求するステップと、上記データベースによって提供される上記コンタクト情報のディメンション値を解析して予測指定ディメンション値を抽出するステップと、上記指定ディメンション値を含むレコードを生成するステップと、上記ディメンション値に対する結果コードから予測呼対応時間値、呼収益値、および確率を求めるために一連の計算を実行するステップであって、上記計算は、上記値の、数学的に適切な様式で所望のコードを得る可能性を求めて各ディメンション値について履歴レコードを検索することと、数学的に適切な様式で、各結果値の確率をプールして確率を求めることと、数学的に適切な様式で、呼の対応時間の加重平均を求めることと、数学的に適切な様式で、すべての所望の結果コードにわたって各所望の結果コードの値をプールすることの１つ以上を含む、一連の計算を実行するステップと、予測対応時間および予測呼収益の予想を求めるステップとを含む。
【０００６】
別の実施形態において、コンタクトセンターにおける生産性を増大させるためのシステムが提示され、システムは、呼収益の実効結果を求めることが可能なデータベースからコンタクト情報を要求するための手段と、上記コンタクト情報のディメンション値を解析するための手段と、上記指定ディメンション値を含むレコードを生成するための手段と、上記ディメンション値に対する各結果コードに対する予測呼対応時間値、呼収益値、および確率を求めるために一連の計算を実行するための手段と、結果コードのセットに対する確率、予測対応時間、および予測呼収益の予想を求めるための手段とを備える。
【０００７】
別の実施形態において、コンタクトセンターにおける総収益を増大させるためのシステムが提示され、システムは、データベースからコンタクト情報を要求するための手段と、上記データベースから提供される上記コンタクト情報のディメンション値を解析して指定ディメンション値を抽出するための手段と、上記指定ディメンション値を含むレコードを生成するための手段と、上記ディメンション値に対する各結果コードに対する呼収益値および確率を求めるために一連の計算を実行するための手段と、結果コードのセットに対する確率および予測呼収益の予想を求めるための手段とを備える。
【図面の簡単な説明】
【０００８】
【図１】システムの基本構成要素を示す図である。
【図２】予想を求めるプロセスの一実施形態を示す流れ図である。
【図３】ディメンション定義レコードを示すサンプル表の図である。
【図４】ディメンション−コンタクトリストの相互参照レコードを示すサンプル表の図である。
【図５】ディメンション値レコードを示すサンプル表の図である。
【図６】ディメンション値スーパーキーレコードを示すサンプル表の図である。
【図７】ディメンション文字列値レコードを示すサンプル表の図である。
【図８】ディメンション整数バンドレコードを示すサンプル表の図である。
【図９】公称日付レコードを示すサンプル表の図である。
【図１０】ディメンション日レコードを示すサンプル表の図である。
【図１１】特別日規則定義レコードを示すサンプル表の図である。
【発明を実施するための形態】
【０００９】
本発明の原理の理解を促進する目的で、図面に示されている実施形態を参照し、特定の文言がこれを説明するために使用される。それにもかかわらず、本発明の範囲の限定はそれによって意図されていないことが理解されよう。説明されている実施形態における任意の変更およびさらなる修正、ならびに本明細書に記載されている本発明の原理の任意のさらなる応用は、本発明が関連する技術分野における当業者に一般的に想起されるように企図されている。
【００１０】
企業は、自身のポートフォリオ内のアカウントにコンタクトをとるにあたって、エージェント、双方向音声応答（ＩＶＲ）能力、エージェントスキルセットなどのような自身のリソースの最良の使用を判定するときに問題を経験する。エージェントは、多数のアカウントを有し得、リソースを最大化するためにいずれにコンタクトをとるべきかに関する決定を提示されることが多い。所望の結果を達成するために各コンタクトを発呼するための最良の時間の判定は、時間、エネルギー、およびリソースを消費する。呼には、いくつかの時間帯において予測されるよりも多い、または少ない対応時間がかかる場合があり、さらには他の呼はまったく行われない場合がある。生産性を維持するために、エージェントは、時間の空白を埋めるためにスケジュールされていなかったアカウントに発呼する場合がある。多くの場合、他のアカウントは、問題を解決するために予期せず着呼する場合があり、これには、エージェントがこれらの呼に予期せず対応する必要がある。結果として、エージェントの事前に設定されているスケジュールが計画的でなくなるおそれがあり、リソースが効率的に利用されなくなるおそれがある。
【００１１】
呼収益およびエージェントの生産性を増大させるための方法およびシステムが説明される。少なくとも１つの実施形態において、方法およびシステムは、コンタクトまたはコールセンターに適用されてもよい。コンタクトに届くのに最良の時間を正確に予想することによって、間違った相手にメッセージを残すのとは対照的に、正しい相手とのコンタクトを行うことができる。間違った相手の一例は、コンタクト目標ではない個人、または、留守番電話に対する呼であり得る。呼の結果を追跡するためにコードが採用され得る。そのようなコードの例は、成功、正しい相手、間違った相手、留守番電話、回線使用中、応答なし、エージェントによる他の対応、または機械による他の対応を含んでもよい。結果コードは、ラップコード、または、呼の間に起こったことの分類を指定する文字列から要約されてもよい。加えて、データを分類および収集する手段としてディメンション値がシステム内で使用されてもよい。ディメンションは、予想が作成される属性であり得る。ディメンションは、自動、人口学的、時間記述的などであってもよい。
【００１２】
自動ディメンションは、システムが呼に対応し通常通り処理するときに呼から抽出され得る。自動ディメンションは、限定ではないが、以下の例、すなわち、呼の結果、使用されている電話のタイプ、呼の長さ、エージェントが応答する前にコンタクトが保留にされた時間、呼がエスカレートしたか否か、およびそうである場合、どの程度呼がエスカレートしたか、電話のタイムゾーンオフセット、および、電話のタイムゾーン名を含んでもよい。電話のタイプは、携帯電話、固定電話、家庭用電話、勤務先電話、主要電話番号などを含んでもよい。電話のタイムゾーンオフセットはまた、ＵＴＣ（「協定世界時」）から東向きを正とした分に基づいて計算され得る。
【００１３】
時間ディメンションは、呼から、呼が開始またはダイヤルされた時間を考慮して抽出され得る。時間ディメンションは、限定ではないが、以下の情報、すなわち、呼の１５分間隔でとられた時刻、曜日、月、年などを含んでもよい。
【００１４】
人口学的ディメンションは、リストデータベース表内の特定のフィールドまたは列内の特定の値から抽出されてもよい。人口学的ディメンションは、ユーザによって定義されてもよく、またはこの情報は提供されてもよい。人口学的情報はまた、条件付きで定義されてもよい。たとえば、カナダ郵便番号は、フィールドが「ＡＮＡ  ＮＡＮ」、ＡおよびＮはアルファベット文字および数字を表す、の形態にある場合にのみ条件付きで定義され得る。ユーザによって定義され得るディメンションの例は、州／省、主要電話加入区域コード、社会的性別（ｇｅｎｄｅｒ）、婚姻区分、未払残高、カナダ郵便番号、英国郵便番号、米国郵便番号、年齢、信用度、収入、職業、在留資格などを含んでもよい。「ディメンション」という語は、人口統計学データを指定するのに使用されてもよいが、代替的に「属性」と称される場合がある。「生物学的性別（ｓｅｘ）」および「社会的性別（ｇｅｎｄｅｒ）」のように、複数の異なるコンタクトリストからの異なった名称の列が同じディメンションに置かれてもよい。この例において、「１」、「２」、および「３」の範囲が使用されてもよく、社会的性別に対する値として、Ｍが１と等価であり、Ｆが２と等価であり、Ｕが３と等価である。「Ｍ」、「Ｆ」、および「Ｕ」の値は「生物学的性別」に使用されてもよく、Ｍは男性であり、Ｆは女性であり、Ｕは不明である。生物学的性別および社会的性別は同じディメンションと解釈されてもよいが、それらは異なるマッピング規則を有し得る。ディメンション値は、コンタクトからのデータをいくつかのグループにおくのに使用され得る。そのような各グループはまた、多くのコンタクトからのデータをも有し得る。成功の確率を判定するために、および、成功、対応時間、および収益の予想を補助するために、類似のコンタクトからのデータがグループ化され得る。システムは、指定期間における各グループに対する試行の回数を更新することによって、収集されるデータから学習する。代替的に、システムは、各コード、各グループ、各期間などについて完了した呼の数を更新してもよい。
【００１５】
図１に示すように、全体的に１００において示されているシステムの一実施形態が提供される。システム１００は、ネットワーク経路を介していくつかのコンピュータ１１０をともに結合するコンピュータネットワーク１１５を含んでもよい。より詳細には、システム１００は、いくつかのサーバ、すなわち、アウトバウンドダイヤラサーバ１２５、キャンペーンサーバ１３０、および戦略選択サーバ１３５を含んでもよい。システム１００はまた、複数のエージェントワークステーション１０５をも含んでもよい。１つのみのコンピュータ１１０が示されているが、代替的な実施形態においてはより多くのコンピュータが利用されてもよい。
【００１６】
エージェントワークステーション１０５は、ディスプレイ１０２に結合されているワークステーションコンピュータ１０３を含んでもよい。ワークステーションコンピュータ１０３は、同じタイプであってもよく、または、異なるコンピューティングデバイスの異種同士の組み合わせであってもよい。同様に、ディスプレイ１０２も、同じタイプであってもよく、または、異なる視覚デバイスの異種同士の組み合わせであってもよい。例示的な実施形態において１つのワークステーション１０５が記載されているが、より多くのワークステーションが利用されてもよいことが理解されるべきである。システム１００のコンタクトセンターアプリケーションは一般的に、１つまたは複数の物理的位置においてこのタイプのより多くのワークステーションを含むが、明瞭性を維持するために図１においては１つのみが示されている。
【００１７】
デジタル電話機１０１がエージェントワークステーション１０５と関連付けられ得る。加えて、デジタル電話機１０１は、エージェントコンピュータ１０３に統合されてもよく、かつ／または、ソフトウェアにおいて実装されてもよい。ネットワーク１００に直接接続されることが可能であるデジタル電話機１０１は、ハンドセット、ヘッドセット、または当業者に想起されるような他の構成の形態にあってもよいことが理解されるべきである。コンピュータネットワーク１１５からエージェントワークステーション１０５への接続が、最初に関連付けられるワークステーション電話機へ、その後、ワークステーション電話機から、ワークステーション電話機に対する接続を通る経路によってワークステーションコンピュータへと行われることができることがさらに理解されるべきである。代替的に、ネットワークから、一方はワークステーション電話機への、もう一方はワークステーションコンピュータへの２つの接続が行われてもよい。明瞭性を維持するために図示されていないが、エージェントワークステーション１０５はまた、代表的な数例のみ挙げると、キーボード、マウス、トラックボール、ライトペン、および／または１つまたは複数のマイクロ遠隔通信器のような、１つまたは複数のオペレータ入力デバイスをも含んでもよい。加えて、ディスプレイ１０２に加えて、スピーカ（複数の場合もあり）および／またはプリンタのような１つまたは複数の出力デバイスが含まれてもよい。
【００１８】
コンピュータネットワーク１１５は、ローカルエリアネットワーク（ＬＡＮ）、都市域ネットワーク（ＭＡＮ）、インターネットのような広域ネットワーク（ＷＡＮ）、これらの組み合わせ、または当業者に想起されるようなそのような他のネットワーク構成の形態とすることができる。システム１００の動作論理は、ネットワーク１１５にわたって送信される信号、プログラミング命令、専用ハードウェア、またはこれらの組み合わせにおいて具現化することができる。任意の数のコンピュータ１１０を、コンピュータネットワーク１１５によってともに結合することができることが理解されるべきである。
【００１９】
エージェントワークステーション１０５は、Ｉｎｔｅｒａｃｔｉｖｅ  Ｉｎｔｅｌｌｉｇｅｎｃｅ社のＩｎｔｅｒａｃｔｉｏｎ  Ｃｌｉｅｎｔ（登録商標）」のような、エージェントアクセスアプリケーションを介してコンピュータネットワーク１１５を通じてアウトバウンドダイヤラサーバ１２５と接続されてもよい。任意の数のエージェントが利用されてもよい。エージェントの数はシステムの有効性に正比例し得、したがって、エージェントの数が多くなるほど、理想的には、結果としてシステムはより有効なものになり得る。アウトバウンドダイヤラサーバ１２５は、エージェントワークステーション１０５、コンタクト１２０、およびキャンペーンサーバ１３０との間で通信を行うことができる。コンタクト１２０は、エージェントによって目標とされる、コールセンターにおけるもののような、エンドパーティであってもよい。アウトバウンドダイヤラサーバ１２５は、コンタクト番号へのダイヤルおよび呼全体を通じた接続の維持に関係する活動を管理することができる。情報は、アウトバウンドダイヤラサーバ１２５とキャンペーンサーバ１３０との間で共有され得る。キャンペーンサーバ１３０は、構成を記憶するサーバであってもよく、当該サーバを通じて、コンタクトリストまたは呼リストを含み得る呼リストデータベース１４０がアクセスされる。
【００２０】
キャンペーンサーバ１３０はまた、戦略選択サーバ１３５とも通信することができる。戦略選択サーバ１３５は、いずれのアカウントに次回発呼すべきかを判定するために、アカウントの評価を実行することができる。戦略選択サーバ１３５は呼選択データベース１４５と接続されてもよい。呼選択データベース１４５は、戦略選択サーバが呼リストの中でいずれのコンタクトを選出すべきかを判定するのに必要な情報を含み得る。呼選択データベース１４５内に、システム１００が、いずれのアカウントまたは電話番号に発呼すべきか、および、後述するように、最も有効な結果が達成される可能性が高いのはいつかを判定することを可能にするデータが収容され得る。この情報は、その日が週末または平日に入るか否か、その日が存在するのが一年のうちのいずれの週か、などのような、曜日の評価を含んでもよい。特別な日および休日も、評価に含まれてもよい。
【００２１】
一実施形態において、キャンペーンサーバ１３０および戦略選択サーバ１３５は、本事例においては別個に提示されているが、同じ機械に収容されてもよい。一実施形態において、呼リストデータベース１４０および呼選択データベース１４５は、本事例においては別個に提示されているが、同じ機械に収容されてもよい。
【００２２】
図２に示されているように、呼選択のための予想を求めるためのプロセス２００の一実施形態が提供される。プロセス２００は、システム１００（図１）において機能し得る。プロセス２００は、予想を求めるために複数回反復されてもよい。
【００２３】
動作２０５において、データベースからのコンタクト情報が要求され得る。たとえば、呼選択データベース１４５からの、発呼するためのコンタクトアカウントまたは電話番号が、アウトバウンドダイヤラ１２５（図１）のような自動ダイヤル機能によって要求され得る。呼選択データベース１４５がコンタクト情報を提供する。制御は動作２１０に移り、プロセス２００は継続する。
【００２４】
動作２１０において、システムはデータベースによって提供されるリスト内のディメンション値を解析する。たとえば、システムは、生成されたコンタクトレコードに基づいて一連の計算を実行する。コンタクトをとるためのアカウントが検査され得る。これらのアカウントについて、関連するディメンションおよびこれらのディメンションの現在の値が抽出される。各ディメンション値は２つ以上のコンタクトに適用されてもよい。たとえば、グループ分けが、各々が４５歳女性である５つのコンタクトを含んでもよい。したがって、これら５つのコンタクトは、年齢（４５歳）および社会的性別（女性）について同様のディメンション値を有する。すでに述べたように、ディメンションデータは、自動ディメンションデータ、時間ディメンションデータ、および人口学的ディメンションデータであってもよい。制御は動作２２０に移り、プロセス２００は継続する。
【００２５】
動作２１５において、関連する呼レコードが生成される。たとえば、所望されるディメンション値を有する呼レコードが提示される。制御は動作２２５に移り、プロセス２００は継続する。
【００２６】
動作２２０において、システムは一連の計算を実行する。そのような計算は、結果コードの確率、呼の予測対応時間値、および呼収益値を含んでもよい。たとえば、各ディメンション値について、その値が所望の結果コードを得る可能性を求めて履歴レコードが検索される。そのような結果コードは、呼の間に起こったことの分類を指定する文字列を含むラップコードを考慮することによって求められてもよい。確率をもたらすために、数学的に適切な様式で、各結果値（すなわち、成功の数または試行の数）の確率がプールされる。結果値は、成功、正しい相手、間違った相手、回線使用中、留守番電話、応答なし、エージェントによる他の対応、または機械による他の対応を含んでもよい。各ディメンション値の確率は２つ以上のコンタクトに適用されてもよい。上記の例を使用して、グループ分けが、各々が４５歳女性である５つのコンタクトを含んでもよい。したがって、これら５つのコンタクトは、年齢（４５歳）および社会的性別（女性）について同様のディメンション値を有する。したがって、推定確率、予測対応時間値、および／または呼収益値は、各個々のコンタクトについてではなくディメンション値について一度だけ計算されればよい。
【００２７】
呼の予測対応時間は、寄与する呼事象の対応時間の加重平均であってもよい。加重平均は、確率を計算するために利用された同じ適切な方法によって、各ディメンション値の予測確率によって、また、ディメンションにわたって重み付けされてもよい。呼収益は、通話呼秒数ではなく、ドル売上高、ドル回収高、または想定受動者のような目標に対する基底効果を含んでもよい。制御は動作２３０に移り、プロセス２００は継続する。
【００２８】
動作２２５において、各ディメンションについて計算された結果コード確率が、数学的に適切な様式でシステムによって加算される。たとえば、所望の結果コードにわたって各所望の結果コードについての値がプールされてもよい。単純な方法によって小さい分母群がプールされてもよく、一方で、予測逆分散数重みを使用することによって大きいプールが組み合わされ得る。制御は動作２０５に戻り、プロセス２００は継続する。
【００２９】
予想によって、エージェントが、所望の結果をもたらすために発呼するための最良の時間を求める計算に基づいて呼を行うことを可能にする。最高の収益生産性を有するコンタクトが選択される。たとえば、最高の収益生産性は、コンタクトの確率を有するコンタクトを所与として予測収益を乗算し、この結果を予測対応時間で除算することによって求めることができる。コンタクトをとるための収益生産性の最高の総和を有するコンタクトのセットが選択され得る。最高の収益生産性を有するコンタクトがコンタクトをとられてもよい。結果はダイヤラに提供され得、ダイヤラは発呼されるべきアカウントをエージェントに送る。計算におけるディメンション値は、休日のような、コンタクトの挙動が任意の他の日とは異なる日を考慮にいれることができる。そのため、コンタクトの挙動が変化する任意のそのような日には特別措置が適用され得る。
【００３０】
別の実施形態において、動作２２０は、上記ディメンション値に対する各結果コードについての呼収益値および確率を計算することのみを含んでもよい。その後、結果コードのセットについての確率および予測呼収益の予想が求められてもよい。最高の収益を有するコンタクトは、コンタクトの最高の収益を有するコンタクトを所与として予測収益を乗算し、この結果を予測対応時間で除算することによってコンタクトをとるように選択されてもよい。
【００３１】
いくつかのレコードが予想を補助するために存在し得る。図３は、サンプルディメンション定義レコード表を示す。ディメンション定義レコード表３０２（図３）は、いくつかのディメンション定義レコード３００から構成され得る。少数のレコード３００ａ、３００ｂ、３００ｃ、および３００ｄのみが図３に示されているが、任意の数のレコード３００が与えられてもよい。ディメンション定義レコード３００は、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース内に存在し得る。ディメンション定義レコード３００（図３）は、ディメンション識別子（Ｄｉｍｅｎｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド３０５と、カテゴリタイプ（Ｃａｔｅｇｏｒｙ  Ｔｙｐｅ）フィールド３１０と、データタイプ（Ｄａｔａ  Ｔｙｐｅ）フィールド３１５と、新値タイプ（Ｎｅｗ  Ｖａｌｕｅ  Ｔｙｐｅ）フィールド３２０と、徐変フラグ（Ｓｌｏｗｌｙ  Ｃｈａｎｇｉｎｇ  Ｆｌａｇ）フィールド３２５と、ディメンション名（Ｄｉｍｅｎｓｉｏｎ  Ｎａｍｅ）フィールド３３０とを含んでもよい。ディメンション識別子フィールド３０５は、ディメンションの識別子を含み得、識別子は必ず一意であり、一貫して使用されることが好ましい。たとえば、ディメンション識別子は、ランダムに生成される英数字コードまたは文字列であってもよい。ディメンション識別子は、各アカウントに関連して使用される識別子を示すことができる。本明細書において特定の例のディメンション識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図３に示されている例を使用して、「４２２」は、ディメンション定義レコード３００ａと関連付けられるディメンション識別子である。ディメンション識別子「４２３」は、レコード３００ｂと関連付けられる。ディメンション識別子「４２４」は、レコード３００ｃと関連付けられる。ディメンション識別子「４２５」は、レコード３００ｄと関連付けられる。
【００３２】
各ディメンション定義レコードは、提示される情報が所与の範囲からのものであり得るか、またはある値であり得ることを示し得るカテゴリタイプフィールド３１０を割り当てられ得る。たとえば、ディメンション定義レコード３００ａは、カテゴリタイプが「範囲（Ｒａｎｇｅ）」であることを示す。これは、レコード３００ａに関して、情報が範囲として提示されることを意味し得る。ディメンション定義レコード３００ｂ、３００ｃ、および３００ｄはすべて、「値（Ｖａｌｕｅ）」のカテゴリタイプ３１０を示す。これは、レコード３００ｂ、３００ｃ、および３００ｄに関して、情報がある値として提示されることを示し得る。
【００３３】
データタイプフィールド３１５は、そのレコードにおいてデータがどのように提示されるかを示し得る。データは、整数または文字列として提示され得る。たとえば、ディメンション定義レコード３００ａは、データタイプ３１５が「整数（Ｉｎｔｅｇｅｒ）」であることを示す。したがって、データは、文字列データとは対照的に整数として提示される。ディメンション定義レコード３００ｂ、３００ｃ、３００ｄはすべて「文字列（Ｓｔｒｉｎｇ）」のデータタイプ３１５を提示し、これは、情報が文字列データとして提示されることを示す。
【００３４】
新値タイプフィールド３２０は、値がデータベース内に存在するかまたはデータベースにない場合に、フィールドが作成される必要があるか否かを示し得る。データが存在しない場合、データがシステムによって自動的に作成され得る。指定されているもの以外のデータが存在する場合、システムはこれをデータエラーとして認識し、このデータを無視し得る。たとえば、ディメンション定義レコード３００ａ、３００ｃ、および３００ｄは各々、新値タイプ３２０が「自動作成（ＡｕｔｏＣｒｅａｔｅ）」であることを示す。したがって、システムはデータを作成することになる。ディメンション定義レコード３００ｂは、「無視（Ｉｇｎｏｒｅ）」の新値タイプ３２０を示し、したがって、システムは、この情報を無視すべきである認識する。
【００３５】
徐変フラグフィールド３２５は、何らかの期間にわたってゆっくりと変化し得る意味を有する情報を示し得る。ゆっくりと変化するデータの一例は、米国ドル表示の商品の価格であってもよく、これは、その実際の値がインフレーションに起因して経時的に変化し得る。フラグは、それがない場合にシステムがそうし得るよりも頻繁にデータをパージするために、この情報におかれ得る。たとえば、ディメンション定義レコード３００ａ、３００ｂ、３００ｃ、および３００ｄは、徐変フラグフィールド３２５が「いいえ（Ｎｏ）」であることを示す。したがって、情報が変化しており、システムが通常通りデータをパージすることを示すために、ディメンション定義レコード３００ａ、３００ｂ、３００ｃ、および３００ｄ内のデータにフラグはおかれない。
【００３６】
ディメンション名フィールド３３０は、そのレコード内のディメンションに与えられる名前を示し得る。ディメンション名は、システムが対応するときに呼から抽出され得る人口学的情報または自動ディメンションデータのような、レコード内に含まれる情報のタイプを示し得る。たとえば、ディメンション定義レコード３００ａは、ディメンション名３３０が「年齢（Ａｇｅ）」であることを示す。ディメンション定義レコード３００ｂは、ディメンション名３３０が「社会的性別（Ｇｅｎｄｅｒ）」であることを示す。ディメンション定義レコード３００ｃは、ディメンション名３３０が「米国郵便番号（ＵＳＰＳ  ＺＩＰ  Ｃｏｄｅ）」であることを示す。ディメンション定義レコード３００ｄは、ディメンション名３３０が「カナダ郵便番号（Ｃａｎａｄａ  Ｐｏｓｔ  Ｃｏｄｅ）」であることを示す。
【００３７】
図４は、サンプルディメンション−コンタクトリスト相互参照レコード表を示す。ディメンション−コンタクトリスト相互参照レコード表４０２（図４）は、いくつかのディメンション−コンタクトリスト相互参照レコード４００から構成され得る。少数のレコード４００ａ、４００ｂ、４００ｃ、および４００ｄのみが図４に示されているが、任意の数のレコード４００が与えられてもよい。ディメンション−コンタクトリスト相互参照レコード４００は、呼選択データベース１４５（図１）または呼リストデータベース１４０と関連付けられ得るか、または呼選択データベース内に存在し得る。ディメンション−コンタクトリスト相互参照レコードは、リスト識別子（Ｌｉｓｔ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド４０５（図４）と、ディメンション識別子（Ｄｉｍｅｎｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド４１０と、列名（Ｃｏｌｕｍｎ  Ｎａｍｅ）フィールド４１５と、トリム規則（Ｔｒｉｍ  Ｒｕｌｅ）フィールド４２０と、変換規則（Ｔｒａｎｓｆｏｒｍ  Ｒｕｌｅ）フィールド４２５と、ゲート規則（Ｇａｔｅ  Ｒｕｌｅ）フィールド４３０と、アクティブ収集フラグ（Ａｃｔｉｖｅ  Ｃｏｌｌｅｃｔｉｏｎ  Ｆｌａｇ）フィールド４３５と、アクティブ使用フラグ（Ａｃｔｉｖｅ  Ｕｓｅ  Ｆｌａｇ）フィールド４４０とを含んでもよい。リスト識別子フィールド４０５は、同じフォーマットであるが物理的に異なるまたは類似の情報を有するリストのグループの識別子を含み得る。リスト識別子は、ユーザによって設定される識別の手段であり得る。本明細書において特定の例のリスト識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図４に示されている例を使用して、「７２２」は、ディメンション−コンタクトリスト相互参照レコード４００ａ、４００ｂ、４００ｃ、および４００ｄと関連付けられるリスト識別子４０５である。これは、これらのレコードがリスト識別子フィールド４０５において各々同じ値を有するため、すべて同じリストの部分であることを示し得る。
【００３８】
ディメンション識別子フィールド４１０は、ディメンションの識別子を含み得、識別子は必ず一意であり、一貫して使用されることが好ましい。たとえば、ディメンション識別子は、ランダムに生成される英数字コードおよび／または文字列であってもよい。ディメンション識別子は、各アカウントに関連して使用される識別子を示すことができる。本明細書において特定の例のディメンション識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図４に与えられている例を使用して、「４２２」はディメンション−コンタクトリスト相互参照レコード４００ａと関連付けられるディメンション識別子４１０であり、「４２３」はディメンション−コンタクトリスト相互参照レコード４００ｂと関連付けられ、「４００ｃ」はディメンション−コンタクトリスト相互参照レコード４００ｃと関連付けられ、「４２５」はディメンション−コンタクトリスト相互参照レコード４００ｄと関連付けられる。
【００３９】
列名フィールド４１５は、検査されている特定のリスト内の列の名前を示し得る。図４において、たとえば、列名フィールド４１５は、ディメンション−コンタクトリスト相互参照レコード４００ａにおいて、リスト７２２内で誕生日（Ｄａｔｅ  ｏｆ  Ｂｉｒｔｈ）列が検査されていることを示す。レコード４００ｂにおいては、リスト７２２内で生物学的性別（Ｓｅｘ）列が検査されており、レコード４００ｃおよび４００ｄにおいては、郵便番号（ＺＩＰ）列が検査されている。
【００４０】
トリム規則フィールド４２０は、情報の所望のフォーマット、および、システムがどのように情報を編集し得るかを示し得る。トリム規則は、ユーザによって指定されてもよい。図４に与えられている例を使用して、トリム規則フィールド４２０は、レコード４００ａについて、情報が誕生「日（Ｄａｔｅ）」であり、日付フォーマットにあり得ることを示す。トリム規則フィールド４２０においてこの指定に適合しない任意の情報は、システムによって編集削除されることになる。レコード４００ｂについて、トリム規則フィールド４２０は「１文字（Ｏｎｅ  Ｃｈａｒａｃｔｅｒ）」を示す。この文字を超える任意の情報は編集削除されることになる。同様に、トリム規則フィールド４２０は、レコード４００ｃおよび４００ｄについて、情報が「非ホワイトスペース（Ｎｏｎ  Ｗｈｉｔｅｓｐａｃｅ）」であることを示す。データフィールドに存在する任意のホワイトスペースは、したがって、システムによって廃棄されることになる。
【００４１】
変換規則フィールド４２５は、その情報がディメンションにおける提示のためにどのように変換されるかを示し得る。図４に与えられている例を使用して、変換規則フィールド４２５は、レコード４００ａについて、「現在からさかのぼる年数（Ｙｅａｒｓ  Ｂｅｆｏｒｅ  Ｎｏｗ）」を変換規則として示す。システムは、データを、誕生日列における情報を示す数に、現在の日付より前の年数として変換するように認識し得る。レコード４００ｂは、「標準的な生物学的性別（Ｓｔａｎｄａｒｄ  Ｓｅｘ）」を変換規則として示す。システムは、データを、個人の生物学的性別を示す文字に変換するように認識し得る。レコード４００ｃは、規則が「最初の５字（Ｆｉｒｓｔ  Ｆｉｖｅ）」であることを示し、これは、情報が最初の５文字に含まれていることを意味する。レコード４００ｄは、規則が「最初の６字（Ｆｉｒｓｔ  Ｓｉｘ）」であることを示し、これは、情報が最初の６文字に含まれていることを意味する。
【００４２】
ゲート規則フィールド４３０は、所望の基準を満たさない情報をシステムによってさらにフィルタリング除外する規則を含み得る。たとえば、ゲート規則フィールド４３０は、レコード４００ａについて、情報が「１０〜１００（１０−１００）」であることを示し、これは、所望の情報が値１０〜１００に入ることを意味する。レコード４００ｂは、ゲート規則４３０が「Ｆ」、「Ｍ」、「Ｕ」であることを示す。これは、所望の内容が「標準的な生物学的性別」を表す「１文字」であるだけでなく、内容が「Ｆ」、「Ｍ」、または「Ｕ」のいずれかでなければならないことを示し得る。レコード４００ｃは、「全数字（Ａｌｌ  ｎｕｍｅｒｉｃ）」であるゲート規則を有し、これは、情報が変換規則フィールド４２５に従って最初の５文字に含まれるだけでなく、情報がすべて数字でもあることを意味する。レコード４００ｄは、「ＡΝΑΝΑΝ」ゲート規則４３０を有する。これは、「最初の６」文字が英数字であり、文字と数字とが交互になっていることを意味し得る。
【００４３】
アクティブ収集フラグフィールド４３５は、ユーザに関してデータが収集されるべきか否かを示し得る。この列内の情報は、「はい（Ｙｅｓ）」または「いいえ（Ｎｏ）」フォーマットにあり得る。図４に与えられている例を使用して、アクティブ収集フラグフィールド４３５は、レコード４００ａ、４００ｂ、４００ｃ、および４００ｄについて「はい」の値を有し、これは、このフィールドに従ってユーザに関してデータが収集されることになることを示す。
【００４４】
アクティブ使用フラグフィールド４４０は、収集されたデータが予想に使用されるべきか否かを示し得る。アクティブ使用フラグフィールド４４０は、ユーザによって変更することができるデフォルトのプリセットを有し得る。たとえば、本システムにおいて、デフォルトは「はい」に設定される。アクティブ使用フラグフィールド４４０は、レコード４００ａ、４００ｂ、４００ｃ、および４００ｄについて「はい」の値を有し、これは、データが予想目的に使用されることになることを示す。
【００４５】
図５は、サンプルディメンション値レコード表を示す。ディメンション値レコード表５０２（図５）は、いくつかのディメンション値レコード５００から構成され得る。少数のレコード５００ａ、５００ｂ、および５００ｃのみが図５に示されているが、任意の数のレコード５００が生成されてもよい。ディメンション値レコード５００は、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース１４５内に存在し得る。ディメンション値レコード５００（図５）は、ディメンション識別子（Ｄｉｍｅｎｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド５０５と、日識別子（Ｄａｙ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド５１０と、値識別子（Ｖａｌｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド５１５と、期間識別子（Ｐｅｒｉｏｄ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド５２０と、データ年（Ｄａｔａ  Ｙｅａｒ）フィールド５２５と、保持識別子（Ｒｅｔｅｎｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド５３０と、成功（Ｓｕｃｃｅｓｓ）フィールド５３５と、正しい相手（Ｒｉｇｈｔ  Ｐａｒｔｙ）フィールド５４０と、間違った相手（Ｗｒｏｎｇ  Ｐａｒｔｙ）フィールド５４５と、留守番電話（Ａｎｓｗｅｒｉｎｇ  Ｍａｃｈｉｎｅ）フィールド５５０と、応答なし（Ｎｏ  Ａｎｓｗｅｒ）フィールド５５５と、回線使用中（Ｂｕｓｙ）フィールド５６０と、他エージェント（Ｏｔｈｅｒ  Ａｇｅｎｔ）フィールド５６５と、他機械（Ｏｔｈｅｒ  Ｍａｃｈｉｎｅ）フィールド５７０とを含んでもよい。
【００４６】
ディメンション識別子フィールド５０５は、ディメンションの識別子を含み得、識別子は必ず一意であり、一貫して使用されることが好ましい。たとえば、ディメンション識別子は、ランダムに生成される英数字コードおよび／または文字列であってもよい。ディメンション識別子は、各アカウントに関連して使用される識別子を示すことができる。本明細書において特定の例のディメンション識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図５に与えられている例を使用して、「４２２」は、ディメンション定義レコード５００ａおよび５００ｂと関連付けられるディメンション識別子である。ディメンション識別子「４２３」は、ディメンション値レコード５００ｃと関連付けられる。
【００４７】
日識別子フィールド５１０は、時間サイクルに対するその関係に関する日を識別し得る。このフィールドは、年間通算日、曜日、月などを示すように詳述されてもよい。図５に与えられている例を使用して、「２３４」は、レコード５００ａ、５００ｂ、および５００ｃについての日識別子である。
【００４８】
値識別子フィールド５１５は、システムがそれに関してデータを収集している値を識別し得る。たとえば、レコード５００ａは「７」の値識別子を示し、レコード５００ｂは「８」の値識別子を示し、レコード５００ｃは「１」の値識別子を示す。
【００４９】
期間識別子フィールド５２０は、日単位の期間を示し得る。この情報は、１５分刻みの日間通算の分数として指定され得る。たとえば、ディメンション値レコード５００ａ、５００ｂ、および５００ｃは各々、期間識別子フィールド５２０において「４８０」の値を示す。値「４８０」は、コンタクトの時間帯における午前８：００〜午前８：１５に変換され得る。
【００５０】
データ年フィールド５２５は、データが収集された年を示し得る。このフィールドは、ユーザが一定の閾値を過ぎてデータを保持することを望まない場合に、システムがデータをリタイアさせるときより古いデータを識別するのにも使用され得る。たとえば、レコード５００ａ、５００ｂ、および５００ｃについて、データ年フィールド５２５内に存在する値は「２０１２」である。これは、データが２０１２年に収集されたことを示し得る。
【００５１】
保持識別子フィールド５３０は、データが一度にパージされるのではなく、徐々にリタイアされ得るように、情報を一年の中でともに集約し得る。たとえば、レコード５００ａ、５００ｂ、および５００ｃの各々について、保持識別子フィールド５３０内に存在する値は「２５」である。これは、第２５のサイクルがこの行を救済することになることを意味し得る。サイクルが２週おきに発生する場合、第２５のサイクルは、暦年において１２月の終わり付近に発生することになる。
【００５２】
成功フィールド５３５は、エージェントによって達成された成功した呼の数を示し得る。成功した呼は、エージェントが所望の結果を達成し、もはや目下のところアカウントに発呼し続ける必要がない呼であり得る。図５に示されている例を使用して、レコード５００ａは成功フィールド５３５内に「２１」の値を示し、レコード５００ｂは成功フィールド５３５内に「３１」の値を示し、レコード５００ｃは成功フィールド５３５内に「２７」の値を示す。
【００５３】
正しい相手フィールド５４０は、電話呼の間に正しい相手につながったが、成功は達成されなかったことを開示する情報を示し得る。たとえば、レコード５００ａは、「２２」の値を示す。これは、正しい相手に届いたが、成功は達成されなかった２２回の呼が行われたことを示し得る。レコード５００ｂは「２９」回の正しい相手の結果を示し、レコード５００ｃは「１７」を示す。
【００５４】
間違った相手フィールド５４５は、エージェントによって所望の相手に届かなかった呼の数を開示する情報を含み得る。たとえば、呼が別の相手によってとられたときには、所望の相手が存在しない場合がある。このシナリオにおいて、呼は間違った相手によってとられた。図５に示されている例を使用して、レコード５００ａは、間違った相手フィールド５４５内に「１６」の値を示す。これは、１６回の呼が間違った相手によってとられたことを示す。レコード５００ｂは「１２」の値を示し、一方でレコード５００ｃは「２３」の値を示す。
【００５５】
留守番電話フィールド５５０は、相手に届いたのではなく、留守番電話サービスが呼をとった呼の数を開示する情報を含み得る。図５の例を使用して、レコード５００ａは、値「５６」を表示する。これは、５６回の呼が、相手ではなく留守番電話が呼をとることによって終わったことを示し得る。レコード５００ｂは「４５」値を示し、レコード５００ｃは「３９」の値を示す。
【００５６】
応答なしフィールド５５５は、呼の間に応答が届かなかった呼の数を開示する情報を含み得る。図５の例を使用して、レコード５００ａは、値「２４」を表示する。これは、２４回の呼が、人間または留守番電話のいずれによっても応答されなかったことを示し得る。レコード５００ｂは「２８」の値を表示し、レコード５００ｃは「２２」の値を表示する。
【００５７】
回線使用中フィールド５６０は、回線が使用中または他の様態で占有されており、エージェントが通すことができなかった呼の数を開示する情報を含み得る。図５の例を使用して、レコード５００ａは、値「９」を表示する。これは、９回の呼が回線使用中のために通らなかったことを示し得る。レコード５００ｂは「２３」値を表示し、レコード５００ｃは「１７」の値を表示する。
【００５８】
他エージェントフィールド５６５は、エージェントが呼に時間を費やさなければならなかった呼の数を開示する情報を含み得る。たとえば、ＰＢＸはシステムによって認識されない話中信号を与えることがあり、エージェントは自身で呼を終わらせなければならない。図５の例を使用して、レコード５００ａは、値「２」を表示する。これは、エージェントが仲裁しなければならなかった呼が２回行われたことを示し得る。レコード５００ｂは「１」の値を表示し、レコード５００ｃは「０」の値を表示する。
【００５９】
他機械フィールド５７０は、呼の間に中断に至った呼の数を開示する情報を含み得る。トライトーンが発生している場合もあり、または、サーバとの通信に断絶があった。図５の例を使用して、レコード５００ａは、値「９」を表示する。これは、９回の呼が、機械の問題によって応答されなかったことを示し得る。レコード５００ｂは「１３」の値を表示し、レコード５００ｃは「１２」の値を表示する。
【００６０】
図６は、サンプルディメンション値スーパーキーレコード表を示す。ディメンション値スーパーキー表６０２（図６）は、いくつかのディメンション値スーパーキーレコード６００から構成され得る。少数のレコード６００ａ、６００ｂ、および６００ｃのみが図６に示されているが、任意の数のレコード６００が生成されてもよい。ディメンション値スーパーキーレコードは、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース内に存在し得る。ディメンション値スーパーキーレコード６００（図６）は、ディメンション識別子フィールド６０５と、値識別子フィールド６１０と、カテゴリタイプフィールド６１５と、データタイプフィールド６２０とを含んでもよい。
【００６１】
ディメンション識別子フィールド６０５は、ディメンションの識別子を含み得、識別子は必ず一意であり、一貫して使用されることが好ましい。たとえば、ディメンション識別子は、ランダムに生成される英数字コードおよび／または文字列であってもよい。ディメンション識別子は、各アカウントに関連して使用される識別子を示すことができる。本明細書において特定の例のディメンション識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図６に示されている例を使用して、「４２２」は、ディメンション定義レコード６００ａおよび６００ｂと関連付けられるディメンション識別子である。ディメンション識別子「４２３」は、ディメンション定義レコード６００ｃと関連付けられる。
【００６２】
値識別子フィールド６１０は、システムがそれに関してデータを収集している値を識別し得る。たとえば、レコード６００ａは「７」の値識別子を示し、レコード６００ｂは「８」の値識別子を示し、レコード６００ｃは「１」の値識別子を示す。
【００６３】
カテゴリタイプフィールド６１５は、与えられるべき情報が範囲または値であるかを示し得る。図６に示されている例を使用して、カテゴリタイプフィールド６１５は、レコード６００ａおよび６００ｂについて、与えられるデータが「範囲」であることを示す。カテゴリタイプフィールド６１５は、レコード６００ｃについて、与えられるデータが「値」であることを示す。
【００６４】
データタイプフィールド６２０は、与えられる情報が整数またはデータ文字列であるかを示し得る。図６に示されている例を使用して、カテゴリタイプフィールド６１５は、レコード６００ａおよび６００ｂについて、与えられるデータが「整数」であることを示す。カテゴリタイプフィールド６１５は、レコード６００ｃについて、与えられるデータが「文字列」であることを示す。
【００６５】
図７は、サンプルディメンション文字列値レコード表を示す。ディメンション文字列値レコード表７０２（図７）は、いくつかのディメンション文字列値レコード７００から構成され得る。１つのレコードのみが図７に示されているが、任意の数のレコード７００が生成されてもよい。ディメンション文字列値レコード７００は、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース１４５内に存在し得る。ディメンション文字列値レコード７００（図７）は、ディメンション識別子フィールド７０５と、値識別子フィールド７１０と、値フィールド７１５とを含んでもよい。
【００６６】
ディメンション識別子フィールド７０５は、ディメンションの識別子を含み得、識別子は必ず一意であり、一貫して使用されることが好ましい。たとえば、ディメンション識別子は、ランダムに生成される英数字コードおよび／または文字列であってもよい。ディメンション識別子は、各アカウントに関連して使用される識別子を示すことができる。本明細書において特定の例のディメンション識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図７に示されている例を使用して、「４２３」は、ディメンション定義レコード５００ｃと関連付けられるディメンション識別子である。
【００６７】
値識別子フィールド７１０は、システムがそれに関してデータを収集している値を識別し得る。たとえば、レコード７００は、「１」の値識別子を示す。
【００６８】
値フィールド７１５は、ディメンション識別子フィールド７０５および値識別子フィールド７１０に基づいて収集される情報の値を示し得る。たとえば、女性を表すＦ、男性を表すＭの値、または、不明を表すＵの値が、表に示され得る。値識別子は、値識別子フィールド７１０に示されているようにＦに対して１、Ｍに対して２、およびＵに対して３のように、値に対して割り当てられる。図示されている例を使用して、値フィールド７１５は、レコード７００において「Ｆ」の値を示す。
【００６９】
図８は、サンプルディメンション整数バンドレコード表を示す。ディメンション整数バンドレコード表８０２（図８）は、いくつかのディメンション整数バンドレコード８００から構成され得る。少数のレコード８００ａおよび８００ｂのみが図８に示されているが、任意の数のレコード８００が生成されてもよい。ディメンション整数バンドレコード８００は、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース１４５内に存在し得る。ディメンション整数バンドレコード８００（図８）は、ディメンション識別子フィールド８０５と、値識別子フィールド８１０と、最小値（Ｍｉｎｉｍｕｍ  Ｖａｌｕｅ）フィールド８１５と、最大値（Ｍａｘｉｍｕｍ  Ｖａｌｕｅ）フィールド８２０とを含んでもよい。
【００７０】
ディメンション識別子フィールド８０５は、ディメンションの識別子を含み得、識別子は必ず一意であり、一貫して使用されることが好ましい。たとえば、ディメンション識別子は、ランダムに生成される英数字コードおよび／または文字列であってもよい。ディメンション識別子は、各アカウントに関連して使用される識別子を示すことができる。本明細書において特定の例のディメンション識別子が提示されているが、本明細書における実施形態の範囲から逸脱することなく、任意の種類の一意の識別子が使用されてもよい。図８に示されている例を使用して、「４２２」は、ディメンション−コンタクトリスト相互参照レコード８００ａおよび８００ｂと関連付けられるディメンション識別子である。
【００７１】
値識別子フィールド８１０は、システムがそれに関してデータを収集している値を識別し得る。たとえば、レコード８００ａは「７」の値識別子を示し、レコード８００ｂは「８」の値識別子を示す。
【００７２】
最小値フィールド８１５は、図６に示されている値識別子フィールド６１０およびカテゴリタイプフィールド６１５の範囲を指定する数値バンドの下端を含み得る。図３に示されているように、ディメンション名フィールド３３０は、その範囲が、データタイプフィールド３１５に基づいてその中に入るための整数に対するものであることを示す。最小値フィールド８１５（図８）は、レコード８００ａについて、「４０」の値を示し得る。レコード８００ｂは、最小値フィールド８１５において「５０」の値を示し得る。
【００７３】
最大値フィールド８２０は、図６に示されている値識別子フィールド６１０およびカテゴリタイプフィールド６１５の範囲を指定する数値バンドの上端を含む。図３に示されているように、ディメンション名フィールド３３０は、その範囲が、データタイプフィールド３１５に基づいてその中に入るための整数に対するものであることを示す。最大値フィールド８２０は、レコード８００ａについて、「５０」の値を示す。レコード８００ｂは、最大値フィールド８２０において「６０」の値を示す。図８に与えられている情報は、レコード８００ａに対するデータが４０〜５０の値の間の整数であり、一方で、レコード８００ｂについて、整数は値５０〜６０の間である。
【００７４】
図９は、サンプル公称日付レコード表を示す。公称日付レコード表９０２（図９）は、いくつかの公称日付レコード９００から構成され得る。少数のレコード９００ａ、９００ｂ、および９００ｃのみが図９に示されているが、任意の数のレコード９００が生成されてもよい。公称日付レコードは、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース１４５内に存在し得る。公称日付レコード９００（図９）は、日付識別子（Ｄａｔｅ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド９０５と、日付（Ｄａｔｅ  ｉｎ  Ｔｉｍｅ）フィールド９１０と、日識別子フィールド９１５と、特別日識別子（Ｓｐｅｃｉａｌ  Ｄａｙ  Ｉｄｅｎｔｉｆｉｅｒ）フィールド９２０と、年（Ｙｅａｒ）フィールド９２５とを含んでもよい。
【００７５】
日付識別子フィールド９０５は、表がデータ行を識別するために使用されるテクニカルキーを含んでもよい。たとえば、レコード９００ａは、日付識別子フィールド９０５において「１」の値を有する。レコード９００ｂは「２」の値を有し、９００ｃは「３」の値を有する。
【００７６】
日付フィールド９１０は、レコードの日付を識別するのに使用される情報を含んでもよい、たとえば、レコード９００ａは「２０１２  Ｊａｎ  １」の値を有し、レコード９００ｂは「２０１２  Ｊａｎ  ２」の値を有し、レコード９００ｃは「２０１２  Ｊａｎ  ３」の値を有する。「２０１２  Ｊａｎ  １」は、レコード９００ａに含まれるデータが、カレンダー日付２０１２年１月１日からのものであることを示し得る。
【００７７】
日識別子フィールド９１５は、時間サイクルに対するその関係に関する日を識別し得る。ここのフィールドは、年間通算日、曜日、月などを示すように詳述されてもよい。図９に与えられている例を使用して、「２３４」は、レコード９００ａ、９００ｂ、および９００ｃについての日識別子である。
【００７８】
特別日識別子フィールド９２０は、システムに、図１１において関係付けられている情報を示し得る。特別日識別子は、システムに、平均的な日付とは異なる特別な情報がこのレコードに適用されることを示し得る。特別な日は、人々が一般的に仕事が休みであるか、または他の様態で自身の通常の習慣とは異なる日のような、コンタクトの挙動が任意の他の日とは異なる情報を示し得る。特別な日は、時として休日によってなどで予想することができるか、または、猛吹雪もしくはハリケーンのように、予想することができない。特別日識別子フィールド９２０は、レコード９００ａについて「３」の値を示し、９００ｂおよび９００ｃの各々について「０」の値を示す。「３」の値は、システムに、これが日である特別な日であり、特別な情報がこのレコードと関連付けられることを示し得る。「０」の値は、この特定のレコードが特別な日ではなく、したがって、データはシステムによって通常通り処理されるべきであることを示し得る。
【００７９】
年フィールド９２５は、データの年構成要素であり得る。年フィールド９２５は、レコード９００ａ、９００ｂ、および９００ｃの各々について「２０１２」の値を示し、これは、日付が２０１２年に存在することを示す。
【００８０】
図１０は、サンプルディメンション日レコード表を示す。ディメンション日レコード表１００２（図１０）は、いくつかのディメンション日レコード１０００から構成され得る。少数のレコード１０００ａ、１０００ｂ、および１０００ｃのみが図１０に示されているが、任意の数のレコード１０００が生成されてもよい。ディメンション日レコード１０００は、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース１４５内に存在し得る。ディメンション日レコード１０００（図１０）は、日識別子フィールド１００５と、曜日（Ｄａｙ  ｏｆ  Ｗｅｅｋ）フィールド１０１０と、月間通算日（Ｄａｙ  ｏｆ  Ｍｏｎｔｈ）フィールド１０１５と、月（Ｍｏｎｔｈ  ｏｆ  Ｙｅａｒ）フィールド１０２０と、年間通算週（Ｗｅｅｋ  ｏｆ  Ｙｅａｒ）フィールド１０２５と、週部分（Ｗｅｅｋ  Ｐａｒｔ）フィールド１０３０と、集約タイプ（Ａｇｇｒｅｇａｔｅ  Ｔｙｐｅ）フィールド１０３５とを含んでもよい。
【００８１】
日識別子フィールド１００５は、時間サイクルに対するその関係に関する日を識別し得る。このフィールドは、年間通算日、曜日、月などを示すように詳述されてもよい。図１０に与えられている例を使用して、「２３４」は、レコード１０００ａ、１０００ｂ、および１０００ｃについての日識別子である。
【００８２】
曜日フィールド１０１０は、その日付が入る曜日を示し得る。たとえば、レコード１０００ａは「日曜日」に入り、レコード１０００ｂは「月曜日」に入り、レコード１０００ｃは「火曜日」に入る。
【００８３】
月間通算日フィールド１０１５は、その日付が存在する月間通算日を示し得る。たとえば、レコード１０００ａは「１」の値を有し、これは、その日付がその月の最初の日に存在することを示し得る。レコード１０００ｂは「２」の値を有し、これは、その日付がその月の２番目の日に存在することを示し得る。レコード１０００ｃは「３」の値を有し、これは、その日付がその月の３番目の日に存在することを示し得る。
【００８４】
月フィールド１０２０は、所与の暦年の間にその日付が存在する月を示し得る。たとえば、レコード１０００ａ、１０００ｂ、および１０００ｃはすべて、「１月」の月に存在する。
【００８５】
年間通算週フィールド１０２５は、所与の暦年の間にその日付が存在するのがいずれの週かを示し得る。たとえば、レコード１０００ａ、１０００ｂ、および１０００ｃはすべて「１」の値を有し、これは、これらの日付がその暦年の最初の週内に存在することを示し得る。
【００８６】
週部分フィールド１０３０は、その日付が週末または平日に存在するかを示し得る。たとえば、レコード１０００ａは「週末（ＷｅｅｋＥｎｄ）」の値を有し、これは、その日付が平日とは対照的に週末に存在し得ることを示す。レコード１０００ｂおよび１０００ｃは「平日（ＷｅｅｋＤａｙ）」の値を有し、これは、それらの日付が週末とは対照的に平日に存在し得ることを示す。システムが使用される場所に応じて、週末である日は、土曜日および日曜日を含み得、一方で、平日は、月曜日、火曜日、水曜日、木曜日、および金曜日を含み得る。
【００８７】
集約タイプフィールド１０３５は、存在する情報の量に応じて「詳細（Ｄｅｔａｉｌ）」または「集約（Ａｇｇｒｅｇａｔｅ）」の値を示し得る。表がすべての値を埋めさせている場合、ユーザは、情報のすべてを見るために「詳細」ビューを選択し得る。ユーザが情報のすべてを見ることを望まないか、または断片が欠けている場合、ユーザは、情報の一部のみを見ることを選択し得る。たとえば、レコード１０００ａ、１０００ｂ、および１０００ｃは、表内に値「詳細」を示し、これは、ユーザが表に含まれる情報のすべてを見ることを望んでいることを示し得る。
【００８８】
図１１は、サンプル特別日規則定義レコード表を示す。特別日規則定義レコード表１１０２（図１１）は、いくつかの特別日規則定義レコード１１００から構成され得る。少数のレコード１１００ａ、１１００ｂ、１１００ｃ、１１００ｄ、および１１００ｅのみが図１１に示されているが、任意の数のレコード１１００が生成されてもよい。特別日規則定義レコード１１００は、呼選択データベース１４５（図１）と関連付けられ得るか、または呼選択データベース１４５内に存在し得る。特別日規則定義レコード１１００（図１１）は、特別日識別子フィールド１１０５と、ロケール（Ｌｏｃａｌｅ）フィールド１１１０と、特別措置（Ｓｐｅｃｉａｌ  Ｔｒｅａｔｍｅｎｔ）フィールド１１１５と、開始時間（Ｓｔａｒｔ  Ｔｉｍｅ）フィールド１１２０と、終了時間（Ｅｎｄ  Ｔｉｍｅ）フィールド１１２５と、特別日名（Ｓｐｅｃｉａｌ  Ｄａｙ  Ｎａｍｅ）フィールド１１３０と、特別日規則（Ｓｐｅｃｉａｌ  Ｄａｙ  Ｒｕｌｅ）フィールド１１３５とを含んでもよい。
【００８９】
特別日識別子フィールド１１０５は、システムに、平均的な日付とは異なる特別な情報がこのレコードに適用されることを示し得る。特別な日は、人々が一般的に仕事が休みであるか、または他の様態で自身の通常の習慣とは異なる日のような、コンタクトの挙動が任意の他の日とは異なる情報を示し得る。これらは、時として休日によってなどで予想することができるか、または、猛吹雪もしくはハリケーンのように、予想することができない。特別日識別子フィールド１１０５は、レコード１１００ａについて「１」の値、レコード１１００ｂについて「２」の値、レコード１１００ｃについて「３」の値、レコード１１００ｄについて「４」の値、およびレコード１１００ｅについて「−１」の値を示す。
【００９０】
ロケールフィールド１１１０は、特定の地域または国のような、特別な日の場所を示し得る。たとえば、レコード１１００ａ、１１００ｂ、１１００ｄ、および１１００ｅは、これがシステムが利用されているロケールであることを示し得る「デフォルト（Ｄｅｆａｕｌｔ）」のロケールを示す。レコード１１００ｃは、これが、他のどこでもなく、特別な日が存在している国であることを示し得る「カナダ」のロケールを示す。
【００９１】
特別措置フィールド１１１５は、特別な日が識別されると、特別な日をどのように処理すべきかを示し得る。システムは、特別な日を無視するか、標準的な措置、または指定通りに任意の他のそのような措置をもたらし得る。たとえば、レコード１１００ａ、１１００ｂ、１１００ｃ、および１１００ｄは、「標準（Ｓｔａｎｄａｒｄ）」特別措置を示す。レコード１１００ｅは、特別措置フィールド１１１５内に「無視（Ｉｇｎｏｒｅ）」を示す。システムは、したがって、この特別な日を無視し得る。
【００９２】
開始時間フィールド１１２０は、特別な日を認識するための期間の始まりを示し得る。たとえば、レコード１１００ａ、１１００ｂ、１１００ｃ、１１００ｄ、および１１００ｅは、「２０１２  Ｊａｎ  １」の開始時間を示し、これは、システムが２０１２年１月１日に特別な日の認識を開始することを意味し得る。
【００９３】
終了時間フィールド１１２５は、特別な日を認識するための期間の終わりを示し得る。たとえば、レコード１１００ａ、１１００ｂ、１１００ｃ、１１００ｄ、および１１００ｅは、「空値（ＮＵＬＬ）」の終了時間を示し、これは、システムが特別な日の認識のための終了時間を有しないことを意味し得る。
【００９４】
特別日名フィールド１１３０は、認識される特別な日の名前を示し得る。たとえば、レコード１１００ａは、特別な日の名前が「クリスマス」であることを示す。レコード１１００ｂおよび１１００ｃは、「感謝祭」を示す。レコード１１００ｄは「イースター」を示し、レコード１１００ｅは「特別な日（Ｓｐｅｃｉａｌ  Ｄａｙ）」を示す。
【００９５】
特別日規則フィールド１１３５は、システムが認識するための規則としての、特別な日が存在する日付を示し得る。規則は、たとえば、日および月、平日、計算などのような、任意の数のフォーマットにおいて提示されてもよい。たとえば、レコード１１００ａは「１２月２５日（Ｄｅｃ  ２５）」を示し、これは、特別日名「クリスマス」が、システムによって「１２月２５日」に存在するものとして認識されるべきであることを示し得る。レコード１１００ｂは「１１月第４木曜日（Ｎｏｖ  ４ｔｈ  Ｔｈｕ）」を示し、これは、特別日名「感謝祭」が、システムによって１１月の第４木曜日に存在するものとして認識されるべきであることを示し得る。レコード１１００ｃは「１０月第２月曜日（Ｏｃｔ  ２ｎｄ  Ｍｏｎ）」を示し、これは、特別日名「感謝祭」が、システムによって１０月の第２月曜日に存在するものとして認識されるべきであることを示し得る。レコード１１００ｄは「Ｅ」を示し、これは、特別日名「イースター」がシステムによって計算されるべきであることを示し得る。レコード１１００ｅは「Ｘ」を示し、これは、この日を予想することができないことを示し得る。
【００９６】
図面および上記の説明において本発明が詳細に図示および説明されたが、これは特性において例示であるとして、また限定ではないとして考えられるべきであり、好ましい実施形態のみが図示および説明されていること、ならびに、本明細書においておよび／または添付の特許請求の範囲によって記載されているような本発明の精神の中に入るすべての均等物、変更、および修正が保護されることが所望されることは理解されたい。
【００９７】
したがって、本発明の適切な範囲は、図面に示され本明細書に記載されているものと等価なすべてのそのような修正およびすべての関係を包含するように、添付の特許請求の範囲の最も広い解釈によってのみ決定されるべきである。
【図１】
2015526785.tif 000003
【図２】
2015526785.tif 000004
【図３】
2015526785.tif 000005
【図４】
2015526785.tif 000006
【図５】
2015526785.tif 000007
【図６】
2015526785.tif 000008
【図７】
2015526785.tif 000009
【図８】
2015526785.tif 000010
【図９】
2015526785.tif 000011
【図１０】
2015526785.tif 000012
【図１１】
2015526785.tif 000013
【国際調査報告】
2015526785.tif 000014