要看 HellGPT 每个成员处理了多少咨询，本质上是把“咨询”定义清楚，然后从系统日志和客服/工单平台里按成员（或账号）聚合会话或工单，做去重与跨平台合并，区分自动回复与人工参与，最后用会话数、消息数、解决率和平均响应时长等指标来呈现和校验结果。
先把问题说清楚：什么算“处理了一次咨询”
这一步像是在定规则。不同定义会得到完全不同的数字。举个比方：两个人聊了一轮，每人各自发了三条消息，这算两次咨询、六条消息，还是算一次持续会话？
- 会话（session）为单位：按一次用户发起到结束（超时或显式关闭）算一次，会话里可能有多人参与。
- 工单（ticket）为单位：按客服工单系统里的单独条目统计，适合有明确工单生命周期的场景。
- 消息（message）为单位：按消息条数统计，能体现工作量但会高估“咨询次数”。
- 问题/主题为单位：按用户实际问题或主题去重合并，更能反映价值，但实现上需要语义聚类。
通常推荐以“会话”为主指标，辅以消息数、解决率和时间指标来校验。
你需要的数据来源（哪里找）
想要得到靠谱的按成员统计，就必须从系统里拉日志和元数据。常见来源包括：
- 客服平台或工单系统（agent_id、ticket_id、status、created_at、closed_at）
- 对话/会话日志（session_id、participant_id、message_id、sender_type、timestamp、content_hash）
- 自动化模块/机器人日志（区分自动回复与人工接手）
- 外部渠道汇总：微信、邮箱、网页对话、电话转写等（要合并到统一的session层）
注意：
如果 HellGPT 在多个平台提供服务，需要先做渠道归并，按统一的 session_id 或通过时间窗+用户ID 做合并。
一步步做：从原始数据到按成员统计
1) 明确时间窗口与粒度
- 按天/按周/按月统计；初次建议先看周数据，能平滑偶发波动。
- 确定时区、是否包含测试账号、是否剔除内部沟通。
2) 清洗与去重
- 合并跨渠道同一用户的会话（通过用户ID或手机号/邮箱的哈希）。
- 去除系统生成的心跳/状态消息和重复推送。
- 识别并过滤测试/内部账号。
3) 归因规则（谁算处理人）
归因是关键，也是最常产生争议的地方。常见策略：
- 最后回复者归因：把会话计给最后一个有“解决”动作或最后一次回复的成员。
- 首次响应者归因：按第一个人工响应者计数，适合衡量响应速度。
- 工时拆分法：复杂会话按参与时间或消息数进行加权拆分（例如 A 参与 70%、B 参与 30%）。
选哪种看你的管理目标：关注“谁解决问题”就选最后回复者；关注“谁承担前线”就选首次响应或消息计数。
4) 计算核心指标（示例指标）
- 会话数（Sessions）：按上文定义的会话单位统计每个成员处理的会话数。
- 消息数（Messages）：成员发出的消息总数。
- 平均首次响应时长（ART）：用户发起到成员首次人工回复的平均时间。
- 平均处理时长（AHT）：从会话开始到会话关闭的平均时长（或从接手到关闭）。
- 解决率/关闭率：归因后该成员负责的会话中，标为“解决”或“满意”的占比。
示例 SQL 思路（伪代码）
下面给出一种常见的按“最后回复者归因”的思路，注意只是示例，需要根据你们的数据表结构调整。
思路：
- 从 messages 表里按 session_id 找到最后一条人工回复（sender_type = ‘agent’）和对应 agent_id。
- 把这条记录与 sessions 表 join，过滤时间窗口；按 agent_id 聚合会话数和其他指标。
| 示例字段 | 说明 |
| sessions.session_id | 会话唯一标识 |
| messages.message_id | 消息唯一标识 |
| messages.sender_id / agent_id | 消息发送者 |
（伪SQL）
SELECT agent_id, COUNT(DISTINCT session_id) AS sessions_handled, SUM(message_count) AS messages_sent, AVG(first_response_seconds) AS avg_first_response FROM (
— 找到每个会话最后一条人工回复并拿到 agent_id
) GROUP BY agent_id;
常见陷阱与如何避免
- 自动回复被误算：机器人或模板消息要打标记，跟人工消息区分开来。
- 多成员协作的重复计数：明确归因规则，或用加权拆分避免双重计数。
- 跨平台重复：用户在多个渠道同时发起，会话要合并或按规则分配主会话。
- 时区和时间窗：跨时区团队要统一时间基准，否则日报/周报看起来会错乱。
- 被动/主动的工作量差异：部分成员做主动回访或跟进，单看会话数可能低估其贡献，需要结合任务类型标签。
如何把结果做成可读的报表
报表不仅要告诉“谁处理了多少”，还要能支持管理决策。常见展示维度：
- 按成员+时间（天/周/月）的趋势图，识别周期性峰谷。
- 按渠道拆分（微信/网页/邮件），看谁在哪些渠道更忙。
- 按问题类型或话题聚合，判断成员的专长或薄弱环节。
- 结合客户满意度或二次回访率，评估质量而不仅是数量。
合规与隐私提醒
在提取会话和消息内容时，要尽量做数据脱敏、仅保留必要的元数据用于统计。遵守当地隐私法律（例如数据最小化、保留期策略、访问控制），对外展示时做匿名化处理。
如何验证你统计的“靠谱不靠谱”
- 做抽样审核：随机抽取若干会话，手工核对归因是否合理。
- 比较多种归因规则的结果差异（最后回复 vs 首次回复 vs 加权拆分），看差距在哪儿。
- 对比业务其他指标（比如满意度、重复问题率），检查是否存在统计偏差。
举个具体的、容易上手的工作流程
- 定义：团队会议上明确“什么是一次咨询”、“归因规则”和“统计口径”。
- 数据准备：从消息/会话/工单表导数据，合并渠道，过滤测试数据。
- 清洗：去重、去心跳、标注机器人消息。
- 计算：按选定归因规则跑聚合脚本，输出成员维度的会话数、消息数、ART、AHT、解决率。
- 验证：抽样审核、对比历史、检查异常值。
- 呈现：做日报/周报仪表板，支持下钻查看单会话详情。
最后说几句实操建议（像边写边想的那种）
刚开始别把统计弄得太复杂，先把“会话数”和“首次响应时长”做出来，能反映大多数日常工作量。等数据稳定后再引入加权拆分、语义聚类来衡量复杂问题。团队里最好有一位数据负责人和一位业务负责人一起定义口径，避免统计口径随便改引起争议。嗯，反正就是先把规则订明白，再把数据管干净，结果就不会让人怀疑。