客服知识库的条目不是写出来的，是从工单里捞出来的

做客服自动化，大部分团队第一步是坐下来写 FAQ。几个人关半天会议室，凭经验列出三十个常见问题，写成标准答复，灌进知识库。

上线之后命中率不到四成。不是写得不好，是经验里的常见问题和买家实际问的，重合度本来就不高。

条目要从工单里捞

客服知识库条目的三条来路

第二条最有价值。机器人答不上来才转人工，这批工单就是知识库现在的漏洞清单，而且是带着真实上下文的。

第三条最容易被跳过，因为退货原因通常在选项里，没人去看买家自己填的那句话。那句话里藏着的产品问题，往往比提问更能说明买家卡在哪。

三条来路要分开统计，不要混成一个池子。混在一起的结果是高频问题占满名额，缺口类和困惑类一条都进不来，最后知识库变成一份更整齐的旧 FAQ。

取数的时候不取样

捞工单要取近 90 天全量，不要抽样。抽样的麻烦在于低频长尾问题会被抽掉，而长尾恰恰是客服成本最高的部分——高频问题早就被处理熟了，真正耗人的是那些一个月出现两三次的。

九十天是个折中。太短覆盖不到周期性问题，太长会混进已经改版过的旧答案。

一条合格条目要有的四要素

问题原文、标准答复、适用边界、失效期。

问题原文必须保留买家的说法，不能改成你的说法。买家搜的是「怎么用」，你写的是「使用方法」，匹配就断了。

适用边界是最容易省的一栏。同一个问题，在发货前和发货后答案是两回事，在保修期内和过保又是两回事。不写边界，机器人会给出发货后的答复去回应发货前的提问，答得越标准，买家越生气。

写法上我要求一栏只写一个条件，不写复合句。复合条件机器读得懂，人复核的时候读不懂，半年后没人敢改。

失效期最没人写。产品改版、政策调整、物流方案换了，条目还挂着旧答案。我给的默认失效期是 180 天，到点强制复核，复核不了就下线。

上线之后只看两个数

自助解决率，以及转人工的原因分布。

第一个数衡量现在有没有用，第二个数决定下一轮补什么。第二个数按月看它的排序变化——哪一类原因上来了，下一轮就补哪一类条目。

只盯第一个数，团队会倾向于把答不上来的问题也硬塞进自助流程，数字好看了，买家体验更差了。两个数必须一起看。

一个提醒

知识库建好不要急着扩量。第一批控制在四十到六十条，跑满一个月，看命中率和转人工分布，再决定下一批补什么。

一开始就铺三百条，你会得到一堆从没被调用过的条目，以及一份看起来很充实、实际没用的库。