把验收拆成“可独立成立的部分”和“必须等第三方补齐的部分”,先对前者出具书面确认,后者单独挂起并写明补验条件。这样做的依据是:延期只影响依赖第三方的那条链路,不应当让已经完成的策略、素材、配置和自测结果一起被冻结。实际操作上,先列出交付清单中每一项的前置依赖,把无外部依赖的项标为可验收,把有外部依赖的项标为条件验收,再据此安排下一步。
常见情形是,第三方延期消息一到,双方都会本能地把整个项目按“未完成”处理。结果是已经交付的部分没人签字,未完成的部分又说不清差在哪,验收会议变成责任争论。另一种解释是:延期本身不是问题,问题是交付清单里没有区分“谁在等谁”。如果一份清单把所有条目都绑在同一个上线节点上,任何一环延期都会让全部条目失去验收依据。
这两种解释指向不同的处理方向。前者需要重新谈责任和时间,后者只需要把清单拆开。区分它们的证据很具体:看延期影响的是交付物本身,还是只影响交付物的某个使用前提。例如素材文件已经交付,但投放账户的开通要等第三方审核,那么素材验收不受影响,受影响的只是“可投放状态”的确认。
多数交付清单是按名称列的,比如策略文档、素材包、账户配置、数据看板。这种列法无法回答“现在能验什么”。更实用的做法是给每一项标注前置依赖来源:
分类完成后,只有第三类需要挂起。第一类应当立即进入验收,第二类可以设定客户方补齐的期限,第三类则单独记录延期原因和预计补齐时间。这个动作的直接结果是:验收范围从“全部”缩小到“当前可验部分”,会议议题随之从追责转向确认。
对依赖第三方的条目,不要写“待第三方完成后验收”,而要写清补验的触发条件和验证方法。一个可用的结构是:
假设一个场景:服务商负责搭建投放账户结构,但账户开通依赖平台审核。此时可以把“账户结构方案”和“账户可投放状态”拆成两条。前者按方案文档验收,后者写为条件验收,补验条件是审核通过后完成一次小额测试投放并核对转化跟踪。这个例子的数字仅用于说明比较方法,不代表任何实际投放结果。
延期通知本身不能证明责任归属。能区分的证据通常有三类:
反过来,如果服务商无法提供提交记录,中间产物也迟迟不交付,那么“第三方延期”更可能是整体进度问题的解释,而不是单一外部依赖。此时应先处理可独立验收的部分,再重新评估剩余条目的时间安排。
实际操作顺序可以固定为:先出拆分清单,再对无外部依赖项逐条确认,然后把条件验收项单独列成待办,最后根据待办数量决定是否调整后续排期。这个顺序的关键在于,先拿到一部分书面确认,能让后续沟通有据可依;如果一上来就谈整体延期,容易把已完成的交付也拖入不确定状态。
需要说明的适用条件是:拆分验收要求交付清单本身足够细,且每项有可核对的完成标准。如果原始合同或需求说明只写了“完成账户搭建”“交付素材包”这类笼统描述,拆分就会缺少依据,此时应先补一份交付项与依赖来源的对照表,再进入验收。对依赖第三方的条目,补验条件应当在延期发生时同步写入,而不是等到第三方完成后再补,否则验收范围会再次变得模糊。