Cisco Packaged Contact Center Enterprise レポート ユーザ ガイド リリース 10.0(1)
メトリックを処理するタスク
メトリックを処理するタスク

メトリックを処理するタスク

平均応答時間

平均応答時間(ASA)は、平均応答待機時間(すべての受信タスクが応答されるまでに待った時間の合計)です。 応答待機時間には、遅延時間、キュー時間、および呼び出し時間が含まれます。 ASA はコールがキューに入ると開始し、4 台のエンティティに対して設定されます。

  • Agent(エージェント)
  • コール タイプ
  • スキル グループ(Skill Group)
  • プレシジョン キュー(Precision Queue)

ASA は、時間、分、秒(HH:MM:SS)で報告されます。

エージェントの場合、エージェントによって応答されたコールの合計応答待機時間をエージェントが応答したコール数で分割することによって、ASA は計算されます。 (AnswerWaitTime/CallsAnswered)

コール タイプの場合、コール タイプの合計応答待機時間をコール タイプによって処理されたコール数で分割することによって、ASA は計算されます。 (AnswerWaitTime/CallsHandled)

スキル グループとプレシジョン キューの場合、スキル グループまたはプレシジョン キューで応答されたコールの合計応答待機時間をそのスキル グループまたはプレシジョン キューによって応答されたコール数で分割することによって、ASA は計算されます。 (AnswerWaitTime/CallsAnswered). 次の例を検討してください。

  • コールがスキル グループ X で 30 秒間キューイングされている。
  • コールはその後、スキル グループ Y で 10 秒にキューイングされる。

この場合、合計キュー時間は 40 秒となり、コールがスキル グループ Y で 10 秒間キューイングされただけの場合も、スキル グループ Y の ASA の計算に使用されます。

サービス レベル

サービス レベルは、コールへの応答に関する目標を設定し、評価する際に役立ちます。

指定した間隔内に応答または放棄されたすべてのコールは、その間隔のサービス レベル コールであると見なされます。


(注)  


サービス レベルは、サービス レベル時間内に応答も放棄もされていないコールの影響は受けません。 たとえば、サービス レベルのしきい値内でエラー条件が発生したコールはサービス レベルに影響しません。

サービス レベルの計算では、次の 2 つの設定パラメータが重要です。

  • [サービス レベルのしきい値(Service level threshold)]:コールを処理するための目標として設定する秒数。 特定時間のサービス レベルを計算する場合、Packaged CCE は、その間隔内でサービス レベル イベントが発生したコール数を特定します。 たとえば、目標を 2 分以内のコールの 80% に応答に設定する場合は、サービス レベルのしきい値を 120 秒に設定します。 レポートには、その間隔内でサービス レベル イベントがあった、コールのパーセンテージが表示されます。
  • [サービス レベル タイプ(Service level type)]:サービス レベルのしきい値よりも前に放棄されたコールがサービス レベル計算に与える影響が決まります。 サービス レベル タイプには次の 3 つのオプションがあります。
    • [無視する(Ignore)]:放棄されたコールはサービス レベルの計算から除外されます。
    • [マイナスの影響(Negative impact)]:サービス レベルしきい値内で放棄されたコールは処理されるコールとしてカウントされません。
    • [プラスの影響(Positive impact)]:サービス レベルしきい値内で放棄されたコールは処理されるコールとしてカウントされます。

サービス レベルの計算は、サービス レベル設定に定義されたサービス レベル タイプに基づきます。 これらについては、次の表で説明します。

表 1 サービス レベル タイプの数式

サービス レベル タイプ

サービス レベルを決定するために使用される数式

放棄呼の無視

ServiceLevelCalls / (ServiceLevelCallsOffered – ServiceLevelAband)

放棄呼へのマイナスの影響

ServiceLevelCalls / (ServiceLevelCallsOffered)

放棄呼へのプラスの影響

(ServiceLevelCalls + ServiceLevelAband) / (ServiceLevelCallsOffered

サービス レベル タイプの計算方法の例については、次のコール数を考慮してください。

  • サービス レベルしきい値(ServiceLevelCalls)内に応答 = 70 コール
  • サービス レベルしきい値(ServiceLevelAband)内に放棄 = 10 コール
  • 超過サービス レベルしきい値(ServiceLevelCallsOffered –(ServiceLevelCalls + ServiceLevelAband))= 20 コール
  • 合計サービス レベル イベント(ServiceLevelCallsOffered)= 100 コール

これらのコール数では、次のようにサービス レベルが計算されます。

表 2 サービス レベルの計算

このサービス レベル タイプの場合:

サービス レベル計算:

放棄呼を無視する計算方法

70/(100 - 10)= 77%

放棄呼が、マイナスの影響を与える計算方法

70/100 = 70%

放棄呼が、プラスの影響を与える計算方法

(70 + 10)/100 = 80%

サービス レベルのしきい値とタイプは、システム全体に設定したり、個々のコール タイプ、スキル グループおよびプレシジョン キューに設定したりできます。 個々のエンティティの設定はシステム レベルでの設定をオーバーライドします。

コール タイプのサービス レベル

カスタマー エクスペリエンスを全体的に測定するためにコール タイプを使用すると、コール処理全体と発信者によるシステムの使用状況について深く理解できるようになります。

コール タイプのサービス レベルのしきい値タイマーは、サービス レベルが定義されているコール タイプにコールが入った時点で開始します。 サービス レベル タイマーが経過すると、サービス レベルは、このコールに関連付けられている現在のコール タイプに適用されます。

[キューイング(Queue To)] ノードを使用するスクリプトに関連付けられているコール タイプだけが、サービス レベルを定義します。 コール タイプがスクリプト変更またはコール タイプ ノードを使用して変更されると、サービスしきい値タイマーはリセットされます。

このコール タイプに対して発生する可能性があるサービス レベル イベントは、次の 4 つです。

  • サービス レベルのしきい値が経過する前に、エージェントがコールに応答します。 この場合、ServiceLevelsCallsOffered および ServiceLevelCalls データベース フィールドが増加します。
  • サービス レベルのしきい値が経過する前に Unified CVP またはエージェントの電話でコールが放棄された場合。 この場合、ServiceLevelCallsOffered および ServiceLevelAband データベース フィールドが増加します。
  • サービス レベルのしきい値が経過する前に応答されなかったため、コールがリダイレクトされた場合。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。
  • たとえば、コールがエージェントによって応答、または放棄されないまま、サービス レベルのしきい値タイマーが経過した場合。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。

サービス レベルしきい値が経過する前にコールにエラーが発生した場合、[ServiceLevelError] データベース フィールドの値は増加しますが、[ServiceLevelOffered] の値は増加しません。 サービス レベルしきい値が経過した後にコールにエラーが発生した場合は、[ServiceLevelOffered] の値が増加します。

サービス レベルの計算からエラーを除外するには、エラーのコールを除外して [ServiceLevelCallsOffered] を調整します。調整された SL 提供コール数 = SL 提供コール数 –(Total Error コール数 - ServiceLevelError)

この例では、放棄コールがマイナスの影響を与えます。ServiceLevel = ServiceLevelCalls / (ServiceLevelCallsoffered – (AgentErrorCount + ErrorCount – ServiceLevelError))。

スキル グループとプレシジョン キューのサービス レベル

スキル グループとプレシジョン キュー レベルでは、サービス レベル メトリックは、モニタリング エージェント、スキル グループ、およびプレシジョン キューのパフォーマンスに役立ちます。 スキル グループまたはプレシジョン キューのサービス レベルのしきい値タイマーは、コールがスキル グループまたはプレシジョンキューにキューイングされるとすぐに開始されます。

スキル グループまたはプレシジョン キューで発生する可能性のあるサービス レベル イベントが 5 つあります。

  • サービス レベルのしきい値が経過する前に、エージェントがコールに応答します。 この場合、コールに応答したスキル グループまたはプレシジョン キューの [ServiceLevelsCallsOffered] および [ServiceLevelCalls] データベース フィールドの値が増加します。 コールが複数のスキル グループにキューイングされた場合は、他のスキル グループまたはプレシジョン キューに対する [ServiceLevelsCallsOffered] および [ServiceLevelCallsDequeued] データベース フィールドの値が増加します。
  • サービス レベルしきい値が経過する前に、スキル グループまたはプレシジョン キューからコールがキューイング解除されます。 この場合、ServiceLevelsCallsOffered および ServiceLevelCallsDequeued データベース フィールドが増加します。 コールは [キャンセル キュー(Cancel Queue)] ノードを使用してキューから外される場合もあれば、別のスキル グループまたはプレシジョン キューにルーティングされるためにそのスキル グループまたはプレシジョン キューのキューから外される場合もあります。
  • サービス レベルのしきい値が経過する前に、VRU(キュー)またはエージェントの電話でコールが放棄された場合。 この場合、ServiceLevelCallsOffered および ServiceLevelAband データベース フィールドが増加します。
  • サービス レベルのしきい値が経過する前に応答されなかったため、コールがリダイレクトされた場合。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。
  • サービス レベルのしきい値タイマーが経過した場合。 例:コールがエージェントによって応答、または放棄されないまま、サービス レベルのしきい値に達しました。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。

(注)  


ServiceLevelCallsOffered からエラーを削除する場合は、カスタム レポートで ServiceLevelCallsOffered –(Errors – SLErrors)という数式を使用できます。


バケット間隔

バケット インターバルを指定すると、特定の時間増分(0 ~ 8 秒、60 秒未満など)内の放棄呼または応答呼のデータを追跡できます。

バケット間隔は次のものに関連付けられます。

  • コール タイプ
  • スキル グループ
  • プレシジョン キュー

これは、システム全体に設定したり、個々のコール タイプ、スキル グループ、およびプレシジョン キューに設定したりできます。 個々のエンティティの設定はシステム レベルでの設定をオーバーライドします。


(注)  


現在、グローバル設定はコール タイプにのみ適用できます。


サービス レベルでは、何パーセントのコールが特定の時間内に応答されたかがわかりますが、サービス レベルのどれくらい近くで、コールが応答または放棄されたかはわかりません。 コール タイプの間隔では、コールが応答されるまでに、または放棄されるまでに、発信者がどれくらい待っているかも把握できます。

たとえば、サービス レベルが 2 分の場合に、間隔を 30 秒、1 分、90 秒、120 秒、180 秒、210 秒、および 240 秒に設定したとします。 これらのインターバルを使用すれば、コールが 180 秒のサービス レベルしきい値の 30 秒後までに応答されたのか、ほとんどの人が応答されるまでにさらに 1 分長く待っているのかがわかります。

この間隔は、発信者が放棄するまでにどれぐらい待とうという意志があるかについての洞察も得られます。 たとえば、サービス レベルを 2 分過ぎるまでは、発信者の多くはコールを放棄しないとします。 この場合は、サービス レベルの目標を変更できることが示されている可能性があります。

レポートの不一致を回避するには、特定の時間境界(つまり、1 日、週、または月の終わり)でのみバケット間隔設定を変更します。 時間境界を変更するときには、変更するインターバルに対してレポートを実行しているユーザがいないことを確認してください。