新增需求最容易失控的地方，不是需求本身复杂，而是它常常在沟通、交付或售后过程中临时出现，并被顺手混入当前任务。结果是范围不断扩大、时间节点被打乱，原本已经确认的交付内容也变得难以验收。SOP 的作用，是把“听到新要求”变成一套可判断、可记录、可追踪的动作，而不是要求执行者凭经验临场决定。

先定义新增需求的触发条件

“客户又提了一个想法”还不够具体，触发条件应写成能够启动流程的事件，例如：客户在交付后提出原范围之外的功能，或现有任务需要增加未确认的文件、修改内容和服务环节。

一旦触发，先不要直接执行，而是建立一条新增需求记录，至少写清楚：

• 客户和关联项目；
• 新需求的具体描述；
• 与原交付范围的关系；
• 需要补充的资料或确认事项；
• 可能影响的时间、费用和交付方式；
• 当前状态和下一次跟进动作。

这里的关键是把“口头要求”转化为“可判断对象”。如果需求信息不完整，状态应标记为“待补充”，而不是直接进入制作或修改。

用检查点区分三种处理路径

新增需求进入 SOP 后，应先判断它属于哪一类：原范围内的修改、交付缺陷，还是范围变更。原范围内的修改可以按照既有交付流程处理；交付缺陷应进入售后支持流程；范围变更则需要暂停执行，重新确认方案。

判断时可以检查：

• 是否已经包含在原合作范围和交付物中；
• 是否属于原交付结果未达到约定要求；
• 是否会增加工作内容、时间节点或沟通成本；
• 客户是否需要重新确认交付方式。

只有完成分类，才能决定是继续当前任务、修正已有交付，还是建立独立的新任务。不要因为客户表达得紧急，就跳过范围判断。

把确认结果写成新的执行入口

如果确认属于新增需求，SOP 应规定后续动作：记录需求，说明影响，确认时间、费用和交付方式，再决定是否建立新任务。未经确认，不应直接修改当前版本，也不应把新增内容隐藏在原项目清单中。

最终关闭条件也要写清楚。新增需求完成后，应保存最终版本，记录客户确认结果，并将项目状态更新为“已验收”“待补充”或“转为新需求”。如果客户继续提出范围之外的内容，就再次触发同一套流程。

这套 SOP 不需要复杂。只要能让每次新增需求都经过“触发—记录—分类—确认—执行—关闭”，业务就不再依赖临场记忆。执行几次后，再根据返工、范围争议或遗漏情况调整检查点，流程才会真正贴合实际工作。