> For the complete documentation index, see [llms.txt](https://docs.maiagent.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.maiagent.ai/serve/daily-operations/supervisor-guide.md).

# 客服主管指南

客服主管指南：每日與每週要看的事、排班與可用性、工作負載與改派、品質抽查、把答錯的問題變成 FAQ、怎麼讀對話平台分析，以及客服人員的權限配置。

這一頁給帶客服團隊的人：排班、看負載、抽查品質、把 AI 答錯的問題修掉，以及替新進客服開權限。客服人員本身的操作在 [客服人員操作手冊](/serve/daily-operations/agent-handbook.md)；轉接條件、派工模式等平台設定在 [客服轉真人設定](/build/conversation-settings/human-handoff.md)。

## 每日與每週節奏 <a href="#cadence" id="cadence"></a>

### 每日 <a href="#daily" id="daily"></a>

| 時間  | 做什麼                                                                  | 在哪裡                                                                            |
| --- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| 開班前 | 看今天誰可派：名單裡每位客服的狀態（可服務／暫停接單／排休中），請假的人排休有沒有設                           | [客服可用性](/build/conversation-settings/human-handoff.md#agent-availability)      |
| 開班前 | 看 <mark style="color:blue;">未指派</mark> 分頁有沒有昨夜留言（狀態列「等待真人客服」）        | [未指派的對話](/serve/daily-operations/human-handoff-operations.md#unassigned-queue) |
| 班中  | 看 <mark style="color:blue;">客服工作負載</mark>：排隊數、每人處理中件數、誰已滿載           | [客服工作負載](/build/conversation-settings/human-handoff.md#agent-workload)         |
| 班中  | 排隊太久或有人滿載時手動改派                                                       | 本頁 [工作負載與改派](#workload-and-reassign)                                           |
| 收班前 | 用 <mark style="color:blue;">依狀態篩選</mark> 選「處理中」，把已經處理完卻沒結案的對話批次改成已解決 | [批次更新狀態](/serve/daily-operations/reply.md#batch-update)                        |
| 收班前 | 看 AgentOps 對話紀錄的品質評分，低分的對話當天看過                                       | [AI 客服品質管理](/serve/ai-quality-guide.md#quick-start-three-quality-metrics)      |

### 每週 <a href="#weekly" id="weekly"></a>

| 做什麼                        | 在哪裡                                                                                |
| -------------------------- | ---------------------------------------------------------------------------------- |
| 抽查 AI 與真人的對話各幾則，照固定清單打分    | 本頁 [品質抽查流程](#quality-review)                                                       |
| 處理客服回報的「AI 答錯」清單，改知識庫或角色指令 | 本頁 [把答錯的問題變成 FAQ](#fix-wrong-answers)                                              |
| 跑一次對話平台分析，看主題與解決率的變化       | 本頁 [怎麼讀對話平台分析](#read-inbox-analysis)                                               |
| 檢查下週排休：請假的人設好排休、派工名單是否要調整  | [客服可用性](/build/conversation-settings/human-handoff.md#agent-availability)          |
| 看滿意度：倒讚與低分問卷的對話是哪些         | [滿意度回饋](/serve/daily-operations/human-handoff-operations.md#satisfaction-feedback) |

## 排班與可用性 <a href="#scheduling" id="scheduling"></a>

自動派工只會派給「在名單內、帳號啟用、可服務、不在排休、未滿載」的客服，四個條件缺一不可，見 [挑選客服人員](/build/conversation-settings/human-handoff.md#assignable-members)。排班時對應三件事：

1. **誰在名單裡**：每個對話平台各有一份 <mark style="color:blue;">可分配的客服人員</mark>，新人報到、同事轉組都要在這裡改。
2. **誰今天不在**：客服自己會切 <mark style="color:blue;">暫停接單</mark> 與設排休；忘了的話，主管可以在名單上直接替他改 <mark style="color:blue;">狀態</mark> 或點 <mark style="color:blue;">排休</mark>。替他人調整需要組織擁有者，或對該平台有編輯權限，見 [客服可用性](/build/conversation-settings/human-handoff.md#agent-availability)。
3. **非服務時間怎麼辦**：在 [服務時間](/build/conversation-settings/human-handoff.md#service-hours) 設定週幾幾點有人，離線行為選「接受留言」就會留在 <mark style="color:blue;">未指派</mark> 分頁等上班處理；選「顯示離線訊息」則不轉接。

<figure><img src="https://1593648278-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fmzb5NG9GDzFP2YDKeYVl%2Fuploads%2Fgit-blob-9496d88fce21ddb4a8d3fb2d6ec2db39f75bc845%2Fhandoff-dispatch-availability.png?alt=media" alt="派工設定分頁：派工模式與可分配的客服人員名單，每位客服旁有狀態下拉與排休按鈕"><figcaption><p>派工設定：勾選名單內的客服，並可直接替每位客服改「狀態」或設「排休」</p></figcaption></figure>

{% hint style="info" %}
想讓對話停在 <mark style="color:blue;">未指派</mark>、由客服自行認領，請把 [派工模式](/build/conversation-settings/human-handoff.md#dispatch-mode) 設為「接手制」，不要用清空名單的方式。接手制與留言模式下對話指派前不會寄 Email，要安排人定期看分頁。
{% endhint %}

## 工作負載與改派 <a href="#workload-and-reassign" id="workload-and-reassign"></a>

### 看負載 <a href="#watch-workload" id="watch-workload"></a>

[客服工作負載](/build/conversation-settings/human-handoff.md#agent-workload) 面板顯示每位客服處理中、已解決件數與狀態（排休中 > 暫停接單 > 已滿載 > 可派工），以及目前排隊中的對話數。判斷方式：

| 看到                  | 代表                    | 動作                                                                                      |
| ------------------- | --------------------- | --------------------------------------------------------------------------------------- |
| 排隊數持續大於 0，但有人是「可派工」 | 派工模式是接手制，或這些人不在該平台名單  | 請在線客服去 <mark style="color:blue;">未指派</mark> 認領，或把人加進名單                                  |
| 多數人「已滿載」            | 每位客服同時可接對話數太低，或大家結案太慢 | 調高 [容量](/build/conversation-settings/human-handoff.md#capacity-and-queue)，或先批次結案已處理完的對話 |
| 某人處理中件數遠高於其他人       | 路由模型是輪詢，或其他人常暫停接單     | 改用「最少負載優先」，或手動改派                                                                        |
| 排隊逾時常轉回 AI          | 等待超時時間太短，或人力不足        | 調整等待超時時間，開啟 [逾時重派](/build/conversation-settings/human-handoff.md#reassign-on-timeout)   |

<figure><img src="https://1593648278-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fmzb5NG9GDzFP2YDKeYVl%2Fuploads%2Fgit-blob-19743553e81d868507dab70926c04e50f890ceaf%2Fhandoff-agent-workload.png?alt=media" alt="派工設定分頁下方展開的客服工作負載面板：每位客服的處理中、已解決與狀態，下方顯示排隊中的對話數"><figcaption><p>「客服工作負載」面板：展開後看每位客服的處理中件數、已解決件數、狀態與目前排隊數</p></figcaption></figure>

### 手動改派 <a href="#reassign" id="reassign"></a>

* **未指派的對話**：在 <mark style="color:blue;">未指派</mark> 分頁把滑鼠移到對話上點指派圖示，或點開後用 <mark style="color:blue;">指派客服</mark>。
* **已有負責人的對話**：點開後按 <mark style="color:blue;">轉交</mark>，選同事並填轉接原因。
* 選人視窗會列出每位客服目前的進行中對話數、今日處理數與是否已達上限；目前負責人與已達上限的人無法點選，照負載挑人就不會把對話派給滿載的人。

操作細節見 [接手、轉派與轉回 AI](/serve/daily-operations/reply.md#handoff-actions)。

<figure><img src="https://1593648278-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fmzb5NG9GDzFP2YDKeYVl%2Fuploads%2Fgit-blob-ccb468047e21ff9a915e872e8238ddeefd60dcdf%2Fhandoff-transfer-modal.png?alt=media" alt="轉交對話視窗：轉接原因、選擇標籤與客服卡片，卡片顯示進行中對話數、今日處理數與目前負責人"><figcaption><p>改派時的選人視窗：卡片上有每位客服的進行中對話數與今日處理數</p></figcaption></figure>

### 需要分組時 <a href="#tag-routing" id="tag-routing"></a>

帳務、技術等問題要派給特定小組時，用 [標籤路由](/build/conversation-settings/human-handoff.md#tag-routing)：先在 [對話標籤管理](/build/conversation-settings/conversation-tags.md) 建標籤、把成員綁到標籤，再開啟 [對話分析](/build/conversation-settings/conversation-analysis.md) 讓系統在轉接時自動貼標。

<figure><img src="https://1593648278-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fmzb5NG9GDzFP2YDKeYVl%2Fuploads%2Fgit-blob-5d45d4fca40d3d2e0b870f56db3194bfa463537b%2Fconversation-tags-list.png?alt=media" alt="對話平台設定頁的對話標籤管理：列出帳務與發票、待修正、試用申請三個標籤與指派成員欄"><figcaption><p>對話標籤管理：每個平台各自建立標籤，「指派成員」就是標籤路由要派給的人</p></figcaption></figure>

## 品質抽查流程 <a href="#quality-review" id="quality-review"></a>

AI 回覆與真人回覆分開抽，判準不同。

### AI 回覆 <a href="#review-ai" id="review-ai"></a>

1. 開 AgentOps 的 <mark style="color:blue;">AI 助理監控</mark> → <mark style="color:blue;">對話紀錄</mark>，依 <mark style="color:blue;">品質評分</mark> 排序，低分的先看；Agent 要先開啟自動評估才有分數，見 [如何查看評估報告分數](/serve/ai-quality-guide.md#quick-start-three-quality-metrics)。
2. 用 [簡易判斷法](/serve/ai-quality-guide.md#simple-evaluation-method) 分三種問題：說錯（忠實性低）、答非所問（相關性低）、找錯資料（上下文精確度低）。
3. 每種問題對應的修法在 [三步驟改善方案](/serve/ai-quality-guide.md#three-step-improvement-plan)；要看 AI 當時查了哪些文件、用了哪個工具，用 [對話檢視器](/serve/daily-operations/reply/conversation-viewer.md)。
4. 每週統計用 [回覆品質追蹤](/serve/ai-quality-guide.md#response-quality-tracking) 的範本。

### 真人回覆 <a href="#review-human" id="review-human"></a>

每週每位客服抽 3～5 則已解決的對話（<mark style="color:blue;">依狀態篩選</mark> 選已解決，再看負責人），照下列清單檢查：

* [ ] 接手後第一則回覆有沒有讓客戶重講一次
* [ ] 有沒有先接手再回覆（沒有的話會和 AI 的回覆重疊）
* [ ] Copilot 建議有沒有核對再送（對照建議卡片的引用來源）
* [ ] 轉交有沒有填原因、摘要有沒有寫處理結果
* [ ] 結案時機：問題已解決才按解決，還在等後續的沒有提前結案
* [ ] 客戶若有倒讚或低分問卷，原因是什麼

對話的事件時間軸（誰接手、何時轉交、何時轉回 AI）在 <mark style="color:blue;">詳情</mark> 裡，見 [對話詳情](/serve/daily-operations/reply.md#conversation-details)。抽查結果拿來做 [客服人員操作手冊：常見錯誤](/serve/daily-operations/agent-handbook.md#common-mistakes) 的團隊回饋，不要只告訴個人。

## 把答錯的問題變成 FAQ <a href="#fix-wrong-answers" id="fix-wrong-answers"></a>

客服依 [AI 答錯要回報](/serve/daily-operations/agent-handbook.md#scenario-report-ai-error) 給你對話 ID、錯在哪、正確答案。建議先在各對話平台建一個「待修正」[對話標籤](/build/conversation-settings/conversation-tags.md)，客服貼上後你用 <mark style="color:blue;">依對話標籤篩選</mark> 一次撈出本週的清單。處理每一筆：

1. **分類**：知識庫沒有這個資訊、資訊過時、AI 找錯文件、還是 AI 有資料卻答偏了。
2. **修正**：
   * 答案固定、問法明確 → 在 AgentOps 對話紀錄把這則對話 [加入 FAQ](/build/agent-ops/add-to-faq.md)，問題改寫成通用問法、答案寫完整。
   * 知識庫文件過時 → 更新文件，依 [步驟 1：更新資料內容](/serve/ai-quality-guide.md#step-1-update-content) 的清單整理。
   * AI 有資料卻答偏 → 調整角色指令，依 [步驟 2：調整 AI 回答原則](/serve/ai-quality-guide.md#step-2-adjust-ai-answer-principles)。
   * 應該轉真人卻沒轉 → 補 [轉真人條件](/build/conversation-settings/human-handoff.md#transfer-conditions) 的描述。
3. **驗證**：用 [搜尋測試](/build/knowledge-base/test-search-result.md) 確認客戶原本的問法找得到新內容；改角色指令後用 [測試資料集](/build/agent-ops/test-datasets.md) 跑一次自動評估。
4. **收尾**：把對話標籤從「待修正」拿掉或換成「已修正」，並回覆提出的客服，他們才會持續回報。

同類問題一週出現 3 次以上，或涉及價格、政策錯誤，當天就修，優先序見 [日常檢查](/serve/ai-quality-guide.md#daily-checks)。

## 怎麼讀對話平台分析 <a href="#read-inbox-analysis" id="read-inbox-analysis"></a>

[對話平台分析](/serve/daily-operations/reply/inbox-analysis.md) 針對一個平台、一段期間的對話，用 AI 歸納主題、解決率與失敗原因。建議每週或每兩週跑一次，固定看四個地方：

| 先看                                                                           | 回答的問題                      | 接著做                                       |
| ---------------------------------------------------------------------------- | -------------------------- | ----------------------------------------- |
| [解決狀況](/serve/daily-operations/reply/inbox-analysis.md#resolution-status)    | AI 自己解決了多少                 | 解決率下降時，往下看失敗原因                            |
| [解決／失敗原因分佈](/serve/daily-operations/reply/inbox-analysis.md#failure-reasons) | 沒解決是因為知識庫缺口、指令太限制、工具失敗還是幻覺 | 知識庫缺口 → 補內容；指令過於限制 → 放寬角色指令；幻覺 → 加強知識庫與約束 |
| [熱門問題排行](/serve/daily-operations/reply/inbox-analysis.md#top-questions)      | 客戶最常問什麼、哪些主題解決率低           | 高頻且低解決率的主題優先補 FAQ，展開範例意圖看客戶真實問法           |
| [分析摘要](/serve/daily-operations/reply/inbox-analysis.md#synthesis)            | AI 的整體建議                   | 挑一兩項排進下週改善                                |

兩個常見用法：

* **改完想知道有沒有效**：分別對「調整前一週」與「調整後一週」各跑一份，比較解決率與失敗原因，見 [版本更新後影響評估](/serve/daily-operations/reply/inbox-analysis.md#case-version-impact)。
* **轉真人太多**：對照失敗原因，若「知識庫缺口」占多數，補知識比加人力划算。

即時的量化指標（對話次數、訊息數、滿意度）在 [使用分析](/build/agent/usage.md)；對話層級的成本在 [Credit 消耗彙總](/serve/daily-operations/reply.md#credit-summary)。分析會消耗額度，建立前確認日期範圍與取樣數。

## 權限怎麼配給客服 <a href="#permissions" id="permissions"></a>

權限在 <mark style="color:blue;">組織設定</mark> 的 [角色權限管理](/org/roles/role-permission.md) 設定。建議為客服與主管各建一個角色：

| 要讓他能做                                         | 需要                                                                                                                                                  |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| 進 <mark style="color:blue;">所有對話</mark> 接手、回覆 | <mark style="color:blue;">客服對話權限</mark> → <mark style="color:blue;">所有對話權限</mark>，並在 [分配對話平台](/org/roles/role-permission.md#assign-inboxes) 給他負責的平台 |
| 被自動派工                                         | 上一列，加上把他放進該平台的 [可分配的客服人員](/build/conversation-settings/human-handoff.md#assignable-members)                                                         |
| 用 Copilot 產生 AI 建議                            | 角色還要 [分配 AI 助理](/org/roles/role-permission.md#assign-chatbots) 到該平台綁定的 Agent，見 [誰可以使用](/serve/copilot.md#permissions)                               |
| 查聯絡人、改標籤與自訂屬性                                 | <mark style="color:blue;">客服對話權限</mark> → <mark style="color:blue;">聯絡人權限</mark>                                                                    |
| 改平台設定（轉真人、派工、Copilot）                         | <mark style="color:blue;">對話平台權限</mark>，且對該平台有編輯權限；一般客服不需要                                                                                          |
| 替同事調整接單狀態與排休                                  | 組織擁有者，或對該客服所在派工名單的任一平台有編輯權限                                                                                                                         |
| 跑對話平台分析                                       | <mark style="color:blue;">客服對話權限</mark> → <mark style="color:blue;">對話平台分析權限</mark>                                                                 |
| 看 AgentOps 品質評分、加入 FAQ、改知識庫                   | AI 助理與知識庫相關權限，通常只給主管與建置者                                                                                                                            |

{% hint style="info" %}
新客服報到的順序：建帳號 → 加入客服角色 → 在角色的分配對話平台勾他負責的平台 → 在各平台派工名單勾選他 → 派一則測試對話確認收得到通知。成員看不到對話時的檢查表見 [疑難排解](/org/roles/role-permission.md#troubleshooting)。
{% endhint %}


---

# 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://docs.maiagent.ai/serve/daily-operations/supervisor-guide.md?ask=<question>&goal=<user_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.