CIC系统计算Service Level的不妥之处
2012-02-10
公司的Wallboard程序年代久远，显示KPI统计不太美观。去年11月抽了个空，我根据CIC系统接口文档重新整了一个小玩意。
在开发比对我在程序中各项统计值和系统自收集的统计值，基本上都是一致的，可就是Service Level这一项老是对不上号。我得到的值总小于或等于（等于的情况也就热线开线一小段时间内）系统自收集统计的值中，我的计算方式是按照COPC标准提倡的那样计算。实在没法，我只好寻找CIC系统自带的说明文档是否有计算Server level描述。最后在Workgoup Monitoring Guide中找到了该信息的统计方法说明，具体如下：
Service Level Statistics
Service Level statistics measure the percentage of interactions that connected callers to agents within a specified time interval.
Number of Service Level Periods
This statistic is for internal use, but may be useful in a support situation.
Service Level (Current Period)
The percent of interactions where the caller was connected to the agent within the specified time interval. For example, "Service Level Current Period 0-30 Seconds" refers to the percent of interactions in the current period that were answered after waiting 30 seconds or less.
In technical terms, this is the percent of interactions that entered the queue and went to an ACD-Assigned state in the specified time interval, calculated as:
(Interactions Serviced in the interval (Current Period) / Interactions Answered (Current Period)) * 100
Service Level (Current Shift)
The percent of interactions where the caller was connected to the agent within the specified time interval. For example, "Service Level Current Shift 0-30 Seconds" refers to the percent of interactions in the current shift that were answered after waiting 30 seconds or less.
In technical terms, this is the percent of interactions that entered the queue and went to an ACD-Assigned state in the specified time interval, calculated as:
(Interactions Serviced in the interval (Current Shift) / Interactions Answered (Current Shift)) * 100
Service Level (Previous Period)
The percent of interactions where the caller was connected to the agent within the specified time interval. For example, "Service Level Previous Period 0-30 Seconds" refers to the percent of interactions in the last period that were answered after waiting 30 seconds or less.
In technical terms, this is the percent of interactions that entered the queue and went to an ACD-Assigned state in the specified time interval, calculated as:
Interactions Serviced in the interval (Previous Period) / Interactions Answered (Previous Period)) * 100
Service Level (Previous Shift)
The percent of interactions where the caller was connected to the agent within the specified time interval. For example, "Service Level Previous Shift 0-30 Seconds" refers to the percent of interactions in the last shift that were answered after waiting 30 seconds or less.
In technical terms, this is the percent of interactions that entered the queue and went to an ACD-Assigned state in the specified time interval, calculated as:
(Interactions Serviced in the interval (Previous Shift) / Interactions Answered (Previous Shift)) * 100
Service Level Periods
This statistic is for internal use, but may be useful in a support situation.
Interactions Serviced in the interval / Interactions Answered) * 100
哈哈
，总算被我发现问题了，原来CIC在计算Service Level时是基于Interactions Answered的数量来的，怪不得和我的老对不上。
用Interactions Answered个人感觉有点不妥:
1、Callcenter在运行中，需要关心用户的体验。除去CSR的沟通、解决问题的技能和礼貌态度之外，Service Level也是一个比较好去了解用户体验的关键KPI-------展示CallCenter对用户的响应速度。如果用Interactions Answered统计，会造成统计片面，忽略了那些由于在ACD中等待时间过长而放弃的用户体验。
2、如果用Interactions Answered，也会对计划排班和人员配置造成偏差。用该方法可能出现Service Level很高，Abandon也很高的现象，形成了负相关；有时它们之间又会出现正相关。照理这两个KPI指标应该属于正相关性。
举例：
由于人员排班没有预计到高峰，使的Abandon 高达15%，但是Interactions Answered90%都集中在10S内，另外10%都在10S~20S之间响应了。上述也就是说Abandon掉的都超过了30S。Callcenter运营管理者不能直接从Service Level这个指标衡量运营健康状态，也不便于快速做出反应。毕竟Service Level高，Abandon可能很高也可能理想或非常理想。
综上，个人感觉基于Interactions offer to ACD这个数值计算Service Level比较靠谱 ，如计算Service Level Periods用 Interactions Serviced in the interval /Interactions offer to ACD) * 100，包含上在ACD中abandon的Interaction数量，这样上述两个问题也就解决了。
最后拷个新Wallboard屏作为此blog的结束标志。
