本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Connect 中的实时指标中的队列回拨量
<a name="about-queued-callbacks"></a>

本主题介绍了排队回拨如何显示在实时指标报告和联系记录中。

**提示**  
要仅查看正在等待回拨的客户数量，您需要创建一个只包含回拨联系人的队列。若要了解如何执行此操作，请参阅[在 Amazon Connect 中设置路由](connect-queues.md)。目前无法查看等待回拨的联系人的电话号码。

1. 当[转接到队列](transfer-to-queue.md)数据块在回拨队列中创建回拨时启动回拨。下图显示了流末尾的**转接到队列**数据块。  
![\[以“转移到队列”数据块结尾的流。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/queued-callback-flow-callback-initiation.png)

1. 应用任何初始延迟后，回拨将放入队列。它会保持在队列中，直至有座席可用并可向其提供联系人。下图显示了**实时指标**页面上的**队列中**列中的联系人。  
![\[在“实时指标”页面的“队列中”列出的联系人。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/rtm-callback-in-queue.png)

1. 当回拨连接到座席时，系统会为联系人创建一个新的联系记录。下图显示了三条联系记录。第三条记录是连接到 Agent 3 的回拨记录。  
![\[三个数据块，每个联系记录一个。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/ctr-diagram.png)

1. 回拨联系记录中的**启动时间戳**对应于流中启动回拨的时间，如步骤 1 所示。下图显示了**联系记录**页面上的**启动时间戳**字段。  
![\[“联系记录”页面，“启动时间戳”字段。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/ctr-callback-initiation-timestamp.png)

## “转接队列”数据块中的属性如何影响此流
<a name="transfer-to-queue-properties"></a>

Tr [ansfer to qu](transfer-to-queue.md) eue 块具有以下属性，这些属性会影响回调的 Amazon Connect 处理方式：
+ **初始延迟**：此属性影响将回拨放入队列的时间。指定在流中启动回拨联系，与客户在队列中等待下一个可用座席之间需要经过多长时间。有关更多信息，请参阅 [初始延迟如何影响 Amazon Connect 中的计划指标和队列中指标](scheduled-vs-inqueue.md)。
+ **最大重试次数**：如果设置为 2，则 Amazon Connect 尝试呼叫客户最多 3 次：初始回拨和两次重试。
+ **两次尝试之间的最短时间**：如果客户未接听电话，则需要等待多长时间才能再次尝试。

## 回拨指标
<a name="callback-metrics"></a>

使用以下指标来监控您业务中的回拨数量：
+ [回拨联系人](metrics-definitions.md#callback-contacts)：该指标表示从排队的回拨中发起的联系数量。也就是说，有多少客户选择了排队回拨。
+ [处理的回拨联系人](metrics-definitions.md#callback-contacts-handled)：该指标统计从排队的回拨中发起并由座席处理的联系。也就是说，有多少回拨得到了回复。
+ [回拨尝试](metrics-definitions.md#callback-attempts)：该指标表示已尝试回拨但客户未接听的联系次数。

# 初始延迟如何影响 Amazon Connect 中的计划指标和队列中指标
<a name="scheduled-vs-inqueue"></a>

在[转接到队列](transfer-to-queue.md)数据块中，**初始延迟**属性影响将回拨置于队列中的时间。例如，假设**初始延迟**设置为 30 秒。以下是实时指标报告中显示的内容：

1. 20 秒后，回拨已经创建，但由于**初始延迟**设置，它尚未进入队列。在下图的**实时指标**页面中，**队列中** = 0，**已计划** = 1。  
![\[已计划但不在队列中的联系人。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/rtm-callback-scheduled.png)

1. 35 秒后，回拨联系被排入队列。在下图中，回拨现在处于**队列中**。它已经不是“已计划”了。  
![\[“队列中”列为 1，“已计划”列为 0。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/rtm-callback-in-queue2.png)

1. 假设在 40 秒后，有座席接受回拨。**队列中**列 = 0，**已计划**列 = 0。  
![\[“队列中”列为 1，“已计划”列为 0。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/rtm-callback-accepted-by-agent.png)

# 在 Amazon Connect 中尝试回拨失败
<a name="failed-callback-attempt"></a>

如果座席未接受提供的回拨，这种情况不会计为失败的回拨尝试。而是由路由引擎将回拨提供给下一个可用座席，直到座席接受。

失败的回拨尝试会是：一个座席接听了某个回拨，但是在那之后到座席加入与客户的通话之间出现了问题。

在座席接受提供的回拨联系之前，该联系人被视为在回拨队列中。

Amazon Connect 当回调连接到代理时，将其从队列中移除。那时， Amazon Connect 开始给客户打电话。

下图显示了联系记录中的这种情况：
+ 出队时间：回拨连接到座席的时间戳。这也是 Amazon Connect 开始给客户打电话的时候。

![\[包含一次出队的联系记录。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/ctr-enqueue-and-dequeue.png)


特定回拨分支在联系记录上的排队时间，对应于进行特定回拨尝试之前联系人处于队列中的时间。这不是在所有联系记录上的总排队时间。

例如，在计划回拨之前，入站呼叫可以在排队 5 分钟。然后，在 10 秒的初始延迟后，回拨联系人可在回拨队列中等待 10 秒座席的接听。在这种情况下，您将看到两条联系记录：

1. 第一个带有 InitiationMethod =INBOUND 的联系人记录的排队时间为 5 分钟。

1. 第二个带有 InitiationMethod =CALLBACK 的联系记录的排队时间为 10 秒。

# 队列回拨流的 Amazon Connect 实时指标示例
<a name="queued-callback-example"></a>

本主题演示了排队回拨流的示例，并讨论如何为其设置联系记录和时间。

假设我们已经设置了以下流：
+ **入站流** – 在客户呼叫客户服务号码时运行。
+ **客户队列流** – 当客户在队列中等待时运行。在此示例中，我们构建了一个向客户提供回拨的流。如果客户选择 “是”，则此流程将执行 “**转接到队列**” 区块，将联系人转移到名为的回拨队列 CallbackQueue，初始延迟为 99 秒，然后挂机。
+ **出站私密消息流** – 进行排队回拨时，客户在接听后并在连接到座席之前会听到此消息。例如，“您好，这是您的计划回拨...”
+ **座席私密消息流** – 这是座席在接听联系电话之后并在加入与客户的对话之前听到的内容。例如，“您即将连接到客户 John，他请求退款... “

在此示例中，John 致电客户服务。将发生以下情况：

1. 入站流创建联系记录-1：

   1. John 在 11:35 拨打客户服务电话。入站流运行，于 11:35 将其置于队列中。

   1. 客户队列流运行。在 11:37，John 选择安排回电，因此在入站联系人断开连接之前，在 11:37 Amazon Connect 发起回拨联系。

1. 回拨流创建联系记录-2：

   1. 回拨联系在 11:37 启动。

   1. 由于初始延迟为 99 秒，因此在 99 秒过去后， CallbackQueue 在 11:38:39 进入回拨联系。现在，回拨联系转接给可用的座席。

   1. 21 秒后，在 11:39:00 有一位座席可接听联系电话。向该座席播放 10 秒的座席私密消息流。

   1. 特工耳语流完成后，在 11:39:10 给 John Amazon Connect 打电话。John 接起电话，收听 15 秒的出站私密消息流。

   1. 出站私密消息流完成后，John 在 11:39:25 连接到座席。他们交谈直到 11 点 45 分，然后 John 挂断电话。

这种情况会出现两条联系记录，包括以下元数据。


| 联系记录-1 | 数据 | 注意 | 
| --- | --- | --- | 
|  启动方法  | 入站  |   | 
|  启动时间戳  | 11:35  | 入站联系是在中发起的 Amazon Connect。  | 
|  ConnectedToSystem 时间戳  | 11:35  | 因为这是入站联系人，因此 InitiationTimestamp = ConnectedToSystemTimestamp。  | 
|  下一个联系 ID   | 指向联系记录 2  |   | 
|  队列  | InboundQueue  |   | 
|  入队时间戳  | 11:35  | 入站联系人置于队列中。  | 
|  出队时间戳  | 11:37  | 因为没有特工接走，所以这是相同的 DisconnectedTimestamp。  | 
|  ConnectedToAgent 时间戳  | 不适用  | John 在有任何座席接听之前计划了一个回拨。  | 
|  Disconnected 时间戳  | 11:37:00  | John 从流中断开。  | 


| 联系记录-2 | 数据 | 注意 | 
| --- | --- | --- | 
|  PreviousContactId  | 指向联系记录-1  |   | 
|  启动时间戳  | 11:37  | 回拨联系人是在中创建的 Amazon Connect。  | 
|  队列  | CallbackQueue  |   | 
|  入队时间戳  | 11:38:39  | 在 99 秒的初始延迟结束后 CallbackQueue，联系人进入了。  | 
|  出队时间戳  | 11:39:00  | 21 秒后，座席接听联系电话。  | 
|  队列持续时间  | 120 秒  | 这是初始延迟（99 秒），加上在队列中等待座席可用的任何额外时间（21 秒）。  | 
|  ConnectedToSystem 时间戳  | 11:39:10  | John 在 10 秒座席私密消息流完成后被呼叫。  | 
|  ConnectedToAgent 时间戳  | 11:39:25  | 在 15 秒的出站私密消息流完成后，John 与座席接通。  | 
|  Disconnected 时间戳  | 11:45  | John 挂断电话。  |