通过工作项统一实时和异步工作
作者：Justin Steinberg
统一实时与异步工作：介绍 Zoom 呼叫中心工作项
呼叫中心长期以来一直在与一个根本性的脱节作斗争：语音通话和聊天等实时通道通过复杂的路由引擎流转，而后台任务——工单、案例、发票、后续跟进——则留在各自独立的系统中。这种碎片化会带来运营难题，迫使客服人员在不同平台之间切换上下文，并让团队需要处理的所有工作难以被智能地优先排序。Zoom 呼叫中心的 Work Item 功能改变了这一范式，它将异步任务视为一等可路由通道，就像呼叫或消息一样。让我们来看看它是如何运作的，以及这对您的呼叫中心运营意味着什么。
核心概念：将工作项作为可路由通道
从本质上说，Work Item 功能引入了一个看似简单却强大的理念：如果每一项工作——无论是实时电话呼叫，还是三天后需要跟进的案例——都能通过同一个路由引擎流转，会怎样？Work Items 通过将异步任务转化为 Zoom 呼叫中心可以使用您为实时通道已配置的相同全渠道逻辑进行路由、排队和分配的互动，从而实现这一点。这不仅仅是在同一个界面中查看工单；更重要的是，将一致的智能逻辑应用到客服人员处理的每一次交互中。
解决实际运营问题
传统方法会带来可预见的痛点。当 Zoom 呼叫中心将一名客服人员分配去处理来电语音通话时，其他业务系统可能会同时把同一名客服人员分配给一个紧急案例或发票。由于这些系统彼此独立运行，无法看到对方的分配情况，这就会导致工作流冲突、客户响应延迟，以及客服人员在管理相互竞争的优先事项时感到棘手。不同的路由系统也意味着需要分别进行配置、报表和优化。你实际上是在同一屋檐下运营多个呼叫中心，每个都带着各自的复杂性开销。Work Items 有助于消除这种碎片化。当每项任务都通过同一个路由引擎流转时，您就能获得统一的容量管理、一致的优先级逻辑，以及关于客服人员工作负载的单一事实来源。
架构与集成模式
Work Items 采用外部触发模型。Zoom 呼叫中心并不自己创建这些任务——您现有的系统（CRM、ERP、工单平台等）继续承担这一责任。相反，ZCC 专注于它最擅长的事情：路由、排队、分配和报表。集成通过 开始互动 API。当您的外部系统需要将工作路由给客服人员时，它会向 Zoom 呼叫中心发起一次 API 调用，并附上工作项详情。从那一刻起，ZCC 接管路由和分配流程，自动将这些异步工作与您的实时通道结合起来。这一架构选择是有意为之：您的业务系统仍然是每个工作项的权威记录系统，而 Zoom 呼叫中心则充当统一的工作分发引擎。这支持根据客服人员的技能、可用性和工作负载，智能地路由每一项任务——无论其来源如何。
配置深入解析
设置工作项路由遵循 ZCC 管理员已经熟悉的基于流程的配置模型。该过程包括五个关键步骤：
创建工作项队列。 这个专用队列会将工作项交互与您的语音或聊天队列分开处理，使您能够将不同的服务级别目标和人员配置策略应用于异步工作。
构建工作项流程。 使用标准 ZCC 流编辑器，像构建其他频道一样构建一个流程，编写决定工作项如何在您的系统中流转的路由逻辑。此流程连接到您的工作项队列，并且可以包含基于技能的路由、优先级处理和溢出逻辑，就像任何其他频道流程一样。
生成入口 ID。 这个唯一标识符将成为外部系统将呼叫的 API 端点，用于将工作项注入您的呼叫中心。
将条目 ID 链接到你的流程。 此关联告诉 ZCC 在工作项通过 API 到达时应使用哪个流程。
通过 Start Engagement API 进行集成。 您的外部系统开始调用 ZCC API 端点，传递会被转换为可路由参与项的工作项详情
注意
我们建议创建一个 server-to-server 应用以开始使用，请参阅我们关于 server-to-server 内部应用.
API 机制和数据映射
Start Engagement API 使外部系统能够在 Zoom 呼叫中心中创建工作项。每个 API 请求包含三类信息：
流程入口 ID - 确定哪个流程将处理工作项请求，并将其引导到相应的路由逻辑和队列
工作项信息 - 包括名称、描述和超链接，供坐席在外部系统中打开并执行该工作，以及优先级、到期日期和来源等其他元数据
消费者信息 - 终端消费者的姓名和联系人信息，工作应为其执行。这些字段映射到可在你的流程中访问的 ZCC 全局变量，从而能够基于工作项属性实现自定义路由逻辑。例如，你可以将来自特定来源的高优先级项目路由到专用专家队列，同时通过常规队列处理标准项目。
重复阻止: API 强制唯一性约束，以阻止重复的有效工作项。如果你尝试使用与现有有效互动相同的 work_item_id 和 work_item_name 组合创建工作项，API 将以错误拒绝该请求。此保护措施有助于确保你的外部系统不会为同一个案例或工单意外创建冗余工作项。一旦原始互动关闭，如有需要，你可以使用相同标识符创建新的工作项。这种行为对于幂等重试逻辑尤为重要——如果你的集成需要重试失败的 API 呼叫，你应先确认工作项是否已实际创建，再重新提交请求。有关完整的 API 规范、字段定义和集成示例，请参阅 Zoom 呼叫中心 API 参考.
坐席体验和能力
对于坐席而言，工作项会在 Zoom Workplace 应用中显示为互动（Windows、macOS 和 web 上均在线可用）。中间讨论小组/面板显示工作项标题和描述，以及一个快捷 URL，便于快速导航到源系统中的详细信息。右侧的互动详情讨论小组/面板可访问通过 API 传递的所有变量信息。坐席对工作项拥有完整的生命周期控制。他们可以在暂停工作时将项目标记为无效，在完成后关闭互动，并可随时访问开启和已关闭的互动以供参考或跟进。如有必要，转移功能允许将工作项路由到不同的队列或流程。主管通过强插监听功能保持监督，在需要辅导或协助时可加入工作项互动。这一统一界面有助于减少困扰传统工作流的频繁应用程序切换。无论他们是在处理语音通话、回复聊天还是处理案件升级，坐席都能在单一视图中工作。
工作项如何融入其他频道
对于任何全渠道实施来说，一个关键问题是：“系统如何决定下一步分配什么工作？”当坐席在线时，他们应该接到语音通话、聊天消息还是工作项？坐席能否在进行语音通话时同时处理多个工作项？答案是：可使用现有的 Zoom 呼叫中心路由机制完全配置。工作项可与三个关键 ZCC 功能无缝集成：
消费者路由配置文件 - 控制来自特定消费者的互动如何被优先处理和路由
坐席路由配置文件（基于技能的路由） - 根据坐席的技能确定哪些坐席有资格处理哪些类型的工作
坐席占用规则 - 定义坐席可以处理的并发互动组合。这些配置选项可让你对以下问题进行精细控制：
坐席下一步会收到哪种互动类型——语音通话、工作项，还是两者都有？
坐席能否一次处理多个工作项？
坐席在正在进行语音通话时能否收到工作项？
借助这些现有的 ZCC 功能，工作项不需要单独的一套路由规则。相反，它们会参与你已经为实时频道配置的同一智能分发逻辑，确保真正统一的全渠道运营。
战略影响
工作项的真正价值远不止于技术实现。通过将实时和异步工作统一到单一路由引擎中，组织可以从根本上重新思考其运营策略。容量规划变得整体化。你无需分别为电话队列和案件积压配置人力，而是围绕总工作负载优化坐席总容量，让路由引擎根据实时状况智能分配工作。基于技能的路由得到一致应用。将复杂语音通话路由给专家的同一坐席技能，也可将复杂案例路由给同样的专家，因此专业能力会被应用在最有价值的地方。报表和分析得以合并。与其拼接多个系统的指标，不如获得对坐席生产力、频道表现和整体运营效率的统一可见性。
展望未来
工作项代表了呼叫中心架构的成熟。随着客户旅程越来越多地融合同步和异步触点，“实时频道”与“后台工作”之间的人为分离，正从一种合理的分工变成负担。通过将所有工作视为可路由的互动，Zoom 呼叫中心使组织能够通过单一平台高效处理全方位的客户服务。2025 年 11 月的初始版本通过由 API 触发的工作项奠定基础；未来增强很可能会扩展围绕工作项生命周期管理和更深层集成模式的能力。对于评估此功能/特性的技术团队来说，关键问题不是是否采用工作项，而是你能多快将外部系统集成进来，并开始通过你的全渠道引擎路由异步工作。实施完成后，统一路由、简化的坐席体验、合并后的报表等运营收益将迅速叠加。
请参阅 Zoom 的支持中心，了解有关以下内容的更多信息： 管理 Zoom 呼叫中心工作项互动 和 更改 Zoom 呼叫中心工作项队列设置.
最后更新于
这有帮助吗？