如前面ACD（来电分配）部分中提到的，ACD在非常老旧的PBX（用户专用自动电话交换机）系统中都能实现，而报表功能则是决定PBX能否应用在Service Desk环境中的关键。

 

评估服务台运作所需数据

当衡量一个Service Desk的操作表现时，以下是一些呼叫处理的SLA（服务水平协议）定义：

“呼叫数量”——一个月中接收到的来电数量。

“应答时间”——一个来电由呼入到被接听前的时间（按秒计算）。

“呼损率”——用户来电后，由于等待时间过长，在电话被坐席接听前选择挂断电话的比例。

 

其他对于评估Service Desk运作的有用数据：

“通话时长”——每个已接听电话的持续时间。

“总量趋势”——与“来电总量”类似，但同时包括每个来电的时间，以供分析一天中的来电高峰与低谷。

“坐席负载”——每位服务台坐席所接听的来电数量及持续时间

“高频呼入者”——致电服务台最多的人。

“排队时间”——处于排队状态、等待接听的电话数，及其能被坐席接听前的预计时间。这种实时报告往往会比月报更有用。

 

报表功能对服务管理的影响

尽管PBX的数据报告功能是服务台电话系统的一个重要选择标准，但许多PBX系统却不是为Service Desk而是为一些典型的办公环境而设计的。一个无法使用数据来衡量服务水平的Service Desk，其对SLA的定义实际上毫无意义，更为重要的是，服务水平的不可管理将会对最终用户满意度产生影响。

同时我们也应该注意，当PBX提供数据，比如“呼损率”报告时，细节的缺失将使我们无法对失败做进一步分析，亦失去改进服务的机会。

比如，一个老旧的电话系统可能提供如下的呼损率报告：

Period Start

Period End

Total Number
of Calls

Total Abandoned
Calls

Average Duration
before Abandoned

2010-08-01

2010-08-31

8,442

251

15s

从这个报告中，你可以看到呼损率为2.97%（251/8442），但是“挂断前的平均等待时间”其实毫无意义，因为它无法显示：在等待时间达到或超过20秒之后，究竟有多少用户放弃等待而挂断电话——而这是一种更典型的对呼损的界定。一般认为，用户在没有等待相对长的时间（20秒）就挂断电话的情况，并非是必然的“放弃”，因为可能是他已经找到了新的解决方案，或忽然有更紧急的事情要处理，抑或只是暂时挂断而又立即重拨。

 

应当指出，电话呼损率会产生指数级的增长。一个中途放弃等待挂断电话的用户，即便没有立即重拨，也会在不久后再次拨打。如果第二个呼入仍然没有被适时的接听，则会产生又一个呼损电话，直到这个电话被某个坐席应答。因此拥有一些呼入电话的详细信息会非常有帮助，这将能分析哪些电话是真正的呼损电话，哪些用户频繁重复拨打而带来“呼损”，更好的管理用户来电、避免呼损。

（希望你已经正在考虑：如何面对或解决那些由于电话多次无法接通，可能倍感“沮丧”的的呼入用户，以管理用户满意度。）

 

而下面是由具备报表功能的电话系统所提供的一系列相连呼入电话的数据示例，它可以支持进行包括呼叫总量，应答时间，通话时长，呼损电话，高频呼叫者，坐席负载，高峰时段，及排队时间的分析：

 

Agent

Caller

Time Received

Time Hang Up

Time Queued

Time Answered

Queue Time (s)

Pick Up Time (s)

Talk Time (s)

Remark

2045

2116

2010-08-31 18:24:07

2010-08-31 18:25:15

2010-08-31 18:24:08

2010-08-31 18:24:15

4

4

60

Short support call – 1m 0s

2045

2112

2010-08-31 18:07:08

2010-08-31 18:10:29

2010-08-31 18:07:15

2010-08-31 18:07:26

5

5

183

Normal support call – 3m 3s

2045

2113

2010-08-31 17:56:29

2010-08-31 18:02:51

2010-08-31 17:56:34

2010-08-31 17:56:47

6

6

364

Lengthy support call – 6m 4s

2045

2116

2010-08-31 16:28:30

2010-08-31 16:32:21

2010-08-31 16:28:42

2010-08-31 16:28:47

2

2

214

Normal support call – 3m 34s

2045

2114

2010-08-31 15:59:31

2010-08-31 16:02:24

2010-08-31 15:59:37

2010-08-31 15:59:44

3

3

160

Normal support call – 2m 40s

2045

2110

2010-08-31 14:58:51

2010-08-31 15:01:54

2010-08-31 14:59:01

2010-08-31 14:58:16

4

4

218

Normal support call – 3m 38s

2045

2112

2010-08-31 13:40:52

2010-08-31 13:43:07

2010-08-31 13:40:52

2010-08-31 13:41:03

5

5

124

Normal support call – 2m 4s

2045

2111

2010-08-31 12:55:15

2010-08-31 12:56:45

2010-08-31 12:55:18

2010-08-31 12:55:22

2

2

83

Short support call – 1m 23s

2045

2112

2010-08-31 11:53:40

2010-08-31 11:56:57

2010-08-31 11:53:43

2010-08-31 11:51:12

2

2

345

Lengthy support call – 5m 45s

 

2116

2010-08-31 11:43:44

2010-08-31 11:44:29

 

 

0

0

0

Abandoned after 45 seconds

2045

2114

2010-08-31 10:00:14

2010-08-31 10:03:56

2010-08-31 10:00:14

2010-08-31 10:00:26

6

5

210

Normal support call – 3m 30s

 

2114

2010-08-31 09:49:25

2010-08-31 09:49:36

 

 

0

0

0

Hang Up after 11 seconds (not abandoned)

2045

2113

2010-08-31 09:05:52

2010-08-31 09:12:07

2010-08-31 09:05:49

2010-08-31 09:06:10

10

10

357

Lengthy support call – 5m 57s

© Rick Ho ,CTO, Gamutsoft

 

 官方专栏：http://www.gamutsoft.com/expert/index.aspx?nodeid=5