美洽的“未解决问题统计”就是把仍处于开放或待处理状态的会话/工单按时间、渠道、客服、标签等维度汇总，得到未解决量、未解决率、平均开放时长、SLA违约率等关键指标。你可以在平台的统计/看板里按条件筛选，也能导出原始数据在Excel或BI工具中复核。关键是先明确“未解决”的定义和时间窗口、去重与转人工的计数规则，然后选择合适的分组与可视化，才能把统计结果变成可执行的运营改进建议。
先把问题说清楚：什么是“未解决问题统计”
想象客服系统里的会话像一篮苹果，未解决的问题就是还没被挑出来放到结账台的那些。统计的作用就是帮你数清楚篮子里剩下多少，以及它们为什么没走完流程。简单来说，未解决问题统计包含三个核心要素：
- 对象：会话（IM会话、聊天记录）或工单（ticket）；
- 状态定义：什么算“未解决”？是“未关闭”“未回复24小时”“等待客户反馈”还是“被转人工但未处理”？不同定义结果差别很大；
- 时间窗口：统计的是实时快照、当天/周/月累计，还是历史某段区间的截止数量。
为什么要认真定义“未解决”？
如果没有一致的计数口径，数据会像没对齐的尺子：看似很多，但不能正确告诉你问题在哪里。举个例子：把“等待客户回复”的会话和“客服已处理，等待系统关闭”的会话都统计为未解决，会让未解决率被高估，进而导致资源误配。
在哪里查看（通用路径与平台差异）
不同客服平台的界面名字可能不一样，但常见逻辑相同。以常见的SaaS客服产品为例，查看未解决统计通常有两种方式：
- 控制台/看板直观查看：进入管理后台的“统计”、“报表”或“数据看板”，选择会话或工单维度，设置“状态=未解决”或相应筛选条件；
- 导出原始数据做深度分析：在会话或工单列表页导出CSV/Excel，或通过数据接口（API）把原始事件流拉到BI工具中做二次加工。
典型步骤——在平台控制台看板上做快速查看
- 登录管理后台，找到“统计”或“报表”模块；
- 选择数据维度（会话/工单），设置时间范围；
- 在状态筛选里选“未解决”“待处理”“开放”等对应项；
- 按渠道（web/微信/APP）、客服、标签等拆分结果；
- 查看趋势图、堆叠图，以及未解决的Top N标签或原因。
如果平台上看不全或口径不清：导出与复核的实用流程
看板方便但不一定透明。导出原始数据可以让你复核每一条是如何被判断为“未解决”的，步骤如下：
- 导出字段至少包括：会话ID、创建时间、最后更新时间、当前状态、最新处理人、标签、是否转人工、关闭时间（若有）、客户回复时间等；
- 在Excel或SQL中按自己的口径重算（例如：状态不等于“已关闭”视为未解决，或最后客服回复距今超过48小时视为未解决）；
- 按会话ID做去重，注意合并同一客户在短时间内的重复会话；
- 对“被机器人回复后转人工”的情况，决定是把它算作未解决直到人工处理完成，还是算作已启动处理，这对指标影响很大。
示例：Excel中常用的逻辑公式（思路级）
- 未解决标记（逻辑表达）：IF(Status<>“Closed” AND LastUpdateTime > StartWindow, “Open”, “Closed”)；
- 平均开放时长：对所有未解决会话取 NOW() – CreateTime 的平均；
- 未解决率：UNRESOLVED_COUNT / TOTAL_COUNT；
- SLA违约率：COUNT( OpenTime > SLA_threshold ) / TOTAL_COUNT。
关键指标与计算口径（必须明确）
下面给出一组常用且有操作性的指标与建议口径，按Feynman的思路把每个指标拆成“我为什么要看、怎么算、注意什么”。
1. 未解决数（Open Count）
- 为什么看：最直观的工作量；
- 怎么算：当前状态属于“未关闭/开放/待处理”的会话或工单总数；
- 注意：去掉重复会话、测试会话和机器人自动应答但无需人工的会话。
2. 未解决率（Open Rate）
- 为什么看：衡量整体未完成率，便于对比不同时间段；
- 怎么算：未解决数 / 总会话数（或总工单数）；
- 注意：选择合适的分母（当天到达的会话、某时间窗口内的会话或累计会话），口径不一致会误导判断。
3. 平均开放时长（Average Time Open）
- 为什么看：反映问题悬而未决的时长，长期开放说明流程或资源问题；
- 怎么算：对未解决会话取（当前时间 – 创建时间）的平均值；
- 注意：若包含长期停滞（例如等待客户反馈的会话），可分别统计“等待客服处理时长”和“等待客户时长”。
4. SLA违约率
- 为什么看：衡量对服务承诺的履行情况；
- 怎么算：超出SLA时限仍未解决的会话数 / 总会话数；
- 注意：区分首次响应SLA和解决SLA，两者都可能是运营优化的切入点。
5. 拥堵度与排队长度
- 为什么看：了解峰值压力和是否需要增加人力；
- 怎么算：某时间点或窗口内同时处于开放状态的会话/工单数；
- 注意：结合入量曲线看拥堵趋势，而非孤立地看一个时间点。
常见陷阱与如何排查（实际操作时经常踩到的地雷）
- 口径不一致：不同团队对“已解决”的定义不同——有的团队把“已回复且客户无回应”当成已解决，有的则等客户显式确认；解决办法：统一SOP并在报表注释口径；
- 重复会话高：同一问题被客户多次发起会话，导致未解决数膨胀；解决办法：按客户+时间窗口合并或标注重复；
- 转人工计数混乱：机器人回复后转人工的会话如何统计模糊；解决办法：把“机器人已处理但未人工确认”的单独归类；
- 时区与时间字段：多国业务时区混用会导致统计错位；解决办法：统一用UTC或明确本地时间转换规则；
- 数据延迟：日末导出数据可能与实时看板不同步；解决办法：在报告中标注数据刷新时间。
从数据到行动：如何把未解决统计用于改进
数据本身没有魔法，关键是把它们转成可执行的运营动作。下面是一个实用的闭环流程：
- 识别：用未解决Top N标签或渠道找出问题高发区；
- 分析：抽样复查未解决会话，确认是流程、权限、知识库、或第三方问题；
- 行动：对症下药：更新知识库、增加二线支持、调整SLA或增加机器人前置筛查；
- 验证：观察未解决数、平均开放时长和SLA违约率在下一周期的变化；
- 优化：把成功的改进固化成SOP并周期性复盘。
举个真实风格的例子（边想边写的那种）
前几周我们看到周五晚上的未解决会话激增，最开始以为是客服人手不够，但抽样后发现大部分是“物流查询”类：第三方接口超时导致客服无法确认物流状态。于是做了三件事：1) 把物流查询单独标记并给到专人跟进；2) 在知识库里加入临时兜底话术，减少人工等待；3) 同步给技术同事固定拉取频率。两周后，未解决相关标签数下降了40%，周五晚高峰的拥堵也明显缓解。这说明：真正的答案往往是“流程+角色+工具”一起修。
给运营/管理者的快速检查清单（到位就能用）
- 确认“未解决”口径并写入报表说明；
- 在看板里设置默认过滤（状态=未解决、时间窗口=近7天）；
- 每周导出一次原始数据做抽样复核；
- 按客服、渠道、标签三个维度做Top N分析；
- 记录每次改进后的KPI变化（未解决数、平均开放时长、SLA违约率）；
- 建立快速响应机制（比如：当未解决数超过阈值自动报警并临时调配人力）。
给数据工程/技术团队的建议（如果你能用数据接口）
如果可以拉原始事件流或使用API，推荐做这几件事来保证统计口径可复现：
- 在数据表里保留每次状态变更的事件（state_change log），这样可以重算任何时间点的“快照”；
- 把“等待客户/等待第三方/等待内部”作为独立字段记录，便于拆分开放时长；
- 保留会话被合并与被拆分的记录，方便排重和合并口径一致；
- 设置定时任务把当日快照导出并归档，便于历史回溯和审计。
示例表：关键字段与解释（一个可以直接复用的最小表结构）
| 字段 | 类型 | 说明 |
| session_id / ticket_id | string | 唯一标识，会话或工单ID |
| create_time | datetime | 会话/工单创建时间（统一时区） |
| last_update_time | datetime | 最后一次状态或消息时间 |
| status | enum | 开放、待处理、等待客户、已关闭等 |
| owner | string | 处理人/客服 |
| tags | string[] | 问题分类标签（物流、退货、技术等） |
| is_bot_handled | boolean | 是否机器人先行处理并转人工 |
| close_time | datetime | 若已关闭则记录关闭时间 |
最后再提醒几句（像在白板旁自言自语）
统计本身是工具，不是答案。真正有用的未解决统计是能把“数据问题”变成“可执行的改进建议”。在操作上，先把口径定好，再看数据，最后用结果推动流程、知识库和系统改造。还有一点：别光盯着未解决数孤立下降，要观察用户满意度和复购率有没有随之改善。这样，数据的背后才是价值，而不是数字游戏。