优派网免费推广，报价按工时计费时怎样判断返工归属
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f64c468a3345.html
📄
优派网免费推广，报价按工时计费时怎样判断返工归属
判断返工归属的核心不是看谁改得多，而是看触发返工的原因落在哪一方的责任边界内：需求方在开工后改变已确认的范围，通常计入新增工时；执行方交付物不符合事先确认的验收标准，返工应由其自行承担。若旧内容、旧系统或旧合作关系正在退出，只有把“保留部分”和“废弃部分”提前写进确认单，工时争议才有可裁定的依据。
矛盾现象：同一批返工，双方都能说成对方的问题
常见情形是：项目进入收尾，执行方提交了一份工时追加说明，理由是“按你的意见改了三轮”；需求方则认为这三轮都在原始范围内，属于对方没做对。两边都不算说谎，因为争议点不是改了几次，而是每次修改的触发原因没有被记录。旧合作关系退出阶段尤其容易这样：前期靠口头默契推进，等到结算时才发现没有可对照的基线。
还有一种更隐蔽的情况：旧内容或旧系统里保留了一部分资产，比如沿用旧栏目结构、旧素材库或旧接口。执行方按新标准施工，需求方按旧习惯验收，返工就变成了标准之争，而不是工作量之争。
两种解释：范围变更型返工，还是质量不达标型返工
第一种解释是范围变更型返工。已确认的交付范围之外，需求方新增了要求，或推翻了此前确认的决定。这类返工本质是新工作，按工时计费时理应追加，但前提是变更发生前有书面确认，且执行方在收到变更时给出了影响工时的提示。
第二种解释是质量不达标型返工。交付物没有达到开工前双方确认的验收标准，比如约定的字段缺失、页面在目标环境下无法正常显示、旧数据迁移后出现明显丢失。这类返工是执行方履行合同义务的一部分，不应单独计费。区分这两种解释，不能靠事后回忆，只能靠开工前留下的基线文件。
能区分两种解释的证据：确认单、变更记录与验收口径
可用的证据按证明力从高到低排列：
- 范围确认单：写清交付物清单、不包含什么、验收方式。没有“不包含什么”，范围就会被无限解释。
- 变更记录：每次需求方提出新要求的时间、原话、执行方回复的工时影响。缺少执行方的工时提示，追加计费的说服力会下降。
- 验收口径：用可观察的结果描述，而不是“大气”“再优化一下”这类无法裁定的表述。
- 旧资产处置清单：退出旧系统或旧合作关系时，明确哪些保留、哪些废弃、保留部分由谁负责维护。
一个假设例子：某项目约定首页改版按四十小时计费，确认单写明“不含移动端适配”。开工后需求方要求补移动端，执行方当天回复“预计增加十二小时，是否继续”。需求方回复“继续”。这十二小时属于范围变更，应追加。反之，若确认单写明“含移动端适配”，执行方交付后在常见机型上错位，修复耗时不应计费，因为验收标准已经覆盖了这一项。
实际动作：把返工判定前置到开工前的一次确认
具体做法是在开工前发一份简短确认，包含三部分：交付物清单、明确排除项、验收方式。发出后请对方回复确认，哪怕只回一句“按这个来”。这个动作的直接结果是：后续每次返工都能对应到“在范围内”或“在范围外”，工时归属不再依赖谁的记忆更好。
如果对方不愿意逐条确认，可以退一步，只确认排除项和验收方式这两项。排除项决定了哪些追加要计费，验收方式决定了哪些修复不能计费。两项确认完成后，再开始计工时，争议空间会明显缩小。
退出旧合作时，保留部分要先定价再交接
旧内容、旧系统或旧合作关系退出时，最容易忽略的是“保留部分”的维护责任。假设旧素材库仍要沿用，但格式需要转换，这部分转换工时属于谁？如果不在交接清单里写明，执行方可能按新增需求计费，需求方则认为是收尾工作。可行的处理是：在交接清单中把保留部分单列，注明转换、迁移、后续维护分别由哪方承担，以及对应是否计入工时。清单确认后再动手，返工归属才有落点。
需要提醒的是，免费推广或免费额度并不等于零成本，时间投入、迁移工作和沟通成本仍然存在，按工时计费的项目更要把这些隐性投入写进确认范围。报价按工时计费时，返工归属最终取决于开工前那份确认单是否把范围、排除项和验收方式写清楚；写得越具体，后续越不需要靠争论来分摊工时。
