> 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/unifying-live-and-asynchronous-work-with-work-items.md).

# 使用工作项统一实时与异步工作

### 统一实时与异步工作：介绍 Zoom 呼叫中心 Work Items

呼叫中心长期以来一直在应对一个根本性的脱节：语音通话和聊天等实时渠道通过复杂的路由引擎流转，而工单、案例、发票、后续跟进等后台任务则留在各自独立的系统中。这种碎片化会带来运营上的麻烦，迫使坐席在不同平台之间来回切换，并让团队需要处理的所有工作难以进行智能优先级排序。Zoom 呼叫中心的 Work Item 功能/特性通过将异步任务视为一等可路由渠道，像呼叫或消息一样，改变了这一模式。让我们来看看它是如何运作的，以及它对你的呼叫中心运营意味着什么。

### 核心概念：将 Work Items 作为可路由渠道

从本质上说，Work Item 功能/特性引入了一个看似简单却很强大的想法：如果每一项工作——无论是一次实时电话呼叫，还是一项需要在三天后跟进的案例——都能通过同一个路由引擎流转，会怎样？Work Items 通过将异步任务转换为 Zoom 呼叫中心可以使用你已经为实时渠道配置好的相同全渠道逻辑进行路由、排队和分配的交互来实现这一点。这不只是把工单放在同一个界面里查看；而是要将一致的智能逻辑应用到坐席处理的每一次交互上。

### 解决真实的运营问题

传统方法会带来可预见的痛点。当 Zoom 呼叫中心为某位坐席分配处理一个传入的语音通话时，其他业务系统可能会同时向同一位坐席分配一个紧急案例或发票。由于这些系统彼此独立运行，无法看到对方的分配情况，这就会导致工作流冲突、客户响应延迟，以及坐席在管理相互竞争的优先事项时感到沮丧。独立的路由系统也意味着独立的配置、报告和优化工作。你本质上是在一屋之下运行多个呼叫中心，每个都有自己复杂的开销。Work Items 有助于消除这种碎片化。当每一项任务都通过同一个路由引擎流转时，你就能获得统一的容量管理、一致的优先级逻辑，以及坐席工作负载的单一事实来源。

### 架构与集成模式

Work Items 采用外部触发模型。Zoom 呼叫中心并不创建这些任务本身——你现有的系统（CRM、ERP、工单平台等）继续负责这一职责。相反，ZCC 专注于它最擅长的事情：路由、排队、分配和报告。集成通过 *启动交互 API*实现。当你的外部系统需要将工作路由给坐席时，它会向 Zoom 呼叫中心发起一次 API 呼叫，并提供 Work Item 详细信息。从那一刻起，ZCC 就接管路由和分配流程，将这类异步工作自动与实时渠道融合在一起。这个架构决策是经过深思熟虑的：你的业务系统仍然是每个 Work Item 的记录系统，而 Zoom 呼叫中心则作为统一的工作分发引擎。这样可以支持根据坐席技能、可用性和工作负载，对每一项任务——无论来源如何——进行智能路由。

### 配置深度解析

设置 Work Item 路由遵循 ZCC 管理员已经熟悉的基于流程的配置模型。该过程包括五个关键步骤：

1. **创建一个 Work Item 队列。** 这个专用队列将工作项交互与您的语音或聊天队列分开处理，使您能够将不同的服务级别目标和人员配置策略应用于异步工作。

<div data-with-frame="true"><figure><img src="/files/da73c2a118e0b0e192d7e9138b6473941764ee1b" alt="Image showing a Call Queue named &#x27;Work-Item&#x27;"><figcaption><p>创建 Work-Item 队列示例</p></figcaption></figure></div>

2. **构建一个 Work Item 流。** 使用标准的 ZCC 流编辑器，像为其他频道一样构建一个流，构建决定工作项如何在系统中流转的路由逻辑。此流连接到您的 Work Item 队列，并且可以像任何其他频道流一样包含基于技能的路由、优先级处理和溢出逻辑。

<div data-with-frame="true"><figure><img src="/files/1bc6d6a9fdacb6f3672213dee226722d801944c8" alt="Widgets within Zoom Contact Center&#x27;s flow builder creating a Work-Item flow"><figcaption><p>创建 Work-Item 流示例</p></figcaption></figure></div>

3. **生成一个入口标识符。** 这个唯一标识符将成为外部系统会呼叫的 API 端点，用于将工作项注入到您的呼叫中心。

<div data-with-frame="true"><figure><img src="/files/12554f5432aa9af658b9c230fb62b6be471ceb1f" alt="Screenshot showing how to locate an Entry ID for an endpoint in the Zoom web portal"><figcaption><p>查找条目 ID 的示例</p></figcaption></figure></div>

4. **将条目 ID 链接到你的流程。** 此关联会告诉 ZCC 在工作项通过 API 到达时使用哪个流程。

<div data-with-frame="true"><figure><img src="/files/846f64a654849cda5a24e6451210f6bf71f9bd44" alt="Screenshot showing how to link an Entry ID to a flow in Zoom Contact Center&#x27;s flow builder"><figcaption><p>将 Entry ID 链接到流程的示例</p></figcaption></figure></div>

5. **通过 Start Engagement API 进行集成。** 您的外部系统开始调用 ZCC API 端点，传递将转换为可路由接洽的工作项详情

```plaintext
5. curl https://api.zoom.us/v2/联系人_center/engagement \
5.   --request POST \\
5.   --header 'Content-Type: 应用程序/json' \\
5.   --header 'Authorization: Bearer YOUR_SECRET_令牌' \
5.   --data '{
5.   "work_item_variables": {
5.     "work_item_id": "24fwet23525",
5.     "work_item_name": "处理发票请求 24fwet23525",
5.     "work_item_desc": "根据标准规则审核发票",
5.     "work_item_type_id": 1,
5.     "work_item_type": "工作项",
5.     "work_item_origin": "发票系统",
5.     "work_item_priority": 1,
5.     "work_item_转写文字_url": "", 
5.     "工作项_超链接": "www.example.com/24fwet23525"
5.   },
5.   "流程": {
5.     "流程_条目_id": "rUCiH99999999zzz"
5.   },
5.   "语言_代码": "en-US",
5.   "频道": [
5.     {
5.       "频道": "work_item",
5.       "频道_来源": "API"
5.     }
5.   ],
5.   "消费者": [
5.     {
5.       "消费者_外部ID": "janet.smith",
5.       "消费者显示名称": "Janet Smith",
5.       "consumer_电子邮件": "janet.smith@example.com",
5.       "consumer_number": "+16505557772"
5.     }
5.   ]
5. }'
```

{% hint style="info" %}
**注意**

我们建议先创建一个服务器到服务器应用，参见我们的文档： [服务器到服务器内部应用](https://developers.zoom.us/docs/internal-apps/).
{% endhint %}

### API 机制与数据映射

Start Engagement API 使外部系统能够在 Zoom 呼叫中心内创建工作项。每个 API 请求都包含三类信息：

* **流程入口 ID** - 决定哪个流程将处理工作项请求，并将其导向相应的路由逻辑和队列
* **工作项信息** - 包括名称、描述和供代理在外部系统中打开并执行工作的超链接，以及优先级、到期日期和来源等其他元数据
* **消费者信息** - 最终消费者的姓名和联系信息，即应为其执行工作的对象。这些字段映射到可在您的流程中访问的 ZCC 全局变量，从而基于工作项属性启用自定义路由逻辑。例如，您可以将来自特定来源的高优先级项路由到专用专家队列，同时通过您的通用队列处理标准项。
* **重复预防**：API 会强制执行唯一性约束，以阻止重复的正在进行的工作项。如果您尝试使用与现有正在进行的参与记录相同的 work\_item\_id 和 work\_item\_name 组合创建工作项，API 将以错误拒绝该请求。此保护措施有助于确保您的外部系统不会为同一案例或工单意外创建冗余工作项。一旦原始参与记录关闭，如有需要，您可以使用相同的标识符创建新的工作项。这种行为对于幂等重试逻辑尤为重要——如果您的集成需要重试失败的 API 调用，您应先验证工作项是否确实已创建，然后再重新提交请求。要查看完整的 API 规范、字段定义和集成示例，请参阅 [Zoom 呼叫中心 API 参考](https://developers.zoom.us/docs/api/contact-center/#tag/engagements/post/contact_center/engagement).

### 座席体验与功能

对于座席而言，工作项会作为参与记录显示在 Zoom Workplace 应用中（可在 Windows、macOS 和 Web 上使用）。中间面板会显示工作项标题和说明，以及用于快速导航到源系统中详细信息的快捷 URL。右侧的参与记录详情面板可访问通过 API 传递的所有变量信息。座席可对工作项进行完整生命周期控制。他们可以在暂停工作时将项目标记为非活动，完成后关闭参与记录，并可随时访问未关闭和已关闭的参与记录以供参考或后续跟进。传递功能可在需要重新分配时将工作项路由到不同的队列或流程。主管通过强插监听功能保持监督，可在需要辅导或协助时加入工作项参与记录。这种统一界面有助于减少困扰传统工作流的频繁应用程序切换。无论座席是在处理语音通话、回复聊天，还是处理案件升级，他们都可以通过单一界面完成工作。

<div data-with-frame="true"><figure><img src="/files/a8cfb82fcee02e1239d9e448f7a7fc5a1c83a1f6" alt="Image showing an example of a routed Work Item in the Zoom Contact Center tab of the Zoom Workplace app."><figcaption><p>路由后的工作项示例</p></figcaption></figure></div>

### 工作项如何融入其他渠道

对于任何全渠道实施而言，一个关键问题是：“系统如何决定下一步分配什么工作？”当座席变为在线时，他们应该接收语音通话、聊天消息还是工作项？座席在语音通话期间能否同时处理多个工作项？答案是：这可使用现有 Zoom 呼叫中心路由机制进行完全配置。工作项可与三个关键 ZCC 功能无缝集成：

1. **消费者路由配置文件** - 控制来自特定消费者的互动如何被优先处理和路由
2. [坐席路由配置文件（基于技能的路由）](https://library.zoom.com/business-services/zoom-contact-center/expert-insights/agent-selection-using-skills-based-routing) - 根据坐席的技能，确定哪些坐席有资格处理哪些类型的工作
3. [坐席占用规则](https://library.zoom.com/business-services/zoom-contact-center/expert-insights/configuring-agent-occupied-rules) - 定义坐席可处理的并发互动组合。这些配置选项让你可以对以下问题进行精细控制：

* 坐席下一步接收的是哪种互动类型——语音通话、工作项，还是两者？
* 坐席能否一次处理多个工作项？
* 坐席在正在进行语音通话时，能否接收工作项？

通过利用这些现有的 ZCC 功能，工作项不需要单独的一套路由规则。相反，它们会参与到你已经为实时渠道配置的同一套智能分发逻辑中，从而确保真正统一的全渠道运营。

### 战略影响

Work Items 的真正价值远不止技术实现。通过将实时工作与异步工作统一到单一的路由引擎中，组织可以从根本上重新思考其运营策略。容量规划变得更加整体化。与其分别为电话队列和案件积压配置人员，不如根据总工作负载优化坐席总容量，让路由引擎依据实时情况智能分配工作。基于技能的路由保持一致。用于将复杂语音呼叫路由到专家的相同坐席技能，也可以将复杂案例路由给这些相同的专家，因此专业知识会被应用在最有价值的地方。报表和分析得到合并。你无需再从多个系统拼接指标，而是可以统一查看坐席生产力、频道表现以及整体运营效率。

### 展望未来

Work Items 代表着呼叫中心架构的成熟。随着客户旅程越来越多地融合同步和异步触点，"实时频道"与"后台工作"之间的人为分隔不再是合理的分工，而会成为一种负担。通过将所有工作都视为可路由的交互，Zoom 呼叫中心使组织能够通过单一平台高效处理全方位的客户服务。2025 年 11 月的初始版本以由 API 触发的 Work Items 奠定基础；未来增强功能很可能会扩展围绕工作项生命周期管理以及更深层次的集成模式。对于评估此功能的技术团队来说，关键问题不是是否采用 Work Items，而是你能多快集成外部系统，并开始通过你的全渠道引擎路由异步工作。一旦实施完成，统一路由、简化的坐席体验、合并报表等运营收益将迅速叠加。

有关以下内容的更多信息，请参阅 Zoom 的支持中心 [管理 Zoom 呼叫中心工作项交互](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083708) 和 [更改 Zoom 呼叫中心工作项队列设置](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083707).


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://library.zoom.com/technical-library/zh/shang-ye-ban-fu-wu/zoom-contact-center/expert-insights/unifying-live-and-asynchronous-work-with-work-items.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.