> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/zh/shang-ye-ban-fu-wu/zoom-contact-center/expert-insights/time-of-day-and-operating-hours-routing.md).
# 按时段和营业时间路由
作者：Justin Steinberg
在本指南中，我们将演示时间路由的标准部署，也称为工作时间路由。
{% hint style="success" %}
**前提条件**
Zoom 呼叫中心为您的呼叫中心处理拨入来电。
{% endhint %}
## 概述
我们将使用三个核心组件来构建我们的时间路由：
**工作时间**
工作时间配置元素用于设置您的呼叫中心何时开放。
工作时间有两个子组件：
* 工作时间 - 这是您典型的标准工作时间，例如，您可能在工作日 8:00 到 20:00 营业
* 停业 - 这是您一年中某些会关闭的时段，例如节假日或其他计划内停业。例如，每年 1 月 1 日关闭。
Zoom 呼叫中心支持多个可在账户级和/或队列级创建的工作时间安排/定时发送。
**队列**
队列处理需要连接到您的客服人员的来电。队列可以有自己的工作时间安排/定时发送。当您有多个部门/队列遵循不同的工作时间时，这很有用。
**流程**
流程包含了呼叫中心的大部分业务逻辑。这包括用预录制（或文本转语音！）提示向来电者问候、向来电者展示 IVR 菜单，以及将来电路由到队列（最终到客服人员）。流程还负责检查工作时间，并决定在呼叫中心开放时做什么，以及在呼叫中心关闭时做什么。
### 整合起来
虽然工作时间决定了您的业务安排/定时发送/工作时间，但流程会根据工作时间安排/定时发送决定会发生什么。就按时间路由/工作时间路由而言，检查工作时间是流程的责任。
流程可以通过两种方式实现时间路由：
#### 检查账户级工作时间安排/定时发送
在使用账户级工作时间安排/定时发送时，流程使用条件组件来检查工作时间。在此配置下，条件组件会选择将使用的工作时间和/或停业。该组件可以从默认的账户级配置中进行选择，也可以选择特定的账户级工作时间和/或停业。由于这种按时间强制执行可以在选择特定队列之前发生，因此在此配置下，任何队列级工作时间配置都会被忽略。通过这种设计，该组件会指定特定的工作时间配置，而不考虑任何队列级配置。
{% hint style="info" %}
**注意**
上述账户级工作时间配置是实现按时间检查的最简单方式，适合用于您的整个流程要么开放，要么关闭的情况。但是，如果您的工作时间因部门而异，则可以使用队列级配置。
{% endhint %}
#### 检查队列级工作时间安排/定时发送
当队列之间的工作时间不同的时候，使用队列级工作时间安排/定时发送配置是合适的。在下面的示例中，拨入流程的来电者会为其队列进行菜单选择。选择完成后，按时间路由会在队列级发生。条件组件使用“获取队列数据”检查来选择特定队列，然后强制执行在该队列上配置的工作时间。
如上面的流程示例所示，流程检查工作时间安排/定时发送的结果将是以下之一：
* 在线 - 在线 状态的典型流程配置是将来电者路由到“开放”逻辑，包括 IVR 菜单和/或路由到队列/客服人员。
* 不可用 - 对于不可用，典型流程配置是将来电者路由到“下班后”逻辑，例如关闭菜单和/或语音信箱。
{% hint style="info" %}
**注意**
虽然可以在账户级和/或队列级配置工作时间，但始终是流程决定如何处理工作时间。\\
因此，使用您的工作时间逻辑来配置流程至关重要；如果您的流程没有使用条件组件来执行工作时间检查，那么您还没有完成按时间路由的配置！
{% endhint %}
#### 结合账户级和队列级工作时间安排/定时发送
由于工作时间的强制执行发生在流程配置中，因此您可以灵活选择按时间路由的处理方式。您可以根据需要同时使用账户级条件检查和队列级检查，以实现适当的工作时间逻辑。
## 配置步骤
对于按时间路由/工作时间路由功能/特性的配置，我们将使用工作时间功能/特性来构建我们的工作时间。然后我们将配置流程来强制执行按时间路由检查/逻辑。
### 账户级工作时间
在本节中，我们将完成默认账户级工作时间，并将其应用到流程中。对于此配置，我们将完成以下高级步骤：
1. 配置账户级工作时间
2. 更新流程以强制执行账户级工作时间
#### 工作时间
1. 在您的 Zoom 呼叫中心管理员门户中前往 [**管理员中心**](https://zoom.com/account) → **CX 管理** → **呼叫中心** → [**偏好设置**](https://zoom.com/cci/index/admin#/admin-preferences).
2. 在“偏好设置”页面上，单击 **工作时间** 选项卡。
3. 首先查看 **工作时间** 安排/定时发送。默认情况下，您将只有一个 **默认工作时间** 工作时间安排/定时发送，默认情况下为全天候 24x7 开放。如果您的整个呼叫中心将共享同一个工作时间安排/定时发送，您只需将默认工作时间安排/定时发送编辑为您的常规工作时间即可。如果您有多个部门，而且大多数部门共享相同的工作安排/定时发送，您也可以使用默认工作时间安排/定时发送。请记住，按时间路由的执行责任在于流程，因此如果您有任何遵循不同工作时间的流程/部门/电话号码，您可以稍后在流程配置中进行调整。在我们的示例中，让我们编辑默认节假日安排，并将时间设置为周一至周五 8:00 到 20:00。
下一步是创建 **停业** 用于任何需要覆盖您的标准工作时间安排/定时发送的节假日或计划内停业。如有需要，您可以创建多个停业安排/定时发送。单击 **+ 添加停业集** 按钮，并根据相应的公司安排/定时发送创建您的停业。以此示例为例，我们将创建一个名为“公司节假日”的单一停业，它涵盖几个常见的美国节假日。请注意，我们已勾选“设为账户默认停业”，因为这将作为整个企业使用的停业配置。
{% hint style="warning" %}
**注意**
关于账户默认停业的特别说明：默认停业安排/定时发送适用于整个账户，包括任何队列级配置。因此，建议您在配置任何默认停业时，如果有拥有自己安排/定时发送的特殊部门/队列，请将这一点考虑在内。
{% endhint %}
一个特殊用例示例是，如果您有任何全年 365 天开放的队列，则不应配置默认停业，因为该队列将无法覆盖该默认停业安排/定时发送。
此时，我们已经配置了这两者： **工作时间** 以及 **停业** 并且现在已经完成了 **工作时间** 配置。
#### 流程
您在流程中实施的配置决定了我们是否检查/应用按时间/工作时间逻辑。要向您的流程添加工作时间检查，您需要使用条件组件。
1. 打开您将实施工作时间检查的流程。
2. 向您的流程中添加一个新的条件组件。
1. 类型：选择工作时间
2. 工作时间：选择/配置您之前配置的合适工作时间安排/定时发送
3. 停业：选择/配置您之前配置的合适停业安排/定时发送
3. 将条件组件的在线出口连接到适当的流程逻辑，例如路由到队列或开放时间菜单。
4. 将条件组件的不可用出口连接到适当的流程逻辑，例如路由到下班后菜单或语音信箱。
恭喜。您现在已经完成了账户级工作时间/按时间路由。如果您有多个流程，请确保您的所有流程都具有适当的工作时间/按时间路由配置。如果所有部门都遵循相同的工作安排，那么一旦所有流程都配置完成，您就完成了按时间路由配置。然而，如果某些部门/队列遵循不同的安排，您可以按照下一部分的配置来处理队列级工作时间。
### 队列级工作时间
在上一节中，我们配置了账户级工作时间，这在所有部门共享相同安排/定时发送时适用。本节将讨论使用队列级工作时间，这在某些队列采用非默认工作时间或停业安排/定时发送时适用。
在本节中，我们将完成队列级工作时间，并将该安排/定时发送应用到一个特定队列。对于此配置，我们将完成以下高级步骤：
1. 为特定部门/队列配置一个新的工作时间安排/定时发送
2. 将工作时间安排/定时发送应用到队列
3. 更新流程以强制执行队列级工作时间
#### 工作时间
1. 在您的 Zoom 呼叫中心管理员门户中前往 [**管理员中心**](https://zoom.com/account) → **CX 管理** → **呼叫中心** → [**偏好设置**](https://zoom.com/cci/index/admin#/admin-preferences)
2. 在“偏好设置”页面上，单击 **工作时间** 选项卡。
3. 点击 **+ 添加工作时间** 按钮。在此示例中，我们将为技术支持部门创建一个新的工作时间安排/定时发送。该部门的时间与默认值不同，因此他们需要自己的队列级配置。
4. 在新的工作时间安排/定时发送中，输入相应的时间，然后单击 **保存**.
5. 现在您将看到“默认工作时间”和“技术支持工作时间”。请注意，虽然我们已经为技术支持部门创建了工作时间安排/定时发送，但如您在“Used In”列中所见，它尚未被分配。我们稍后会在队列配置中完成这项操作。
6. 下一步是创建 **停业** 用于处理任何节假日。在此示例中，我们不会为技术支持部门配置任何停业安排/定时发送，因为他们全年 365 天开放。如果您需要遵循停业，您可以根据需要配置额外的停业配置，以满足您的要求。
{% hint style="info" %}
**注意**
如果您有一个全年 365 天开放的部门，请确保没有配置默认的账户级停业，因为这会应用到您的队列级配置。
{% endhint %}
7. 此时，我们已经配置了 **工作时间** 并完成了 **工作时间** 配置。
#### 队列
在完成上述工作时间配置后，我们现在需要将工作时间应用到队列。在此示例中，技术支持部门的工作时间与公司其他部分不同。因此，我们将把技术支持工作时间分配到技术支持队列。对于其他所有队列，它们将使用默认设置的工作时间。因此，本队列部分仅适用于遵循非默认工作时间或停业的队列。
1. 在您的 Zoom 呼叫中心管理员门户中前往 [**管理员中心**](https://zoom.com/account) → **CX 管理** → **呼叫中心** → [**队列**](https://zoom.com/cci/index/admin#/admin-queues)
2. 单击技术支持部门使用的队列，并向下滚动到工作时间部分。找到工作时间设置，并选择您之前创建的技术支持工作时间安排/定时发送。
3. 单击 **保存**。现在是转到流程配置以应用队列级工作时间安排/定时发送的时候了。
#### 流程
您在流程中实施的配置决定了我们是否检查/应用按时间/工作时间逻辑。要向您的流程添加工作时间检查，您需要使用条件组件。
1. 打开队列所使用的相应流程。在此示例中，我们将打开用于路由技术支持部门来电的主流程。您需要确保以下配置已应用到您的配置中的相应流程。
2. 进入流程编辑器页面后，向您的流程中添加一个新的条件组件。
1. 类型：选择“获取队列数据”
2. 队列：<选择相应的队列，在此示例中我们将使用技术支持队列>
3. 队列数据：选择工作时间可用性
3. 将条件组件的在线出口连接到适当的流程逻辑，例如路由到队列或开放时间菜单。
4. 将条件组件的不可用出口连接到适当的流程逻辑，例如路由到下班后菜单或语音信箱。
恭喜。您现在已经完成了队列级工作时间/按时间路由。如果队列使用多个流程，请确保您的所有流程都具有适当的工作时间/按时间路由配置。
**替代配置**
在这个队列级示例中，我们创建了一个工作时间安排/定时发送，将其应用到队列，然后使用条件组件的“获取队列数据”配置来检查该队列的工作时间。另一种方法是使用条件组件的工作时间配置，并指定合适的工作时间和/或停业。
## 总结
在本文中，我们介绍了 Zoom 呼叫中心按时间路由 / 工作时间逻辑的概念和配置。我们介绍了如何配置账户级和队列级配置。对于这两种配置，我们都讨论了流程如何通过使用条件组件来检查账户级或队列级工作时间，从而实现实际的按时间路由。由流程决定在工作时间开放时会发生什么，也决定在工作时间关闭时会发生什么。
上述示例是基础示例，借助您在本文中学到的概念，您可以将适当的配置应用到您的流程中，以根据业务需求实现按时间路由/工作时间检查。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://library.zoom.com/technical-library/zh/shang-ye-ban-fu-wu/zoom-contact-center/expert-insights/time-of-day-and-operating-hours-routing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
