网络推广公司，关键交付依赖第三方但对方延期时怎样拆分验收
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7fcbe882466e.html
📄
网络推广公司，关键交付依赖第三方但对方延期时怎样拆分验收
先把“第三方延期”拆成两种性质：一种是第三方物料未到，但你的推广公司已经完成可独立验证的准备工作；另一种是第三方结果本身就是合同约定的验收对象，缺少它就无法判断推广公司是否履约。前者可以拆分验收，后者只能部分验收或延期验收。拆分的关键不是把付款切碎，而是把“已可判断的部分”和“仍不可判断的部分”分开记录。
先判断延期卡住的是过程还是结果
假设合同约定推广公司负责落地页、投放素材和渠道数据回传，其中数据回传依赖第三方统计工具开通权限。第三方延期两周。这时要问：推广公司的义务是“把代码部署好并提交开通申请”，还是“数据必须已经回传并可核对”？
- 如果义务是前者，部署完成、申请记录可查，就可以先验收这一项，注明“回传验证待第三方开通后补做”。
- 如果义务是后者，就不能因为代码已部署而判定整项通过，只能记为“部分完成”，并把尾款或下一阶段启动条件挂在回传验证上。
判断依据不是对方口头说“已经尽力”，而是合同或需求文档里对交付物的描述。描述里出现“确保”“实现”“达到”时，通常指向结果；出现“提交”“部署”“配合”时，通常指向过程。
可拆分验收的三种条件
不是所有延期都适合拆分。满足以下条件之一，拆分才成立：
- 交付物之间没有强依赖。例如内容文案和落地页设计可以分别检查，文案不依赖设计定稿就能判断质量。
- 缺失部分不影响已交付部分的独立使用。例如渠道账户结构已搭好，第三方素材未到，但账户结构本身可以单独核对命名、层级和权限。
- 延期责任可归因且可记录。有邮件、工单或会议纪要能说明是第三方未响应，而不是推广公司未发起。没有这类记录，拆分验收容易变成单方面让步。
实际操作上，可以先发一封确认邮件，列出“已完成项”“待第三方项”“待第三方项对应的验证动作”。如果对方回复确认，这封邮件就成为后续验收的依据；如果对方回避或改口，说明交付边界本身没谈清，此时应暂停拆分，先补边界。
保留、改写还是退出：三种取舍的适用前提
延期发生后，旧合作关系的处理不只有“继续等”和“终止”两个选项。
- 保留适用于第三方延期属于一次性外部事件，推广公司此前交付记录稳定，且缺失部分有明确补做时间。保留时要把补做时间、验证方式和未验收部分的付款条件写进补充确认，而不是只口头约定。
- 改写适用于推广公司已交付的部分仍有价值，但原合同把太多验收绑在第三方结果上。可以把合同拆成“已交付部分按现状验收，第三方部分改为独立补充协议”，让已投入的部分不至于全部作废。
- 退出适用于第三方延期反复发生，或推广公司无法说明自己已采取哪些推进动作。退出时重点不是追责，而是确认哪些账号、素材、数据权限需要移交，避免已交付部分随关系终止一起丢失。
三种取舍的共同前提是先完成一次书面盘点：哪些交付物已可验证，哪些仍不可验证，哪些即使第三方到位也无法验证。盘点结果决定下一步是补做、改写还是移交。
拆分验收时写什么、不写什么
拆分验收的记录应包含：验收项名称、判断依据、当前状态、缺失依赖、补做触发条件。不要写“基本完成”“大致没问题”这类无法复核的描述。也不要因为第三方延期，就把推广公司已交付部分的验收标准整体降低——降标准等于把延期成本转给自己。
一个可用的短例子：假设合同含三项交付，A 已可验证，B 依赖第三方且未到，C 依赖 B 无法开始。拆分方式是先验收 A 并付款对应比例，B 记为“待依赖”，C 记为“未启动”。当第三方到位后，先验证 B，再启动 C。这样做的结果是：已投入部分不会因一项延期全部冻结，同时 B 和 C 的付款条件仍然清楚。如果第三方最终无法到位，至少 A 的价值已被确认，退出时也知道该保留什么。
延期归零不等于处理正确
第三方恢复后，抓取量、回传量或某项统计从零恢复，只能说明依赖已解除，不能单独证明推广公司此前没有拖延。恢复也可能是第三方自身排期变化、权限重新开通或数据延迟回补造成的。要区分责任，需要看推广公司在延期期间是否有持续跟进记录、是否主动提出替代方案、是否在依赖未解除时推进了其他可做项。没有这些证据，恢复只能作为补做开始的信号，不能作为验收通过的充分理由。
因此，拆分验收的收尾动作是：把补做项的验证结果与延期期间的推进记录放在一起看。两者都成立，才适合把该阶段标记为完成；只有结果恢复而过程无记录，应保留观察项，不急于关闭。
