Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン（SRND）Releases 7.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月14日
章のタイトル： コール センターのリソース サイジング
コール センターのリソース サイジング
Cisco Unified Contact Center に限らずすべてのコール センターの設計では、リソースの適切なサイジングが重要です。 この章では、（コールの量および必要なサービス レベルなどのお客様要件に基づいて）必要なコール センターのエージェントの人数、さまざまなコール シナリオ（コール処理、プロンプトとコレクト、キューイング、セルフ サービス アプリケーションなど）に必要な Unified IP IVR ポート数、PSTN やその他の PBX、TDM IVR など（TDM 発信元）から着信するトラフィックがある場合に必要となる音声ゲートウェイ ポートの数を決定するためのツールおよび方法論について説明します。
この章で説明されている方法論およびツールは、Unified CC の展開で各種リソースに適用されている Erlang-B および Erlang-C モデルを使用したトラフィック エンジニアリングの原則に基づいています。 Unified IP IVR でのコール処理（プロンプトとコレクト）の影響やエージェントが費やすラップアップ時間の違いなど、さまざまなコール シナリオに対してリソースがどのように影響を受けるのかを示すために、例を提供します。 これらのツールと方法論は、コール センターのリソース サイジングや IP テレフォニーの各種応用における基本手法として一般的に利用されることを意図しています。
コール センターの基本トラフィック用語
コール センターに共通する用語を理解し、その使用においてはあいまいさを排除することが重要となります。 コール センターのリソース サイジングに使用されているツールでこれらの用語が不正確に使用されている場合、サイジング結果が不適切になる可能性が生じます。
ここにリストアップした用語は、コール センターの業界でリソース サイジングに使用されている最も一般的な用語です。 コール センターの用語の定義については、インターネット上のその他のリソースも参考になります。
このセクションにリストされている用語以外に、「Cisco Unified CC Resource Calculator」のセクションには、シスコ コール センターのサイジング ツールである Unified CC Resource Calculator の入出力に使用される特定の用語が定義されています。
また、このマニュアルで説明されているコール センターの各種用語および概念についての詳細は、次の URL でオンラインで入手できる Unified CC 製品マニュアルを参照してください。
最頻時の期間は、1 時間もしくは（必要に応じて 30 分や 15 分などの）1 時間よりも短い時間に設定してサイジングを実施できます。 最頻時の期間は、1 日のうちでトラフィックが最も集中する時間の長さを示します。 最頻時または最頻時の期間は、日、週、および月によって変動します。 週毎の一番の混雑時もあれば季節による一番の混雑時もあります。 1 年で一番の混雑時もあります。 一般的な方法では、最頻時の平均（1 年で最も混雑している時間の上位 10 の平均）値を使って設計します。 ただしこの平均値は、マーケティング キャンペーンや季節の最頻時（祝日のピークなど）に対応するための配置が必要となる場合には、常に適用できるわけではありません。 コール センターでは、エージェントの最大人数はピーク期間の数値を使用して決定されますが、1 日のピーク期間以外の配置要件は、コールに応答するエージェントの適切なスケジューリング、および訓練や指導などのオフラインの活動のためのエージェントのスケジューリングを考慮して、一定の時間単位（通常は 1 時間単位）で個別に計算されます。 多くの場合、トランクおよび IVR ポートに関しては、これらのリソースを毎日追加または削除することは実用的ではないため、ピーク期間に合わせてサイジングされます。 一部の小売業では、ピークとなるシーズンだけ増設用のトランクを追加し、ピークがすぎると切り離すこともあります。
最頻時/最頻時の期間の発呼（BHCA; Busy Hour/Interval Call Attempts）
BHCA は、トラフィックのピークとなる時間帯にコール センターで受信または受信を試みたコールの総数です。 説明を簡略化するために、音声ゲートウェイに提供されるすべてのコールは、コール センターのリソース（エージェントおよび Unified IP IVR ポート）によって受信され、処理されるものとします。 コールは通常 PSTN 経由で受信されますが、コール センターへのコールはヘルプ デスク アプリケーションなどによって内部的に生成することもあります。
サーバは、トラフィック負荷またはコールを処理するリソースです。 コール センターには、PSTN トランクおよびゲートウェイ ポート、エージェント、音声メール ポート、IVR ポートなど、数多くのタイプのサーバがあります。
通話時間とは、エージェントが発信者との通話に費やす時間のことです。この時間には、エージェントが発信者を保留にしている時間、および相談のための打ち合わせ時間が含まれています。
ラップアップ時間とは、コールの終了後（発信者がエージェントとの通話を終了し、電話を切った後）、エージェントがコールをラップアップするために必要とする時間のことです。エージェントはこの時間に、データベースの更新、コールのメモ記録などのタスク、またはエージェントが別のコールに応答できるようになるまでの間に実行するその他の活動を行います。 この概念を表す Unified CC 用語は アフターコール ワーク時間 です。
平均処理時間（AHT; Average Handle Time）
AHT とは、指定された期間の間のコールの平均継続時間のことです。 この用語は、いくつかのタイプの処理時間（コール処理時間、通話時間、キューイング時間など）の合計を示す、一般的に使用される用語です。 最も一般的な定義では、AHT は、エージェントの通話時間とエージェントのラップアップ時間の合計となります。
Erlang は最頻時のトラフィック負荷の計測単位です。 Erlang は、同一の回線、トランク、またはポートに、コールが 3600 秒（60 分、つまり 1 時間）存在する場合を基準としています （コールの回数や平均継続時間に関係なく、1 つの回線が 1 時間にわたって話中になる状態です）。 コンタクト センターが最頻時に 30 のコールを受信し、それぞれのコールの継続時間が 6 分である場合、この値は、最頻時では 180 分のトラフィック、つまり 3 Erlang（180 分/60 分）に相当します。 最頻時にコンタクト センターが平均 36 秒のコールを 100 個受信した場合、受信した総トラフィックは 3600 秒、つまり 1 Erlang（3600 秒/3600 秒）になります。
トラフィック（単位 Erlang）=（最頻時のコール数 ∗ AHT 秒）/ 3600 秒
この用語は、トラフィック エンジニアリングで使用されるキューイング セオリーの考案者であるデンマークの電話技術者 A. K. Erlang にちなんで付けられました。
最頻時トラフィック（BHT; Busy Hour Traffic）（単位：Erlang）
BHT は最頻時のトラフィック負荷であり、BHCA と AHT の積として計算され、1 時間で正規化されます。
たとえば、最頻時にコール センターが平均 2 分間のコールを 600 回受信した場合、最頻時のトラフィック負荷は（600 * 2/60）= 20 Erlang となります。
BHT は通常、PSTN トランク数やセルフサービス用の IVR ポート数などのリソースを計算するために Erlang-B モデルで使用されます。 一部のカルキュレータでは、利便性を高めるために BHCA および AHT を使用して透過的にこの計算を実行できます。
この値は、最頻時にリソースまたはサーバがビジーになっている確率を示します。 あるユーザが電話をかけてきたときにすべてのリソースが占有中という可能性もあります。 このような場合、そのコールは失われるかまたはブロックされます。 この確率をブロック率と呼び、一般的には音声ゲートウェイ ポート、IVR ポート、PBX 回線、トランクなどのリソースに適用されます。 音声ゲートウェイの場合、サービス グレードは、総 BHCA に対するブロックされたコール、またはビジー トーン（使用可能なトランクなし）を受信したコールのパーセンテージになります。 たとえばサービス グレードが 0.01 の場合、最頻時にはコールの 1 % がブロックされることになります。 1 % というブロック率は PSTN トランクを使用する場合の典型的な値ですが、別のアプリケーションでは異なるサービス グレードが必要になる場合もあります。
ブロックされたコールとは、即時にサービスを受けることができないコールのことです。 発信者が別のルートまたはトランク グループに再ルーティングされるか、遅延されるか、キューに入れられるか、またはトーン（ビジー トーンなど）や応答メッセージで対応される場合に、その発信者はブロックされたとみなされます。 ブロックされたコールの内容に応じて、対応するリソースのサイジングに適用されるモデルが決定されます。
これはコンタクト センター業界の標準用語であり、（音声ゲートウェイおよび他のソースから受信されて） x 秒（ x は変数）以内に応答されるコールの割合をパーセンテージで示しています。 販売系のコール センターでは、全コール中の 90 % が 10 秒以内に応答されるのが一般的です（一部のコールはキューに入れられて遅延されます）。 サポート系のコール センターの場合は、たとえば最頻時に全コールの 80 % が 30 秒以内に応答されるというように、販売系とは異なるサービス レベルを目標値として設定する可能性があります。 コンタクト センターのサービス レベルの目標に応じて、必要とされるエージェントの人数、キューに入れられるコールの比率、コールがキューに入れられている平均時間、および必要となる PSTN トランク数と Unified IP IVR のポート数が決定されます。 Unified CC 製品におけるサービス レベルのより詳細な定義については、Unified CC 用語集を参照してください。この用語集は、次の URL からオンラインで入手できます。
エージェントが他の発信者と通話中であるかまたは対応できない場合（ラップアップ中であるために）、いずれかのエージェントが応答可能になるまで後続の発信者をキューに入れておく必要があります。 キューに入れられたコールの比率およびキュー内で経過する平均時間は、目標設定したサービス レベルおよびエージェントの配置状況によって決定されます。 シスコの Unified CC ソリューションでは、Unified IP IVR を使用して発信者をキューに入れ、アナウンスを流します。 IVR は、全コールの初期処理（コール処理、DTMF 入力や課金番号などのプロンプトとコレクト、またはその他の情報収集）、および発信者がエージェントと通話することなく受けることができるセルフサービス アプリケーション（銀行の勘定残高や航空機の発着時間などの情報取得）に使用することもできます。 これらの各シナリオでは、さまざまなアプリケーションを処理するために必要となる Unified IP IVR のポート数が異なります。これは、それぞれの平均処理時間およびコールの負荷が異なっているためです。 これらの各アプリケーションで必要となるトランクまたはゲートウェイ ポートの数も、それに応じて異なります （「コール センターのエージェント、IVR ポート、およびゲートウェイまたはトランクのサイジング（インバウンド コール センター）」のセクション、たとえば、必要となるトランクおよびゲートウェイ ポートの数の計算方法についてのセクションを参照してください）。
コール センターのリソースとコールのタイムライン
この章では、次に示すコール センターの主要なリソースのサイジングについて説明します。
インバウンド コール センターの処理の構造は、そこで使用される各種リソースとそれらのリソースで費やされる時間に関係があるので、最初にその構造を把握しておくことが後ほどの理解に役立ちます。図7-1 に、使用される主要なリソースとそこで費やされる占有状態（保持時間と処理時間）について示します。
コールが即時に応答されない場合は、リングの遅延時間（ネットワーク リング）を含める必要があります。 この遅延は平均すると数秒ですが、トランクの平均処理時間に追加する必要があります。
Unified CC システム全体のサイジングには、さまざまなツールやリソースを使用できます。 コンタクト センターのトラフィック データやサービス レベル要件を Unified CC Resource Calculator に入力し、生成された出力を他のツールで処理することによって、次の Unified CC システム コンポーネントおよびリソースをサイジングできます。
Unified CC システムに必要な数のエージェントをサポートするには、次のコンポーネントをサイジングします。
–
Unified CC サーバ：「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
–Cisco Unified CallManager クラスタ：次の URL にある Cisco Unified CallManager Capacity Tool を使用します。
http://www.cisco.com/cgi-bin/CT/CCMCT/ct.cgi
Unified CC システムに必要な数の IVR ポートをサポートするには、次のコンポーネントをサイジングします。
–Unified CC サーバ：「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
–Cisco Unified CallManager クラスタ：次の URL にある Cisco Unified CallManager Capacity Tool を使用します。
http://www.cisco.com/cgi-bin/CT/CCMCT/ct.cgi
–Unified CVP ポートおよびサーバ：次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。
Unified CC システムに必要な数のゲートウェイ ポートをサポートするには、次のコンポーネントをサイジングします。
–Unified CC サーバ：「Unified CC のコンポーネントとサーバのサイジング」を参照してください。
–Cisco Unified CallManager クラスタ：次の URL にある Cisco Unified CallManager Capacity Tool を使用します。
http://www.cisco.com/cgi-bin/CT/CCMCT/ct.cgi
–Unified CVP ポートおよびサーバ：次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。
–ゲートウェイ：次の URL にある『 Cisco Unified Customer Voice Portal Solution Reference Network Design (SRND) 』を参照してください。
設計ツールとしての Erlang カルキュレータ
電話のシステムおよびリソースのサイジングに利用できるトラフィック モデルは数多く存在します。 正しいモデルの選択は、次の 3 つの要素に依存しています。
この文書の目的であるコール センターのリソース サイジング用に一般的に使用されているのは Erlang-B および Erlang-C という 2 つのトラフィック モデルです。インターネットで調べると、この他のさまざまなモデルについての詳細な解説を参照できます（traffic engineering（トラフィック エンジニアリング）で検索してください）。
Erlang カルキュレータは、次の質問に答える場合に役立つよう設計されています。
これらの基本的な質問に答えるには、少なくとも、これらのカルキュレータの入力として必要になる次の情報を準備しておく必要があります。
• Busy Hour Call Attempts（BHCA; 最頻時発呼数）
• リソースごとの Average Handle Time（AHT; 平均処理時間）
• サービス レベル（ x 秒以内に応答されるコールの割合）
• PSTN トランクおよび Unified IP IVR ポート用として必要となるサービス グレード、またはブロック率
これ以降、この章では簡単な用語を使用して Erlang-B と Erlang-C トラフィック モデルの違いについて説明します。また、コール センターの特定リソース（エージェント、ゲートウェイ ポート、および Unified IP IVR ポート）のサイジングに使用するモデルを示します。 さまざまな Web サイトでコール センターのサイジング ツールが無料で提供されていますが（機能が豊富なバージョンを購入用として提供しているサイトもあります）、これらのツールはすべて基本トラフィック モデルである Erlang-B および Erlang-C を使用しています。シスコは、特定のベンダー製品を支持していません。お客様はそれぞれの必要に応じてツールをお選びください。 いずれのツールでも、要求される入力項目および使用される方法論は、ツールに関係なく同じになります。
シスコは、Cisco Unified CC Resource Calculator という独自のテレフォニー サイジング ツールを開発しました。 ここでの検討に使用するバージョンは、コール センターのリソース サイジングを目的として設計されています。 この章の後半には、Cisco Unified CC Resource Calculator の使用方法を示すために、いくつかの基本的な例が示されています。 入力フィールドの一部（すべてではありません）が既知または使用可能である場合のこのツールの使用方法を示す追加の例も含まれています。
Cisco Unified CC Resource Calculator について説明する前に、Cisco Unified CC Resource Calculator を使用できない読者、または Cisco 以外の Erlang ツールを使用する読者のために、次の 2 つのセクションで一般的な Erlang モデルと（インターネットから入手可能な）Erlang ツールの入出力項目について簡単に説明します。
Erlang-C
Erlang-C モデルは、コールをエージェントに送る前にいったんキューに送るコール センター内のエージェントをサイジングする場合に使用します。 このモデルは次のような条件を前提とします。
• すべてのエージェントがビジーの場合、新規のコールはキューに入れられ、ブロックされない。
• 必要な遅延またはサービス レベル（指定された秒数以内で応答されるコールの割合で記述します）
Erlang-C モデルの出力には、必要なエージェントの人数、応答可能なエージェントがいない場合に遅延されたコールやキューに入れられたコールの比率、およびこれらのコールの平均キュー時間がリストされます。
Erlang-B
Erlang-B モデルは、PSTN トランク、ゲートウェイ ポート、または Unified IP IVR ポートをサイジングする場合に使用します。 このモデルは次のような条件を前提とします。
• すべてのトランクおよびポートが占有されている場合、新規のコールは失われるかブロックされ（ビジー トーンを受信）、キューには入れられない。
Erlang B モデルの入出力は、次の 3 つの要素で構成されています。 これらの要素のいずれか 2 つは既知である必要がありますが、3 つ目の要素はこのモデルで計算されます。
• Busy Hour Traffic（BHT; 最頻時トラフィック）。つまり最も混雑している運用時間におけるコール トラフィックの時間（単位は Erlang）。 BHT は、最頻時のコールの数（BHCA）と Average Handle Time（AHT; 平均処理時間）の積で表されます。
Cisco Unified CC Resource Calculator
シスコは頻繁に Cisco Unified Communications Resource Calculator の機能強化を行っており、現在、次のようなカルキュレータを含んでいます。
• スタンダード Unified CC Resource Calculator：1 つのトランク グループを持つ 1 つのコール センターの出力を提供する設計になっています。 ユーザは、エージェントの数を変更できます。
• アドバンスド Unified CC Resource Calculator：スタンダード カルキュレータのすべての計算を含み、さらに複数のトランク グループにトラフィックを割り当てて、セルフサービス IVR に送信されるコールを含むことができます。 また、信頼および成長の要因に関する入力もあります。
• アウトバウンド Unified CC Resource Calculator：アウトバウンド コール キャンペーンのコンポーネントを使用して、必要なリソース（アウトバウント ゲートウェイ ポートおよびトランク、ダイヤラ ポート、アウトバウンド エージェント、および IVR ポート）を計算します。
• Unified IP IVR セルフサービス カルキュレータ：セルフサービス IVR に必要なポート数を決定する標準の Erlang B カルキュレータです。 最大 5 つのポートグループまたは個別の IVR への入力があります。
これらのカルキュレータの最新バージョンおよび関連するユーザ ガイドは、次の URL から入手できます。
http://tools.cisco.com/partner/ipccal/index.htm
Cisco Unified CC Resource Calculator は、シスコの社員およびシスコ パートナーが使用できます。 これらのツールは、業界の Erlang トラフィック モデルに基づいています。 Web で入手できるその他の Erlang トラフィック カルキュレータも、コンタクト センターの各種リソース サイジングに使用できます。
図7-2 に、現在のスタンダード Unified CC Resource Calculator のスナップショット、入力と出力のためのフィールドと定義とその使用方法、およびこれらの解釈方法を示します。
図7-2 Cisco Unified CC Resource Calculator
スタンダード Unified CC Resource Calculator の入力フィールド（指定する必要がある項目）
スタンダード Unified CC Resource Calculator を使用するときは、次の入力データを指定する必要があります。
Project Identification（プロジェクト名）
プロジェクトやお客様名、およびこの計算のための特定のシナリオを識別するための説明です。 このフィールドは、あるプロジェクトまたはお客様の提案に対して実行される（エクスポートおよび保管される）さまざまなシナリオを識別する場合に役立ちます。
Calls Per Interval (BHCA)（最頻時発呼数）
最も混雑している時間の発呼数、または Busy Hour Call Attempts（BHCA; 最頻時発呼数）。 ここでは混雑時間を 60 分、30 分、または 15 分の中から選べます。 混雑時間を 1 時間という単位よりも短い長さで指定することにより、必要なエージェント人数をより正確に計算できます。 また、1 日の任意の時間帯におけるエージェントの必要人数の計算にも使用できます（混雑していない時間の人員計画）。
Service Level Goal (SLG)（サービス レベルの目標値）
指定した秒数以内に応答するコールの割合（30 秒以内に 90 % など）。
Average Call Talk Time（平均コール通話時間）
エージェントがコールに応答した後、発信者がオンラインになっている平均の秒数。 この値には、コールが終了するまでの通話時間およびエージェントが保留している時間が含まれています。 この値には、コール処理のために IVR で経過した時間またはキューに入れられていた時間は含まれていません。
Average After-Call Work Time（アフターコール ワーク平均時間）
発信者が電話を切った後のエージェントがラップアップに要する平均時間です。 このエントリでは、エージェントがラップアップ モードにない場合、エージェントはコールに応答できることが想定されています。 着席しているエージェントがコールに応答できない（ラップアップ モードとは異なる）別のモードに入っている場合は、その分の追加時間を（すべてのコールについて平均して）アフターコール ワーク時間に追加する必要があります。
Average Call Treatment Time (IVR)（コールの平均処理時間）
コールをエージェントに送る前に、そのコールが IVR 内で費やした平均時間（秒）。 この時間には、コールをエージェントにルーティングするための数字を収集および入力（プロンプトとコレクト、または IVR メニューとも呼ばれます）するための時間だけでなく、グリーティングおよびアナウンスの時間も含まれています。 この時間には、エージェントが応答できない場合のキューイング時間は含まれていません （このキューイング時間は、カルキュレータの出力項目として計算されます）。 セルフサービスのために IVR に着信するコールは、このコールをエージェントにルーティングしない場合、コール処理時間には含めないようにする必要があります。 セルフサービス IVR アプリケーションは、Erlang-B カルキュレータを使用して個別にサイジングする必要があります。
Wait Before Abandon (Tolerance)（放棄までの待ち時間、許容時間）
このフィールドには、発信者が許容できる待ち時間を秒単位で指定します。これ以上応答がないと発信者は待ちきれずに電話を切る、とコンタクト センター マネージャが想定する時間です。 この値は、放棄率（放棄されるコールの数）を除き、いずれの出力フィールドにも影響を与えません。
Blockage % (PSTN Trunks)（ブロック率、PSTN トランク）
このフィールドは、サービス グレードとも呼ばれます。最頻時または最頻時の期間中に、ビジー トーン（ゲートウェイで使用可能なトランクが存在してない）を受信するコールの割合を示しています。 たとえばブロック率が 1 % である場合は、期間中に PSTN のすべての発呼の 99 % がゲートウェイ上でトランク ポートを使用でき、IVR またはエージェントに到達できることを示しています。
Check to Manually Enter Agents（エージェントの人数指定）
このボックスにチェック マークを付けると、ユーザはエージェントの数を手動で入力できます。 入力されたエージェントの数が計算された（推奨）人数と大幅に異なる場合は、カルキュレータによってエラー メッセージが表示されます。 このエラーは、キューに入れられているコールの数が 0 % または 100 % に到達すると必ず発生します。
スタンダード Unified CC Resource Calculator の出力フィールド（算出される項目）
スタンダード Unified CC Resource Calculator では、入力データに基づいて次の出力値が計算されます。
Recommended Agents（エージェントの推奨人数）
最頻時または最頻時の期間中にコール センターに配置する必要があるエージェントの人数です（Erlang-C に基づいて計算されます）。
Calls Completed (BHCC)（最頻時発呼完了）
Busy Hour Call Completions（BHCC; 最頻時発呼完了）、つまり最頻時に完了することが予測されているコールの数を示しています。 これは、発呼数からブロックされたコールの数を引いたものです。
Calls Answered Within Target SLG（目標 SLG 時間内に応答されたコール）
[Service Level Goal (SLG)] フィールドに入力した目標時間内に応答されたコールの割合です。 この値は、エージェントが応答可能である場合は即時に応答されたコールの割合の計算値となります。 この値には、SLG 以内（たとえば 30 秒未満）に応答できるエージェントがいないためキューに入れられたコールの一部が含まれています。 SLG 目標を過ぎてからキューに入れられるコールがあるため、この値には、キューに入れられたすべてのコールが含まれているわけではありません。
Calls Answered Beyond SLG（SLG を超える応答コール）
[Service Level Goal (SLG)] フィールドに入力した設定済みの目標時間を過ぎて応答されたコールの割合です。 たとえば、30 秒以内にコールの 90 % が応答される SLG の場合、この SLG を過ぎてから応答されたコールは 10 % になります。 この値には、キューに入れられたすべてのコールの一部が含まれていますが、SLG を（たとえば、30 秒以上）過ぎてからキューに入れられた部分だけが含まれています。
最頻時または最頻時の期間中に IVR でキューに入れられたすべてのコールの割合です。 この値には、SLG を過ぎてからキューに入れられたコールだけでなく、キューに入れられてからサービス レベル目標以内に応答されたコールも含まれています。 たとえば、コールの 90 % が 30 秒以内に応答される SLG で、キューに入れられたコールが 25 % の場合は、コールの 10 % が 30 秒を過ぎてからキューに入れられ、コールの残りの 15 % は 30 秒（SLG）以内に応答されます。
Calls Answered Immediately（即座に応答されたコール）
（IVR が実装されている場合に）コールが IVR で処理された後、即時にエージェントによって応答されたコールの割合です。 これらのコールは、キュー内でエージェントを待機する必要はありません。 上記の例と同様に、コールの 25 % がキューに入れられている場合（目標の 30 秒を超えているコールを含む）、そのコールの 75 % は即時に応答されます。
Average Queue Time (AQT)（平均待ち時間）
コールがキュー内で、期間中にエージェントが応答可能になることを待機する平均時間（秒）です。 この値には、エージェントにコールを送信する前の IVR でのコール処理は含まれていません。
Average Speed of Answer (ASA)（平均応答スピード）
期間中のすべてのコールについての応答の平均スピードです。キューに入れられたコールおよび即時に応答されたコールが含まれています。
Average Call Duration（平均コール継続時間）
コールがシステムに留まっていた時間の合計（秒）です。 この値は、平均通話時間、平均 IVR 遅延（コール処理）、および平均応答スピードの合計です。
コール トラフィックの処理にかかったエージェント時間対アイドル時間の比率です。 アフターコール ワーク時間は、この計算には含まれていません。
Calls Exceeding Abandon Tolerance（放棄までの許容時間を超えたコール）
最頻時の期間において、入力項目として指定した許容時間を超えたために放棄されたコールの割合（および数）です。 この出力がゼロの場合、キューに入れられたすべてのコールは指定した許容時間内にエージェントによって応答されています（最も長くキューに入れられていたコールでも許容時間には達しませんでした）。
PSTN Trunk Utilization（PSTN トランク稼働率）
PSTN トランクの占有率です。提供されている負荷（Erlang）をトランク数で割って計算されます。
Voice Trunks Required（音声トランクの必要数）
音声ゲートウェイによって応答されたコールの数、および最頻時の期間中のトランクの平均の保留時間に基づいて最頻時の期間中に要求された PSTN ゲートウェイ トランクの数。 この値には、IVR でのコール処理の平均時間、（応答可能なエージェントがいなかったため）IVR でキューイングされていた平均時間、およびエージェントの通話時間が含まれています。 計算されたこの数は、すべてのトランクが 1 つの大きなグループにまとめられて、指定された最頻時（または期間）のコールを処理することを想定しています。 代わりに、いくつかの小さいトランク グループを使用した場合は、追加のトランクが必要となるためグループが小さくなり効率も低下します。
IVR Ports Required for Queuing（キューイングに必要な IVR ポートの数）
エージェントが応答可能になるまで発信者が待機している間、コールをキューで保持するために必要となる IVR ポートの数です。 この値は、キューに入れられているコールの数、およびこれらのコールの平均キュー時間を使用した Erlang-B 計算に基づいて算出されます。
IVR Ports Required for Call Treatment（コール処理に必要な IVR ポートの数）
IVR でのコール処理のために必要となる IVR ポートの数です。 この値は、応答されたコールの数、およびコール処理時間（平均 IVR 遅延）を使用した Erlang-B 計算に基づいて算出されます。
Total IVR Ports Requirement（IVR ポートの合計必要数）
キューイングおよび処理のために個別のポートグループが設定されているシステムにおいて、必要となる IVR ポートの総数を示すものです。 処理およびキューイングのいずれにも使用できるポートをプールする場合、トラフィックを 2 つの個別の IVR ポート プールまたはグループに分割する場合と比べて、より少ないポート数で同じトラフィック量を処理できます。 ただし、シスコは、キューイングに必要なポート数を独立したグループに設定し、使用可能な場合は他のグループにオーバーフローできるよう設定することをお勧めします。
必要な入力フィールドすべてにデータを入力した後、[Submit] ボタンをクリックして出力値を計算します。
[Export] ボタンをクリックして、カルキュレータの入力および出力をカンマ区切り値（CSV）フォーマットでハード ドライブ上の任意の場所に保管します。 この CSV ファイルを Microsoft Excel にインポートすると、ビッド プロポーザルへの挿入用またはクライアントやお客様へのプレゼンテーション用としてフォーマットできます。 入力フィールドを 1 つ以上変更し、入力の変更を反映した列に適切なタイトルを付け、すべての出力を 1 つの Excel スプレッドシートに結合すると、複数のシナリオを保管できます。 このフォーマットを使用すると、複数のシナリオを簡単に比較解析できます。
コール センターのエージェント、IVR ポート、およびゲートウェイまたはトランクのサイジング（インバウンド コール センター）
このセクションのコール センターの例では、さまざまなシナリオにおける Unified CC Resource Calculator の使用方法について、要求されたインバウンド コール センターのリソースに対する影響とともに説明します。 このセクションの最初の例は、基本的なコール フローです。コール センターに着信するすべての着信コールは、PSTN から音声ゲートウェイに提供されます。 コールは、エージェントが応答可能である場合、そのエージェントに直接ルーティングされます。応答可能でない場合、エージェントが応答可能になるまでコールはキューに入れられます。
コール センターの基本例
この例は、後続のこの章のすべての例の基本となります。 この基本例における 3 つのリソース（エージェント、IVR ポート、および PSTN トランク）を強調した出力結果について簡単に説明した後、コール処理およびエージェントのラップアップ時間などのさまざまなシナリオを追加して、この例を後続のシナリオの基礎とし、各種リソースがさまざまなシナリオによってどのような影響を受けるかについて説明します。
• 音声ゲートウェイへの PSTN からコール センターへの BHCA（60 分間）の合計 = 2,000。
• 必要なサービス レベルの目標（SLG）= 30 秒以内にコールの 90 % が応答される。
• コールの平均通話時間（エージェントの通話時間）= 150 秒（2 分 30 秒）。
• アフターコール ワーク時間なし（エージェントのラップアップ時間 = 0 秒）。
• コール処理（プロンプトとコレクト）なし、が最初に実装されている。 すべてのコールは、応答可能なエージェントにルーティングされるか、またはエージェントが応答可能になるまでキューに入れられます。
• 発信者が電話を切るまでの待ち時間（許容時間）= 150 秒（2 分 30 秒）。
• 音声ゲートウェイ上の PSTN トランクの必要なサービス グレード（ブロック率）= 1 %。
上記のデータを入力フィールドに入力し、カルキュレータの下部にある [Submit] ボタンを押すと、図7-3 に示されている結果が出力されます。
出力には、PSTN から試行された合計 2000 のコールの内、音声ゲートウェイによって受信され処理された（完了した）コールは 1980 であることが示されています。 これは、PSTN プロバイダーに 1 % のブロック率のプロビジョニングを要求し、その結果、合計で 2000 のコールの内 20 のコール（1 %）が PSTN によってブロックされた（ビジー トーンを受信した）ためです。
着席しているエージェントが 90 であるという結果は、Unified CC Resource Calculator に内蔵されている Erlang-C 関数を使用して決定された値です。このリソース（エージェント）へのコールはキューに入れられます。
エージェントが 90 の場合、計算によるサービス レベルは、30 秒以内にコールの 93 % が応答されることになります。これは、入力セクションで要求された必要な値である 90 % を超えています。 エージェントが 1 人少ない場合（90 ではなく 89）、SLG 90 % は満たされなかったことになります。
この結果は、コールの内 7 % は SLG 30 秒を過ぎてから応答されることも示しています。 また、コールの 31.7 % がキューに入れられ、一部のキューは 30 秒未満、その他はそれよりも長くキューに入ることになります。 キューに入っているコールの平均キュー時間は 20 秒です。
コールの 31.7 % がキューに入れられた場合、図7-3 の出力に示されているように、68.3 % のコールがキュー内で遅延することなく即時に応答されます。
この基本例では、Unified IP IVR は、応答可能なエージェントがいない場合にコールをキューに入れるキュー マネージャとして使用されています。 カルキュレータは、キューに入っているコールのパーセントおよび数（31.7 %、つまり 627 コール）および平均キュー時間（20 秒）を示しています。
Erlang-C の計算のこれら 2 つの出力は、カルキュレータに内蔵されている Erlang-B 関数の入力として使用され、キューイングに必要な IVR ポートの数（この例では 10 ポート）が計算されます。
同様に、カルキュレータは Erlang-B を使用して、コール負荷（応答されたコール）およびエージェントが応答できないときにキューイングする必要があるコールに基づき、必要な音声ゲートウェイ ポート（PSTN トランク）の数を計算します。
この総トラフィック負荷以上を伝搬するのに必要な総トランク数は 103 トランクです。
この計算には、すべてのコールを応答可能なエージェントに送る前に、最初に IVR での処理を要求するコール シナリオで必要となる可能性のあるトランクは含まれていません。 このようなシナリオについては、次の例で検討します。
コール処理の例
この例は、上記のセクションの基本例に基づいています。 ここでも、コール センターに着信するすべての着信コールは、PSTN から音声ゲートウェイに提供され、コールはコール処理（最初のグリーティング、プロンプトとコレクトによるアカウント情報の収集など）のために即時に Unified IP IVR にルーティングされた後、エージェントが応答可能である場合はそのエージェントに送られます。 応答可能なエージェントがいない場合、コールはエージェントが応答可能になるまでキューに入れられます。
すべてのコールを Unified IP IVR に送った場合は、コール処理による保持時間の間、PSTN トランクがさらに長く保持されることになります。 キューに入れられているコールに必要なポート以外に、この余分な負荷を伝搬するために、さらに多くの Unified IP IVR ポートが要求されます。
エージェントに与えられるトラフィックの負荷（コールの数、通話時間、およびサービス レベル）は変化していないと想定されるため、この例のコール処理（プロンプトとコレクト）は必要なエージェントの数に影響を与えるようには見えません。 実際に、発信者を識別するための情報入力フォームの収集などのコール処理を、CTI ポップ画面を使用するエージェントに追加すると、発信者がエージェントで費やす平均時間を短縮して貴重なリソースを節約し、適切なエージェントのより正確な選択やルーティングを提供して、顧客サービスの向上をもたらします。
図7-4 に、15 秒のコール処理を使用してその他の入力はすべて同じにした場合、キューイングのための既存の 10 のポート以外に、PSTN トランクの数（112）および Unified IP IVR ポートの数（16）が必要であることを示します。
アフターコール ワーク時間（ラップアップ時間）の例
上記の例を使用して、各コール後に平均 45 秒の作業時間（ラップアップ時間）を追加します。 この場合は、Unified CC Resource Calculator を使用して、同じトラフィック負荷を処理する場合に必要となるエージェント数を決定できます（図7-5 を参照）。
アフターコール ワーク時間（ラップアップ時間）は、発信者が電話を切った後に始まるため、トランクおよび Unified IP IVR リソースは影響を受けず同じままで、他のすべての入力も同じままであると想定します。 SLG およびトラフィック負荷も同じままであると想定すると、コール負荷に応答し、エージェントがラップアップ モードにある時間を償うためだけに追加のエージェントが必要となります。
トランクおよび IVR ポートは実質的には同じままですが、例外として追加のトランクが 1 つあります（112 ではなく 113）。 このわずかな増加は、ラップアップ時間によるものではなく、ラップアップ時間のために必要な 116 のエージェントに対する計算の丸めによって、SLG がわずかに変化したことの（93 % ではなく 92 %）副次効果によるものです。
アウトバウンド コール センターのエージェント、IVR ポート、ダイヤラ ポート、およびゲートウェイまたはトランクのサイジング
このセクションのコール センターの例では、さまざまなシナリオにおけるアウトバウンド Unified CC Resource Calculator の使用方法について、アウトバンド コール センターに要求されたリソースに対する影響とともに説明します。 このセクションの最初の例は、基本的なアウトバウンド コール キャンペーンです。すべてのコールはシステムによって（IP ダイヤラ ポートおよびプリディクティブ ダイヤリング経由で）自動的にダイヤルされ、音声ゲートウェイに提供されます。 コールは、コール タイプまたはコール処理に基づいて処理されます。 応答されなかったコール（ビジー、無効番号、および無応答時間）は、システムで自動的に検出されます。 Answering Machine コールは、IVR または処理のためのエージェントのいずれかに送信されます。 人が応答したコールは、処理のための IVR またはエージェントのいずれかに送信されます（これらのコールはエージェントに送信される前に簡単なメッセージを送るため IVR に送信されることもあります）。
アウトバウンド Unified CC Resource Calculator では、アウトバウンド サービスのレベル（2 秒以内に 99 % のコールに応答など）を指定できます。 米国では、顧客が応答したコールを未処理のままにする（放棄する、またはシステムによる応答がない）と法律違反になるため、エージェントの代わりにコールを処理する IVR またはメッセージ アナウンスメントが存在する必要があります。 このような追加の IVR ポートも、このアウトバウンド カルキュレータを使用して計算されます。 IVR またはメッセージ アナウンスメントが提供されない国では、この出力を無視できます（図7-6の IVR message を参照してください）。
図7-7は、アウトバウンド コール キャンペーンがアウトバンド エージェントなしで、すべて IVR（IVR コール キャンペーン）によって処理される場合を示します。 このカルキュレータの使用方法および入出力フィールドの定義の詳細については、次の URL の Unified CC Resource Calculator のマニュアルを参照してください。
http://tools.cisco.com/partner/ipccal/index.htm
図7-7 純粋 IVR（エージェントなし）アウトバウンド コールのキャンペーン例
エージェントの人員計画における考慮事項
エージェント要件を計算する場合は、次の調整を行って、エージェントを非生産的または応答不可状態にするすべての活動や状況を考慮する必要があります。
エージェント リソースの縮小は、勤務時間中のエージェントがコールを処理できない場合に行われます。具体的には、休憩、ミーティング、訓練、電話を使用しない作業、予定にない不在、スケジュールに従わない、一般的な非生産的時間などがここに含まれます。
この係数はさまざまに変化するため、コール センターごとに計算する必要があります。 ほとんどのコール センターでは、このパーセンテージは 20 ～ 35 % の範囲になります。
この数は、特定のコール負荷（BHCA）およびサービス レベルに対する Erlang-C の結果に基づいています。
この係数を計算するには、Erlang-C で必要となるエージェントの数を、生産的なエージェントの割合（または 1 から縮小率を引いたもの）で割ります。 たとえば、Erlang-C で 100 のエージェントが必要であり縮小が 25 % の場合は、100/.75 となり、配置要件は 134 エージェントとなります。
コール センター設計時の考慮事項
コール センターのリソース サイジングを行う場合は、次の設計要素を考慮します。
• さまざまな最頻時の期間（最頻時）で必要となるリソースを計算します。たとえば、季節ごとの最頻時や毎日の平均最頻時などです。 数多くの企業では最頻時の人員計画を、1 年の内の最も混雑している時間の上位 10 の平均値に基づいて計算しています（季節的な最頻時は除きます）。 小売業のコール センターでは、休暇シーズンなどの季節的な要求に基づいて一時的にスタッフを増員します。 複数の期間計算を実行して、毎日のスタッフ要件を確認します。 いずれの会社でも、1 日または 1 週間の間にさまざまなコール負荷が発生しているため、（さまざまな交代制や配置レベルを使用して）それに応じてエージェントを配置する必要があります。 Customer Relationship Management（CRM; カスタマー リレーション シップ マネジメント）やこれまで蓄積したレポートデータは、プロビジョニング計算を微調整し、サービス レベルを維持または改善する場合に役立ちます。
• IVR ポートおよび PSTN トランクをサイジングする場合は、プロビジョニングを下方に見積るよりも上方に見積ります。 余分なキャパシティを削る（PSTN 回線を接続解除する）コストは、収益の減少、劣悪なサービス、または法律上のリスクよりも大幅に安くなります。 一部の政府機関では、最低限のサービス レベルを満たすことが要求されているため、委託されたコール センターは、特定のサービス レベル契約を満たす必要がある場合があります。
• コール センターが複数のトランク グループでさまざまな着信コール負荷を受信する場合、1 つの大きなトランク グループを使用して同じ負荷を伝搬するには、追加のトランクが必要となります。 Erlang-B カルキュレータを使用すると、「コール処理の例」の場合と同じ方法論に従って、必要なトランクの数を設定できます。 必要なトランクのサイジングは、トランク グループのタイプごとに行う必要があります。
• 今すぐ電話をかけることを要求するコマーシャルを実施するマーケティング キャンペーンについて考慮します。この場合は、短期間にコール負荷が集中する可能性があります。 Erlang トラフィック モデルは、このような短期間のピーク（集中コール）に対応するようには設計されていません。ただし、60 分ではなく、15 分のような短い最頻時の期間を使用し、最も混雑している 15 分間に予想されるコール負荷を入力し、必要なエージェントおよびリソースを計算すると、近似が得られます。 「コール センターの基本例」を使用すると、60 分間のコール負荷が 2000（最頻時の期間）の場合、90 のエージェントと 103 のトランクが必要となります。 期間を 15 分にしてコールを 500（上記のコール負荷の 1/4）にすると、同一の結果が得られます。 ただし、600 のコールが 15 分の期間に着信し、残りの時間に残りの 1400 のコールが着信する場合は、同一のサービス レベル目標以内に 600 のコールに応答するには、106 のエージェントと 123 のトランクが必要となります。 セールス コール センターでは、追加の売上および収益が見込まれる可能性がある場合、エージェントの追加にかかるコストは正当化されます。マーケティング キャンペーンのコマーシャルを 1 時間、1 日、およびさまざまな時間帯を通じて交替させている場合は、特に正当化されます。
• エージェントが不在の場合について考慮します。このような場合はサービス レベルが低下するため、追加のトランクおよび Unified IP IVR キューイング ポートが必要となります。これは、キューでの待機時間が長くなるコールが増えるほど、即時対応されるコールの数が少なくなるからです。
• エージェントの縮小係数に基づいて、エージェントの配置を調整します（「エージェントの人員計画における考慮事項」 で説明されているように、スケジュールおよび配置係数に従います）。
• 成長、予測できない出来事、および負荷の変動を予測します。 Erlang モデルの想定と比較して、トランクおよび IVR キャパシティを増やし、これらのイベント（実生活）の影響に対処します （想定は現実と一致していない場合があります）。 必要な入力を得ることができない場合は、欠落している入力を推測し、3 つのシナリオ（低、中、高）を実行して、ビジネス（セールス、サポート、社内ヘルプ デスク、業界、ビジネス環境など）に対するリスク許容度および影響に基づいて最も優れた出力結果を選択します。 一部の取引業界では、 表7-1 に示されているコール センター メトリックおよび統計情報が発行されています。この統計情報は、
http://www.benchmarkportal.com などの Web サイトから入手できます。 コール センターに関する特定のデータ（既存の CDR レコード、履歴レポートなど）がない場合は、これらの業界の統計情報を使用できます。
|
|
|
|
|---|---|---|
Unified CC Resource Calculator の出力は、要素の中でも、特に IVR ポート数、エージェント数、トランク数、および関連付けられているトラフィック負荷（BHCA）を入力として要求する他の Cisco Configuration and Ordering Tool の入力として使用します。
フィードバック