Cisco IP Contact Center Enterprise Edition ネットワーク デザイン(SRND) Releases 5.0/6.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： コール センターのリソース サイジング
コール センターのリソース サイジング
IP Contact Center に限らずすべてのコール センターの設計では、リソースの適切なサイジングが重要です。この章では、（コールの量および必要なサービス レベルなどのお客様要件に基づいて）必要なコール センターのエージェントの人数、さまざまなコール シナリオ（コール処理、キューイング、セルフ サービス アプリケーションなど）に必要な IP IVR ポート数、PSTN やその他の PBX、TDM IVR など（TDM 発信元）から着信するトラフィックがある場合に必要となる音声ゲートウェイ ポートの数を決定するためのツールおよび方法論について説明します。
この章で説明されている方法論およびツールは、IPCC の配置で各種リソースに適用されている Erlang-B および Erlang-C モデルを使用したトラフィック エンジニアリングの原則に基づいています。IP IVR でのコール処理の影響やエージェントが費やすラップアップ時間の違いなど、さまざまなコール シナリオに対してリソースがどのように影響を受けるのかを示すために、IPCC の配置例を提供します。これらのツールと方法論は、コール センターのリソース サイジングや IP テレフォニーの各種応用における基本手法として一般的に利用されることを意図しています。
コール センターの基本トラフィック用語
コール センターに共通する用語を理解し、その使用においてはあいまいさを排除することが重要となります。コール センターのリソース サイジングに使用されているツールでこれらの用語が不正確に使用されている場合、サイジング結果が不適切になる可能性が生じます。
ここにリストアップした用語は、コール センターの業界でリソース サイジングに使用されている最も一般的な用語です。コール センターのその他の専門用語については、次の URL で定義を参照してください。
http://www.thecallcenterschool.com/glossary.html
（コール センターの用語の定義については、インターネット上のその他のリソースも参考になります。）
この項にリストされている用語以外に、「Cisco IPC Resource Calculator」の項には、シスコ コール センターのサイジング ツールである IPC Resource Calculator の入出力に使用される特定の用語が定義されています。
また、このマニュアルで説明されているコール センターの各種用語および概念についての詳細は、次の URL でオンラインで入手できる IPCC 製品マニュアルを参照してください。
最頻時の期間は、1 時間もしくは必要に応じて 30 分や 15 分などの 1 時間よりも短い時間に設定してサイジングを実施できます。最頻時の期間は、1 日のうちでトラフィックが最も集中する時間の長さを示します。最頻時または最頻時の期間は、日、週、および月によって変動します。週毎の一番の混雑時もあれば季節による一番の混雑時もあります。1 年で一番の混雑時もあります。一般的な方法では、最頻時の平均（1 年で最も混雑している時間の上位 10 の平均）値を使って設計します。ただしこの平均値は、マーケティング キャンペーンや季節の最頻時（祝日のピークなど）に対応するための配置が必要となる場合には、常に適用できるわけではありません。コール センターでは、エージェントの最大人数はピーク期間の数値を使用して決定されますが、1 日のピーク期間以外の配置要件は、コールに応答するエージェントの適切なスケジューリング、および訓練や指導などのオフラインの活動のためのエージェントのスケジューリングを考慮して、一定の時間単位（通常は 1 時間単位）で個別に計算されます。トランクおよび（多くの場合は）IVR ポートに関しては、これらのリソースを毎日追加または削除することは実用的ではないため、ピーク期間に合わせてサイジングされます。一部の小売業では、ピークとなるシーズンだけ増設用のトランクを追加し、ピークがすぎると切り離すこともあります。
最頻時/最頻時の期間の発呼（BHCA; Busy Hour/Interval Call Attempts）
BHCA は、トラフィックのピークとなる時間帯にコール センターで受信または受信を試みたコールの総数です。説明を簡略化するために、音声ゲートウェイに提供されるすべてのコールは、コール センターのリソース（エージェントおよび IP IVR ポート）によって受信され、処理されるものとします。コールは通常 PSTN 経由で受信されますが、コール センターへのコールはヘルプ デスク アプリケーションなどによって内部的に生成することもあります。
サーバは、トラフィック負荷またはコールを処理するリソースです。コール センターには、PSTN トランクおよびゲートウェイ ポート、エージェント、音声メール ポート、IVR ポートなど、数多くのタイプのサーバがあります。
通話時間とは、エージェントが発信者との通話に費やす時間のことです。この時間には、エージェントが発信者を保留にしている時間、および相談のための打ち合わせ時間が含まれています。
ラップアップ時間とは、コールの終了後（発信者がエージェントとの通話を終了し、電話を切った後）、エージェントがコールを「ラップアップする」ために必要とする時間のことです。エージェントはこの時間に、データベースの更新、コールのメモ記録などのタスク、またはエージェントが別のコールに応答できるようになるまでの間に実行するその他の活動を行います。この概念を表す IPCC 用語は「アフターコール ワーク時間」です。
平均処理時間（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 トランク数と IP IVR のポート数が決定されます。IPCC 製品におけるサービス レベルのより詳細な定義については、IPCC 用語集を参照してください。この用語集は、次の URL からオンラインで入手できます。
すべてのエージェントが他の発信者と通話中であるかまたは対応できない場合（ラップアップ中であるために）、いずれかのエージェントが応答可能になるまで後続の発信者をキューに入れておく必要があります。キューに入れられたコールの比率およびキュー内で経過する平均時間は、目標設定したサービス レベルおよびエージェントの配置状況によって決定されます。シスコの IPCC ソリューションでは、IP IVR を使用して発信者をキューに入れ、アナウンスを流します。IVR は、全コールの初期処理（コール処理、DTMF 入力や課金番号などのプロンプトとコレクト、またはその他の情報収集）、および発信者がエージェントと通話することなく受けることができるセルフサービス アプリケーション（銀行の勘定残高や航空機の発着時間などの情報取得）に使用することもできます。これらの各シナリオでは、さまざまなアプリケーションを処理するために必要となる IP IVR のポート数が異なります。これは、それぞれの平均処理時間およびコールの負荷が異なっているためです。これらの各アプリケーションで必要となるトランクまたはゲートウェイ ポートの数も、それに応じて異なります（「コール センターのエージェント、IVR ポート、トランクのサイジング」の項、たとえば、必要となるトランクおよびゲートウェイ ポートの数の計算方法についての項を参照してください）。
コール センターのリソースとコールのタイムライン
この章では、次に示すコール センターの主要なリソースのサイジングについて説明します。
インバウンド コール センターの処理の構造は、そこで使用される各種リソースとそれらのリソースで費やされる時間に関係があるので、最初にその構造を把握しておくことが後ほどの理解に役立ちます。図4-1 に、使用される主要なリソースとそこで費やされる占有状態（保持時間と処理時間）について示します。
コールが即時に応答されない場合は、リングの遅延時間（ネットワーク リング）を含める必要があります。この遅延は平均すると数秒ですが、トランクの平均処理時間に追加する必要があります。
設計ツールとしての Erlang カルキュレータ
電話のシステムおよびリソースのサイジングに利用できるトラフィック モデルは数多く存在します。正しいモデルの選択は、次の 3 つの要素に依存しています。
この文書の目的であるコール センターのリソース サイジング用に一般的に使用されているのは Erlang-B および Erlang-C という 2 つのトラフィック モデルです。インターネットで調べると、この他のさまざまなモデルについての詳細な解説を参照できます（「traffic engineering（トラフィック エンジニアリング）」で検索してください）。
Erlang カルキュレータは、次の質問に答える場合に役立つよう設計されています。
これらの基本的な質問に答えるには、少なくとも、これらのカルキュレータの入力として必要になる次の情報を準備しておく必要があります。
•
Busy Hour Call Attempts（BHCA; 最頻時発呼数）
• リソースごとの Average Handle Time（AHT; 平均処理時間）
• サービス レベル（ x 秒以内に応答されるコールの割合）
• PSTN トランクおよび IP IVR ポート用として必要となるサービス グレード、またはブロック率
これ以降、この章では簡単な用語を使用して Erlang-B と Erlang-C トラフィック モデルの違いについて説明します。また、コール センターの特定リソース（エージェント、ゲートウェイ ポート、および IP IVR ポート）のサイジングに使用するモデルを示します。さまざまな Web サイトでコール センターのサイジング ツールが無料で提供されていますが（機能が豊富なバージョンを購入用として提供しているサイトもあります）、これらのツールはすべて基本トラフィック モデルである Erlang-B および Erlang-C を使用しています。シスコは、特定のベンダー製品を支持していません。お客様はそれぞれの必要に応じてツールをお選びください。いずれのツールでも、要求される入力項目および使用される方法論は、ツールに関係なく同じになります。
シスコは、Cisco IPC Resource Calculator という独自のテレフォニー サイジング ツールを開発しました。ここでの検討に使用する最初のバージョンは、コール センターのリソース サイジングを目的として設計されています。この章の後半には、Cisco IPC Resource Calculator の使用方法を示すために、いくつかの基本的な例が示されています。入力フィールドの一部（すべてではありません）が既知または使用可能である場合のこのツールの使用方法を示す追加の例も含まれています。
Cisco IPC Resource Calculator について説明する前に、Cisco IPC Resource Calculator を使用できない読者、または Cisco 以外の Erlang ツールを使用する読者のために、次の 2 つの項で一般的な Erlang モデルと（インターネットから入手可能な）Erlang ツールの入出力項目について簡単に説明します。
Erlang-C
Erlang-C モデルは、コールをエージェントに送る前にいったんキューに送るコール センター内のエージェントをサイジングする場合に使用します。このモデルは次のような条件を前提とします。
• すべてのエージェントがビジーの場合、新規のコールはキューに入れられ、ブロックされない。
• 必要な遅延またはサービス レベル（指定された秒数以内で応答されるコールの割合で記述します）
Erlang-C モデルの出力には、必要なエージェントの人数、応答可能なエージェントがいない場合に遅延されたコールやキューに入れられたコールの比率、およびこれらのコールの平均キュー時間がリストされます。
Erlang-B
Erlang-B モデルは、PSTN トランク、ゲートウェイ ポート、または IP IVR ポートをサイジングする場合に使用します。このモデルは次のような条件を前提とします。
• すべてのトランクおよびポートが占有されている場合、新規のコールは失われるかブロックされ（ビジー トーンを受信）、キューには入れられない。
Erlang B モデルの入出力は、次の 3 つの要素で構成されています。これらの要素のいずれか 2 つは既知である必要がありますが、3 つ目の要素はこのモデルで計算されます。
• Busy Hour Traffic（BHT; 最頻時トラフィック）。すなわち最も混雑している運用時間におけるコール トラフィックの時間（単位は Erlang）。BHT は、最頻時のコールの数（BHCA）と Average Handle Time（AHT; 平均処理時間）の積で表されます。
Cisco IPC Resource Calculator
図4-2 に、現在の Cisco IP Communications（IPC）Resource Calculator のスナップショット、入力と出力のためのフィールドと定義とその使用方法、およびこれらの解釈方法を示します。
シスコは頻繁に IPC Resource Calculators の機能強化を行っており、最新バージョンは次の URL から入手できます。
http://tools.cisco.com/partner/ipccal/index.htm
Cisco IPC Resource Calculators は、シスコの社員およびシスコ パートナーが使用できます。これらのツールは、業界の Erlang トラフィック モデルに基づいています。Web で入手できるその他の Erlang トラフィック カルキュレータも、コンタクト センターの各種リソース サイジングに使用できます。
図4-2 Cisco IPC Resource Calculator
IPC Resource Calculator の入力フィールド（指定する必要がある項目）
Cisco IPC 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 % に到達すると必ず発生します。
IPC Resource Calculator の出力フィールド（算出される項目）
IPC 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 ポート、トランクのサイジング
この項のコール センターの例では、さまざまなシナリオにおける IPC Resource Calculator の使用方法について、要求されたリソースに対する影響とともに説明します。最初の例は、基本的なコール フローです。コール センターに着信するすべての着信コールは、PSTN から音声ゲートウェイに提供されます。コールは、エージェントが応答可能である場合、そのエージェントに直接ルーティングされます。応答可能でない場合、エージェントが応答可能になるまでコールはキューに入れられます。
コール センターの基本例
この例は、後続のこの章のすべての例の基本となります。この基本例における 3 つのリソース（エージェント、IVR ポート、および PSTN トランク）を強調した出力結果について簡単に説明した後、コール処理およびエージェントのラップアップ時間などのさまざまなシナリオを追加して、この例を後続のシナリオの基礎とし、各種リソースがさまざまなシナリオによってどのような影響を受けるかについて説明します。
• 音声ゲートウェイへの PSTN からコール センターへの BHCA（60 分間）の合計 = 2,000。
• 必要なサービス レベルの目標（SLG）= 30 秒以内にコールの 90 % が応答される。
• コールの平均通話時間（エージェントの通話時間）= 150 秒（2 分 30 秒）。
• アフターコール ワーク時間なし（エージェントのラップアップ時間 = 0 秒）。
• コール処理（プロンプトとコレクト）なし、が最初に実装されている。すべてのコールは、応答可能なエージェントにルーティングされるか、またはエージェントが応答可能になるまでキューに入れられます。
• 放棄されるまでの待ち時間（許容時間）= 150 秒（2 分 30 秒）。
• 音声ゲートウェイ上の PSTN トランクの必要なサービス グレード（ブロック率）= 1 %。
上記のデータを入力フィールドに入力し、カルキュレータの下部にある [Submit] ボタンを押すと、図4-3 に示されている結果が出力されます。
出力には、PSTN から試行された合計 2000 のコールの内、音声ゲートウェイによって完了したコールは 1952 であることが示されています。これは、PSTN プロバイダーに 1 % のブロック率のプロビジョニングを要求し、その結果、合計で 2000 のコールの内 20 のコール（1 %）がブロックされ、ビジー トーンを受信したためです。
着席しているエージェントが 90 であるという結果は、IPC Resource Calculator に内蔵されている Erlang-C 関数を使用して決定された値です。このリソース（エージェント）へのコールはキューに入れられます。
エージェントが 90 の場合、計算によるサービス レベルは、30 秒以内にコールの 93 % が応答されることになります。これは、入力セクションで要求された必要な値である 90 % を超えています。エージェントが 1 人少ない場合（90 ではなく 89）、SLG 90 % は満たされなかったことになります。
この結果は、コールの内 7 % は SLG 30 秒を過ぎてから応答されることも示しています。また、コールの 31.7 % がキューに入れられ、一部のキューは 30 秒未満、その他はそれよりも長くキューに入ることになります。キューに入っているコールの平均キュー時間は 20 秒です。
コールの 31.7 % がキューに入れられた場合、図4-3 の出力に示されているように、68.3 % のコールがキュー内で遅延することなく即時に応答されます。
この基本例では、IP IVR は、応答可能なエージェントがいない場合にコールをキューに入れるキュー マネージャとして使用されています。カルキュレータは、キューに入っているコールのパーセントおよび数（31.7 %、つまり 627 コール）および平均キュー時間（20 秒）を示しています。
Erlang-C の計算のこれら 2 つの出力は、カルキュレータに内蔵されている Erlang-B 関数の入力として使用され、キューイングに必要な IVR ポートおよびそれに対応する必要な PSTN トランクの数が計算されます。ここでは、コールに対する応答またはサービスに使用可能なトランクまたは IVR ポートがない場合、コールはビジー信号を受信する（失われる）ため、Erlang-B 関数が使用されています。
次のトラフィックの負荷は、カルキュレータの出力から得られるキューイングのための IP IVR ポートの必要数に影響を与えます。
• キューに入っている（627 がキューに入っています）コールが与えるトラフィック負荷。コールに即時に応答可能なエージェントが存在していない場合の平均キュー時間は 20 秒です。この負荷は、キューイングに 10 の IVR ポートが必要であることを示しています。
• 着信トラフィックが与える負荷（応答されたコールは 1952）。全コールについてのエージェントの平均通話時間は 150 秒です。
• キューに入っている（31.7 % がキューに入っています）コールが与えるトラフィック負荷。コールに即時に応答可能なエージェントが存在していない場合の平均キュー時間は 20 秒です。
この総トラフィック負荷以上を伝搬するのに必要な総トランク数は 103 トランクです。
この計算には、すべてのコールを応答可能なエージェントに送る前に、最初に IVR での処理を要求するコール シナリオで必要となる可能性のあるトランクは含まれていません。このようなシナリオについては、次の例で検討します。
コール処理の例
この例は、上記の項の基本例に基づいています。ここでも、コール センターに着信するすべての着信コールは、PSTN から音声ゲートウェイに提供され、コールはコール処理（最初のグリーティング、アカウント情報の収集など）のために即時に IP IVR にルーティングされた後、エージェントが応答可能である場合はそのエージェントに送られます。応答可能なエージェントがいない場合、コールはエージェントが応答可能になるまでキューに入れられます。
すべてのコールを IP IVR に送った場合は、コール処理による保持時間の間、PSTN トランクがさらに長く保持されることになります。キューに入れられているコールに必要なポート以外に、この余分な負荷を伝搬するために、さらに多くの IP IVR ポートが要求されます。
エージェントに与えられるトラフィックの負荷（コールの数、通話時間、およびサービス レベル）は変化していないため、コール処理（プロンプトとコレクト）は必要なエージェントの数に影響を与えません。
図4-4 に、15 秒のコール処理を使用してその他の入力はすべて同じにした場合、キューイングのための既存の 10 のポート以外に、PSTN トランクの数（112）および IP IVR ポートの数（16）が必要であることを示します。
アフターコール ワーク時間（ラップアップ時間）の例
上記の例を使用して、エージェントが各コール後の作業時間（ラップアップ時間）に費やす時間は平均 45 秒であるという想定を追加します。この場合は、IPC Resource Calculator を使用して、同じトラフィック負荷を処理する場合に必要となるエージェント数を決定できます（図4-5 を参照）。
アフターコール ワーク時間（ラップアップ時間）は、発信者が電話を切った後に始まるため、トランクおよび IP IVR リソースは影響を受けず、同じままです。SLG およびトラフィック負荷も同じままであると想定すると、コール負荷に応答し、エージェントがラップアップ モードにある時間を償うためだけに追加のエージェントが必要となります。
トランクおよび IVR ポートは実質的には同じままですが、例外として追加のトランクが 1 つあります（112 ではなく 113）。このわずかな増加は、ラップアップ時間によるものではなく、ラップアップ時間のために必要な 116 のエージェントに対する計算の丸めによって、SLG がわずかに変化したことの（93 % ではなく 92 %）副次効果によるものです。
セルフサービス IVR アプリケーションを使用したコール センターのサイジング
セルフサービス アプリケーションでは、コールが IVR（IP IVR または Customer Voice Portal（CVP）、以前は ISN と呼ばれていました）にルーティングされます。また、このアプリケーションでは、さまざまなデータベースの情報にアクセスするための選択項目で構成されているメニューがコールに提供されます。コールは IVR でサービスを受けますが、エージェントによる応答はありません。トランザクションの最後に発信者が電話を切るため、エージェントと通話する必要はありません。例として、銀行の勘定残高やトランザクションへのアクセス、航空機の到着や出発情報、ドライブの道案内などのメニュー サービスがあります。
このようなセルフサービス アプリケーションのコール負荷および IVR 平均処理時間は、エージェントに送られるコール負荷とは異なります。この場合は、PSTN トランク（音声ゲートウェイ ポート）および IVR ポートだけが必要であり、追加エージェントは不要です。
次の例に示されているように、このようなセルフサービス アプリケーションの場合、必要な追加の PSTN トランクおよび IVR ポートの計算には、スタンドアロンの Erlang-B 計算が必要となります。したがって、上記の例で説明し、次の例に示されているように、エージェントに送られるコールに対してコール センターで必要となるその他の要件に、これらのトランクおよび IVR ポートを追加できます。
IVR セルフサービス アプリケーションでのコール センターの例
この例では、コール センターは最頻時に 18,000 のコールを受信し、これらのコールの一部（20 %）は、エージェントに転送されることなく IVR でセルフサービス処理されます。これらのコールは、平均で約 60 秒継続してから、それぞれのトランザクションを完了して電話を切ります。
別の 20 % は、（発信者の電話番号、ダイヤルされた番号、またはその他の自動識別情報に基づいて）「高優先順位」発信者として識別され、IVR でコール処理されることなく即時に専用のエージェント グループにルーティングされ、95 % という高いコールのサービス レベル目標で 10 秒以内に応答されます。
残りの 60 % は標準コールで、エージェントに転送される前に IVR でメニュー（コール処理、プロンプトとコレクト）が提供されます。これらのコールの SLG は 90 % で、30 秒以内に応答されます。平均のコール処理は約 3 分 9 秒（171 秒）で、平均の通話時間は 5 分（300 秒）です。
要約すると、このコール センターに着信する 3 つのトラフィック負荷（コール タイプ）は、次のコールから構成されています。
• 高優先順位コール（IVR での遅延がなく、直接エージェントに転送される）は、次のとおりです。
エージェントが応答可能である場合は、即時に転送され、IVR コール処理は実行されない。
SGL = コールの 95 % が 10 秒以内に応答される。
SGL = コールの 90 % が 30 秒以内に応答される。
高優先順位の標準コールでは、コールに即時に応答できるエージェントがいない場合、そのコールは IVR でキューに入れられて待機が必要となる場合があります。
これら 3 つのタイプのコールそれぞれについて、次のように必要なリソースを計算できます。
エージェントが不要または関係しないセルフサービス アプリケーションの場合にだけ、Cisco IP IVR Stand-Alone Calculator（図4-6 に示されています）を使用します。このツールでは、Erlang-B を使用して必要なトランクおよび IP IVR ポートの数が計算されます。
• Busy Hour Traffic（BHT; 最頻時トラフィック）=（3600 コール ∗ 60 秒/3600）= 60 Erlang。
カルキュレータの [Self Service] というタイトルの最初の列にこれらの値を挿入すると、図4-6 に示されているように、次の結果が得られます。
これらの PSTN トランクおよび IVR ポートは、優先順位コール（20 %）、およびエージェントに転送される前のキューイングやコール処理に PSTN トランクと IVR ポートを要求する標準コール（60 %）で必要となる可能性のあるものに追加されます。残りの列は、CVP の場合のように、まとめてプールされなかった複数のトランクおよび IVR グループがある（複数のセルフサービス アプリケーション）か、または採用されている IVR がエッジ（ローカルの PSTN 着信ゲートウェイと接続しているリモート ブランチ）にあるコールをキューに入れることができる場合に使用できます。
（注） Web 上には、無料で入手できる Erlang-B カルキュレータが数多くあります（Erlang-B で検索してください）。
高優先順位コール（直接エージェントに転送され、IVR コール処理されません）
• エージェントが応答可能である場合は、即時に転送され、IVR コール処理は実行されない。
• SGL = コールの 95 % が 10 秒以内に応答される。
これらのパラメータを IPC Resource Calculator に挿入すると、次の結果が得られます（図4-7 を参照）。
• SGL = コールの 90 % が 30 秒以内に応答される。
これらのパラメータを IPC Resource Calculator に挿入すると、次の結果が得られます（図4-8 を参照）。
このコール センターの例で 3 つのタイプのコールに必要なリソースをすべてサイズ設定したため、この結果を加算して、必要となる各タイプ（エージェント、PSTN トランク、および IVR ポート）のリソースの合計を決定できます。
• 高優先順位コール（IVR を経由せずにエージェントによって応答されるコール）のためのエージェント = 384
• 標準コール（IVR 処理の後、エージェントに転送されるコール）のためのエージェント = 907
• エージェントの合計 = 384 + 907 = 1291
• キューイング用の IVR ポート = 6 + 40 = 46
• IVR ポートの合計 = 75 + 46 + 540 = 661
• PSTN トランクの合計 = 75 + 386 + 1469 = 1930
IP IVR が使用された場合は、サーバ リソースを適切にサイジングするために、Configuration and Ordering Tool にコール処理およびキューイングのためのポートの数を入力する必要があります。Configuration and Ordering Tool には、次の URL からアクセスできます。
http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1844/prod_how_to_order.html
使用されている IVR タイプが CVP（ISN）の場合は、Customer Voice Portal（CVP）のサイジングの詳細について、「ISN コンポーネントのサイジング」 の項を参照してください。
ISN コンポーネントのサイジング
Internet Service Node（ISN）のサイジングには、次のコンポーネントが関係しています。
• 「ICM ペリフェラル ゲートウェイ（PG）のサイジング」
ISN サーバのサイジング
『Cisco Internet Service Node Technical Reference』（ http://www.cisco.com で入手できます）によると、共通の 包括的 ISN 配置モデルで配置された ISN Combo Box（ISN Application Server、および同じサーバで提供される ISN Voice Browser）は、300 の 有効な コールをサポートできます。有効なコールとは、（ISN の VXML 制御下の）Cisco IOS ゲートウェイ上の IVR でコール処理またはキューイングされるコール、または ISN によってエージェントに転送され、まだ ISN によってモニタおよび制御されているコールのことです。後者のコールでは、たとえば、ISN が IP 転送方式を使用してコールをエージェントにルーティングしている場合、ISN はそのコールをまだモニタしているため、そのコールは有効なコールとみなされます。一方、Outpulse または IN Transfer を使用してコールをエージェントにルーティングしている場合、ISN はすでにそのコールを制御していないため、そのコールは有効なコールとは みなされません 。また、ISN（Voice Browser）による制御または関与を受けずに直接エージェントに転送されるコールも、これらのコールがエージェントを見つけることができ、その後 ISN によって処理されない限り、有効なコールとはみなされません。
（注） この項では、上記の「IVR セルフサービス アプリケーションでのコール センターの例」 の場合と同じ例を使用していますが、明解にするために、その例と同じパラメータを繰り返し使用しています。
コール センターで 18,000 コールの BHCA を受信する例について考慮します。これらのコールの 20 % が、エージェントに転送されずに IVR でセルフサービスを受けると想定します。これらのコールは、平均で約 60 秒継続してから、それぞれのトランザクションを完了して電話を切ります。
また、着信コールのうち別の 20 % は、（発信者の電話番号、ダイヤルされた番号、またはその他の自動識別情報に基づいて）高優先順位発信者であると識別され、ISN が関与することなく（コール処理されずに）発信者の 95 % が 10 秒以内に応答される Service Level Goal（SLG; サービス レベル目標）で、即時に専用のエージェント グループにルーティングされると想定します。ただし、これらのコールのわずかのパーセンテージは、即時にエージェントに到達できないため、ISN によるキューイングの対象とする必要があります。
残りの 60 % は標準コールであり、エージェントに転送される前に、30 秒以内に 90 % が応答される SLG で ISN によって IVR 処理されます。平均のコール処理は 3 分 9 秒（171 秒）で、平均の通話時間は 5 分（300 秒）です。
このコール センターに着信するトラフィック負荷（コール タイプ）は、次のとおりです。
• 高優先順位コール（エージェントに直接転送されます）は、次のとおりです。
エージェントが応答可能である場合は、即時にエージェントに転送され、IVR コール処理は実行されない。
SLG = 発信者の 95 % が 10 秒以内に応答される。
エージェントが応答可能でない場合、ISN はコールをキューに入れる必要がある。
SLG = 発信者の 90 % が 30 秒以内に応答される。
後者の 2 つのコール タイプ（高優先順位コールおよび標準コール）では、コールに応答できるエージェントがいない場合、そのコールは IVR（ISN）でキューに入れられて待機する必要があることがあります。
「コール センターのリソース サイジング」 の章で説明されているツールおよび方法論を使用して、これらのコール タイプごとに必要な IVR ポートおよびエージェントの数を計算すると、次の結果が得られます。
• IVR セルフサービス コール（Cisco IP IVR スタンドアロン Erlang-B カルキュレータを使用）は、次のとおりです。
• ISN による関与またはコール処理を受けずに、エージェントに直接転送される高優先順位コール（Cisco IPC Resource Calculator を使用）は、次のとおりです。
–コールが即時にエージェントに到達できない場合のキューイング用に 6 ポート
• 標準コール（Cisco IPC Resource Calculator を使用）は、次のとおりです。
3 つのタイプのコールに必要なリソースをすべて計算したため、その結果を合計して、ISN を適切なサイズに設定する場合に必要となる有効なコールの数を決定できます。有効なコールとは、ISN によって IVR コール処理またはキューイング処理を受けるコール、または ISN がエージェントに転送したが ISN がまだモニタする必要のあるコールのことです。ここでの例では、エージェントはすべて IPCC エージェントです。したがって、ISN がコールをエージェントにルーティングした場合、ISN は IP 転送ルーティング方式を使用します。つまり、ISN は継続してそれらのコールをモニタします。
• IVR に必要なポート数 =（75 + 540）= 615
• キューイングに必要なポート数 =（6 + 40）= 46
• PSTN トランク数（VXML あり）= 75 + 1469 = 1544
• PSTN トランク数（合計）= 75 + 1469 + 386 = 1930
したがって、ISN で結合されている IVR およびキューイングの負荷は、661 の同時コールになります。この場合、IVR キューイング処理は、物理的には Cisco IOS ゲートウェイで実行されます（ISN の 包括的 配置モデルを使用）。
ISN によって IPCC エージェントに転送されたコール（ISN によるモニタが必要）の数には、（ISN がすべての標準コールをエージェントに送る前にこれらのコールを処理したため）標準コールに必要な 907 のエージェントによって処理される同時コール、および（最初にエージェントに到達できなかったため）ISN によってキューに入れられた後にエージェントに転送されるわずかな高優先順位コールの合計が含まれています。これらの高優先順位コールに必要な余分の量は複雑な計算になりますが、ほとんどの場合、単に高優先順位コールに必要な ISN キュー ポートの数を 2 倍にすることによって近似できます。この場合は、次のようになります。
したがって、この例では、エージェントに転送されて ISN によってモニタされるコールの数は、次のようになります。
したがって、ISN のサイジングを目的とした場合、同時に 有効なコール の総数は、次のようになります。
661（IVR およびキューイング）+ 921（転送）= 1582 の有効コール
各 ISN Combo Box は 300 の有効なコールをサポートしているため、この例の場合は、次の数が必要となります。
冗長性を確保するために、さらに ISN Combo Box を増やすことをお勧めします。最終的に、合計は次のようになります。
図4-9 に、上記の ISN サイジングの例を示します（簡略化するために、Cisco IOS ゲートキーパーおよび Cisco CallManager は表示されていません）。
ISN のサイジングのライセンス
ISN ソフトウェア ライセンス
ISN Application Server ソフトウェア ライセンスおよび ISN Voice Browser ソフトウェア ライセンスは、ISN Combo Box ごとに必要です。したがって、図4-9 のこの例の配置には、7 つの ISN Application Server ソフトウェア ライセンスおよび 7 つの ISN Voice Browser ソフトウェア ラインセンスが必要となります。
ISN セッション ライセンス
ISN ソフトウェア ライセンス以外に、次のセッション ライセンスも必要です。
ISN Application Server セッション ライセンスは、ISN による IVR およびキューイング処理を必要とする同時コールの最大数分必要となります。この例では、661 の ISN Application Server セッション ライセンスが必要です。
ISN Voice Browser セッション ライセンスは、IVR とキューイング処理される同時コールの最大数、および ISN によってモニタされるエージェントに転送されるコールの数の合計分必要となります。つまり、ISN Voice Browser セッション ライセンスは、以前定義した有効なコールの数だけ必要となります。この例では、1582 の ISN Voice Browser セッション ライセンスが必要です。
ISN キャパシティのサイジングのための代替簡略化方法
この項では、これまでの項で使用されている厳密な ISN サイジング計算の代替となる、高速で簡略化された計算方法について説明します。この簡略化された方法は、エージェントの数、および必要となる IVR やキューイング セッションの数が既知である場合に使用できます。この簡略化された方法では、エージェントに送られるすべてのコールが ISN によってモニタされるワーストケース シナリオを想定しています。
図4-9 の例では、IVR およびキューイングに 661 のセッションが必要で、1291 のエージェントがいることを想定しています。ワーストケース シナリオでは、単純に IVR およびキューイング セッションの数をエージェントの数に加えると、有効なコール数の見積りが 1952 になります。この有効なコールの数には、7 つの ISN Combo Box と冗長性のための追加分が必要となるため、ISN Combo Box は 8 つになります。したがって、8 つの ISN Application Server ソフトウェア ライセンスおよび 8 つの ISN Voice Browser ソフトウェア ライセンスが必要となります。
この方法では、（661 の IVR およびキューイング セッションに）661 の ISN Application Server セッション ライセンスが必要であると見積られますが、ISN Voice Browser セッション ライセンスの数は（661 + 1291）= 1952 となります。この見積りは、より厳密なサイジング計算から得られる数よりも大きくなっていますが、見積りとしては妥当であり、慎重な見積りです。
ただし、エージェントおよび IVR ポートの数の見積りが実際に必要な数（計算による方法）と比較してかなり大きい場合は、ライセンスおよびサーバが過大になり、見積り価格が高くなります。エージェントの数が過大に見積られる可能性がある理由としては、このカウントには最頻時に着席している必要があるエージェントの数ではなく、雇用されているすべてのエージェントが含まれていることが挙げられます（必要なエージェント数の見積りの詳細については、「エージェントの人員計画における考慮事項」を参照してください）。
Cisco IOS ゲートウェイのサイジング
Cisco IOS ゲートウェイで必要な PSTN 入力ポートの数は、すべての IVR およびキューイング ポートの数にエージェントの数を加えることによって見積ることができます。図4-9 の例では、1952 のゲートウェイ入力ポートが必要です。
ISN 包括的配置モデルを使用する場合、Cisco IOS ゲートウェイでは、単に PSTN ポートが終了するだけではありません。このゲートウェイは VXML ブラウザとしても動作し、ISN の制御下でプロンプトとコレクト、およびキューイング処理を実行します。VXML および PSTN 機能は、同一の Cisco IOS ゲートウェイまたは個別のゲートウェイに常駐できます。VXML パフォーマンスを得るための Cisco IOS ゲートウェイのガイダンスについては、Cisco Systems Engineer（SE）にお問い合せください。
ICM ペリフェラル ゲートウェイ（PG）のサイジング
各 ISN Application Server は、ICM VRU PIM のインスタンスを要求します。したがって、7 つの ISN Combo Box という見積りに基づいて、この例での配置では、ICM VRU PIM のインスタンスが 7 つ必要になります。PIM ライセンスには明示的な料金はなく、このライセンスは ISN Application Server ソフトウェア ライセンスに含まれています。
VRU PG および PIM キャパシティの詳細については、「IPCC のコンポーネントとサーバのサイジング」の章を参照してください。
プロンプト メディア サーバのサイジング
プロンプトの .wav ファイルを保持するために十分なゲートウェイ メモリがある場合は、（ISN の VXML 制御下で）Cisco IOS ゲートウェイによって再生される、録音ずみのプロンプトをゲートウェイ フラッシュ メモリに保存できます。ただし、ほとんどの場合、プロンプト ファイルは、プロンプト メディア サーバと呼ばれる独立した Web サーバに保存されます。
必要なプロンプト メディア サーバの数を見積るには、次の方法を使用します。
録音ずみのプロンプトの .wav ファイルは、G.711 帯域幅（約 80 kbps）を使用して Cisco IOS ゲートウェイにプッシュする必要があります。したがって、Cisco IOS ゲートウェイから再生されるプロンプトを受信する各コールには、プロンプト メディア サーバの 80 kbps のメディアが必要となります。
その他に必要な情報には、プロンプト メディア サーバとして動作する Web サーバのメディア供給キャパシティがあります。サーバでサポート可能なプロンプトの最大数を決定するには、メディア サーバのメディア供給キャパシティをプロンプトごとに 80 kbps で割ります。
たとえば、プロンプト メディア サーバのメディア供給キャパシティが 32 Mbps であると想定します。このサーバでは、次の内容がサポートされます。
32 Mbps / 80 kbps = 400 同時プロンプト（メディア サーバごと）
図4-9 の例では、661 のセルフサービス、および IVR とキューイング処理されているコールに対してプロンプト（メディア）を再生する必要があります。このためには、661/400 = 2 プロンプト メディア サーバ（およびフェールオーバーの目的で推奨する 3 番目のプロンプト メディア サーバ）が必要となります。
このサイジング方法は厳密ではありませんが、適度に正確で簡単な方法です。プロンプトの一部をゲートウェイ メモリにキャッシュできる場合は、必要なプロンプト メディア サーバの数を減らすことができることもあります。
エージェントの人員計画における考慮事項
エージェント要件を計算する場合は、次の調整を行って、エージェントを非生産的または応答不可状態にするすべての活動や状況を考慮する必要があります。
エージェント リソースの縮小は、勤務時間中のエージェントがコールを処理できない場合に行われます。具体的には、休憩、ミーティング、訓練、電話を使用しない作業、予定にない不在、スケジュールに従わない、一般的な非生産的時間などがここに含まれます。
この係数はさまざまに変化するため、コール センターごとに計算する必要があります。ほとんどのコール センターでは、このパーセンテージは 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 日、およびさまざまな時間帯を通じて交替させている場合は、特に正当化されます。
• エージェントが不在の場合について考慮します。このような場合はサービス レベルが低下するため、追加のトランクおよび IP IVR キューイング ポートが必要となります。これは、コールが増加するとキューで待機している時間が長くなり、コールが減少すると即時に対応できるためです。
• エージェントの縮小係数に基づいて、エージェントの配置を調整します（「エージェントの人員計画における考慮事項」 で説明されているように、スケジュールおよび配置係数に従います）。
• 成長、予測できない出来事、および負荷の変動を予測します。Erlang モデルの想定と比較して、トランクおよび IVR キャパシティを増やし、これらのイベント（実生活）の影響に対処します（想定は現実と一致していない場合があります）。必要な入力を得ることができない場合は、欠落している入力を推測し、3 つのシナリオ（低、中、高）を実行して、ビジネス（セールス、サポート、社内ヘルプ デスク、業界、ビジネス環境など）に対するリスク許容度および影響に基づいて最も優れた出力結果を選択します。一部の商業界では、 表4-1 に示されているコール センター メトリックおよび統計情報が発行されています。この統計情報は、
http://www.benchmarkportal.com などの Web サイトから入手できます。コール センターに関する特定のデータ（既存の CDR レコード、履歴レポートなど）がない場合は、これらの業界の統計情報を使用できます。
|
|
|
|
|---|---|---|
IPC Resource Calculator の出力は、要素の中でも、特に IVR ポート数、エージェント数、トランク数、および関連付けられているトラフィック負荷（BHCA）を入力として要求する他の Cisco Configuration and Ordering Tool の入力として使用します。
フィードバック