分析
讀取你的票務分析，將支援數據轉化為決策。
票務分析指南
分析能回答你無法只靠滑動 Discord 就得出的問題：你的團隊是否越來越快、哪個分類最耗時間，以及你究竟什麼時候需要人手在線。
完整的 Analytics 頁面是進階功能。免費伺服器只能看到預覽與升級卡片——以及儀表板首頁直接顯示的 最近 7 天 活動與人員圖表。
開啟 Analytics
開啟你的伺服器儀表板。
在側邊導覽中點擊 Analytics → Overview。
快速統計
頂部的四張卡片會摘要目前期間的狀況，並附上與前一期間相比的趨勢。
| Card | What it tells you |
|---|---|
| Total Tickets | 你的支援量 |
| Avg Response Time | 成員等待第一個回覆的時間 |
| Avg Resolution | 工單從建立到關閉的存活時間 |
| Returning Users | 有多少成員會帶著新工單再次回來 |
Avg Response Time 是你的成員最有感的數字。Avg Resolution 則是你的團隊最有感的數字。這是兩個不同的問題，需要不同的解法。
圖表
大多數圖表都有自己的 時間範圍選擇器：7 天、14 天、30 天、季度與年度。
| Chart | What it shows | Use it for |
|---|---|---|
| Ticket Activity | 每日開啟與關閉的工單數 | 找出積壓——關閉數應該跟上開啟數 |
| Category Distribution | 各分類的工單數，以及你的最高分類 | 決定哪些內容該寫進文件，或從源頭修正 |
| Staff Performance | 每位人員處理的工單數 | 找出你的主力成員並發現過載情況 |
| Response Time | 首次回覆與所有訊息的平均值 | 衡量排班調整的效果 |
| Messages per Ticket | 每張工單平均往返訊息數 | 數值過高通常代表你的步驟問得不夠完整 |
| Returning Support Users | 新增與回流的支援使用者 | 回流率高表示問題其實沒有真正解決 |
| Ticket Priority Distribution | 優先級的分布情況 | 檢查「緊急」是否真的還代表緊急 |
| Ticket Resolution Time | 從建立到關閉的平均時間 | 觀察長期趨勢 |
| Ticket Creation Patterns | 按小時與日期的分布，包含尖峰時段與尖峰日 | 規劃人員應該何時在線 |
如果某個圖表顯示 Not enough data — Come back later…，只是因為該範圍內目前還沒有足夠的已關閉工單。不是系統壞掉了。
解讀數據
開啟與關閉的數字開始分岔
你的 Ticket Activity 圖表顯示連續好幾天開啟的工單比關閉的更多。這代表積壓正在形成。
有幫助的做法： 根據 Creation Patterns 在尖峰時段增加人手、把 global open limit 調低作為緊急煞車，或對已經處理完成的工單使用 auto-close scheduling。
某個分類一枝獨秀
Category Distribution 圖表有 60 % 都集中在同一個主題。
有幫助的做法： 把那個主題整理成 FAQ、置頂訊息，或使用一個會關閉工單的 step option that closes the ticket，並附上答案連結。
每張工單的訊息數持續上升
每張工單都需要越來越多來回溝通。
有幫助的做法： 使用 ticket steps。在對話開始前就先詢問版本、平台或已驗證帳號 before the conversation starts。
回流率很高
同一批成員一直回來開新工單。
有幫助的做法： 閱讀幾份回流成員的 transcripts。不是答案沒有真正解決問題，就是同一個底層 bug 一直反覆出現。
一切都變成「緊急」
優先級分布幾乎只剩高與緊急工單。
有幫助的做法： 成員設定的優先級只是願望，不是事實。讓 LunAI 來分類工單，再用 /ticket priority 修正它。
工單歷史
在圖表旁邊，Tickets → Ticket History 會列出這些數字背後的單一工單，並為每張工單提供詳細頁面。
Analytics 告訴你改變了 什麼。歷史紀錄與 transcripts 則告訴你 為什麼。
下一步
- Ticket Transcripts（數據點背後的故事）
- LunAI（自動優先排序）
- Ticket Categories（更好的分類，更好的分析）
How is this guide?