分析
阅读你的工单分析数据，把支持数据转化为决策。
工单分析指南
分析功能回答的是你无法通过滚动 Discord 直接看出来的问题：你的团队是否越来越快，哪个分类最耗时，以及你究竟什么时候需要有人在线值守。
完整的 Analytics 页面是高级功能。免费服务器只能看到带升级卡片的预览——以及仪表盘首页上直接显示的 最近 7 天 活动和员工图表。
打开分析
打开你的服务器仪表盘。
在侧边导航中点击 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 | 各优先级的分布情况 | 检查“Urgent”是否真的还意味着紧急 |
| 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 一直在反复出现。
一切都是“Urgent”
优先级分布几乎全是高优先级和紧急工单。
有帮助的做法： 成员设置的优先级只是愿望，不是事实。让 LunAI 来分类工单，然后再用 /ticket priority 进行修正。
工单历史
在图表旁边，Tickets → Ticket History 会列出这些数字背后的单个工单，并且每个工单都有自己的详情页。
分析告诉你发生了什么变化。历史记录和 transcripts 告诉你为什么会这样。
下一步
- Ticket Transcripts（数据点背后的故事）
- LunAI（自动优先级分类）
- Ticket Categories（更好的分类，更好的分析）
How is this guide?