按效果付费，报价按工时计费时怎样判断返工归属
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /df5d73d6f2fe.html
📄
按效果付费，报价按工时计费时怎样判断返工归属
结论先给：在按效果付费的框架下，如果报价按工时计费，判断返工归属的核心不是“谁做错了”，而是“返工触发条件在动工前是否被写进效果定义里”。写进去的，按约定归属；没写进去的，默认由需求提出方承担工时，除非能证明是执行方偏离了已确认的交付口径。这个结论有一个明确的反例，见下文。
先分清两类返工：口径变更与执行偏差
按效果付费常被理解成“没效果不收费”，但工时计费的部分通常针对过程投入。返工归属之所以容易吵，是因为双方对“返工”的定义不同。实务中要拆成两类：
- 口径变更型返工：效果指标、验收标准、目标页面或结算触发条件在动工后被修改，导致已完成的工时作废。这类返工由提出变更的一方承担。
- 执行偏差型返工：口径没变，但交付物不符合已确认的标准，例如约定的字段缺失、逻辑写错、素材规格不符。这类返工由执行方承担，且不应重复计入结算工时。
区分这两类的动作是：把动工前确认的效果定义、验收清单、变更记录放在同一份文档里，每次返工先对照最近一次确认版本，而不是对照口头记忆。这一步做完，归属判断从“互相说服”变成“对照版本”，下一步才谈工时怎么扣。
使上述结论失效的反例：效果定义本身是模糊的
如果动工前的效果定义只有一句“带来有效咨询”或“提升转化”，没有可核对的判定方式，那么口径变更型和执行偏差型就无法区分。此时无论怎么对照版本，都会退回到主观判断，按工时计费的返工归属也就没有稳定答案。
这种情况下，正确的做法不是继续争论这一次归谁，而是先补一个可判定的效果定义再谈扣费。例如把“有效咨询”明确为“通过指定表单提交且字段完整、可回拨的记录”，并注明假设：该定义只用于本次结算口径，不代替真实业务判断。定义一旦可核对，返工归属才有落点。
三个可区分的证据，用来定位返工原因
当双方各执一词时，用证据而不是立场来定位：
- 变更时间线：需求修改发生在交付物提交之前还是之后。之后提出的修改，倾向于口径变更型。
- 验收清单对照：交付物是否逐条满足动工前确认的清单。不满足且清单未变，倾向于执行偏差型。
- 依赖条件记录：返工是否由外部依赖变化引起，例如素材延迟、第三方接口调整、审批口径变化。这类既不是执行偏差，也不完全是需求方变更，需要在合同里单独约定归属，否则最容易变成无归属工时。
把这三项记录成简短日志，每次返工先标注属于哪一类，再决定工时是否计入。这个动作的结果直接影响下一步：归属清晰的返工可以当场结算，归属不清的返工应暂停计费，先补定义再继续。
按效果付费与按工时计费并存时的结算边界
两种计费方式并存时，要提前写清工时部分是否受效果结果影响。常见处理是：执行偏差型返工不计入结算工时，由执行方自行消化；口径变更型返工计入工时，但计入哪一方的预算要按变更提出方确定。若效果未达成，工时部分是否减免，取决于合同是否把“效果达成”设为工时结算的前置条件，而不是默认关联。
这里要区分广告计费与自然排名服务：广告按点击或展示计费时，返工通常体现为投放调整，归属看调整指令由谁发出；自然排名相关的服务若按工时计费，返工归属看的是交付口径是否变更，而不是排名是否波动。两者不能套用同一套判断。
下一步动作：把归属规则写进变更单
与其在返工发生后争论，不如在每次变更时填一张变更单，包含四项：变更内容、提出方、影响的已完工时、归属结论。下一次返工发生时，先查变更单，再查验收清单，两者都没有记录的，视为新增需求而非返工。这个动作把判断从“事后追责”前移到“事前留痕”，也决定了后续工时是否可结算、效果结算基数是否要同步调整。
如果常规做法已经试过仍然解决不了，通常不是规则不够多，而是漏掉了“效果定义可判定”这个前置条件。先补它，再谈返工归属，顺序反了就会一直循环。
