> 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-tw/shang-wu-fu-wu/zoom-contact-center/expert-insights/engagement-brief-hero-use-cases.md).
# 互動簡報英雄使用案例
## 簡介
Engagement Brief 是一份由 AI 生成的文件，由 Zoom Contact Center 在客戶互動結束後建立。可設定為自動產生，或由客服人員手動觸發。Engagement Brief 會將對話逐字稿、共用媒體與會話中繼資料整合成一份結構化、可直接分享的紀錄。這可免除人工做筆記的工作，並使 Engagement Brief 成為每次互動的最終系統紀錄。
## 必要條件
### Zoom Contact Center 套件需求
客服人員必須在其 Zoom Contact Center 使用者帳戶中指派 Elite 套件，才能產生 Engagement Brief。此需求特別適用於結束互動的客服人員，即使對話中有多位客服人員參與也是如此。
{% hint style="info" %}
請記住，Engagement Brief 會在互動結束的當下產生，前提是結束互動的客服人員的帳戶已指派 Elite 套件。
{% endhint %}
## 設定與使用
如何設定與使用 Engagement Brief 功能的詳細說明，超出本文件範圍。
{% hint style="info" %}
如需如何設定與使用此功能的指引，請參閱下方所示連結中的說明中心文件。
* [啟用 Zoom Contact Center Engagement Brief](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085600\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953)
* [產生 Zoom Contact Center 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 Contact Center 的全域變數與自訂變數。產生摘要時會考量變數內容（例如，某個變數可能包含消費者的帳號或保單號碼）。
為了讓模型理解變數的用途，變數具有有意義的名稱與說明非常重要。為了達到最佳效果，您必須避免使用通用或含糊不清的變數名稱。
{% 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、EMAIL 或 URL 類型。
* 未設定為遮蔽敏感資料。
在產生 Engagement Brief 時，互動後處理最多會納入 50 個變數。
### 範本
Engagement Brief 範本定義了 AI 在互動結束後產生摘要時所使用的結構與區段。範本可在資產庫中設定，路徑為 Zoom 管理入口網站中的「聯絡中心管理 → 資產庫 → Engagement Brief 範本」。
#### 設計指引
為了獲得最佳結果，我們建議您遵循以下設計原則：
* 使用文字與標題（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]客戶：我們有 chat:write、chat:read 和 users:read。一直以來都是這些，直到今天早上都還正常。
\[03:45]客服：了解。昨晚的更新為訊息傳送端點引入了新的權限模型——現在頻道需要 chat:write.public，而私訊（DM）需要 chat:write.direct。舊的 chat:write 範圍即將停用。我會在聊天室中分享一個遷移指南連結給您。
\[05:20]客戶：好，我看到了連結。所以我需要用新的範圍重新授權這個應用程式嗎？
\[05:38]客服：沒錯。我會帶您一步一步操作。首先，請前往您的開發者入口網站——您可以分享螢幕讓我引導您嗎？
\[06:00]客戶：可以，現在已開始分享螢幕。
\[14:50]客服：很好——您現在可以看到新的範圍已列出。請點選「重新安裝應用程式」，並完成 OAuth 流程。完成後，請再嘗試一次這個端點。
\[17:30]客戶：成功了！200 回應又回來了。非常感謝！
\[17:45]客服：太好了！我會把解決結果記錄在您的案件中。還有另外兩個端點受到影響——chat:write.public 與 reactions:write——所以我建議在 6 月 30 日停用前先檢查它們。我也會把所有這些內容一併納入我將寄出的案件摘要中。
\[24:10]客戶：太完美了。謝謝你這麼細心！
|
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### 範例 Engagement Brief
此範例摘要是根據本使用案例中詳述的範本與對話所產生。
{% file src="/files/2551babc52ed96510d5188ddbe32d6726f30d379" %}
#### Engagement Brief 如何提供幫助
對於像這樣技術內容豐富的支援互動，支援技術人員通常會承受相當大的文件記錄負擔。在結束通話後，他們必須在處理待接來電隊列的同時，回想並記錄以下資訊：
* 準確的錯誤碼
* 已執行的疑難排解步驟
* 所需的特定範圍變更
* 交換過的連結
* 標記為 6 月 30 日前需跟進的事項
Engagement Brief 透過彙整完整的對話逐字稿、會話期間分享的截圖與日誌檔案，以及 ZCC 會話中繼資料，將這項負擔降到最低，並產生一份結構化文件。生成的摘要可記錄問題陳述、解決路徑、後續行動與互動時間軸，這些正是主管進行稽核、同事接手後續工單，或知識庫編輯者建立可重複使用的解決文章時所需要的資訊。支援技術人員可在整通電話中持續專注於客戶，而不必擔心互動結束後的文件整理。
### 預約受理：汽車服務中心
#### 情境
一位車主致電汽車服務中心的客服專線，預約例行保養，包括換油與煞車檢查。客服人員每天處理數十通這類電話。受理流程有固定結構，但細節繁多。客服人員必須蒐集：
* 客戶的全名與聯絡資訊
* 車輛品牌、型號、年份、目前里程數與車身識別碼（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]客服：不客氣。週六見！
|
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### 範例 Engagement Brief
此範例摘要是根據本使用案例中詳述的範本與對話所產生。
{% file src="/files/1312dae77e75b16297a63303c74efcd5a9e55f66" %}
#### Engagement Brief 如何提供幫助
對於這種高量的受理流程，即使是很小的效率損失也會很快累積。若沒有 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 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-tw/shang-wu-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.