> 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).
# Engagement Brief Hero 用例
由 Craig Letheren 编写
## 简介
Engagement Brief 是一份由 AI 生成的文档，由 Zoom 呼叫中心在客户互动结束后创建。它可以配置为自动生成，也可以由用户手动触发。Engagement Brief 会将对话转写文字、共享媒体和会议元数据整合为一份结构化、可直接共享的录制记录。这消除了手动记笔记的需要，并使 Engagement Brief 成为每次互动的权威记录系统。
## 前提条件
### Zoom 呼叫中心软件包要求
坐席必须将 Elite 软件包分配到其 Zoom 呼叫中心用户账户，才能生成 Engagement Brief。此要求具体适用于结束该互动的坐席，即使在对话过程中有多个坐席参与也是如此。
{% hint style="info" %}
请记住，Engagement Brief 会在互动结束时生成，前提是结束该互动的坐席的账户已分配 Elite 软件包。
{% endhint %}
## 配置与使用
关于如何配置和使用 Engagement Brief 功能/特性的详细说明超出了本文档的范围。
{% hint style="info" %}
有关如何配置和使用此功能/特性的指导，请参阅我们可通过下方所示链接在线获取的帮助中心文档。
* [启用 Zoom 呼叫中心 Engagement Brief](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085600\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953)
* [生成 Zoom 呼叫中心 Engagement Brief](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 类型。
* 不得配置为屏蔽敏感数据。
在生成 Engagement Brief 时，最多会有 50 个变量包含在互动后处理过程中。
### 模板
Engagement Brief 模板定义了 AI 在互动结束后生成摘要时使用的结构和部分。模板通过导航到以下位置在资产库中配置： [管理员中心](https://zoom.com/account) → CX 管理 → 呼叫中心 → 资源库 → [Engagement Brief 模板](https://zoom.com/cci/index/admin#/admin-assets#EngagementDocTemplates) 在 Zoom 管理员门户中。
#### 设计指南
为了获得最佳效果，我们建议您遵循以下设计原则：
* 使用文本和标题（H1-H4）的组合来定义部分层级。
* 使用描述性文本字段，让 AI 根据互动内容进行填充。
* 每个字段末尾都加上一个终止字符，后跟一个空格（例如“: ”），以便在生成的摘要中清晰区分字段名称和内容。
* 保持字段简洁，并使用描述性语言而不是规定性说明。例如，使用“客户情绪：”而不是“请描述客户感觉如何。”
{% hint style="info" %}
您定义的标题将在生成的摘要中保持原样显示。
{% endhint %}
#### 示例
下面是一个简单示例，其中包含三个部分，每个部分都有一个 H1 标题，后跟描述性字段；在生成 Engagement Brief 时，AI 可以清晰识别这些字段。
## 示例用例
以下两个场景说明了 Engagement Brief 如何为坐席及其组织带来即时且切实的价值。
### 技术故障排查：企业版软件支持
#### 场景
一位商业版客户在供应商端平台更新后，其企业版软件平台的 API 集成失败，于是联系技术支持。该视频呼叫持续近 25 分钟。支持技术员系统地引导客户完成一系列诊断步骤；检查配置设置、查看 API 错误代码、在沙盒环境中重现故障，并最终定位到此次更新引入的权限策略冲突。
在整个会议过程中，消费者通过视频聊天分享错误截图，并提供了一份详细的日志文件。到呼叫结束时，支持技术员已找到解决方案，但这次互动积累了大量技术细节：版本号、错误代码、配置路径，以及五个不同的故障排查步骤，这些都需要准确记录，以用于案例管理、后续跟进以及未来的知识库使用。
#### Engagement Brief 模板
下面是一个 Markdown 格式的示例模板，可复制/粘贴到 engagement brief 模板中，以重现此示例。
```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日的后续事项
Engagement Brief 通过将完整的对话转写文字、在会议期间共享的截图和日志文件，以及 ZCC 会议元数据汇编成一份结构化文档，从而减轻了这一负担。生成的 Brief 记录了问题陈述、解决路径、下一步行动以及交互时间线，而这些正是主管进行审核、同事接手后续工单，或知识库维护人员编写可复用解决方案文章所需要的信息。支持技术员在整个呼叫过程中都能专注于客户，而不必担心在呼叫结束后记录这次交互。
### 预约接待：汽车服务中心
#### 场景
一位汽车所有者联系一家汽车服务中心的客户服务热线，安排/定时发送例行保养，包括更换机油和刹车检查。客服人员每天要处理数十通这样的呼叫。接待流程结构化，但细节很多。客服人员必须收集：
* 客户的全名和联系人信息
* 车辆的品牌、车型、年份、当前里程和 VIN
* 确认所请求的服务
* 检查可用性
* 记录任何相关历史，例如客户提到的召回通知
在呼叫结束时，坐席需要完成一份内部服务订单表，并向客户发送其预约的书面确认。为每次呼叫手动执行此操作既耗时，又会带来转写错误的风险。错误的 VIN 或输错的电话号码可能会导致服务当日延误。
#### Engagement Brief 模板
下面是一个 Markdown 格式的示例模板，可复制/粘贴到 engagement brief 模板中，以重现此示例。
```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" %}
#### 互动简报如何提供帮助
对于像这样的大批量接收工作流，即使是很小的低效也会迅速累积。若没有 Engagement Brief，客服人员必须手动把每个细节——VIN、里程、服务项目、预约时段、召回代码——从呼叫中转移到服务订单表单中，然后再撰写并发送客户确认。转写错误的风险是真实存在的，而且这一过程会占用两次呼叫之间的时间。
有了 Engagement Brief，情况就会更改。当呼叫结束时，Engagement Brief 会生成一份结构化文档，预先填入客户的联系人信息、车辆信息、所请求的服务以及预约详情，这些内容直接根据转写文字和 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 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/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 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.
