YundaDesk大促一结束，多数团队做的「复盘」是开个会，说一句「这次挺辛苦，整体还行」，然后各自回去补觉。问题是，下次大促来临时，团队记住的往往只是情绪，不是数据——同样的知识缺口会再犯一次，同样的渠道排班错配会再错一次。真正有用的复盘，是把共享工作台里躺着的对话数据拉出来，按问题类型和渠道拆解，再把结论落成两件具体的事：知识库要补什么、下次排班怎么调。
复盘不是开会，是看数据
大促期间，AI 客服和人工坐席的每一次接待、每一次转接、每一次「AI 没答上人工补答」，都留在共享工作台里。这些记录不是用来核算工作量的，是用来回答几个具体问题的：
- AI 独立解决了多少比例的咨询？哪些主题它接不住？
- 转人工的会话里，有多少是知识库缺内容，有多少是客户情绪需要人来安抚？
- 哪个渠道的咨询量涨得最快、响应最吃紧？
把这几个问题的答案写下来，复盘会才有东西可谈，而不是停留在「大家辛苦了」的层面。
大促复盘实操：高峰前值得记住的数据基线
按问题类型拆解：区分知识缺口和流程缺口
把大促期间的会话按主题聚类，通常会分成两类问题：
| 类型 | 特征 | 该做什么 |
|---|---|---|
| 知识缺口 | AI 没答上，人工靠经验现场回答，答案本该写进知识库 | 把人工的答法整理后确认入库 |
| 流程缺口 | AI 答对了，但客户仍不满意（比如改地址流程太绕、退款审批太慢） | 调整流程或审批链，不是知识库问题 |
区分这两类很关键——把流程问题当知识缺口处理，只会让 AI 更「聪明」地复述一个本身就不顺的流程。
按渠道拆解：流量从哪来、AI 接住了多少
同一份复盘，再按渠道切一遍。大促期间不同渠道的表现往往差异很大——比如网站挂件的 AI 独立解决率可能远高于 WhatsApp，因为后者的咨询更容易带情绪、带图片、带多轮追问。把每个渠道的咨询量、AI 解决率、转人工触发原因列出来，能看出两件事：这次的渠道排布是否合理，下次要不要把人力往咨询量涨得最快的渠道倾斜。
知识库补缺：把人工补答的答案确认入库
复盘中挑出的知识缺口，不要停留在文档里，直接动手补进知识库。三个来源优先处理：
- 大促期间人工反复手打的相同答案——出现三次以上的，值得写成标准条目
- AI 没答上、转人工后客户满意的回复——说明答案是对的，只是知识库里没有
- 新品或大促专属政策带来的临时问题——大促结束了但这类商品可能还在卖，答案要留下来
补完之后，下一波咨询（不管是不是大促）AI 就能直接接住这些问题，不用每次都靠坐席现场救火。
受控学习：把新答法确认入库，而不是让 AI 自己学
复盘中经常会遇到坐席「纠正 AI」的场景——AI 给了一个不够准确或语气不对的回答，坐席当场改了说法。这些纠正会生成【待确认学习建议】，但不会自动生效。复盘会正是审核这批建议的好时机：老板或客服主管逐条评审，确认后才沉淀为技能或知识库条目，每条都可追溯、可测试、可一键回滚。这也是「越用越聪明」在复盘环节的具体落地——不是 AI 自己悄悄变了，而是每一次变化都经过人的确认。
延伸阅读可以看看《教会 AI 客服越用越聪明》。
把结论变成下次的排班依据
复盘的最终产出应该是几条可执行的调整，而不是一份总结报告。可以直接沉淀成一份清单：
- 知识库已补上本次识别出的高频缺口
- 待确认学习建议已逐条评审，确认或驳回
- 下次大促的坐席排班按渠道咨询增速重新分配
- 高风险问题（退款、投诉）的转人工触发词已按本次遗漏项更新
- SLA 目标按本次实际达成情况重新校准
这份清单本身就是下次备战的起点，和《大促客服备战清单》配合使用，备战与复盘就形成了一个闭环：每一次大促都在为下一次积累经验，而不是从零开始。
复盘该多久做一次、该谁参与
大促结束后一周内是复盘的最佳窗口——数据还新鲜，坐席对具体案例还有印象。参与者不需要太多，客服主管加一到两名一线坐席就够了，重点是能看懂共享工作台数据、能对知识缺口做判断的人。复盘不必等到下一次大促才启动，日常的小促、周期性活动同样可以套用这套流程，只是规模更小、周期更短。
复盘的价值不在于写了多长的总结，而在于知识库多了几条准确答案、下次排班多了一份数据依据。把这套流程重复几次，你会发现每次大促的「救火」成分在变少——不是因为运气变好了，是因为上一次的经验真的被接住了。