> For the complete documentation index, see [llms.txt](https://docs.omnichat.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omnichat.ai/features/tong-ji-biao/chat-dashboard-new.md).
# 對話報表
{% hint style="info" %}
此功能原名稱：聊天統計
{% endhint %}
## 日期區間
* 一進到網頁的預設日期，是從今天開始算到過去 14 天（兩週）
* 可以點選日期，去搜尋該日期區間的數據
* 搜尋新日期之後，整個頁面的數據都會同時被更新
* 當日數據每小時更新一次
* 「全部通訊渠道」可以篩選只看哪一個社群平台的對話紀錄量
## 上排數據總覽說明
* 總新增事件 = 新增機器人事件＋新增客服事件
* 新增真人客服事件：未觸發機器人模組進行互動都屬於客服事件，但機器人事件轉向真人客服事件則不會計算進去
* 新增機器人事件：觸發 「 社群渠道設定/歡迎訊息 」、 「 離線訊息/即時回覆 」、「 關鍵字自動回覆 」、「 社群身份綁定／綁定成功訊息 」 和 「 購物車再行銷/綁定成功訊息 」
{% hint style="info" %}
小提醒：對話事件在 「 已結束 」 狀態，當客人再次傳送訊息時，此時對話事件會進到 「 待處理 」 狀態中，也會算進一次 「 新增客服事件 」
{% endhint %}
* 機器人轉真人客服觸發時機：
1. 客人在機器人模組中點選按鈕導向 「真人客服 」
2. 客人在傳送訊息中，未打中任何關鍵字觸發機器人模組，也會轉向真人客服
{% hint style="info" %}
小提醒：從機器人事件轉到 「處理中」 的真人客服事件則不會被計算進去
{% endhint %}
* 跟進事件次數
* 同一個對話在還沒被結束前，跟進次數只會算一次（就算從 123 客服指派到 456 客服）
* 真人客服事件跟進率
* 計算方式：跟進事件/(新增客服事件＋機器人轉真人事件）
* 結束事件次數
* 計從 「 處理中 」 事件點擊 「 結束 」 按鈕即會計算一次，因此一個對話有可能被結束超過一次以上
* 範例：
* 對話 A 結束後，客人在同一個對話裡面，提出了另外一個問題
* 第二個問題再次被解決之後，這個對話 A 就產生了 2 個事件結束次數
{% hint style="info" %}
小提醒：若是因為 「 自動結束 」 功能結束的對話事件則不會納入計算
{% endhint %}
* 結束事件率
* 計算方式：結束事件次數／跟進事件次數
## 數據總覽常見問題
* 新增事件＆結束事件次數
* 這兩個是算法是分開獨立的
* 範例：
* 選擇的日期區間是 9/1 - 9/8
* 事件 B 在 8/31 新增的，但卻在 9/2 被結束
* 選擇的日期區間裡，事件 B 不會包含在『新增事件』，但事件 B 在 9/2 被結束次數會顯示在 「 結束事件次數 」
* Ｑ1：對話初始是 「 機器人對話 」，但客人從機器人訊息導到 「 真人客服 」，這種情況的事件怎麼計算？
* A1：以事件最一開始創建的狀態來記錄，所以這個事件只會記錄在「機器人對話」的總數裡面
## 圖表
### 新增事件統計
列出該日期區間，每天新增事件的次數
 
1. 預設顯示該日期區間中每天的數據，也可以選擇讓圖表顯示 「 每週 」 或 「 每月 」 的數據；每週都是以禮拜天～禮拜六，視為一週
2. 時段分析：時段分析將會按小時匯總數據資料，以協助管理者了解新增客服事件的趨勢
3. 點擊 「 下載 CSV 」 ：以 csv 格式，導出該日期區間的數據，方便其他數據分析用途
4. 圖表可支援放大區塊工具列
* 滑鼠移到想看的日期上，會顯示不同事件的占比
* 以圖 06-14 示範
* 06-14 總共有 47 個新增事件
* 新增機器人事件：81% = 38 個機器人事件 / 47 總共新增事件
* 新增客服事件：19% = 9 個客服事件 / 47 總共新增事件
### 事件處理統計
* 「 跟進事件次數 」只以第一個跟進的為主
### 平均等候時間
* 平均等候時間：每個事件從產生後，到被客服人員按下 「 跟進 」 的時間（待處理 -> 處理中）
* 平均值 = 選擇期間的每天平均等候時間加總／選擇期間的天數
* 平均值：可以當作每日平均等候時間一個基準，去觀察哪一天客人的事件會等比較久被跟進
### 平均處理時間
* 平均處理時間計算方式：不管是真人客服或機器人事件，從任何狀態（待處理、處理中）進到 **已結束** 都會被納入計算。
* 平均處理時間計算範例：
* 如果同一個事件移轉給多個客服人員：
* 客服 A 跟進 3 分鐘之後移轉客服 B
* 客服 B 跟進 4 分鐘之後移轉給客服 A
* 客服 A 跟進後在 5 分鐘之後結束此事件
* 客服 A 的處理時間：3 + 5 = 8 分鐘
* 客服 B 的處理時間：4 分鐘
* 平均處理時間：( 8 + 4 ) / 2 = 6 分鐘
* 平均值 = 選擇期間的每天平均處理時間加總／選擇期間的天數
* 「 平均值 」 可以當作 「 每日平均處理時間 」 的一個基準，去觀察哪一天客人的事件都用多少時間解決
### 平均回應時間
* 當對話已在成員「處理中」：每當客人又發送新的訊息時，團隊成員第一次作出回覆的時間差。\
如果客人發送了多個訊息，團隊成員才回覆，會以客人發出的第一則訊息時間計算。
* 報表時間範圍中的回覆時間平均值
* 計算方式：每個對話的首次回應時間加總／對話數
以下圖情境為例：
* 16:50 顧客發問，並在 16:50 也收到品牌端回覆 ⇒ 獲得一段回覆時間差（且此階段已完結）
* 16:50 顧客接續發問，並連傳 3 則訊息才收到品牌端回覆 ⇒ 這一個新階段的第一則顧客訊息與品牌成員回覆的時間差，就是第二段回覆時間差
### 平均首次回應時間
{% hint style="danger" %}
官網對話插件的對話尚不支援計算
{% endhint %}
* 首次回應時間：計算客服首次回覆客人第一則訊息的時間差（待處理 -> 第一次回覆）
* 計算方式：全部的首次回應時間加總 / 首次回覆次數
* 若客服人員重啟事件後，客人沒有傳送訊息，而是客服人員再次回復，則不算在首次回覆的數據。
以下圖情境為例：
* 13:45 時客人發送第一句訊息並開啟對話視窗（對話落在待處理），品牌成員跟進到處理中，17:29 首次回覆該名客人，此時這中間的時間差就是一段首次回應時間。
* 但若客人在對話處理中，又傳送新的訊息，此時儘管品牌成員有新的回覆，該回覆的時間差，也不會拿來計算平均首次回應時間（因該對話並未被結束、從待處理再到跟進後的首次回覆這個過程）
從待處理跟進此對話
跟進中送出的第一則訊息
### 遺漏訊息
定義：無論客人端傳送訊息落在哪個事件狀態，如果真人客服未回應時間差超過 720 分鐘，該次回應會被視為遺漏訊息。
{% hint style="info" %}
遺漏訊息計算會排除已結束對話。
* 已結束對話來源包含以下：
* 單一對話結束
* 批量結束
* 自動結束
* 對話單一解除綁定
* 停用團隊成員
* 團隊成員 > 編輯聯絡人 > 取消綁定
{% endhint %}
## 事件來源
* 顯示事件來源各個渠道的數量、占比
* 沒有被開通的渠道，依舊會顯示在這個區域
* 沒有開通的渠道數據會是 0（或是已開通但該日期區間沒有事件來源）
## 團隊成員統計
 
* 預設第一頁最多會顯示 10 個成員
* 點選團隊成員的名字會彈出圖表，顯示該團隊成員，每天事件處理統計的數據