第 21 章　把一次服务复盘成可复制的交付流程

01一个真实场景：想把这次交付变成"下次照做就行"

接着上一章。这次 2 天内训交付完，效果不错。你想把它变成"下次照着做就行"的 SOP，可服务记录里既有真事实，又有你临场的即兴发挥，还有一堆没验证的想法。一股脑写进流程，就会把这次的偶然，当成以后的标准。

02先区分"这次发生了什么"和"以后应该怎么做"

让 WorkBuddy 先分类，别直接把全部内容写成标准流程：

本次事实：
本次关键判断：
本次失败或返工：
本次可以复用：
还需要验证：

03这一趟它动用了什么

• 资料：这次交付的服务记录——排期、现场问答、学员反馈、你的临场决策；
• 任务：让它先分类、再只根据已确认事实生成 SOP 草案，把没验证的单独放到"待验证"；
• 要它分清：事实、判断、建议、待验证——四样东西不能糊在一起。

04让它生成 SOP 草案

请只根据已确认事实，整理下一次交付流程：
1. 开始前准备；
2. 进行中的关键动作；
3. 必须人工确认的节点；
4. 出现异常时的回退；
5. 结束后的回流。
把未确认内容放到"待验证"，不要混入正式步骤。

05必须你判断的：SOP 的价值不在写得完整

真正有用的 SOP，是让下一次执行更容易，而不是把所有可能情况都写进去。先覆盖最常见、最容易重复的路径，异常单独保留。每个关键节点要有人负责确认——SOP 里写"人工确认"，不是走过场。

06结果与留下的资产

跑完你得到两样能直接复用的东西：一份经过你确认的交付 SOP 草案，和一张下一次起盘清单。一次成功的交付，就这样从"你个人的手感"，变成了"团队能照着跑的流程"——这，就是把一次经验真正沉淀成资产。

07完成检查

• 事实、判断、建议和待验证分开；
• SOP 只包含已经确认的步骤；
• 每个关键节点有人负责确认；
• 异常有回退路径；
• 下一次可以用清单直接起盘。

第二篇到这里就完成了。下一篇进入进阶系统：怎样把"一次能用"，变成一支越来越懂业务的 AI 员工队伍。