Chatbot 分析指南：KPI、儀表板與指標

聊天機器人分析應呈現客戶是否獲得有用的協助、還剩下多少人工工作，以及這項服務的成本。 先掌握對話量，分開計算確認解決與推定解決，追蹤人工轉接及無人回覆的轉接，並附上回饋的回答數。有足夠紀錄可衡量時，再加入經驗證的任務完成與重複聯絡。

一段沒有轉接給人工的對話結束，不代表問題已解決。同樣地，AI 產生的結果標籤、正面評分與已完成的退款，是不同類型的證據。每個指標旁都應定義統計母體、分子、分母與觀察期間。

下載合成聊天機器人分析工作表。其中有 20 段虛構對話，以及可編輯的結果審查、人工轉接、回饋、重複聯絡與成本分攤欄位。下方計算範例說明計算方式。這些是教學資料，不是客戶成果、產品測試，也不是 Quickchat AI 的匯出格式。

財務模型請參閱降低客服成本與聊天機器人 ROI 計算器。員工騰出的時間可用於其他工作，但只有支出實際減少，或避免了原本必要的開銷，才會成為現金節省。

可選的範例檢查工具

• 比較按解決計費的情境。調整提供的使用量與解決率假設來比較成本。此工具不會預測實際解決品質，也不會擷取價格。

• 估算測試回覆所需的點數。依提供的測試數、重複次數、每個案例的回覆數與模型計算點數。此工具不會執行測試，且不包含評估成本與外部工具費用。

前言：為什麼聊天機器人分析很重要

什麼是聊天機器人分析？

聊天機器人分析結合對話紀錄、系統事件、客戶回饋，以及取得得到的業務結果。實際用途是找出值得修正的問題，並檢查修改是否有幫助。

將三層證據分開：系統記錄了什麼、客戶回報了什麼，以及您獨立驗證了什麼。情緒是推斷出的標籤。問卷是受訪者提供的回饋。成功取消訂單則需要訂單系統中的證據。三者不能自動互相替代。

從一個客服佇列與固定期間開始。註明時區、哪些對話符合條件、如何處理重複資料，以及何時結束後續追蹤。比較修改前後相似的流量，並記錄可能解釋差異的產品上線、服務中斷或渠道組成變化。

依類別整理的核心聊天機器人指標

使用這些類別挑選一小組報表指標。它們描述可採用的衡量方式；實際可用性取決於平台、整合與資料蒐集設定。

核心使用者指標

對話數不是人數。同一個人可能透過不同工作階段或裝置回訪，而匿名訪客不一定能可靠地串聯。

不要將對話總數改稱為不重複使用者數。如果缺乏跨渠道身分識別，就分渠道回報數量並說明限制。

對話指標

時長與訊息量搭配結果後才更有意義。短對話可能以成功或放棄結束；長對話可能反映複雜度，也可能是回答反覆失敗。

若 AI 回覆延遲對工作流程重要，應獨立衡量。定義計時在第一個 token 還是第一個有用回答出現時停止。兩者都不同於轉接後等待人工回覆的時間。

結果指標

比較百分比之前，先寫出分母。以訊息為單位的失敗率與以對話為單位的解決率，回答的是不同問題。

在工作表中，fallback_messages 計算收到備援回覆的合資格訪客訊息，每則訪客訊息最多計一次。此例中，80 則合資格訪客訊息有 10 則收到備援回覆，因此為 12.5%。從總數扣除這個數量，算出的會是非備援回覆占比。最終成功的對話中，也可能曾出現備援回覆。

人工轉接也可能是正確的結果，例如客戶要求與真人交談，或授權程序需要員工審查。請依人工轉接工作流程評估這條路徑。

LLM 聊天機器人的 AI 專屬指標

將模型行為與供應商的計費單位分開。

我們的 token 解說介紹基礎概念。AI 點數文件說明平台的計費單位，包括測試期間產生的回覆。適用時，另行追蹤評估與外部服務費用。

解決率、每次解決成本與情緒

當證據與統計母體清楚時，這些衡量方式可以搭配使用。它們不是可互換的客戶成功指標。

AI 解決率

Quickchat AI 的 Analytics 文件定義了三種含有問題的對話結果：

• Confirmed Resolution： 訪客明確表示問題已解決。
• Assumed Resolution： 沒有明確確認，但推斷問題已解決。
• Unresolved： 問題未得到令人滿意的回答。

畫面顯示的計算方式為：

Reported resolution rate =
(Confirmed Resolution + Assumed Resolution)
/ (Confirmed Resolution + Assumed Resolution + Unresolved) × 100

Small Talk 被排除，因為沒有需要解決的實質問題。只有閒聊的期間沒有解決率。應顯示被排除的數量。

這些是系統回報的分類，不是對每項任務的獨立稽核，也不能證明之後沒有人再次聯絡。人工轉接是另一個維度；不要強行將每段已轉接對話塞入互斥的結果類別。所有類別都應抽樣審查，包括看似成功的對話。

每次解決成本

成本與結果必須採用相同的報表範圍。納入平台與使用費、連接服務、審查與維護工作，以及所選服務邊界內的人工客服。如果平台價格已包含模型費用，就不要再加一次。

Cost per defined resolution = Allocated operating cost / Count of defined resolutions

在合成工作表中，20 列資料每列都示範分攤 $6，總計 $120。因此，每次被分類為已解決的成本為 $10（$120 / 12），或每次經驗證自助服務成功的成本為 $15（$120 / 8）。相同成本可以有不同分母。這些虛構分攤值不是供應商價格，也不是產業基準。

為自己的報表記錄共用成本與人力的分攤方式。包含員工工時估值的成本是經濟成本，不一定是可消除的現金支出。若沒有符合條件的解決結果，應回報成本與零結果；此時比率未定義。有了 LLM，說話不再便宜討論了更廣泛的結果觀點。

對話情緒分布

Quickchat AI 的 Advanced 檢視顯示 Positive、Neutral 與 Negative 對話數隨時間的變化。可用它們挑選需要審查的對話。不要將負面標籤視為問卷回答，也不要假設每則訊息都有自己的情緒分數。

結合對話紀錄審查與主題模式，找出反覆發生的問題。區分自動發現的主題與團隊自行定義的類別。Topics 簡介介紹這些類別的整理方式。

深入理解分流率：公式、證據與改善方法

不同團隊使用「分流」時，可能指不同事物。請說明是沒有人工轉接、經驗證的自助服務成功，還是實際量測到的進件量減少。它們需要不同證據。

什麼是分流率？

在營運報表中，將留在自助渠道的比例（containment）定義為特定聊天機器人群組中沒有人工轉接的占比。它衡量的是路由，也包含未獲協助就離開的對話。

No-handoff containment = Conversations without a handoff / All cohort conversations × 100
Verified self-service share = Verified self-service successes / Eligible support conversations × 100

聲稱避免了一張工單，需要更強的證據：它要回答沒有聊天機器人時會發生什麼事。沒有人工轉接的數量本身無法建立這個反事實。在將工單需求減少歸因於聊天機器人前，應採用合適的比較或實驗。

為什麼重要：成本與客戶體驗影響

有用的自動化可能減少員工的重複工作，或縮短客戶取得答案的路徑。應檢查兩方面，而不是套用通用的節省百分比。

追蹤轉接後仍需完成的人工工作、重複聯絡的工作量與審查投入。若 AI 更快給出錯誤的政策解釋，仍可能增加工作。相反地，適當轉接即使降低了 containment，也可能保護客戶。

在宣稱 ROI 前，先將營運變化連結到實際帳單、加班費、人力需求或有紀錄的處理能力。

以合成工作表取代通用基準

使用可下載的 CSV，在試算表中重現這些數字。每一列都是虛構資料。群組包含 2026 年 10 月 1 日開始的 20 段對話：18 段初始客服對話對應 18 個不同問題，另有 2 段閒聊。後續重複聯絡是附加於初始問題的標記，不是新增的群組資料列。重複聯絡的計算期間是每段初始對話開始後的 7 天。虛構審查日期為 10 月 9 日，因此每個後續觀察期間都已結束。

CSV 的欄位是工作表欄位，不是 Quickchat AI 的匯出欄位。匯入試算表時，使用逗號分隔與 UTC 時間戳記。若跨語言共用計算，請維持欄位識別名稱不變。

調整方式如下：

1. 將虛構資料替換成已定義群組中每段初始對話一列的紀錄。對話 ID 與問題 ID 應分開：多段對話可能涉及同一問題，一段對話也可能包含多個問題。將重複聯絡連結回原始問題，不要再把它們新增為初始資料列。記錄審查截止點與後續觀察期間。
2. 依平台回報類別填入 resolution_label。將 Small Talk 排除於客服分母之外。分別記錄轉接與人工回覆的時間戳記。在 human_reply_status 中，區分 answered、unanswered、unknown 與 not_applicable。缺少回覆時間戳記絕不等於零秒；紀錄不可取得，也不能證明轉接後無人回覆。
3. 在 reviewed_ai_task_success 中獨立審查任務成功與否。對 same_issue_recontact_7d，串聯能可靠識別的各渠道後續聯絡。證據不可取得或觀察期間未結束時，使用 unknown；閒聊則使用 not_applicable。
4. 只有任務成功為 yes、重複聯絡為 no，而且沒有人工轉接時，才計入經驗證的自助服務。分母為所有符合條件的客服對話。此例中，有 3 項任務審查與 4 項重複聯絡檢查結果未知。它們仍在分母內，但不標記為失敗。8 / 18 是保守的經驗證占比，不會自動等同 First Contact Resolution。
5. 編輯後重新計算數量與比率。篩選已回覆的轉接，以秒數相減取得等待時間，並同時呈現平均數、中位數與已回覆／總轉接數。只平均已記錄的 CSAT 值。以表示有幫助的「yes」回答數，除以有記錄的有幫助程度回答數。成本欄加總一次，再除以選定的結果數。

此例的所有觀察期間都已結束，但仍有 4 段客服對話缺乏可靠的重複聯絡證據。14 段後續情況已知的對話中，有 5 段出現同一問題的重複聯絡。未觀察到重複聯絡，不代表客戶滿意，也不能排除經由未追蹤渠道聯絡的可能。

固定群組是一種教學方式。實際儀表板卡片可能依不同事件日期分組；比較匯出資料或重現圖表前，應先對齊日期規則。將 $6 的成本分攤替換成有紀錄的成本方法。若分母為零，百分比應顯示為不可用。

「好」與「壞」的分流

評估客戶是否獲得正確協助，以及需要時能否聯絡真人。高 containment 若同時伴隨重複聯絡、投訴或無人回覆的轉接，就需要調查。

問卷受訪者可能與沒有回應的使用者不同。除了明顯失敗的對話，也應審查部分未評分與被分類為已解決的對話。任何人工品質評分旁，都應標示樣本數與選樣規則。

AI Discord 工單機器人示範從知識內容回答，並在需要時建立工單。工單建立事件證明已升級處理，不代表最終解決。

不隱藏失敗的九項自助服務改善方法

1. 修正反覆導致錯誤回答的來源文章。
2. 將缺少的政策條件與例外加入知識庫。
3. 測試模糊、多語言與不完整的問題。
4. 以明確問題蒐集非強制回饋。
5. 讓客戶容易完成尋求人工協助的要求。
6. 宣稱成功前，驗證訂單、預約或帳戶 Actions 的結果。
7. 讓協助內容容易透過導覽與搜尋找到。
8. 修改提示或知識後，重新測試具代表性的案例。
9. 同時審查重複聯絡、無人回覆的轉接與平台回報的解決情況。

依發生頻率、對客戶的影響與審查證據，決定修改的優先順序。這些方法都不保證特定的解決率或節省比例。

AI 客服儀表板：將資料用於行動

有用的儀表板能將數字變化連結到可檢查的紀錄。將產品原生報表與需要串聯資料或人工審查的指標分開。

現代 AI 客服儀表板的構成

Quickchat AI 將總覽圖表、詳細趨勢與個別對話審查分開：

Advanced 文件說明圖表的位置。First Contact Resolution、獨立驗證的自助服務、跨渠道重複聯絡與完整營運成本，需要額外證據；此表不承諾這些是原生儀表板卡片。

必須追蹤的指標及其意義

Advanced 中的 Time to First Response 衡量已確認轉接後，等待第一則人工回覆的時間。它使用實際經過時間，包含隔夜等待。純 AI 對話與無人回覆的轉接，不會產生回覆時間數值。請閱讀回覆時間定義，並在時間統計旁顯示回覆涵蓋率。

Advanced 中的 CSAT Ratings 使用轉接後，從已連接客服系統收到的回饋。它與 Conversation Rating不同；後者啟用後，會在對話內蒐集體驗與有幫助程度的回饋。空白資料表示未記錄相關評分，不是零分。3 份評分不能代表工作表中的全部 20 段對話。

未解決主題與負面情緒有助於選擇調查對象。在判定原因前先閱讀對話紀錄：缺少知識、整合失敗、授權邊界，以及客戶偏好真人，需要不同的處理方式。

從洞察到迭代

每週進行一次簡短審查：

1. 檢查期間、母體與缺少的紀錄。
2. 在資料可用時，比較結果、人工轉接、回饋與重複聯絡。
3. 閱讀已解決、未解決、未評分與已轉接等不同對話。
4. 選定一個有證據支持的原因與範圍明確的修改。
5. 測試受影響情境，並記錄修改日期。
6. 重新檢查可比較的流量，也納入不利結果。

graph TD
    A[檢查範圍與缺少的資料] --> B[審查指標與對話];
    B --> C[選擇一項有依據的修改];
    C --> D[測試受影響的情境];
    D --> E[比較結果與限制];
    E --> A;

修改前後的改善是一項觀察。流量變化、其他版本發布與小樣本，都可能使因果結論無法成立。

建議工具與設定選項

先確定決策需要哪些資訊。只有能填補特定缺口時，更大型的報表系統才有用。

從 CSV 與既有產品檢視開始。當維護工作表持續成為限制時，再加入自動資料串聯。

逐步架構：建立聊天機器人分析系統

增加更多圖表前，先確立定義與負責人。

將業務目標對應至 KPI

對客服工作而言，一個有用的目標是提高特定任務的經驗證完成率，同時保留取得人工協助的管道。搭配未解決數、重複聯絡、回饋與營運成本來衡量。

對潛在客戶開發而言，先定義合格潛在客戶，並驗證資料已進入預定的 CRM 紀錄。提交表單或點擊連結是較早的事件，不會自動等於營收。Shopify 聊天機器人營收追蹤說明如何將 Agent 建立購物車所產生的訂單對應回對話；這種歸因仍不能證明聊天促成了購買。

建立基準後再設定目標。記錄負責人、預定修改與評估所需證據，不要借用通用產業百分比。

設定機器人與資料倉儲的量測

若需要額外衡量，請定義對話開始、轉接確認、人工回覆傳送與任務完成等事件。這些是建議的事件概念，不是承諾提供的 Quickchat AI 匯出欄位。

保留時間戳記、對話與問題識別碼、來源渠道，以及受評估設定的版本。記錄時區與延遲到達資料的處理規則。串聯多個系統前，先檢查數量是否能核對一致。

可用的審查與匯出流程請參閱 Inbox 文件。將共用分析中的個人資料減至必要範圍，限制存取，並定義保留與刪除程序。聊天機器人隱私指南說明更完整的資料流考量。以 ID 取代姓名，不會自動使資料集匿名化。

設計 AI 客服儀表板檢視

優先顯示使用量、回報結果與人工轉接。旁邊呈現已審查樣本數、未知結果與回饋數。人工回覆時間應與無人回覆的轉接並列。

在總覽下方，依穩定的主題分類整理未解決問題，並連結到具代表性的紀錄。成本分攤假設與後續觀察期間應清楚可見，不要藏在另一份報表裡。

依自己的基準與漏掉問題的後果選擇審查門檻。Quickchat AI 的 Manage Alerts用於找出符合條件的個別對話。不應將它描述成可針對任意彙總 KPI 門檻發出警示的內建引擎；那類用途需要適當設定的報表工具。

建立回饋循環

指派人員審查佇列，並安排負責維護相關知識或整合的人員。記錄修改，才能調查之後的變化。

使用 Testing執行可重複的情境，同時檢查自動評分與人工審查。模擬分數描述的是那些測試案例，不是正式環境的解決率。執行測試會消耗資源；上方可選預算工具只估算提供的回覆點數假設。

更新知識、編輯提示與微調模型是不同操作。依產品變更與觀察到的失敗安排審查，不要聲稱每個聊天機器人都需要每月重新訓練模型。

常見陷阱與避免方式

大多數報表問題始於定義不清楚或缺乏證據。

虛榮指標陷阱

更多訊息可能反映需求增加，也可能是反覆困惑。呈現活動量時，同時顯示完成的任務與客戶付出的努力。若修改使對話變長，應先調查原因，再決定額外互動是否代表成功。

不要將 containment 視為獨立驗證的解決，也不要將回報的解決視為避免了一張付費工單。

「設定後就不再管理」的問題

政策變化可能使原本正確的回答過時。為來源內容保留負責人，並在更新後測試重要工作流程。

除了回答品質下降，也要注意流量組成變化。新渠道或更困難的問題，可能在既有任務表現不變時，改變彙總比率。

LLM 回答中的偏誤與幻覺

自動評估器可能認同錯誤答案。對於影響較大的主張，例如政策例外與帳戶操作，應使用有來源支持的標準與人工審查。

樣本中應包含困難案例與相關語言。記錄模型標籤與審查者的分歧，不要將它們藏在平均值中。經整理的知識來源可以改善回答依據，但不保證正確性。幻覺解說討論這項限制。

整合瓶頸

檢查連接系統是否確實完成要求的操作。成功的請求、已建立的工單與已解決的客戶問題，是不同事件。

驗證存取權限、識別碼、回傳資料與失敗行為。操作失敗時，提供準確說明與可用的升級處理路徑。將這些失敗與知識缺口分開，讓工作交給正確的團隊。

透過關聯證據擴充聊天機器人分析

基本報表可靠後，可考慮將客服結果與重複聯絡、產品事件或已完成交易串聯。每次串聯都需要明確的身分識別規則與涵蓋範圍檢查。

對話中的問題也能啟發公開協助內容的改善。優先處理反覆出現的重要缺口，並驗證完成的文章。聊天機器人情緒、containment 或儀表板使用量，不能證明 Google 或 AI 搜尋系統會提高頁面排名或引用它。

結論：整合各項衡量

從一小組能解釋數字的報表開始。將分類結果、客戶回饋、經驗證的任務成功與人工工作分開，再一起使用它們來選擇修改。

第一個月可依以下順序進行：

1. 第 1 週： 達成定義共識並重現工作表計算。
2. 第 2 與第 3 週： 審查真實且獲准使用的樣本，找出缺少的紀錄並建立基準。
3. 第 4 週： 測試一項內容或工作流程修正，待後續觀察期間結束後，比較受影響的結果。

使用 Quickchat AI 文件說明的對話檢視，並保留業務所需的額外證據。目標是建立能清楚呈現假設與剩餘不確定性的審查流程。

常見問題

以下回答採用與上述工作表及產品功能對照相同的定義。

什麼是聊天機器人分析？它與網站分析有何不同？

聊天機器人分析檢視對話需求、回答、結果、人工轉接與回饋。網站分析檢視網站造訪與互動。將兩者串聯有助於理解使用歷程，但頁面瀏覽、對話、人與已解決問題是不同的計數單位。

如何在工單系統中計算分流率？

先定義分流。若指沒有人工轉接的 containment，就以未轉接對話數除以指定聊天機器人群組。若指經驗證的自助服務，就以無人工協助且符合完成與後續追蹤標準的問題數，除以符合條件的客服問題數。未解決與未知案例應持續可見。要主張聊天機器人導致工單減少，還需要額外比較證據。

SaaS 客服團隊的「良好」分流率是多少？

若沒有可比較的任務範圍、流量與定義，就不存在有用的通用百分比。應與自己的基準比較，同時檢查重複聯絡、回饋與取得人工協助的管道。SaaS 客服指南提供了需要不同成功標準的工作流程範例。

AI 客服儀表板應先顯示哪些指標？

先顯示對話量，分開呈現回報的解決類別、人工轉接、無人回覆的轉接與客戶回饋數。有證據時，再加入獨立審查的成功、重複聯絡與營運成本。每個百分比旁都應標示母體與觀察期間。

應多久重新訓練一次使用 LLM 的聊天機器人？

產品、政策、知識或設定有重大變更，以及出現失敗時，應進行審查。更新相關來源或提示後，再重新測試。更新知識與編輯提示，不等於微調底層模型。沒有通用的每月重新訓練要求。

改善聊天機器人分析真的能提高 SEO 排名嗎？

它可以找出值得在公開內容中回答的問題。Google 的實用內容指南強調有用且可靠的資訊。聊天機器人指標改善本身，不能證明排名或 AI 引用會提升。發布內容改善後，應另行衡量搜尋表現。

如何降低 token 消耗而不損害回答品質？

針對提示長度、擷取內容、回答長度或模型選擇，測試一項範圍明確的修改，並使用具代表性的案例。採用前先檢查事實正確性與任務完成情況。在 Quickchat AI，回覆點數取決於所選模型與 AI 回覆數，因此單一回覆使用較少 token，不代表計費點數必然減少。

將 CRM 與 AI 客服儀表板整合，最簡單的方式是什麼？

先找出需要的欄位與事件，再檢查支援的原生整合或 API。確認身分配對、權限與資料流向。建立聊天機器人連線，不會自動形成完整的分析資料串聯，或可靠的跨渠道重複聯絡指標。

開始聊天機器人分析需要資料科學家嗎？

不需要。小型工作表與對話紀錄審查，就能建立有用的定義並找出缺少的證據。進階群組分析或因果衡量可能需要專業協助。無論使用何種工具，都應顯示樣本數與未知值。

如何避免聊天機器人的語氣太機械？

在指示中設定清楚的語氣，移除重複用詞，並測試真實情境的對話。結合使用者回饋，一起審查清晰度、同理心與正確性。更親切的語氣無法彌補錯誤答案或受阻的人工轉接。