客服周报怎么写：接通率、满意度、工单量怎么拆成三段

客服组长每周五下午交一份周报，接通率 94%，满意度 4.8 分，工单量 1320 单，三个数都达标，老板看完只问了一句：「上周那批投诉处理完了吗？」为什么三个数全部达标的周报，老板还是不满意？

她翻遍表格，没找到。这三个数没错，错的是这三个数回答的不是老板的问题，那投诉这一块到底该写进哪个数里？

客服周报的特殊性在于：它处理的每一个数，背后都有一个具体的人。运营的留存率跌了 3%，是一个统计现象；客服的接通率跌了 2%，是有人打了三次电话没人接。

所以客服周报如果只报量，等于只报了半件事，另一半是这些量说明了什么、哪些问题反复出现、哪个环节下周要先堵。

站内前面写过几篇讲通用周报怎么写的，一篇是 30 分钟用 AI 写完周报：从流水账到老板愿意看的四步法，一篇是 月报、季度总结别写成流水账：用 AI 理数据出结论的四步法，还有 运营周报怎么写 讲的是「数据涨了老板问原因」，客服岗多出来的那个约束，具体会怎么改写周报？

那三篇解决的共性是「把流水账改成有结论的文档」，客服岗多一个约束：结论必须能落到具体动作，否则投诉会重复发生。

客服周报和其他周报差在哪

判断客服周报写得对不对，有一个很省事的办法：随便挑一个数，问自己「如果这个数下周还是这样，能不能避免」。那接通率一直稳在 94% 的时候，周报还有必要写吗？

接通率 94% 这个数，如果下周还是 94%，说明人力排班没变，那它就没有决策价值 —— 老板看完不知道该做什么，反过来，如果写成「周三下午 2 点到 4 点接通率 71%，原因是两位客服同时去处理线下工单」，那这个数下周可以被改，那没有明显波动的时候，归因是不是就没得写了？

差别在于客服周报的核心交付物不是量，是从量里读出来的流程漏洞。

这个差别来自客服岗的工作性质。运营的指标变化是一个聚合结果，要靠归因去推；客服的指标变化往往直接对应某个具体环节，比如排班、话术、工单流转、权限设置。

所以客服周报的写法有一个固定套路：量 → 环节 → 动作。先把量摆清楚，再指出量出问题在哪个环节，最后给出下周要改的具体动作。

那三个环节具体指什么？下面按三段分别说。这四个环节里最难定位的是哪一个？

第一段：量能说明什么，只放三个数

客服岗的指标很多，全放进正文一定超载，一个务实的做法是只放三个数，且必须是能对应到动作的那三个，客服周报的三个数建议这样选：

• 接通率，它对应排班和响应机制
• 一次解决率，它对应话术能力和工单流转
• 投诉量与集中度，它对应产品或流程漏洞

满意度分数可以作为第四个可选数，但不要当主角。

原因是满意度太综合：它受客户心情、等待时长、问题难度影响，同一个 4.8 分可能对应完全不同的服务状态。

而接通率掉 2 个点，几乎一定是某个环节出了具体问题，选数的判断标准可以更直接：这个数变了以后，你能不能立刻说出一个要改的动作，能，就放进第一段；不能，说明它更适合放到附录。

第一段还有个容易忽略的细节：三个数都要带上周对比，并且带一句方向判断。

不是「接通率 94%」，而是「接通率 94%，较上周降 2 个点，是连续第二周下降」。

连续两周同向下降，和单周波动，含义完全不同，前者是趋势，后者要找出具体那天发生了什么。

第二段：问题落在哪个环节

这是客服周报最值钱、也最容易被跳过的一段。

跳过的写法是「本周用户反馈集中在物流和账号问题上」。这句话里没有可指认的环节，也没有可指认的动作，客服岗的问题几乎总能落到四个环节之一：遇到一个落不进这四类的问题该怎么处理？

• 排班环节，峰值时段人力不够，或者坐席被非接线任务占用
• 话术环节，同一个问题不同坐席给的答案不一样，或者自助引导没覆盖
• 工单环节，转出之后没人跟，或者跟了但没闭环
• 产品环节，用户反复遇到同一个操作障碍

这四个环节对应的责任方不同，写周报时要说清是哪一个，因为下周要改的动作不一样。

排班环节的证据通常来自时段分布：某个时段接通率明显低于全天平均，话术环节的证据来自重复咨询：同一问题一周内被问了 20 次，工单环节的证据来自超时率：转出工单里有多少超过约定时限，产品环节的证据最硬，通常直接有用户在评论里写出来。

判断该把问题归到哪个环节，有一个简单办法：问这个问题需不需要用户离开当前页面。

不需要离开但还是卡住了，多半是话术或引导问题；需要离开才解决，多半是产品问题。

第三段：下周堵哪一个

第三段是客服周报区别于报表的地方，只有两段的周报，半年后回头看会发现每个月的结论都一样，因为没有动作，写法上有一个原则：一周只写一个主攻方向，加最多一个次要方向，主攻方向要满足两个条件：它是本周量级最大的问题，同时它的改动成本在一周内能落地，那如果本周量级最大的问题改动成本超过一周，该怎么写？

比如本周投诉最集中的是「改了密码之后登不上」，那主攻方向就是复现这个流程，测出卡在哪一步，下周出结论。

不要写「优化用户体验」这种没法验收的方向。方向要能回答一个问题：做完之后，哪个数会变。

有一类情况要特别处理：问题定位不了的时候怎么办。

这种情况很常见，尤其是产品类问题。正确写法是「本周已确认是产品侧问题，已同步给产品团队，修复时间待定，下次周报跟进进度」。

比硬凑一个原因有用得多。老板看到的不是「她说不清」，而是「她已经升级了并且在跟」。

三个最容易翻车的地方

一、把投诉当个案处理

客服周报最常见的一个错，是把投诉当成零散事件，「本周收到 12 条投诉，其中 8 条已处理完毕」这句话里的信息量接近零，因为它没有说 12 条投诉是不是同一件事，正确做法是先聚类再统计，12 条投诉里有 5 条都是同一个问题，那么本周的投诉量是 1 个问题出现 5 次，而不是 5 个问题各 1 次，那聚类这件事能不能直接交给 AI？

这两种说法的处理方式完全不同。前者要找产品修，后者要找话术补。

二、只报总量不报分布

「本周工单 1320 单」这个数几乎没有决策价值，因为它掩盖了全部结构，同样 1320 单，可能是一周均匀分布，也可能是某天 800 单，集中爆发和均匀分布要采取的动作不一样：集中爆发要查突发原因，均匀分布要查容量，那选哪个维度拆最省事？

客服周报里的数至少要有一个维度可以拆：按时段、按问题类型、按处理结果，三者选一。

选的维度应该是这周真的有差异的那个，而不是固定维度。比如本周如果只有投诉量有集中现象，就按时段拆接通率、按类型拆投诉，量本身不用拆。

三、把 AI 生成的归因当真

客服周报是 AI 最容易编数字的地方，因为它结构固定、指标清晰，模型很擅长补全一段看起来合理的归因。

风险在于模型会替你猜原因。你把「本周投诉 12 条」丢进去，它可能写出一段「主要因用户操作不当导致」，这句话没有任何数据支撑，那要怎么样才能发现它编了一个原因？

防御方法是在提示词里加硬约束，并且每次都人工核一遍归因的数据来源。

每一个归因都必须能追到一个具体的数字或者一条具体的记录，追不到就删掉或者标成待确认。

怎么让 AI 帮你把这三段填起来

客服周报最费时间的不是写，是从几百条工单里聚类，这个环节可以交给 AI，但必须你先把边界划好，那第一步的聚类要做到什么粒度才算够？

第一步，把原始工单数据整理成一张表，每行一条工单，字段至少要有：时间、问题类型、是否转出、是否在时限内关闭、处理人。

然后让 AI 只做一件事：按问题描述聚类，输出每个聚类的条数和占比。

这一步不要让它给原因，只让它分组，原因判断是下一步的事，且必须由你确认，第二步，让它基于聚类结果出归因候选，每个候选必须标注对应的工单条数，这一步能过滤掉大部分编造的归因，因为它必须报数字。

第三步，把确认后的归因喂回去，让它按三段结构生成周报正文，并明确要求「不得出现未在工单数据中出现过的分类或数字」。

提示词可以直接用下面这段：

最后一步必须自己读一遍，而且要重点读第二段，AI 帮你省下的时间是聚类和排版，判断哪个环节是真问题、哪个投诉该升级给产品，依然是你自己的活。

一份可以直接照抄的检查清单

写完别急着发，用这五条过一遍。

三个数都带上周对比了吗，没有就补上。

有没有至少一个数带了分布维度，没有就挑一个拆，每个归因能追到具体条数或具体记录吗，追不到就标待确认，四个环节说清了是哪一个吗，含糊就点名到排班/话术/工单/产品，下周那个主攻方向能验收吗，不能就改成能验收的。

这五条里最容易不过关的是第三条和第五条。

客服周报最容易出现的失败不是写得不好，是看起来写得很完整但没有一条能落地。

站内还有一篇 运营周报怎么写，客服和运营的区别可以一句话说完：运营的周报是解释数字，客服的周报是解释数字背后的人在什么地方被卡住了。