Chiho AI
Telegram 响应时间分析帮助你了解团队在所处理客户对话中的回复速度。Chiho 提供个人和团队报告，包含总体平均值、计入的回复数量以及对话级结果。
本指南讨论团队对客户的回复。它不估算 Telegram 官方支持服务回答账号或平台问题所需的时间。
在 Chiho 中创建响应时间报告
- 打开个人资料 → 分析，选择个人或相关团队。
- 选择想审核的日期范围。
- 选择创建报告，等待报告完成。
- 查看总体平均响应时间、消息总数和对话行。
- 需要在 Chiho 之外比较报告时，使用导出数据。
比较周期时，保持团队选择、日期范围和可用对话历史一致。已连接账号或已收集消息集合的变化，可能改变结果，而不代表人员工作方式发生变化。
了解当前计算衡量什么
Chiho 当前的响应计算按时间顺序处理可用消息。一条入站消息开始等待区间。另一条入站消息会替换起始时间。所选回复账号或团队发出的下一条消息结束区间，并记录一次回复。
这意味着区间从回复前最近一条入站消息开始，而不一定从客户第一条消息开始。记录一次回复后，后续出站消息不会形成另一个区间，直到出现新的入站消息。
完整示例
设想以下虚构对话：
- **10:00：**客户提出问题。
- **10:04：**客户补充细节。
- **10:10：**同事回复。
- **10:12：**同事发送第二段说明。
记录的响应区间为 6 分钟，从 10:04 到 10:10。这是一个响应区间，不是两个。从第一条消息起，客户已等待 10 分钟，但这回答的是另一个问题。
如果另一个已记录区间为 14 分钟，这两个区间的平均值为 10 分钟：(6 + 14) ÷ 2。用此示例解释指标，而不要默认它衡量的是首次响应服务等级。
报告目前将响应区间数量标为消息总数。应将该数字理解为测量到的回复，而不是全部入站与出站消息的总量。
使用平均值前要检查的三个局限
未回复消息不是已完成的响应区间
尚未收到回复的客户，不会为该次等待贡献已完成区间。因此，即使仍有未回复对话，报告也可能看起来很快。审核平均值时同时查看开放队列；记录到零次回复不应被理解为即时服务。
经过时间包含非工作时间
计算直接对消息时间戳做减法，不应用工作时间日历。客户周五晚间发来消息、团队周一回复，可能产生很长的经过区间，即使团队符合其声明的服务时间。审核结果时记录营业时间。
群组活动和可用历史会影响解读
在群组中，可能有多人参与交流。检查哪些人算作回复团队成员，并在将区间视为某个员工的表现前查看对话。历史缺失和不同报告窗口也会限制比较。
进行能够导向具体操作的每周审核
选择可比较的周期和相同团队范围。记录平均值、计入的响应区间和报告中出现的对话。然后查看一小组慢回复交流和未回复对话。
对每个样本询问：
- 下一步操作是否有明确负责人？
- 交接时是否丢失了客户问题？
- 团队是否在等待其他人的信息？
- 自动确认是否很快到达，但有用答复却晚得多？
- 交流是否发生在团队声明的工作时间之外？
为下一个周期选择一项流程变更：明确责任归属、澄清交接笔记，或在固定时间审核未解决问题。仅凭平均值变化，无法知道哪项干预起了作用。
共享 Telegram 收件箱指南解释如何整理队列。对需要进一步操作的对话，使用基于优先级的跟进。
将响应速度与未解决工作结合查看
快速确认和解决客户问题是不同结果。审核下一步操作、客户最新问题，以及问题是否真正关闭。避免通过发送无法帮助客户的消息来优化响应指标。
Telegram 支持升级技能可以帮助组织对需要关注的对话的审核。请求一份建议升级名单，并在修改任务或发送回复之前查看底层消息。
常见问题
这是客户获得首次回复前的平均时间吗？
当前计算使用符合条件的出站回复之前最新的一条入站消息。当客户连续发送多条消息时，它不是从第一条消息到首次回复的指标。向同事解释报告时，使用上面的完整示例。
什么样的响应时间算好？
根据客户期望、营业时间和请求紧迫程度设定目标。比较类似对话，并在审核已完成回复时同时查看未回复工作。通用数字会掩盖这些差异。
能直接比较两个团队吗？
需要谨慎。先检查其对话类型、可用历史、工作时间、业务量和发送者定义。用比较结果寻找值得调查的问题，而不要将平均值视为服务质量的完整衡量。
用较短报告周期试用 Chiho，查看几个来源对话，并在团队审核中使用该指标前确认其含义。