用 WorkBuddy 整理客服工单：做出一张能开会用的分类统计表

客服工单堆到几百条的时候，「这周主要是什么问题」这个问题就没人答得上来了——因为没人有时间一条条看。

这是官方场景包里「业务数据洞察与自动化响应」的典型用法之一，官方给的描述是：分析用户反馈与评论文档，情感归类与问题提炼，生成附带优化建议的周期性洞察报告。

这篇讲怎么把它做成一张能直接拿去开会的表，而不是一段读起来顺但没法用的总结。

本文依据 WorkBuddy 官方产品页场景包描述、官方使用技巧与权限模式文档，核对日 2026-08-16。我们没有安装客户端，本文不含实测数据。

一、动手之前：先脱敏

工单里通常带着客户手机号、姓名、订单号、有时还有地址。

如果你的分析只是要「本周主要是什么问题」，这些字段一个都不需要。

处理前先删掉——保留工单内容、时间、渠道、状态就够了。这一步是纯手工的，但它是你唯一 100% 可控的环节。

为什么必须做：官方在日志说明里明确写了日志可能包含对话记录、设备信息等数据；官方英文隐私文档里那个「帮助优化模型」开关默认是开启的（开着时对话可能被用于训练和改进模型）。客户信息不该进这条链路。

配套目录：按官方建议建独立文件夹，比如 kefu-gongdan\，里面放脱敏后的副本。

二、绑定的交付物：一张分类统计表

这个场景的核心产出，就是这张表。 别要「总结」，要表。

【目标】把 <工单文件> 整理成本周工单分类统计

【输入】D:\WorkBuddy\kefu-gongdan\本周工单_脱敏.xlsx
        （已删除手机号、姓名、地址列；保留：工单内容、提交时间、渠道、状态）

【输出格式】保存为 xlsx，文件名 工单统计_20260817.xlsx，含两个表：

表一「分类统计」，列：
  问题类型 | 条数 | 占比 | 代表性原文（2 条，逐字引用）

表二「高频问题 TOP5」，列：
  排名 | 问题描述 | 条数 | 首次出现时间 | 最近出现时间

【约束】
- 分类必须基于原文内容，不要归入原文没出现过的类别
- 条数必须与原始数据对得上（总和 = 总工单数）
- 引用原文逐字引用，不要改写、不要润色
- 无法归类的单独列一类「其他」，不要硬塞
- 不做「客户为什么这么想」的心理推测
- 不需要开场白

几个设计考虑：

• 「条数总和 = 总工单数」 是最好的验收锚点——一眼能看出有没有漏或者重复计算；
• 「代表性原文逐字引用」 让每一类都能追回去核对；
• 「无法归类的单独列『其他』」 很重要——不给这个出口的话，它会把不相关的工单硬塞进某一类，把统计做脏；
• 「不做心理推测」 是这类任务最容易越界的地方。

三、★ 客服场景独有的红线：不代客户做承诺

这一条是客服岗位特有的，其他场景没有。

表现形式：你让它「基于这些工单起草一版回复模板」，它可能写出这样的句子——

• 「我们会在 24 小时内为您处理」
• 「已为您加急，请放心」
• 「后续版本会修复这个问题」

这三句话都是承诺，而且是代表公司做出的承诺。AI 不知道你们的 SLA 是多少、不知道加急流程存不存在、更不知道产品路线图上有没有这一项。

指令里的防线：

起草回复时：
- 不写具体时限承诺（如「24 小时内」），改为「我们会尽快跟进」
- 不承诺产品改动或版本计划
- 不使用「已为您加急」「一定」「保证」这类表述
- 需要承诺的地方留空并标注 <此处需人工填写>

最后一条最实用——留空比让它编一个好，你一眼就知道哪儿需要自己拍板。

四、验收：三查

第一查：条数对不对。 各类条数加起来等于总工单数吗？对不上说明有漏计或重复。这一步不通过，整份重来。

第二查：抽两条原文回去核。 随机挑两条「代表性原文」，回原始文件确认是不是逐字的、是不是真属于那一类。

第三查：有没有承诺句。 通读一遍生成的回复模板，搜「小时内」「保证」「一定」「已加急」这类词。有就删。

五、周期化：能不能配成自动任务

客服工单统计是典型的周期性任务，符合官方自动化判据的前两条（重复性高、规则明确）。第三条「无需实时人工干预」要看你的情况——如果分类口径稳定，那就满足。

配的时候两个建议：

一、工作空间别用默认的。 官方说明自动化默认分配 automation-xxxx 工作空间——建个 kefu-weekly\ 之类的独立目录，名字一看就知道是哪个任务。

二、「推送到小程序」慎开。 官方说明开启后推送会通过安全链路把文件同步到云端。工单数据即使脱敏了，也建议先想清楚。

折中做法：让它只推送一句不含具体内容的摘要（比如「本周工单 213 条，TOP1 问题：登录异常，47 条」），完整表格仍存在本地。

还有一条兜底必须写进提示词：

找不到数据时，如实写「本期无数据」，不要编。

自动跑的时候没人当场发现问题——一份看起来正常但内容是编的统计表，可能好几周都没人察觉。

六、几件不该交给它的

• 判断某条工单该怎么处理——升级、退款、补偿，这些是要担责的决策；
• 给客户发消息——发出去收不回来。让它起草、你过目、你手动发；
• 归因：「这周投诉多是因为上周那次更新」——这是推断，不是数据里的事实。让它列客观特征（哪天开始多的、涉及哪些功能），归因由你做；
• 涉及具体客户的个案分析——那需要人去看上下文，而且个案里的敏感信息不该进工作目录。

七、一个能提高长期价值的做法

每周跑完之后，把分类口径固化下来。

如果你发现每周都在跟它解释同样的分类标准（什么算「功能问题」、什么算「体验问题」），那就值得用官方的「创建技能」——输入任务描述，让它把这套规则做成一个技能，以后调用一次就带上了。

判断标准很简单：这件事你是不是每次都要把同样的要求重复说一遍？

小结

• 官方场景包对应的是用户反馈与舆情分析（情感归类与问题提炼，生成周期性洞察报告）。
• ★ 动手前先脱敏：手机号、姓名、地址这些分析用不上的字段先删掉。
• 绑定交付物：一张分类统计表（分类/条数/占比/代表性原文 + 高频问题 TOP5），别要「总结」。
• 四个设计要点：条数总和 = 总工单数（最好的验收锚点）、原文逐字引用、给「其他」这个出口、不做心理推测。
• ★ 客服独有红线：不代客户做承诺。指令里禁止具体时限、禁止承诺产品改动，需要承诺的地方留空标注 <此处需人工填写>。
• 三查验收：条数对不对（不通过整份重来）→ 抽两条原文核 → 搜有没有承诺句。
• 配自动任务：别用默认工作空间、慎开推送到小程序、提示词里加「找不到数据就如实写，不要编」。
• 分类口径稳定之后，可以用「创建技能」固化下来。

功能与场景描述以官方为准，核对日 2026-08-16。