> 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/engagement-brief-hero-use-cases.md).
# 互动简报 Hero 使用场景
## 简介
互动摘要是 Zoom 呼叫中心在客户互动结束后创建的一份 AI 生成文档。它可以配置为自动生成，或者由客服手动触发。互动摘要会将会话的转写文字、共享媒体和会议元数据整合成一份结构化、可直接共享的录制。这消除了手动记笔记，并使互动摘要成为每次互动的权威系统录制。
## 前提条件
### Zoom 呼叫中心软件包要求
客服必须将 Elite 软件包分配到其 Zoom 呼叫中心用户账户，才能生成互动摘要。此要求专门适用于结束互动的客服，即使在对话过程中有多位客服参与也是如此。
{% hint style="info" %}
请记住，只有在结束互动的客服的账户已分配 Elite 软件包时，互动摘要才会在互动结束时生成。
{% endhint %}
## 配置与使用
关于如何配置和使用互动摘要功能的详细说明超出本文档范围。
{% hint style="info" %}
有关如何配置和使用此功能的指导，请参阅我们可通过以下在线链接访问的帮助中心文档。
* [启用 Zoom 呼叫中心互动摘要](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085600\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953)
* [生成 Zoom 呼叫中心互动摘要](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085601\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953)
{% endhint %}
## 其他注意事项
### 变量
在会话结束时，会话的转写文字会与其他互动元数据一起发送以供处理，其中包括来自 Zoom 呼叫中心的全局变量和自定义变量。在生成摘要时，会考虑变量内容（例如，某个变量可能包含消费者的账户或保单号码）。
为了让模型理解变量的用途，变量必须具有有意义的名称和描述。为获得最佳效果，您必须避免使用通用或含糊不清的变量名称。
{% hint style="info" %}
变量的配置超出本文档范围。更多信息请参阅我们可通过以下在线链接访问的帮助中心文章： [此链接](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0059058\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953).
{% endhint %}
要满足互动后处理的条件，变量必须：
* 类型必须为 STRING、电子邮件或 URL。
* 不得配置为对敏感数据进行掩码处理。
在生成互动摘要时，最多会将 50 个变量纳入互动后处理。
### 模板
互动摘要模板定义了 AI 在互动结束后生成摘要时使用的结构和各部分。模板可在资产库中通过导航至 呼叫中心管理 → 资源库 → 互动摘要模板，在 Zoom 管理员门户中进行配置。
#### 设计指南
为获得最佳效果，我们建议您遵循以下设计原则：
* 使用文本和标题（H1-H4）的组合来定义部分层级。
* 使用描述性文本字段，让 AI 根据互动内容填写。
* 每个字段末尾使用一个结束字符，后跟一个空格（例如“: ”），以便在生成的摘要中清晰分隔字段名称和内容。
* 保持字段简洁，并使用描述性语言，而不是规定性说明。例如，使用“客户情绪：”而不是“请描述客户的感受。”
{% hint style="info" %}
您定义的标题将原样显示在生成的摘要中。
{% endhint %}
#### 示例
下面是一个简单示例，其中包含三个部分，每个部分都有一个 H1 标题，后面跟着描述性字段，在生成互动摘要时 AI 可以清晰识别这些字段。
## 示例用例
以下两个场景说明了互动摘要如何为客服及其组织带来立竿见影的实际价值。
### 技术故障排查：企业版软件支持
#### 场景
一位使用企业版软件平台的商业版客户在供应商侧的平台更新后，其 API 集成失败，于是联系了技术支持。视频呼叫持续了将近 25 分钟。支持技术人员系统地引导客户完成一系列诊断步骤：验证配置设置、查看 API 错误代码、在沙箱环境中重现故障，最终定位到此次更新引入的权限策略冲突。
在整个会话过程中，消费者通过视频聊天分享错误截图，并提供了详细的日志文件。到呼叫结束时，支持技术人员已经找到了解决方案，但这次互动积累了大量技术细节：版本号、错误代码、配置路径以及五个不同的故障排查步骤，这些都需要准确记录下来，以用于案例管理、后续跟进以及未来的知识库使用。
#### 互动摘要模板
下面是一个 Markdown 格式的示例模板，可复制/粘贴到互动摘要模板中，以重现此示例。
```plaintext
# 互动详情
- 时间与日期：
- 客户姓名：
# 客户问题
- 问题描述：
# 信息采集
- 错误代码：
- 配置详情：
- 故障排查步骤：
# 解决方案
- 问题是否已解决？
- 如果是，解决方案是什么？
- 下一步：
# 经验教训
- 已记录的知识：
```
#### 示例呼叫转写文字
| \[00:00]客户：您好，我想咨询一下我们的 API 集成——昨晚你们的平台更新推送生效后，今天早上它就停止工作了。
\[00:38]坐席：您好，很抱歉听到这个情况。我这里能看到您的账户。您能告诉我，哪个 API 端点报错了吗？
\[01:05]客户：是 /v2/messages/send 端点。我们收到了 403 Forbidden。现在我把错误截图发给您。
\[01:40]坐席：我收到了截图，谢谢。我能看到 403。这通常指向 OAuth 范围问题。您能确认一下您的应用当前被授权了哪些 OAuth 范围吗？
\[03:10]客户：我们有 聊天:write、聊天:read 和 users:read。一直都是这些，直到今天早上之前都运行正常。
\[03:45]坐席：明白了。昨晚的更新为消息发送端点引入了新的权限模型——现在频道需要 聊天:write.public，私信需要 聊天:write.direct。旧的 聊天:write 范围正在被弃用。我会在我们的聊天中分享迁移指南的链接。
\[05:20]客户：好的，我能看到链接了。所以我需要使用新的范围重新授权应用吗？
\[05:38]坐席：没错。我来带您一步步操作。首先，进入您的开发者门户——您能进行屏幕共享吗？这样我可以指导您。
\[06:00]客户：可以，现在屏幕共享已开启。
\[14:50]坐席：很好——您可以看到新的范围现在已经列出来了。点击重新安装应用并完成 OAuth 流程。完成后，再试一次访问该端点。
\[17:30]客户：成功了！200 响应回来了。太感谢了！
\[17:45]坐席：太好了！我会在您的工单中记录解决结果。还有另外两个受影响的端点——聊天:write.public 和 reactions:write——因此我建议您在它们于 6 月 30 日下线之前先检查一下。我会把这些内容都写进稍后发给您的工单摘要里。
\[24:10]客户：太好了。谢谢你这么细致！
|
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### 示例互动简报
此示例简报是根据此用例中详述的模板和对话生成的。
{% file src="/files/beb6254cba38a71c34550259b267ec2c15ead130" %}
#### 互动简报如何提供帮助
对于这样一个技术含量很高的支持互动，支持技术员通常会面临很重的文档负担。结束后，他们需要在管理队列的同时回忆并记录以下信息：
* 确切的错误代码
* 已采取的故障排查步骤
* 所需的具体范围更改
* 已交换的链接
* 标记为 6 月 30 日的后续事项
互动简报通过将完整的对话转写文字、在会议期间共享的截图和日志文件，以及 ZCC 会议元数据汇总到一份结构化文档中，来减轻这项负担。生成的简报会捕捉问题陈述、解决路径、后续行动，以及互动时间线——这正是主管进行审计、同事接手后续工单，或知识库维护人员编写可复用解决方案文章时所需要的信息。支持技术员在整个通话过程中都能专注于客户，而不必担心通话结束后还要补做文档记录。
### 预约接待：汽车服务中心
#### 场景
一位车主联系汽车服务中心的客户服务热线，想预约常规保养，包括换油和刹车检查。坐席每天要处理几十通这样的呼叫。接待流程结构化但细节繁多。坐席必须收集：
* 客户的全名和联系信息
* 车辆的品牌、车型、年份、当前里程和 VIN
* 确认所请求的服务
* 检查可用时间
* 记录任何相关历史，例如客户提到的召回通知
在呼叫结束时，坐席需要填写内部服务单，并向客户发送预约的书面确认。对每通呼叫都手动执行这一步既耗时，又会带来转写错误的风险。VIN 错误或电话号码输入错误，都可能导致服务当天延误。
#### 互动摘要模板
下面是一个 Markdown 格式的示例模板，可复制/粘贴到互动摘要模板中，以重现此示例。
```plaintext
# 客户详情
- 客户姓名：
- 联系信息：
# 车辆信息
- 车辆型号：
- 车辆年份：
- 当前里程：
- 车辆识别号码：
# 服务详情
- 请求的服务：
- 请求的预约时段：
- 相关历史：
```
#### 示例呼叫转写文字
| \[00:00]坐席：感谢您致电汽车服务中心。今天有什么可以帮您？
\[00:06]客户：您好，我想预约一次换油，并检查一下刹车。我觉得我听到了一点轻微的尖啸声。
\[00:18]坐席：当然可以！我可以帮您安排。可以先告诉我您的姓名和最佳联系电话吗？
\[00:24]客户：当然——Sofia，电话号码是 415-555-0192。
\[00:35]坐席：很好。请问您的车辆年份、品牌和车型是什么？
\[00:40]客户：是一辆 2021 Camry SE。
\[00:46]坐席：明白了。当前里程大约是多少？
\[00:50]客户：大约 38,500 英里。
\[00:54]坐席：谢谢。您手边有 VIN 吗？您也可以在挡风玻璃附近的仪表板上找到它。
\[01:10]客户：有——是 4T1B11HK0MU512347。
\[01:22]坐席：很好，我记下了。接下来是服务——标准的合成机油换油，以及全面刹车检查。我还看到有一个关于燃油泵模块的开放召回。您想让我们在同一次到访中一起处理吗？这是免费提供的。
\[01:42]客户：哦，我不知道有这个。是的，请一起处理。
\[01:48]坐席：当然可以。我们这周六上午 9 点或 11 点有空。哪个更方便？
\[01:55]客户：上午 9 点正合适。
\[02:00]坐席：已确认——周六上午 9 点，车辆为 2021 Camry SE，VIN 4T1B11HK0MU512347。服务包括：合成机油换油、刹车检查，以及燃油泵模块召回修复。您很快会收到电子邮件和短信确认。还有什么我可以帮您的吗？
\[02:18]客户：没有了，这就够了。非常感谢。
\[02:22]坐席：不客气。周六见！
|
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### 示例互动简报
此示例简报是根据此用例中详述的模板和对话生成的。
{% file src="/files/f983718a041c3d479785b8819ee3953f7498c154" %}
#### 互动简报如何提供帮助
对于这样高频的接待流程，即使是很小的低效也会很快累积。没有互动简报时，坐席必须手动将每个细节——VIN、里程、服务项目、预约时段、召回代码——从通话中转入服务单，然后再撰写并发送客户确认。转写错误的风险真实存在，而且这个流程会占用两次呼叫之间的时间。
有了互动简报，这一切就不同了。通话结束后，互动简报会基于转写文字和 ZCC 变量，直接生成一份预先填充了客户联系信息、车辆信息、所请求服务和预约细节的结构化文档。坐席可以先检查其准确性，并在结束该互动前做任何快速修改。
在坐席接起下一个呼叫之前，内部服务单实际上就已经完成。每周数百笔预约中，节省下来的时间相当可观，而数据录入错误的减少会直接转化为客户更顺畅的服务日体验。
---
# 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/engagement-brief-hero-use-cases.md?ask=&goal=
```
`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.