对间隔为真 (TTI) 范式
WFM 使用 CXone Mpower ACD 中的历史数据来计算交互数量和平均处理时间 (AHT)。 交互会自动分成能够以间隔级别用于 WFM 目的的数据。 该数据用于生成预测。
在间隔期间有两种评估交互的方法:
-
联系结束时 (WCE):在交互结束的时间间隔内对交互计数一次,即使交互持续多个时间间隔也是如此。 在此方法中,仅在交互结束的时间间隔内报告处理时间。
查看示例
交互分析,从 9:10 开始,到 09:40 结束。
间隔 数量 已处理 处理时间 人员要求 09:00 - 09:15 0 0 0 0 09:15 - 09:30 0 0 0 0 09:30 - 09:45 1 1 30:00 2
-
对间隔为真 (TTI):在交互开始时对此交互计数一次。 如果此交互跨多个时间间隔,则在每个时间间隔中此对交互进行计数。 在交互处于活动状态的每个时间间隔内都会报告处理时间。
查看示例
交互分析,从 9:10 开始,到 09:40 结束。
间隔 活跃 已处理 处理时间 人员要求 09:00 - 09:15 0 1 5:00 0.33 09:15 - 09:30 1 0 15:00 1 09:30 - 09:45 1 0 10:00 0.67
请记住,由于 TTI 是一种相对较新的数据表示方式,因此在 TTI 之前生成的预测数据仍显示在 WCE 中。 这意味着预测数据正在显示 WCE 数据,而实际数据是 TTI。 在这种情况下,这些数据将不匹配。 为确保预测数据由 TTI 表示,生成新的预测,并且相应地发布新计划表。

在早班期间,有 5 次交互:
-
交互 A:于 8:02 开始。 坐席于 8:10 应答,在 8:20 结束交互。
-
交互 B:于 8:05 开始,并在坐席应答之前于 8:12 结束。 可能是呼叫者在等待时挂断了电话。
-
交互 C:于 8:11 开始。 坐席于 8:22 应答,在 8:29 结束交互。
-
交互 D:于 8:16 开始。 坐席于 9:05 应答,在 9:14 结束交互。
-
交互 E:于 8:35 开始。 坐席于 9:10 应答,在 9:14 结束交互。
这是当天信息显示的内容:
间隔 |
已收到 |
实际 |
回答 |
活动 |
积压 |
放弃 |
---|---|---|---|---|---|---|
8:00 |
3 (A, B, C) |
2 (A, B) |
1 (A) |
|
|
1 (B) |
8:15 |
1 (D) |
2 (A, C) |
1 (C) |
1 (A) |
|
|
8:30 |
1 (E) |
|
|
|
1 (D) |
|
8:45 |
|
|
|
|
2 (D, E) |
|
9:00 |
|
2 (D, E) |
2 (D, E) |
|
|
|
* 括号内的字母不会在当天信息中显示。 它们表示该间隔期间内包含哪些交互。
当天信息从 2024 年 8 月开始收集积压数据。 不显示之前的数据。
与 WCE 范式相比,TTI 捕获更真实的数据,尤其是在以下情况时:
-
处理时间较长或间断,并且交互跨多个时间间隔。
-
时间间隔比交互的总处理时间短。
TTI 范式有几个优点:
-
提高较长持续时间和异步渠道
促进客户在联系中心交互的各种语音和数字通信媒介。(数字)的预测准确性。
-
解决当 AHT
平均处理时间是坐席处理交互所花费的平均时间。 超过计划间隔时错误的人员配备需求。
-
生成与基于利用率的真实需求相一致的更准确计划表。
-
即使持续时间较长且为异步渠道(数字),当天信息视图和报告也更加准确。
记住,在从 ACD 接收历史数据时,TTI 范式正常工作。 目前导入的预测数据不支持该范式。 因此,如果您正在使用“导入预测数据”,则将根据交互结束的时间评估导入的数据(使用 WCE 范式)。

假设您一天只接到一个呼叫。 这个呼叫花费了一个小时来处理。
这是当天信息显示的内容:
间隔 |
已应答 |
活跃 |
实际 |
---|---|---|---|
总计 | 1 | 3 | 4 |
11:00 |
1 | 0 | 1 |
11:15 |
0 | 1 | 1 |
11:30 | 0 | 1 | 1 |
11:45 | 0 | 1 | 1 |
12:00 | 0 | 0 | 0 |
“总计”行中的“实际”数据是四而不是一。 为什么? 因为此呼叫跨了四个时间间隔。 “总计实际”数据显示每个时间间隔发生的交互次数。
当天信息中的实际数据现在自动用 TTI 表示。 如果您发现实际数据与预测数据之间存在较大差异,则预测数据可能是使用 WCE 生成的。 这意味着预测数据正在显示 WCE 数据,而实际数据是 TTI。 在这种情况下,这些数据将不匹配。 为确保预测数据由 TTI 表示,生成新的预测,并且相应地发布新计划表。

假设您一天只接到 3 个呼叫。 所有呼叫都是在 11:00 开始的。 第一次持续了 10 分钟,第二次持续了 20 分钟,第三个持续了 30 分钟。
这是当天信息显示的内容:
间隔 |
已应答 |
活动 |
---|---|---|
11:00 |
3 | 0 |
11:15 |
0 | 2 |
11:30 | 0 | 1 |
11:45 | 0 | 0 |
积压:在上一个时间间隔内未应答的交互数量。 假设在 9:10 收到一条交互。 坐席于 10:05 开始处理交互。 这意味着此交互是在 10:00 的间隔期间内收到的。 9:15、9:30 和 9:45 间隔的交互列在积压列中。
基于 TTI 范式的计算
更新后的计算为:
-
数量 = 已处理交互 + 已弃呼交互 + 活动交互
-
平均处理时间 = (已处理时间 + 工作时间) ÷ (已处理交互 + 活动交互)
TTI 故障排除

TTI 适用于所有交互,包括语音。 在时间间隔的最后几分钟获得交互很常见。 例如您在 09:29 接到一个呼叫,该呼叫于 09:32 结束。 TTI 将识别 09:29-09:30 之间的活动时间分钟数和 09:30-09:32 之间的 2 分钟。

事实上,TTI 将直接影响调度,因为调度要求将取决于 TTI 以及在所有适用间隔内所花费的活动时间。

在 Supervisor 应用程序或仪表板上收到的交互将继续表示基于已完成交互的数据。

TTI 的运作方式与旧的 WCE 范式不同。 数字交互分布在不同的时间间隔内,需要更少的时间来回答。 活动参数仅在应答的时间间隔内计数,而不是在整个持续时间内计数,这会减少 AHT。