> 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).
# 互動摘要 Hero 使用案例
由 Craig Letheren 撰寫
## 簡介
互動摘要是一份由 AI 產生的文件，Zoom Contact Center 在客戶互動結束後建立。它可以設定為自動產生，或由客服專員手動觸發。互動摘要會將對話逐字稿、共享媒體和工作階段中繼資料彙整成一份結構化、可直接分享的紀錄。這可免除人工記錄，並使互動摘要成為每次互動的最終權威紀錄系統。
## 必要條件
### Zoom Contact Center 套件需求
客服專員必須在其 Zoom Contact Center 使用者帳戶上指派 Elite 方案，才能產生互動摘要。此需求特別適用於結束互動的客服專員，即使在通話期間有多位客服專員參與也是如此。
{% hint style="info" %}
請記住，若結束互動的客服專員在其帳戶上指派了 Elite 方案，互動摘要會在互動結束時產生。
{% endhint %}
## 設定與使用
本文件不涵蓋如何設定與使用互動摘要功能的詳細說明。
{% hint style="info" %}
如需如何設定與使用此功能的指引，請參閱下方連結中的說明中心文件。
* [啟用 Zoom Contact Center 互動摘要](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0085600\&DeviceId=e6686144-67a3-4d5a-9326-ead1176f18d3\&SessionId=1784309024953)
* [產生 Zoom Contact Center 互動摘要](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。
* 未設定為遮罩敏感資料。
在產生互動摘要時，最多會有 50 個變數納入互動後處理。
### 範本
互動摘要範本會定義 AI 在互動結束後產生摘要時所使用的結構與區段。範本可在資產庫中設定，方法是前往 [管理中心](https://zoom.com/account) → CX 管理 → Contact Center → 資產庫 → [互動摘要範本](https://zoom.com/cci/index/admin#/admin-assets#EngagementDocTemplates) ，位於 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]客戶：我們有 chat:write、chat:read 和 users:read。一直以來都是這些，而且直到今天早上都還正常。
\[03:45]客服專員：了解。昨晚的更新為訊息傳送端點引入了新的權限模型——現在頻道需要 chat:write.public，私訊則需要 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]客戶：完美。謝謝你這麼細心！
|
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### 範例互動摘要
此範例摘要是根據本使用案例中的範本與對話內容產生的。
{% file src="/files/2551babc52ed96510d5188ddbe32d6726f30d379" %}
#### 互動摘要如何提供協助
對於像這樣技術性很高的支援互動，支援技術人員平時需要承擔相當可觀的文件記錄負擔。結束處理後，他們必須在管理佇列的同時，回想並記錄下列資訊：
* 確切的錯誤代碼
* 採取的疑難排解步驟
* 所需的特定範圍變更
* 交換過的連結
* 標記為 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/1312dae77e75b16297a63303c74efcd5a9e55f66" %}
#### 互動摘要如何提供協助
對於這類大量預約受理流程，即使是很小的效率低落也會快速累積。若沒有互動摘要，客服專員必須手動將每個細節——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 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-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 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.
